The coordinator runs a plan, not a pull request; a child is handed a contract and hands back a deviation; verification cannot be weakened without its spec

The ask. Decide: the ship coordinator that record 0029 puts on Cloudflare Workflows takes a plan record and its unit graph as its input, not one task, and runs each ready unit as the pull-request pipeline ship runs today, one thread per unit; every coding child is handed one typed contract (the unit's text, the spec rows it binds, the repository's agent rules, the guards it may not weaken) and returns one typed handoff (deviations, follow-ups, what it could not prove) that the parent records on the unit's tracker issue; the merge of a unit's pull request is a granted action the runner holds, so a pull request on a plan branch is merged by the runner on an approving review with the guards green, and any other pull request gets record 0029's wait for a person; and a deterministic guard makes a removed test a review finding, and a narrowed one a question the reviewer must answer, unless the same pull request changes the spec that covers it. Owner: the maintainer; the merge grant is the owner's to withdraw. Needed before the ship track's first code unit, because it changes what that unit builds. Written for an engineer who knows the dispatch pipeline, records 0002, 0007, 0019 and 0029, and has read the two published accounts this record is held against: the AI-native SDLC playbook (claude.com/blog/the-ai-native-sdlc-playbook) and the self-driving codebases report (cursor.com/blog/self-driving-codebases).

Success criteria: (1) the loop the maintainer's agent ran by hand to land this program's first units (cherry-pick a unit, open its pull request, run the review loop, fix, merge on the maintainer's standing instruction, rebase the dependent, repeat) is a product path in which every child passes the authorize stage as the requesting user and every merge is a granted action; (2) a coding child never starts from a free-text task alone when a plan unit exists for the work; (3) no pull request can delete a test bound to a spec without the spec changing in the same pull request, and no narrowed assertion passes review undisposed; (4) a child's deviation from its unit reaches the unit's tracker issue without a person writing it there.

TL;DR

In the day ending 2026-09-11 (UTC) four of the orchestration program's units and the retirement of a fifth went from a retired branch onto main in one pass: six pull requests, two fix rounds, one blocking bug the review caught, no edits by a person to any branch; the maintainer's agent did the orchestration by hand, one unit at a time, merged each on the maintainer's standing instruction after the review agent approved, and wrote the one deviation from the plan into a tracker comment. Both published accounts of agent-run development describe exactly that loop as the product: a committed chain of intent, spec, plan, diff and review with agents at each stage and humans only at gates, and a planner that hands scoped work to isolated workers and reads their notes back. Our program has the durable piece both accounts skip, a ledger that survives kills, and the per-child policy check already designed in record 0029 though not yet built, and none of the three pieces they make load-bearing: the coordinator orchestrates one pull request, a child receives a task string, and a handoff is prose. It also has an unwritten rule under strain: the repository says a person merges every pull request and ship never merges, and the pass merged six with none read by a person. The bet is that the ship coordinator widens to run a plan's unit graph, that the child's input and output become typed artifacts the specs bind, that the merge becomes a granted action the runner holds (on a plan branch: the runner merges on approval with the guards green; anywhere else: record 0029's wait for a person, unchanged), and that the review gate gains a deterministic guard against weakened verification. It is decided before the coordinator is built, not after, because three things take their shape from what one instance runs and are expensive to reshape once live: the instance's parameters (today's design: one parent record id; the runner's: a plan reference and a unit cursor), the card the bot draws from the instance's events (one pipeline's rounds, or a unit's rounds under a plan header), and the run record the bot assembles at the end (one pipeline, or one per unit). Deciding now costs the state machine one outer state (advance to the next ready unit) and the contract renderer; the first increment built may still run a plan of one unit, which is today's ship. The cost is a wider first unit for the ship track, two typed artifacts to maintain and one new policy action; one resident unit and one ship unit move behind it: wake and provision as instances (the last alarm stays until then) and the pipeline's receipt after deploy (the gated deploy itself already exists). Open: whether a unit's contract should carry the whole spec or only the rows the unit names, and whether a child may propose a new unit or only report one.

Today at 511b5b2b

