Router treats ship checkpoint continuation as plane command

[justinhelmer]

A follow-up intended to resume an aborted ship checkpoint routed to command and executed plane show instead of continuing the coding/ship work.

Message (verbatim):

<@U0BQNU1AD27> resume from checkpoint `88bcd3b42` and finish this task through a clean PR. Invoke the pr-description skill before finalizing the PR body. Ensure issue #3624 and the PR description clearly state that deletion is required because editable `coding-agent` names plus historical scopes cannot establish installer/MCP provenance and can widen unrelated customer REST-key permissions. Keep the explicit record that no UAT or production mutation ran.

Expected preset: coding/ship checkpoint continuation.
Actual preset: command; the response began Plane · 3 live · 19 recent · 5 units · 1 pull requests.

Run: https://switchboard.coreplanelabs.dev/runs/1255b44a-618e-4619-a47e-b5646b8c4ee2
Slack thread: https://coreplanelabs.slack.com/archives/C0BRRHKFLCB/p1790118354325429

The prior ship card explicitly said: “The next reply in this thread resumes from that checkpoint instead of starting over.”

[justinhelmer]

Second checkpoint-continuation failure on the same Slack thread today.

Verbatim message:

<@U0BQNU1AD27> continue from the existing implementation on exact branch `plan/urgently-remove-the-bulk-faaf9f/u1` at `dd97eb92c21788ba7e460fbb6e38315c7a29452f`; do not reimplement or start another Ship pipeline. Invoke the pr-description skill, open the PR from that exact branch, and leave one clean coherent commit. Ensure every PR-body code anchor uses the current full 40-character head SHA. The PR body and nominal#3624 must state that editable `coding-agent` names plus historical scopes cannot establish installer/MCP provenance, so bulk repair can widen unrelated customer REST-key permissions, and explicitly state that no UAT or production mutation ran. Report the PR URL and exact head SHA.

Expected: continue the finished coding session / coding follow-up.
Actual: operator_refusal from door, reason permanent, cause provider; no coding run started.

Run: https://switchboard.coreplanelabs.dev/runs/c3eb6b7d-4569-482e-85e3-fda7f550c495

[justinhelmer]

Fresh recurrence at 2026-09-23T12:45:35.440Z immediately after the #2285 abort on nominal#3692. Boris replied verbatim continue in the aborted ship thread. Command run e58a0e0e-4a01-4dbf-909e-86893a8b7c52 bound that reply to plane show, returned a status table, and started no coding/ship recovery. The operator recorded one bind violation before accepting the wrong command; MCP friction says no friction detected. This is the same checkpoint-continuation-to-plane-command failure and resets the stability clock at the failed recovery finish.

[justinhelmer]

Broken recovery promise: acceptance addition

Rechecked Boris's report and exact continuation run e58a0e0e-4a01-4dbf-909e-86893a8b7c52: the input is verbatim continue, the accepted bind is plane show, and no recovery starts. The operator's rationale was “Show the ended pipeline unit and tracked PR status before continuing”; the promised continuation never occurs. This is the existing recurrence, not a new incident or stability reset.

The prior #2285 abort explicitly promised the next reply would resume. Treat that message and the continuation contract as one user journey:

• An addressed plain continue in the ended unit's thread resolves to that authorized unit, branch, and current remote PR head and resumes the appropriate next operation. An informational command is not fulfillment.
• Preserve budgets, requester authority, exact-head validation/review, and single-owner fencing. Repeated or concurrent replies must not create duplicate work or PRs.
• If continuation cannot occur, name the specific blocker truthfully; do not post a status table as though the request succeeded.
• Show user-facing saved-work state and the concrete next action, without “coding child,” redundant abort wording, or unsupported promises of automatic recovery.
• Prove this with a thread-level regression covering the original abort card followed by continue, plus genuine blocked/ambiguous cases.

No common RCA with the pre-model startup failure #2306 has been demonstrated. One paired stability investigation owner is being admitted with #2285, while #2306 keeps its existing owner. No duplicate recovery of Boris's product PR is authorized by this bookkeeping update.

[justinhelmer]

New post-deployment continuation symptom, tracked here rather than a duplicate issue: September 23, 3:44:53 PM PDT reply says “Unit U1 does not retain the pull request’s durable expected head, so continuation did not start. Nothing else ran.”

Fresh MCP thread read confirms preceding hosted ship 5756bdc7-2f1e-4a7b-b3cd-af438021d3c3 / plan-implement-the-task-this-070c52 completed merge-ready. Its findings coder 2e716754 pushed de411e9c08969d2bbc8ca1cfdc307eac95e6912b, and reviewer d77ad699 approved that exact head. Thus code/review head evidence exists, yet continuation reports the durable unit expected-head prerequisite missing. Parent friction says no friction detected; that does not cover the subsequent refusal.

