§1 — Why this exists

Reckon can coordinate a sprint but cannot dispatch a worker that is not an in-process subagent of the orchestrator's own harness. This plan adds that path, and does so through a single dispatch instruction that names no harness, model, effort level or sandbox flag. The agent states what it wants; reckon resolves how. Per-backend flag translation is compiled code the agent never reads, which is what makes drift between execution paths structurally impossible to express.

The seam design, the single permitted branch and the verified per-backend matrix are recorded in Agent Fleet Orchestration §2–§3. Read that before implementing.

✓ landed §2 — The task-definition contract

Landed as crew.validate_node plus a pre-dispatch checklist in the skill. A live rejection named five failing properties at exit 2; 18 tests cover the seven, including the three the measure names. Independently verifiable gained a real test on implementation — the manifest path must be absolute, because a relative one resolves against the worker's own worktree and makes a delivered node look silent. Contract text now lives in references/worker-protocol.md; the table below is the design record. § contract

This is the highest-value deliverable in the sprint, because a worker that thrashes is almost always executing a malformed task. The contract makes well-formedness checkable before dispatch, so the escape hatch handles only the genuine residual.

A node is dispatchable only when all seven hold:

Implement this as an explicit pre-dispatch checklist in the skill and as a validation in reckon crew dispatch that refuses a node missing a goal, a measurable done-when, or a write scope. A node that fails is reshaped or split — never dispatched with the hope that the worker will work it out.

✓ landed §3 — Deliverables

