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

System overhaul transition diary

Status: CLOSED 2026-08-01, audited entry by entry against the post-L3/L4 tree (4b444103) and archived. Begun 2026-07-22. system.md, the normative system this file deferred to, no longer exists — the target design is docs/, and the live plan is plans/finalization-arc.md. Read this file for the reasoning behind a bridge and for the evidence its cleanup ran; never for direction.

This diary records code or data retained solely to cross a self-hosting boundary. It grants no permanent compatibility. Every active entry names one owner, one call surface, the reason it must temporarily exist, and an executable removal gate.

The closing audit (2026-08-01)

Every entry was checked against the tree by grepping its named surfaces. Ten of the eleven active bridges are gone; T002 is the only one whose surface a runtime still executes. Four superseded sole paths (S001, S002, S003, S004) are replaced; nine remain. Three things the audit found that the tables above did not say, recorded because they are gate deviations rather than gate completions:

1. T020’s gate was skipped, not met. Meson was deleted (no meson.build in the tree, no meson target in the Makefile) before the console lanes were ever built under cake and compared against it. The oracle the row existed to preserve is gone and the comparison it was preserved for never happened.
2. T014’s surface left the code and stayed in the spec. No producer emits the derivation-input provenance arm, but docs/spec/artifact-formats.md still specifies pit.linked.runtime.derivation-input@1 as though one does.
3. Two rows contradict the tree by their own terms. S006’s gate requires boot/boot.cart automatic production and discovery to be deleted; both survive (source/cart_boot.c, Makefile), as do boot/engine_lite.mach and cart/image.c, which the 2026-07-23 cart-cutover decision below names for deletion. And the 2026-07-22 note “native execution has one policy question” records allow_compile as deleted; pit-shop/policy.ce carries it.

Rules:

1. A transition has a unique name and is never selected by probing or fallback.
2. Its ordinary runtime reachability is stated explicitly and kept as narrow as possible.
3. Its removal is part of the phase that satisfies the named gate.
4. Deleted entries remain in the completed table as evidence that the cleanup ran.
5. A superseded surface that is still the sole implementation is tracked separately below; calling it a transition does not make it an accepted second path.

Active temporary bridges

Superseded sole paths awaiting replacement

These are removal work, not compatibility promises. They remain reachable because their replacement phase is incomplete.

Audit 2026-08-01 — what each surviving row is, in the tree. S001-S004 moved to the completed table; the eleven below were re-verified by grep and not one gate is fully met.

• S005 — engine/boot_walk.cm:16-22 still names boot_dylib_open / boot_dylib_symbol / boot_dylib_preload / os.native_module_load as boot-context facts and still prefers an AOT dylib on a UNIT row with the pool as fallback; pit-shop/cement.cm:360-363 writes program_dylib_path into that row. AOT is parked by edict 7, so this gate is parked, not approaching.
• S006 — half met. pit.cart@2 is the only container: cart/cart.cm:1, pit-shop/cart2.cm, source/cart_boot.c:1, and the magic actually compared is pcr2 (source/cart_boot.c:354) with no v1 probe or fallback anywhere. pit.cart@1 survives only as text in one comment copied three ways (Makefile:545, boot/manifest/bootstrap.sh:569, cake/manifest.cm:376) and one stale line (source/cart_boot.c:344). NOT met: automatic boot/boot.cart production and discovery, which the gate requires deleted, is live in source/cart_boot.c:25,207-229 and Makefile:332-334,391,403-416,546-564. Also still present, both named for deletion at this cutover by the 2026-07-23 decision below: boot/engine_lite.mach (still cement’s engine input — Makefile:855, pit-shop/cement.cm:157) and cart/image.c (surviving repurposed, as the mounted image’s positional read surface).
• S007 — pit.bundle@2 exists nowhere. pit.bundle@1 is still the sole shop/store snapshot: pit-shop/shop_build.cm:2805,2871, shop_realize.cm:1556, shop_source.cm:2296,2328, shop_actor.ce:1011.
• S008 — pit.policy.receipt@1 exists nowhere. pit-shop/policy.ce:63,239 still carries allow_compile, which the 2026-07-22 note below records as deleted.
• S009 — half met, and the other half is superseded rather than pending. The actor module carries no runtime-wide power: tests/actor_module_surface.ce:16-29 pins nineteen names as unreachable by import. But they landed on FIVE endowments — $inspect, $hook, $runtime, $vm, $pgo — not the one policy-granted $runtime this row names, and docs/shop/endowments.md:369-371 now ratifies that split as permanent. The row’s gate describes a design the docs replaced.
• S010 — see T002. wota2value / nota2value are C-owned semantic traversal on the boot, cart-metadata and mailbox paths.
• S011 — pit_region_table is still a process-global (source/runtime.c:73-259), and the append-only registry is still source/start_plan.c:55-247, PLAN_IMAGE_MAX and the “none evictable; restart the” refusal at :87 included.
• S012 — the public os dylib/preload/symbol/native-module surface is still exported per platform: platform/dc/os_dc.c:133-143,382,412-413, platform/n64/os_n64.c:146-156,397, and the posix arm.
• S013 — create_actor_shell (source/pit.c:388, source/pit_actor.c:8-14), boot_actor_plan (:55-99), register_image (:101-125), endowment_descriptor (:284), execution_lane_available (:321) and set_message_handler (:441) are all still installed. Partial credit: shutdown, set_courier_actor and set_logger_actor did move to $runtime (source/pit_actor.c:673,846; std_endowments/runtime.c:45,157).
• T015 — unmet, and the gate is superseded. The file moved internal/vm.c -> std_endowments/vm.c and still compiles as endowment/vm: boot/manifest/darwin.manifest:95. But the gate ("$runtime owns the same functions; the package manifest no longer declares $vm") is contradicted by docs/shop/endowments.md:369-371, which names $vm one of four permanent debugging endowments. This row wants retiring as obsolete, not executing.
• T016 — unmet. set_logger_actor still takes an actor id, not the opaque token the gate requires: logger/sink_core.cm:37 ($runtime.set_logger_actor(boot.id)) and pit-shop/development_shop.ce:1298. Partial credit: the C forwarding function left the actor module for $runtime, and the C plan walker is gone with S004.

Plan-alignment decisions made during implementation

• 2026-07-23 — runtime observation and collector policy are explicit inputs. Allocation-site sampling is quiescent until an authorized Pit profiler selects a nonzero interval through $runtime, and player builds omit the sampling sites and counters. Collector topology and sizing are one exact GC profile; verification is a test-build choice. Node worker count and actor heap, stack, and timer limits arrive as explicit node/start configuration. Failure to instantiate the selected collector is a diagnostic runtime-start refusal. The current ambient allocation-sample, nursery, worker-count, timer, and legacy Mach-generation switches are cleanup inventory, not compatibility surfaces.

• 2026-07-23 — a sealed console cart selects an exact linked-provider closure. PS1 and N64 cart production writes the cart’s claims to a build spec after cementing. The matching fleet linker compiles exactly the linkable manifest providers named by that spec, omits all other ordinary extensions, and refuses every unknown, missing, or optional-library key. Static boot primitives remain unconditional. The N64 shipped cart/fleet is exactly n64-nan32-v1; nan64 is a standalone non-shippable harness diagnostic. Both current console lanes select UTF-32 explicitly, and PS1 accepts only the retail 2 MiB or diagnostic 8 MiB RAM maps. This is permanent exact-profile and provider-closure behavior, not a fallback. The SDK-independent scripts/check_console_readiness.sh keeps this input boundary green and separately reports the still-open P4 resident-pool/player-memory gates.

• 2026-07-23 — the plain v1 console claims sidecar is crossing-bound. Its provider keys are selected exactly, but adjacent naming and the PIT_*_CLAIMS_SPEC override do not bind that detached file to the cart bytes. It is sufficient only for the current cart-v1 proof. A sealed v2 linker reads the claim closure from the verified cart manifest, or consumes a sidecar carrying and verifying the exact cart content identity; it does not accept an arbitrary detached key list.

• 2026-07-23 — bootstrap fleet realization owns its end-to-end request budget. A cold portable fleet realization can compile a large source closure before returning through the development and root shops. The bootstrap request now carries an explicit 1,800-second REPLYTIMEOUT; ordinary forwarding preserves that field, so both waits describe the same initiating operation. Builder batches remain independently bounded by their 600-second compile timeout. This is permanent requestor-owned lifetime policy, not a transition variable, retry path, or compatibility fallback.

• 2026-07-23 — engine_lite is the sole cold and ordinary Pit runner. The engine is necessarily the first executable image and already owns the strict target-start path, so a second general realization runner would duplicate lifecycle, binding, and actor-state policy. Move the provider-adapter behavior and focused coverage from pit-shop/realization_runner.cm and the authorization/store-selection coverage from pit-shop/image_provider.cm into engine_lite, then delete both test-only modules and their focused tests. The deletion gate is one suite against the engine path covering direct pools, adapter-backed providers, initialization order, dense result imports, provides, retained module results, cleanup, and balanced image pins. Cold and ordinary entry select that same implementation; there is no runner probe or fallback.

• 2026-07-23 — provider adapters are unit closures in the actor’s one realization. A provider-registry row keeps the portable adapter executable hash, selected local unit, private binding, and raw-provider ABI. Target finalization brings that adapter’s complete manifest closure into the requesting executable’s realization, assigns its local units unique dense actor-state instance slots, places all main and adapter images under one request/receipt, and verifies each adapter manifest’s precomputed initialization order. The exact start packet carries each adapter manifest. engine_lite initializes adapter closures first, exposes private provider/identity/ control values only to each selected adapter unit, publishes the selected result as the public endowment, and then initializes the main executable. Every returned value remains in one ordinary actor-owned module-result array and every image follows the same PoolBinding/provider-owner lifetime. This schema cutover begins after the in-flight fresh-successor request completes and its cold-boot gate is recorded. The composition/finalizer slice now carries and verifies the complete manifest array, assigns adapter instances in the shared realization, includes adapter images in the policy subject, and executes adapter initialization in the Pit runners. Production activation now uses that same schema: the normal portable compiler publishes the exact adapter manifest and closure, the build exposes Cake’s linked rows with the exact adapter manifest/unit/private binding, ordinary and bootstrap realization select only rows claimed by the requesting closure, and bootstrap reads adapter manifests and mcode through the ordered store stack. Ordinary realization consumes the exact permanent catalog supplied by the root and fails closed when it is absent; it never hashes the running executable, whose cart and pitpack tails are placement rather than bare-runtime identity. pit-shop/realization_runner.cm, pit-shop/image_provider.cm, and their focused tests remain transition-only proof scaffolds until the accepted runner can execute the equivalent engine_lite suite; that gate deletes them rather than exposing a second runner or image-provider API.