Fact the design depends on	Where
Ship is one dispatch() run whose parent runs N serial child rounds in one process: coding at round 0, then review and fix rounds on a pinned head until approve or the caps; the compound permission gate runs once at preflight and the children call the agent loop directly, never re-entering dispatch(); a resident binds one branch per thread, so a second unit in the same thread is refused; findings and dispositions are typed; the pipeline is not resumable and after a kill the next generation tells the thread how to re-issue	src/core/dispatch/ship.ts, src/core/shipPipeline.ts, src/core/ship/codingChild.ts, src/core/ship/childRound.ts, docs/reference/specs/agent-ship.md items 2, 3, 4 to 10
A ship coding child is resident-only and is handed the request text, the thread's history and the resident system prompt; the prompt fixes the pull-request description as a typed object and forbids merge and approve ("a human decides what merges"); nothing in it names a plan unit, a spec row or a guard	src/agents/registry.ts (CODING_SYSTEM_RESIDENT, PR_DESCRIPTION_TEMPLATE, NEVER_MERGE), src/core/ship/codingChild.ts, docs/reference/specs/agent-ship.md item 11
The review agent reads the whole diff, checks it against only the specs it touches, and files a contradiction at minor or above; the verdict is typed; in a repository opted in through two variables an approving verdict auto-approves the pull request; no review by a person is required and a person merges every pull request; ship never merges and refuses repositories with auto-merge on; the bot's GitHub writes are branch, pull request and review post, never a merge or a push to the default branch	src/agents/registry.ts (REVIEW_SPEC_CHECK, REVIEW_VERDICT_INSTRUCTION), docs/reference/specs/agent-review.md items 14 and 15, .github/workflows/auto-approve-review-lgtm.yml, src/core/shipPipeline.ts (the auto-merge refusal and the "human merge" ending), docs/reference/specs/agent-ship.md item 9, AGENTS.md
A spec row binds a criterion to a test by file::describe::title; specs:check fails when the file or the title is gone; specs:coverage maps a changed path to the specs whose Code/Tests header names it; a test whose title survives but whose assertions are removed or loosened passes both checks	scripts/specs-check.mjs, scripts/specs-coverage.ts, docs/reference/specs/specs-coverage.md
The orchestration program plan is a record of sixteen units with a dependency graph, a phase table and a follow-ups ledger whose rows are written by hand; a plan's body is frozen once its status leaves proposed, so nothing appends to it after that; no bot path writes to main; the program's board is one issue per unit	docs/plans/2026-09-10-001-feat-orchestration-program-plan.md (Implementation Units, Appendix B), src/docs/records.ts (the immutability rule includes docs/plans)
Four units (the record's acceptance, the durable mutex, the refresh instance, the provider example) reached main, and the branch-line unit was retired, in six pull requests over the day ending 2026-09-11 (UTC) through the review loop, merged by the maintainer's agent on the maintainer's instruction with no branch edits by a person; one review round found a blocking bug the earlier branch review had missed (an incarnation id re-minted on every state transition); one deviation from the plan's order (the durable-mutex and refresh-instance units before the seam tests that were to gate them) exists only as a comment on the board	the six pull requests' review threads and the board's unit issues
Record 0029 fixes the coordinator's substrate: a Workflow instance in the bot's shim Worker that holds no credential, children through dispatch() as the requesting user, retried idempotent steps, and a coordinator that waits for a person's merge; the plan adds the dedicated bearer and run finished from the state Worker, and its two ship-track units (the finish event and bot steps; the ship Workflow) build it for one pull request	docs/decisions/0029-durable-objects-store-workflows-schedule.md, the plan's ship-coordinator requirements and its two ship-track units

The shape

Both published accounts converge on one machine seen at two scales. The playbook: every stage commits an artifact the next stage reads (intent, spec, plan, diff, review findings), agents do the work at each stage, humans review intent and risk at gates, and a production signal re-enters the chain as a new intent. The browser report: a root planner owns the scope and codes nothing, subplanners own slices, workers take one task each on an isolated copy and hand back notes, concerns and deviations, git merges, nobody holds a shared lock, and the instructions handed down decide the outcome more than anything else. Switchboard already runs the chain's artifacts in the repository (records, plans, specs bound to tests, a review agent gated on the touched specs) and already has what both accounts omit: a run ledger that resumes a child after a kill, and, designed in record 0029 for the coordinator's children, a policy table every child passes through as the requesting user. What it lacks is the planner's seat, the two typed edges around a worker, and a decided answer to who merges.

The design fills exactly those. The plan runner is the ship coordinator of record 0029 with a wider input: a plan record's unit graph. It walks the graph in dependency order, and for each ready unit runs the pull-request pipeline ship runs today in a thread of the unit's own (a resident binds one branch per thread), one open-or-edit pull request per unit keyed by a head branch that names the plan and the unit, review rounds to approve, the merge, then the dependents. The merge grant decides the merge: a policy action plan:merge the runner holds; for a pull request on a plan branch the runner merges (squash, the title as the commit, an empty body) through the bot's GitHub identity as a write the table authorizes to the runner once the review approves and the guards are green; for any other pull request the runner waits for a person's merge exactly as record 0029 has it. The child contract is what a coding child is handed for a unit: the unit's own section of the plan, the spec rows whose proofs the unit will add or change, the target repository's agent rules, and the names of the guards it may not weaken; it is a typed object rendered into the child's first turn, never a task string, and its first instruction is to rebase the unit's branch onto the merged parent, so the only writes are the child's own under the requester's token. The handoff is what the child returns beside its pull-request description: deviations from the unit, follow-ups it found and did not do, and criteria it could not prove; the parent records it on the unit's run and posts it to the unit's tracker issue, where receipts already live; the plan's own ledger is amended by a person at review points, because a plan's body freezes once accepted. Around the merge gate, a verification guard runs deterministically on the pull request's range: a deleted test file, a removed test block or an added skip marker is a finding at minor severity unless the same pull request changes a spec that covers that test, and a lowered assertion count or a renamed test is a line the reviewer must dispose of; the same-pull-request rule the specs already impose on behaviour.

The closest known shape is the browser report's planner and workers. The two ways this differs: every worker here is a dispatch() run under the requesting user's grants, so fan-out never escapes the policy table; and where that report lets workers commit imperfect work and trusts later workers to converge on a green branch, the runner lands each unit as a decided event, because the ledger and the review gate make a decided landing affordable and our children push to repositories other people own.

One trace: two dependent units, a death and a deviation

The maintainer points the runner at this program's plan with two ready units, the second depending on the first. Each beat names what it demonstrates.

1. Contract. The runner opens a thread for the first unit, renders its contract (its section, the spec rows it names, the agent rules, the guard names, the rebase instruction) and spawns a coding child through dispatch() as the maintainer, whose grants the authorize stage checks now, with the idempotency key <instance>:<unit>/0/coding.
2. Handoff. The child rebases onto main, does the work, pushes the unit's branch, submits its description and a handoff with one deviation ("one re-arm stays until the next unit moves the wake path") and one follow-up (a file that should split).
3. Death. The bot dies mid-push. The next generation reclaims the run from the ledger and finishes it; the state Worker sends run finished; the runner confirms through read-record and reads the handoff. Nothing was re-issued.
4. Guard. The review child runs on the pinned head with the same contract. The guard reports two removed test blocks covered by a spec the pull request changes: allowed. It reports one assertion-count decrease in another test file as a check; the reviewer reads the diff, calls it weakened, files it at minor.
5. Fix and land. The runner spawns the fix child with the finding; the assertion returns; re-review approves; the guards are green; because the pull request is on the unit's plan branch, the runner merges (squash, blank body) under its own plan:merge and records the unit done with its handoff. A pull request off a plan branch would wait here for a person, as record 0029 has it.
6. Dependent. The runner renders the second contract with the first unit's deviation appended and spawns in a new thread; the child's first step rebases the unit's branch onto the merged first. A conflict is not retried: the unit ends with the conflict as its handoff for a person, its dependents stay blocked, and any other ready unit proceeds.
7. Tracker. The unit's board issue gains the handoff as a comment, posted by the runner; the plan's Appendix B is amended by a person at the next review point.

The difficulty map

1. Guarding verification without false findings (most likely to be wrong, cheapest to correct): a deleted test is a fact; a lower assertion count is a guess, and a guess that fails the gate teaches people to route around it. Two classes and a measured baseline, below.
2. The child contract (most open): what a unit hands a coding child, how much of a spec, and how the reviewer and the guards know what the child was told. Its two open questions are the record's. Section below.
3. The runner's identity and resumption (most work, least risk): one pull request per unit, a re-run that resumes rather than duplicates, a dependent that rebases. Record 0029's idempotency key and ship's open-or-edit rule, generalized; the plan's unit carries the design.
4. Handoffs as data (least): { deviations: [{ from, to, why }], followUps: [{ what, where }], unproven: [{ criterion, why }] }, submitted through the same tool path as the pull-request description, recorded on the child's run, and posted by the runner to the unit's tracker issue; a person decides each disposition and amends the plan's ledger while the plan is proposed. The only design question is what a child may say, and it is one of the two open questions.
5. The merge grant (a decision, not a difficulty): who holds the merge. Section below.

The child contract

The constraint: both accounts find that the instructions handed to a worker decide the outcome, and Switchboard's units already exist as text with bound spec rows; handing a child less than that wastes what the plan already knows, and handing it the whole tree drowns it. The contract is therefore the unit's section verbatim (goal, requirements, files, approach, test scenarios, verification), the spec rows the unit names by item number with their current proof bindings, the repository's agent rules file, and the list of guard names with one line each on what they refuse. It is rendered into the child's first user turn under fixed headings so the review child can be handed the same object and check the diff against it: a test scenario the unit listed and the diff did not add is a finding at minor, the same severity as a spec contradiction.

What is decided: the contract is a typed object in src/core/ship/, rendered by the runner, never assembled by the child; it names spec rows, not whole specs; the child may not edit the plan record. What is open, with the maintainer resolving it on the first two units run this way: whether a unit that names no spec rows gets the covering specs' rows by path (from specs:coverage) or nothing, and whether a child may propose a new unit in its handoff or only report a follow-up.

The number this section lacks is the rendered length of a real contract against a cold child's first turn. It is unknown today; the first unit rendered this way measures it (this program's committed unit sections run from 116 to 716 words, mean about 350, counting the heading to the next heading, before spec rows), and the cut rule below is the backstop until it is known.