All eight landed: reckon/_backends.py (translation, keyed to a backend's command, verified against four event streams recorded from live runs), reckon crew dispatch/attach — plus observe, resume, list and stop, without which the measures are unreachable — references/worker-protocol.md, the structured escape hatch, the four-axis reflex with a validator that refuses a non-quantitative completion, continuation at three altitudes, budget capture with an explicit unknown state, and the skill upgrade with the gate-fence rule authored solely here. § dispatch, § divergences

The launch matrix as code. reckon/_backends.py translates a resolved flight config plus a node into a concrete invocation for each backend: argument construction, session-id capture from the backend's machine-readable stream, resume form, terminal-event recognition, and final-message retrieval. Unit-tested per backend against recorded event fixtures, with no live process required.

The uniform CLI primitive. reckon crew dispatch --project P --plan L --section S --role R --node N and reckon crew attach --run R --task T. Dispatch validates the node against §2, resolves flight config, creates the detached worktree through the existing fleet script, composes the fenced prompt, and then branches once on launch: kind — spawning the process and returning a run id for a cli backend, or returning a dispatch directive for an in-harness backend which the agent binds back with attach. Atomic: it performs the whole operation or none of it. JSON on stdout.

The harness-agnostic worker contract. skills/reckon-ship/references/worker-protocol.md owns the task-definition contract, the four fences, the compact manifest shape, and the escape hatch — everything true of a worker regardless of backend. Having one home for these is what stops them drifting between backends. The fence set is scope, time, evidence and delivery; delivery is a fence rather than a convention because a background worker can complete its work and end its turn without delivering a report, at which point the node looks failed when it is not.

The escape hatch. A worker stops and emits a report opening with NEEDS-HELP: and four required fields: tried: the attempt and its observable result, options: two or three concrete paths, leaning: which and why, cost-if-wrong: what must be redone. Named triggers: the same command failed twice with different fixes attempted; a decision the plan does not settle is required; the necessary change exceeds the write scope; the gate's evidence cannot be produced with the available tools or data; or the budget is spent with the gate still closed. The orchestrator answers by default, escalates only scope trade-offs and irreversible choices, and resumes the same session — which is why session reuse is load-bearing rather than an optimisation.

The summary reflex. Four axes — what, why, how, when — emitted at dispatch, at completion, and when micro-planning the next step, one line each, at most two lines per axis, restating nothing the plan already says. The binding discipline is that at completion, why carries the gate evidence, which forces every wave report to be quantitative and makes a wave that cannot state its evidence visibly incomplete rather than plausibly done. Specified with worked examples in Agent Fleet Orchestration §8.

Continuation wiring at every level. Work must never end without naming what comes next, and the chain has to close at three altitudes rather than one. A worker returns candidate follow-ons in its manifest — work it discovered but was fenced out of — which the orchestrator either folds into the current wave or writes as a plan followup; today a worker's out-of-scope discovery has nowhere to go but prose. A plan landing resolves its driving followup and appends the next one-line invocation, or records that the chain closes; this rule exists but is enforced only by discipline, so make it a validated condition of the writeback. A sprint close reports the sprints it feeds, derived from the dependency graph — the downstream sprints whose items this sprint's plans unblock — which does not exist at all today. Enforce all three: a session ending with neither a next invocation nor an explicit no-followup outcome is a failure, at every altitude.

Record whatever budget signal the backend emits. The two CLI backends are asymmetric here and the design must not pretend otherwise. One emits a structured rate-limit event carrying utilisation, reset time and a threshold status — enough to reason about headroom. The other emits per-turn token usage but no headroom at all, and offers no query command for it. So capture what is emitted into the run record, expose it as a budget block that may legitimately read unknown, and never infer exhaustion from absence. Acting on that signal is the subject of budget-aware-dispatch; this plan only ensures the data is captured from the first dispatch onward, so the later work has history to reason over.

The skill upgrade — and this plan owns SKILL.md outright. reckon-ship/SKILL.md gains the pre-dispatch checklist, the one dispatch instruction, the summary reflex and the gate-fence rule that a wave does not open through a closed gate. It gains no backend-specific text. references/worker-backends.md is added as maintainer documentation of what _backends.py does internally — it is not agent-facing, and the ownership test is that a sentence in it which does not turn on process, session or observation mechanics is misfiled.

The gate-fence rule is authored here and nowhere else. Gates are not yet structured state, so enforcement at this stage means the orchestrator reads the plan's declared evidence-gate table and refuses to open the next wave until its measure has produced evidence. derived-gate-state later swaps that enforcement from reading prose to reading computed state; it must not re-author the rule, and no concurrent node may write this file until this plan's changes are integrated. Saying so explicitly is the point — two plans claiming one rule is how a worker rewrites a peer's text believing it owns it.

Dispatch resolves the base to a commit, compares the working plan's bytes against that commit's blob and verifies the named section by authored id or heading — all before a worktree exists. It refuses at exit 4 with error=plan-unavailable, beside 2 for a malformed node and 3 for a budget hold, so a caller branches without parsing prose. Demonstrated on the live failure rather than a fixture: with the plan genuinely dirty, a dispatch naming it returned "differs from base 'HEAD'; commit the plan before dispatching" and created 0 worktrees. It then blocked this session twice more, correctly both times. 5 new tests, suite green at 1,680 (commit c558f47).

A dispatch cuts a detached worktree from a base ref and then tells the worker its first act is to read the live plan at the named section. Those two facts do not compose: the worktree holds the committed plan, so any edit still sitting in the orchestrator's working tree is invisible to the worker. The node names a section that, from where the worker stands, does not exist.

The failure is quiet in the worst way. The node is well-formed — it passes all seven properties, because well-formedness is judged against the node, never against what its worktree can show. Nothing warns. The worker either burns its budget hunting a missing section or, worse, finds an older revision of it and implements the previous intent faithfully.

Observed 2026-08-12 while dispatching against a section written minutes earlier: caught thirty-seven seconds in, by chance, only because the worktree was opened to check. The cost was one stopped run and one removed worktree; unnoticed it would have been a wasted budget and a plausible-looking wrong result.

Dispatch refuses before it creates anything. The plan the node names must be readable at the base ref, must contain the named section there, and must not differ from the orchestrator's working copy. Any of those failing is a refusal that names the file and says to commit — checked before the worktree exists, so a refused dispatch leaves nothing to unwind.

No override accompanies this. The remedy is one commit, the rule is cheap to satisfy, and an escape hatch here would be taken exactly in the hurry that produces the bug.

A conjunction bounds two deliverables only when a task action follows it, and a listed term preceded by a hyphen no longer fails demonstrability; then and ; stay explicit separators. All 3 conjoined-noun goals refused in one wave now pass while the genuine two-deliverable goal from that same wave is still refused. Re-checked against this session's own three refusals: 2 were false positives and now pass, 1 was a true positive and still refuses — a bare vague adjective, which is the case the check exists for. 2 new tests, suite green at 1,701 (commit a2aef3e).

Two properties reject nodes that satisfy them, and both failures share a shape: a pattern matching a surface feature of the wording rather than the thing the property is about.

Single-goal matches any " and ". A goal naming one deliverable through a conjoined noun phrase — "round-trip a section from parse and serialisation", "derived age and a staleness verdict", "sprint order and incompleteness" — is refused as two nodes. Three of three nodes in one wave were refused this way, each reworded to remove a conjunction that was never a second deliverable. The distinction that matters is between a conjunction joining two verb phrases and one joining a noun phrase.

Demonstrable matches a subjective term inside a compound. The check tests a word boundary, and a hyphen is one, so machine-readable, human-readable and any compound ending in a listed adjective are rejected as opinions. Observed twice today, once while dispatching the guard in §6 itself: a done-when naming a machine-readable exit code was refused for resting on the term "readable".

The direction of the error is what makes these worth fixing. Both checks exist to stop a worker being sent an unmeasurable goal; here they block the most precise available wording and push the coordinator toward vaguer text. And both were survivable only because a human noticed — a refused dispatch is silent about whether the refusal was correct.

The checks are worth keeping: the same pass correctly caught a genuine two-deliverable goal and a time budget overrunning its fence. The defect is precision, not existence, so the measure is a test carrying both the correctly-refused and the wrongly-refused wording from the waves that produced them.

A dry run now returns the write paths it resolved, so a coordinator sees what it actually fenced before committing a wave to it, and the worker protocol states plainly that scoped checks exclusivity and does not prove the named paths can carry the goal. 2 new tests (commit 7952c4c). The worker reported blocked rather than claiming complete, because the full suite was red on arrival from a concurrent commit deriving plan dispatchability — its own two measures passed throughout, and the suite came back green at 1,711 once that peer landed its fix. The run is recorded with gate not-run: the measure was unevaluable against this node, which is not the same as failed.

A node can satisfy all seven properties and still be unbuildable. Scoped verifies that write paths are enumerated and shared with no concurrent node; nothing verifies that those paths can carry the goal. Observed today: a node fenced to two files passed validation and blocked on arrival, because the behaviour it had to change lived in two further files — exactly one of the two required surfaces was reachable, so the assertion the node existed to make could not truthfully be made.

The escape hatch handled it as designed: the worker audited the call graph, changed nothing, and named both missing files. The cost was still a full dispatch cycle, and the fault was the coordinator's — the fence came from a symbol search rather than from the callers of the thing being changed.

A property that sounds like it guarantees buildability while checking only exclusivity is worse than one that states its own limit. So the cheap half is to report the resolved write scope back from a dry run, letting a coordinator see what it actually fenced before committing a wave to it; and the honest half is to say plainly, in the contract, what scoped does and does not check.

Append refuses a duplicate id across followups, questions, research and comments, naming the existing entry and leaving the version unmoved; a resolve whose id has no open entry returns an error instead of reporting success; and resolve skips a closed duplicate to reach the open match. Validated non-mutatingly against this plan's own live HTML — 2 matching entries, 1 open before and 0 open after — then the stuck record was closed for real. 4 new tests, suite green at 1,703 (commit 6b043e3).

Two sessions independently minted f-uwd-003 against this plan, and the store accepted both. The consequence is not cosmetic: resolve targets by id, so it matched the same article twice and reported success both times while leaving the second followup open. A write that cannot address a record it claims to have written is worse than one that fails, because nothing surfaces the miss — it was caught only by reading the state back and counting.

The neighbouring ledger already refuses this exact shape: append_run rejects a second record for a run id, on the grounds that a double promotion double-counts the very measurements a later reader depends on. A collection whose entries are addressed by id owes the same guarantee, and followups are addressed by id on every resolve.

Two halves, and the second is what makes the first safe to rely on. Append refuses a duplicate id, naming the existing entry, so the collision is a visible error at the moment it is created rather than a silent one later. And a resolve that matches no open entry says so instead of reporting success, which is the failure that hid this one.

The stuck record on this plan is the test case: its content is already folded into §7, and it cannot be closed through any sanctioned write path today — the prose tool correctly refuses to edit structured state, and the state tool cannot reach past the first match.

An active plan below full implementation now carries its own continuation, so an ordinary mid-run resolve passes; at 1.0 a final resolve with no chain answer still refuses, new terminal landings without one still refuse, and plans already recorded as shipped stay writable. The gate that mattered is met directly: the same resolve driven through the ops path and the HTTP patch path returns [true, true], and both persist zero open followups — the two doors that disagreed now answer alike. 5 new tests over 6 cases, suite green at 1,717 (commit ac93488). Reported blocked on a stale base: the 3 roadmap failures it saw had already been fixed on main by a concurrent session before it finished.

The rule that work must not end without naming what comes next is enforced on two write paths, and they disagree. The ops path treats a batch that resolves a followup or sets a terminal status as a landing; the HTTP patch path keys on terminal status alone. The same resolve is therefore refused through one door and accepted through the other — which is exactly the drift the shared definition was introduced to prevent, and the module says so in its own words: one definition exists "so the ops writer and the HTTP patch writer cannot disagree". They share the definition of a continuation. They do not share the trigger.

Resolving a followup is not a landing. A plan left active, below full implementation, with a section dispatched and in flight, has manifestly not ended — yet the refusal reads "plan landing leaves no continuation". An error that misdescribes what happened is worse than no error, because the reader satisfies the string instead of the intent.

And the cheapest way past a false fire corrodes the signal it protects. The outcome text only has to contain "no followup" to pass, so a check firing on ordinary mid-run resolves trains its users to write that phrase into outcomes that are not final. Every false fire devalues the marker for the one case it exists to catch. This was met live: the phrase had to be worded carefully into a genuinely non-final outcome to get a true statement past the check.

Once same-plan follow-on work is folded into sections rather than deferred as followups, zero open followups becomes the normal state of a healthy active plan. A check keyed to that condition fires on the common case and stays quiet on the rare one.

Fix the definition, not the trigger. Narrowing the ops trigger to terminal status would lose a real protection: a session that resolves its driving followup, leaves the plan active and ends naming nothing is the failure this was built for. Instead let a plan that is manifestly still in progress — non-terminal status below full implementation — count as carrying its own continuation. A final resolve on a plan with nothing left still refuses; both fields are already structured state, so nothing has to parse the HTML for a rendering convention that would rot; and the reconciliation lands in the shared definition, which is where the module already says the single truth belongs.

§5 — Constraints

Worker prompts carry fences and a pointer to the live plan. They never copy plan context, decisions, research or done-when prose — a copied brief becomes a second source of truth that drifts between workers and sessions.

The worktree dispatch contract already in references/sprint-orchestration.md §6 remains binding and is not restated: no branch creation or switching, no stash, rebase, clean or hard reset, explicit path staging only, no shared plan-state edits, conventional commit subject and body, no AI attribution, no plan or sprint identifiers in commit messages.

Workers default to the full-access tier bounded by their detached worktree. A node whose only write is its own manifest may be dropped to a read-only tier as a runtime choice; that is routing, not a policy change.

/reckon-ship uniform-worker-dispatch

/reckon-ship crew-run-ledger

/reckon-ship uniform-worker-dispatch

/reckon-ship uniform-worker-dispatch

/reckon-ship uniform-worker-dispatch