• 2026-07-23 — native-loader authority crosses only after the accepted cold successor. Cake owns the exact linked-runtime provider catalog: canonical static keys, logical requirements, implementation kinds/ABIs, typed entry provenance, and exact adapter identities. A realization selects its closure-specific registry from that catalog and exact native-image descriptors. The root privately captures only exact static invocation, typed native-image placement/entry materialization, and an opaque process-pinned owner. Pit owns receipt authorization, catalog selection, content/ABI/entry verification, placement policy, and the content-addressed $native_loader.load({image, abi, entry}) interface. The loader adapter is an ordinary provider-adapter closure in the requesting executable’s one realization, receipt, image set, initialization order, and actor result array. Player catalogs name fixed sealed images/entries and omit the general loader. S012 records the one producer crossing and complete deletion gate; it is not an active compatibility bridge before the current cold-successor gate.

• 2026-07-23 — cart v1→v2 is a producer-only crossing followed by an atomic reader cutover. The running v1 generation first emits the successor’s strict root manifest and mcode closure, complete profile/ABI/provider registry, policy request/receipt, target realization and binding rows, and direct pmp1 pools with engine_lite first. Pit then writes the binary v2 cart. T014 links and hashes the bare runtime before that cart is cemented and appended. The raw provider learns to adopt validated resident POOL_DATA ranges; the successor C floor gets one bounded v2-only header/BOOT/first-pool reader and passes an opaque checked view to engine_lite, which materializes the semantic realization. No runtime binary reads both versions. The cutover includes both currently reachable artifacts: thin appended boot/root.cart and full discovered boot/boot.cart, which cart_boot.c prefers when present. Changing only the thin cart does not cross cold boot. Once both discovery cases cold-boot/store-verify v2, or the full-cart route has been deleted, remove the v1 cement and read paths, old BOOT/PLANS schemas, parsed-Mach boot, source/start_plan.c and its registries/tables, legacy cart/image accessors, boot/engine_lite.mach, both pseudo-runners, fixtures, probes, and all fallback selection in the same successor change.

• 2026-07-23 — the v2 root cart has one boot route and separates system roots from executable roots. boot/root.cart becomes the one embedded v2 development root cart. Automatic boot/boot.cart production, discovery, freshness state, and preference are deleted; an explicitly configured game cart remains an ordinary v2 input to the same reader. The cart system roots name the exact bare runtime image, target profile, linked runtime provider catalog, aggregate claims closure, and boot realization. Package resolutions/locks and closure-specific provider registries remain attached to their executable/realization objects rather than being collapsed into one cart-wide lock or registry. A fixed BOOT row names the root realization, first engine pool, entry index, and engine unit instance. A bounded metadata object index supplies exact non-pool/non-asset objects; C validates only the container, BOOT, profile/ABI, checksum, and resident engine placement before passing opaque views to Pit. boot/engine_lite.mach and cart/image.c are deleted at this cutover. Deliberately duplicated pool placements retain distinct placement identity and adopted resident ranges never unmap container-owned memory.

• 2026-07-23 — pcr2 is a deterministic Pit-owned physical projection of the logical cart manifest. The logical pit.store.manifest@1 cart record has the fixed system roots {runtime, target_profile, provider_catalog, aggregate_claims, boot_realization}; executable locks and closure-specific provider registries remain in their executable/realization objects. Its closed BOOT record names the rooted realization, engine pool, Mach ABI, entry, unit instance, and ordered service locators. Every declared object has exactly one physical class: indexed METADATA_DATA, one-or-more explicit POOL_DATA placements, or indexed cold ASSET_DATA. The pcr2 writer emits a fixed target-endian header and section directory, engine-first POOLS and PLACEMENTS rows, canonical manifest, claims root, and closing trailer. It verifies every object hash/length, the canonical target-profile and Mach-ABI records, each pool’s embedded profile/ABI/checksum, all ranges, and both the directory and zeroed-field payload checksums before publication. The Pit complete publication/offline reader repeats those checks and canonical-layout reconstruction. Runtime mounting retains the range-reader store boundary so it can authenticate the manifest/indexes without scanning cold ASSET_DATA; no eager whole-blob store shortcut exists. Production v1 routing remains untouched until S006’s atomic reader cutover.

• 2026-07-23 — synchronous startup publishes Pit’s outbound queue at the realization boundary. Actor and module top levels execute ordinary Pit and may send while their initialization order is running, but synchronous actor startup does not enter the scheduler’s later turn-end hook. The development shop therefore booted successfully and queued its policy-service request, then idled forever before receiving a first turn that could flush it. engine_start_finished now invokes the existing Pit send_messages hook once after all unit initializers complete. No scheduler message walk or service-specific C wakeup was added. A child-actor regression proves that a top-level send reaches its overling before the child receives any mailbox turn.

• 2026-07-23 — image-provider mutation checks use the Pit exception contract. PoolBinding’s two actor-owned provider-array writes previously compared the PitValue returned by Pit_SetPropertyNumber with an integer error convention used by a different property API. Both sites now test the returned value with Pit_IsException before publishing the corresponding native resolved-bit. This is C-floor correctness at the irreducible image-address seam; no binding policy or fallback moved into C.

• 2026-07-23 — module-granular finalization is also module-granular in memory. The portable bootstrap reader used to authenticate and store units one at a time, then the development-layout helper reparsed the entire mcode closure into one actor-owned record before lowering it. The layout builder now consumes each authenticated unit immediately, emits its Mach pool and origin sidecar, and releases the parsed tree before requesting the next unit. Only per-unit image rows and import counts survive until binding/layout sealing. A synchronous-reader trampoline prevents callback recursion from retaining prior unit frames; no heap increase, paging policy, or second finalization path was introduced.

• 2026-07-23 — bootstrap cement consumes exact references lazily. The old root-cart path copied every Mach payload into the bootstrap actor’s executable graph before the cement writer copied those bytes again into CODE. Generation B reached its actor heap limit during that duplicate hydration. boot_cart now requires exact Mach hashes and services the writer’s synchronous read_mach callback from the verified content store one object at a time. The executable stays in reference form; no heap increase or compatibility loader was added.

• 2026-07-23 — unused module-initializer aliases do not enlarge the VM. shop_build retained many top-level aliases after their owning paths moved to dedicated modules. They made its generated initializer require 269 frame slots, beyond the fixed 256-slot Mach frame. The unused aliases were deleted, restoring a valid initializer, rather than increasing permanent runtime memory for dead bindings.

• 2026-07-23 — dead C compatibility names and arbitrary-Mach actor boot are deleted. Static extensions have one exact lookup API and build-generated tables are their only registration source; the no-op registration macros, invocations, and legacy lookup alias were removed. Actors can enter only the provider-owned shared engine image selected by their checked start path, so the unused heap-copying run_boot primitive, owned-Mach shell, and per-actor ownership/free flag were removed. Boot carts require a root plan; the unused hydrated-record accessor and record-only BOOT form were deleted. Header-only debugger declarations with no implementation or caller were also removed. These were final deletions, not self-host bridges; start_plan.c remains governed by S004 until the cold Pit-runner gate passes.

• 2026-07-23 — sealed bootstrap artifacts are adapted once at the typed finalizer boundary. The root target stores all exact records uniformly as {value, hash}. The module-granular layout API accepts role-specific {finalizer, hash} and {mach_abi, hash} inputs. The bootstrap realizer now performs that field adaptation after validating the sealed target, before invoking the layout API. The prior direct pass could only fail its exact-byte check; no compatibility shape or fallback reader was retained.

• 2026-07-23 — canonical stone text is an exact Mach ABI axis. The hosted pool validator requires canonical packed UTF-32 text carrying its finalized FASH64 hash, so pit.mach.abi@1 names that semantic contract as stone.text: "canonical-fash64-v1" in its complete execution-safety record. Pool derivations key on the exact ABI artifact hash; naming the validator contract changes that hash and makes structurally older cached pools unreachable. Bootstrap construction, bootstrap adaptation, development finalization, and runtime start require the exact complete ABI record.

• 2026-07-23 — the first portable pitpack was packed by the bounded T001 host tool. Generation B could not realize the qop command after the source generation crossed, and its mounted QOP did not contain the cached command’s exact Mach closure. The already-audited T001 uncompressed packer wrote the standard QOP layout from the verified content/ tree and independently checked every row, member byte, path hash, bound, and BLAKE2 object name. This is crossing tooling only; ordinary generation output remains owned by the Pit qop actor once the new shop cold-boots.

• 2026-07-23 — the one-generation bootstrap starts through the ordinary catalog. The crossing QOP has one canonical catalog row for gitea.pockle.world/john/cell/internal/bootstrap.ce; its variant names the exact stored executable object, and the root resolves that row through the mounted content backend. The predecessor-only pit.bundle@1 envelope exists solely to pass Generation B’s root gate before the actor-local store adapter exposes the standard manifest. The verified T001 workspace source map is mutable producer input only and is absent from the QOP, pitpack, cart, and accepted successor. The successor carries the portable development closure as source, mcode, exact resolution, and package metadata in the standard content manifest.

• 2026-07-22 — artifact identity and embedded checksums. A Mach pool or cart is identified by the content-store hash of its exact final bytes. Each fixed header field computed with its own bytes zeroed is named payload_checksum and is used only to validate container corruption. It is not exposed as a content or artifact hash. Loose development realization tests prove the stored-byte hash is the image identity and remains distinct from the embedded checksum; cart v2 follows the same rule.

• 2026-07-22 — object layout is an explicit profile axis. pit.target.profile@1 names object.header_bits and a versioned object.layout (pit.object.nan64-v1 or pit.object.nan32-v1). Pool finalization consumes that axis directly; value width never implicitly selects an object ABI.

• 2026-07-22 — emergency frame capture is a permanent primitive boundary. Ordinary inspection and symbolization belong to Pit’s $runtime and debugger. Crash, teardown, and no-actor paths retain a fixed six-row, allocation-free C capture containing only raw IMAGE pool/function/PC or process-local register/native code/PC facts. It performs no name, file, line, hook, or heap work and is therefore not a compatibility bridge.

• 2026-07-22 — execution form is exact. Native and Mach realizations are distinct authorized artifacts. A native start row contains no Mach payload; failure to load its selected dylib is a start failure. Runtime availability never substitutes another execution form.

