Fixes requiring judgment calls in thread limit, scalar arg count, connection limit. Subset #11.

Per the AI Analysis in #11 (Bucket 3, item 3i), three book/code mismatches are interpretive rather than factual — each chapter is consistent with one reading and another chapter consistent with another reading, so they were deliberately kept out of the per-item PRs being opened for 3a–3h. Filing them here as a separate issue so we can decide the canonical wording before any book PR lands.

Each item below has the verbatim text from the book, the actual code, and a proposal that I think is the least-surprising answer. If you sign off on (or counter) any of these I'll open the corresponding PR(s).

3i.1 — Thread limit per PID

The book says two different things.

Book site A — ch02-00-server-architecture.md L11:

up to 32 threads

Book site B — ch01-05-glossary.md L55:

Each PID can have up to 30 threads. Note that thread 0 is always present and it is the interrupt handler thread.

Code — kernel/src/arch/riscv/process.rs L6-L9:

pub const MAX_THREAD: TID = 31;
pub const EXCEPTION_TID: TID = 1;
pub const INITIAL_TID: TID = 2;
pub const IRQ_TID: TID = 0;

with threads: [Thread; MAX_THREAD] L85 — 31 in-array slots — plus IRQ_TID = 0 handled separately, for 32 addressable TIDs. Of those:

• TID 0 (IRQ_TID) — reserved for the interrupt handler
• TID 1 (EXCEPTION_TID) — reserved for the exception handler
• TIDs 2..31 — user-schedulable (INITIAL_TID upward) → 30 slots

So:

• ch02's "32" is correct only if you count slots including both reserved TIDs.
• ch01-05's "30" is correct as the user-schedulable count, but the "thread 0 is always present" parenthetical undercounts the reserved slots (TID 1 is also always present and is the exception handler, not just IRQ).

Proposal: standardize on "up to 30 user-schedulable threads per PID (32 TID slots total: TID 0 is the interrupt handler, TID 1 is the exception handler)". Update both sites accordingly.

3i.2 — Scalar-message argument count

The book is internally inconsistent across four sites.

Code — xous-rs/src/definitions/messages/mod.rs L92-L107:

pub struct ScalarMessage {
    pub id: MessageId,
    pub arg1: usize,
    pub arg2: usize,
    pub arg3: usize,
    pub arg4: usize,
}
…
pub fn to_usize(&self) -> [usize; 5] { [self.id, self.arg1, self.arg2, self.arg3, self.arg4] }

So Scalar / BlockingScalar carry 1 opcode id + 4 args = 5 usize words on the wire. The "5" sites are counting wire words; the "4" sites are counting argument words only. The ch07-08 scalar5 reference is not a message type — it's a return type variant (Result::Scalar5) that carries 5 scalars back from a server, paired with ReturnScalar5.

Proposal: standardize on "4 argument words plus 1 opcode word" for the message call sites (ch00, ch07-00, ch01-05) and rewrite ch07-08 to call out that scalar5 is the return shape, not the call shape:

• ch00 L48: "only 4 usize-sized arguments per message, plus the opcode" (currently correct in spirit, but says "u32" — usize is more accurate on 32-bit Xous targets and matches the code)
• ch01-05 L51: change "maximum of 5, 32-bit arguments" → "maximum of 4, usize-sized arguments (the 5th word in the on-wire layout is the message opcode)"
• ch07-00 L49 is already correct.
• ch07-08 L12: leave the description of scalar5 but clarify that scalar5 is the return type — the 5 32-bit words come back from the server via Result::Scalar5, not in the original call.

3i.3 — Connection limit + stale MAX_CID

The book is correct as written, but the code carries a stale constant that contradicts it.

Book — ch01-05-glossary.md L27 and ch07-00-messages.md L27 both say 32.

Code — kernel/src/services.rs L224 declares connection_map: [Option<NonZeroU8>; 32], and kernel/src/syscall.rs L1301 prints conns:%/32 — both consistent with the book.

But xous-rs/src/definitions.rs L11 still has:

pub const MAX_CID: usize = 34;

grep -r MAX_CID over xous-core returns only its definition; it appears to be dead and stale.

Proposal: no book change needed (the book is right). Code-side follow-up: delete MAX_CID = 34 from xous-rs, since nothing reads it and its value contradicts the actual connection-map size. I can open that as a separate PR against xous-core if you want.

Asks

1. For 3i.1 (thread limit) and 3i.2 (scalar args): does the proposed wording work? If so I'll open one PR per book site fixed.
2. For 3i.3: confirm MAX_CID = 34 is dead code and OK to remove (and whether you'd prefer me to send that PR against xous-core).
3. Any related "judgment call" you'd like folded in while these are being touched?