Archive — history, not state. Kept for its reasoning and its evidence; its plan is closed.

Stones 6 and 7 — the execution map (recon 2026-07-28, read-only, verified against the tree)

Produced because the roadmap’s rows 6 and 7 are each one line and each is 5-6 landings. Everything here is cited to file:line and was read, not grepped. Where this contradicts plans/roadmap.md, this is right and the roadmap is stale — the corrections are §4.

1. THE UNBUILT PREREQUISITE THE ROADMAP DOES NOT NAME — 6.0 / 7.0

LANDED 2026-07-29 — one landing, not three. source/mach.c now carries Pit_MachAssemblePool / Pit_MachAssemblePoolFromUnit / Pit_MachLowerWindowToPool. The size question below is answered: ~600 lines of C, and it does not split. See “the measurement” at the end of this section. Everything else in §1 is the recon as written, and stays for the reasoning.

There is no C single-unit pool assembler. The only producer of pmp1 bytes anywhere is shoplib/mach_pool_emit.cm:454 — Pit. In C, "pmp1" appears only in readers.

This is load-bearing for BOTH stones:

• Stone 6 wants mach_materialize_cpool dead. It cannot die when “constants live in images”; it dies when pit_load_mach_code dies (its sole caller, mach.c:4280). And pit_load_mach_code serves both payload lanes — pmac AND pmcd. boot/root.cart’s windows are all pmcd (verified: 23 modules, 23 pmcd windows), so the register-tree lane survives until pmcd can be lowered to a pool by this binary’s own emitter. docs/architecture/boot.md:53-54 already states that as the target: “one mcode unit to one pool”.
• Stone 7 needs the same thing, because after the boot-actor rewrite root.cart still carries exactly two pmcd windows (engine + boot walker) and both must be callable.

Size unknown: the single-unit case has no cross-unit dedup and an empty import plan (mach_lower.cm:85-91), so it should be far smaller than mach_pool_emit.cm’s 903 lines — but that number was not measured, and it decides whether 6.0 is one landing or three.

The measurement (2026-07-29)

mach_pool_emit.cm is 903 lines. Mapped onto the single-unit case in C:

~600 lines, and it is ONE landing. The reason is not the size, it is that there is no seam: a pool is sealed by a checksum over its own finished bytes, so half a writer emits nothing that opens, and no intermediate state is a shippable capability. The three-landing shape the recon allowed for would have been three commits of which only the last was testable.

Two things made it smaller than the table suggests. Pass one was factored out of Pit_MachPoolFragment (mach_frag_lower) rather than reimplemented, so the two producers cannot see different instruction words for one unit — the byte-equality claim rests on that being one function. And Pit_MachStoneText was factored so the object header, packing and cached hash have one constructor (mach_stone_object_from_codepoints) reached from both the PitValue side and the C-string side.

Byte-identical, verified. Not “conformant” — the same bytes, for 16 units including engine/engine_lite.cm (78KB pool) and cart/cart.cm (307KB pool). tests/pool_assembler.ce is the breadth gate (real fleet modules, plus running what C assembled through $image against the register lane); source/mach_pool_asm_test.c is the C gate that runs in every check-arms arm, against a fixture the Pit linker wrote (tools/pool_fixture.ce, regenerated by make smoke). Both were falsified: removing the disruption_pc sentinel translation turns the C test red.

What this does NOT do. It adds a capability; it deletes nothing. mach_lower_mcode_window, mach_materialize_cpool, pit_load_mach_code, the pmac reader and the code cache are all untouched and still on the live path — those are 6.2, strictly downstream. PIT_POOL_PAYLOAD stays off. mach_load_bin still calls the register lane for a pmcd window; Pit_MachLowerWindowToPool takes the same bytes and answers the other form, which is the call 7.3 will make.

6.1b — the switch: the boot path lowers to a pool (LANDED 2026-07-29)

