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

FABRIC-3.5.md §XLI: the build punchlist -- phases 0-2 buildable, phase 3 blocked

Browse Source 
Answers the question asked: yes for the first three phases, no for the
fourth, and the reason is three named things rather than general caution.

Phase 0 is preparation with no behaviour change -- Category A
reachability established per §XXII.2's three routes rather than by grep,
the strips themselves, MANIFEST corrected as its files go, freed blocks
returned, stadium_conserved() added, and the framebuffer registration
audited. Phase 1 is Hestia with messaging untouched, sequenced per
§XXXIV.4 so Hermes is retained and is_fleet_foundation holds four names.
Phase 2 is the allocator and its audit, inert, ending in the Stage B
proof that §XXXIX.4 corrected: the ledger plus stadium_conserved(), with
fleet_conserved explicitly not evidence.

Twenty-five tasks across those three phases, each with its own check,
which also discharges item 34. Phase 2 is deliberately reachable early,
since §XXXIII named it the only genuinely hard part and it should fail
cheaply with nothing built on top.

Phase 3 is not buildable pending item 27 (channels: negotiation or one
membership), item 32 (SK_SWITCH_MAX_SLOTS is 16 and §XXXII made the
switcher the sole mover, so whether this is a constant bump or a table
redesign changes the phase's shape), and §XXXII.5.1, the delivery
hand-off, which is the last genuine design question in the reshuffle and
sits on the critical path.

Records a caution: phases 0-2 can run without answering those, which is a
feature, but it means arriving at a working audited allocator with the
cutover still undesigned. Better to settle the hand-off before phase 2
finishes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VkM1zHGvBerLF6aqkHPweP
This commit is contained in:
Claude
2026-09-19 12:14:31 +00:00
parent 91173854cb
commit 91108c23c9
1 changed files with 120 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
FABRIC-3.5.md
+120
View File
@@ -4330,3 +4330,123 @@ whoever meets a VM that has quietly stopped being able to send knows where it wa
- ⬜ **Item 43, NEW, outside this reshuffle** — should a Stadium reservoir ever replenish?
(§XL.6)
- Items 32–35, 37, 42 unchanged.
---
## XLI. The build punchlist: phases and testable tasks
**Asked: is it now possible to break this into phases and small testable tasks? Answer: for
Phases 0–2, yes. For Phase 3, no — and the blockers are three named things, not general
caution.** Each task below carries its own check, which also discharges item 34 ("name the
evidence before the stage runs").
**Standing rules for every task:** one task per commit; three-architecture QEMU acceptance
(`clean qemu`, amd64/aarch64/riscv64, foreground, one at a time) before the next; logs
committed; `dict_hash` **identical across architectures** (changing is expected, diverging is
the stop condition, §XXXIV.6). **No task starts without explicit authorization.**
### XLI.0 — Phase 0: preparation, no behaviour change
| # | Task | Check |
|---|---|---|
| 0.1 | Establish Category A reachability per §XXII.2's three routes — boot path, tooling, baked capsule directory. **Never by grep alone.** | A written list with the route that proves each entry dead |
| 0.2 | Strip `common/msg.4th` | 3-arch boot; `mkcapsule --lint` clean |
| 0.3 | Strip `process.4th` (takes `EVENT-EMIT/WAIT/DRAIN` with it, §XXXIII.3) | 3-arch boot; lint clean |
| 0.4 | Strip `SPAWN-EVENT` | 3-arch boot; lint clean |
| 0.5 | Correct `MANIFEST.md` blocks 4055 and 2049 **as their files are stripped** (§XXII.5) | Manifest describes no file that no longer exists |
| 0.6 | Return freed block ranges to `capsule-reserved.txt` | lint clean |
| 0.7 | **Add `stadium_conserved()`** (item 41) — `Σ patron + reservoir + consumed == Q48_ONE`, epsilon zero, the five-line analogue of `vm_physics_conserved()` | Returns true on a clean boot, all three arches |
| 0.8 | Verify `PLOT`/`FB-WIDTH`/`FB-HEIGHT` are registered **nowhere but** the table Hestia will own (item 33) | Read-only audit; a second registration site is a defect to report |
**Phase 0 gate:** all three architectures boot to `zuse)ok>`, `stadium_conserved()` true, no
`UNKNOWN WORD`.
### XLI.1 — Phase 1: Hestia, with messaging untouched
| # | Task | Check |
|---|---|---|
| 1.1 | Allocate Hestia's block range against `capsule-reserved.txt`, avoiding 4997 | `mkcapsule --lint` clean |
| 1.2 | Create `capsules/hestia/init.4th` — messaging load, `MSG-CD-INIT`, banner. **No fabric yet** | Boots; Hestia absent from fleet (not yet birthed) |
| 1.3 | Add Hestia to `is_fleet_foundation` — **four names, Hermes retained** (§XXXIV.4) | 3-arch boot; Hermes still live |
| 1.4 | Birth Hestia at `kernel_main.c`, **alongside** Hermes's existing birth | Registry shows both; `dict_hash` identical across arches |
| 1.5 | Register Hestia for switch signals (`:1007` pattern) | Boot clean; no switch storm (§XXVIII.2's failure shape) |
| 1.6 | Move `fabric.4th` from `init.4th` to `hestia/init.4th` | Hera's dict shrinks, Hestia's grows; cross-arch identity holds |
| 1.7 | Move `font.4th` likewise | Same |
| 1.8 | Move `PLOT`/`FB-WIDTH`/`FB-HEIGHT` registration to Hestia's table only | A non-Hestia VM calling `PLOT` gets `UNKNOWN WORD` — **verify positively** |
| 1.9 | Assert §XVIII.6's headless invariant in code: Hestia's birth sets no `g_wirebind_attached_username`, mints no proxy | Boot headless with no thumbdrive; no prompt appears |
**Phase 1 gate:** Tripod is Hera/Artemis/Hestia **plus** Hermes; drawing works from Hestia and
only Hestia; headless policy intact.
### XLI.2 — Phase 2: the allocator and its audit (Stage A/B, inert)
**This is the phase that matters most and the one §XXXIII named as the only genuinely hard
part.**
| # | Task | Check |
|---|---|---|
| 2.1 | Kernel-Hermes message/membership structures. **Wired to nothing; draws no heat** | Boot byte-identical; `dict_hash` unmoved (no FORTH edit) |
| 2.2 | Heat-coupled allocate: pull `Q.SLOT` from the caller's reservoir, roll back on refusal | Unit path: N allocs against a VM with known reservoir; refusal at the right count |
| 2.3 | Release: return remaining heat via the eviction path | Reservoir restored exactly for an undecayed message |
| 2.4 | The four counters — `held`, `pulled`, `returned`, `consumed` (§XL.4) | Each increments at exactly one site |
| 2.5 | Decay: apply, and **record the delta into `consumed`** (§XXXVII.3) | `consumed` grows by exactly `heat_before − heat_after` |
| 2.6 | Self-audit: `held == pulled − returned − consumed`, **epsilon zero** (§XXXVII.3) | Holds across the cycle; deliberately corrupt a counter → audit fires on the first unit |
| 2.7 | **Stage B proof** (§XXXIV.3, corrected by §XXXIX.4): alloc/free cycle verifying **(a)** the ledger and **(b)** `stadium_conserved()` before and after. **`fleet_conserved` is not evidence here** | Both true before and after, all three arches |
| 2.8 | Scan-based cross-check of the counters, for diagnostics only, off the hot path (§XXXVII.4) | Scan agrees with counters |
**Phase 2 gate — and the project's real go/no-go:** if 2.7 fails, **stop and re-plan. Do not
proceed to Phase 3.** §XXXIII said if K holds across alloc/free/evict under the new arbiter, the
rest is protocol plumbing; this is where that is established or disproved, cheaply, with nothing
else built on top.
### XLI.3 — Phase 3: cutover — NOT YET BUILDABLE
**Three specific blockers, each a ruling or a design, not a task:**
1. **Item 27 — channels: negotiation or one broadcast membership?** §XXXIII.5 recommends one
membership and keeping the FORTH channel words until something asks for them. **Unruled**,
and it changes what Phase 3 builds.
2. **Item 32 — `SK_SWITCH_MAX_SLOTS` is 16.** §XXXII made the switcher the sole mover of
control, so 16 becomes a fleet ceiling. **Whether this is a constant bump or a table
redesign changes Phase 3's shape**, and cannot be estimated until it is decided.
3. **§XXXII.5.1 — the delivery hand-off is undesigned.** Delivery must cause the payload to
*execute inside* the target (`messaging.4th` block 5041). Under §XXXII the switcher resumes
the target on its own stack, so kernel-Hermes must leave the payload somewhere the target
consumes on resume. **That mechanism does not exist on paper.** It is the last genuine design
question in the reshuffle, and it is on the critical path.
**What Phase 3 will look like once unblocked** (shape only, per §XXXIV.3): cut over
`BLK-ATTACH-EVENT` alone — one request/ack pair, the narrowest live type — under §XXXIV.2's
partition rule, one message type owned by exactly one layer; then the remaining types one at a
time; gate each on `stadium_conserved()` plus the ledger, and on no new allocation refusals
against the FORTH-only baseline (§XXXIV.6).
### XLI.4 — Phase 4: Category B strip
Only after every live type is cut over. `hermes/init.4th`, the routing table, the slot-3 pairing
convention, then `messaging.4th` itself. **Hermes leaves `is_fleet_foundation` and
`kernel_main.c` here** — not earlier (§XXXIV.4). One commit per item; 3-arch boot each.
### XLI.5 — Phase 5: close-out
Isabelle/HOL pass, deliverable being the **restated boundary** including §XXV.4's coverage loss,
not a green build (§XXV.3) · documentation sweep, grepping **by exclusion** (§XXVIII.3), with
CLAUDE.md's four errors, the `TRIPOD.md`/0.1 contradiction, and item 42's K-qualification ·
`make sbom`, checking `Created:` and `DocumentName` · `LITHOS_VERSION = 2.1.0`, engine `VERSION`
per §XXX.6's rule · resolve the stray `v2.0.1` branch and PR #1 · merge to `master` · tag
`v2.1.0` · **archival close of this document.**
### XLI.6 — The honest assessment
**Buildable now: Phases 0, 1, 2 — 25 tasks, each with a check, each one commit.** That is
roughly half the work and includes the hard part (Phase 2), which is deliberate: the riskiest
piece is reachable early and fails cheaply.
**Not buildable: Phase 3**, pending two rulings and one design. **Phases 4 and 5 are
shape-complete but depend on 3.**
**A caution worth stating.** Phases 0–2 can be executed without answering the Phase 3 blockers,
and that is a feature — but it means arriving at a working, audited, inert allocator with the
cutover still undesigned. **Better to settle §XXXII.5.1's hand-off before Phase 2 finishes**, so
Phase 3 starts with momentum rather than a pause. It is the last real design question, and it is
the natural next iteration.