admin/LithosAnanake
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

std79 DoE campaign rerun post-Stage-4: 81/81, §XIV caught live by rerun's own harness bug (FABRIC-3.md §XXXI)
Build / build-amd64-iso (push) Canceled after 0s
Details
Build / build-aarch64-iso (push) Canceled after 0s
Details
Build / build-riscv64-img (push) Canceled after 0s
Details

Browse Source 
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
This commit is contained in:
Robert Allan James
2026-09-15 04:56:31 -04:00
co-authored by Claude Sonnet 5
parent 597f5a6cd8
commit 16cc74243c
11 changed files with 73130 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
experiments/std79-doe/README.md
+18
View File
@@ -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).