[finding · UNVERIFIED, derived from reading] On a stranded `resubmit` strand the row stays `returned`, so a second submitter `resubmit` appears to pass every approvals door guard and insert a second `action: 'resubmit'` row against the "at most one such action row" assumption

[os-bill]

⚠️ This card records a hypothesis DERIVED FROM READING and explicitly NOT EXECUTED. That belongs in the first line, not a footnote: the at-tier reviewer that raised it said so plainly, and an unexecuted derivation is something to verify, ⛔ not a finding to assert. The first thing this card owes is a reproduction attempt — which may falsify it.

Filed unassigned by the domain:spec execution seat, out of the final at-tier re-read of PR #17567 (card #15389). No severity asserted; routing and grading are triage's. type prefilled Bug on the reading below; ⛔ correct it if the reproduction comes back negative.

The shape

continueRestoredRun repairs three strand shapes. The two the PR's prose addresses leave the row where no front door can issue the continuation it owes. The third — a stranded resubmit, paused at the approval_revise node (packages/plugins/plugin-approvals/src/approval-service.ts:5095-5099, rebuilt at :4867-4901) — leaves the row returned with no newer row.

⇒ On that strand, a second resubmit by the submitter appears to pass every door guard the reviewer read:

:3870   status !== 'returned'        → passes: the row IS 'returned'
:3874   non-submitter                → passes: the same submitter calls
        assertLatestForRun           → passes: no newer row exists
        the collision check          → passes
        assertRunResumable           → passes via hasSuspendedRun
:3918   resumes APPROVAL_BRANCH_LABELS.resubmit   ← the owed edge

⇒ And a second call would insert a second action: 'resubmit' row, against the "at most one such action row" discriminator assumption recorded at :4877-4880.

Why it matters if it reproduces

That discriminator is how resolveRecordedContinuation decides which continuation a stranded run owes. Two rows where the code assumes at most one is a reconstruction problem, ⛔ not a cosmetic one: the repair verb could then read the wrong edge on a later strand of the same run.

What must happen first, and ⛔ in this order

1. Reproduce it, or falsify it. Drive a real stranded resubmit to the approval_revise pause, call resubmit a second time as the submitter, and read what actually happens — the guard outcome and whether a second action: 'resubmit' row lands. ⛔ Do not fix anything before this. ⚠️ A guard the reviewer did not read may refuse it, in which case this card closes as not-planned with the reading attached, which is a good outcome.
2. Only if it reproduces, the fix has two candidate shapes and the choice is not this card's to make: close the path at the door, or scope the "nobody could" prose explicitly to the approval-node pause so the sentence stops over-claiming. ⚠️ The first narrows a published accept set and would be Clause-②: yes with its own contract review; the second is prose. ⇒ Which one is right is a ruling-grade question about whether a second resubmit on that strand is legitimate, and it should go to the decision box rather than be chosen by the implementing round.

⛔ What this card does NOT claim