• 2026-07-22 — ordinary policy is fail closed. Missing, dead, timed-out, malformed, denied, or execution-form-mismatched policy responses refuse the start. The only temporary exception is the locator-exact T005 cold-boot bridge above; it grants no ordinary package, build, or debug operation.

• 2026-07-22 — system messages have one semantic owner. The scheduler no longer scans unbounded encoded mailbox bytes for a stop shape or halts an actor before its receiver runs. Every mailbox value passes through the one bounded Wota decoder, and engine_lite interprets the system symbol in Pit. The scheduler retains only the primitive halt operation invoked by that Pit path. The duplicate stop and profiler-label byte walkers and their tests were deleted.

• 2026-07-22 — seed and cart are one boot generation. A seed build records its content stamp, seals and verifies the matching cart with the daemon that produced the seed, and only then repacks and restarts the runtime. A rejected required boot service writes an ERROR: boot record, and the launcher terminates and reaps an endpoint-less child after boot failure or readiness timeout. This prevents a stale cart from shadowing a fresh seed and a failed daemon from blocking the corrected launch.

• 2026-07-22 — module-result imports are portable IDs. Mcode declares a dense import table and its import instruction refers only to an entry ID. Executable manifests bind that ID to a provider unit instance. The Pit start runner installs the corresponding actor-owned module-result values only while invoking the consuming unit’s zero-argument initializer. Same-image edges are final indices; cross-image code relationships remain PoolBinding rows, while dynamic module results remain ordinary actor state.

• 2026-07-22 — content dedup retains reference provenance. A cart/store object row is identified by its content hash and may serve distinct module locators whose final bytes are identical. Each executable manifest/record retains its own ordered locator references. Verification compares the referenced object hash while policy, diagnostics, and update provenance use the per-reference manifest row.

• 2026-07-22 — executable image rows carry the expected Mach ABI. The pool header seals the backend/Mach-ABI artifact hash, so every Mach image row in a target realization carries that exact hash into the authorized open request. The provider validates content, target profile, and ABI from authenticated inputs rather than deriving an expectation from a path or mutable host state.

• 2026-07-22 — live image functions retain their placement owner. An image-backed function has a traced actor-heap edge to its binding/provider owner in addition to the raw immutable PoolBinding pointer and function index. Nested closures inherit it. The private provider gives each binding its own balanced pin, so explicit open/pin tokens can be released while live closures continue to execute; both copying and compact collectors scan the edge.

• 2026-07-22 — realization binding coordinates are physical row indices. unit.entry and provider_entry select ENTRIES rows, while binding.import selects an IMPORTS row. The selected IMPORTS row carries the portable (importing_unit, import_id) identity. Loose one-unit pools keep the current zero/dense values, and fused pools remain unambiguous when several units have the same dense import ID.

• 2026-07-22 — content lookup and image lifetime remain separate adapters. The Pit image-provider adapter resolves an authorized exact hash to a local content-store path and strips policy/store fields before invoking C. The unimportable C provider receives only placement plus expected content, profile, and Mach-ABI hashes; it maps, validates, binds, pins, and closes. Cart placement and non-local store materialization can replace the Pit path selector without changing the VM/provider lifetime contract.

• 2026-07-22 — the raw image provider is a consumed boot capability. C installs the private provider record only in the initial engine context. engine_lite captures it and clears the slot before any executable unit can run; the record has no registry symbol or source locator. Pit consequently owns authorization, store selection, and realization orchestration without exposing unchecked placement primitives as an actor endowment. The synchronized seed/cart blake2:8a5240a8d237528a73c112857700f7d72ac0ef5f80df749a0aed9945742b43e9 store-verifies and cold-boots with this boundary active.

• 2026-07-22 — ordinary compilation enters through portable mcode and actor start selects a target-final form. Source compilation produces and caches strict portable mcode. Development starts and boot-service requests select Mach by default; an explicit native start consumes the same mcode input. Hydrated mcode closures no longer cross the actor-start boundary or scale the coordinator heap with build provenance. Until T008 is removed, the cart-v1 workshop finalizer emits its legacy Mach image from that portable input; the production replacement is the exact pit.mach.pool@1 realization selected before start.

• 2026-07-22 — static-binding schema change invalidated the derivation catalog. The local development catalog contained 3,089 recomputable rows produced by the pre-ID builder. It was cleared once while retaining every content object, package, and source checkout, forcing the ID-producing builder to realize current executable records. No compatibility reader was retained in the catalog path.

• 2026-07-22 — compact pools keep the common container and target object layout. The pure-Pit finalizer now emits nan32 int22/binary32 immediates, 32-bit object prefixes, UTF-32/fash64 stone, and either target byte order in the same pit.mach.pool@1 tables used by nan64. Hosted nan32 tests open and validate both endian forms through the production C parser. Image-backed execution on compact profiles remains gated on the provider installing the resident placement as an image reference window before it creates any PitValue pointing into that stone; arbitrary desktop file mappings do not satisfy that address ABI.

• 2026-07-22 — realization content and freshness are separate. Legacy realization closure roots now use canonical JSON and carry only canonical locators plus exact source/mcode/native/provider content identities. Absolute checkout paths, stats, and creation times live only in schema-v4 realize-index.json, which is a deletable freshness accelerator. The realization context no longer contains shop_path or core_path; linked checkout graph identity projects links to canonical package locators and manifest hashes. Once compilation has produced exact source and mcode hashes, post-link dependency collection no longer reopens every source file: it records optional local stats only, and a later freshness check reads bytes only after a stat change. Native files retain the stat-fast/content-verify path because their content identity is not already present in mcode. Seed/cart blake2:7c6f5c968d29acb4cc22c60fd5401f00d13ecf990184f3a09f32a13c2c5a9bea store-verifies and cold-boots, and the executable-artifact suite passes 14/14 from that boot.

• 2026-07-22 — package locator and native symbol namespace are separate. Dependency rows and executable provenance retain the canonical package locator. Static C symbol construction uses the package manifest’s declared name; thus gitea.pockle.world/john/cell/internal/nota_raw has canonical package identity gitea.pockle.world/john/cell and symbol pit_core_internal_nota_raw_use. Native provider identity is the canonical package plus manifest key, so aliases and request spellings cannot duplicate it. Core is reached through an ordinary declared dependency rather than an implicit bare-name fallback.

• 2026-07-22 — source resolution converges at the manifest boundary. A short recipe name or workspace alias may locate a package, but every returned source/native target uses the manifest’s canonical package locator. The source reader mounts the lookup spelling and declared locator onto the same backend. This removed five redundant fleet execution references and ten duplicate native claim spellings; byte-identical distinct canonical files remain separate logical rows backed by one physical object.

• 2026-07-22 — executable lookup retains aliases only at the catalog edge. Explicit program targets are canonicalized to the package manifest’s locator before realization, and every sealed cart executable is indexed by its canonical root in addition to its declared user-facing aliases. Alias generation keeps only meaningful stem, filename, and basename spellings; the invented core/core/... rows were deleted. The strict seed/cart blake2:0f083bf019454e2598e3b88efaa1202b4594dd196f7537fcda3d8317bdf49aab contains 103 unique objects and 12 executable records, store-verifies, and cold-boots; canonical/alias resolution passes 20/20.

• 2026-07-22 — byte-oriented codecs do not inherit host integer order. Wota text uses the same conditional word swap as Wota blobs, FIT reads and writes explicit most-significant-first bits without memcpy into a native integer, and Nota exposes exact signed decimal coefficient/exponent pairs. Forced big-endian text, aligned and unaligned FIT, signed 64-bit FIT, and canonical decimal vectors pass in the native codec-correctness test. These remove the two reproduced N64 codec blockers without adding a target branch.

• 2026-07-22 — deny-C is an executable-finalization invariant. The strict executable manifest retains policy_request.deny_c in its content identity, checks the declared per-unit native extension closure before creating any target realization, and reports a deterministic root-to-provider import path on refusal. The same finalizer verifies that every binding provider precedes its consumer in the sealed initialization order; runtime startup never repairs dependency order. Production still has to route compiler-derived native claims through the strict manifest lane before this replaces the mixed executable path.

• 2026-07-22 — cart payload retrieval follows the store manifest. A read-only cart-v2 backend now mounts the canonical pit.store.manifest@1 without touching POOL_DATA or ASSET_DATA. Catalog locators select exact hashes; fetching a hash reads and verifies only its declared complete-object range, and locator aliases retain separate rows over one physical asset range. Sub-object requests are sliced after whole-object verification until the binary container supplies manifest-bound range proofs. This keeps the physical metadata-section encoding decision out of the logical store adapter.

• 2026-07-22 — the interning/shapes-off gate follows pool-native shapes. The register loader still realizes portable shape facts into the shared runtime cache, and direct image execution does not yet consume pool SHAPES rows. The switch is therefore sequenced after pool-native shape execution; an earlier flag would test a compiler restriction rather than the target memory model.

• 2026-07-22 — native execution has one policy question. Ordinary start already submits its selected Mach/native form and complete static/dylib provider rows in the aggregate executable_policy request. The unused generic allow message, per-module native question, allow_compile knob, and unused native policy bit were deleted rather than retained as a second authority path. The transition lane can still build a discovered dylib before this decision; strict manifest claims and receipt-authorized native image hashes replace that ordering.

• 2026-07-22 — whole-executable Mach hydration is a transition failure, not a memory-management feature. A 58-unit ordinary compile produced complete exact source/mcode identities and 58 locally present Mach objects, then the development coordinator failed while embed_executable_cached_payloads copied the 37th object into its heap. Direct local-store reads and removal of duplicate verification did not change the failure. The replacement boundary therefore passes only manifest, realization, profile, receipt, provider-registry, and image-hash references into the new actor; the image provider maps/pins each pool there. The legacy hydration, scratch-cement, and supplied pit.executable start paths are deletion targets and will not receive a larger heap or another recursive loader.

• 2026-07-22 — provider adapters require exact code identity. The initial pit.provider.registry@1 row names its Pit adapter only by source locator. That is insufficient for a sealed or offline realization: it under-keys the adapter bytes and would force runtime source/module lookup. Production registry/finalization must name the adapter’s exact executable-manifest hash and root unit; the target realization then maps its complete closure to finalized image entries and unique actor-state instance slots. The Pit runner initializes that closure through the same image/provider machinery before granting the public endowment. The private raw provider remains an unforgeable boot-context value and no C $runtime special case is introduced.

• 2026-07-22 — committed lock bytes are the executable’s lock identity. package_lock.read_lock accepts only the canonical committed lock.json, validates its complete typed graph and requested target, stores those exact bytes in the content store, and returns their content hash. The executable constructor consumes that artifact rather than regenerating selector facts or accepting a mutable in-memory resolution result. Selected version/commit/tree facts are copied into executable package rows; selector and dependency-path provenance remains in the exact lock object.