This is a new observed failure mode within the existing continuation contract after the #2324 repair shipped, NOT proof that its fail-closed guard should be relaxed. Preserve the guard; determine why authoritative unit state lacks the expected head or is not read correctly. Common root cause with active #2200 binding repair is not established. Existing shared continuation/binding owner should triage before admitting another writer. Website #397 subsequently merged through its existing ownership lane; do not restart its obsolete adoption pipeline.

[justinhelmer]

Triage result: distinct from #2200, but adjacent at the durable binding boundary. This is a missing write, not a permissive-read problem. No new writer is admitted.

Evidence from the affected durable unit (plan-implement-the-task-this-070c52:U1): the unit row retains PR #397 and the merge_ready ending, but has no lastPush; the findings coder record carries headSha=de411e9c08969d2bbc8ca1cfdc307eac95e6912b, and the final reviewer approved that exact head. The continuation gate therefore read the row truthfully and failed closed.

The missing write is mechanical:

• driver.ts at deployed main sends headSha to unit-end only for review_pending (or an idle review-pending state), not for merge_ready.
• adminCoordinator.ts persists lastPush only when that unit-end body carries headSha.
• dispatcher.ts correctly refuses continuation when unit.lastPush is absent.

#2200 / PR #2332 establishes and fences exact existing-PR publication authority while coding is active. It does not change the merge_ready unit-end write above or replace #2265 continuation’s unit.lastPush prerequisite. Therefore #2332 should not be expanded or amended for this symptom. The follow-up belongs under #2265: persist the final exact reviewed PR head on terminal resumable rows (at minimum merge_ready), and prove the adopted-PR case where findings move the head before approval, followed by a post-ending continuation. Preserve the current fail-closed read and all authorization/budget/ownership guards.

PR #397 is merged; no product recovery or rerun is needed.

[justinhelmer]

Promoted P2 → P1: confirmed direct blocker of the existing nominal#3589 delivery, even after #2332 deployment. Parent admission owner ses_f33636c39ffeSqqWRFhI35afhw; existing continuation/binding owner ses_f3153e8c0ffeVycGKdtmAHeBka retains the repair scope. First eligible binding-recovery repair after the current fleet-drain/deployment hold is explicitly released, ahead of routine backlog; no writer admitted during the hold.

Evidence: #2200 (comment) and the #397 terminal-write diagnosis #2265 (comment) . Retained #3589 U1 has neither lastPush nor publication binding; #2332 cannot migrate that durable state. No supported same-owner recovery command exists, so a deploy-and-retry promise would be false.

Acceptance: persist reviewed head on future merge_ready endings; recover legacy state only from the SAME unit durable child/review evidence; verify current repository/PR/branch/base/head/requester/sole owner; atomically persist lastPush and complete binding. Fail closed on absent/ambiguous/moved/foreign/changed-owner evidence. Preserve normal repo:use authorization and exact-ref fencing. No directive, new thread/pipeline/ref, direct state injection or alternate identity as recovery. No #397 rerun. Existing #3589 owner retains product changes. Parent rechecks admission on fleet-drain event and coordinated release disposition; this issue is now an explicit additional prerequisite for #3589 acceptance, not claimed fixed by #2332.

[justinhelmer]

Recurrence on September 23, 2026 at 8:30:12 PM PDT: a post-review ready-state follow-up for coreplanelabs/nominal#3736 at exact head c5bad312bc148e8f4d4f3d9b501ab20ad43ef2f2 was refused before run creation with Unit U1 does not retain the pull request\x27s durable expected head, so continuation did not start. Nothing else ran. Source: https://coreplanelabs.slack.com/archives/C0BRRHKFLCB/p1790220610866799?thread_ts=1790217952.394079&cid=C0BRRHKFLCB. Expected: continue the existing coding owner/PR with the current durable head; actual: no run. Recovery will use an explicit coding continuation only after this closed refusal.

[justinhelmer]

Recovery generated a forbidden alternate durable unit/ref

The September 23, 2026, 8:16:26 PM PDT recovery reply in the original Slack thread explicitly named existing ref plan/fix-issue-2265-s-missing-b41c79/u1 at exact SHA a75d6d429cabddfe587dfef5e1ed1745d1e02e31, required reconciliation of that work, and said “do not … create an alternate branch.”

Ship f790005f-364f-4144-9b49-b4430847a557 nevertheless created a distinct durable instance plan-fix-issue-2265-s-missing-9cd02b and advertised new ref plan/fix-issue-2265-s-missing-9cd02b/u1. Coding child 7f8b42e0-8d6a-4e32-9ce8-001b53478c34 confirms that ref in run_meta; it began from main, fetched the requested original branch, and fast-forwarded the generated alternate worktree to the preserved commit. It did not reimplement the patch, but post-stop salvage published the same commit to the alternate remote ref.

The parent was hard-stopped at 8:17:14 PM PDT because this violated exact-ref/single-unit recovery. The child received its hard stop at 8:18:47 PM PDT, sealed stopped_hard, and still recorded/pushed a75d6d4 on the alternate ref by salvage. No PR was opened from that ref, and it is not authorized for publication or continuation.

