fix(runtime,spec): the resume door asks the engine whether a status-less exit is repairable

[os-litant]

Fixes #17541

Clause-②: yes (widening)

Ruling: batch #148 item 5, letter 1 (comment 5716043121), maintainer 「同意」 2026-09-17T14:27Z.

The defect, as the ruling asked for it: a WIRE reading

Step one of the ruling is a measurement through the HTTP route, not through the engine. Driven through HttpDispatcher.handleAutomation on a parked two-level delegation — the parent parked at its subflow node, the child parked at a pausing node, the child's downstream node then throwing — POST /automation/parent_flow/runs/:parentRunId/resume answered:

BEFORE (origin/main at f1c9bb3056, the defect reproduced on trunk):

400 {
  "success": false,
  "error": {
    "code": "FLOW_FAILED",
    "message": "subflow run 'run_8a89ceab…' (child_flow) failed: update_record(crm_leave_request) failed: Record 9SEmlyRfw8D9-J7Z not found",
    "httpStatus": 400,
    "details": { "runId": "run_240f641d…", "repairable": false }
  }
}

AFTER (this branch):

400 {
  "success": false,
  "error": {
    "code": "FLOW_FAILED",
    "message": "subflow run 'run_bc8d989f…' (child_flow) failed: update_record(crm_leave_request) failed: Record 9SEmlyRfw8D9-J7Z not found",
    "httpStatus": 400,
    "details": { "runId": "run_337c1bca…", "repairable": true }
  }
}

At that same instant, on the same engine, both readings taken in the same probe run:

engine.inspectConsumedSuspension(parentRunId)
  = { repairable: true, runId: "run_…", flowName: "parent_flow", nodeId: "sub",
      correlation: "subflow:run_…", witness: "journal", consumedAt: "…" }
engine.restoreConsumedSuspension(parentRunId, { requestedBy: "ops" })
  = { restored: true, chain: [childRunId, parentRunId] }

So the wire told an operator not to retry a repair that works, and the schema's own .describe() stated the opposite reason — projected verbatim into the generated reference page.

What changed