Failure modes: a stale unit (the plan says one thing, main has moved) reaches the child as fact. The rebase step before the spawn and the "today" facts the child re-reads mitigate it; the handoff's deviation field is where the child says the unit was wrong. A contract too long for a cold child's first turn is cut by dropping approach text before spec rows, never the other way.

The runner's identity and resumption

A unit has one head branch, plan/<plan-id>/<unit-slug>, so two plans sharing a unit name never share a branch, and ship's open-or-edit rule makes the pull request idempotent by that branch; a pull request a person closed unmerged is not reopened: the unit ends with that as its handoff. The runner's steps carry the plan's idempotency keys, <instance>:<step> with the step named <unit>/<round>/<kind>, so a retried spawn answers alreadySpawned for a live or finished run carrying the key. A unit is done when its pull request is merged and its handoff recorded; a runner instance that dies resumes at the first unit not done, reading the ledger, not its own memory; two instances for one plan are refused by the plan id in the instance name. Each unit runs in its own thread, because a resident binds one branch per thread. The rebase onto the merged parent is the coding child's first instruction under the requester's token, never a write of the runner's; a conflict ends the unit with the conflict as its handoff for a person, blocks its dependents, and leaves other ready units running.

The merge grant

Amendment, 2026-09-15 (record 0036). The instance decides, not the branch. Record 0036 collapses ship's task form and plan form into one plan instance, seeded from a file or generated from the request, so every ship branch is a plan/ branch or an adopted pull request's own head, and a branch name can no longer carry the merge decision. The hand-off writes merge: runner | person on the instance (person for a generated plan unless the request says otherwise; a seeded plan as it declares), the driver reads it, and the runner's door checks the plan:merge grant, the field, and that the pull request heads the unit's row. The grant and its guards are unchanged; what selects them moves from a filename convention to a field. The "task string never merges and keeps refusing repositories with auto-merge on" clause below is superseded the same way: a generated plan never merges by default, and the auto-merge refusal is replaced by the per-pull-request fact (record 0036).