The call above is now made. All three pmcd doors — start_plan.c’s run_unit and boot walker, pit.c’s actor boot image — go through Pit_MachWindowResidentPool and run the result as a pool. boot.md’s “loading it is lowering it” is true of the code for the first time; the doc needed no change.

• One decision function, Pit_MachWindowIsPoolLane, is all the three doors branch on. pmp1 → already a pool. pmcd → lowered here. pmac → the register lane.
• Lowered pools are cached runtime-wide, keyed by a blake2-256 of the source window, because the image provider adopts a placement BY ADDRESS and borrows the range forever: a second actor must reach the same bytes, not a second copy. No source copy is kept (the code cache’s memcmp key would have cost megabytes of retained mcode).
• runtime_window_pool_count / _bytes are new $inspect counters and are the POSITIVE observable — every other counter in §2.3 is a thing that should shrink; this is the thing that should exist.

Measured, darwin/host-nan64-v1, make smoke daemon, before → after:

The −22 is exactly root.cart’s pmcd windows leaving the code cache. Net resident bytes are down ~2.47MB even counting the new pool cache. The per-program +1 did not move and could not have: that entry is the program’s own freshly cemented unit, which is pmac because the lever is off. Measured with PIT_POOL_PAYLOAD=1 the per-program delta is 0 — so the two halves of the runtime_code_count story are this switch (boot media) and the lever (what the shop cements), and neither substitutes for the other.

What it deleted: mach_lower_mcode_window, on every arm but one. It is now #if defined(PIT_TEXT_KIM8) and so is mach_load_bin’s pmcd branch — see §2.5.

What it did NOT free, and why it is one reason not five. pit_load_mach_code, mach_materialize_cpool, mach_resolve_shape_spec/_record_shapes, the code cache, mark_code_tree_shared and the three code->shared GC arms are ALL still live, and all of them for the same single cause: with PIT_POOL_PAYLOAD off, every cemented scratch image’s CODE windows are pmac, and run_unit’s register arm loads them. Verified by call-site sweep, not inferred. So 6.2’s remaining deletions are gated on 5b/5c exactly as §2.1’s graph already says — the switch does not shorten that dependency, it only proves the pool side of it works on the boot media first.

2. STONE 6 — the coupled deletions

2.1 Dependency graph (forced, and not the order the roadmap gives)

              5b/5c: PIT_POOL_PAYLOAD on + reseed
                     (boot.cart windows become pmp1)
                              │
     ┌────────────────────────┼──────────────────────────┐
   6.0 C single-unit    6.1 convert/delete          6.1b cross-target
       pool assembler       $mach_load +                 pool stamp
       *** NOT IN ROADMAP    $mach_compile_mcode_bin      (numrep/endian)
                             + 125 .cm/.ce sites
     └────────────────────────┼──────────────────────────┘
                              │
   6.2 delete pit_load_mach_code and everything it owns:
       mach_materialize_cpool (mach.c:2515) · mach_resolve_record_shapes (2608) ·
       mach_resolve_shape_spec (2586) · the pmac reader (3148-3355, 4482) ·
       the pmac WRITER (2873-3142) · code_cache + mark_code_tree_shared +
       the three code->shared GC early-returns
                              │
   6.3 delete the intern table
       A: Pit_SetPropertyStr stops interning   ← INDEPENDENT, landable now (in flight)
       B: rt_init_builtin_keys out of the runtime stone pool
       C: pit_new_cfunc_internal's name key
                              │
   6.4 ct_lock has zero callers  ← THE COMPLETENESS CHECK

Parallel: 6.0, 6.1, 6.1b, and 6.3-A are mutually independent. Serial: everything into 6.2; 6.3 proper behind 6.2.

2.2 pmac is NOT residue — it is the live payload form

