From 1c220ad4b4b12461aa5c5261b09e4637f0eff4de Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Mon, 14 Sep 2026 21:34:58 -0400 Subject: [PATCH] =?UTF-8?q?Close=20=C2=A7XXVIII:=20defer=202=20known=20bug?= =?UTF-8?q?s=20to=20Stage=204=20(FABRIC-3.md=20=C2=A7XXIX)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Bob's call after an honest end-to-end status check: multitasking (fixed Tripod fleet) and multiuser (Zuse/WIREBIND) each work for their own tested paths, but two known bugs remain rather than zero -- the §XIV concurrent WIREBIND attach detection gap, and the never-reconciled MSG-TICK/Stage-3-switch dual-ownership rough edge. Both deliberately deferred to be addressed during or at the close of Stage 4, since both bear directly on WIREBIND VMs joining the switch-signal population. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01BWpNjdwPtFLuVLaAq44L9K --- FABRIC-3.md | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/FABRIC-3.md b/FABRIC-3.md index dfd26e4c..a9e3c5be 100644 --- a/FABRIC-3.md +++ b/FABRIC-3.md @@ -3949,3 +3949,42 @@ three now reach `Startup: Artemis live` -> `[zuse@Hera] ok>` with **no** `VM-EXE at all -- confirming both that the fix is correct and that this was the sole cause of that report (nothing else was masking or contributing to it). +## XXIX. Task closed, 2 known bugs explicitly deferred to Stage 4 (2026-09-14) + +**Bob's call, made after an honest end-to-end status check on both multitasking and multiuser:** +both work, separately, for their own tested paths -- but "no known bugs" overstated it, and +rather than chase either now, both are deliberately deferred, to be addressed as needed during +or at the close of Stage 4 (WIREBIND-scope extension) rather than as a standalone detour first. +Recorded here so Stage 4 opens with both already on its own punch list, not rediscovered. + +**Bug 1 -- §XIV, still open: concurrent WIREBIND attach detection gap.** Attaching several +identity thumbdrives at (or near) the same real-time instant reliably causes the kernel to +detect and birth only some of them; the rest never trigger `WIREBIND: attached` at all. +Confirmed not a QEMU-side issue (every device is genuinely present per host-level `query-block`) +-- the gap is in the guest kernel's own per-tick attach-pending scan only surfacing one (or a +few) of several simultaneously-pending port events. Sequential one-at-a-time attach (wait for +each `WIREBIND: attached` before the next) is the only confirmed-reliable path today. +Directly relevant to Stage 4: extending preemption to WIREBIND VMs presumes those VMs exist and +are attached reliably in the first place, including under the "already plugged in at power-on" +case §XIV's own second reproduction showed failing. + +**Bug 2 -- the MSG-TICK/Stage-3-switch dual-ownership rough edge (§XXVIII's own admission, +never revisited).** Both MSG-TICK's idle-pump dispatch and the Stage 3 timer-driven switcher can +independently move control between the same VMs; not reconciled, not observed to interact badly +so far, but never proven safe under all interleavings either. Directly relevant to Stage 4 for +the same reason as Bug 1: WIREBIND VMs bring a second population of dynamically-birthed contexts +into a switching story that already has one unreconciled ownership question among the fixed +three. + +**Everything else closed out tonight (§XXVIII.2, §XXVIII.3) is verified clean on all 3 +architectures and not part of this deferral** -- the message-arrival eligibility hook, the +trampoline-blind switch-storm fix, and the `SWITCH-MARK-WORK` off-by-one are done, done, done. + +**This closes the active §XXVIII thread in this document.** Preemptive multitasking works +end-to-end for the fixed Tripod fleet (Hera/Hermes/Artemis); identity/multiuser (Zuse/WIREBIND) +works end-to-end for its own tested paths; the two are not yet composed (Stage 4, not attempted); +the two bugs above are the known, accepted, deferred debt against that composition. Bob has +indicated a larger new initiative is coming that will be introduced during Stage 4 work itself +-- not detailed here since it hasn't been scoped yet, flagged only so this closing note doesn't +read as "nothing more is coming." +