ADR-0063: Program-to-cart handoff: control ruled out, continuity through the mission region

enrich-never-gate; launch-app as the sanctioned launch verb from cart and mission Lisp), ADR-0049 (the opaque live :world handle, N1-N8; program-to-program handoff), ADR-0051 (accepted missions are world-backed; mission_world.c), ADR-0040 (the UDS sanctioned-write boundary), ADR-0019 (physical cartridge insertion), ../software/programs/enrichment-contract.md (the shared mission world-region, §4), ../software/runtime/world-engine.md (the region authority), ../software/programs/bzbx.md, ../software/programs/conduit.md, ../software/cartridges/modules/ice-breaker.md

Context

The recon loop and the intrusion loop meet at one edge. During a mission the operator runs bzbx and CONDUIT over the shared mission world-region: hosts get revealed, findings get committed to DOSSIER, the trace meter moves. Then the operator turns to the intrusion cart, and the question this ADR answers is what crosses that edge. Two candidate mechanisms were on the table: a control transfer (a program starts or switches into the cart’s game surface, the way ICE Breaker can drop the operator into a CONDUIT session) and a data path (the cart reads what the programs wrote).

The launch topology so far covers every direction except this one. Carts and missions launch programs (launch-app, ADR-0042 Decision 4). Programs launch programs, threading the live :world handle by region identity across the context switch (ADR-0049 N5, N7). No decision covered a program starting a cart, and the gap showed at the moment of payoff: ICE Breaker’s (cart-init) seeds its run from the contract id (ib/adopt-contract! calls (ib/reset! id) in carts/carts/icebreaker.lsp), so the system it generates has no connection to the host the operator scouted in bzbx ten minutes earlier. The recon and the attack read as two worlds.

Verified runtime facts

The decision below rests on four facts checked in the runtime source:

1. Both tiers bind the six world read accessors through one seam. nosh_world_bind (runtime/src/nosh_world_bind.c) binds world-handle? / world-node-revealed? / world-node-online? / world-node-value / world-trace / world-node-count and is called from the cart bridge (nosh_lisp_bridge_register, runtime/src/nosh_lisp_bridge.c) and from the System-tier context factory (runtime/src/sys_context.c). The read surface exists on both sides today; no new bind is required.
2. The live handle is minted only into program contexts today. screen_router.c binds *world* to the minted live handle when it launches a program (router_bind_live_world); no code path mints the mission region’s handle into the cart context, so a cart’s *world* stays nil and ICE Breaker’s (world-handle? *world*) guard falls back to its static value. This is the one implementation gap the seam has.
3. The mission world-region survives the cart-load edge. The region is process-global run-state in world_engine.c; world_engine_init runs once at host boot (nosh_host.c), and mission_world.c resets the region only when the next NOSH_EVENT_MISSION_ACCEPTED arrives. cartridge_load_v2 opens a fresh per-cart Fe arena and resets only the Fe handle-wrapper pool (nosh_world_reset_handles); the handle is a value (region id + generation), so re-minting it in the new context resolves the same region (the GWP-630 contract in runtime/src/nosh_world_bind.h). Cart insertion does not destroy the recon.
4. The contract readers already reach the cart. (mission-contract-id) / -kind / -threat (GWP-773) are polled at (cart-init) and delivered through (on-mission-accepted) when the cart is live at accept time (runtime/src/nosh_runtime.c).

Decision

1. Program-to-cart control transfer is ruled out

No program starts, launches, or switches into a cart surface, and the rule covers the whole roster. launch-app stays one-directional: carts and missions launch programs (ADR-0042), programs launch programs (ADR-0049 N5/N7), and no launch targets a cart. The doors into a cart surface remain the two that exist: physical cartridge insertion (ADR-0019) and the operator’s own screen switching.

Three reasons, in order of weight:

