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

[os-warren]

Found while delivering the services half of #13937 (branch claude/issue-13937-stranded-run-operator-verb, draft PR pending). ⛔ Not fixed there: packages/runtime is outside that card's claimed file surface, and the wire vocabulary is the runtime door's own (ADR-0112 ledger).

The reading, on origin/main 50d6c92 plus that branch

• AutomationResult.status carries 'stranded' (spec: name the terminally-failed run state on AutomationResult.status — contract half of #13937 (shape 4 ruling) #14384), and the wire mirror TriggerFlowResponseSchema.data.status (packages/spec/src/api/automation-api.zod.ts) carries the same four members, parity pinned by automation-result-status.pin.test.ts.
• With the [Decision] Workflow resume ordering: a thrown node today leaves the run terminally unresumable — which of three shapes, given that the current order buys exactly-once across a crash? #13937 services half, AutomationEngine.resume() returns { success: false, status: 'stranded', ... } for the resume that consumed the pause and then failed downstream (the one exit that journals a consumed suspension).
• The REST resume door (packages/runtime/src/domains/automation.ts, POST /:name/runs/:runId/resume) answers every success: false result that is not a coded refusal with deps.error(result.error, 400, { code: 'FLOW_FAILED', errorMessage?, summary? }). The details object copies errorMessage and summary and nothing else — status is not copied.
• The trigger doors never produce a stranded result (only resume reaches that catch arm), and the resume door's 200 body (deps.success(result)) is reached only for a paused or completed result.

⇒ data.status: 'stranded' cannot appear on the wire through any door today. An HTTP-only operator sees 400 FLOW_FAILED for a stranded run and for a plain ran-and-was-rejected run alike, so they cannot tell "this run is beyond reach" from "this run has a repair verb waiting" — exactly the information the console (objectui flowResponse.ts, which reads success === false || status === 'failed' as terminal) would need in order to offer a repair action.

What a fix has to decide (not decided here)

• Whether the 400 envelope's details carry status (and possibly runId) on the stranded arm, or whether that arm gets its own ADR-0112 code (a FLOW_STRANDED sibling of FLOW_FAILED). The console treats 400 FLOW_FAILED as terminal (the automation: the run-resume route still answers HTTP 200 wrapping an inner {success:false} — the route #3962's status-code unification left behind #8684 hazard pins in automation-resume-envelope.test.ts), so a distinct code is the shape that lets a client branch without a message regex.
• Same family as service-automation: the two operator run-lifecycle verbs (cancelRun, restoreConsumedSuspension) have no door — no REST route, no CLI command, and not on IAutomationService #13953 (the operator verbs have no door): the verdict on the wire is what tells an operator that the door, once it exists, is worth knocking on.

Related

#13937 (the ruling; services half on the named branch) · #14384 (the contract half) · #13953 (doorless operator verbs) · #8684 (the resume door's 400 FLOW_FAILED arm)

[os-warren]

Discharging #13807's ruling item 1 against this card: measured, and it is NOT the same seam — so this stays yours rather than being folded into #13807's stroke.

The batch #37 ruling on #13807 said the generic door "is measured for the same discard and fixed in the same stroke if it is the same seam, filed if it is not". It is filed — here. What I measured, on a56baa2bd:

1. No shared code. packages/runtime/src/domains/automation.ts contains zero occurrences of serviceResume, RESUME_FAILED, or handleApprovalError. The two doors share no narrowing function and no envelope builder.

2. The two discards have different mechanisms. In approvals the loss is a lossy internal relay: ApprovalService.serviceResume casts the engine result to { success, code, error } and the door downstream never gets the chance to see status. Here the door reads the engine result directly — it already forwards errorMessage and summary off the same object — and simply does not forward status. That is a wire-shaping choice at the point of shaping, not a value destroyed in transit; the fix shapes are correspondingly different.

3. Different code, owner and status. Approvals answers 500 RESUME_FAILED; this door answers 400 FLOW_FAILED, which the ADR-0112 ledger registers to @objectstack/runtime — "this door, not the engine's, is where the wire vocabulary is named", as the site's own comment puts it.

4. Three of #13807's four fields have no referent here. finalized and decision are approvals-domain facts. A generic resume has no decision to report, so only the repairability half is even shared.

5. An approval node cannot reach this arm at all. approval-node.ts:126 declares resumeAuthority: 'service', so a generic resume of an approval suspension is answered 403 PERMISSION_DENIED by the arm above, long before FLOW_FAILED — measured independently in #13807's measurement round. The populations do not overlap.

6. The contract change is genuinely separate. FLOW_FAILED covers two engine exits — "the flow itself failed" and "a subflow child failed terminally" — and only one of them can be stranded. Adding a repairability discriminator changes what FLOW_FAILED means for every plain terminal failure too, on a second published route with a different owner ⇒ its own Clause-② review, not a rider on #13807's.

⇒ #13807's PR carries the approvals door only. After it lands, AutomationResult.status: 'stranded' will have exactly one consumer; this card remains the second, and the shared piece it can reuse is strandedDecisionDetails / strandedDecisionFailure in @objectstack/types (new there in that PR) if a maintainer wants the same field vocabulary on a 400.

---

Generated by Claude Code

[os-zhuang]

分诊路由(本评论来自分诊座位)· R+150 · date -u 实测 2026-09-04T20:09:35Z 一轮

domain:cli · finding · priority:p2。

落点:packages/runtime/src/domains/automation.ts(REST resume 门)⇒ 车道表把 runtime 归 cli 车道(cli/runtime/verify/qa/types/rest/mcp/client*)。⚠️ 卡面自己也点明了这一点(「packages/runtime 是那张卡宣称文件面之外的」),这正是它没被 #13937 顺手修掉的原因。

p2 判据:契约上有一个成员(status: 'stranded')在线上不可达 —— 只有 HTTP 的运维对「这条 run 已经够不着了」和「这条 run 跑了但被拒了」看到的是同一个 400 FLOW_FAILED。⇒ 声明 ≠ 可达(spec 侧的 TriggerFlowResponseSchema.data.status 甚至有 parity pin 钉着四个成员,而其中一个永远出不来)。⛔ 不是 p1:没有错误行为、没有数据问题,缺的是区分度;而且修复动作(#13953 的操作动词门)本身还不存在,所以今天即使分辨出来了也无处可去。⛔ 不是 p3:它是发布出去的线上词表上的一个洞。

⭐ 卡面给的两个方向里,第二个有明确的支持证据,值得在派发词里点名:控制台把 400 FLOW_FAILED 当终态处理(objectui flowResponse.ts 读 success === false || status === 'failed',且 #8684 的危害 pin 钉着这条),⇒ 一个独立的 ADR-0112 码(FLOW_STRANDED)才是让客户端不靠正则匹配消息就能分支的形状;把 status 塞进 400 的 details 里,客户端仍要先信任那个 details 结构。⚠️ 但新增错误码是 ADR-0112 台账上的契约新增 ⇒ 走 Clause-② 复审,⛔ 不是顺手加个字符串。

⚠️ 与 #13953(操作动词无门)是同族但不是重复:本卡是「线上看不出它是 stranded」,那张是「看出来了也没有门可敲」。⇒ 两张都做才有意义,而先后顺序上本卡在前(先有区分度,门才值得建)。

---

Generated by Claude Code