FABRIC-3.md §XXXIII: multiuser/multitasking DoE design (no code yet)

Scopes the DoE Bob asked for after §XXXII closed -- "a pretty big
experiment... long running multi-factor DoE that sort of puts the OS
through its paces." Design only, per this project's standing
plan-before-code discipline.

Three corrections found and recorded before the design could be
trusted:
- Console sessions are not a concurrency axis and this isn't a defect:
  console.c hardcodes one physical UART as static global state, not an
  instantiable abstraction. One physical terminal, one foreground
  session, by construction. Bob's reaction (eventual multi-seat/
  telnet-ish/pty-multiplexer idea) recorded separately in memory,
  explicitly deferred behind this DoE.
- The real, provable concurrency primitive is VM-EXEC (doe-campaign.4th's
  own THREE-VM-CAMPAIGN already proves the pattern), resolved through
  the full VM registry (unbounded kmalloc list), not messaging.4th's
  16-slot routing table -- checked live, not assumed.
- No FORTH-reachable monotonic clock exists; latency dropped as a
  response variable rather than building a new timing primitive under
  this scope.

Also flagged, not chased: every acceptance boot this session produced
an L8-DoE CSV despite init.4th never calling it and KERNEL_ARGS
defaulting to empty -- likely a stale starforth.cfg survivng `clean`.
Practical decision: the new campaign is its own driver, independent of
whatever causes that.

Ratified design: concurrency level (2/4/8 VM-EXEC-driven VMs) x
workload assignment (uniform/heterogeneous across the existing 10
workload capsules) as the crossed factorial; identity origin
(WIREBIND vs UNATTENDED-BIRTH) as a fixed arm rather than crossed, since
WIREBIND's per-identity USB-attach cost doesn't scale into a full
factorial. Response variables: correctness-proxy (completes without
vm->error), heat/CV stability under contention, completed-trials-per-
interval in place of the dropped latency variable.

Punch list recorded; implementation not started per standing "plan
approval is not a start signal" rule.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BWpNjdwPtFLuVLaAq44L9K

FABRIC-3.md

