Declared endpoints (`type: 'flow'`): converge onto the #9378 status table — the ruled follow-up to #9446's staged execution

[os-zhuang]

Filed by the triage seat as the door-3 half of the #9446 ruling (maintainer, 2026-08-18, verbatim 「同意」: the #9378 status table is a property of the flow-dispatch CONTRACT, executed in stages — door 2 in #9446 itself, door 3 as this card).

Scope

packages/runtime/src/endpoint-executor.ts's flow branch currently ends with an unconditional successAnswer(await automation.execute(...)) — HTTP 200 wrapping {"success":false,...} on every failure, the double envelope #3962 ruled out for /actions. Converge it onto the four-row table the trigger routes answer after #9413/#9415 (404 / 409 FLOW_DISABLED / 422 FLOW_NO_START_NODE / 400 FLOW_FAILED), consuming the producer's result.code.

Constraints (from the ruling)

• The envelope flip is BREAKING for any consumer of the current double envelope on declared endpoints. The PR must say so plainly, and landing is sequenced against consumers — enumerate them (objectui, examples, docs) with real greps before flipping, and coordinate the objectui half if one exists.
• Door 3 carries the endpoint policy chain and outputMapping, so this is not a copy of door 2's mapper — the mapping must sit where those still apply.
• content/docs/protocol/kernel/http-protocol.mdx's boundary wording (corrected by spec: add FLOW_DISABLED / FLOW_NO_START_NODE to AutomationResult.code and deliver the trigger ruling's remaining two rows (409/422) #9415 to describe the divergence) flips back to "same response contract" in the same PR.
• Clause-②: yes — accept/reject behavior changes on a public surface; contract-review tier dispatch, claim carries Clause-②: yes.
• If implementation surfaces a reason door 3 cannot converge, report the fork back to the decision inbox — no silent scope change.

Refs: #9446 (the ruling record) · #9378 (the table) · #9413 / #9415 (doors 1's rows) · #3962 (the double-envelope precedent).

Filed by triage session session_pm_triage_20260818T0104Z; ruling provenance on #9446.

[os-zhuang]

Claim: PM loop round 18
Session: session_012WKSnqAaoqtW3QX7SSf1Vk
Branch: claude/issue-9462-declared-endpoints-status-table
Worktree: objectstack-issue-9462
Domain: domain:cli
File surface: packages/runtime/src/endpoint-executor.ts + its test siblings, and content/docs/protocol/kernel/http-protocol.mdx (the boundary wording this card's own body says flips back) — stop on breach; explain in the report
Container & model: M–L, mode:subagent, model: opus — a DOWNGRADE from the Clause-② mandate, under the maintainer's one-time authorization
Clause-②: yes, verbatim from this card's own body — accept/reject behaviour changes on a public surface.
Serial constraints cleared: packages/runtime freed at 12:38:35Z — #9446 landed (PR #9584). Verified on origin/main by probe, ⛔ not taken from the merge event: flow-dispatch-status is referenced by exactly 2 files, action-execution.ts and domains/automation.ts — the two live doors — against a control of 243 files in packages/runtime/src. ⚠️ #9416 and #9457 are deliberately NOT dispatched alongside this card (same package; the maintainer re-confirmed 「不豁免，维持串行」 on 2026-08-18). This card goes first because the staging ruling sequenced door 3 after door 2, and door 2 has just landed.

Model-tier downgrade, recorded as the rule requires

Maintainer authorization, 2026-08-18, verbatim: 「授权一次性降档到 opus」, given in answer to a direct question naming five cards — #9446, #9416, #9462, #9488, #9487 — while the Fable 5 budget was exhausted (five measurements, ~01:2x through ~09:3x, the last three by throwaway probe touching no card). ⛔ The authorization does not generalise beyond those five.

The review tier is reduced; the verification bar is not. The reverse-verification requirement below is the compensating control, and I will verify the breaking-change analysis myself rather than on report.

Premise re-verified on origin/main this round

• Door 3 still ends its flow branch with an unconditional return successAnswer(await automation.execute(plan.flow, automationContext)); — endpoint-executor.ts:483 (control: the file is 508 lines, so it resolves).
• ⭐ endpoint-executor.ts has zero references to flow-dispatch-status — the shared module The other two flow-dispatch doors never got the #9378 status table — /actions mislabels never-dispatched refusals, declared endpoints still answer 200 #9446 just created exists and this door is not yet wired to it. That wiring is the card, and it is why the ruling staged this after door 2: there is now one definition to call rather than a third table to write.

⚠️ What makes this card heavier than #9446, and what the dispatch will demand

The envelope flip is breaking for any consumer of the current HTTP 200 {"success":true,"data":{"success":false,...}} double envelope — the shape #3962 already ruled out for /actions. The card's own constraints require the consumers be enumerated with real greps before flipping, and the objectui half coordinated if one exists. My starting measurement for the dev to extend rather than trust: packages/client/src/index.ts plus two of its test files match the double-envelope shape.

⛔ If implementation surfaces a reason door 3 cannot converge, that is a fork report back to the decision inbox — ⛔ never a silent scope change. And door 3 carries the endpoint policy chain and outputMapping, so this is not a copy of door 2's mapper: the mapping has to sit where those still apply.

---

Generated by Claude Code