• 2026-07-22 — compilation projects a small logical graph before payload hydration. While strict mcode claims and resolved bindings are already in hand, the transitional compiler emits root, unit/package/source/mcode rows, initialization order, per-unit claims, and script-to-script import bindings. Native imports remain exact extension claims for the realization provider registry and are not misrepresented as Mach unit instances. The pure executable constructor joins this graph to the committed lock without reopening mcode or copying Mach objects.

• 2026-07-22 — $runtime has one Pit implementation and two temporary constructors. runtime_api.make(raw) owns the public API. The strict runtime_adapter receives the private $provider binding named by an exact provider-registry row. The cart-v1 development shop temporarily reaches the same factory through runtime.cm and the unimportable raw primitive; T007 deletes that constructor when strict actor initialization becomes ordinary.

• 2026-07-22 — native providers are not executable-unit bindings. A logical executable binding row maps one portable import ID to another initialized unit instance. A native import is carried by that unit’s extension claim and resolved by the target provider registry. This distinction fixed strict graph construction for mixed script/native closures and leaves no invented unit row for a C provider.

• 2026-07-23 — development packages use selected workspace snapshots. A development executable identifies every workspace-selected package with pit.workspace.snapshot@1: canonical package/version, exact package-manifest hash, selected logical target arms, and canonical relative source/hash rows used by that executable. pit.workspace.resolution@1 joins those snapshots and the selected typed dependency edges. Published selections remain typed Git commit/tree rows from the committed lock. The two resolution arms are disjoint. Checkout paths, link state, and mtimes remain freshness data, and unselected workspace files do not invalidate an unrelated actor.

• 2026-07-23 — executable root package identity comes from the resolved unit graph. Development construction finds the unit whose exact locator is named by graph.root and uses that unit’s canonical package row. It rejects a missing root unit, an unowned root unit, or duplicate root rows that disagree about package. It does not recover semantic identity by reparsing the root locator’s display spelling. This made canonical package::file eval roots construct the same workspace resolution as ordinary canonical units.

• 2026-07-23 — synchronous request continuations must exist before the request. Pit function declarations become function values when execution reaches them. shop_realize invoked synchronous strict construction before reaching the declaration of its continuation; the callback consequently called an uninitialized closure slot after GC made the timing visible. The continuation now precedes the request. Live Mach symbolization proved the retained closure-slot counts and copying collector were correct, so no VM or C workaround was added.

• 2026-07-23 — claim aggregation is one normalization pass. Executable finalization normalizes each unit’s four claim classes once, adds them to four aggregate sets, and sorts each aggregate once. The repeated copy-and-sort append path was deleted. A 512-claim fixture covers deterministic convergence and duplicate removal without making claim count change the algorithmic shape.

• 2026-07-23 — the T011 bridge has one fresh/cache representation. The mixed executable emitted immediately after a build contains target payload hashes after those payloads are cached. The cache-hit path already hydrated those hashes for the cart-v1 scratch-image walker; the fresh path now performs that same explicit T011 hydration before returning. During the self-host cycle the old coordinator failed once for each newly built seed utility, as expected, until the replacement QOP/cart was sealed. After restart, two deliberately fresh eval executables started on their first attempt; executable artifacts passed 18/18 and construction passed 2/2. This symmetry is part of T011 and is deleted with the mixed executable path rather than retained as a general content-store fallback.

• 2026-07-23 — target execution identities are exact stored artifacts. Immutable runtime build facts, the exact provider registry, and explicit target powers form one stored pit.target.profile@1. The Mach VM/pool contract is a separate pit.mach.abi@1; the producer is a pit.mach.finalizer@1 naming exact implementation/toolchain content and semantic flags. None accepts a checkout path, timestamp, process, or machine identity. Production finalizer construction must still supply the implementation closure hash before ordinary startup replaces T011.

• 2026-07-23 — toolchain derivation is package-content identity. The bootstrap toolchain stamp is a canonical projection of package names, normalized relative file names, exact content hashes, and pass flags. Package input order and checkout paths are discarded; changing a toolchain file changes the stamp. The active boot generation still carries the earlier stamp until the synchronized reseed recorded below.

• 2026-07-23 — development Mach finalization is store-only and module-granular. Given exact executable-manifest, target-profile, Mach-ABI, and finalizer artifacts, the development finalizer consumes each strict mcode unit by its manifest hash, immediately emits its image and origin sidecar, persists a one-unit-per-group link plan and loose layout, and stores each final pool under the hash of its exact bytes. This is the hot-reload layout; closure-fused layouts remain an independent link-plan choice.

• 2026-07-23 — every finalized pool gets an exact origin sidecar. Final Mach PC ranges now carry exact mcode/source hashes, stable function/site IDs, spans, and ordered inline or alternate origins in pit.mach.origin@1. The sidecar is stored by content hash and referenced from the loose pool row. Pool bytes remain stripped and executable without it; debugger and PGO joins retrieve it by exact identity.

• 2026-07-23 — canonical package-file spelling begins at executable sealing. Resolver, filesystem, and compilation coordination retain their useful slash-shaped transport locators. The pure executable constructor verifies that every unit belongs to its already-resolved canonical package, derives its normalized relative path, and remaps root, bindings, initialization, and claims to canonical-package::relative/path. It reads no checkout or shop state. The abandoned coordinator-level conversion and its unused helper were deleted.

• 2026-07-23 — cart freshness includes the exact seed generation. The cart stamp previously hashed the source-input graph and the existing cart but omitted boot.qop, boot/root.cart, and boot/engine_lite.mach, even though those are the cart builder’s direct inputs. A synchronized self-host consequently wrote a current QOP while cement-current accepted a stale cart, leaving the cold coordinator on the prior toolchain algorithm. CART_STAMP_EMIT now includes each exact seed-artifact hash as well as the cart hash. Any changed member forces recement before restart.

• 2026-07-23 — realizer semantics are an explicit derivation input. The strict executable-manifest constructor and canonical package-file identity changed the result of realization without changing source, target, or compiler identity. pit-realize-v6 names that construction contract, so a realization created by the former mixed-executable constructor cannot satisfy the new derivation. This is a cache-key version, not a compatibility reader; old records become unreachable and remain ordinary collectable store data.

• 2026-07-23 — the development shop is the sole realization-index owner. Cement no longer imports a second stateful shop_realize instance. It asks $shop for each exact fleet realization, so the long-lived development shop is the only actor that loads, mutates, and flushes realize-index.json. Read-only fleet selection and content retrieval remain ordinary module calls. This removes the private-snapshot race in which a short-lived cement actor could write new records and the long-lived shop could subsequently replace them with its older snapshot.

• 2026-07-23 — fresh and cached executable values are the same complete value. Per-module endowment attribution is deterministically derived from the exact mcode units already covered by executable identity. It is persisted in the cached executable instead of being grafted only onto fresh replies. The cache projection also retains the executable-claim list rather than silently dropping one identity-covered field. The executable-linker and outer realization-contract salts were advanced so neither cache layer can return an entry produced by either incomplete projection. This removes cart-byte and behavior changes caused solely by whether a realization was cold or warm.

• 2026-07-23 — cart metadata uses canonical passive Wota. Artifact serialization sorts record keys recursively, retains array order, and refuses actors, functions, and active hooks. Cement uses that Pit-level encoder for executable records and plan parameters, so JSON cache round-tripping cannot change cart bytes merely by changing record insertion order. Public Wota keeps its language-level toJSON and replacer behavior; the artifact path is an explicit passive-data operation. The synchronized v8 seed then produced two byte-identical 6,986,576-byte carts across consecutive cold/warm cements: cart content blake2:31c0522bcaa5c71a3abfc4dc6920d550b939b6d538f5b5761d2855c04591e20d, file SHA-256 45c28e242b0ba275cd2bb7548d679f81391938eac7d74779b6e2ad95394da62a. Independent verification re-hashed all 109 Mach objects and matched all 12 executable records to their realization records.

• 2026-07-23 — $args is actor-local engine state, not a target provider. The first strict-start generation classified only constructed engine endowments as engine-owned, so its provider-registry builder asked the static target registry for endowment/args. The replacement classifies the complete engine endowment surface, captures the private target-start packet before executable code runs, and removes that packet from public $args. T001 uses one temporary registry arm for the formerly misclassified actor-local engine names to let the preceding development shop compile this correction. The arm returns only a non-null bridge marker; engine_value remains their sole semantic provider. It is deleted immediately after the corrected shop reseeds itself, followed by a second clean reseed so no final runtime image or profile contains it.

• 2026-07-23 — the first complete origin-sidecar seed has a bounded heap bridge. The preceding boot image canonicalizes a 137,034-site streamline.cm origin map by retaining a separate Pit text for each JSON fragment. Its live set crosses the ordinary 1 GiB actor limit before it can compile the replacement mach_origin module. An attempted T001 crossing temporarily raised the C default to 2 GiB; the old canonicalizer completed enough work to persist an exact bootstrap executable but its copying heap was then killed by the host before it could seal a generation. The final crossing did not enlarge the heap again: it mounted the existing temporary host-reseed QOP, supplied that cached executable directly to the root, and let the isolated bootstrap actor compile current source. The replacement validates fixed-shape producer rows in Pit, skips duplicate-key serialization for the overwhelmingly common single-origin range, serializes keys only for actual alternate-origin sets, copies/sorts function or range arrays only when their order is noncanonical, and writes the normalized sidecar through the JSON grow buffer without a fragment graph. It sealed the complete replacement generation in 42 seconds. Because the ordinary qop tool exposed the separately tracked loose-realization provider defect, a one-shot host packer wrote the uncompressed QOP layout; an independent reader validated all 123 rows, footer fields, path hashes, bounds, and source bytes. No host-packer source remains. The C ceiling is restored to 1 GiB and that generation cold-boots the complete fleet without transition variables. The temporary host QOP and request records remain only until the provider correction enters a clean generation produced by the ordinary Pit QOP packer.

• 2026-07-23 — native-import manifest bridge. Portable mcode correctly records an import request without deciding whether its resolved provider is Pit or native. The preceding boot generation’s executable-manifest finalizer nevertheless requires native providers in the importing unit’s claims.extensions. During T001 only, shop_build mirrors each exact extension-binding provider into that legacy claim projection so the old finalizer can seal the replacement generation. The replacement finalizer derives native authority and deny_c paths from exact extension-binding rows; the mirror is deleted before the clean verification reseed.