@@ -4810,8 +4810,129 @@ carefully rather than mechanically.
 
 This closes the four-part initiative opened in §XXXII: Stage A (`USE` fix, root-caused past the
 original symptom into the Hera-fault-scoping gap it exposed), Stage B (logging policy +
-level-aware eviction), Stage C (triage), Stage D (fixes, this entry). §XXXII.2's human-vs-
-unattended identity model remains open as Stage E, not started this pass -- its four design
-questions (§XXXII.2) still need settling on paper before any code, per that section's own
-"Stage E" plan.
+level-aware eviction), Stage C (triage), Stage D (fixes, this entry).
+
+**Stage E update, 2026-09-16 -- also closed.** §XXXII.2's human-vs-unattended identity model
+is fully settled and built: all four design questions ratified on paper (with two mid-course
+corrections recorded plainly, not folded in silently -- the `drive_uuid` scratch-device
+mechanism and the ACL-bit-vs-`ACL.4th` correction), then all four punch-list items
+implemented and live-verified end to end (`MINT-SCRATCH`/`MINT-SCRATCH-EMIT`,
+`UNATTENDED-BIRTH`, `CONSOLE-ATTACH`), closing with a real mint -> birth -> console-attach ->
+relayed-command-executes-on-target proof, not just a structural argument. §XXXII as a whole is
+now fully closed; the multiuser/multitasking DoE this unlocked is scoped separately as §XXXIII.
+
+## XXXIII. Multiuser/multitasking DoE -- design, no code yet (2026-09-16)
+
+**Origin.** With §XXXII closed (real concurrent VMs, real identity for both human and
+unattended origins, real console attachment), Captain Bob asked whether we're positioned to
+run a DoE that actually stresses the multiuser/multitasking capability itself, "a pretty big
+experiment... long running multi-factor DoE that sort of puts the OS through its paces." This
+section settles the design on paper before any code, per this project's own standing
+discipline for every initiative this size.
+
+### XXXIII.1 -- Three corrections found before the design could be trusted
+
+**Console sessions are not a concurrency axis -- confirmed, not a defect.** `console_get_vm_
+name()` (`console.c`) is a single global `USE` mutates; `sk_repl_dispatch_line()`'s pairing
+check (`repl.c:1241-1266`) reads it to decide which one `<name>~user` VM the physical terminal
+is currently relaying to. This is not an oversight -- `console.c` hardcodes one physical UART
+(`NS16550_BASE`/COM1, a compile-time constant, not a discoverable device list) and every piece
+of console state is a static module global, not a field on an instantiable type. One physical
+terminal, one foreground session, by construction. Multitasking (many VMs alive and doing real
+work concurrently) is real and unbounded by this; simultaneous *human* interaction from two
+different physical seats is not something this kernel builds today. (Captain Bob's own
+reaction to this finding is recorded separately, [[project_multiseat_console_idea.md]] in
+memory -- a future multi-seat/telnet-ish/pty-multiplexer initiative, explicitly deferred
+behind this DoE, not scoped here.)
+
+**The real, provable concurrency primitive is `VM-EXEC`.** `doe-campaign.4th`'s own
+`THREE-VM-CAMPAIGN` already proves the pattern live: Hera dispatching work onto named child
+VMs (`S" DOE-WORK" S" Hermes" VM-EXEC`) with no console involved at all. Checked live:
+`mama_word_vm_exec()` resolves its target via `capsule_vm_find_by_name()` against the full VM
+registry -- a plain `kmalloc`'d linked list with no hard size cap -- not against
+`common:messaging.4th`'s 16-slot `VM-NAME-ADDRS`/`VM-NAME-LENS` routing table (that table is
+scoped to `MSG-SEND` destination routing for the console-relay path specifically, and has
+nothing to do with `VM-EXEC`). Concurrency level for this DoE is therefore bounded by kmalloc
+heap headroom and sane trial runtime, not by any 16-VM ceiling.
+
+**No FORTH-reachable fine-grained clock exists.** `sf_monotonic_ns()` is used internally in C
+(`dictionary_heat_diagnostic_words.c`, `physics_benchmark_words.c`) but nothing wraps it as a
+callable word, and `capsule_mint.c`/`capsule_runcap.c` both say outright that no monotonic-ns
+source exists anywhere in this codebase yet as a settled, general-purpose thing. **Latency is
+dropped as a response variable for this campaign** rather than building a new timing primitive
+under this scope; a future latency-focused campaign can add that word separately if wanted.
+
+**Found live, unresolved, noted rather than chased:** every acceptance boot this whole
+session produced a `doe-<arch>-<timestamp>.csv` even though `capsules/init.4th` itself never
+calls `doe.4th`/`L8-DOE`, and `Makefile.starkernel`'s `KERNEL_ARGS` defaults to empty (the
+`--doe` flag that does trigger it, `kernel_main.c:896-901`, is opt-in). Most likely a stale
+`starforth.cfg` left on a boot image from an earlier session that `clean` doesn't touch --
+not root-caused, out of this section's scope. **Practical decision:** this new campaign is its
+own explicitly-invoked driver capsule, independent of whatever is causing the existing L8 DoE
+to run automatically; it does not attempt to disable or coordinate with that behavior.
+
+### XXXIII.2 -- Ratified design
+
+**Factor A -- concurrency level:** count of `VM-EXEC`-driven workload VMs alive at once.
+Levels: **2 / 4 / 8**.
+
+**Factor B -- workload assignment:** which of the 10 existing workload capsules
+(`workload-0.4th`..`workload-9.4th`) each concurrent VM runs. Levels: **uniform** (every VM
+runs the same one, chosen per-trial) / **heterogeneous** (round-robin distinct assignment
+across the live VMs).
+
+**Identity origin -- a fixed arm, not a crossed factor.** Crossing origin into the full
+factorial would multiply the expensive axis (WIREBIND needs a real or emulated USB attach
+event per identity) across every concurrency/workload cell. Instead:
+- **Main block:** every concurrent VM is `UNATTENDED-BIRTH`'d (cheap, scales freely to the
+  full factorial above).
+- **Fixed arm:** one smaller, separate block at a single concurrency level (4) and a single
+  workload mode (heterogeneous), with a mix of real WIREBIND-attached and unattended
+  identities, sized to what's actually practical to automate for USB attach at trial count
+  (punch-list item: confirm the automation mechanism, e.g. reusing the existing minted-
+  thumbdrive-image approach from the identity-verification campaigns, before fixing rep count).
+
+**Response variables (latency dropped, see XXXIII.1):**
+- **Correctness proxy:** each trial VM completes its assigned workload run without setting
+  `vm->error` -- this measures "ran to completion under contention," not the workload's own
+  arithmetic correctness (the existing 10 workload capsules are physics-load generators, not
+  self-checking programs like the std79 exerciser was). Noted as a real limitation, not
+  silently assumed away.
+- **Heat/CV stability per VM:** the same physics metric the existing single-VM L8 DoE already
+  trusts (`VM-PHYSICS-STATUS`, `INFER-VARIANCE@`-family words), now measured with real
+  concurrent neighbors present -- does contention perturb what a single VM's own physics
+  runtime reports about itself.
+- **Completed-trials-per-interval:** a throughput proxy standing in for the dropped latency
+  variable -- how many of the N concurrent VMs finish their assigned run within the trial's
+  fixed iteration budget.
+
+**Trial mechanics (single boot per architecture, matching `doe.4th`'s own model -- not one
+reboot per trial):** for each cell in a Fisher-Yates-shuffled run matrix (concurrency level ×
+workload mode × rep), `UNATTENDED-BIRTH` N fresh identities, assign workloads per the cell's
+mode, drive each via `VM-EXEC` for a fixed iteration budget, collect the three response
+variables per VM, then tear every trial VM down (`KILL`) before the next cell -- clean
+isolation between trials, matching `doe.4th`'s own `PHYSICS-RESET-STATS`-per-run discipline.
+CSV row per trial, same streaming-to-serial convention `doe.4th`'s `EMIT-ROW` already uses.
+
+**Reps and scale, proposed (not yet fixed -- punch-list item):** 3 concurrency levels × 2
+workload modes = 6 main-block cells; 10 reps/cell = 60 main-block trials. Fixed arm: 1 cell,
+reps TBD pending the WIREBIND-automation punch-list item above. Total comfortably in the
+"long-running, puts it through its paces" range Bob asked for without being unbuildable in one
+pass -- open to widening (more concurrency levels, more reps) once the harness itself is
+proven at this scale.
+
+### XXXIII.3 -- Punch list (design only -- no code authorized yet)
+
+- Confirm/build a practical WIREBIND-automation path for the fixed arm's mixed-origin block
+  (reuse existing minted-thumbdrive-image tooling from the identity-verification campaigns, or
+  scope a new one) and fix its rep count once the per-trial cost is known.
+- Build the driver capsule (`multiuser-doe.4th` or similar): run-matrix generation/shuffle
+  (reuse `doe.4th`'s own `RUN-MATRIX`/`SHUFFLE-MATRIX` pattern), per-trial birth/assign/drive/
+  measure/teardown, CSV emission.
+- Decide the per-VM iteration budget (fixed count vs. fixed wall-clock-equivalent tick count,
+  given no monotonic clock is available -- likely a fixed heartbeat-tick count, matching how
+  the existing physics runtime already paces itself).
+- Acceptance: 3-arch clean boot running the full campaign to completion, CSVs committed per
+  standing convention, at least one full pass reviewed for plausibility before calling the
+  harness itself proven.