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