The constraint: the repository's rule is that a person merges every pull request and ship never merges, and the pass this record starts from merged six with none read by a person, on the maintainer's standing instruction to their agent. A runner that merges silently would break the rule; a runner that never merges keeps a person in a loop the accounts and the pass both show is the one that stops scaling. The decision: the merge is a policy action, plan:merge, in the same table as every other action (record 0007), and the runner holds it. What decides a merge is the branch, not the requester: a pull request whose head branch is a plan branch (plan/<plan-id>/<unit-slug>, the branch the runner itself opened for the unit) is merged by the runner once the review's verdict approves and the guards are green, squash with the title as the commit and an empty body, through the bot's GitHub identity, and the merge is one more of the bot's named GitHub writes; a pull request on any other branch waits for a person, which is record 0029's behaviour and stays it, so ship on a task string never merges and keeps refusing repositories with auto-merge on. The release pull request, which deploys, is always a person's merge. Decided by the owner, in place of a grant held per requester, on what the pass showed: every unit it landed was merged on the owner's standing instruction and none was read by a person, so a grant held by the runner names what already happens, where a grant held per requester would have named a person who was not in the loop; the release pull request stays the one merge a person makes. Withdrawing the grant returns every merge to a person. Compensating controls for the runner's merge: the review agent's approval, the specs bound to tests, the hygiene ratchet, the verification guard, and the release pull request's human gate in front of production.