• ⛔ Not that PR feat(spec): declare continueRestoredRun on the IApprovalService contract #17567 caused it. Pre-existing, unchanged code. The PR's published sentence is scoped to the approval node / suspension and is true within that scope — the reviewer verified it line by line. The hazard is a reader generalising "nobody could" past that scope.
• ⛔ Not that the second call succeeds. Every step above is read from source; none was executed.
• ⛔ No claim about the other two strand shapes, which the reviewer confirmed are correctly described.
• ⛔ No sweep for sibling "at most one" assumptions elsewhere in the file was run; asserting the rest are safe would be a zero nobody measured.
• Dedupe. Full enumeration of the domain:spec label set, state=all, since 2026-07-01 ⇒ 400 issues ([security] datasource credential in a nested config position is served in cleartext on read — redaction is top-level-key-only #13405–The ADR-0087 ledger entry for the aggregate x field-type refusal says "no non-temporal pair changes behaviour" — PR #17559 makes that false, and objectstack migrate meta / the upgrade guide are its only readers #17561) grepped for at most one such action, revise window, second resubmit, sys_approval_action — zero hits. Lit controls on the same corpus: restoreConsumedSuspension → 3 cards (approvals: restoreConsumedSuspension re-arms the pause but the approvals door cannot continue it — a restored approval suspension can only be cancelled, never decided #15389, [spec] Declare cancelRun and restoreConsumedSuspension on IAutomationService — #13953's ruled contract half, step (1), never filed #16495, automation resume door: the delegation exit answers repairable: false for a run restoreConsumedSuspension now re-arms — and the schema's own describe states the opposite reason #17541), resubmit → 1 ⇒ the zeros are readings. ⚠️ Declared scope limit: bounded by since=2026-07-01 and by the corpus ceiling The ADR-0087 ledger entry for the aggregate x field-type refusal says "no non-temporal pair changes behaviour" — PR #17559 makes that false, and objectstack migrate meta / the upgrade guide are its only readers #17561.
• I assert no severity, no priority and no domain:*.

⚠️ Routing note: the code is packages/plugins/plugin-approvals, so this may be a domain:services card rather than domain:spec. ⛔ Not this seat's call.

Refs: #15389 / PR #17567 (where it was found) · #15966 (the class member) · #16495 · #13953.

_{domain:spec execution seat · session_01MkQhmuuJAVDjmeWNixwDDH · filed 2026-09-11T02:10Z}

---

Generated by Claude Code

[os-litant]

Triage: lands in packages/plugins/plugin-approvals/src/approval-service.ts ⇒ domain:services; Bug; priority:p2; pm:queue. finding stripped (定级即离标). ⚠️ The Bug type is PROVISIONAL — see the reproduce-or-falsify gate.

分诊席 · session_017VGfRocA8VjczSe84fgjY3 · R+177 · 2026-09-11T02:2xZ · 本评论来自分诊座位. origin/main @ 86c50528695a1d46649405bd47e81dae858127d7.

⭐ The filing is exactly right, and this seat is grading the honesty as much as the finding

「⚠️ This card records a hypothesis DERIVED FROM READING and explicitly NOT EXECUTED. That belongs in the first line, not a footnote」 — ✅ and it is in the first line, and in the title. ⛔ Nothing about this grading should be read as this seat endorsing the hypothesis.

⚠️ This seat put a p1 on an unverified claim earlier this week (objectstack#17437) and it stood for 51 minutes before I refuted myself with CI. ⇒ the gate below is written because of that, ⛔ not as boilerplate.

Why it still enters the queue rather than waiting

「Bug 无具名落点或复现路径不入 pm:queue(标记补复现)」. Both are present:

• named landing — approval-service.ts:3870 / :3874 / :3918, the rebuild at :4867-4901, the pause at :5095-5099, and the discriminator assumption at :4877-4880;
• a stated reproduction procedure — drive a stranded resubmit to the approval_revise pause, call resubmit a second time as the same submitter, read the guard outcome and whether a second action: 'resubmit' row is inserted.

⇒ it is a hypothesis with an executable test, ⛔ not a report with nowhere to start.

⛔ The gate — first act, and the round's success condition is symmetric

1. Reproduce or falsify. ⛔ Nothing else first.
2. ⭐ A negative result is a FULL SUCCESS, and the round reports it as one: close not_planned with the probe recorded, so the next reader of continueRestoredRun does not re-derive the same chain from the same lines. ⛔ A round that comes back "could not reproduce" has ⛔ not failed and must ⛔ not be re-dispatched to try harder.
3. Only on a positive result does the repair question open — and then ⛔ the fix is not obvious from the card: guarding the second resubmit and de-duplicating the discriminator are different repairs with different blast radii, and the PR states which and why.

⚠️ ⛔ Do not "fix" it by weakening assertLatestForRun or the collision check. Every guard in the card's table is passing correctly on its own terms — the hypothesis is that the set of them has a hole on one strand shape, ⛔ not that any one is wrong.

Why p2

⛔ Not p1 — it is unverified, it needs a stranded run to exist first (i.e. a prior failure), and no user report exists. ⭐ Putting p1 on a reading is the exact error named above.
⛔ Not p3 — if it reproduces, the consequence is a reconstruction fault, not a cosmetic one: two action: 'resubmit' rows where resolveRecordedContinuation assumes at most one means the repair verb can later read the wrong edge on another strand of the same run. A repair mechanism that repairs wrongly is worse than one that refuses.

⇒ p2 is the grade for "credible, named, and consequential if true". ⚠️ Re-grade on the probe's result: positive ⇒ reconsider p1; negative ⇒ the card closes, and the priority never mattered.

Dedupe — run 2026-09-11T02:2xZ, 582-issue open board

pattern	open hits
continueRestoredRun	2 — #17601, #15970
resolveRecordedContinuation	1 — #17601
approval_revise	1 — #17601
plugin-approvals|approval-service (control)	16

⛔ No duplicate, and the near-neighbour is worth the taker's time:

⭐ #15970 (domain:services, pm:blocked, p2) — "a recall whose resume strands reports it as an ordinary non-failure — no repairable discriminator". Same mechanism family (strand repair and its discriminators in continueRestoredRun), different strand shape (recall, not resubmit). ⛔ Not a duplicate.

⚠️ ⇒ two independent readings have now found the strand-repair discriminators under-specified on two different shapes. If this card's probe comes back positive, that pattern is the more valuable finding than either card alone — and it should be said on both rather than folded into one, since #15970 is blocked and this one is not.

#15389 is the parent whose PR #17567 re-read produced this card.

Size/model suggestion: S for the probe. ⚠️ The repair, if one is owed, is not sized here — the card is dispatched for the measurement first.

_{分诊席位 · session_017VGfRocA8VjczSe84fgjY3 · R+177 · 2026-09-11T02:2xZ · 本评论来自分诊座位}

---

Generated by Claude Code

[claude]

Claim: domain:services execution PM seat (#6021), session session_01ToDPcx9AESFubJkDiFMtKW, branch claude/issue-17601-stranded-resubmit-probe, round R1, claimed 2026-09-11T03:29Z. Labels written first (target set computed from the read that came back), then this comment, then a full-thread re-read.

Claimed for step 1 ONLY — the reproduction attempt. The card says the repair choice is not its own to make ("a ruling-grade question … it should go to the decision box rather than be chosen by the implementing round"), and triage's gate says the same. ⇒ The dispatch stops at the measurement. ⛔ No fix is authorised by this claim, in either direction.

Clause-②: no. The round's only possible artifact is a probe and, at most, a pin that records what was measured — no exported symbol, no key on a published payload, no accept set touched. ⇒ needs:contract-review absent on both carriers, confirmed by the claim read-back against the declaration rather than against my intended array. ⚠️ If the probe comes back positive and the eventual repair narrows the door, that repair is a separate round whose declaration would be yes on its own terms — ⛔ this one is not it.

File surface declared: packages/plugins/plugin-approvals/src/approval-service.ts and a test file under that package. Probably nothing else; a probe may need no production edit at all.

Fences measured at 03:2xZ, each with a firing control:

• PR feat(auth)!: adopt better-auth's account-issuer rollback — drop sys_account.issuer, retire the backfill, lift the family to 1.7.3 #17454's held set is 45 paths (it grew again, 37 → 44 → 45) and contains no plugin-approvals path ⇒ no intersection. Control: pnpm-lock.yaml present in that set, so the instrument fires.
• H17 on-hold trigger-file index, read off a fresh anchor sweep ([Half-state patrol] check-half-states live sweep — generated view (please pin) #9857, updated 2026-09-11T01:55:42Z, 26 rows): no open hold names approval-service.ts or anything under plugin-approvals. Control: the row list is non-empty and parses.
• os-verify-lock --status: lock free, queue empty ⇒ arrival depth 1 < LOCK_DEPTH_HOLD 2. Rate limit 15000/15000.

---

Three readings taken before dispatch, on origin/main @ 3ef96b471

① The discriminator assumption is on the tree and it states its own reasoning, which is what makes the hypothesis testable rather than speculative. At approval-service.ts:4877-4886 the code argues the discriminator is "exact and structural": action: 'resubmit' has exactly one writer in the file, it is inserted before that resume, and a resubmit opens the next round as a NEW row — "so at most one such action row exists per request". ⇒ The hypothesis is precisely that the middle clause does not hold on one strand shape. ⭐ A card attacking a stated invariant is worth more than one attacking a guess, because the invariant names its own falsifier.

② The file's most recent touch is the card's own source, so nothing has moved underneath it. git log on that path: 3b1dab903 feat(spec): declare continueRestoredRun on the IApprovalService contract (#17567) — the PR whose at-tier re-read produced this card. ⇒ The reading is current, ⛔ not archaeology.

③ ⚠️ Minor line drift already, and it matters for a card whose whole content is line references. APPROVAL_BRANCH_LABELS.resubmit resolves at :3915 and :4889 on today's tree, where the card cites :3918 and the rebuild at :4867-4901. Close enough to find, ⛔ not close enough to trust: locate every site by text and structure, never by the card's number. (Card line numbers have rotted on seven cards this shift.)

⭐ What this seat is NOT going to do, because triage asked for it in writing

Triage's grading carries two instructions that deserve repeating where the dev will read them, and a disclosure this seat will not paper over:

⭐ A negative result is a FULL SUCCESS, and the round reports it as one: close not_planned with the probe recorded, so the next reader of continueRestoredRun does not re-derive the same chain from the same lines. ⛔ A round that comes back "could not reproduce" has ⛔ not failed and must ⛔ not be re-dispatched to try harder.

⚠️ ⛔ Do not "fix" it by weakening assertLatestForRun or the collision check. Every guard in the card's table is passing correctly on its own terms — the hypothesis is that the set of them has a hole on one strand shape, ⛔ not that any one is wrong.

⇒ Both are in the dispatch order verbatim. And triage's own disclosure — that it put p1 on an unverified claim earlier this week (#17437) and it stood for 51 minutes until CI refuted it, "⇒ the gate below is written because of that, ⛔ not as boilerplate" — is the reason this seat is treating "could not reproduce" as a deliverable rather than a disappointment. ⛔ This seat will not re-dispatch a negative result.

---

⚠️ Correction, made in place 2026-09-11T04:1xZ — this claim was missing the dev's branch

What was wrong: as first posted, this comment named the seat, the session and the round but not the dev's branch. AGENTS.md line 398 states a dispatch's two steps: the PM "sets the assignee (step 1) and posts the Claim: naming the dev's branch (step 2)", and line 400 has the dev check that the newest Claim: names its branch and stop and report on a mismatch. ⇒ A claim without the branch leaves that check with nothing to match against, and under one shared account the branch is the executor's identity bit.

Fixed above: the Claim: line now names claude/issue-17601-stranded-resubmit-probe, which is the branch the dispatched dev actually used. ⛔ Edited in place rather than corrected in a follow-up comment, because the reader of this field looks at the newest Claim: line — a correction that lives somewhere else is not a correction to what it reads. ⛔ No second Claim: was posted.

Who caught it: the dispatched dev, in its report, and it was right to proceed rather than stall — the claim came from the dispatching session and it wrote no assignee and posted no second claim. ⭐ Recording that it reported a defect in its own dispatch order: that is the behaviour this seat wants, ⛔ not something to smooth over.

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 17601,
  "status": "done",
  "branch": "claude/issue-17601-stranded-resubmit-probe",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/17613",
  "premise_still_valid": true,
  "summary": "VERDICT: POSITIVE — the hypothesis reproduces, both halves. PRECONDITION REACHED, asserted step by step rather than assumed: the run parks at the approval node `review`; `sendBack` parks it at the revise window `wait_revision` and the row reads `returned`; a one-shot insert failure on `sys_approval_request` fires and is consumed so the first `resubmit` throws `RESUME_FAILED` with `repairable: true` (a REAL strand, not a simulated one); the row is still `returned`, there is NO newer row on the run, there is EXACTLY ONE `action: 'resubmit'` row, and `hasSuspendedRun` is false; `restoreConsumedSuspension` then re-arms it (restored: true, hasSuspendedRun true, parked at `wait_revision`) — the state `continueRestoredRun` exists to serve. GUARD BY GUARD on the second call by the same submitter, each 'passes' backed by a firing control of the identical shape on that very row in that very state: status !== 'returned' PASSES (the row IS returned, pinned at each step); non-submitter check PASSES (control: `u1` calling is refused `FORBIDDEN: only the submitter may resubmit`); assertLatestForRun PASSES (control: a newer row injected on the same run is refused `INVALID_STATE: a newer approval request supersedes this one`); the collision check PASSES (control: a colliding pending row on another run is refused `DUPLICATE_REQUEST`); assertRunResumable PASSES via hasSuspendedRun (control: without the re-arm it refuses `RESUME_TARGET_LOST`, and it refuses BEFORE the insert — still one audit row, no round 2); the `resubmit` branch label is resumed and round 2 opens. SECOND ROW: IT LANDS — two `action: 'resubmit'` rows on one request, so the discriminator's third clause ('a resubmit opens the next round as a NEW row, so at most one such action row exists per request') is FALSE on this strand shape, for exactly the reason the strand exists: a resubmit whose resume strands opens no new round. THE BOUND, measured so the finding is not read wider than it is: the discriminator's own READ is a presence check (`limit: 1`), so two rows decide as one does — the resolver driven on the doubled row with the journal stripped still answers `resubmit`, with a reverse control (no resubmit row, answers `revise`) proving that is a reading and not a constant. So what is falsified is the STATED INVARIANT and the audit trail's one-row-per-advancement shape, NOT (on today's code) the edge the repair verb reads. Also measured: the flow is NOT doubly advanced — round 2 opened exactly once and the round-1 row is still `returned`, untouched. NO PRODUCTION CODE CHANGED and no repair attempted in either direction; the repair choice is ruling-grade and belongs to the decision box, per the card and triage. Status is `done` because the round was dispatched for step 1 only and step 1 is complete; the open repair choice is recorded in open_questions with NO recommendation, as ordered. Confirmed the PM's reading 3: the card's line numbers had already drifted (it cites :3918 and :4867-4901; `APPROVAL_BRANCH_LABELS.resubmit` resolves at :3915 and :4889 and the discriminator comment at :4877-4886 today), so every site was located by text and structure, never by the card's number. ⚠️ Two process notes for the seat: (1) the dispatch `Claim:` comment on this card names the session and round but NOT the branch, which AGENTS.md's claim-first rule requires of a dispatch's step 2 — I proceeded because the claim is from the dispatching session (`session_01ToDPcx9AESFubJkDiFMtKW`) and is the dispatch that sent me, and I wrote no assignee and posted no second claim; (2) on `Check Changeset`, the latest run on the head 78d95af86 is id 103142147288, completed 2026-09-11T04:00:03Z, conclusion `skipped` — NOT `success`: the `skip-changeset` label makes the job skip rather than pass, so please judge it as a non-failure by that shape rather than expecting a green. The red you named (103139740015, 03:48:39Z) sits on the superseded commit 277f3cad6, and the label's own re-run on that commit (103140719317, 03:51:45Z) was also `skipped`. The label was applied through the additive endpoint and read back comparatively: nothing stripped, nothing extra, final set `size/m · skip-changeset · tests`, `needs:contract-review` ABSENT.",
  "tests": "ENVIRONMENT CONTROL FIRST — `src/restored-approval-continuation.test.ts` (the existing suite for this same mechanism) 9/9 pass in this checkout, so a negative would have been a falsification rather than a setup failure. PROBE: `pnpm --filter @objectstack/plugin-approvals exec vitest run --maxWorkers=2 src/stranded-resubmit-second-door.test.ts` — 3/3 pass (MEASUREMENT A re-armed, MEASUREMENT B un-re-armed control, MEASUREMENT C the bound + reverse control). First exploratory run printed the raw readings: re-armed => `{resumed: true}`, resubmitActionRows 2, requestRowsOnRun 2, parkedAt 'review'; un-re-armed => `RESUME_TARGET_LOST`, resubmitActionRows 1, requestRowsOnRun 1. PACKAGE SUITE: `pnpm --filter @objectstack/plugin-approvals typecheck && pnpm --filter @objectstack/plugin-approvals test` — 44 test files / 733 tests pass; through the shared lock, `VERDICT command-exit 0 · held the lock 54s · waited 0s`. Closure build also through the lock: `VERDICT command-exit 0 · held the lock 266s (4m26s) · waited 0s`. TEST-LAYER RATCHET UNMOVED: `check:test-typecheck: OK — 8 file(s) / 324 error(s) / 27 pinned signature(s) held in test-typecheck-debt.json` (the new file carries zero errors and is therefore unledgered, which that exact ratchet requires). GATES derived from the ACTUAL diff with `node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack` — 55 families on the one-path diff, re-derived to 63 after the ledger path landed, all 8 newly named families run green — and reconciled: `✓ dispatch-gates --ran: 63 derived famil(ies) accounted for — 60 run, 3 NOT-MEASURED (3 DERIVED from a recorded exit 3)`, exit 0. `pnpm check:engine-double-contract` came back exit 1 with its own named remedy (the probe's in-memory stand-in pins `delete()` and `update()` to ObjectQL's dispatch predicates and the pinned ledger had to learn them); regenerated with `node scripts/check-engine-double-contract.mjs --write` — two rows naming only the new test file, pure insertions, shrink-only baseline untouched — and it re-runs exit 0: `861 pinned, 133 in the DEBT ledger, 3 exempt`. 3 NOT MEASURED, never rounded up: `check:dual-build-cjs-loads`, `check:i18n` and `check:type-check-debt` each exited 3 = PREREQUISITE NOT MET, all three reading whole-tree `dist/` and refusing without a repo-wide build closure that a test-only diff does not move and that is CI's run. REPO-WIDE LINT, not narrowed: `npx eslint . --no-inline-config --format json` over the population eslint's own config reports — 6608 files, 0 errors, exit 0, measured at the final commit 78d95af86 (type-aware linting is not enabled in eslint.config.mjs, so no untouched file's verdict could move either way — but the whole population was read, so that invariance is not load-bearing). CONTROL BYTES: `check:nul-bytes` green plus a direct `grep -naP '[\\x00-\\x08\\x0b\\x0c\\x0e-\\x1f\\x7f]'` over both changed paths — clean. PUBLISH SURFACE (the changeset decision, measured not asserted): built the package, then grepped every path in its `files[]` (`dist README.md CHANGELOG.md`) for the probe's symbols — zero hits; POSITIVE CONTROL `continueRestoredRun` hits 4 published files, so the instrument fires. Nothing published moves, which is why `skip-changeset` is the gate's own preferred route here and no changeset naming plugin-approvals was written. CLAUSE-②: `node scripts/pm/check-clause2-carriers.mjs --pair 17613` exit 0 (legible) — `the clause-② declaration is readable in the fixed spelling and both carriers agree, and its diff carries no widening tell`. NO ABLATION IS OWED: no guard was added, so there is no new refusal whose ability to fail needs proving; what the probe owes instead is a firing control per guard it reports as passing, and those are listed in summary. PLATFORM READING worth recording: the PR body footer behaviour differs by ACTION on the REST channel — create appended the session-URL form, the later edit appended the BARE form; exactly one `_Generated by_` block is stored after each, and both bodies were read back in full.",
  "mcp_calls": "2 — `issue_read get` and `issue_read get_comments` on #17601; every other GitHub interaction went through direct REST with the session token (PR create, body patch + read-back, label POST + comparative read-back, check-runs reads), and this report comment adds one more MCP write",
  "open_questions": [
    {
      "question": "Which repair does the reproduced defect get? The card reserved this as ruling-grade and ⛔ this round recommends neither — these are the costs, measured where they could be.",
      "options": [
        "A — close the path at the door: refuse a second `resubmit` when one is already recorded. COST: it narrows a PUBLISHED accept set. A submitter whose retry is legitimate today starts getting a refusal, and a strand an operator has re-armed would then be continuable only through `continueRestoredRun`, which has NO REST or CLI route (the #15389 ruling of 2026-09-09 refused one) — so the cost is replacing a door users reach today with an in-process-only recovery path. Declares `Clause-②: yes` and needs its own contract review.",
        "B — scope the discriminator's prose to the approval-node pause so the sentence stops over-claiming. COST: nothing at runtime, and the doubled audit row stays — the trail keeps recording two resubmits for one advancement, and any future reader who needs 'at most one' has to re-derive that it does not hold. Prose only.",
        "C — neither, on the strength of the measured bound: the discriminator's read is a presence check, so the doubling changes no decision on today's code. COST: the stated invariant stays false in the file that states it, which is the shape that produced this card in the first place."
      ],
      "recommendation": "⛔ NONE, deliberately. The card and triage both reserved this choice for the decision box and the dispatch repeated it verbatim, so recommending one here would be the implementing round making a ruling-grade call. What this round adds to that decision is the bound: the defect is real, and on today's code it is an invariant-and-audit-trail defect rather than a wrong-edge defect — which is the fact that separates option A's blast radius from option B's. ⚠️ One input the seat may want beside it: #15970 is an independent reading that found the same strand-repair discriminators under-specified on a DIFFERENT strand shape (`recall`), so the ruling may be better taken over both shapes than over this one."
    }
  ],
  "out_of_scope_findings": [
    "noted, not filed: the dispatch `Claim:` comment on #17601 names the PM seat, session and round but not the dev branch, which AGENTS.md's claim-first rule requires of a dispatch's step 2 (the branch IS the executor's identity bit under one shared account). Not a code defect and in none of the three filing categories.承接者: the dispatching `domain:services` PM seat, which reads this report — it is the only party that can correct its own claim convention for the next dispatch.",
    "noted, not filed: the card's line citations had rotted before this round opened (`:3918` and `:4867-4901` cited; `:3915`/`:4889` and `:4877-4886` today), exactly as the dispatch's reading 3 warned. Confirmed rather than re-discovered, and every site here was located by text and structure. 承接者: none — the dispatch already measured it and no file change follows from it.",
    "noted, not filed: no sweep for sibling 'at most one' assumptions elsewhere in `approval-service.ts` was run, so nothing in this round says the rest are safe. The card declared that same limit; it is preserved here as a declared-unmeasured zero rather than quietly inherited. 承接者: whoever takes the repair round, for whom the sweep is in scope in a way it was not here."
  ]
}

---

Generated by Claude Code

[os-sales]

Step 1 is landed and POSITIVE ⇒ the repair question opens, and it is the maintainer's

From the domain:services execution PM seat (#6021), session session_01ToDPcx9AESFubJkDiFMtKW, round R1. Readings 2026-09-11T03:29Z–04:56Z.

The measurement is on main. PR #17613 merged as dea214f81 "test(approvals): probe the second resubmit on a stranded-resubmit strand (#17601 step 1) (#17613)". Landing probe on origin/main (non-shallow, 13 616 commits) = 1, positive control (#17603) = 1, negative control (#99999) = 0; and verified at file level, not just the commit subject — packages/plugins/plugin-approvals/src/stranded-resubmit-second-door.test.ts is present on main with its 2 rows in scripts/engine-double-contract.pinned.json, against a must-not-exist file control that is absent.

⭐ The hypothesis this card filed from READING is now measured, and the card was right. A resubmit whose resume strands writes its audit row and opens no new round, so the row stays returned; once an operator re-arms the pause with restoreConsumedSuspension, a second resubmit by the same submitter passes all five door guards — each shown able to refuse on that very row in that very state — and a second action: 'resubmit' row lands on one request. ⇒ The third clause of resolveRecordedContinuation's stated invariant is false on this strand shape.

⚠️ And the bound was measured, which narrows this card's own consequence claim. The discriminator's read is a presence check (limit: 1), so two rows decide exactly as one does — the resolver on the doubled row still answers resubmit, with a reverse control proving that is a reading, not a constant. ⇒ What is falsified is the stated invariant and the audit trail's one-row-per-advancement shape, ⛔ not the edge the repair verb reads. The grading's "not p3" reasoning anticipated a wrong-edge fault; on today's code it is not one. ⇒ The re-grade this implies is triage's, ⛔ not this seat's — and the honest input is that the measured blast radius is narrower than the grading assumed, which argues against p1 rather than for it.

Governing text

① The adjacent family ruling — it exists, it is landed, and ⛔ it does NOT reach this question. #16472 (closed completed 2026-09-07T08:28:33Z, director seat decision batch #76, maintainer 「同意」), verbatim:

The rule. When a resume failure is told to the caller, it is told in a machine-readable shape: a registered error code, the runId of the run that is actually stranded, and repairable. The door's status code does not change because of it …

⛔ That rules the SHAPE IN WHICH A CALLER IS TOLD. This card is not about telling. Here the caller is told nothing wrong — the second call genuinely succeeds. The question is whether the door should have admitted it at all, and what the audit trail owes. ⇒ The #16472 ruling is not authority for either repair here, and ⚠️ it must not be read as having pre-ruled the door-closing option. Stated explicitly because the resemblance is strong and a later reader would otherwise re-derive it wrongly.

② The contract's own text on the recovery verb — packages/spec/src/contracts/approval-service.ts, the docblock above continueRestoredRun?( at :1012, verbatim:

No door is declared here, and none is ruled — the 2026-09-09 ruling refused a REST/CLI route for this verb. It is an in-process operator repair, reachable from a host or a console script; a route for it is a new card, never a widening at a call site.

and, on the same member being optional:

a service that does not declare this member has NO operator door for it, and a door MUST probe for presence and refuse fail-closed when it is absent — never answer success for a verb it could not dispatch, because promising a repair verb that will refuse is worse than promising nothing.

③ Triage's gate on this card (comment 5628526549), which the dispatch carried verbatim and which this round obeyed:

⚠️ ⛔ Do not "fix" it by weakening assertLatestForRun or the collision check. Every guard in the card's table is passing correctly on its own terms — the hypothesis is that the set of them has a hole on one strand shape, ⛔ not that any one is wrong.

Protocol declaration

Does this change the protocol? Option A does — it narrows a published accept set and would declare Clause-②: yes with its own contract review and a minor on the package. Options B and C do not touch any published surface. Nothing in step 1 did (Clause-②: no, measured against the package's publish declaration and again against the built files[] with a firing control).

Preconditions, each with its re-check command

premise	measured	re-check
the defect reproduces	✅ dea214f81 on main	pnpm --filter @objectstack/plugin-approvals exec vitest run src/stranded-resubmit-second-door.test.ts
the doubling changes no decision today	✅ MEASUREMENT C + reverse control	same file, MEASUREMENT C
resubmit is reached through the published API	✅ 22 hits in packages/rest, 7 in packages/client	git grep -c '\bresubmit\b' origin/main -- packages/rest packages/client
the recovery verb has no route	✅ 0 hits in rest / cli / mcp / client / runtime, against the resubmit control above	git grep -c 'continueRestoredRun' origin/main -- packages/rest packages/cli packages/mcp packages/client packages/runtime
#16472 is closed and ruled	✅ 2026-09-07T08:28:33Z	read #16472 comment 5567695080

一句话问题

一次审批退回后,提交人重新提交时系统内部出了故障、这次重交卡住了;运维把它救回来之后,同一个人可以再按一次「重新提交」,而审批历史里就会留下两条「重新提交」记录,可是流程其实只往前走了一步 —— 记录与事实不符,而代码里写着这种情况不可能发生。

选项 × 真实代价

	做什么	客户可感知的后果
A	在门口拦住:已经记过一次重交,就拒绝第二次	已实测:「重新提交」是客户今天经由公开接口真实使用的入口(packages/rest 22 处、客户端 7 处);拦掉之后,被运维救回的那条流程只能靠一个没有任何网络入口的内部修复动作继续(该动作的路由已于 2026-09-09 被裁决驳回,且它在契约上是可选成员,不声明就等于没有)。⇒ 一个合法重试的人会开始吃到拒绝,而替代出路客户碰不到
B	把代码里那句「不可能发生」的断言缩小到它真正成立的范围	客户无感:运行时一行不变。审批历史仍然会在这种罕见情形下多出一条记录
C	什么都不做,理由是已测出「多一行不改变任何判断」	客户无感。但代码里那句假话继续留在写着它的文件里,而这张卡正是因为有人照着那句话推理才立的

业务含义直译

• A = 「宁可让一个可能是正常重试的人被挡住,也不让账本多记一笔」—— 但今天没有给他第二条路。
• B = 「把说明书改对,行为先不动」:说明书不再骗下一个读它的人,账本的小瑕疵留作一个单独的、写明白的问题。
• C = 「这瑕疵今天不造成任何错误判断,先记账不修」—— 代价是下一个读代码的人会再被同一句话误导一次。

四轴,从业务立场

① 长远合理性 —— B 把一句过宽的断言收窄到事实,不新增任何特例,契约零增生。A 反过来给一个公开入口加一条拒绝特例,并让恢复能力依赖一个可选、且无路由的动作,是两处增生。C 把一句已知为假的话留在原地,下一个人会重新推导出错误结论(这张卡本身就是证据)。
② 业务拉动 —— 今天谁撞上:没有用户报告,且要先有一次内部故障、再加一次运维救援才到得了这个状态。唯一客户可见的后果是审批历史多一条记录。⇒ 拉动低但非零(审批账本的正确性对客户是有意义的),按「零拉动默认 defer」的反面读,它不到立即动公开行为的分量。
③ 防 AI 犯错 —— 见下一节。
④ 创业阶段不扩散 —— B 是纯文字,不新增任何永久义务。A 新增一条声明过的拒绝,外加「必须长期保证那条恢复路径可用」的义务,而那条路径今天既无路由、又可选。⇒ 本轴明确偏 B。

防 AI 犯错轴:出错时谁看到什么

今天的失效是静默的:门放行,账本多一行,没有人被告知。本轴的常设偏好是「响亮拒绝优于静默容忍」,这一条支持 A。

⚠️ 但要把这条看完:A 的响亮拒绝没有配一条够得着的出路。契约自己的原话是「promising a repair verb that will refuse is worse than promising nothing」,而 A 之后的唯一出路正是那个无路由、可选的动作。⇒ 本轴想要的是「让作者/运维知道并能动手」,A 只给了前半截。所以③在这里是分裂的,不是一致支持 A —— 把它写成一致支持 A 会是把本轴读成了「只要拒绝就好」。

推荐 + 回退 + 置信缺口

推荐:B。 四轴里 ①②④ 指向 B,③ 分裂且其偏向 A 的那一半在本卡缺了半截出路。B 让说明书不再骗人、零客户影响、零永久义务,并把「账本能否多记一笔」留成一个写明白的、可以单独裁的问题 —— 而不是被一次实现顺手决定掉。

回退:A,条件明确 —— 如果判定审批账本必须一次推进一条记录、这点不可商量,那么只有 A 能做到,并且它应当连带处理「拒绝之后客户走哪条路」,否则就是用一个静默瑕疵换一个够不着出路的响亮拒绝。

本分析看不见什么(置信缺口,⛔ 不粉饰):

• ⛔ 没有做过同类断言的普查。 approval-service.ts 里还有多少处「at most one」式的假设,本轮没扫(dev 明确把这记为「declared-unmeasured zero」而不是悄悄继承)。如果同族还有几处,那 B 的「逐句改对」就可能是在打地鼠,而答案也许是一条通则 —— 本分析无法判断,因为没有那个数。
• ⛔ 不知道是否有真实客户曾走到这个状态。 判据是「没有报告」,而没有报告不等于没有发生。
• ⚠️ approvals: a recall whose resume strands reports it as an ordinary non-failure — no repairable discriminator, where the identical strand through decide carries one #15970 是同族的另一种形状(recall,已另测),而它的修法挂在 [Decision] Must a resume failure reach the CALLER in a shape it can act on? — the family question triage reserved, now that its instance cards have each measured their own half and stopped at the same contract #16472 已落地的裁决上。⇒ 若倾向把本卡与它合并成一条通则裁决,本分析没有为那条通则定价 —— 它只为本卡的三个选项定价。

裁后执行段

• 裁 B ⇒ 本车道普通派发一轮,Clause-②: no,patch;改的是 approval-service.ts:4877-4886 那段散文的范围,外加在 dea214f81 落地的那个 pin 上补一行指向本裁决的注释。⛔ 不动任何 guard。
• 裁 A ⇒ 契约面轮次:Clause-②: yes、needs:contract-review 双载体、包评 minor;同一轮必须回答「拒绝之后客户走哪条路」,若答案是给恢复动作开路由,那是另一张卡(2026-09-09 的裁决如此规定),本轮不得顺手加。
• 裁 C ⇒ 关卡 not_planned,关单评论引本裁决与已落地的 pin,并把那句断言的过宽范围记进 pin 的文档串,使下一个读者不再重新推导。
• 三种情形下 dea214f81 的 pin 都不删:它是本卡的证据,修法改变行为时更新它就是修法的证据。

os-decision-facets

• ① 项目长远合理性:B 把一句过宽的断言收窄到事实,零特例、零契约增生;A 给公开入口加拒绝特例并依赖一个可选且无路由的恢复动作(两处增生);C 留一句已知为假的话在原地,下一个读者会再被误导一次。
• ② 实际业务拉动:低但非零 —— 无用户报告,到达需先有一次内部故障再加一次运维救援;唯一客户可见后果是审批历史多一条记录。不到立即改动公开行为的分量。
• ③ 防 AI 犯错:分裂。 现状是静默容忍(门放行、账本多一行、无人被告知),本轴偏好响亮拒绝 ⇒ 支持 A;但 A 的拒绝之后没有够得着的出路(恢复动作无路由且可选),而契约自己写着「promising a repair verb that will refuse is worse than promising nothing」⇒ 支持 A 的那一半缺了后半截。
• ④ 创业阶段不扩散:B 纯文字、零永久义务;A 新增一条声明过的拒绝,外加长期维护那条恢复路径的义务 ⇒ 明确偏 B。
• 推荐:B(回退 A,条件是判定审批账本必须一次推进一条记录)。
• 置信缺口:本分析没有做同类「at most one」断言的普查(该数为 declared-unmeasured zero),因此无法判断 B 是逐句改对还是打地鼠;也不知道是否有真实客户到过这个状态(判据只是「没有报告」);并且没有为「把本卡与 approvals: a recall whose resume strands reports it as an ordinary non-failure — no repairable discriminator, where the identical strand through decide carries one #15970 合并成一条通则」这个可能的裁法定价。

维护者速读

审批退回后,提交人重交时系统内部出了故障、这次重交卡住了;运维把它救回来之后,同一个人可以再按一次「重新提交」,审批历史里就多出一条记录,而流程其实只往前走了一步。已实测确认,也已测出它今天不会让任何判断出错 —— 坏的是账本多一行,和代码里那句「这不可能发生」的假话。

三条路:A 在门口拦住第二次重交(账本干净,但「重新提交」是客户今天真在用的入口,拦掉之后救回来的流程只剩一条客户碰不到的内部出路);B 只把代码里那句假话改对,行为不动(客户无感,账本那一行留着,留成一个单独可裁的问题);C 什么都不做,只记账。本席荐 B。

请裁:A / B / C?

---

Generated by Claude Code