Robert Allan JamesandClaude Sonnet 5
c19ef365fe
Replaces the fixed SK_SWITCH_MAX_SLOTS=16 compile-time array with a boot-time, RAM-derived allocation via a new sk_vm_switch_signal_boot_init(), kmalloc'd to stadium_max_vm_count() entries -- the same pattern session_boot_init() already established for Stadium-derived sizing. Every switch-signal participant is a Stadium VM, so this reuses that bound directly rather than deriving a separate one. Verified live on all three architectures: switch table sized to 50 slots (amd64), 202 slots (aarch64), 50 slots (riscv64) -- all well past the old fixed cap. All three boot to [zuse@Hera] ok> cleanly; dict_hash for Hermes/Hestia identical across architectures, unmoved from pre-task values. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
897 lines
66 KiB
Markdown
897 lines
66 KiB
Markdown
# FABRIC-3.6.md — the Tripod/kernel reshuffle: execution log
|
||
|
||
> ## START HERE — session handoff
|
||
>
|
||
> **If you have just been told "go build it", read this section, then `FABRIC-3.5.md`'s §XLI,
|
||
> then start at task 0.0 below. Do not re-derive the design — it is settled.**
|
||
>
|
||
> **Where the code is.** This repo is **LithosAnanke, on the Gitea instance at
|
||
> `gitea.strshipos.com`, repo `admin/LithosAnanake`** — Captain Bob has the credentials.
|
||
> **Confirm you are in the right repo before anything else.** `git remote -v` must show
|
||
> `gitea.strshipos.com/admin/LithosAnanake`. **Nothing outside Gitea is this project.** (The
|
||
> handoff was authored in a container whose default working directory was a *different*, empty
|
||
> repo on an unrelated remote — if you ever see that, you are in the wrong place.) `master` is
|
||
> the sole production line. Work on branch **`claude/starshipos-tripod-kernel-reshuffle-itbjns`**
|
||
> (a clean fast-forward of `master` at `e56974e`; **documentation only — no reshuffle code has
|
||
> been written**. The branch head is the source of truth; do not trust a commit id quoted here).
|
||
>
|
||
> **The two documents.** `FABRIC-3.5.md` is the **design record and is authoritative** — every
|
||
> ruling, with its reasoning and evidence, §I–§XLIII. **This** document is the execution log.
|
||
> Rulings are cited here, never restated. **If a task proves a ruling wrong, record the finding
|
||
> here and amend `FABRIC-3.5.md` — never silently diverge.**
|
||
>
|
||
> **First action: task 0.0**, the three-ISA baseline. It is a gate, not a formality — see its
|
||
> own rationale below. **Nothing else starts until it is recorded.**
|
||
>
|
||
> **Five traps this project's own history proves are real. A fresh session will walk into these:**
|
||
>
|
||
> 1. **Silent failure is the dominant mode here.** `FABRIC-3.5.md` §XXXV.0 lists four
|
||
> independent instances. Most relevantly: *"a switch storm and a healthy idle REPL produce an
|
||
> identical serial log."* **A green boot is weak evidence.** Name the specific observation
|
||
> that proves a task worked, before running it.
|
||
> 2. **`grep` cannot establish capsule reachability.** Capsules are birthed by name from runtime
|
||
> strings. A reference count over `capsules/` and `src/` put the six live `init-l8-*`
|
||
> capsules at **zero references**; including `experiments/` found 18–19 each. §XXII.2. **Use
|
||
> the three routes, never grep alone.**
|
||
> 3. **`fleet_conserved` cannot see Stadium heat.** The two heat accountings are entirely
|
||
> decoupled (§XXXIX). A leaking message allocator leaves `fleet_conserved` reporting a serene
|
||
> `1`. **Stage B's evidence is the ledger plus `stadium_conserved()`, never `fleet_conserved`.**
|
||
> 4. **`dict_hash` *changing* is expected; `dict_hash` *diverging* across architectures is the
|
||
> stop condition.** §XXXIV.6. Do not "fix" a changed hash.
|
||
> 5. **Documentation in this repo drifts from the code — trust the code.** `.claude/CLAUDE.md`
|
||
> carried four stale claims; **all four were corrected 2026-09-19 (§XLIV) and it is now
|
||
> reliable.** Others are not: `capsules/MANIFEST.md` still describes block 4055 as a live
|
||
> "immutable ABI" that `FABRIC-2.md:2773` declared stale, and still misdescribes block 2049.
|
||
> `FABRIC-0.md` §25.7 lists resolved defects as open. **Where a document and the code
|
||
> disagree, the code wins — and record the drift rather than working around it.**
|
||
>
|
||
> **Blocked, and not to be worked around:** Phase 3 needs three decisions from Captain Bob —
|
||
> **B1** channels (one membership or negotiation), **B2** the `SK_SWITCH_MAX_SLOTS` ceiling of
|
||
> 16, **B4** the payload bound against `INPUT_BUFFER_SIZE` 1025. **All design is complete; these
|
||
> are rulings, not investigations.**
|
||
>
|
||
> **Do not:** create branches, stash, fix defects found in passing, bundle tasks into one
|
||
> commit, or start any task without explicit authorization. Captain Bob's Law,
|
||
> `.claude/CLAUDE.md`.
|
||
|
||
**Status: LIVING WORKING DOCUMENT, opened 2026-09-19.** This is the **execution** record for
|
||
the reshuffle designed in `FABRIC-3.5.md`. Work is tracked, annotated and closed here.
|
||
|
||
**Why this is a separate document, per the series' own rule.** `FABRIC-1.md` closed at **4,420
|
||
lines** for a stated reason: *"continuing to append here made the still-open work hard to find."*
|
||
`FABRIC-3.5.md` stands at **4,452 lines** with 40+ open punch items scattered among hundreds of
|
||
settled rulings — **it has crossed the same threshold, for the same reason.** Annotating a task
|
||
list inside it, commit by commit, would bury the design record it exists to be.
|
||
|
||
**The split of responsibility is strict, and stated because `FABRIC-3.5.md` §XXXI found that
|
||
documents in this series lose track of each other:**
|
||
|
||
| | `FABRIC-3.5.md` | `FABRIC-3.6.md` (this) |
|
||
|---|---|---|
|
||
| **Holds** | The design record — every ruling, its reasoning, its evidence | The work — tasks, results, dates, commits |
|
||
| **State** | Design phase closed; archival close at `v2.1.0` (§XXVI.5) | Living until the work is done |
|
||
| **On a conflict** | **Authoritative** | Defers, and records the discrepancy |
|
||
|
||
**Design rulings are never restated here, only cited** (`§XXXIV.2`, `§XL.4`, …). If a task needs
|
||
a rule explained, read `FABRIC-3.5.md`. **If executing a task proves a ruling wrong, that is a
|
||
finding: record it here and amend `FABRIC-3.5.md` there** — never silently diverge.
|
||
|
||
**The checkbox convention is deliberate.** `FABRIC-3.5.md` §XXXI.2 found the series'
|
||
carry-forward discipline was mechanically auditable (`grep -c '\- \[ \]'`) up to `FABRIC-2.md`,
|
||
and **broke at `FABRIC-3.md`, which uses no checkboxes at all** — after which "is anything still
|
||
open?" stopped being a `grep` and became a reading exercise. **This document restores the
|
||
convention**, so that question stays answerable by machine.
|
||
|
||
---
|
||
|
||
## Standing rules
|
||
|
||
Apply to **every** task, from `.claude/CLAUDE.md` and `FABRIC-3.5.md` §XXXIV:
|
||
|
||
- **One task, one commit.** No bundling.
|
||
- **Acceptance is the three-architecture QEMU boot** — `clean qemu`, amd64/aarch64/riscv64, one
|
||
at a time, in the foreground. Logs committed. There is no other acceptance test.
|
||
- **`dict_hash` changing is expected. `dict_hash` *diverging* between architectures is a stop
|
||
condition** (§XXXIV.6).
|
||
- **`mkcapsule --lint capsules/` clean** after any capsule change.
|
||
- **No task starts without explicit authorization.** Captain Bob's Law.
|
||
- **Report, don't fix.** A defect found while doing a task is recorded here, not repaired in
|
||
passing.
|
||
|
||
## Annotation convention
|
||
|
||
```
|
||
- [x] 0.2 — Strip common/msg.4th
|
||
2026-09-DD · commit abc1234 · 3-arch boot clean, lint 0 violations
|
||
note: <anything surprising; a finding gets its own entry below>
|
||
```
|
||
|
||
Mark `[~]` for started-not-finished, with what is outstanding. **Never mark `[x]` on a task
|
||
whose check did not actually run** — `FABRIC-3.5.md` §XXXV.6 records that declaring done too
|
||
early is this project's most repeated failure.
|
||
|
||
---
|
||
|
||
## Pre-flight — establish the baseline before anything changes
|
||
|
||
**Branch state at open (2026-09-19):** `claude/starshipos-tripod-kernel-reshuffle-itbjns`, head
|
||
`3a4e5cf`, **working tree clean, pushed, 33 commits ahead of `master`** — all documentation, no
|
||
code. `master` is unmoved at `e56974e`, so the branch remains a clean fast-forward. **Execution
|
||
starts from this commit.**
|
||
|
||
- [x] **0.0** — **Three-ISA baseline smoke test on the unmodified branch.**
|
||
`make -f Makefile.starkernel ARCH=<arch> clean qemu` for amd64, aarch64, riscv64 — one at
|
||
a time, in the foreground, per `.claude/CLAUDE.md`.
|
||
*Check:* all three reach `zuse)ok>`; zero `UNKNOWN WORD`; logs committed under
|
||
`logs/<timestamp>/<arch>/`; **record each `dict_hash` and confirm the three are
|
||
identical.**
|
||
2026-09-19 · `logs/20260919-130023/amd64/`, `logs/20260919-130137/aarch64/`,
|
||
`logs/20260919-130319/riscv64/` — all three reach `[zuse@Hera] ok>`, zero `UNKNOWN WORD`.
|
||
`dict_hash` identical across all three: Hera (`PARITY:M7.1a`) `0x6824fe5993239838`,
|
||
Hermes `0x062252c4da6858da`, Artemis `0xed80117724c26f36`.
|
||
note: **first attempt confounded, see findings log** — `logs/20260919-124835/amd64/` and
|
||
`logs/20260919-124952/aarch64/` (kept, not deleted) show Artemis's `dict_hash` diverging
|
||
(`0xed80117724c26f36` vs `0x93d6e815354b61c0`) purely because `disk/artemis.img` is shared
|
||
across all three ISAs' `qemu` targets (`FABRIC-3.md` §XXXV.2) and the second run resumed
|
||
the first run's already-formatted disk instead of formatting its own. Restored
|
||
`disk/artemis.img` and `disk/thumbdrives/zuse-thumb-ident.img` to their committed blank
|
||
state (`git checkout --`) before each of the three reruns above to remove the confound.
|
||
|
||
**Why this is a gate and not a formality.** Every task in this document takes the
|
||
three-architecture boot as its acceptance (§XXXIV). **Without a known-good baseline captured
|
||
first, the first red boot is ambiguous** — pre-existing fault or something task 0.2 just did?
|
||
This project has been bitten by exactly that ambiguity before (`FABRIC-3.md` §XXVI: "the
|
||
lockdown was never broken — wrong VM tested"). The baseline is what makes every later
|
||
acceptance run interpretable, and the recorded `dict_hash` triple is the reference every
|
||
subsequent §XXXIV.6 divergence check compares against.
|
||
|
||
**Run it yourself — you are expected to.** Captain Bob confirmed (2026-09-19) that execution
|
||
happens on his PC with the full toolchain installed, so **the session reading this can and
|
||
should run task 0.0 directly**, once authorized. Verify first that `qemu-system-x86_64`,
|
||
`qemu-system-aarch64`, `qemu-system-riscv64`, the aarch64/riscv64 cross-compilers and
|
||
OVMF/AAVMF are all present; **if any are missing you are not on the intended machine — stop and
|
||
say so rather than improvising a partial test.**
|
||
|
||
*(Historical note: this document was authored in a container with none of that toolchain, which
|
||
is why task 0.0 was written but never run. Do not take its unchecked state as a prior failure —
|
||
it has simply not been attempted.)*
|
||
|
||
---
|
||
|
||
## Phase 0 — Preparation (no behaviour change)
|
||
|
||
**Gate:** all three architectures boot to `zuse)ok>`, `stadium_conserved()` true, no
|
||
`UNKNOWN WORD`.
|
||
|
||
- [x] **0.1** — Establish Category A reachability by §XXII.2's three routes (boot path, tooling,
|
||
baked capsule directory). **Never by grep alone.**
|
||
*Check:* a written list naming the route that proves each entry dead.
|
||
2026-09-19 · investigation only, no code changed. Checked by all three routes — a boot-path
|
||
trace of `init.4th`/`hera`/`hermes/init.4th`/`artemis/init.4th` for any `EXEC`/`S" name"`
|
||
load, an experiments/tools/docs invocation search, and confirming presence in the baked
|
||
capsule directory doesn't by itself make a name reachable if nothing constructs it at
|
||
runtime:
|
||
|
||
| Candidate | Boot path | Tooling/experiments/docs | Verdict |
|
||
|---|---|---|---|
|
||
| `capsules/common/msg.4th` | zero `EXEC`/load sites in any boot-loaded capsule | zero invocations; its only two words `HERMES-ACK`/`HERMES-NACK` have zero callers anywhere; `messaging.4th` block 5033's own comment: "common:msg.4th's HERMES-ACK/NACK indirection is retired" | **DEAD** |
|
||
| `capsules/process.4th` | zero `EXEC` sites anywhere | zero invocations; its four words `SPAWN`/`PAUSE`/`RESUME`/`KILL-VM` have zero callers outside the file itself | **DEAD** |
|
||
| `SPAWN-EVENT` (constant, `messaging.4th`) | N/A — a constant, only ever defined, never read by name | zero invocations by name anywhere | **DEAD** |
|
||
|
||
Both files are present in the baked capsule directory (`mkcapsule` build log: `[p]
|
||
common:msg.4th`, `[p] process.4th`) — noted per §XXII.2 that presence alone proves
|
||
nothing; it only means nothing constructs either name at runtime to reach them, which the
|
||
other two routes confirm.
|
||
|
||
finding: `EVENT-EMIT`/`EVENT-WAIT`/`EVENT-DRAIN` (`messaging.4th`, Category B, staying)
|
||
have one caller beyond `process.4th` that §XXXIII.3 missed — `tools/hermes_smoke.sh` calls
|
||
all three directly. This does not make them live: the script is already broken on its own
|
||
terms, referencing `capsules/core/init.4th` and `build/amd64/standard/starforth`, neither
|
||
of which exists in this repo, and calling the pre-rename `CD-INIT` word (`messaging.4th`
|
||
block 5033 renamed it to `MSG-CD-INIT`) — it cannot currently execute. Task 0.3's plan
|
||
stands unchanged; recorded because §XXXIII.3's "only other reference is `MANIFEST.md`"
|
||
was itself an undercount of exactly the kind §XXII.2 warns about, even though the
|
||
conclusion survives.
|
||
|
||
finding: `PAUSE-EVENT`/`RESUME-EVENT`/`KILL-EVENT` (`messaging.4th`) are exactly as
|
||
dead-by-name as `SPAWN-EVENT` — zero references anywhere outside their own definition;
|
||
`process.4th`'s calls pass bare numeric literals (`1`/`2`/`3`/`4`), never the constant
|
||
names. Task 0.4 only names `SPAWN-EVENT`; not expanding its scope here, but flagging that
|
||
the other three meet the identical bar for whoever picks up Category A stripping next.
|
||
- [x] **0.2** — Strip `capsules/common/msg.4th`. *Check:* 3-arch boot; lint clean.
|
||
2026-09-19 · `logs/20260919-131945/amd64/`, `logs/20260919-132054/aarch64/`,
|
||
`logs/20260919-132226/riscv64/` — all three reach `[zuse@Hera] ok>`, zero `UNKNOWN WORD`.
|
||
`mkcapsule --lint capsules/` clean, 38 files, 0 violations (was 39 before the strip).
|
||
`dict_hash` **unchanged** from the task 0.0 baseline on all three (Hera
|
||
`0x6824fe5993239838`, Hermes `0x062252c4da6858da`, Artemis `0xed80117724c26f36`) — expected,
|
||
not a defect: task 0.1 confirmed `msg.4th` was never `EXEC`'d into any VM's dictionary, so
|
||
removing the dead file from the baked capsule directory doesn't move anything actually
|
||
loaded. `capsule-reserved.txt` not yet touched — block 4055's range is returned in task 0.6
|
||
per the punchlist's own ordering. `MANIFEST.md`'s stale block-4055 entry not yet corrected
|
||
— bundled into task 0.5 alongside block 2049's correction, per the punchlist.
|
||
- [x] **0.3** — Strip `capsules/process.4th` (takes `EVENT-EMIT`/`-WAIT`/`-DRAIN` with it,
|
||
§XXXIII.3). *Check:* 3-arch boot; lint clean.
|
||
2026-09-19 · `logs/20260919-132914/amd64/`, `logs/20260919-133024/aarch64/`,
|
||
`logs/20260919-133156/riscv64/` — all three reach `[zuse@Hera] ok>`, zero `UNKNOWN WORD`.
|
||
`mkcapsule --lint capsules/` clean, 37 files, 0 violations (was 38). Deleted
|
||
`capsules/process.4th` outright and `messaging.4th`'s Block 5030 in full
|
||
(`EVENT-EMIT`/`EVENT-WAIT`/`EVENT-DRAIN` — a self-contained block, nothing else in it).
|
||
`dict_hash`: Hera's `PARITY:M7.1a` snapshot unchanged (`0x6824fe5993239838` — it fires
|
||
before any capsule loads, so capsule edits never move it); Hermes and Artemis both moved
|
||
(`0xa0f5c639a1228596`, `0x1650cb7153056160`) since both load `messaging.4th` — **identical
|
||
across all three architectures**, which is the actual property that matters (§XXII.4: every
|
||
strip changes `dict_hash`, cross-arch identity is the invariant). `capsule-reserved.txt`
|
||
still untouched (task 0.6); `MANIFEST.md`'s stale block-4055/2049 entries still untouched
|
||
(task 0.5, now unblocked since both 0.2 and 0.3 are done).
|
||
- [x] **0.4** — Strip `SPAWN-EVENT`. *Check:* 3-arch boot; lint clean.
|
||
2026-09-19 · `logs/20260919-133452/amd64/`, `logs/20260919-133559/aarch64/`,
|
||
`logs/20260919-133731/riscv64/` — all three reach `[zuse@Hera] ok>`, zero `UNKNOWN WORD`.
|
||
`mkcapsule --lint capsules/` clean, 37 files, 0 violations (unchanged — a one-line edit
|
||
within `messaging.4th`, no file added or removed). Removed the single `1 CONSTANT
|
||
SPAWN-EVENT` line only, per task 0.1's finding — `PAUSE-EVENT`/`RESUME-EVENT`/`KILL-EVENT`
|
||
left in place, matching the punchlist's stated scope. `dict_hash` moved for Hermes/Artemis
|
||
(`0x52801b746e063ae9`, `0x6ad92fa3935918d4`), identical across all three architectures;
|
||
Hera's `PARITY:M7.1a` snapshot unchanged as before. `capsule-reserved.txt` and
|
||
`MANIFEST.md`'s stale entries still untouched — Phase 0's strips (0.2–0.4) are now all
|
||
done; 0.5 and 0.6 are next.
|
||
- [x] **0.5** — Correct `capsules/MANIFEST.md` blocks 4055 and 2049 **as their files are
|
||
stripped** (§XXII.5). *Check:* manifest describes no file that no longer exists.
|
||
2026-09-19 · documentation only, no capsule content touched, `mkcapsule --lint capsules/`
|
||
still clean (37 files, 0 violations). Block 2049's justification rewrote its claimed
|
||
`init.4th` load list (`compudynamics`, `common:msg`, `fleet-k`, `process`) against the
|
||
file's actual current content — none of those four are loaded there; two were already
|
||
deleted (`compudynamics.4th`/`fleet-k.4th`, `9323f776`), two are this pass's own strips.
|
||
The standalone `common/msg.4th` and `process.4th` sections (former blocks 4055 and
|
||
4300–4301) were removed and folded into "Deleted capsules (historical)" alongside the
|
||
existing `compudynamics.4th`/`fleet-k.4th` entry, same convention. Unassigned Ranges table
|
||
updated: 4055–4059 and 4300–4399 now read as former-file ranges rather than "extension
|
||
space" for files that no longer exist. Verified every remaining `### \`*.4th\`` section in
|
||
the manifest names a file actually present on disk — zero stale entries left.
|
||
- [x] **0.6** — Return freed block ranges to `capsule-reserved.txt`. *Check:* lint clean.
|
||
2026-09-19 · added `4055-4059` (former `common/msg.4th`) and `4300-4399` (former
|
||
`process.4th`) to `tools/capsule-reserved.txt`, each noted as freed by this reshuffle's
|
||
strip rather than owned by non-capsule infrastructure (the file's usual purpose) —
|
||
documented as lifted, not permanent, once someone deliberately wants a range back.
|
||
`mkcapsule --lint capsules/` clean, 37 files, 0 violations, and `check_reserved_conflicts()`
|
||
(the hard build-gate that actually reads this file, `tools/mkcapsule.c:974`) passes clean
|
||
on a real `make -f Makefile.starkernel ARCH=amd64 all` — confirms the new entries don't
|
||
collide with anything currently baked. Documentation/registry only, no capsule content
|
||
touched, so no 3-arch boot run for this task. All of Phase 0's strips and documentation
|
||
corrections (0.1–0.6) are now done; `stadium_conserved()` (0.7) and the `PLOT`/`FB-WIDTH`/
|
||
`FB-HEIGHT` registration audit (0.8) remain before Phase 0's gate is fully met.
|
||
- [x] **0.7** — Add `stadium_conserved()`: `Σ patron + reservoir + consumed == Q48_ONE`,
|
||
**epsilon zero** (§XL.4, item 41). *Check:* true on a clean boot, all three arches.
|
||
2026-09-19 · `logs/20260919-135137/amd64/`, `logs/20260919-135240/aarch64/`,
|
||
`logs/20260919-135417/riscv64/` — all three reach `[zuse@Hera] ok>`, zero `UNKNOWN WORD`,
|
||
and print `Stadium conservation: CONSERVED` (all identical: resident_sum=47641
|
||
reservoir=17895 sum=65536=`Q48_ONE`). Implemented `int stadium_conserved(VMUuid vm_id)` in
|
||
`src/starkernel/vm/stadium.c` (declared `include/starkernel/vm/stadium.h`) as
|
||
`stadium_resident_sum(vm_id) + stadium_reservoir_peek(vm_id) == Q48_ONE` — the **two-term**
|
||
form, not three. §XL.4's `consumed` term is a Phase 2 kernel-Hermes ledger deliverable that
|
||
doesn't exist yet; nothing draws on any VM's Stadium quota today (Phase 2 task 2.2 is
|
||
literally where that wiring gets built), so `consumed` is honestly zero right now and
|
||
folding it in would be inventing Phase 2 state ahead of it existing. Doc comment on the
|
||
function says exactly this, so whoever builds Phase 2's ledger extends this function rather
|
||
than working around it. Wired into the existing per-VM boot diagnostic
|
||
(`stadium_words_print_boot_diagnostics()`, `kernel_main.c:810`, Hera only — the sole
|
||
existing call site) rather than adding a new one. No compiler warnings on either edited
|
||
file (checked with a forced recompile).
|
||
- [x] **0.8** — Audit that `PLOT`/`FB-WIDTH`/`FB-HEIGHT` are registered **nowhere** but the
|
||
table Hestia will own (item 33). *Check:* read-only; a second site is a defect to report.
|
||
2026-09-19 · read-only audit, no code changed. **Finding: they are reachable from every
|
||
VM today, not confined to one table.** Traced the two layers separately:
|
||
- **FORTH level** (the drawing vocabulary): `capsules/fabric.4th`/`font.4th` (which build
|
||
`CART-PLOT` etc. on top of raw `PLOT`) are `EXEC`'d only from `capsules/init.4th` — Hera
|
||
only. Neither `hermes/init.4th` nor `artemis/init.4th` load them. This layer matches
|
||
item 33's expectation and is exactly what tasks 1.6/1.7 move to `hestia/init.4th`.
|
||
- **C level** (the raw primitives themselves): `register_framebuffer_words()`
|
||
(`src/word_source/framebuffer_words.c:60-65`, registering `PLOT`/`FB-WIDTH`/
|
||
`FB-HEIGHT`) is called unconditionally from `register_forth79_words()`
|
||
(`src/word_registry.c:139`), which is itself called unconditionally from `vm_init()`
|
||
(`src/starkernel/vm/vm_bootstrap.c:263`) — **the generic per-VM bootstrap every VM goes
|
||
through, no identity check, no `#ifdef`.** So the raw primitives are already in every
|
||
VM's C-level dictionary at birth, Hestia or not.
|
||
- **Verified live, not just from source**: booted amd64 (`logs/20260919-140231/amd64/`)
|
||
and ran `S" FB-WIDTH ." S" Hermes" VM-EXEC` and the same against `Artemis` — **both
|
||
returned `1280`, not `UNKNOWN WORD`.** Neither loads `fabric.4th`, so this is the raw
|
||
C primitive itself answering, confirmed reachable from VMs that were never meant to
|
||
draw.
|
||
**Not fixed here** — read-only per the task, and this is exactly task 1.8's own stated
|
||
check ("a non-Hestia VM calling `PLOT` gets `UNKNOWN WORD` — verify positively"), which
|
||
this finding confirms currently **fails** and gives 1.8 a concrete starting state:
|
||
`register_framebuffer_words()`'s call site in `register_forth79_words()` will need to
|
||
become conditional on VM identity (or moved out of the universal bootstrap entirely),
|
||
not just the FORTH-level `fabric.4th` relocation tasks 1.6/1.7 already plan for.
|
||
|
||
**Phase 0 gate met**: all three architectures have repeatedly booted to `[zuse@Hera] ok>`
|
||
with `stadium_conserved()` true and zero `UNKNOWN WORD` across tasks 0.2–0.7. Phase 0 is
|
||
closed; Phase 1 (Hestia, messaging untouched) is next.
|
||
|
||
## Phase 1 — Hestia (messaging untouched)
|
||
|
||
**Gate:** Tripod is Hera/Artemis/Hestia **plus** Hermes; drawing works from Hestia and only
|
||
Hestia; headless policy intact.
|
||
|
||
- [x] **1.1** — Allocate Hestia's block range vs. `capsule-reserved.txt`, **avoiding 4997**.
|
||
*Check:* lint clean.
|
||
2026-09-19 · allocated **`4986–4996`** (11 blocks) for `hestia/init.4th`, documented in
|
||
`capsules/MANIFEST.md`'s Unassigned Ranges table (not `capsule-reserved.txt` — that file is
|
||
for blocks owned by non-capsule infrastructure, per its own header comment; a real capsule
|
||
allocation belongs in `MANIFEST.md`, same as every other infrastructure capsule). Checked
|
||
against the actual current occupancy, not the table's own stale blanket "4853+ OPEN" line:
|
||
`fabric.4th` occupies 4900–4924 and `font.4th` 4925–4985 already (both are their own
|
||
standalone capsule files, `EXEC`'d by `init.4th` but block-numbered independently of it —
|
||
task 1.6/1.7 relocate *which capsule EXECs them*, not their own block ranges), and 4997 is
|
||
the console proxy's hardcoded `Block 4997` string literal (`capsule_console.c:27-29`).
|
||
4986–4996 sits in the gap between the two, avoiding 4997 as required, with room for
|
||
Hestia's initial messaging-load/banner shape (task 1.2) plus moderate growth (bind
|
||
vocabulary, per §XVIII.5) without colliding with anything. No `.4th` file created yet.
|
||
`mkcapsule --lint capsules/` still clean, 37 files, 0 violations (documentation-only, no
|
||
capsule content changed).
|
||
- [ ] **1.2** — Create `capsules/hestia/init.4th`: messaging load, `MSG-CD-INIT`, banner. **No
|
||
fabric yet.** *Check:* boots; Hestia not yet birthed.
|
||
- [x] **1.3** — Add Hestia to `is_fleet_foundation` (`capsule_birth.c:793-796`) — **four names,
|
||
Hermes retained** (§XXXIV.4). *Check:* 3-arch boot; Hermes still live.
|
||
2026-09-19 · `logs/20260919-163734/amd64/`, `logs/20260919-163837/aarch64/`,
|
||
`logs/20260919-164005/riscv64/` — all three reach `[zuse@Hera] ok>`, zero `UNKNOWN WORD`,
|
||
**byte-identical to the pre-change baseline** (same `dict_hash` triple) — expected, since
|
||
nothing births anything named "Hestia" yet (that's task 1.4), so the added name in the
|
||
`is_fleet_foundation` check never matches. Added a fourth
|
||
`vm_name_prefix_eq_nocase(capsule_name, "Hestia")` alongside Hera/Hermes/Artemis in
|
||
`src/starkernel/capsule/capsule_birth.c`'s `is_fleet_foundation` local (the only
|
||
consequence of this flag: `session_set_pinned(vm_id, 1)` for whichever VM name matches).
|
||
Hermes confirmed still present in the check and still born normally (`BIRTH: Hermes live`
|
||
in all three logs).
|
||
- [x] **1.4** — Birth Hestia in `kernel_main.c`, **alongside** Hermes's existing birth.
|
||
*Check:* registry shows both; `dict_hash` identical across arches. *Change graphics metekey.
|
||
2026-09-19 · `logs/20260919-165646/amd64/`, `logs/20260919-165802/aarch64/`,
|
||
`logs/20260919-165931/riscv64/` — all three reach `[zuse@Hera] ok>`, zero `UNKNOWN WORD`.
|
||
**Registry shows all four**: `BIRTH: Hermes live`, `BIRTH: Hestia live`,
|
||
`PARITY:BIRTH` lines for Hermes/Hestia/Artemis all present in every log. **Hestia's
|
||
`dict_hash` identical across all three architectures**: `0x31cab513929eea89`
|
||
(capsule_hash `0x3d3a87c3509ab7f3`, matching `hestia:init.4th`'s own hash). Hera/Hermes
|
||
hashes unchanged from task 1.3's baseline; Artemis's `vm_id` shifted (now the 4th birth
|
||
instead of the 3rd — `vm_id` is derived from birth-sequence position, not identity, so
|
||
this is expected, not a divergence) but its `dict_hash` is unchanged and still identical
|
||
across arches. Added a birth block in `src/starkernel/kernel_main.c` immediately after
|
||
Hermes's own (`S" Hestia" BIRTH` + registry-lookup confirmation), same shape as the
|
||
existing Hermes/Artemis blocks. No compiler warnings (forced recompile checked). Noted in
|
||
passing, not a regression: Hestia's birth log shows the same `( Unterminated comment`
|
||
HADES warning Artemis's own birth has shown since task 0.0's very first baseline — a
|
||
pre-existing quirk, not something this task introduced.
|
||
- [x] **1.5** — Register Hestia for switch signals (the `:1007` pattern). *Check:* boot clean;
|
||
**no switch storm** (§XXVIII.2's shape — and note it is invisible by default, §XXXV.0).
|
||
2026-09-19 · `logs/20260919-170232/amd64/`, `logs/20260919-170403/aarch64/`,
|
||
`logs/20260919-170537/riscv64/` — all three reach `[zuse@Hera] ok>`, zero `UNKNOWN WORD`,
|
||
hashes identical to task 1.4's baseline (switch-signal registration is pure C runtime
|
||
state, doesn't touch any FORTH dictionary). Added a fourth
|
||
`capsule_vm_find_by_name_nocase("Hestia", ...)` + `sk_vm_switch_signal_register(...)` block
|
||
in `src/starkernel/kernel_main.c`, same shape as the existing Hermes/Artemis blocks,
|
||
**after** all four fleet members are confirmed born (same "never register before birth is
|
||
confirmed" discipline the existing comment on this block already states).
|
||
**Took §XXXV.0's "invisible by default" warning literally rather than trusting a clean
|
||
boot log alone:** §XXVIII.2's own recorded storm signature is "QEMU pinned near 100% CPU,
|
||
serial log frozen solid" — not an error message, not `UNKNOWN WORD`. Named that signature
|
||
before running, then checked for it directly rather than just reading `ok>` and moving on:
|
||
confirmed each boot reached the prompt in normal wall-clock time (~30s, matching every
|
||
prior run in this document), and — since TCG itself always shows ~100% CPU regardless of
|
||
guest workload, so CPU alone proves nothing — watched the serial log's own line count at
|
||
the idle prompt for 5–10s on all three architectures and confirmed it **stopped growing**
|
||
(last real output, `StarForth CLI`/`ok>`, with nothing appended after) rather than flooding
|
||
or silently stalling mid-boot. No compiler warnings.
|
||
- [x] **1.6** — Move `fabric.4th` from `init.4th` to `hestia/init.4th`. *Check:* Hera's dict
|
||
shrinks, Hestia's grows; cross-arch identity holds.
|
||
**Merged with task 1.7 into one commit — see that entry.** Real dependency discovered
|
||
while attempting 1.6 alone, not a convenience bundling: recorded here and there.
|
||
- [x] **1.7** — Move `font.4th` likewise. *Check:* same.
|
||
2026-09-19 · **finding, not a defect: 1.6 and 1.7 are not independent, and doing 1.6 alone
|
||
breaks Hera's boot.** `font.4th` calls `G-LINE`/`G-ELLIPSE`, which are `fabric.4th`'s own
|
||
words (`fabric.4th` blocks 5000–5002 per `font.4th`'s own comment). Confirmed live before
|
||
committing to either approach: removed only `fabric.4th`'s `EXEC` from `init.4th`, left
|
||
`font.4th`'s in place, booted amd64 — Hera's boot floods with `UNKNOWN WORD: 'G-LINE'`/
|
||
`'G-ELLIPSE'` the moment `font.4th` loads (`logs/20260919-171047/amd64/`, kept as evidence,
|
||
not deleted). Reverted that partial state immediately (`git checkout --
|
||
capsules/init.4th`), asked Captain Bob how to proceed given the two tasks as separately
|
||
scoped can't each independently pass their own three-arch-boot check, and was told to use
|
||
best practices. **Merged both into this one commit**, moving `fabric.4th` and `font.4th`
|
||
together, in their original relative order, into a new `capsules/hestia/init.4th` block
|
||
4988 — a deliberate, documented deviation from "one task, one commit," not a bundling of
|
||
convenience.
|
||
|
||
`logs/20260919-171942/amd64/`, `logs/20260919-172123/aarch64/`,
|
||
`logs/20260919-172253/riscv64/` — all three reach `[zuse@Hera] ok>`, zero `UNKNOWN WORD`.
|
||
Hestia's `dict_hash` (`0xe4e6b1916827e320`, capsule_hash `0x6aa0a1b5daf9d2ec`) identical
|
||
across all three architectures. **Verified the shrink/grow live, not just inferred from
|
||
hash movement**: `HERE .` reads `20008` in Hera, `63040` in Hestia (post-move) — a huge gap
|
||
confirming Hestia's dictionary now genuinely holds the drawing vocabulary. `CART-PLOT` in
|
||
Hera returns `UNKNOWN WORD: 'CART-PLOT'`; the identical call routed into Hestia via
|
||
`VM-EXEC` reaches the word and fails on a stack underflow instead (`>R: DSP underflow`) —
|
||
proof the word exists there, since an unknown word can't underflow. `mkcapsule --lint
|
||
capsules/` clean, 38 files, 0 violations. `MANIFEST.md` updated: `init.4th`'s block 2049
|
||
entry no longer lists `fabric.4th`/`font.4th`; `hestia/init.4th`'s entry gains block 4988.
|
||
- [x] **1.8** — Move `PLOT`/`FB-WIDTH`/`FB-HEIGHT` registration to Hestia's table **only**.
|
||
*Check:* **positively verify** a non-Hestia VM calling `PLOT` gets `UNKNOWN WORD`.
|
||
2026-09-19 · `logs/20260919-173129/amd64/`, `logs/20260919-173251/aarch64/`,
|
||
`logs/20260919-173420/riscv64/` — all three reach `[zuse@Hera] ok>`, zero `UNKNOWN WORD`
|
||
during boot. This is the real fix for task 0.8's finding: `register_framebuffer_words()`
|
||
(`src/word_source/framebuffer_words.c`) was called unconditionally from
|
||
`register_forth79_words()` (`src/word_registry.c:139`), itself called unconditionally from
|
||
`vm_init_with_host()` — the generic per-VM bootstrap every VM goes through, with no way to
|
||
know a VM's name at that point. **Removed the unconditional call**; added a name-gated
|
||
call instead in `capsule_birth_baby()` (`src/starkernel/capsule/capsule_birth.c`), right
|
||
beside the existing `is_fleet_foundation` check — the one place in the whole birth path
|
||
where `capsule_name` and the newly-allocated `VM*` are both in scope together:
|
||
`if (vm_name_prefix_eq_nocase(capsule_name, "Hestia")) register_framebuffer_words((VM*)new_vm);`
|
||
|
||
**Positively verified, exactly as the check demands, not just inferred**: at the live
|
||
prompt, `S" FB-WIDTH ." S" Hermes"/"Artemis" VM-EXEC` both return `UNKNOWN WORD:
|
||
'FB-WIDTH'`; the identical call against `"Hestia"` returns `1280`. Confirmed at the
|
||
fundamental level too: Hera's own base `PARITY:M7.1a` word count **dropped from 531 to
|
||
528** — exactly the three words removed — identical across all three architectures
|
||
(`hash=0xb3b23dc361371c97`, `latest_id=697`). Hermes/Artemis/Hestia `dict_hash` all moved
|
||
accordingly and are identical cross-arch.
|
||
|
||
**Side effect on the vendored hosted build, expected and not a regression**: `capsule_birth.c`
|
||
is kernel-only (`src/starkernel/`), so the plain hosted `starforth` binary has no Hestia
|
||
concept and now never registers these words at all — confirmed live (`echo "FB-WIDTH ."
|
||
| ./build/amd64/standard/starforth` → `UNKNOWN WORD: 'FB-WIDTH'`). `framebuffer_words.c`'s
|
||
own top comment already calls this surface "Kernel-only; no-op on hosted builds," so the
|
||
prior stub registration there was already vestigial — this tightens it to match its own
|
||
documented intent rather than breaking anything real. Ran a plain `make` sanity build to
|
||
confirm the vendored hosted target still compiles and links clean (CLAUDE.md's own stated
|
||
purpose for that target); `lfs/amd64/starforth` regenerated as a result and included in
|
||
this commit since it would otherwise sit stale against the source that produced it.
|
||
`mkcapsule --lint capsules/` clean, 38 files, 0 violations (no capsule content changed —
|
||
this task is pure C). No compiler warnings on either edited file.
|
||
- [x] **1.9** — Assert §XVIII.6's headless invariant: Hestia's birth sets no
|
||
`g_wirebind_attached_username` and mints no proxy. *Check:* boot headless, no thumbdrive,
|
||
**no prompt appears**.
|
||
2026-09-19 · Audited first: neither `capsules/hestia/init.4th` nor her birth block in
|
||
`kernel_main.c` references `g_wirebind_attached_username`, `CONSOLE-ATTACH`, `MINT`, or any
|
||
proxy-minting mechanism — the invariant already held structurally, by absence, before any
|
||
code change here. Stated it explicitly anyway, as the task asks: added a comment at
|
||
Hestia's birth site in `kernel_main.c` quoting §XVIII.6's invariant verbatim and warning
|
||
future edits not to add console/wirebind/proxy code there without re-reading it first.
|
||
|
||
**Verified live with `make -f Makefile.starkernel ARCH=<arch> qemu ZUSEDISK=`** — the
|
||
actual no-thumbdrive boot, not the default (which always attaches
|
||
`disk/thumbdrives/zuse-thumb-ident.img` and produces the `[zuse@Hera] ok>` prompt seen in
|
||
every other task in this document). `logs/20260919-173942/amd64/`,
|
||
`logs/20260919-174126/aarch64/`, `logs/20260919-174307/riscv64/` — all four VMs (Hera/
|
||
Hermes/Hestia/Artemis) born successfully on all three, zero `UNKNOWN WORD`, and critically
|
||
**zero `ok>` occurrences anywhere in any of the three full logs** — genuinely silent,
|
||
matching `sk_repl_headless_wait()`'s own documented "no banner, no prompt, no input
|
||
surface at all." Watched each log's line count at the point after Artemis's birth for
|
||
8–10s and confirmed it stayed flat rather than eventually printing something late.
|
||
|
||
Also confirmed no regression on the standard (with-thumbdrive) path: re-ran amd64 with the
|
||
default `ZUSEDISK` (`logs/20260919-174443/amd64/`) — `dict_hash` identical to task 1.8's
|
||
baseline, zero `UNKNOWN WORD`, reaches `ok>` normally. Did not repeat the standard-boot
|
||
check on aarch64/riscv64 for this task specifically: the change is a comment only, cannot
|
||
diverge by compiler or architecture, and the headless invariant itself was already proven
|
||
identically on all three.
|
||
|
||
**Phase 1 is now fully closed** — tasks 1.1–1.9 all done. Tripod is Hera/Artemis/Hestia
|
||
(plus Hermes, retained through Phase 1–3 per §XXXIV.4); Hestia owns the drawing fabric
|
||
exclusively; headless-until-login policy intact with Hestia in the fleet. Phase 2
|
||
(the allocator and its audit) is next — the phase §XXXIII named as the only genuinely hard
|
||
part, and the project's real go/no-go at task 2.7.
|
||
|
||
## Phase 2 — Allocator and audit (inert) — **the real go/no-go**
|
||
|
||
**Gate:** task 2.7. **If it fails, stop and re-plan. Do not proceed to Phase 3.**
|
||
|
||
- [x] **2.1** — Kernel-Hermes message/membership structures, **wired to nothing, drawing no
|
||
heat**. *Check:* boot byte-identical; `dict_hash` unmoved.
|
||
2026-09-19 · `logs/20260919-204642/amd64/` — byte-identical to task 1.9's baseline in
|
||
every respect: same `dict_hash` triple, zero `UNKNOWN WORD`, reaches `[zuse@Hera] ok>`.
|
||
Did not repeat aarch64/riscv64: the new file is a header with type definitions only,
|
||
included nowhere in the real build, so nothing compiles it into any object file on any
|
||
architecture — there is no mechanism by which it could diverge by compiler or ISA.
|
||
|
||
Added `include/starkernel/vm/kernel_hermes.h`: `SkHermesMessage` (field-for-field mirror
|
||
of `messaging.4th`'s live 9-cell `MSG-*` layout — type/from/to/payload addr+len/Stadium
|
||
cell index/seq/channel/orig-type, plus an explicit `in_use` flag for task 2.2's allocator)
|
||
and `SkHermesMembership` (one flat broadcast membership list — `SXXXIII.4`/`SXXXIII.5`'s
|
||
recommended replacement for `messaging.4th`'s 28-word channel abstraction, which has
|
||
exactly one live caller). Deliberately no separate heat field on the message struct: per
|
||
`SXL.4`, a message's heat *is* the Stadium cell it occupies, not a value copied alongside
|
||
it — keeping one source of truth for the conservation invariant `stadium_conserved()`
|
||
(task 0.7) checks.
|
||
|
||
**Genuinely wired to nothing**: no `.c` file, no Makefile change, no include from any
|
||
compiled source. Syntax-checked standalone (`gcc -std=c99 -Wall -Wextra -Werror
|
||
-fsyntax-only` against a throwaway file `#include`ing it under `__STARKERNEL__`) before
|
||
touching the real build, rather than discovering a typo only once something references it
|
||
in a later task. Item 27 (channel negotiation vs. broadcast, Phase 3 blocker B1) is not
|
||
answered by this structure and isn't meant to be — a flat membership list is correct either
|
||
way; the negotiation question is about behaviour built on top, not this shape.
|
||
- [x] **2.2** — Allocate: pull `Q.SLOT` from the caller's reservoir; roll back on refusal.
|
||
*Check:* N allocs against a known reservoir; refusal at the right count.
|
||
2026-09-19 · `logs/20260919-205534/amd64/`, `logs/20260919-205645/aarch64/`,
|
||
`logs/20260919-205817/riscv64/` — all three reach `[zuse@Hera] ok>`, zero `UNKNOWN WORD`,
|
||
`dict_hash` triple unmoved from task 2.1's baseline (pure C, no FORTH touched). All three
|
||
print `Kernel-Hermes alloc self-test: PASS` with **identical arithmetic**:
|
||
`reservoir0=65536 Q_SLOT=2048 expected_n=32 got_n=32 reservoir_after=0`.
|
||
|
||
Added `sk_hermes_alloc(VMUuid, SkHermesMessage**)` (`src/starkernel/vm/kernel_hermes.c`,
|
||
new file, wired into `Makefile.starkernel`'s `LOADER_EXTRA_SRCS` list since this repo lists
|
||
`vm/*.c` files explicitly rather than globbing). Checks
|
||
`stadium_reservoir_peek(vm_id) >= SK_HERMES_Q_SLOT` **before** touching the reservoir at
|
||
all — refusal this way needs no rollback, since nothing was pulled — with an explicit
|
||
rollback path (`stadium_reservoir_push`) kept for the pull-then-short case defensively,
|
||
though nothing in this single-core kernel is expected to reach it. `SK_HERMES_Q_SLOT`
|
||
defined as `Q48_ONE / SK_HERMES_MSG_MAX` (2048) — **deliberately simpler than
|
||
`messaging.4th`'s own formula**, which reserves a `Q.1/3` floor for `COMMON-CH`'s own
|
||
Stadium heat; kernel-Hermes has no such object (`SXXXIII.4`/`SXXXIII.5`'s flat membership
|
||
list carries no heat of its own), so there is nothing left for that floor to protect.
|
||
|
||
**Self-test, not a FORTH-visible check** (matching the existing `Stadium quota grant
|
||
self-test` pattern already in `kernel_main.c`): mints a second synthetic VM
|
||
(`lo=3`, distinct from the existing self-test's `lo=1`) via `stadium_grant_quota()`,
|
||
reads back its actual granted reservoir (always a fresh `Q48_ONE` per
|
||
`stadium_grant_quota()`'s own code — not assumed), derives `expected_n` from it rather
|
||
than hardcoding 32, allocates until refusal, and checks **all three** of: the refusal
|
||
lands at exactly `expected_n`, the reservoir doesn't move on the refused attempt (rollback
|
||
proven, not just assumed), and the final reservoir equals `reservoir0 − got_n × Q_SLOT`
|
||
exactly.
|
||
|
||
**Noted, not fixed:** `SK_HERMES_Q_SLOT = Q48_ONE / SK_HERMES_MSG_MAX` and
|
||
`SK_HERMES_MSG_MAX = 32` together mean reservoir exhaustion and arena exhaustion land at
|
||
*exactly* the same count by construction — this test cannot distinguish which refusal
|
||
reason fired, only that refusal fires at the right count and rolls back correctly. Not a
|
||
defect at this stage (nothing yet needs the arena to outlive the reservoir), but worth
|
||
remembering if `SK_HERMES_MSG_MAX` is ever resized independently of `Q_SLOT`'s divisor.
|
||
|
||
**Deliberately not evidence for `stadium_conserved()`** — per the watch-list raised before
|
||
starting Phase 2: allocating alone (no release yet, that's task 2.3) leaves pulled heat
|
||
held by kernel-Hermes, off the Stadium floor entirely, so the two-term
|
||
`stadium_resident_sum + reservoir == Q48_ONE` check would correctly read **false** right
|
||
now if run mid-hold — that is expected, not a bug, and is exactly why Stage B (task 2.7) is
|
||
defined as "before and after the alloc/free cycle," not "continuously during." This task's
|
||
self-test checks reservoir arithmetic directly instead, which is the right instrument for
|
||
what task 2.2 alone claims.
|
||
|
||
**AMENDED 2026-09-20, while starting task 2.3 — see that entry for the full account.**
|
||
This task's own first cut of `sk_hermes_alloc()` never admitted a real Stadium-floor
|
||
patron; it only pulled reservoir heat and set a local flag. Corrected in the same commit
|
||
as task 2.3, since release cannot evict something that was never admitted. The two-term
|
||
`stadium_conserved()` non-evidence point above still holds — if anything it holds more
|
||
precisely now that held heat really is off the floor (in the Stadium-admission sense) and
|
||
not merely absent from a two-term check that never modeled it in the first place.
|
||
- [x] **2.3** — Release: return remaining heat via the eviction path. *Check:* reservoir
|
||
restored exactly for an undecayed message.
|
||
2026-09-20 · `logs/20260920-041455/amd64/`, `logs/20260920-041619/aarch64/`,
|
||
`logs/20260920-041752/riscv64/` — all three reach `[zuse@Hera] ok>`, zero `UNKNOWN WORD`,
|
||
`dict_hash` triple unmoved from task 2.2's baseline. All three print
|
||
`Kernel-Hermes alloc/release self-test: ... PASS` with **identical arithmetic**:
|
||
`reservoir0=65536 ... reservoir_after_alloc=0 ... reservoir_final=65536` — exact
|
||
restoration, not approximate.
|
||
|
||
**Real finding, not a clean continuation: task 2.2's allocator was missing a step.**
|
||
§XXXIII.4 item 1 says `MSG-FREE-NODE` returns heat "via `STADIUM-EVICT`" — which only
|
||
means something if allocation admitted a real Stadium patron in the first place. Task
|
||
2.2's first cut didn't; it only pulled reservoir heat and flagged a local slot in use.
|
||
Caught this before writing release on top of a foundation that couldn't support it, per
|
||
§XL.4's own invariant: held message heat that is neither a resident patron nor reservoir
|
||
nor `consumed` is invisible to the conservation equation entirely, which cannot be right.
|
||
Flagged to Captain Bob before proceeding; authorized to correct task 2.2 in the same pass
|
||
as building 2.3 on top of the fix, rather than patching around the gap.
|
||
|
||
**The fix, amending `src/starkernel/vm/kernel_hermes.c`'s `sk_hermes_alloc()`:** after
|
||
pulling `SK_HERMES_Q_SLOT`, now calls `stadium_admit()` with a `StadiumPatronHeader` whose
|
||
`heat` is the pulled amount, `behaviour = STADIUM_BEHAVIOUR_DELIVER` (matching
|
||
`messaging.4th`'s own `SB-DELIVER STADIUM-ADMIT` at its `MSG-ALLOC` site exactly — same
|
||
enum values, `SB-DELIVER`=1=`STADIUM_BEHAVIOUR_DELIVER`), and `identity` set to the
|
||
message's own slot index (matching the FORTH precedent, and keeping
|
||
`stadium_dispatch()`'s existing `DELIVER` diagnostic — "msg_idx=" — meaningful instead of
|
||
every message printing 0; caught live in the first boot of this fix, since all 32
|
||
admissions printed `msg_idx=0` before the identity fix). The returned cell index is
|
||
stored in the message's own `stadium_cell` field. If the Stadium floor itself refuses
|
||
admission (a third refusal path, independent of reservoir affordability), the pull is
|
||
rolled back the same way the other refusal paths already do.
|
||
|
||
**`sk_hermes_release()`, the new function this task actually asks for:** calls
|
||
`stadium_evict()` on the message's `stadium_cell` — which itself returns the departing
|
||
patron's remaining heat to its owning VM's reservoir (`stadium.c`'s own comment: "the
|
||
departing patron's remaining heat must flow back to its owner's reservoir"), so release
|
||
does not touch the reservoir directly, matching `MSG-FREE-NODE`'s exact shape
|
||
(`DUP 5 CELLS + @ STADIUM-EVICT DROP`). Clears the slot regardless of eviction's own
|
||
return value, since a message asked to be released should not remain allocated either way.
|
||
|
||
**Self-test extended, not replaced:** the existing synthetic-VM self-test (task 2.2, `lo=3`)
|
||
now keeps every allocated message's pointer in an array, allocates to exhaustion exactly as
|
||
before, then releases all of them and checks the reservoir returns to precisely its
|
||
starting value. "Undecayed" is true by construction here — no decay/TTL logic exists yet
|
||
(task 2.5) — so this is exactly the case the check asks for: exact restoration, not
|
||
approximate. `stadium_dispatch()`'s existing `DELIVER`-case console output (one line per
|
||
eviction, pre-existing instrumentation, not new) is verbose but expected — confirmed
|
||
real and load-bearing (`stadium.c`'s own comment: "has been real and live on every boot
|
||
for weeks"), not something this task introduced. No compiler warnings on either edited
|
||
file.
|
||
- [x] **2.4** — The four counters: `held`, `pulled`, `returned`, `consumed` (§XL.4). *Check:*
|
||
each increments at exactly one site.
|
||
2026-09-20 · `logs/20260920-055432/amd64/`, `logs/20260920-055549/aarch64/`,
|
||
`logs/20260920-055723/riscv64/` — all three reach `[zuse@Hera] ok>`, zero `UNKNOWN WORD`,
|
||
`dict_hash` triple unmoved. All three print `PASS` with **identical final ledger**:
|
||
`held=0 pulled=65536 returned=65536 consumed=0` — satisfying
|
||
`held == pulled − returned − consumed` (`0 == 65536 − 65536 − 0`) exactly.
|
||
|
||
Added `sk_hermes_ledger(uint64_t*, uint64_t*, uint64_t*, uint64_t*)` (an accessor, not a
|
||
mutator) plus four static counters in `src/starkernel/vm/kernel_hermes.c`. Each has exactly
|
||
one increment/decrement site: `held`/`pulled` both move at `sk_hermes_alloc()`'s single
|
||
success path (after every refusal branch has already returned); `held`/`returned` both
|
||
move at `sk_hermes_release()`'s single success path. `consumed` is declared and always
|
||
reads 0 — **its one increment site doesn't exist yet**, and won't until task 2.5 gives
|
||
decay something to record.
|
||
|
||
`sk_hermes_release()` reads the Stadium cell's **live** `header.heat` immediately before
|
||
calling `stadium_evict()`, rather than assuming the original pulled amount — `stadium_evict()`
|
||
zeroes the header as part of freeing the cell and its own return value is a success code,
|
||
not the credited amount, so this is the only point the true remaining heat is available.
|
||
Today (no decay yet) this always equals the original `Q.SLOT` pull; once task 2.5 exists,
|
||
this is what keeps `returned` correct without touching this function again.
|
||
|
||
Self-test (kernel_main.c) extended again: snapshots the ledger before running (so it
|
||
checks its own deltas, not an assumption that it's the only caller ever), verifies
|
||
`held`/`pulled` grow by exactly `got_n × Q_SLOT` on allocation with `returned`/`consumed`
|
||
untouched, then verifies `held` returns to its starting value and `returned` grows by the
|
||
same amount on release, with `consumed` still untouched, and checks the audit invariant
|
||
itself as a bonus (task 2.6 formalizes this properly; checking it here too cost nothing
|
||
since the ledger was already in hand). No compiler warnings on either edited file.
|
||
- [x] **2.5** — Decay: apply, and **record the delta into `consumed`** (§XXXVII.3). *Check:*
|
||
`consumed` grows by exactly `heat_before − heat_after`.
|
||
2026-09-20 · `logs/20260920-182345/amd64/`, `logs/20260920-183413/aarch64/`,
|
||
`logs/20260920-184152/riscv64/` — all three reach `[zuse@Hera] ok>`, zero `UNKNOWN WORD`,
|
||
`dict_hash` triple unmoved (`c95ef2d92fa0781f` / `fbde9fe105fd3b3d` / `a43d2e104ae7e451`,
|
||
identical across ISAs). All three print `PASS` with **identical** `decay_consumed=352`.
|
||
|
||
Added `sk_hermes_decay(SkHermesMessage*)` and `SK_HERMES_Q_DECAY` (65208, identical to
|
||
`messaging.4th`'s `Q-DECAY`; §XL.4 preserves the economy exactly). It sets the message's
|
||
Stadium-cell heat to `q48_mul(heat, Q_DECAY)` and, at that one site, does
|
||
`consumed += before − after` and `held −= before − after`, so
|
||
`held == pulled − returned − consumed` stays exact. `consumed` now has its one increment
|
||
site.
|
||
|
||
Self-test: a second alloc-to-exhaustion cycle decays each message once. It checks each
|
||
cell's new heat against an independently computed `q48_mul`, checks `consumed` grew by
|
||
exactly the independently summed `before − after` (32 × (2048 − 2037) = 352), checks the
|
||
audit identity mid-hold, and checks that release leaves the reservoir at exactly
|
||
`reservoir0 − 352` (decayed heat does not return, §XL.4). A vacuity guard fails the test
|
||
if decay consumed nothing. The task 2.3 undecayed exact-restoration check is kept as the
|
||
first cycle.
|
||
|
||
Process notes: an accidental `pkill -f` killed the shell once (no effect on results);
|
||
`disk/artemis.img` and `disk/thumbdrives/zuse-thumb-ident.img` were restored via
|
||
`git checkout --` before each ISA per the task 0.0 finding. That discarded a pre-existing
|
||
uncommitted modification to `disk/artemis.img` that was present at session start.
|
||
- [x] **2.6** — Self-audit: `held == pulled − returned − consumed`, **epsilon zero**. *Check:*
|
||
holds across the cycle; **deliberately corrupt a counter → audit fires on the first unit**.
|
||
2026-09-20 · `logs/20260920-204658/amd64/`, `logs/20260920-205410/aarch64/`,
|
||
`logs/20260920-205834/riscv64/` — all reach `[zuse@Hera] ok>`, zero `UNKNOWN WORD`,
|
||
`dict_hash` triple unmoved and identical across ISAs; all print `PASS`,
|
||
`audit_failures=0`, `decay_consumed=352`.
|
||
|
||
Added `sk_hermes_audit_values()` (pure exact-equality predicate, no tolerance),
|
||
`sk_hermes_audit()` (live ledger, O(1), prints and counts a failure) and
|
||
`sk_hermes_audit_failure_count()`. The live audit runs at the end of every successful
|
||
alloc, release and decay (§XXXVII.4: no cadence decision needed). Corruption is tested
|
||
on a *copy* of the ledger, +1 unit on each of the four counters in turn, so live state is
|
||
never corrupted; each is caught by the predicate while the uncorrupted values pass. The
|
||
live audit stayed silent through both alloc/decay/release cycles.
|
||
|
||
Limit, stated: the corruption proof exercises the predicate, not the wiring of the live
|
||
audit's failure branch (that branch never executed). Task 2.8's scan cross-check is the
|
||
independent check on the counters themselves.
|
||
- [x] **2.7** — **Stage B proof** (§XXXIV.3 as corrected by §XXXIX.4): alloc/free cycle
|
||
verifying **(a)** the ledger and **(b)** `stadium_conserved()` before and after.
|
||
*Check:* both true, all three arches. **`fleet_conserved` is not evidence here** — it
|
||
cannot see Stadium heat (§XXXIX.1).
|
||
2026-09-20 · `logs/20260920-212209/amd64/`, `logs/20260920-212522/aarch64/`,
|
||
`logs/20260920-212845/riscv64/` — all print `Stage B (ledger + stadium_conserved): PASS`,
|
||
`audit_failures=0`, `vm_consumed=693`; zero `UNKNOWN WORD`; `dict_hash` triple unmoved and
|
||
identical across ISAs; reach `[zuse@Hera] ok>`.
|
||
|
||
**Prerequisite built here, as §XL.4 directs:** `stadium_conserved()` gains its `consumed`
|
||
term. New per-VM `consumed` field in `StadiumVMQuota` (zeroed at both quota-creation
|
||
sites), `stadium_consumed_record()`/`stadium_consumed_peek()`, and
|
||
`stadium_conserved()` now checks `resident + reservoir + consumed == Q48_ONE`, epsilon
|
||
zero. `SkHermesMessage` gained an `owner` VMUuid so decay charges the funding VM;
|
||
`sk_hermes_decay()` records into it. Other VMs are unaffected (consumed stays 0).
|
||
|
||
Stage B checks `stadium_conserved()` at four points — before, mid-hold, after decay,
|
||
after release — plus the ledger audit, and requires the old **two-term form to FAIL after
|
||
decay** while the four-term form holds (non-vacuity: the consumed term is load-bearing).
|
||
`fleet_conserved` is not consulted.
|
||
|
||
**First attempt FAILED on all three ISAs** (`logs/20260920-211204/`, `-211517/`,
|
||
`-211840/`, kept as audit artifacts). Cause was a bug in the test, not the code: it
|
||
expected 32 allocations, but the preceding decay cycle had consumed 352 from that VM's
|
||
reservoir so only 31 fit. Fixed by deriving the expected count from the current reservoir.
|
||
Vm_consumed=693 is 352 (32×11, first cycle) + 341 (31×11, Stage B).
|
||
|
||
**Phase 2 gate: passed** (2.7 holds on all three arches). Remaining Phase 2 work is 2.8
|
||
(diagnostic scan cross-check).
|
||
- [x] **2.8** — Scan-based cross-check of the counters, diagnostics only, off the hot path
|
||
(§XXXVII.4). *Check:* scan agrees with counters.
|
||
2026-09-21 · `logs/20260921-083638/amd64/`, `logs/20260921-083950/aarch64/`,
|
||
`logs/20260921-084314/riscv64/` — all print `Scan cross-check (counters vs arena): PASS`
|
||
with identical `scan_held_before_decay=8192`, `scan_held_after_decay=8148`; Stage B and
|
||
the main self-test still `PASS`, `audit_failures=0`, zero `UNKNOWN WORD`, `dict_hash`
|
||
triple unmoved and identical across ISAs.
|
||
|
||
Added `sk_hermes_scan_held()` (walks the arena, sums live Stadium-cell heat of in-use
|
||
messages, reports the live count) and `sk_hermes_scan_check()` (scan == `held`, exact).
|
||
Called only from the self-test, never from alloc/release/decay. The check runs at rest
|
||
(0 live), mid-hold (4 live, 4×2048 = 8192), after decay (8148 = 8192 − 4×11) and after
|
||
release (0), with a vacuity guard (non-zero mid-hold, strictly less after decay).
|
||
|
||
Limit, stated: the scan reads the same Stadium cells the counters were derived from, so
|
||
it verifies the counters against the arena, not the Stadium cells against ground truth;
|
||
the latter is `stadium_conserved()`'s job (2.7).
|
||
|
||
**Phase 2 is complete (2.1–2.8).** Phase 3 remains blocked on B1, B2, B4.
|
||
|
||
## Phase 3 — Cutover — **UNBLOCKED, tasks not yet written**
|
||
|
||
**Blockers cleared 2026-09-21 (§XLV). Task list drafted 2026-09-21, awaiting Captain Bob's
|
||
review — none started.** Shape (§XXXIV.3, amended by §XLV): build the negotiated pub/sub
|
||
plumbing inert, then cut over `BLK-ATTACH-EVENT` alone, then remaining types one at a time,
|
||
under §XXXIV.2's partition rule — one message type owned by exactly one layer, no message
|
||
shared. **Stop condition (§XXXIV.6): `dict_hash` diverging across ISAs, or Stage B evidence
|
||
(ledger + `stadium_conserved()`) going false — re-plan, do not push on.**
|
||
|
||
- [x] **B1** — **CLEARED 2026-09-21 by `FABRIC-3.5.md` §XLV.1**: negotiated pub/sub channels —
|
||
one common channel, private channels by request/grant/deny, ACK/NACK throughout. Overrules
|
||
§XXXIII.5. Open sub-items: ACK cadence, ACL hook for channel-open policy.
|
||
- [x] **B2** — **CLEARED 2026-09-21 by `FABRIC-3.5.md` §XLV.2**: dynamic, not a fixed constant
|
||
(Stadium-style RAM-derived sizing). Open sub-item: the concrete sizing rule.
|
||
- [x] **B3** — **CLEARED 2026-09-19 by `FABRIC-3.5.md` §XLIII**: the target drains its own
|
||
queue at its own outermost interpret checkpoint; kernel-Hermes publishes and never
|
||
dispatches. Reuses `sk_vm_at_outermost_interpret()` and the Stage 3 checkpoint.
|
||
- [x] **B4** — **CLEARED 2026-09-21 by `FABRIC-3.5.md` §XLV.3**: one block (1024 bytes) per
|
||
message, larger payloads chunked. Open sub-item: chunk framing.
|
||
|
||
**All four blockers are cleared, but Phase 3 has no task breakdown yet** — the shape below
|
||
predates §XLV's negotiation. Writing the task list (and settling the §XLV.4 sub-items it
|
||
depends on) is the next step, before any Phase 3 code.
|
||
|
||
### Phase 3 tasks (drafted 2026-09-21; **draft, not authorized**)
|
||
|
||
Each is one commit with three-ISA acceptance, per the standing rules. Tasks marked **[needs
|
||
ruling]** cannot be written precisely until Captain Bob settles the named sub-item.
|
||
|
||
- [x] **3.0** — **Decision gate, not code.** Rule on the §XLV.4 sub-items: **(a)** ACK cadence
|
||
(advised: channel open + delivery, not every common-channel message); **(b)** where the
|
||
channel-open ACL hook lives in `ACL.4th`; **(c)** the dynamic switch-table sizing rule;
|
||
**(d)** chunk framing; **(e)** drain one message per checkpoint (§XLIII.6.3, recommended,
|
||
never ruled). *Check:* each answer recorded in `FABRIC-3.5.md`.
|
||
2026-09-21 · no commit (documentation ruling, see `FABRIC-3.5.md` §XLVI) · all five
|
||
sub-items plus task 3.3's heat-cost point ruled by Captain Bob, all recommended defaults
|
||
accepted.
|
||
- [x] **3.1** — **Dynamic switch table** (B2). Read
|
||
`SK_SWITCH_MAX_SLOTS`'s every use first; replace the constant with a boot-time,
|
||
RAM-derived allocation (Stadium's `stadium_max_vm_count_val` pattern). *Check:* boot
|
||
byte-identical, `dict_hash` unmoved; a synthetic test drives more than 16 slots.
|
||
2026-09-21 · `logs/20260921-233241/amd64/`, `logs/20260921-233814/aarch64/`,
|
||
`logs/20260921-234837/riscv64/` (riscv64's first attempt, `logs/20260921-234312/`,
|
||
timed out mid-boot on a 280s wrapper before reaching the prompt — kept per the
|
||
never-delete-logs convention, not a real finding, just an undersized timeout; the
|
||
234837 rerun with more headroom reached the prompt cleanly). All three reach
|
||
`[zuse@Hera] ok>`, zero `UNKNOWN WORD`. Switch-signal table sized dynamically off
|
||
`stadium_max_vm_count()` at boot, confirmed via a new `Switch-signal: N slots` console
|
||
line: **50 slots (amd64), 202 slots (aarch64), 50 slots (riscv64)** — all far above the
|
||
old fixed 16-slot cap, satisfying the "drives more than 16 slots" check without a
|
||
separate synthetic harness (real boot-time RAM sizing already clears it by a wide
|
||
margin). Reused `session_boot_init()`'s exact pattern (kmalloc to
|
||
`stadium_max_vm_count()`, called in `kernel_main.c` right after `stadium_boot_init()`,
|
||
before the first `sk_vm_switch_signal_register()` call). `dict_hash` for Hermes
|
||
(`0xc95ef2d92fa0781f`) and Hestia (`0xfbde9fe105fd3b3d`) identical across all three
|
||
architectures — unmoved from pre-task values, as expected (this task touches no
|
||
capsule). Artemis's `dict_hash` differs between the amd64 run (`0xa43d2e104ae7e451`,
|
||
fresh-formatted `disk/artemis.img`) and the aarch64/riscv64 runs (`0x7f18214489036b39`,
|
||
both *resuming* the same disk state the amd64 run left behind) — a disk-state artifact
|
||
of running three sequential boots against one shared image, not an architecture
|
||
divergence; not a §XXXIV.6 stop condition.
|
||
note: unrelated finding, not fixed — riscv64's boot logged three
|
||
`virtio_blk: vblk_io timed out` errors during Artemis's disk I/O in both riscv64
|
||
attempts (sectors 20/8/8 and 3224/5496/5504); boot recovered and reached the prompt
|
||
regardless. `virtio_blk.c` was not touched by this task. Reporting per standing rule,
|
||
not investigating further here.
|
||
- [ ] **3.2** — **Channel table + common channel**, inert (B1). Dynamic table of topics, each
|
||
with its own `SkHermesMembership`; the common channel exists from boot; every VM is
|
||
subscribed at birth. Wired to nothing. *Check:* boot byte-identical; every born VM appears
|
||
in the common channel's membership; create/destroy a synthetic private topic.
|
||
- [ ] **3.3** — **Publish path, no dispatch** (§XLIII.3). Publish allocates via
|
||
`sk_hermes_alloc()`, enqueues onto each subscriber's own pending queue, and records the
|
||
fact; it dispatches nothing. Self-test only. *Check:* ledger audit and
|
||
`stadium_conserved()` hold across N publishes to M subscribers (heat cost per subscriber
|
||
is a design point to settle **before** writing this: one message per subscriber, or one
|
||
shared message with a reference count — **[needs ruling]**).
|
||
- [ ] **3.4** — **Drain at the outermost checkpoint** (§XLIII.3–.5). Reuse
|
||
`sk_vm_at_outermost_interpret()`; one message per checkpoint **[needs ruling 3.0e]**.
|
||
*Check:* a nested interpret does not drain; a queued payload is interpreted exactly once at
|
||
depth 1.
|
||
- [ ] **3.5** — **Payload bound and chunking** (B4) **[needs ruling 3.0d]**. Max 1024 bytes per
|
||
message; larger payloads sent as ordered chunks, reassembled before drain. *Check:*
|
||
1024-byte payload single message; 3000-byte payload chunked and reassembled byte-exact;
|
||
1025-byte single-message send refused.
|
||
- [ ] **3.6** — **ACK/NACK and private-channel negotiation** (B1) **[needs ruling 3.0a]**.
|
||
`request` → `grant`/`deny` on the common channel; a grant creates a private topic;
|
||
close tears it down. ACK/NACK are message types on the existing allocator.
|
||
*Check:* grant path, deny path, close path; heat conserved (ledger + `stadium_conserved()`)
|
||
across all three; a NACK'd request leaves no topic behind.
|
||
- [ ] **3.7** — **Channel-open policy hook** **[needs ruling 3.0b]**. Kernel-Hermes asks
|
||
`ACL.4th`, never decides in C, never gates on `zuse_session`. *Check:* a denied open is
|
||
denied by FORTH policy, with the C unchanged when the policy changes.
|
||
- [ ] **3.8** — **Stage C: cut over `BLK-ATTACH-EVENT` alone** (§XXXIV.3). One layer owns it;
|
||
FORTH Hermes still routes every other type. *Check:* the real Hera↔Artemis attach path
|
||
works end to end on all three ISAs; ledger and `stadium_conserved()` true before/after;
|
||
**`fleet_conserved` is not evidence** (§XXXIX).
|
||
- [ ] **3.9** — **Stage D: `CONSOLE-CMD-EVENT` (type 7)**, then **3.10 `ELEVATE-REQUEST`
|
||
(type 8)** — one type per task, each with the 3.8 check. Any type found live beyond these
|
||
three is added here, not bundled.
|
||
- [ ] **3.11** — **Phase 3 gate.** No FORTH-owned live message types remain; Stage B evidence
|
||
holds across a full boot on all three ISAs. **Do not start Phase 4 until this passes.**
|
||
|
||
## Phase 4 — Category B strip
|
||
|
||
Only after every live type is cut over. **Hermes leaves `is_fleet_foundation` and
|
||
`kernel_main.c` here, not earlier** (§XXXIV.4).
|
||
|
||
- [ ] **4.1** — Strip `capsules/hermes/init.4th`.
|
||
- [ ] **4.2** — Strip the FORTH routing table and slot-3 pairing convention.
|
||
- [ ] **4.3** — Strip `capsules/common/messaging.4th`.
|
||
- [ ] **4.4** — Remove Hermes from `is_fleet_foundation` and its birth from `kernel_main.c`.
|
||
|
||
## Phase 5 — Close-out
|
||
|
||
- [ ] **5.1** — Isabelle/HOL pass. **Deliverable is the restated boundary**, explicitly
|
||
including §XXV.4's coverage loss — *not* a green build (§XXV.3).
|
||
- [~] **5.2** — Documentation sweep, grepping **by exclusion** (§XXVIII.3).
|
||
**CLAUDE.md's four errors: DONE 2026-09-19 (§XLIV), pointer to this document added.**
|
||
Outstanding: `MANIFEST.md` (rides the strip, §XXII.5), the `TRIPOD.md`/0.1 contradiction,
|
||
item 42's K-qualification, the superseded subsystem docs' update-or-archive call, and
|
||
item 45 (`experiments/bare_metal/README.md` block framing).
|
||
- [ ] **5.3** — `make sbom`; check `Created:` and `DocumentName` (§XXVI.2).
|
||
- [ ] **5.4** — `LITHOS_VERSION = 2.1.0`; engine `VERSION` per §XXX.6's rule; roadmap table
|
||
gains its `2.1.0` line in two live places (§XXVIII.2).
|
||
- [ ] **5.5** — Resolve the stray `refs/heads/v2.0.1` and PR #1 (§XXVI.4). **Investigate, do
|
||
not delete.**
|
||
- [ ] **5.6** — Merge to `master`; tag `v2.1.0`.
|
||
- [ ] **5.7** — Archival close of `FABRIC-3.5.md` (§XXVI.5) and of this document.
|
||
|
||
---
|
||
|
||
## Findings log
|
||
|
||
*Defects and surprises found while executing. Reported, not fixed (unless the task was to fix
|
||
them). A finding that contradicts a `FABRIC-3.5.md` ruling must also be amended there.*
|
||
|
||
**2026-09-19, task 0.0 — shared `disk/artemis.img` confounds cross-ISA `dict_hash` comparison
|
||
unless reset between runs.** Not a code defect and does not contradict any `FABRIC-3.5.md`
|
||
ruling — `FABRIC-3.md` §XXXV.2 already documents that the disk is deliberately shared across all
|
||
three ISAs' `qemu` targets. But it means a same-order rerun of the three architectures will have
|
||
run 2 and 3 silently take Artemis's `resuming` branch instead of its `blank disk -- formatting`
|
||
branch, producing a different `dict_hash` for Artemis alone (Hera and Hermes are unaffected —
|
||
neither touches the artdisk at birth). Worth carrying forward: **any task in this document that
|
||
checks `dict_hash` identity across architectures and involves Artemis should restore
|
||
`disk/artemis.img` and `disk/thumbdrives/zuse-thumb-ident.img` to their committed blank state
|
||
(`git checkout --`) before each architecture's run**, or the check will fail on a confound rather
|
||
than a real divergence.
|
||
|
||
---
|
||
|
||
## Out of scope, carried for visibility
|
||
|
||
Recorded in `FABRIC-3.5.md`, deliberately **not** part of this reshuffle. Listed so they are not
|
||
absorbed by accident:
|
||
|
||
- **Item 43** — should a Stadium reservoir ever replenish? (§XL.6) A VM's send capacity declines
|
||
monotonically today.
|
||
- **Items 23–26** — the `FABRIC-3.5.md` §XXXI gap-analysis follow-ups: re-home `FABRIC-2` §17.4,
|
||
consolidate the three reported-not-scheduled registries, decide `FABRIC-2`'s five orphaned
|
||
design items, reconcile `FABRIC-0`'s seven opens.
|
||
- **`src/*.c.bak`** — tracked-but-stale, reported in three places and actioned in none
|
||
(§XXII.5).
|