std79 DoE campaign rerun post-Stage-4: 81/81, §XIV caught live by rerun's own harness bug (FABRIC-3.md §XXXI)

Reran the established 3x9x3 randomized full-factorial campaign
(std79-doe.fth) on all 3 architectures per standing project discipline
(any Stadium-adjacent change reruns the whole DoE from the top).

First amd64 attempt exposed a real test-harness bug that re-triggered
the already-known §XIV concurrent-attach gap: the sequential-attach wait
loop checked for any recent WIREBIND-attached line instead of the
specific identity requested, firing the next device_add before the
kernel finished the current one. Only 2 of 8 identities attached; the
campaign itself completed cleanly with graceful "VM-EXEC: VM not found"
refusals rather than corrupting anything. Fixed the wait loop, discarded
the invalid run's campaign result (its boot log kept for the record),
reran clean.

Corrected reruns: all 8 identities individually confirmed on all 3
architectures, zero VM-not-found errors, zero faults, 81/81 trials
correct against established baseline values. Raw logs archived at
experiments/std79-doe/results-20260915-stage4/.

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

FABRIC-3.md

@@ -4082,3 +4082,49 @@ attach detection gap, still open, sidestepped via sequential attach), the MSG-TI
 dual-ownership rough edge (still open, not observed failing), and the newly-found pre-existing
 `USE`/BINDSTEP crash (flagged, not fixed).
 
+## XXXI. std79 DoE campaign rerun post-Stage-4: 81/81, plus §XIV caught live by the rerun's own
+test harness (2026-09-15)
+
+**Bob's explicit request: rerun the established 3×9×3 randomized full-factorial campaign
+(§XV/§XVI, `experiments/std79-doe/std79-doe.fth`) on all 3 architectures**, matching this
+project's own standing discipline that any Stadium-adjacent mechanism change reruns the whole
+DoE from the top, not just a fresh 3-arch boot smoke test.
+
+**A real harness bug caught §XIV live, on the first attempt.** The orchestration script's
+sequential-attach wait loop checked for *any* recent `WIREBIND: <name> attached and ready` line
+rather than the *specific* identity just requested, so it repeatedly reported success within a
+couple of seconds and fired the next `device_add` before the kernel had genuinely finished the
+current one -- exactly the near-simultaneous-attach pattern §XIV names as the trigger. Result on
+amd64's first attempt: only 2 of 8 identities (`rajames`, `06`) ever actually attached; the
+other 6 silently never triggered their own `WIREBIND: <id> attached` line at all, matching §XIV's
+own description precisely. **The campaign itself did not corrupt anything or crash** -- `VM-EXEC`
+dispatch into a never-attached identity name resolves cleanly to `VM-EXEC: VM not found: <name>`
+and returns, so those specific trials' computational content simply never ran while the
+DOE-RUN/header bookkeeping around them still printed and the run reached "STD79-DOE: complete"
+normally. Caught by checking `VM-EXEC: VM not found` occurrence count in the resulting log
+(non-zero, should always be zero) before trusting the run -- not by anything failing loudly.
+Fixed the wait loop to confirm the specific identity by name with a per-identity timeout and a
+hard abort on failure; discarded the invalid first amd64 run's campaign result (its own boot log
+kept, not discarded, per this project's logs-are-audit-artifacts convention) and reran clean.
+
+**Clean reruns, all 3 architectures, corrected harness:** all 8 non-Zuse identities confirmed
+individually attached (26-52s each, consistent with historical single-identity attach timing),
+zero `VM-EXEC: VM not found` occurrences, zero `VM fault` halts, `STD79-DOE: complete` reached on
+every boot. All 27 run_ids (0-26) present on every architecture, verified both by direct scan and
+by hand-tracing the known cosmetic CSV-splice artifact (heartbeat CSV rows interleaving with
+trial `DOE-RUN,` output on the shared serial line, documented since 2026-09-12) across the one or
+two run_ids each raw log happened to splice mid-token. **Result: 81/81 trials correct across
+amd64/aarch64/riscv64, zero mismatches from established baseline values** (the same
+distinctive `M*`/`M/MOD`/`2147483648 2/` markers this project has checked every prior run).
+Raw logs archived at `experiments/std79-doe/results-20260915-stage4/` per the existing directory
+convention; see that directory's own README entry for the harness-bug detail in brief.
+
+**Scope note, stated explicitly so a future reader doesn't over-claim from this result:** this
+campaign drives every identity via direct `VM-EXEC` dispatch, unchanged since §XV -- it does
+**not** itself exercise Stage 4's new switch-signal participation (WIREBIND VMs as genuine
+preemption targets). That was verified separately, live, in §XXX (real QMP-driven attach +
+`VM-EXEC` compute-check + `EJECT` teardown, one identity, all 3 architectures). This campaign's
+own value here is what it has always been: a large-N cross-identity, cross-architecture
+correctness regression check, now re-confirmed clean after Stage 4's registry/switch-signal
+plumbing changes -- not a preemption-specific test.
+

capsules/BLOCK_MAP.md

@@ -1,5 +1,5 @@
 # Capsule Block Manifest — Auto-generated
-<!-- Generated by mkcapsule --manifest  2026-09-15T07:25:25Z -->
+<!-- Generated by mkcapsule --manifest  2026-09-15T08:37:42Z -->
 <!-- DO NOT EDIT — re-run mkcapsule --manifest to refresh.  -->
 <!-- Hand-written justifications and immutability notes live  -->
 <!-- in MANIFEST.md alongside this auto-generated index.      -->

experiments/std79-doe/README.md

@@ -95,3 +95,21 @@ sd(K) = 0, 100% conserved, across all three architectures, nine identities, and
 replicates — zero deviation.** See `report-20260912/README.md` for the full pipeline and the
 report itself for the complete analysis and discussion, including why this also serves as a
 free regression check on the two Stadium fixes (§XVI–XVII) that landed the same week.
+
+`results-20260915-stage4/` — rerun after FABRIC-3.md §XXVIII Stage 4 (WIREBIND VMs as Stage 3
+switch-signal participants + mark-and-defer tombstone reap), same discipline as every prior
+Stadium-adjacent change: any relevant mechanism change reruns the whole DoE from the top, one
+boot per architecture, all 9 identities simultaneously live, same seed (12345). **Result: 81/81
+trials correct, 0 mismatches, 0 `VM-EXEC: VM not found` errors, zero `VM fault` halts, on all
+three architectures.** Note for anyone rerunning this: the sequential-attach wait loop must
+confirm each identity's own specific `WIREBIND: <name> attached and ready` line before
+proceeding to the next — a loop that just checks for *any* recent WIREBIND-attached line will
+spuriously "succeed" immediately and fire the next `device_add` before the kernel has actually
+finished the current one, re-triggering §XIV's own known concurrent-attach detection gap (caught
+live during this rerun: a first attempt with a buggy wait loop attached only 2 of 8 identities,
+though the campaign itself still completed cleanly with graceful `VM-EXEC: VM not found`
+refusals for the missing ones rather than corrupting anything — the harness bug, not a kernel
+defect). This campaign still drives every identity via direct `VM-EXEC` dispatch, same as every
+prior run — it does not itself exercise Stage 4's new switch-signal participation, which was
+verified separately (see FABRIC-3.md §XXX for the live multiuser-attach + preemption-fleet
+verification that does).