• 2026-07-23 — executable-claimed startup values remain actor state. The start-plan walker had already trimmed the boot context to its baked claim set, but the Pit engine’s finish hook then erased public claimed values including $args. Asynchronous root service startup consequently lost the runtime profile, ABI, target, paths, and daemon endpoint. The finish hook now always removes private loader capabilities, preserves the C transition walker’s already-trimmed public context, and trims strict realizations to the exact per-unit global/endowment names they installed. A one-cycle T012 bypass compiled the correction and was deleted after the corrected image cold-booted.

• 2026-07-23 — code and extension imports occupy one dense namespace. Executable finalization assigns one dense import range per unit across both script and native providers. The Pit realization runner and transition engine runner preallocate that exact range, fill code and extension rows by ID, and refuse holes, duplicates, or out-of-range rows. This fixed the observed compiler unit whose code imports were 0..6,8,10 and extension imports were 7,9; append-shaped array growth had reached key 8 at length 7.

• 2026-07-23 — strict image text and final target Mach have one runtime representation. Generation B cold-booted the complete development fleet without the image-text, lexical-claim, or mutable-implementation environment switches. Current source requires canonical prehashed image text, computes a missing image hash without writing through read-only stone, requires finalized target Mach at start, and has no mcode_lower.cm start-time lowerer. The corresponding environment branches and lexical bridge were deleted.

• 2026-07-23 — execution identity is verified actor state exposed only by $runtime. After the engine verifies the executable, profile, realization, provider registry, policy request, receipt, and their cross-links, it stones {realization_hash, executable_hash} into ordinary actor realization state. The exact runtime module or adapter consumes a one-shot Pit accessor during initialization and $runtime.execution_identity() returns an immutable projection. Request records cannot supply either field, $args carries neither field, and no C getter or process-wide registry participates.

• 2026-07-23 — the fleet catalog now names realizations; portable pitpacks remain independent. The seed producer and QOP consumer use pit.target.realization@1 catalog objects, verify the complete linked manifest/profile/ABI/provider/policy/pool/origin closure, and construct only backend-local placement packets at mount time. Legacy executable service branches were deleted. These target-specific QOP contents are a transitional self-host output; the ruled pitpack carries portable mcode and is mounted independently of the root cart. Bundle signatures optionally authenticate publisher provenance and do not grant execution authority. The next boot step is a thin development root with local policy and bootstrap-finalizer responsibilities, plus a recovery-complete portable dev pitpack whose full compiler and services are locally realized. The generation-B policy program’s legacy mixed identity must be crossed truthfully during that reseed; no newer policy identity or receipt authority is synthesized.

• 2026-07-23 — the root cart carries target bootstrap configuration, not pitpack trust. Cake projects the exact post-probe/post-trim rows that generate the linked static provider table into a canonical pit.bootstrap.target@1 asset at pit.bootstrap::target.json. The record carries content-addressed Mach-ABI and finalizer artifacts plus exact local policy program/configuration identities. Its development policy authorizes the exact fixed development-fleet locators, Mach execution, and available claimed endowments; it grants no native execution and contains no QOP or pitpack identity. The cart reader resolves and range-reads the asset in Pit. T014 truthfully labels the temporarily available linked-runtime build projection as a derivation input until the bare runtime content hash becomes available earlier in the pack order.

• 2026-07-23 — runtime authority stays capability-shaped. $vm was folded into the single policy-granted $runtime provider. Scheduler snapshots carry the actual opaque actor token beside display facts; runtime tools select a row and pass that token rather than reconstructing one from an ID. Source tools no longer consume the public token constructor or logger-ID setter: actor shell creation returns its token to the Pit root, which retains it, and the root recognizes a live logger program and invokes a private token-taking boot primitive. The current C actor record still registers actor.ref and set_logger_actor solely for T016’s already-built boot generation; S013’s atomic split and the authority gate delete both rows. Actor-local log-selector state remains in the Pit engine and its control moved from shop proxy messages to $runtime. The engine captures the actor key from its private boot context and clears both historical context spellings before initializing any executable unit, so a global claim cannot recover it. The fixed development policy actor now starts first; the former bootstrap allowlist is deleted and the remaining fixed services start only after local policy is live.

• 2026-07-23 — actor display lookup is one Pit $runtime rule. runtime_api.select_actor selects an exact scheduler snapshot row by full actor ID, canonical display name, or short display name, then by a unique prefix. Ambiguous names and prefixes are rejected instead of granting the first row encountered. Terminal, heap, live profiler control, stop, per-actor trace, and ps info deleted their independent lookup rules and pass the selected row’s retained opaque actor token directly to $runtime. List filtering remains presentation-only. This is a permanent Pit-side consolidation, not a generation bridge.

• 2026-07-23 — VM benchmark counters are private $runtime facts. Cumulative VM/allocation/GC snapshots, the instruction-counting gate, and per-opcode counts moved out of the public actor module and into the private runtime primitive consumed by runtime_api. The Pit API forwards these three self-only primitives directly: adding a Pit presentation wrapper would execute Mach instructions and allocate inside the interval being measured. All tests and benchmark tools now claim $runtime; there is no actor alias or generation bridge. Compiling the counter arrays and dispatch hook out when the provider is absent remains the separate P8 player-stripping gate.

• 2026-07-23 — profiler semantics and raw-stream authority are Pit-owned. Scheduler C retains bounded timer/safepoint measurement, turn counters, and raw frame-coordinate capture. $runtime.profile_set copies the calling profiler actor’s ID into the selected target as its one raw sink and returns the target’s capture generation. The scheduler sends raw measurements directly to that actor; it publishes no logger channel, so the logger’s intentionally open subscription API cannot bypass $runtime. Replacement, clear, sink loss, and actor destruction invalidate or free the copied sink, while delayed messages are rejected in Pit by generation. profile.ce owns target/module selection, adaptive/session and slow-turn policy, presentation, and optional persistence. profile_present.cm joins IMAGE facts to exact origin sidecars and creates native leaves in Pit. A missing sidecar is retryable because only successful immutable loads are cached. C carries no profiler session, persistence flag, slow threshold, source-line resolver, name formatter, or semantic module filter. This is the permanent $runtime boundary, not a generation bridge; cake-selected player stripping remains the P8 completion gate.

• 2026-07-23 — runtime debugging has no ambient C callback API. The unused public call/return/GC callback system, process-global and per-actor turn callbacks, their PitContext fields, and their branches in Mach calls, C calls, GC, and scheduling were deleted. $runtime pause, step, raw stack, trace, and profiling control do not depend on them. The Pit debugger now follows an IMAGE pool hash through the developer content catalog to its exact origin sidecar and, when the exact source object is present, attaches the mapped source line; absent source leaves the immutable source hash and span available. This is a permanent simplification, not a generation bridge. P8 adds only the private cake-selected observation arm needed by hot reload and compiles it out with the $runtime provider in player builds.

• 2026-07-23 — policy configuration is the development fleet’s readiness edge. The successful reply to the policy actor’s ordinary configure message is the single point that installs the policy reference, releases queued shop messages, and starts daemon/logger/courier/builder/terminal actors through the root’s checked start path. The redundant unsolicited policy_ready message and its race with configuration were deleted.

• 2026-07-23 — absent policy configuration grants no authority. Execution-form gates require their corresponding allow boolean to be exactly true; unknown forms are refused. Missing or malformed default-endowment configuration begins with an empty grant, while the development policy keeps its broad behavior through explicit allow booleans and an explicit ["*"] claimed-endowment grant. The former missing-default grant-all fallback was deleted. This is a permanent policy rule, not a generation bridge.

• 2026-07-23 — realization freshness cannot hide a missing immutable closure. A cached realization is reusable only while every source and mcode object named by both its exact dependency rows and the candidate cached executable’s own module/manifest rows is retrievable from the content-store stack. The candidate executable, rather than the deletable freshness index, is the acceptance authority. Path/stat freshness is checked only after that closure condition. A missing object invalidates the cache record and the ordinary compile path re-ingests the current source, publishes its source blob before consulting the mcode derivation catalog, and republishes its derivation; the focused cache test removes one generated source object, observes an invalidation/rebuild under the same content hash, and then observes the repaired cache hit. Seed and bundle writers remain strict and never reconstruct absent bytes from display paths.

• 2026-07-23 — executable identity is a canonical derivation. The exact identity seed is serialized through the same canonical JSON encoder used by other semantic artifacts before hashing. A focused source-object repair run exposed the former insertion-order dependency by producing two cache executables whose semantic graph, module rows, and manifest rows were byte-for-byte equal while their identity hashes differed. Canonical encoding makes repeated construction under the same semantic inputs select one cache row; no legacy identity probe or alternate key is retained. The adjacent realization, target-image, mcode, executable-manifest, development package graph, and recipe derivations use the same canonical rule. Constant fallback dedup also compares canonical values, so record construction order cannot retain duplicate stone values. The unused pre-sidecar debug-reference projector was deleted rather than preserving a second debug identity path.

• 2026-07-23 — startup binding refusals name the exact physical row. A failed PoolBinding operation reports the importing image and IMPORTS row; code bindings also name the provider image/entry and extension bindings name the provider locator. The diagnostic exposes already-authorized realization coordinates only and does not add a second binding path.

• 2026-07-23 — native providers cross the canonical locator boundary before executable construction. Native resolution now records package::relative/path as the provider key used by static bindings, extension claims, executable-manifest extension rows, target realizations, and provider registries. Executable construction accepts only that canonical shape. T019 records the bounded self-host crossing needed before this permanent invariant can become active in the cold-start engine.

• 2026-07-23 — portable bootstrap authorization binds roles, roots, limits, and origins. The thin-root policy configuration pairs each allowed development-fleet locator with the exact canonical root locator its executable manifest must name. Local finalization carries the executable’s requested limits through request, receipt, realization, and actor start, stores its derived semantic artifacts in the local CAS, and retains one exact Mach-origin sidecar row per module-granular image. A content catalog therefore cannot repoint an allowed boot role at another program, and the portable boot lane preserves the same debug/limit facts as an ordinary development realization.

• 2026-07-23 — bootstrap implementation identity always has bytes. The root-cart producer projects the exact compiler, Mach-finalizer, and local policy closures from the root executable graph into canonical closure records. pit.bootstrap.target@1 carries those records beside their cross-linked hashes, and the bootstrap realizer verifies and installs each standalone record in the local content store before it derives any target images or receipt. This is a permanent content-store invariant, not a transition: a bare implementation hash is insufficient bootstrap metadata.