• Producers: Pit_SerializeMachCode (mach.c:3125), exposed as mach.mach_compile_mcode_bin, the boot-context name, and the $mach_compile_mcode_bin endowment. AND mach_lower.cm:76-78 — the default arm with the lever off and the permanent arm whenever numrep or endian is set, i.e. every cross-target cement (n64/ps1/psp/dc big-endian and fixed32). That second condition is a deliberate capability boundary, not a transitional state.
• Consumers: mach_deserialize_any via mach_load_bin, from start_plan.c:476 and pit.c:103; boot/boot.cart — 113 modules, all 113 windows pmac (verified by parsing it); cart_boot.c:305-312; cart/cart.cm:504,525-526; and 125 direct call sites across 40 .cm/.ce files (heaviest: tests/compile.cm 38, which make check runs).

So pmac deletion is blocked on: the lever landing + a reseed; 6.0; the $mach_* surface conversion; and a cross-target decision (§5.1).

2.3 Observables that prove each deletion

The $inspect counters are already exposed to Pit and no test asserts any of them — that coverage must be written before the deletions are safe.

2.4 Looks deletable, is load-bearing

1. mach_lower_mcode_window (mach.c:3362) — the normative dev boot lane and the only reader of root.cart’s engine window. Re-target it; do not delete it. DONE 6.1b — it was re-targeted, not deleted: the lane it served is now Pit_MachWindowResidentPool, and the function survives compiled only under text=kim8 (§2.5).
2. code->shared + the three GC early-returns (pit_gc_copy.c:884,2414, pit_gc_compact.c:866) — deleting the cache without these is a use-after-free the other way. One atom.
3. pit_rt_ct_alloc for PitCode/PitFunction — why ct_lock does NOT reach zero when only the text table goes.
4. mach_code_cacheable’s MACH_CP_FLOAT rejection is a correctness filter, not policy.
5. plan_run_pool’s image registry (start_plan.c:105-300) — backs actor.register_image and the scratch lane; survives stone 6 entirely.

2.5 text=kim8 holds up MORE than the pmac reader — it holds up the whole register lane

Found while landing 6.1b, and it sharpens §5.1’s open question rather than answering it. A pool’s STONE section is UTF-32 by format, so mach_pool_assemble and everything reaching it sits under #if !defined(PIT_TEXT_KIM8) (mach.c:4504). A kim8 build therefore has no mcode→pool path at all — not merely no pool writer for cements, but no way to make root.cart’s ABI-neutral windows callable except by lowering them into a register tree.

So the switch could not simply delete the register arm of the doors. What it did instead: Pit_MachWindowIsPoolLane answers 0 for pmcd under kim8 and 1 everywhere else, and mach_lower_mcode_window + mach_load_bin’s pmcd branch are compiled only under kim8. That is a PROFILE arm, which the system sanctions, not a compatibility arm, which edict 1 forbids — there is no second way to do this on that target and no first way on any other. It is asserted, in every arm including the kim8 ones, by window_lane_decisions_are_exact() in source/mach_pool_asm_test.c, which is deliberately the one half of that file that runs BEFORE its self-skip.

The judgement, stated so it can be overruled cheaply. Deleting the arm would have been simpler and would have narrowed a target’s capability while John’s §5.1 question is open. Whether kim8 has ever booted a cart is not established — check-arms compiles it and runs the C suite, it does not boot it — so the arm may be protecting a capability that does not exist. If John rules that kim8 need not boot, the whole register lane collapses one step further than 6.2 currently plans: mach_lower_mcode_window goes outright, and pmac’s remaining holders are only the lever and the ~125 mach_load call sites.

2.6 A defect found in passing, NOT fixed here

PIT_INPROCESS=1 deadlocks on a cold realization — reproduced at 68b97fc9 with no changes applied, so it is pre-existing and predates this work. Two actors block and the fleet never completes: one in scheduler_snapshot ($inspect.snapshot()’s per-runtime counter walk) and one in actor_watch_stop_register ($couple’s registration), which reads as a lock-order inversion between the engine and per-actor mutexes that only the in-process lane’s timing exposes. The daemon lane realizes the same program fine, which is why no gate catches it (cli/inprocess runs against already-realized content).