This is concrete evidence that same Slack thread context does not preserve durable unit/ref identity for a re-issued agent:ship task. A recovery request that binds an existing unit/ref must either resume that exact durable unit/ref or refuse before spawning; generating a new plan/ref and copying the commit is not supported reconciliation. Hard-stop handling should also prevent a stopped child from publishing the alternate ref after its parent is sealed.

Authorized recovery stayed on the original ref. PR #2336 now heads plan/fix-issue-2265-s-missing-b41c79/u1 at 5ad85961a1b11f8bf29a3e059c5cf4bff46d49c4, approved with green CI. No alternate-ref PR or additional writer is being admitted.

[justinhelmer]

Additional pre-PR refusal case — not evidence that #2336 fixes it

Justin flagged this September 23, 2026, 10:15:41 PM PDT reply: “Unit U1 does not retain a durable pull request identity, so continuation did not start. Nothing else ran.”

Fresh MCP runs.unit confirms plan-implement-the-narrow-dia-71a097:U1 ended held before edits and before any PR existed. Coding run f6d7342a-f117-4f1b-85b3-4e8c0ef2141f stopped at unchanged 652eb70199d24be067ee91e1c9e14f48770a594c; the unit has no PR identity. Parent ba257df6-026c-4bff-a9c1-5af4cf454b81 ended held/failed. Its empty friction result does not diagnose the later refusal.

Important distinction: the immediately preceding scope-only message explicitly said “This note does not restart it or release held files.” The bot nevertheless answered as though continuation had been requested. No later run was admitted. The fail-closed missing-PR guard is correct for the operation it was asked to perform; a scope-only/no-restart update should not be treated as a continuation request in the first place.

Tracking this evidence under the existing continuation contract, adjacent to #2223 follow-up intent handling. This is not the merge-ready missing-reviewed-head case addressed by #2336: here no PR ever existed. Common root cause and coverage by that patch are unproven. No new writer, retry, scope grant or product continuation is authorized by this receipt; the source message is historical and does not supersede current authority.

[justinhelmer]

September 24, 2026, 7:39 AM PDT additional retained-recovery counterexample: PR #2338 ended no_verdict at unchanged982ed0df. A serialized same-thread recovery explicitly required original unit plan-investigate-and-fix-http-61d7c2:U1 and original ref, refusing any new task/unit/ref. Nevertheless Ship2b51be45 created plan-re-issue-the-retained-23-6bb101 and its new ref. Parent stopped that Ship and separately stopped coding child75f67433; both terminal and no active runs remain in the thread. Original PR still OPEN at exact982ed0df. Child records salvage of unchanged releasebaseb727e587 on the unintended ref; no cleanup deletion performed. The read-only diagnosis had incorrectly claimed this re-issue path preserved unit identity; live readback disproves that. Do not repeat this recovery or substitute a standalone review as proof that the original unit resumed. Original provider-terminal diagnostic gap is separately tracked in #2340. Existing #2265 owner retains dependency repair; no second writer admitted.

[justinhelmer]

Post-#2336 recurrence on September 24, 2026 at 10:36 AM PDT, under live build 1.261.4 / 9f4d0f4c9645ea67ecab3ede2455e658f38a7d4c (which contains #2336).

A new top-level recovery request explicitly named existing nominal PR https://github.com/coreplanelabs/nominal/pull/3763, exact remote head 6414a211abf531e976bf9d66b9af1616a534419c, exact branch plan/fix-issue-3762-the-admin-fc9c12/u1, and required “Adopt and update this exact PR/ref only—do not create a replacement PR/ref.” Switchboard routed correctly to ship but generated a different durable instance/ref:

• Slack: https://coreplanelabs.slack.com/archives/C0BRRHKFLCB/p1790271359153759
• ship: 0b046f1f-d8cb-4f0d-b24c-945e911f72f7
• coding: 513e2879-9c69-486c-a423-15f78b0f11ec
• generated unit/ref: plan-continue-the-existing-pr-1199a8:U1 / plan/continue-the-existing-pr-1199a8/u1

The pipeline was hard-stopped immediately after MCP readback exposed the alternate unit/ref. Parent sealed failed; child sealed stopped_hard before implementation. The stop salvage nevertheless pushed unchanged attach head 9efb20ea0700f7f57499c1047c0730bd7eafc682 to the unauthorized alternate ref. No PR was opened from it, nominal#3763 remains unchanged at 6414a211, and no credential/deploy/product-state mutation occurred.

This is the existing owner-preserving continuation/adoption contract, not a new issue. It also reproduces the already-recorded hard-stop salvage symptom: stopping the structurally wrong recovery still publishes its generated ref. Do not admit another product writer until the existing exact PR/ref can be resumed without generating or salvaging an alternate ref. The nominal PR now has an independently identified acceptance blocker (Select All can choose 64 platform scopes where the approved CLI set is exactly 57), so old-head green CI is not merge readiness.