Guarding verification

The rule the specs already impose, a behaviour change updates the covering spec in the same pull request, is extended to the tests that prove behaviour. A fact and a guess are never the same finding:

• Removed (a fact; fails the guard; a finding at minor): a test file deleted; a test title gone from its file beyond what the pairwise rule below excuses; a skip marker (.skip, .only, xit, xdescribe, .todo) added.
• Check (a guess; printed, never fails; the reviewer disposes of each line in the review body as "weakened", then a finding at minor, or "refactor, verification intact" with one clause of why): a decrease in a file's expect count; a removed title paired with an added title elsewhere in the diff.
• Pairwise rename rule: across the diff's test files, with N removed and M added titles, the min(N, M) removed titles whose bodies most resemble an added block are check-class and the remaining max(0, N − M) are removed-class, so renaming or moving one test does not excuse deleting another.
• Allowed: either class, when the changed paths include a spec whose Code/Tests header names the test file's path; the line prints with the spec's name and does not count. This is file-level: any edit to a covering spec allows every line in that file, and for a title a spec row already binds specs:check forces that edit anyway, so the removed class bites hardest on tests no row binds. Row-level allowance is a later tightening if the file-level one is gamed.
• Where it runs: a deterministic script behind specs:coverage, which already maps paths to specs, so no new command; the review prompt both variants share names both classes and the disposition rule; the removed class joins the pull-request checks when the CI migration in progress settles. The script needs the repository's dependencies, so it is deterministic where it runs, in resident reviews and in CI; a cold-sandbox review, which may not install, has no guard and the reviewer applies the removed rule by hand on the diff and says so, until the CI check covers every pull request.
• What it does not do: read assertion semantics (a toBe loosened to toBeTruthy passes it and stays the review agent's to catch, which the prompt says); notice an expect moved within one file (the count nets out); enforce the reviewer's disposition in code (the prompt requires it and the verdict post does not parse it; a parsed disposition is a later tightening).

The baseline, approximated over the last 290 first-parent commits of the pre-rewrite history with "allowed" read as any spec change in the commit: the removed class fires unallowed on 7 commits (one in forty; every one a squash-merged pull request that deleted tests with the feature they proved), allowed on 7; the check class fires unallowed on 57 (one in five), allowed on 39. So the removed class costs a spec edit on roughly one pull request in forty, and the check class costs the reviewer one clause on one pull request in five, which is why it never fails the gate. Over the 35 commits of the public history the guard would have fired unallowed zero times.

Why not X

• Point the child at the unit by path and let it read the plan and the specs itself. Cheaper to build, and wrong for two reasons. The review child must judge the diff against what the coding child was told, so the two need one shared object, not two readings of a tree that may differ (a cold child has no tree until it clones; a resident child's tree is the pull-request branch, where the plan may already be edited). And a child that assembles its own brief chooses what to leave out; the point of the contract is that the runner chooses.
• Keep a person running the loop. It worked for one day and it is what both accounts say stops scaling: the playbook puts the ceiling at how many streams one person can review properly. The pass also showed the one thing a person adds, judgment on a deviation, is exactly what the handoff makes explicit.
• The browser report's shape as is: no ledger, tolerate turbulence, converge. Right when a child's death is cheap and a bad commit is fixed by the next worker; wrong when children hold write-scoped tokens to other people's repositories. The shape section says how this differs.
• A person merges every pull request, as the repository's rule says and the playbook prescribes. Kept for every pull request off a plan branch, and for the release pull request always. The runner's grant exists because the pass this record starts from already ran that way on the maintainer's instruction, with the review agent's approval, the specs bound to tests and the hygiene ratchet as the controls, and the release pull request as the human gate in front of production; a rule the repository breaks on instruction is better written down as a grant than left unwritten. A generated summary of what changed against which specs belongs on the release pull request, where a person reviews intent and risk.
• A grant held per requester, so a person who holds it lets the runner merge and one who does not gets the wait. The first draft of this record. It names a person as the authority over each merge when the pass showed no person in that loop: the requester who held it would have been the same maintainer whose standing instruction the agent merged on, and a second requester would hold it or not by the owner's say, which is the runner holding it with one more table to keep. The branch shape carries the same decision with nothing to configure per person, and withdrawing the grant is one line either way.
• A separate planner agent with its own loop. A planner that decomposes work is a model turn with judgment, and the plan records already are that decomposition, reviewed by people. The runner walks a graph a person approved; it does not invent one.
• Guard tests by protecting the files. The playbook hooks test paths read-only. Tests here change in more than half of all pull requests by design (21 of the last 36 commits); the same-pull-request spec rule is the sharper line.

Boundaries

Not decided here: the production-signal loop (detection, tiered confidence, an intent written by an agent) that closes the playbook's chain; the runner's entry accepts an intent-shaped input so that loop plugs in, but it is another record. Not decided: which harness a child runs on; the contract is what a child receives under either. Records 0002, 0019 and 0029 are unchanged; record 0007's table gains one action, plan:merge, and the bot's named GitHub writes gain one, the merge of a pull request the runner opened, under that action. Compatibility: the ship directive keeps working on a task string; a task string is a plan of one unit with no spec rows, and its pull request is never on a plan branch, so nothing about its merging changes.

What would change our mind

• If, over the first five units run this way, the runner's fixed pipeline per unit needs judgment calls a person made by hand (which unit next when two are ready and one has a failing dependency, whether a deviation invalidates a later unit), a planner turn returns to the design. The evidence: the runner ending more than one unit in five with a handoff a person had to act on before the next could start.
• If the guard's removed class produces more than one false finding in ten pull requests, the rename rule is wrong and the class narrows to deletions and skips. If reviewers dispose of more than half the check-class lines as refactors over the same ten, the count rule is noise and goes.
• If a child's contract regularly exceeds a first turn, the contract shrinks to spec rows and the unit's test scenarios.

Rollout

The guard first, as one pull request behind specs:coverage and the review prompt; then the contract and handoff as typed objects with the coding and review prompts reading them, receipted on this program's own next unit run by hand with the contract rendered; then the runner as the ship track's first code unit in place of a single-pull-request coordinator, with plan:merge held by the runner for plan branches, receipted by running the program's remaining resident units through it. Reversal at each step is a revert of one pull request, and withdrawing the grant returns every merge to a person; nothing stored changes shape.

Open questions

Question	Owner	Resolves it	Before
Does a unit with no named spec rows receive the covering specs' rows by path, or none?	maintainer	the first two units rendered with a contract	the runner
May a child propose a new unit, or only report a follow-up?	maintainer	the handoffs from the same two units	the runner
Where does the release pull request's "what changed against which specs" summary come from: the runner's handoffs or a diff pass?	maintainer	the first release cut after two runner-landed units	the second runner unit

Validation criteria

Criterion	Proof
A deleted test file, a removed test block and an added skip marker are each a removed-class line and fail the guard; a decreased assertion count and a rename are check-class lines and do not; a covering spec change in the same range allows either class	[unit] the guard module's tests, bound in docs/reference/specs/specs-coverage.md
The review prompt both variants share names the guard and the severity	[unit] src/agents/registry.test.ts
A coding child receives the contract under fixed headings and the review child checks the diff against the same object	[unit] the contract module's tests; [agent] one unit of this program run with a rendered contract, receipted on its board issue
A child's handoff reaches the unit's board issue without a person writing it	[agent] the same unit's receipt
On a plan branch the runner merges on approval with the guards green; off one it waits and the pull request stays open until a person merges; the release pull request is never merged by the runner	[unit] the coordinator state machine's tests and the merge route's branch check; [agent] one unit on a plan branch and one task-string ship, receipted
The runner lands two dependent units in two threads with one bot kill during the first, resuming from the ledger	[agent] the ship track's first receipt