• Programs are instruments, never levers. bzbx’s Tier 1 states the constraint as the design: a readout that cannot move what it displays can be taken at face value. A program that can open the attack surface is a lever, and the instrument reading stops being trustworthy. The same boundary that limits a program to sanctioned run-state writes (world-reveal!, the bzbx-to-CONDUIT reveal this ADR relies on in Decision 2) and denies it every durable or UDS write outside dossier-commit (ADR-0042 enrich-never-gate, ADR-0040) keeps it from transferring control.
• Physical insertion is the product’s identity. The cartridge in the hand, the slot, the swap mid-mission: that ceremony is what the hardware is for. A software door into the cart surface would compete with the physical one and cheapen it.
• The engine owns world truth, and reading it is already enough. Both tiers hold the six read-only accessors (fact 1). Nothing a control transfer would carry exists outside the region and DOSSIER, so the transfer has no cargo.

2. Data continuity is specified in its place

At mission activation, the cart reads what the mission produced:

• The shared mission world-region. The same engine-owned region the programs enriched during the mission, read through the six accessors both tiers bind. The enrichment contract’s shared-region rule extends to the cart: one region per mission, and the cart at mission activation is one more reader of it (enrichment-contract.md §4).
• The accepted-contract readers it already has: (mission-contract-id) / -kind / -threat (GWP-773).

The target mapping. The cart resolves its attack target from the region when the region holds one (the host flagged as the mission’s breach target), and falls back to contract-seed generation when it does not. The engine designates the target at accept; the cart uses it only once recon has revealed that node, so an accepted-but-unscouted contract stays on the contract-seed fallback and the designation never leaks knowledge the operator has not earned. For ICE Breaker: when the region names a scouted breach target, the run opens on that host; when no region or no flag is present (a bare run, a harness run, a recorder run), (ib/reset! contract-id) generates as it does today, unchanged.

What a program passes at a handoff moment: nothing. There is no handoff moment. The program wrote to the region (world-reveal! run-state) and to DOSSIER (dossier-commit, the sanctioned durable write) while the mission ran, as its spec already describes. The cart reads those stores at activation. No payload, no message, no new channel.

The capability boundary is unchanged. Neither tier gains any write capability. The cart-side work is a read-only bind: minting the mission region’s existing handle into the cart context as *world* through the shared nosh_world_bind seam (closing the gap in fact 2). ADR-0040’s sanctioned-write boundary and ADR-0049 N4 hold verbatim.

3. The region-lifetime requirement is pinned

The mission world-region MUST survive the cart-load edge: cart insertion, cart ejection, and a mid-mission physical swap reset neither the region nor its generation counter. The region resets only at the mission-instance boundary, which is the next mission accept and nothing else: the NOSH_EVENT_MISSION_ACCEPTED handler in mission_world.c is the sole reset point. Mission resolution does not reset the region; the resolved mission’s world stays addressable until the next accept replaces it. The shipped runtime satisfies this today (fact 3); this ADR makes it normative so a future load-path change cannot break it without superseding a recorded decision. Context-local Fe handle wrappers may reset at the load edge; the region identity they re-mint from may not.

4. Why both halves land together

Ruling out control while specifying continuity keeps the one-coherent-world promise (ADR-0051) at the moment of payoff. The World Engine generates one world per mission; the programs are lenses over it; the cart is the contest inside it. If the cart invents an unrelated system from the contract seed, the promise breaks where the operator cashes it in: the recon was theater. With the region read in place, the host bzbx revealed is the host the cart attacks, and the chain holds without any program holding a lever.

Options considered

Option A: program-initiated cart launch (REJECTED)

Extend launch-app (or add a sibling verb) so a program can start the inserted cart’s surface. Rejected on all three grounds in Decision 1: it converts instruments into levers, competes with physical insertion, and carries no cargo the region does not already hold. It would also invert the dependency ADR-0042 built the roster on (programs ship content-free; carts supply the world).

Option B: a handoff payload passed from program to cart (REJECTED)

