3 Commits

Include renames

Author	SHA1	Message	Date
Robert Allan JamesandClaude Sonnet 5	0bae928aad	Mint the 8 identity thumbdrives (bob, 00-06) with real MINT data ... zuse-thumb-ident.img was already minted; bob-thumb-ident.img (Captain Bob / rajames / rajames440@gmail.com) and 00-thumb-ident.img through 06-thumb-ident.img (full_name=username=the number, no email/phone) are now real minted identities, not blank images. Done via the actual kernel MINT word at a live console (Zuse authenticated, drives hot-plugged one at a time via the QEMU HMP monitor) -- no Python orchestration, per direct instruction: a small StarForth word, MINT-NUM, wraps MINT for the 7 uniform numeric identities, driven by plain bash + socat against the monitor/serial unix sockets. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018EjXFo7mPXjUMjfJeuUUz4	2026-09-05 22:42:41 -04:00
Robert Allan JamesandClaude Sonnet 5	9e81de3f43	xHCI/BOT driver: genuine multi-device support (FABRIC-3.md §VII) ... Per-slot registry (xhci_msc_slot_t/dev->msc_slots, sized off the controller's own reported max_slots) replaces the single-device scalar fields the driver carried since Milestones 2e-2h. Boot-time port scan no longer stops at the first connected device; a connect/disconnect that arrives while the Command Ring is busy is now queued and drained instead of dropped. blkio_usb.c and repl.c's own single-device state (device descriptor buffers, blkio_dev_t, attach bookkeeping) became per-slot registries the same way. Live multi-device testing (not just compiling) surfaced a second, more severe bug outside the original plan: transfer_purpose and next_action were also single scalars shared across the whole controller. Two devices enumerating concurrently could have one's completion silently overwrite the other's still-outstanding one, permanently stalling it with no error. Fixed by moving both per-slot and, critically, reading the Transfer Event TRB's own real Slot ID field instead of trusting external bookkeeping. Verified live, all three architectures, mandatory clean-qemu acceptance: existing single-device path unchanged, and two devices attached simultaneously (amd64) both progress independently through enumeration without corrupting or stalling each other. Also in this pass (implemented and verified in earlier turns this session, committed together per direct instruction): - Headless-until-login console policy: no prompt/banner until a real identity logs in via an attached thumbdrive (WIREBIND or Zuse, neither special), reusing EMERGENCY_CONSOLE_ENABLED as the debug/recovery escape hatch (now default-off). - KILL/g_repl_active_vm dangling-pointer fix: killing the VM the console is currently USE'd onto now detaches back to Hera first, matching the existing EJECT/UNCLEAN precedent. FABRIC-3.md §VII/§VIII carry full closure notes for all three. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018EjXFo7mPXjUMjfJeuUUz4	2026-09-05 22:14:14 -04:00
Robert Allan JamesandClaude Sonnet 5	c3db963164	FABRIC-3.md §VII: xHCI/BOT single-device architecture — plan only, halted ... Documents the full scope of the driver's single-device-at-a-time state (connect/enumerate, control-transfer, and BOT state machines), the persistent-vs-in-flight distinction that bounds the fix, the concurrency target, and a numbered punch list. No driver code has been touched — implementation is explicitly held pending go-ahead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018EjXFo7mPXjUMjfJeuUUz4	2026-09-05 20:45:20 -04:00