Left alone deliberately: a scheduler lock-order fix is its own landing with its own reasoning, and doing it inside a payload-form change would make both unreviewable. It cost about half an hour of this landing’s time — it looked exactly like the switch having broken boot.

3. STONE 7 — minimal C boot

3.1 The real line count

start_plan.c is 803 lines (not 870, not 757 — 5a grew it). cart_boot.c is 590. The “~150-line fixed header” is achievable only for the cart-mount + header + enter path, and only if medium discovery shrinks. Honest estimate: ~150 for that path, ~240-260 counting runtime creation and the boot wota. host.c’s 461 lines were excluded; if they count, no version of this is 150.

3.2 The crossing — the roadmap’s constraint is half wrong, and the 4b recipe applies

next-arc.md:429 says “pit_init needs image 0’s PLANS before any pit runs — writer and reader cannot move in one pass.” That is true only because engine_claims is derived in C (start_plan.c:607-622) and handed to the engine as a context field. What pit_init structurally needs is the engine window, not the ENTRIES section. Move the derivation into build_engine_record and C never reads ENTRIES.

Then the 4b section-kind recipe applies directly:

1. Phase 1 (additive, Pit only): cement.cm’s build_boot (:708-721) writes a boot-walker module index into the currently-reserved word at BOOT offset 28. cart_boot.c reads only offsets 0 and 4 and requires boot_len >= 24, so an old binary ignores it. Reseed; behaviour unchanged.
2. Phase 2: pit_init reads BOOT+28, makes that window callable, and calls it instead of boot_actor_shell_plan. The Pit boot walker reads ENTRIES/MODULES/STRINGS through the cart codec. start_plan.c deletes.

Each phase is one reseed and never leaves the tree with an unbootable cart. Retire the old path; do not reuse the word.

3.3 shop_actor’s exclusion resolves by the root getting SMALLER

A pmp1 header carries a target-profile hash and a mach-ABI hash and Pit_MachPoolOpen (mach.c:494-497) refuses a mismatch. pmcd carries no stamp at all — that is M1’s ABI-neutrality, and why root.cart’s windows are pmcd. A pool cannot be ABI-neutral.

So: do not make root.cart carry a pool, and do not change M1’s rule. Under the boot-actor model root.cart carries exactly two windows C touches — the engine and the boot walker — both pmcd, both lowered by this binary’s own emitter, neither a fleet module. Everything else, shop_actor included, is started by the boot actor through $image from boot.cart or the store, where windows are pmp1 and stamped. The root cart’s ABI-neutral surface shrinks from 23 windows to 2 and the exclusion evaporates without anyone touching M1.

3.4 The residual floor after stone 7

$log_enabled’s retirement is not one row: the ENGINE_NAMES row (cement.cm:116), the unconditional claim_entry at cement.cm:436, engine_value’s arm, four names in engine_lite.cm:284-303,458,493, the C callback trio (pit_internal.h:2271-2273, runtime.c:1965-1967,2523-2531, pit_actor.c:555-596,931), three GC root sites, and tests/lazy_log_enablement.ce which must be REPLACED by a token-passing test, not deleted. The log pre-injection at pit.c:180-181 goes with it — but the C sink survives as C-internal, since C code must still be able to log.

3.5 Landings

7.0 = 6.0 (shared) · 7.1 engine_claims into build_engine_record (landable now) · 7.2 boot-walker window (additive BOOT word + cement + reseed) · 7.3 pit_init calls it, start_plan.c deletes — DONE 2026-07-29, 805 → 601 lines; see edicts.md, “What 7.3 landed”, for the two-slice handover and why the root-medium walker fallback replaced the cement change this section assumed · 7.4 cart_boot.c shrinks — note it GREW by 87 lines in 7.3 (the root medium is kept beside the mount for its walker), so 7.4 starts from 677 · 7.5 $log_enabled retirement. Serial: 7.0 → 7.3 → 7.4/7.5. Stones 6 and 7 share 6.0/7.0 and both touch mach.c and start_plan.c, so they cannot run as two independent agents.