Keep control with the operator but define a payload a program stages for the cart to ingest (the shape N7 uses for the program-to-program drain). Rejected because the payload has no content: the facts a program could stage are the region’s reveals and DOSSIER’s commits, both of which the cart can read where they live. A second copy of the same facts adds a channel to keep consistent and nothing else.

Option C: continuity through the shared region and contract readers (ACCEPTED)

The cart reads the region and the contract at mission activation and resolves its target from them, with contract-seed generation as the fallback. Chosen because it uses stores and seams that exist, changes no boundary, and delivers the payoff Option A chased without the lever.

Option D: status quo, contract-seed only (REJECTED)

Leave the cart seeding from the contract id alone. Rejected because it breaks the one-coherent- world promise at its payoff (Decision 4): the scouted host and the attacked host never meet.

Consequences

Positive

• The recon loop pays off inside the intrusion loop: the same host, the same world, no lever.
• The launch topology is closed. Every direction now has a recorded decision: cart to program (ADR-0042), program to program (ADR-0049), program to cart (ruled out here).
• The cart-side work is a read-only bind through an existing seam; no FFI surface grows.

Negative / accepted costs

• A cart author who wants a “press here to open the attack” flow inside a program cannot have it; the operator switches surfaces. That is the product working as designed.
• The target mapping adds a branch to cart activation (region-derived target with seed fallback), and the fallback path must stay tested so bare and harness runs never regress.

Follow-up work

All four items shipped with GWP-807:

• Mint the mission region’s live handle into the cart context as *world* at mission activation (the read-only bind closing fact 2’s gap). Shipped as an injected hook mirroring the router’s minter: runtime_bind_cart_world (runtime/src/nosh_runtime.c) is called from cartridge_load_v2 (accept-then-load) and from runtime_mission_accept before the on-mission-accepted hook fires (load-then-accept); the production hook body lives in runtime/src/cart_world_bind.c and is installed by nosh_host_init. A harness with no hook installed leaves *world* nil, so every bare / harness / recorder path is unchanged.
• Define the region query a cart uses to find the breach target. Shipped as a region-level target reference, not a per-node flag: WorldRegion.target is set by the engine at generation (world_designate_target, a deterministic seed-based pick; mission_world.c calls it on every accepted contract) and read through the new (world-target w) accessor on the shared nosh_world_bind seam (both tiers; read-only; logged in the ADR-0005 Amendment Log, 2026-08-23).
• ICE Breaker: region-derived target resolution with the contract-seed fallback in carts/carts/icebreaker.lsp (ib/region-target, ib/target-system-name; the zone/lock layout stays seeded by the contract id).
• The conformance test: runtime/tests/test_cart_world_continuity.c covers both accept orders, the identity-band derivation on the real cart source, the eject/reload region-survival edge (Decision 3), and the no-hook fallback.

Documentation updates

Part of the decision. A PR that lands this ADR without these edits fails review.

• docs/adr/README.md: index row.
• docs/software/programs/bzbx.md: the ruling-out sentence and the continuity statement on the bzbx-to-CONDUIT / DOSSIER flow.
• docs/software/programs/conduit.md: the boundary-against-the-cart note gains the reverse ruling and the continuity statement.
• docs/software/cartridges/modules/ice-breaker.md: target resolution from the region at mission activation, contract-seed fallback.
• docs/software/programs/enrichment-contract.md: §4’s shared-region readership extends to the cart at mission activation.

Narrative (for the design history)

The operator spends the front half of a mission looking through instruments: bzbx sweeping the subnet, CONDUIT riding the box that turned up, DOSSIER filling with what the run learned. Then the cartridge goes in and the contest starts, and for a while the contest started somewhere else: the cart rolled its own system from the contract number and the scouting counted for atmosphere. The tempting fix was a button, some way for the program that found the target to open the fight. Josh ruled the button out. The programs stay instruments, the slot stays the only door, and the fix went to the other side of the edge: the world the programs enriched is engine-owned and outlives the cart swap, so the cart reads it on activation and opens on the host the operator scouted. Nothing new crosses the edge because everything needed is already standing on both sides of it.