• 2026-07-23 — bootstrap closure records cross the canonical locator boundary once. The thin-root producer passes its resolver graph through the same strict package::file projection used by ordinary executable construction before selecting the compiler, Mach-finalizer, and local policy closures. The resulting exact {hash,value,bytes} artifacts flow unchanged into pit.bootstrap.target@1; cart cement no longer discards them and attempts a second projection from resolver-spelled locators.

• 2026-07-23 — policy program identity is typed at every boundary. Policy identities, requests, receipts, target-start packets, QOP object catalogs, loaders, and the engine carry and verify program_kind beside the program hash. Ordinary policy names pit.executable.manifest@1; thin-root bootstrap policy names pit.bootstrap.policy.implementation@1. No loader infers one from the other, and the typed policy-program artifact is an explicit member of every sealed start closure.

• 2026-07-23 — portable bootstrap acceptance has an independent bounded verifier. The read-only host verifier checks the canonical store-manifest identity, exact physical object set, BLAKE2 bytes, canonical byte lengths and kinds, catalog variants and roots, and every executable’s source, mcode, resolution, package-manifest, and workspace-snapshot closure. It refuses Mach pools, target realizations, receipts, native images, and other target-final objects in the development pitpack. Assets and portable debug/PGO sidecars are verified and inventoried when the selected profile includes them; the verifier does not synthesize categories the profile did not select. During this workspace crossing, a typed path-free workspace resolution plus exact package snapshots is the development selection artifact; a published closure instead requires its typed package lock. This does not close P6’s committed-lock work. The same verifier parses the root cart structurally and proves its embedded engine window is byte-identical to the separately emitted engine_lite.mach, and can compare an unpacked content tree with its independently packed QOP by manifest identity.

• 2026-07-23 — the uniform store manifest is an exact typed byte declaration. Every pit.store.manifest@1 object row carries a nonempty semantic kind and a nonnegative integral canonical byte length. Roots and catalog references name declared objects; variant catalogs use exact, nonempty rows with unique canonical selectors. A layered manifest accepts an overlapping content hash only when its semantic kind and canonical byte length agree. Backend-local transport and placement metadata may differ; the first layer’s retrieval metadata wins. The completed merge is validated before publication. QOP and closure verification compare the declared byte length with the hash-verified object before accepting it. The S007 pit.bundle@1 crossing remains explicit, but its writer now derives exact lengths from the already verified closure bytes and its adapter projects declared variant roots through the same strict validator. The former {kind}-only rows, bare catalog text, undeclared roots, duplicate selectors, and first-wins conflicting metadata are rejected rather than repaired or inferred.

• 2026-07-23 — T017 binds the legacy compiler to its exact manifest and rejects unprimed derivations. The first hardened catalog-backed producer wrote its engine and cart, then correctly failed to derive an exact loaded compiler closure: Generation B’s plan start has no verified realization packet, so $runtime.execution_identity() truthfully returned null. For the one remaining T011/S004 crossing, resealing transforms only the exact catalog-selected pit-shop/development_shop executable: it places that executable’s already stored pit.executable.manifest@1 content hash in one reserved policy-param row and publishes the transformed bytes as a separately hash-verified object in the transition QOP. Generation B’s existing cement writer places those executable-owned params in the sealed start plan. The transition reader erases any requester-context spelling of the private key, accepts only a syntactically exact content hash from that plan-owned payload, and projects it into $args.context. The bootstrap shop_realize module captures and clears the field from public $args, rehash-verifies the stored manifest, and uses it only when the strict $runtime identity is absent. No generic realizer output or semantic cache entry carries the field. External start-request identity fields remain ignored and no realization hash is fabricated. This plan reader, field capture, and one resealed transition object are deleted with T011/S004 after the first strict target-realization successor cold-boots. Generation B’s already-baked plan also predates the private $pit_runtime_identity engine value and classified it as a required host endowment. One narrow T017 reader exception permits only that absent private value on the legacy plan. runtime_api consumes null there; strict target execution constructs the exact value in Pit after artifact verification. Generation B also misclassified the later private runtime-control and logger values; before consulting the host registry, the transition reader projects exactly those two names from the Pit engine record when present and otherwise leaves them null only for this one legacy service. The projection and identity exception are deleted with the T011 C plan reader. Independently, locator priming now propagates a missing exact compiler closure as failure before context construction or cache lookup; realization context and status contain only the exact compiler content hash. The former toolchain:unprimed cache key and success-after-failed-prime path were deleted.

• 2026-07-24 — the T017 producer’s actor budgets are crossing-only. The catalog-selected bootstrap actor is first created idle, then the isolated predecessor applies a 65,536-frame stack ceiling and a 100-strike watchdog allowance before delivering the ordinary {type:"bootstrap"} mailbox value. No request field, executable identity, pitpack object, cart row, or global runtime default carries either value. This crossing was established from two rejected attempts: the unadjusted actor disrupted at depth 1024, limit 1024, while a 65,536-frame actor remained healthy in the optimizer but was stopped by the default third 60-second slow strike. The adjusted producer was observed alive at strike four with a healthy heap. The mailbox injection and debugger-mediated budget adjustment exist only because the predecessor terminal cannot address this transitional actor reliably; they are not an execution or realization path. While compiling the 5,200-line optimizer unit, the producer’s exact live set reached about 390 MiB and its copying heap grew to 512 MiB. The isolated actor’s heap ceiling was therefore raised from 1 GiB to 4 GiB before the next demand-driven growth boundary; this does not preallocate memory or change a runtime default. A precautionary copy of the same limits was applied to the isolated predecessor builder worker before development content began, but scheduler evidence later proved that worker received no request: the old root became quiescent before its first discovered batch. Portable fleet construction now remains in the bootstrap actor which already owns the compiler and output transaction, so no second crossing budget is part of the successful path. Delete the mailbox injection and bootstrap actor budget adjustment with T017 after the portable output passes the independent verifier and cold-boots a successor. Permanent bootstrap work selects its policy-authorized actor limits in the sealed executable/start configuration and long compiler passes yield cooperatively; neither outcome grants a general watchdog bypass.

• 2026-07-24 — T017 retries retain only verified content and expose producer defects instead of repairing outputs. The first budget-adjusted producer compiled the current closure through Mach finalization, then rejected mach_origin.cm: Pit declarations inside while bodies were outside the language grammar. Its replacement hoists and reuses those loop locals. A second pass rejected the module’s short internal/crypto import; the source now names the canonical core/internal/crypto provider. Both actors stopped without an accepted output, while their independently hashed mcode and Mach objects remained reusable in the isolated CAS. The next pass wrote root.cart and engine_lite.mach before development-content construction refused an unavailable exact compiler closure; those two files are a rejected partial publication and are never packed or accepted. The sealed development-shop manifest itself was present, hash-valid, and contained the canonical compiler unit. The defect was store activation order: shop_realize queried its actor-local layered store before that actor had mounted the seed pitpack that supplied the manifest. The permanent reader now initializes its verified store layers before resolving the exact executable-manifest hash. The cold seed_fleet regression now makes shop status its first command and requires the exact tagged toolchain hash before any unrelated locator request can prime that actor’s layers. The already-running predecessor module cannot hot replace that function, so this one crossing copied only the same 62,370-byte manifest into its writable CAS after verifying blake2:4db4ce89fce964a49fc557363e123f585e439e6e8affe7ece3061483324e40e6. The retry still derives the compiler closure from those exact bytes; it gains no locator fallback, mutable-file identity, or synthesized toolchain stamp. That legacy root then became completely quiescent at the first cooperative development-closure discovery yield: every actor and scheduler queue was idle, the builder had received no request, and no error or disruption was emitted. The already-written root cart and engine remain valid exact outputs, but the incomplete content directory is rejected. An attempted intermediate runner appended that root cart, first alone and then with the same verified transition pitpack; both new roots initialized their sealed callback tables and then became quiescent before starting services. Those runners and shops are rejected and never become producer or acceptance artifacts. The permanent bootstrap simplification below replaces that attempted crossing; no intermediate-root fallback or extra self-host cycle remains in the accepted path. The permanent producer consequently no longer sends portable fleet builds through $shop. shop_build prepares each mcode executable and invokes the ordinary strict development-manifest constructor in the bootstrap actor, with the same target and {execution_forms:["mach"], limits:{}, deny_c:false} request. The removed root message and its 1,800-second reply timeout carried no semantic input; eliminating them leaves exact source, mcode, workspace resolution, package snapshot, and manifest identities unchanged while making bootstrap independent of a predecessor root’s live scheduler state. The first actor carrying that simplification wrote its exact root cart and engine, then stopped immediately after entering portable content without producing a content directory or an error/disruption record. That partial output is rejected. T017 temporarily exposes one message-only content_only retry in internal/bootstrap.ce and shop_build.bootstrap_content_artifacts: a fresh actor reuses the independently verified target-private files and runs only the portable content transaction, with per-root phase logs. There is no CLI flag and no accepted runtime surface. The predecessor’s cached internal/bootstrap program did not observe the new selector and began another full engine pass; that duplicate actor was halted through the runtime’s thread-safe actor_halt and its output is rejected. The root also correctly refused a newly named retry actor because this predecessor has no development actor and the program was absent from its sealed catalog. A first canonical relay placed a private selector in internal/bootstrap.ce, but that program loads its compiler/build dependency before dispatching the selector and therefore overflowed the relay actor’s default 1,024-frame stack. Its output is rejected. A second tiny canonical relay was also rejected because its new locator was correctly absent from the predecessor’s sealed catalog; that file is deleted and never enters an artifact. The actual crossing reseals the catalog-selected legacy bootstrap executable with only its already-recorded one-generation producer limits in policy.params: 65,536 stack frames, a 4-GiB heap ceiling, and 100 slow strikes. The executable object becomes blake2:c7f6aa3aefa5cc8d2b752f4810211d3c6f68981398718c23f06cfa6e03430190; the legacy envelope, every object row/member, the standalone QOP, and the appended runner were independently rehashed. The exact resulting QOP is blake2:704b70cd3ef426fafb68e282111b346d01d72b29e7fe4fca1b7223ab9719720a and its appended runner is blake2:feb6fb7e7bb46bed533cb0b772a9abd61699cf5647327a5c54eff3199632be39. No supplied executable, new locator, request-time limit, policy fallback, or actor-admin setter participates. Delete the retry entry point, selector, state, phase-specific diagnostic logs, sealed limits, temporary QOP/runner, and any catalog reference immediately after the complete pitpack independently verifies and cold-boots its successor.