packages/spec — IAutomationService declares the read-only member. inspectConsumedSuspension(runId), optional, exactly the shape the engine already implements publicly (AutomationEngine.inspectConsumedSuspension, landed for #15358). The declared result is deliberately narrower than the implementation's, on the precedent the sibling restoreConsumedSuspension set (#16495 route (i)): { repairable: boolean; runId: string; reason?: string }, with reason typed as the string the implementation answers rather than as an enumeration this contract would have to keep in step with. The engine's wider ConsumedSuspensionInspection satisfies it under implements — proved below, in both directions.

packages/runtime — the resume door consults the declared contract. On a 400 FLOW_FAILED whose result carries a status, that stamp still decides and the engine is not consulted at all. On a result that stamps none, the door asks the declared optional member and relays its repairable.

⛔ The door never probes an undeclared member: the member is on IAutomationService first, and the door reads it through that optionality, the same way it already reads resume. Every way of not getting an answer is FAIL-CLOSED — a service that declares no inspection member answers false exactly as it did before, and an inspection that REJECTS (a store it could not read) answers false and says so once at warn. An unreadable store is UNKNOWN, not "nothing to restore", and it is never allowed to replace the 400 the caller asked for with a 500.

⛔ The fence the nested-chain work was dispatched with is untouched: a cascade-failed ancestor is still never STAMPED 'stranded'. Its repairability is carried by the journal and REPORTED by the inspection, which is exactly why the door has to ask instead of reading a word. ⛔ And no new AutomationResult.status member is minted (ruled-out option 2): there is nothing new for a client to learn, and details.repairable is the member a client was already told to branch on.

Docs. ResumeFailureDetailsSchema.repairable's .describe() is rewritten to the truth; content/docs/references/api/automation-api.mdx is REGENERATED with the repo's own tooling (pnpm --filter @objectstack/spec check:generated --fix, which proved exactly that one artifact stale and regenerated only it — a one-line diff). The two hand-written pages were re-read for the same sentence and both carried it, so both are corrected by hand: content/docs/automation/flows.mdx said repairable is "true exactly when status is stranded", and content/docs/api/client-sdk.mdx asserted verdict.data.status === 'stranded' inside its if (verdict.data.repairable) sample.

Tests

Evidence below is from the final commit, 228275a473.

A test that fails without the change and passes with it, plus its controls. New, in two layers:

• packages/verify/src/automation-resume-delegation-repairable.test.ts — the wire, through the real engine and the real route. Three cases: the DELEGATION exit (repairable: true, no status, the whole details parsing under ResumeFailureDetailsSchema, and the operator verb then accepting exactly that run and the re-issued resume completing the tree); a CONTROL that the non-delegation stranded exit is unchanged (status: 'stranded', repairable: true); and a FIRING CONTROL — a delegation whose leaf is NOT repairable answers repairable: false on that same status-less arm.
• packages/runtime/src/domains/automation-resume-delegation-repairable.test.ts — the door's shaping with a fake service, so the arms a real engine will not produce on demand are reachable by name: the two fail-closed arms, and two controls proving a stamped 'stranded' / 'failed' is answered by the STAMP and the engine is never asked.

The pre-existing packages/runtime/src/domains/automation-resume-stranded-details.test.ts is left untouched on purpose and is the standing control that every non-delegation exit answers exactly what it did.

Reverse verification — behaviour. The pre-change expression was put back on the committed tree, proven on disk (injected marker count 1, deleted call count 0, blob hash moved off HEAD's), @objectstack/runtime rebuilt, and the mutation proven to have reached the artifact the suite consumes (node scripts/ablation-dist-preflight.mjs runtime … — marker present in 2 built files). Direction observed, as predicted: turned red, and only there — 1 failed | 4 passed, the failure being the DELEGATION wire case, with both controls and the two pre-existing wire cases still green. Restore leg: source restored from HEAD, whole-tree git status --porcelain clean, blob hash equal to HEAD's, rebuilt, --absent preflight confirming the marker is gone from all 6 built files, suite green again (5 passed).

Reverse verification — types. AutomationEngine implements IAutomationService, so the new declaration is enforced on the implementer. With the engine's ConsumedSuspensionInspection mutated to drop runId from its repairable arm, pnpm --filter @objectstack/service-automation exec tsc --noEmit exits 1 naming the member:

src/engine.ts(8133,11): error TS2416: Property 'inspectConsumedSuspension' in type
  'AutomationEngine' is not assignable to the same property in base type 'IAutomationService'.

Restored, the same command exits 0. That is also the proof the typecheck reads the rebuilt spec .d.ts rather than a cached one.

Suites — both projects run where a package has two, exit codes read from $? after a redirect, never through a pipe:

command	exit
pnpm --filter @objectstack/spec test (--project local)	0 — 486 files, 14017 tests
pnpm --filter @objectstack/spec test:repo (--project repo)	0 — 31 files, 536 tests
pnpm --filter @objectstack/runtime test (--project local)	0 — 266 files, 3667 passed, 1 skipped
pnpm --filter @objectstack/runtime test:repo (--project repo)	0 — 2 files, 69 tests
pnpm --filter @objectstack/verify test	0 — 110 tests
pnpm --filter @objectstack/spec typecheck	0
pnpm --filter @objectstack/runtime typecheck	0
pnpm --filter @objectstack/verify typecheck	0
pnpm --filter @objectstack/service-automation typecheck	0
pnpm --filter '@objectstack/verify^...' build	0

Gates run locally (all exit 0): pnpm --filter @objectstack/spec check:generated (15 of 15 up to date after the regeneration), check:nul-bytes, check-adr-0087-registration --base origin/main, check-changeset-no-major --base origin/main, check-empty-changeset --base origin/main, check:objectui-changeset, check:pm-widening-tells, check-closing-keyword-parity, check-spec-docblock-symbol-anchors, check-doc-frontmatter, check:docs-single-h1, check:doc-anchors, check-docs-section-name, docs-audit/check-affected-docs, check:route-envelope, check:dispatcher-error-vocabulary, check:cross-package-test-inputs, check:test-source-alias, check-undeclared-dep-imports, check:tier-file-adoption, check:type-check-coverage, check:type-check-debt.

The three changeset gates first exited 1 with no merge base between 'origin/main' and 'HEAD' — a shallow-clone PREREQUISITE, not a verdict. git fetch --deepen 300 origin main restored the merge base (f1c9bb3056) and all three then exited 0.

Lint: the whole population, not a narrowing. node --stack-size=4000 node_modules/eslint/bin/eslint.js . --no-inline-config --format json exits 0 over 6834 files (count read from the JSON output), 0 errors and 0 warnings.

NOT measured here, deliberately: the rest of CI's gate farm (the derivation names 107 runnable commands plus 50 artifact-roster families, 10 wide-population families and 6 path-scheduled CI jobs), and the Temporal Conformance / Dogfood / Build Docs jobs, which have no local invocation.

Acceptance notes

Two observations found on the way, neither filed — each is an omission rather than an error, and neither is a reproducible defect, a broken declared contract, or an authoring trap:

• registerSubflowNode is exported from packages/services/service-automation/src/builtin/index.ts but is not re-exported from that package's root index.ts, while five sibling registrars are. Nothing is broken by it: installBuiltinNodes reaches the same executor and is what the new wire test uses. Next party to meet it: an out-of-package test author who wants the subflow node alone.
• ResumeFailureDetailsSchema.status's own describe names "a subflow child that failed terminally" as the status-less case and does not also name the delegation frame. Incomplete, not false, and the ruling named only the repairable describe. Next party to meet it: whoever next edits that enum's text.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/runtime, @objectstack/spec, touching 6 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/client-sdk.mdx (via ResumeFailureDetailsSchema (symbol, a top-level const))
• content/docs/automation/flows.mdx (via ResumeFailureDetailsSchema (symbol, a top-level const))
• content/docs/permissions/system-context.mdx (via handleAutomationRequest (symbol, a top-level function))

⛔ 1 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v17/17-0.mdx (via IAutomationService (symbol, a top-level interface))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• the SDK route bridge reached 60 of 215 client-bound route-ledger rows — the other 155 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 155: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 100 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 141 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json e5705a8ea528573e67eb0ea1ca269dff6c70d512 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 15839e289a60c5edb7cfa314bcb2f42a47dc229e — the merge of head 228275a473565ce3784ca84bea3f1ea80dae9a65 into base e5705a8ea528573e67eb0ea1ca269dff6c70d512, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 15839e289a60c5edb7cfa314bcb2f42a47dc229e && git checkout 15839e289a60c5edb7cfa314bcb2f42a47dc229e
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin e5705a8ea528573e67eb0ea1ca269dff6c70d512 228275a473565ce3784ca84bea3f1ea80dae9a65 && git checkout -B drift-repro e5705a8ea528573e67eb0ea1ca269dff6c70d512 && git merge --no-ff 228275a473565ce3784ca84bea3f1ea80dae9a65

node scripts/docs-audit/affected-docs.mjs --json e5705a8ea528573e67eb0ea1ca269dff6c70d512

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs e5705a8ea528573e67eb0ea1ca269dff6c70d512 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-litant]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 228275a473565ce3784ca84bea3f1ea80dae9a65

① Derived judgments

0. Measurement basis. Own worktree at that head, complete tree, merge base with origin/main = f1c9bb3056 (present without deepening in this clone). pnpm install --frozen-lockfile exit 0, pnpm --filter '@objectstack/verify^...' build exit 0 before any gate or ablation. Every exit read from $? after a redirect. The six gate scripts run by path (check-empty-changeset.mjs, check-adr-0087-registration.mjs, check-changeset-no-major.mjs, spec's check-generated.ts, build-docs.ts, build-api-surface.ts) are blob-identical between the head and origin/main. The head's scripts/pm is behind origin/main on five files; the only one of them that is a gate for this class, check-widening-tells.mjs, was run in both copies. Tree restored to HEAD's blobs and empty porcelain after every mutation.

1. Precedent and narrowing (attack 1). The precedent exists in exactly the claimed shape: restoreConsumedSuspension? at packages/spec/src/contracts/automation-service.ts:893 declares {restored; runId; refusal?: string; reason} against the engine's wider SuspensionRestoreResult, its docblock naming [spec] Declare cancelRun and restoreConsumedSuspension on IAutomationService — #13953's ruled contract half, step (1), never filed #16495 route (i). The new member at :973 declares a Promise of {repairable: boolean; runId: string; reason?: string}. The engine's ConsumedSuspensionInspection (packages/services/service-automation/src/engine.ts:1831) is a four-arm union: the true arm {repairable: true; runId; flowName; nodeId; correlation?; witness; consumedAt} and three false arms each {repairable: false; runId; reason: one literal}. The narrowing is sound in the direction used: the door reads only repairable, coerced with === true; every engine arm carries runId and a boolean-literal repairable; the false arms' literal reason is a string; the true arm carries no reason. So the declared docs ("absent on the true arm", "runId echoed both ways", "throws when a store cannot be read") describe exactly what the engine produces — inspectConsumedSuspension at engine.ts:8133 reads through loadSuspendedRunStrict, whose throw propagates, matching the @throws. The shapes the declared type admits that the engine cannot produce (a reason beside true; a false with no reason) are never read by the door, so the wire cannot inherit them. Enforcement measured: service-automation tsc --noEmit exit 0 at head; with runId deleted from the engine's true arm (blob moved off HEAD's, true-arm runId count 0) exit 1 with three errors, all consequences of that one edit — engine.ts(8132,11) TS2416 Property 'inspectConsumedSuspension' in type 'AutomationEngine' is not assignable to the same property in base type 'IAutomationService', engine.ts(8144,17) TS2353 (the implementation still supplies runId) and engine.test.ts(922,19) TS2322 (a test assigning the engine to the contract). Restored to HEAD's blob: exit 0.

2. Optionality and the fence (attack 2). The read at packages/runtime/src/domains/automation.ts:1484 is automationService.inspectConsumedSuspension?.(runId) on a variable statically typed IAutomationService (deps.getService(context, CoreServiceName.enum.automation) resolves through CoreServiceContract, packages/spec/src/contracts/core-service-contracts.ts:80). That this is a declaration-bound read and not a duck-check wearing a declaration was measured: with the member renamed inside the built packages/spec/dist/contracts/index.d.mts and index.d.ts (sha256 recorded before and after), pnpm --filter @objectstack/runtime exec tsc --noEmit exits 1 with exactly one error, automation.ts(1484,41) TS2551 Property 'inspectConsumedSuspension' does not exist on type 'IAutomationService'; files restored byte-identical, exit 0. A typeof probe on an untyped host would have compiled through that rename. Both no-answer arms measured fail-closed through the real HttpDispatcher with a fake service (packages/runtime/src/domains/automation-resume-delegation-repairable.test.ts, 6 cases, run per-file with the verbose reporter so each case is named): a service with no member answers 400 FLOW_FAILED {runId, repairable: false} with no warning; a member that rejects (connection reset) answers the same 400 with repairable: false and exactly one warn naming the member, the runId and the rejection text — the 400 is never replaced by a 500. The try wraps the await, so a synchronous throw is caught as well; a non-Error rejection is stringified. Absent is silent and rejected is said once, which the helper's docblock keeps apart as two different facts.

3. Only the delegation exit moves (attack 3). resumeFailureDetails has one caller, the resume door's FLOW_FAILED arm (automation.ts:2336); the stamped branch keeps the literal expression status === 'stranded' and the status relay ...(status !== undefined ? { status } : {}) is unchanged. Measured: two stamp controls (a stamped stranded answers repairable: true, a stamped failed answers false) with the fake inspection primed to answer the opposite and not.toHaveBeenCalled() on the spy — whose same-subject hit is the delegation case asserting toHaveBeenCalledWith('run_parent'). The pre-existing runtime control file automation-resume-stranded-details.test.ts (14 cases; git diff --quiet against the merge base exit 0, untouched) and the two pre-existing automation resume door: the 400 FLOW_FAILED envelope drops the engine's status: 'stranded' verdict — the wire mirror's member is unreachable on the wire #15221 wire cases in packages/verify/src/automation-resume-stranded-details.test.ts stay green at head and under the behavioural ablation alike, i.e. they are insensitive to this change as they should be. The verify non-delegation control (resume the CHILD directly) still answers {status: 'stranded', repairable: true} through the real engine. The trigger door's 400 still carries no repairable (pre-existing case green).

4. The service-automation: restoreConsumedSuspension cannot reach a nested run — a stranded child's cascade-failed ancestors are consumed without a snapshot, so restoring the child continues into a dead parent #15222 fence (attack 4). engine.ts is not in the diff (9 files, none under packages/services). The only status: 'stranded' stamp remains engine.ts:6906, the run whose own pause was consumed; failSuspendedRun still records the ancestor 'failed' and journals only when a repairable descendant is below it. The door synthesises no status. Measured on the wire through the real engine: the delegation case asserts details.status is undefined while repairable is true, then the operator verb accepts exactly that run (restored: true, chain [child, parent]) and the re-issued resume completes the tree. No new AutomationResult.status member; ResumeFailureDetailsSchema keeps runId, status?, repairable with only a describe string changed. Ruled-out options 2 and 3 are absent.

5. The two ablations (attack 5). Behavioural, re-derived on the committed tree: pre-change expression put back (marker count 1, deleted call count 0, blob off HEAD's), runtime rebuilt, mutation proven in the artifact verify consumes (packages/runtime/dist/index.js: consumedSuspensionSurvives call count 1 to 0, inspectConsumedSuspension 2 to 0; verify resolves @objectstack/runtime from dist). Verify wire files: 1 failed | 4 passed, the failure being the DELEGATION case only; the two automation resume door: the 400 FLOW_FAILED envelope drops the engine's status: 'stranded' verdict — the wire mirror's member is unreachable on the wire #15221 wire cases, the non-delegation control and the firing control green. Runtime door files: 3 failed | 17 passed — the DELEGATION case, the FIRING CONTROL (asserts the engine was asked) and the rejecting FAIL-CLOSED case (asserts one warn) red; all 14 pre-existing automation resume door: the 400 FLOW_FAILED envelope drops the engine's status: 'stranded' verdict — the wire mirror's member is unreachable on the wire #15221 door cases, the no-member arm and both stamp controls green — exactly the cases that assert the engine is consulted turn, none that pin the prior answers. Restore leg: blob equals HEAD's, rebuilt, dist counts back to 1 and 2, verify 5 passed, runtime 20 passed, porcelain empty. Type-level: re-derived in item 1 (TS2416 at engine.ts:8132; the dev's 8133 is the same site, their edit kept the line count where mine removed a line). The cache reasoning holds: no incremental, composite or tsbuildinfo anywhere in the tsconfig chain of runtime or service-automation, so tsc reads the .d.ts on disk at each invocation; TS2416 can only name a member the read .d.ts contains, so it proves the read was post-PR; the rename ablation in item 2 independently proves runtime's tsc reads the .d.mts present at invocation time.

6. Docs (attack 6). After a full build, pnpm --filter @objectstack/spec check:generated exit 0, 15 of 15 up to date (check:docs and check:api-surface included); a fresh gen:docs exit 0 leaves content/docs/references with an empty porcelain. Controls that hit: the new describe phrase is in 2 built dist files and in the page; the repairable table cell is byte-equal to the source describe text (1046 chars); the exact pre-PR wording exactly when \status` is `stranded`hits the merge-base page once and hits the current page, the dist and the whole ofcontent/ zero times. The committed regeneration diff is exactly the one table row. The two hand-written pages (content/docs/automation/flows.mdx, content/docs/api/client-sdk.mdx) carried the sentence and are corrected in the diff. Whole-tree grep for the sentence outside content/: packages/*/CHANGELOG.mdentries (release-owned, historical, correctly untouched) and one live docblock — see ③ flag 1. The remainingstatus === 'stranded' derivations are the approvals door's own (packages/plugins/plugin-approvals/src/approval-service.ts:3499, :3775; packages/types/src/stranded-decision.ts:85`), a different door outside this ruling and still true of that door.

7. Gates and suites at head, all exit 0 and matching the dev's table: spec test (--project local) 486 files / 14017 tests; spec test:repo 31 / 536; runtime test (--project local) 266 / 3667 passed, 1 skipped; runtime test:repo 2 / 69; verify test 15 / 110; typecheck for spec, runtime, verify, service-automation; the three changeset gates by script path with --base origin/main (merge base f1c9bb305); check-widening-tells.mjs --declaration yes --diff in both HEAD's and origin/main's copy — a yes declaration is never blocked by that gate, so it decides nothing here and this record is the deciding step. CI at this head: 39 check runs, every completed run success or skipped, none failed, including Type Check · workspace, Lint & Repo Gates, Test Core, Build Docs, Temporal Conformance and the Dogfood jobs.

② Semver level

@objectstack/spec minor, @objectstack/runtime minor, Clause-②: yes (widening) — confirmed. Additive only: one optional method added to an existing exported interface; no export added, removed or renamed (check:api-surface, check:export-origins, check:declaration-map all up to date on a fresh build); no wire key added, renamed or retired. Implementer side: the repo's sole implements IAutomationService (AutomationEngine) already carried a conforming member; plugin-approvals' structurally separate ApprovalResumeSurface.inspectConsumedSuspension? never receives an IAutomationService-typed value (attachAutomation(automation: ApprovalResumeSurface)), and its two source tsc --noEmit halves exit 0 against the rebuilt spec dist; the pinned objectui sibling 53ded82bf7 names neither the member nor implements IAutomationService (git grep at that object; control repairable hits 1). Under AGENTS.md's declaration rule, yes takes at least minor and only (narrowing) is BREAKING, so a widening owes no BREAKING banner and no ADR-0087 marker — check-adr-0087-registration reads "adds no declared-breaking changeset", check-changeset-no-major "no major bump", check-empty-changeset "1 declaring changeset added, none from the merge base modified or deleted". Runtime's minor is the wire-observable widening of the set of runs that answer true; a patch would have under-declared a consumer-visible truth change.

③ Boundary flags

1. A live public docblock still carries the retired sentence, outside the ruling's enumerated docs surfaces: packages/client/src/index.ts:5551, the JSDoc on client.automation.resume, reads err.details?.repairable; // true exactly when \status` is 'stranded'. It ships as hover documentation in @objectstack/client's .d.tsand is not projected intocontent/(grep 0; control: the same grep hits the source). Not blocking under letter 1, which named the.describe(), the regenerated reference and the two hand-written pages; the seat may prefer a docs-only follow-up. The fix is one line: replace the comment with the answer's true shape, e.g. // the engine's own answer; can be true with no `status` (subflow delegation)`.

2. Two structural declarations of the same engine member now coexist: spec's IAutomationService.inspectConsumedSuspension? (a Promise of {repairable: boolean; runId: string; reason?: string}) and plugin-approvals' ApprovalResumeSurface.inspectConsumedSuspension? (approval-service.ts:225, {repairable: true} | {repairable: false; reason: literal union}). The spec shape is not assignable to the plugin shape (reason?: string against a required literal union), so a future card that hands plugin-approvals a spec-typed service will need a local widening; today nothing assigns across. Observation for whoever next lets plugin-approvals consume the spec declaration instead of its own.

3. Local prerequisite-not-met readings, recorded so they are not mistaken for reds: pnpm --filter @objectstack/plugin-approvals typecheck exits 1 only in its check:test-typecheck half, on src/status-mirror-cascade.integration.test.ts (untouched by the PR) with TS2307 for @objectstack/trigger-record-change, whose dist does not exist under a build scoped to verify's dependency closure; CI's Type Check · workspace is green at this head. The three changeset gates needed no --deepen in this clone because the merge base was already within reach.

4. The dev's two unfiled observations (registerSubflowNode not re-exported from service-automation's root; the status describe not naming the delegation frame by name) are omissions rather than defects; concur that neither needs a card from this review.

NOT measured: the full eslint population locally (CI Lint & Repo Gates green); @objectstack/service-automation's and @objectstack/plugin-approvals' own test suites (the engine is untouched by the diff; plugin-approvals is not in the diff); the Console Pin Gate (skipped in CI; nothing removed or renamed, so the sibling rule is not engaged); Temporal Conformance, Dogfood and Build Docs locally (CI green); the remainder of CI's gate farm beyond the gates named above.

Implemented-by: claude/issue-17541-resume-door-consults-inspection
Reviewed-by: session_01LvwGppdonww4zGLWZo5rho

VERDICT: PASS

---

Generated by Claude Code