The other two flow-dispatch doors never got the #9378 status table — `/actions` mislabels never-dispatched refusals, declared endpoints still answer 200

[os-zhuang]

Found while implementing #9415 (the #9378 ruling's remaining two rows). Filed unassigned for triage — not fixed there: #9378 ruled the two trigger routes, and what these two doors should answer is a contract decision of its own, not a mechanical extension.

Three doors dispatch a flow through IAutomationService.execute. Only one of them classifies the result.

1. POST /api/v1/automation/:name/trigger (+ the legacy spelling) — CORRECT

respondToFlowTrigger (packages/runtime/src/domains/automation.ts) answers the full four-row table after #9413 + #9415:

engine exit	answer
flow not found	404
flow disabled	409 FLOW_DISABLED
flow has no start node	422 FLOW_NO_START_NODE
ran and failed	400 FLOW_FAILED

2. POST /api/v1/actions/:object/:action with type: 'flow' — MISLABELS two of the four

packages/runtime/src/action-execution.ts maps any success: false result to one code:

if (result && typeof result === 'object' && 'success' in result && result.success === false) {
    const err: any = new Error(`Flow '${action.target}' failed: ${result.error ?? 'unknown error'}`);
    err.status = 400;
    err.code = 'FLOW_FAILED';
    throw err;
}

Its comment says "The flow RAN and rejected" — which is now false for two of the exits it catches. A disabled flow invoked through an action answers 400 FLOW_FAILED, telling the caller a run failed when no node ever executed. The producer's result.code is available and ignored.

3. Declared endpoints (type: 'flow') — still fully pre-#9378

packages/runtime/src/endpoint-executor.ts ends the flow branch with:

return successAnswer(await automation.execute(plan.flow, automationContext));

Unconditional 200. Every failure — including a run that ran and failed — still rides the double envelope #3962 ruled out for /actions: HTTP 200 {"success":true,"data":{"success":false,...}}. This door was not in #9413's scope and nothing has flipped it since.

Consequence for the docs: content/docs/protocol/kernel/http-protocol.mdx describes a type: 'flow' endpoint as "delegated to the same automation pipeline as POST /api/v1/automation/{name}/trigger". True of the context builder and the service method, no longer true of the response. #9415 corrects that page's wording to state the boundary; it does not change the behaviour.

The decision this needs

Whether the #9378 table is a property of the flow-dispatch contract (all three doors converge) or of the trigger route (the others keep their own envelope conventions deliberately). Door 3 additionally carries the endpoint policy chain and outputMapping, so converging it is not a copy of the mapper.

Note both doors also answer for FLOW_FAILED today, so this is not created by #9415 — that card only makes the divergence wider and easier to see, because the producer now says which refusal it is.

Refs: #9378 (the ruling) - #9413 (rows 1-2) - #9415 (rows 3-4) - #3962 (the /actions double-envelope ruling).

[os-zhuang]

