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

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).

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

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:

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.
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

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

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

Claim: PM loop round 15
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). ⛔ endpoint-executor.ts is door 3, out of scope — it is #9462 and the ruling says explicitly it is ⛔ not a rider here.
Container & model: M, mode:subagent, model: opus — a DOWNGRADE from the Clause-② mandate, under one-time maintainer authorization (see below)
Clause-②: yes (unchanged — carried from the triage flag and the maintainer ruling: accept/reject change on a public route).
Serial constraints cleared: packages/runtime — #9416 and #9462 are deliberately NOT dispatched alongside this card. The maintainer was asked again today whether to exempt same-package serialization and answered verbatim 「不豁免，维持串行」, so the 2026-08-13 position stands and only one packages/runtime card runs at a time. #9462 is additionally sequenced after this card by the staging ruling. domains/automation.ts carries no in-flight claim (#8684 bc6434b5b, #8796 a4331227b both landed).

⚠️ Model-tier downgrade, recorded publicly as the rule requires

The account's Fable 5 budget has been exhausted continuously since ~01:2xZ — five independent measurements through ~09:3xZ, the last three taken with a throwaway probe that touches no card. Clause ② is a mandate with no self-service downgrade, so this seat escalated it as budget territory rather than deciding it.

Maintainer authorization, 2026-08-18, verbatim: 「授权一次性降档到 opus」 ("authorize a one-time downgrade to opus"), given in answer to a direct question naming these five cards (#9446, #9416, #9462, #9488, #9487) and stating the trade explicitly: Clause ② exists because contract changes want the highest review tier, so downgrading forfeits that layer for this round.

⇒ This is not the seat relieving its own throughput pressure — that is precisely what the clause forbids and what this seat refused to do at 06:27Z, when it rolled this exact card back rather than re-run it lower. It is a one-time, named-scope exception granted by the rule's owner. ⛔ It does not generalise: the next Clause-② card outside those five needs its own authorization or a recovered budget.

Because the review tier is reduced, the verification bar is not. See the reverse-verification requirement in the dispatch — it is the compensating control.

Stale-premise check on origin/main: the blanket map is still live — err.code = 'FLOW_FAILED' at action-execution.ts:614, with the now-false "the flow RAN and rejected" comment at :610. Probe for the converged shape (result.code / FLOW_DISABLED / FLOW_NO_START_NODE in that file): zero; control (action, same file): 213. The zero is real.

Generated by Claude Code

fix(runtime): /actions answers the #9378 flow-dispatch status table (#…

docs(actions): the action door answers the flow-dispatch table, and a…

PM assessment on PR #9584 — substance looks right. ⛔ NOT flipping to ready: the dev has not reported yet.

This is the card that ran at opus under the maintainer's one-time Clause-② downgrade authorization, so the reduced review tier is paid for by me verifying more, not less. Two readings decide soundness here and I took both myself.

⛔ The release-notes guardrail held

content/docs/releases/ is untouched — verified against the actual changed-file list, not the PR's prose. Worth stating because this PR does edit three other content/docs pages, and the drift check separately flags releases/v17.mdx as named by the change. Named ≠ edited; the read-only page stayed read-only. That is the guardrail working on a diff that had every opportunity to trip it.

"One definition" is structural, not asserted

Both doors import the new module — action-execution.ts:30 and domains/automation.ts:31, from ./flow-dispatch-status.js. So the claim is checkable in the import graph rather than resting on the PR body.

⭐ This is the part I care about more than the mapping, and the PR says so itself: "three doors each holding their own reading of one engine result is exactly what let them answer differently in the first place, so a second copy of the rule is a defect by construction." #9462 (door 3) now has a module to call rather than a third table to write.

The retry-semantics analysis is exactly the thing a Clause-② card owes

My brief said: if any row changes whether a caller should retry, say so explicitly — the status is a contract with the console, not just a number. It did, per row:

409 FLOW_DISABLED — reversible operational state; enable the flow and the identical request succeeds, so a retry after an operator acts is legitimate.
422 FLOW_NO_START_NODE — authoring defect in the stored definition; retrying cannot help.
404 — the action exists, the flow it targets does not; the metadata needs fixing.
400 FLOW_FAILED — unchanged, still terminal, still the only row that says a run happened.

And the compatibility statement is the right one: a caller that treats every non-2xx as "the action failed" is unaffected — all four remain refusals, success: false, no inner envelope. That is the honest scope of the break.

Reverse verification — and a second kind I did not ask for

Predicted 9 red / 4 green before running; got exactly those 9 and exactly those 4. The four survivors are correctly characterised as not pinning the defect — three are regression guards for behaviour that must not change (including the guard against re-introducing the #3962 double envelope, which the ablation restores identically) and the fourth is the parity row that already agreed.

⭐ The one it added on its own: renaming the compared member to a non-member made tsc refuse it — "types … and '"FLOW_DISABLED_TYPO"' have no overlap" — which proves the closed AutomationResult.code union is being read from a rebuilt declaration rather than a stale or any one. That closes a failure mode a behavioural ablation cannot see, and it is the same family as the dist-preflight discipline #9481 used: prove the thing you ablated is the thing under test.

Declared-surface expansion — declared, and each part forced

domains/automation.ts — the delegation. Without it there are still two definitions of one rule, which is what the ruling forbids. packages/runtime is serialised to this card this round, and automation: the run-resume route still answers HTTP 200 wrapping an inner {success:false} — the route #3962's status-code unification left behind #8684/automation resume: the request body's OUTER envelope is lenient — an unknown top-level key is silently ignored and the submission is treated as empty #8796 both landed, so no live claim collides.
content/docs/** — ui/actions.mdx documented the old divergence and cited this very issue, so leaving it would ship docs stating the opposite of the behaviour; and http-protocol.mdx's declared-endpoint row now points at Declared endpoints (type: 'flow'): converge onto the #9378 status table — the ruled follow-up to #9446's staged execution #9462 instead of this card, because after this lands a reader following that link from a line describing an unconverged door would conclude the door was fixed. Both are the change's own consequences, not scope creep.

One gap, honestly reported

check:type-check-debt --re-measure did not complete locally (timed out under contention for the shared build lock). The dev substituted a direct measurement — tsc over packages/runtime including test files reports 227 pre-existing errors and 0 in the new test file, so the diff cannot push the frozen count up — and left the ratchet to CI. ⚠️ That is a substitution, not the gate; I am recording it as such and Lint & Repo Gates is the reading that settles it.

Also correctly left alone: no packages/spec edit (all three codes already registered under @objectstack/runtime), with the observation that their ledger notes still describe only the trigger door as emitter — "incomplete rather than wrong", and the spec seat's to fix. ⛔ Door 3 (#9462) untouched.

Holding for the dev's report, then re-checking the branch head before the ready-flip.

Generated by Claude Code

{
  "issue": 9446,
  "status": "done",
  "branch": "claude/issue-9446-actions-flow-status-table",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/9584",
  "premise_still_valid": true,
  "summary": "Door 2 (`POST /api/v1/actions/:object/:action`, `dispatchFlowAction` in packages/runtime/src/action-execution.ts) now answers the ruled four rows — 404 / 409 FLOW_DISABLED / 422 FLOW_NO_START_NODE / 400 FLOW_FAILED — instead of mapping every `success: false` to the blanket 400. The mapping was extracted into a new module, packages/runtime/src/flow-dispatch-status.ts, and BOTH doors read it: the trigger door's `respondToFlowTrigger` was refactored to delegate, with zero behaviour change, pinned by its own untouched 26-test suite plus the real-AutomationEngine integration test in @objectstack/verify. Door 3 (endpoint-executor.ts) untouched — it is #9462. ZONE 2 ASSUMPTIONS: (1) 'the producer already classifies at door 2' — CONFIRMED: engine.execute stamps code 'FLOW_DISABLED' (engine.ts:3055) and 'FLOW_NO_START_NODE' (engine.ts:3134) and `status: 'failed'` on the ran-and-failed exit, and door 2 receives the same AutomationResult the trigger door does. (2) 'all four rows reachable at door 2' — REACHABLE but NOT via result.code, so the assumed shape was wrong: engine.execute's not-found exit returns `{success:false, error:\"Flow 'X' not found\"}` with NO code and NO status, so 404 could only be answered the way the trigger door answers it — the optional `getFlow` registry probe, run before execute, skipped when the service omits getFlow. Reachability itself holds: a `type:'flow'` action whose `target` names an unregistered flow is not validated anywhere earlier, and door 2 keeps working when getFlow is absent. Worth the PM's eye: 404 now carries two meanings on this route (no such action / no such flow behind the action), told apart by message; both are still 'the thing you asked to run does not exist' and both are non-retryable, so I implemented the ruling as written rather than forking. (3) 'there is a shared definition to delegate to' — FALSIFIED: none existed, all three doors open-coded their own reading. I created one and converted both live doors to it, which expanded the declared file surface by one file (domains/automation.ts) — declared here and in the PR body rather than smuggled; the file carries no in-flight claim (#8684 and #8796 both landed) and packages/runtime is serialised to this card this round. Also outside the named surface: three content/docs pages, one of which (ui/actions.mdx) documented the old divergence and cited this issue by number, so leaving it would have shipped docs stating the opposite of the behaviour. No packages/spec edit was needed or made — all three codes are already registered under @objectstack/runtime in ERROR_CODE_LEDGER. Changeset is `minor` (behaviourally breaking, framed as such in the body per the no-major rule).",
  "tests": "All at final commit 41ff10ed7 (`git rev-parse --short HEAD`), on a tree whose dependency closure was built first; every build/test run wrapped in `flock -E 99 -w N /tmp/os-heavy-verify.lock`. NEW SUITE packages/runtime/src/actions-flow-dispatch-status.test.ts — 13 tests: one per row, plus a set-level distinguishability assertion (statuses [404,409,422,400], 4 distinct statuses, 4 distinct codes, exactly one row claiming FLOW_FAILED), plus a classify-off-the-verdict case (a refusal carrying a failed run's summary/durationMs stays 409), plus the residual guard, plus 4 CROSS-DOOR PARITY cases driving the same AutomationResult through both doors and asserting equal status and code. FULL SUITE `packages/runtime` — 170 files / 2528 tests, all green. `pnpm --filter @objectstack/runtime typecheck` — green (script name echoed, not a zero-match). CONSUMERS, downstream direction (`--filter '...@objectstack/runtime'`, i.e. dependents): @objectstack/client 23 files/310 tests, @objectstack/verify 7/32, @objectstack/cloud-connection 23/191, @objectstack/http-conformance 4/72, @objectstack/hono 2/73 — all green. REVERSE VERIFICATION: the fix was committed first, then ablated (blanket FLOW_FAILED restored at door 2 only), predictions written down BEFORE the run — predicted 9 red (rows 1/2/3, distinguishability, classify-off-verdict, no-getFlow, and 3 of 4 parity cases) and 4 green (row 4, success 200, unclassified-residual guard, the parity row that already agreed), trigger-door suite fully green. ACTUAL: exactly those 9 failed and exactly those 4 passed; failures read `expected 200 to be 404`, `expected 400 to be 409`, `expected 400 to be 422`; trigger suite 26/26 green. The fix was then restored with `git checkout <branch> -- <path>` and `git diff HEAD --exit-code` proved byte-identical restoration. NOT a dist-resolved ablation — it is an in-package vitest run reading src, so no package rebuild was involved or needed; the dogfood ablation preflight does not apply. SECOND REVERSE CHECK (type side): renaming the compared union member to a non-member made tsc refuse it — TS2367 'types ... and \"FLOW_DISABLED_TYPO\" have no overlap' — proving the closed AutomationResult.code union is read from a rebuilt declaration, not a stale or `any` one. Note: an earlier attempt at this check was inconclusive because a build I killed on the harness's 10-minute limit left packages/spec/dist without .d.ts; I rebuilt spec (clean tree afterwards, gen:schema rewrote nothing) and re-ran it. GATES, re-derived from the ACTUAL changed paths via `node scripts/pm/dispatch-gates.mjs` (which named 17 families plus 5 convention-triggered ones, against the dispatch's original 4) — green: check:nul-bytes (plus a manual control-byte grep over the changed files), check:cross-package-test-inputs, check:route-envelope, check:dispatcher-error-vocabulary, check:docs-audit-scope, check:docs-redirects, check:role-word, check:changeset-gate-self-tests, check:objectui-changeset, check-adr-0087-registration, check-changeset-no-major, check-empty-changeset, check-affected-docs, check:query-options-erasure, check:engine-double-contract, check:where-matcher, check:type-check-coverage, and spec liveness (check:liveness, check:empty-state, check:strictness-ledger, check:variant-docs). NOT COMPLETED LOCALLY: `check:type-check-debt --re-measure` — timed out twice under contention for the shared lock (another agent held it for a long dogfood closure build). I measured the thing it would catch instead: tsc over packages/runtime INCLUDING test files (its own tsconfig excludes them) reports 227 pre-existing errors and 0 in the new test file, so this diff cannot ratchet the frozen count up; the structural half is green. CI runs the ratchet. Reported by CI JOB name is the PM's half — CI was not waited on, per the 2026-08-10 ruling.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #9585: a flow ACTION that fails cannot carry the author's `errorMessage` or the run `summary` — `resolveThrownHttpError` builds `error.details` from a closed list (issues/fields) and never reads a thrown `.details`, so the one channel objectui's flowResponse.ts reads is empty at the /actions door. Pre-existing, and after this card it is the only remaining difference between the two doors' answers. Filed unassigned and unlabelled with three options and no recommendation, because widening a resolver two doors share is a contract decision, not a dev-lane call.",
    "filed as #9586 (label `finding`): the ERROR_CODE_LEDGER notes for FLOW_DISABLED and FLOW_NO_START_NODE name `respondToFlowTrigger` as the only emitter; a second door emits them now. Registration and package attribution are unaffected and check:dispatcher-error-vocabulary is green — this is a provenance comment going stale, in a packages/spec file that is the spec seat's, which is why it was filed rather than edited."
  ]
}

Generated by Claude Code

ACCEPT — PR #9584, ready with auto-merge armed. Dev reported status: done; branch head re-checked first, unchanged at 41ff10ed7, still 8 files, and ⛔ content/docs/releases/ re-confirmed untouched.

⭐ Zone 2 assumption 3 was FALSIFIED, and that changed the card's shape

I assumed "there is a shared definition to delegate to" and warned that a fourth open-coded copy would be the real defect. There was no shared definition at all — all three doors open-coded their own reading of one engine result. So the card was not "make door 2 read the shared table"; it was "there is no table, build one and convert the live doors to it."

That is why the file-surface expansion into domains/automation.ts was forced rather than convenient: without it the PR would have left two definitions standing, which is what the ruling forbids. Verified in the import graph — both doors import flow-dispatch-status.js.

⭐ Zone 2 assumption 2 was half-right, and the half that was wrong matters

I assumed all four rows were reachable via result.code. Reachability holds; the mechanism does not. engine.execute's not-found exit returns {success:false, error:"Flow 'X' not found"} with no code and no status, so 404 can only be answered the way the trigger door answers it — through the optional getFlow registry probe run before execute, and skipped when the service omits getFlow.

⇒ Had the dev built the mapping purely off result.code as my brief implied, row 1 would have been unreachable and silently absent — the classic shape of a table that looks complete and has a dead row. It measured instead of assuming.

The judgement call it flagged, and my ruling on it

"404 now carries two meanings on this route (no such action / no such flow behind the action), told apart by message; both are still 'the thing you asked to run does not exist' and both are non-retryable, so I implemented the ruling as written rather than forking."

Correct call, and I am affirming it rather than leaving it hanging. The ruling names 404 for that row specifically so door 2 matches the trigger door, and overloading is not a new divergence — it is two instances of one category, distinguishable by message, identical in retry semantics. Forking here would have been re-litigating a settled ruling on an aesthetic objection, which is exactly what the fork clause is not for. The fork clause exists for "this cannot be done as ruled", not "this could be tidier."

Verification I take on report vs verified myself

Verified myself (the readings that decide soundness for a Clause-② card at a downgraded tier): ⛔ releases untouched · one definition structural in the import graph · 8-file surface unchanged at the final head.

On report, and strong: reverse verification predicted 9 red / 4 green before running and got exactly those, with the four survivors correctly characterised as regression guards rather than defect pins; restoration proved byte-identical with git diff HEAD --exit-code; ⭐ and the type-side second check (renaming the union member → TS2367 "have no overlap") proves the closed AutomationResult.code union is read from a rebuilt declaration, not a stale or any one. That last one closes a failure mode a behavioural ablation cannot see — and the dev disclosed that an earlier attempt at it was inconclusive because a killed build had left packages/spec/dist without .d.ts, then rebuilt and re-ran. Reporting an inconclusive first attempt is worth more than the clean second one.

⚠️ check:type-check-debt --re-measure did not complete locally (lock contention, twice). Substituted with a direct measurement — tsc over packages/runtime including tests: 227 pre-existing errors, 0 in the new file — and left to CI. Recorded as a substitution, not the gate; Lint & Repo Gates settles it.

Follow-ups filed, not fixed

A flow ACTION that fails cannot carry the author's errorMessage or the run summary — the /actions door has no channel for them #9585 — a flow action that fails cannot carry the author's errorMessage or the run summary: resolveThrownHttpError builds error.details from a closed list and never reads a thrown .details, so the one channel objectui's flowResponse.ts reads is empty at this door. ⭐ After this card, that is the only remaining difference between the two doors' answers — a precise statement of what convergence did and did not buy. Filed unassigned, three options, no recommendation, because widening a resolver two doors share is a contract decision.
finding: FLOW_DISABLED / FLOW_NO_START_NODE ledger notes name the trigger door as the only emitter — a second door emits them now #9586 (finding) — the ERROR_CODE_LEDGER notes for FLOW_DISABLED / FLOW_NO_START_NODE name respondToFlowTrigger as the only emitter, and now a second door emits them. Provenance going stale in a packages/spec file ⇒ the spec seat's, filed not edited.

⛔ Door 3 (#9462) untouched, as ruled — and it now has a module to call rather than a third table to write.

Generated by Claude Code

fix(runtime): declared `type: 'flow'` endpoints answer the #9378 flow…

fix(runtime): /actions answers the objectstack-ai#9378 flow-dispatch …

fix(runtime): declared `type: 'flow'` endpoints answer the objectstac…

docs(spec): record the second FLOW_DISABLED / FLOW_NO_START_NODE emit…

fix(spec): the error-code waiver reasons and the auth-feature registr…

Navigation Menu

Repository navigation

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

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

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

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

The decision this needs

⚠️ Model-tier downgrade, recorded publicly as the rule requires

⛔ The release-notes guardrail held

"One definition" is structural, not asserted

The retry-semantics analysis is exactly the thing a Clause-② card owes

Reverse verification — and a second kind I did not ask for

Declared-surface expansion — declared, and each part forced

One gap, honestly reported

⭐ Zone 2 assumption 3 was FALSIFIED, and that changed the card's shape

⭐ Zone 2 assumption 2 was half-right, and the half that was wrong matters

The judgement call it flagged, and my ruling on it

Verification I take on report vs verified myself

Follow-ups filed, not fixed

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

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

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

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

The decision this needs

Activity

os-zhuang commented on Aug 18, 2026

os-zhuang commented on Aug 18, 2026

os-zhuang commented on Aug 18, 2026

os-zhuang commented on Aug 18, 2026

os-zhuang commented on Aug 18, 2026

⚠️ Model-tier downgrade, recorded publicly as the rule requires

os-zhuang commented on Aug 18, 2026

⛔ The release-notes guardrail held

"One definition" is structural, not asserted

The retry-semantics analysis is exactly the thing a Clause-② card owes

Reverse verification — and a second kind I did not ask for

Declared-surface expansion — declared, and each part forced

One gap, honestly reported

os-zhuang commented on Aug 18, 2026

os-zhuang commented on Aug 18, 2026

⭐ Zone 2 assumption 3 was FALSIFIED, and that changed the card's shape

⭐ Zone 2 assumption 2 was half-right, and the half that was wrong matters

The judgement call it flagged, and my ruling on it

Verification I take on report vs verified myself

Follow-ups filed, not fixed

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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

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

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

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