• 2026-07-24 — T017’s sealed strict-manifest identity precedes only the legacy semantic executable identity. A first reseal added the exact current compiler closure and its producer budgets but omitted the already-designed manifest field; the compiler correctly refused to derive a toolchain from an unidentified loaded implementation. A second reseal carried the compiler’s hash-verified pit.executable.manifest@1, but exposed a narrower crossing defect: the legacy start reports its semantic executable hash through $runtime, and shop_realize accepted that syntactically valid hash before consulting the plan-sealed T017 manifest hash. The semantic object is not an executable manifest, so initialization again refused. Both QOPs and shops are rejected. During this one crossing, a syntactically valid pit.t017.host_executable_manifest captured from the sealed plan takes precedence; when that field is absent or malformed, lookup is unchanged and uses only the strict runtime execution identity. Focused regressions cover all three cases. Delete the selector function, its temporary export and test, the plan-param reader, and the captured field together when T017 closes.

• 2026-07-23 — the recovery-complete development fleet roots on-demand actor facilities. Importing the git client module into the development shop did not package the separately started git/git_worker actor, so an otherwise healthy cold transition reached package acquisition and could not resolve the worker. The standard portable fleet now catalogs the exact Git worker and Pit debugger executables alongside its eagerly started services. The independent pitpack verifier requires every standard development-profile catalog root and verifies every selected executable’s complete portable closure. The T001 local workspace mount remains crossing-only producer input and is absent from accepted carts and pitpacks.

• 2026-07-23 — the cart bare-runtime root has one semantic object kind. Cart manifests declare the exact linked runtime bytes as runtime-image. The cart validator requires that kind for its runtime system root, so an arbitrary blob cannot satisfy the provider/runtime identity by hash alone. The pre-link derivation-input record remains a different bootstrap stage and is replaced by the bare-runtime content object before cart publication.

• 2026-07-23 — allocation-site sampling is capture-owned. New actors begin with allocation-site attribution disabled. The runtime no longer reads PIT_ALLOC_SAMPLE_BYTES; a policy-granted $runtime.profile_set capture installs its exact interval, including zero, and clearing or replacing the capture restores the actor’s prior setting. The remaining player-profile work removes the compiled sampling branch entirely.

• 2026-07-23 — an explicit console emulator run is an acceptance gate. SDK-less ordinary PS1/N64 builds continue to self-skip, but setting PIT_PS1_RUN=1 or PIT_N64_RUN=1 makes the requested toolchain, emulator, timeout mechanism, and guest completion mandatory. The bounded emulator process normally ends by host timeout, so its exit status is not the guest result. A shared capture verifier instead requires the exact successful harness marker, or both the exact profile-specific hello done marker and the scheduler’s fleet-completion marker. Fleet acceptance additionally requires the stock 4 MiB N64 report or retail 2 MiB PS1 report, so a successful diagnostic run on expanded hardware cannot satisfy the shipping gate. Missing tools, a boot diagnostic without sample completion, an empty capture, and the former N64 fleet search for the harness-only capacity: marker all fail the command.

• 2026-07-23 — the console player gate names the native facade as deletion, not capability. source/qbe_stubs.c exists only to keep the old native dispatch and public loader surface linkable on targets that cannot supply a native payload runtime. It is not a PS1/N64 provider. The P4 readiness gate remains red while either player manifest contains it; after the accepted successor crosses S012, the unavailable dispatch/API path and its stubs are deleted together rather than shipped as a disruptive fallback. The same gate rejects the public os path/symbol loader and its boot_dylib_* facade in both platform modules, plus the target sys_dylib_* failure stubs. Necessary system facts remain after those unrelated members are split away.

• 2026-07-23 — actor authority splits only after the canonical runner. S013 does not add another private-provider claim to the cart-v1 engine record. After S004/S006, C exposes one unimportable boot primitive which engine_lite captures and clears before unit initialization. The engine derives a root-only atomic create/configure/boot provider and a courier-only serialized-delivery provider; the public actor module retains actor-self operations only. Atomic construction must remove an unpublished shell after any configuration refusal, eliminating the current partially configured starting_actors residue. Delivery performs one checked operation and uses its delivered/dead result rather than a mailbox-existence precheck followed by a racy push.

• 2026-07-23 — receipt-selected actor limits are ceilings. Public actor-self heap, stack, watchdog, and timer adjustment may retain tightening operations, but cannot relax limits authorized by the policy receipt. Root construction applies the exact receipt and provider-selected execution lane; request fields cannot override either. Runtime-wide diagnostic or policy control remains under $runtime or the root policy rather than benchmark-oriented public actor authority. A13’s later removal of process-global contact rows remains separate: the replacement for exporting this runtime’s own public contact descriptor is ruled when A13 is implemented, without retaining the other S013 public administration rows.

• 2026-07-23 — debug presentation joins hashes after raw capture. The allocation-free IMAGE coordinate remains a fixed pool/function/PC fact plus executable, realization, and unit-instance identities; it does not carry a locator, source name, parsed sidecar, or activation object. Pure Pit now verifies the realization and executable objects by those hashes, proves the unit-to-image row, and only then presents the canonical locator and exact source-content span. Optional variable names use a separate pit.mach.slots@1 sidecar whose non-overlapping PC ranges describe slots after final allocation. The current compiler debug sidecar contains source locations but no durable variable-to-final-slot lifetimes, so no names are inferred: publishing that map remains a producer task. The current realization format gives the join enough identity for main-executable units only. P3’s adapter cutover must add the owning executable and executable-local unit ID to each dense instance row before adapter frames use this symbolizer; no index equivalence is inferred in the meantime. The debugger’s pool disassembler independently verifies and parses the stored pmp1 bytes, retains every numeric instruction word, and joins origin/slot sidecars when available. This decision removes caller-supplied symbol maps and keeps player pools executable when all developer sidecars are omitted.

• 2026-07-24 — the actor-authority cutover has one static deletion gate. The active reseal still depends on the mixed public actor record, so its C table and live boot consumers remain unchanged until the accepted cold successor. Once the crossing’s complete workspace input was frozen and hash-verified independently, source-dead rows could be removed from the next generation without changing the running predecessor: register_image, register_actor, the engine’s unused non-silent mailbox_push capture, and the now-unreachable cement-to-RAM scratch-image registry are deleted in the live tree. The still-used public administration and courier rows remain for the atomic S013 split. scripts/check_actor_authority.sh audit records every remaining public administration row, process-global contact field, and Pit consumer without treating that state as compatibility. Its --gate mode becomes mandatory at the S013/A13 cutover. The audit also found benchmark programs increasing their own watchdog budgets through cross-actor setters; those limits move to selected start policy before the setters disappear. Runtime contact becomes courier/root state: each new engine receives its local runtime key and retained courier token explicitly, while changing address, port, and transport observations flow from courier to root by message. internal/runtime_contact.cm prepares that actor-owned state and its immutable engine-routing projection without changing the active bootstrap closure; its focused test covers malformed updates and fixed runtime identity.

• 2026-07-24 — provider lookup has one identity per namespace. Static extension lookup accepts only the generated canonical extension key; the C symbol remains implementation metadata and is no longer a second lookup name. Endowment-descriptor lookup accepts only the source-level logical $name; endowment/name and bare name are not aliases. The focused C policy test asserts both positive identities and every removed spelling. These source changes were made after the crossing snapshot was frozen and syntax-checked immediately; the live cart-v1 binary is intentionally not rebuilt with them because its transition walker still passes symbols. Full execution validation occurs in the first v2-only rebuild, after S004 removes that walker rather than teaching it another name.

• 2026-07-24 — the permanent provider catalog begins at the bare runtime identity. Cake’s pit.provider.catalog@1 constructor requires the exact pre-tail runtime-image content hash and derives every static implementation ABI from that hash, the canonical lookup key, and the typed static entry. Each row separately retains its logical endowment or canonical extension locator, implementation kind, build lane metadata, and exact portable adapter manifest/unit/private binding when present. This is the cart/system artifact from which Pit selects closure-specific registries. The older pit.bootstrap.provider.catalog@1 remains confined to T014’s derivation- input bootstrap record and is deleted with that crossing; it is never accepted as the permanent runtime catalog.

• 2026-07-24 — the host build now exposes its pre-tail runtime to the producer. make seed and make seed-ship pass Meson’s untouched build/pit output through the private bootstrap request as runtime_image; the separately copied top-level pit may already carry a cart/pitpack tail and is never used as T014 input. This establishes the permanent ordering boundary without hashing a path into artifact identity. The v2 bootstrap producer must read and content-hash those bytes, construct the permanent provider catalog from that hash, and feed both to the flat root-cart assembler. The field is presently inert in the v1 producer and is deletion-neutral; T014 remains active until the derivation-input catalog arm is removed and the first v2 cart verifies the exact runtime bytes.

• 2026-07-24 — flat root-cart assembly consumes only exact target artifacts. The v2 root assembler takes one verified pit.target.start@1, exact bare-runtime and pit.provider.catalog@1 bytes, and one first engine_lite pmp1 identity. It fetches remaining pools, origin sidecars, and policy configuration only by content hash, assigns deterministic metadata, resident-pool, and cold-asset ranges, and then calls the canonical cart manifest and pcr2 writer. It does not discover modules, repeat policy, or interpret actor initialization. The thin development root cart embeds no service realizations; those arrive from the independently mounted portable pitpack. Production activation remains gated on the clean crossing, first engine-pool finalization, T014’s bare runtime ordering, and the atomic v2-only reader cutover.

• 2026-07-24 — direct images use self-relative immutable record shapes. A pmp1 SHAPES row is the record’s descriptor: its common 24-byte prefix names the immutable IMG1 kind, field count, canonical hash, and signed self-relative SHAPE_KEYS range. Each ordered key row resolves its canonical STONE text by another checked self-relative offset and carries the target key hash. The VM therefore creates dense records directly from pinned image bytes without consulting a runtime registry or adding per-shape binding state. The DYN1 descriptor tail remains only for decoded Mach and native record templates: its runtime-cache link, PGO token, and inline keys are deletion-bound with the cart-v1/decoded-Mach loader and its native template bridge. It is not a fallback representation for image execution. That deletion removes PitRuntime.shape_*, pit_record_shape_intern, decoded Mach shape resolution and its runtime-meta rows, decoded PGO’s shape-token walk, the QBE AOTRecordTemplate resolver/primer, and the corresponding scheduler/introspection counters and cache-only tests. Host and nan32 builds, direct-image execution, record GC survival, image lifetime, and representation ABI tests pass. The pure-Pit finalizer test is crossing-gated: ./pit --shop .pit test tests/mach_pool_emit.cm currently stops during predecessor boot with image provider open: pool STONE is not a complete canonical text sequence, before the test module is loaded. This is mixed-generation shop evidence, not a failure of the new finalizer; rerun that exact test with the first accepted cold successor.