4. Corrections to the plans files (apply these)

1. roadmap.md:64 and :516 say start_plan.c is 870; it is 803. next-arc.md:423 says 743, :352 says 757. Four numbers, one file.
2. roadmap.md:59-63 omits 6.0 entirely — the prerequisite without which stone 6’s headline deletion cannot happen.
3. roadmap.md:990-993’s stated mechanism for the intern table is already closed: obj[computed_text] goes through pit_key_from_string, which no longer interns. The live caller is Pit_SetPropertyStr (~796 sites), and it is not image-blocked.
4. roadmap.md:62 implies the five listed deletions get ct_lock to zero. They do not — pit_rt_ct_alloc for PitCode/PitFunction and two accounting snapshots also take it. roadmap.md:1042-1047 says this correctly; the two passages disagree.
5. edicts.md:45 lists the pmac reader as deletable “once the pool reader has callers”. The precondition is met; the deletion is nowhere near — 125 call sites, 113 live windows, and a permanent cross-target producer.
6. next-arc.md:953-955 asks for a ruling on shop_tools/mach_emit.cm. The file does not exist. Moot; retire the note.
7. next-arc.md:429’s crossing constraint is half wrong — see §3.2.
8. source/mach.c:63-68 claims “nothing executes from a pool yet”. Stale since 5a.
9. roadmap.md:830-838 lists pit.executable@1 as future work; next-arc.md:707 records it DONE; roadmap.md:29 marks it queued. Three states, one item.
10. Two edicts.md:41-46 kill-list rows are already done and unrecorded: MACH_RESERVED_OP0/OP1 and the DYNAMIC record-shape kind.

5. Open calls

5.1 Needs John (recorded, decided provisionally overnight — see overnight-decisions.md)

• Does the cross-target/big-endian cement lane keep pmac? Decides whether stone 6 can honestly claim the writer is gone.
• Must text=kim8 be able to BOOT, or is it a compile-only arm? Sharpened by 6.1b — see §2.5. It is the last thing keeping mach_lower_mcode_window and mach_load_bin’s pmcd branch compiled anywhere, and nothing in the tree establishes that a kim8 build has ever mounted a cart.
• Do $mach_load/$mach_compile_mcode_bin die, and what replaces the 125 sites? The capability must stay engine-side (functions cannot cross actors).
• Which medium-discovery precedences stay in C? Dropping --cart/PIT_CART/boot.cart to a clerk mount is what makes ~150 reachable, and it changes the dev loop’s shape.
• Does root.cart become 2 windows, or stop existing in favour of appended-only?
• Where does $actorsym live once C stops building the boot context?
• Is the boot actor’s own executable a plan, or found by header offset like the engine? This decides whether C reads ENTRIES at all.

5.2 In-scope judgement (an agent may decide and document)

The split of 6.2 into commits; whether mach_v2_tree_read_swap goes with the reader or the cross-target decision; where the new $inspect assertions live; whether cart_profile_diff survives; the exact BOOT word offset; whether the boot walker is a MODULES row or a section kind; the ordering of 7.4 vs 7.5.

6. Coverage that must exist before the deletions are safe

Exists: tests/image_lanes.ce (the 5a gate, deliberately falsified), tests/mach_code_cache.cm (asserts the behaviour 6.2 inverts — rewrite, do not delete), tests/start_plan_images.ce, the $image surface tests, the C pool-reader tests.

Missing: no test asserts runtime_shape_count == 0, the ct arena being unused, or that every boot.cart window is pmp1. No gate cements a cross-target cart at all, so the pmac cross-target producer is untested as well as undeleted. PIT_MACH_DEBUG_CONTRACTS is compiled by no arm (every arm is -O3).

Source: plans/archive/stone-6-7-map.md