Triage: lands in packages/runtime (action-execution.ts + endpoint-executor.ts) ⇒ domain:cli, type Bug, needs-user-decision — the scope question ("is the #9378 table a property of the flow-dispatch contract or of the trigger route?") is a public-contract ruling, and door 3 carries real semantic differences (endpoint policy chain, outputMapping, the #3962 double-envelope legacy) that keep it out of the sibling-inheritance lane.

Four-facet card face:

• Platform long-term coherence: one engine exit vocabulary answered three different ways at three doors is exactly the divergence [17.0.0-rc] /actions reports business failures as HTTP 200 inside a double envelope — the only route of 12 that does; unify on real status codes before GA #3962/automation: both trigger routes still answer HTTP 200 wrapping an inner {success:false} — the same #3962 residue #8684 closed on resume #9378 have been retiring; ruling "contract property" closes the family instead of the instance.
• Measured business pull: door 2's mislabel is live today — a disabled flow invoked via an action reads as "ran and failed" (400 FLOW_FAILED) with the producer's true code available and ignored; door 3 still answers the [17.0.0-rc] /actions reports business failures as HTTP 200 inside a double envelope — the only route of 12 that does; unify on real status codes before GA #3962-condemned 200 {success:true,data:{success:false}}.
• AI-agent error-resistance: callers (and generated clients) branching on FLOW_FAILED today learn wrong facts on two doors; a closed, shared table is the refusal-vocabulary discipline ADR-0112 exists for.
• Startup scope discipline: door 2's convergence is a small mapper change consuming result.code; door 3 is the real cost (envelope flip on declared endpoints = a breaking change for any consumer of the double envelope).

Recommendation: rule the table a property of the flow-dispatch contract, staged — door 2 converges now (it already claims #9378's semantics in its own comment; it just predates producers that classify); door 3 converges as its own follow-up card with the envelope-flip called out as breaking and sequenced against consumers, rather than silently inside this one. If instead the ruling is "trigger-route-only", doors 2/3 need their conventions written down where #9415's docs correction points, so the boundary is deliberate rather than residue.

Triage seat routine — session session_pm_triage_20260818T0104Z.

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling recorded — maintainer, 2026-08-18, batch acceptance of the triage seat's decision-inbox recommendations, verbatim: 「同意」. Provenance: triage session session_pm_triage_20260818T0104Z.

Ruled: the #9378 status table is a property of the flow-dispatch CONTRACT — all three doors converge — executed in stages:

1. Door 2 (/actions, action-execution.ts) converges NOW — this card's scope: consume the producer's result.code instead of the blanket FLOW_FAILED, mapping the same four rows the trigger routes answer (404 / 409 FLOW_DISABLED / 422 FLOW_NO_START_NODE / 400 FLOW_FAILED). Clause-②: yes (accept/reject change on a public route) — contract-review tier dispatch.
2. Door 3 (declared endpoints, endpoint-executor.ts) converges as its own follow-up card — filed separately with the envelope flip explicitly marked breaking and sequenced against consumers of the current double envelope; ⛔ not a rider here.

If implementation surfaces a reason door 3 cannot converge, that is a fork report back to the inbox, not a silent scope change.

Label needs-user-decision → pm:queue (door-2 work) in the same stroke.

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop round 14
Session: session_012WKSnqAaoqtW3QX7SSf1Vk
Branch: claude/issue-9446-actions-flow-status-table
Worktree: objectstack-issue-9446
Domain: domain:cli
File surface: packages/runtime/src/action-execution.ts + its test siblings (stop on breach; explain in the report). ⛔ packages/runtime/src/endpoint-executor.ts is door 3 and out of scope — the ruling files it as its own card and says explicitly it is ⛔ not a rider here.
Container & model: M, mode:subagent, model: claude-fable-5
Clause-②: yes (carried from the triage seat's ⚠️ line and the maintainer ruling — accept/reject change on a public route).
Serial constraints cleared: packages/runtime — #9416 is the other queue card in this package and is deliberately NOT dispatched this round (same package ⇒ serial; the maintainer declined the same-package exemption twice on 2026-08-13). packages/runtime/src/domains/automation.ts is untouched by this card and holds no in-flight claim (#8684 bc6434b5b and #8796 a4331227b both landed). #9378 belongs to session_01NYgmGheCzM6NrHZN436Cxf and is ⛔ not touched — but it is the source of the status table this card consumes, so its landed rows are the reference, not a thing to re-decide.

Tier derivation (node scripts/pm/dispatch-gates.mjs --tier packages/runtime/src/action-execution.ts, run now, not recalled): "no path-derived mandate … Clause ② is NOT reachable from paths … judged from the card CONTENT. This line is a FLOOR, never a clearance." The floor clears nothing; Clause ② is what sets the tier here, and a mandatory clause outranks any size/model line recorded on the card.

⚠️ Known risk to the dispatch, stated up front: the account's Fable 5 quota was exhausted at ~01:2xZ today and an os-dev at claude-fable-5 died mid-run on an API error once already this session. Clause ② is a mandate with no legitimate downgrade, so the alternative to trying is not "dispatch at opus" — it is "do not dispatch". This dispatch therefore doubles as the quota probe. If the agent dies on quota, the claim stays and the card is re-dispatched when the budget recovers; ⛔ it will not be quietly re-run at a lower tier.

Stale-premise check on origin/main (8a56ad5a1): the blanket map is still there — err.code = 'FLOW_FAILED' at action-execution.ts:614, with the now-false "the flow RAN and rejected" comment above it at :610. Probe for the converged shape (result.code / FLOW_DISABLED / FLOW_NO_START_NODE in that file) returns zero, and the control (action, 213 hits in the same file) is non-zero, so the zero is real. Last commit touching the file is 445ae4deb, unrelated.

---

Generated by Claude Code

[os-zhuang]

Claim withdrawn — the round-14 dispatch died on quota, and the card returns to pm:queue unassigned. State rolled back in one stroke: assignee cleared, pm:dispatched → pm:queue. ⛔ Nothing was implemented; the branch claude/issue-9446-actions-flow-status-table was never created.

What was measured (this dispatch doubled as the quota probe my claim comment announced): an os-dev launched at claude-fable-5 at ~06:27Z terminated immediately with "You've reached your Fable 5 limit." The account's Fable 5 budget has now been exhausted continuously since ~01:2xZ — five hours, across two independent deaths (the earlier one killed #9232's first agent mid-run).

Why this card cannot simply run at opus. Clause ② is a mandate, not guidance. It applies here twice over — the triage seat flagged it, and the maintainer's ruling comment names it explicitly ("Clause-②: yes (accept/reject change on a public route) — contract-review tier dispatch"). A mandate has no legitimate downgrade, so the alternative to dispatching at the mandated tier is not "dispatch lower" — it is do not dispatch. Downgrading here would be the seat quietly overriding a maintainer instruction to relieve its own throughput pressure, which is exactly the failure the clause exists to prevent. (Contrast #9232, where fable was only guidance from a cited precedent tier: that one was legitimately dropped to opus, and the downgrade was recorded publicly rather than taken silently.)

Consequence for this lane, stated plainly: three ruled, ready domain:cli cards are now blocked on budget alone, with no technical obstacle between them and a dev —

card	why it is fable-mandatory	readiness
#9446 (this card)	accept/reject change on POST /api/v1/actions/:object/:action	fully ruled, four rows specified, premise re-verified on origin/main @ 8a56ad5a1
#9416	accept/reject change on the automation resume route (Option A ruled)	fully ruled; triage wrote Clause-②: yes into the card
#9462	door 3's envelope flip — breaking change on declared endpoints	queued, the ruled follow-up to this card's stage 2

This is left as a plain pm:queue card, deliberately. It is not pm:blocked (no upstream issue blocks it — Blocked-by: takes an issue number and a budget is not one) and it is not pm:on-hold (nobody decided "not now"; the work is ruled and wanted). A queue card with the obstacle written in its thread is the honest state: the next selection round will read these comments — that is mandatory — and see both that the card is ready and why it did not run.

Restart condition, for whoever picks it up: re-dispatch at claude-fable-5 as soon as the Fable budget recovers. ⛔ Do not re-dispatch at a lower tier, and ⛔ do not re-derive the tier from paths — dispatch-gates.mjs --tier returns no path mandate for packages/runtime/src/action-execution.ts and says so itself: "Clause ② is NOT reachable from paths … This line is a FLOOR, never a clearance."

Quota is budget territory and therefore the maintainer's floor, not a seat decision — escalated in this round's report rather than worked around here.

Session session_012WKSnqAaoqtW3QX7SSf1Vk, PM loop round 14.

---

Generated by Claude Code