• 2026-07-24 — ordinary dynamic C-string property keys are actor-owned. Pit_SetPropertyStr now creates every non-builtin key as a rooted actor-heap text and canonicalizes it only through that actor’s weak intern table. Two actors in one runtime therefore retain distinct key values that compare equal by content; tearing one actor down cannot affect the other, and property creation or lookup does not change the runtime constant-text count. Compact profiles still recognize only the fixed immutable builtin key bank before allocating the actor value. The nan64 and nan32 text/record tests cover ownership, content equality, forced GC, peer teardown, fixed builtins, and unchanged runtime CT accounting. This is the first D8/A1 cut, not permission to retain the global pool. pit_key_new, pit_key_new_len, and Pit_NewAtomString remain deletion-bound because decoded Mach still materializes constant pools, shapes, and function names through them; the native bridge still builds literal pools, C-string key caches, and DYN1 templates through them; and runtime-global C-function/intrinsic definition objects still require off-actor names in the current bridge. The direct callers and their ABI/ cache fixtures were audited and intentionally left unchanged. Delete those consumers with parsed Mach, native templates, and shared C-definition construction, then remove dynamic compact key lookup and the mutable CT allocator/hash/array/count together.

• 2026-07-24 — resident Mach adoption is a permanent provider primitive. The private image provider has one non-file entrance for immutable pmp1 bytes already placed by a cart mapping, ROM window, or resident-RAM loader. It verifies the exact artifact hash and asks Pit_MachPoolOpen to verify the target profile, Mach ABI, checksum, section bounds, and pool rows once, then records a borrowed MachImageView. Duplicate opens of the same declared physical placement share open/pin/binding refcounts with mapped images; later operations neither map, copy, nor reparse the range, and final close never frees or unmaps caller-owned bytes. This seam remains after the crossing because address placement and lifetime are irreducible platform operations, while placement selection and startup semantics stay in Pit. Host and nan32 tests cover rejection, duplicate adoption, balanced close/ pin/GC ownership, and post-disposal caller access. The production hookup is deliberately not another provider path: P3.8’s v2-only bounded cart reader must feed its verified first POOL_DATA range and identities into this entrance and pass the resulting opaque handle/pin to engine_lite.

• 2026-07-24 — the bounded pcr2 cold reader stops at the first resident image. The successor-only source/cart_v2_boot.c validates the linked runtime’s exact Mach-ABI hash, target byte order, fixed header/directory/ trailer bounds, directory checksum, duplicated payload-checksum closure, internal target-profile agreement among the cart, BOOT row, and first pool, first POOLS and PLACEMENTS rows, exact engine-pool artifact hash, complete pmp1 structure/checksum, and engine entry/unit. It returns only fixed section ranges and the checked physical first-pool view; its adoption helper passes that borrowed range and exact identities to the permanent image-provider entrance. It does not parse the manifest or interpret realizations, policy, claims, services, providers, imports, or initialization order. Cold start deliberately does not recompute the whole-container payload checksum: doing so would page through METADATA_DATA and ASSET_DATA. Pit publication/offline verification owns that full scan, while mounted store reads verify each requested object’s exact content hash. The cold reader verifies every byte it consumes, and its host and nan32 tests corrupt ASSET_DATA to prove it remains untouched. The helper is not in the v1 runtime manifest. The one atomic hookup replaces source/cart_boot.c and its v1 accessors with this reader, supplies the generated linked profile/ABI identities, adopts and pins its returned engine range after runtime creation, enters the declared image entry, passes the opaque cart/image handles to engine_lite, and deletes v1 discovery, fallback, parsed-Mach registration, and start_plan.c in that same successor generation.

• 2026-07-24 — pre-entry safety is the Mach ABI; the target profile names the permanent catalog. pit.mach.abi@1 is the one complete execution- safety artifact linked into C: instruction ABI/name, pool schema/version, endian, value/reference representation, object header/layout, numeric/text/record representations, stone contract, and module-result import opcodes. The target profile’s providers field is the exact permanent pit.provider.catalog@1 hash derived after the bare runtime is linked and hashed. Each policy request and target realization separately names its closure-specific provider registry, and startup requires registry.provider_catalog == profile.providers. Cold C therefore validates the linked Mach-ABI hash and cart/BOOT/first-pool agreement on one target-profile hash; engine_lite authenticates the full profile, catalog, registry, powers, policy request, and receipt before further execution. This ordering removes the bare-runtime/catalog/profile circularity with one execution-ABI artifact. The bounded reader already has that API and validation split. Its atomic P3.8 hookup must generate/link the complete Mach-ABI identity, preserve the internal profile-agreement check, and leave full profile validation in Pit.

• 2026-07-24 — the flat root cart reserves its bootstrap-target locator. root_cart_v2 now requires the exact canonical pit.bootstrap.target@1 artifact that the root shop will use to realize the independently mounted portable pitpack. It places those bytes as the cold pit.bootstrap::target.json asset, rejects a caller-supplied row at that locator, and verifies that its target system, Mach ABI, policy program, and policy configuration agree with the root start packet. This closes the gap in which the v2 assembler could emit a valid first actor but omit the finalizer/policy configuration needed to construct the rest of the development shop. The asset has no pitpack or QOP identity.

• 2026-07-24 — the bootstrap producer writes the v2 root artifact. shop_build.bootstrap_artifacts hashes and stores the exact pre-tail runtime, constructs its permanent provider catalog, builds the shop actor as a strict portable executable manifest, realizes that manifest through bootstrap_realizer, finalizes engine_lite into a direct pmp1, and feeds those exact artifacts to root_cart_v2. The publication transaction writes only root.cart; after the complete root/content transaction succeeds it removes any stale engine_lite.mach. The former cart-v1 root producer and loose engine compiler are no longer selected by this path. This is the producer half of the cold crossing. The produced engine retains its explicit $context.args.realization_start contract, and the realization currently carries CAS-file placements. P3.9 must reconstruct that packet from the checked cart store and adopt cart-backed placements in Pit before the engine can cold-start it. Makefile/profile consumers remain on the predecessor shape until that entry path lands. The current workshop also supplies sysinfo target facts, so cross-profile carts wait for exact linked-runtime target facts rather than deriving them from the host.

• 2026-07-24 — runtime language caches have an explicit off proof. PitRuntimeConfig.cache_profile independently controls actor-local heap-text interning and the transition decoded-Mach/native shape cache. All four combinations preserve content-based key equality, generic record lookup, and values across collection; the off/off direct-image test executes immutable image SHAPES without consulting the runtime shape table. Host UTF-32/copy, nan32 UTF-32/compact, and host kim8/copy cover the seam. This switch is a deletion aid, not a new compatibility mode. With shape caching disabled, callers that still request a DYN1 decoded/native shape are refused. The global CT/key bank and transition shape machinery remain until the parsed-Mach/native-template crossing deletes their final callers; no generic-record fallback was added for them.

• 2026-07-24 — T017 preserves executable-scoped workspace snapshots in a multi-selection store index. The portable fleet first reached its package merge with a two-file runtime-adapter snapshot and a twelve-file development-shop snapshot for the same canonical cell package. Both rows named version 0.9.3, the same package manifest, and the same selected Darwin target arm; each snapshot correctly described only the files selected into its own executable. Store manifests now represent a canonical package with a sorted, exact-deduplicated pit.package.selections@1 row, and layer composition unions those immutable selections. No bundle-wide workspace snapshot is synthesized. Per-executable manifests and workspace resolutions retain their one-selection-per-package rule and remain the identity authorities.

• 2026-07-24 — the portable bootstrap fleet follows the language’s function-level declaration rule. The T017 content-only crossing exposed nested var declarations in the debugger and process-status actors that the ordinary boot closure had not compiled. Their declarations were hoisted without changing behavior. This is a source correction retained by the clean generation, not a compatibility path.

• 2026-07-24 — the ruled finish line is the core system plus build self-hosting. Done means desktop cold boot runs entirely on the target-final artifact chain, one path exists for every artifact kind, the superseded-sole-path table is empty of in-scope rows, no mutable structure is reachable from two actors, and the host build comes from cake. P4 console fleets, P7 distribution, P8 hot swap, S012 native loading, and P9 dec64 are queued behind it and do not block completion. The execution order is system-completion.md §4 F0-F7; the P-phase text remains the content authority.

• 2026-07-24 — images are the only text and shape identity. Superseding the earlier two-tier reading, the runtime holds no text intern table and no shape cache — not one shared between actors, and not one per actor. Constant text and record shapes are emitted at build time into Mach images; a dynamically constructed key is ordinary actor-heap text compared by content through the image-precomputed hashes. system.md §1.1 and §8.2 now state this directly, A1 is restated as deletion rather than containment, and B6’s switch axis is retired: the caches-off configuration proven by source/cache_profile_test.c on host, nan32, and kim8 becomes the only configuration. This removes the last runtime-written structure reachable from two actors.

• 2026-07-24 — cake is the only build system, with one generated non-pit cold path. system.md gains §3.1: cake produces the runtime for every target from cake/plan.cm and the declaring package manifests, the committed boot/manifest/* files are rendered outputs rather than authored inputs, and build/lint/seed/pack work is ordinary Pit actors. The single permitted non-pit artifact is the generated POSIX-sh cold bootstrap, because a machine with no pit must be able to compile a first runtime; it uses no python, meson, ninja, or other third-party build tool and is never hand-edited. The four .py scripts are deleted in F6. Meson is retained for one more phase as T020, a parity oracle whose removal gate is the console lanes building under cake.

• 2026-07-24 — the bootstrap target has one canonical locator and the provider catalog has no recovery arm. A crossing-time edit had pit-shop/shop_actor.ce read the sealed bootstrap target at gitea.pockle.world/john/cell::bootstrap/target.json. No producer emits that spelling: root_cart_v2.cm, docs/spec/artifact-formats.md, system-completion.md, and the cart tests all name pit.bootstrap::target.json, and the completion plan states callers cannot shadow it. The same edit gated boot on an unlogged recovery arm that projected a provider catalog out of that asset when the startup field was absent. That arm could never succeed in either generation — it read through cart/cart, the v1 reader, while the only producer of the asset is root_cart_v2, whose container that reader refuses to open — and both committed carts carry no assets at all. It was also selected by absence rather than by an exact rule, which the rules above forbid. The locator is restored to canonical, the recovery arm and its boot-time content refusal are deleted, and the permanent provider catalog comes only from the exact startup record, refused at its point of use with a reason when inexact. Recorded as A18.

Completed transitions

Source: plans/archive/transition-diary.md