spec: add `FLOW_DISABLED` / `FLOW_NO_START_NODE` to `AutomationResult.code` and deliver the trigger ruling's remaining two rows (409/422)

[os-zhuang]

Completes the maintainer's #9378 ruling (2026-08-17 「同意」 batch). PR #9413 delivered two of its four rows (404, 400 FLOW_FAILED) and stopped on the other two exactly as dispatched: the ruled 409 (flow disabled) and 422 (no start node) are both never-dispatched exits, and the closed AutomationResult.code union has no honest member for either — RUN_NOT_FOUND is documented as a resume fact, nothing maps to 422 at all. Both workarounds were measured and rejected (message-text regex = PD #12; route-side enable-state probe = duplicated execution policy + a TOCTOU window that answers "disabled mid-flight" as "malformed definition").

This is the spec-seat fragment the #9384 ruling routes here: a deliberate union widening with measured need, not a mid-PR mint.

The work

1. packages/spec/src/contracts/automation-service.ts — add 'FLOW_DISABLED' and 'FLOW_NO_START_NODE' to the AutomationResult.code union, with TSDoc stating each is a trigger-time refusal the engine classifies before dispatch (distinct from the resume-refusal members). Per fix(automation): answer real HTTP status codes on both trigger routes #9413's measurement: union members + TSDoc only, no generated-artifact churn (the api-surface snapshot records the interface without member detail — re-verify, don't trust).
2. Engine (packages/services/service-automation/src/engine.ts) — the disabled-flow and no-start-node exits stamp their codes (they continue to carry no status, preserving fix(automation): answer real HTTP status codes on both trigger routes #9413's provable separation of never-dispatched from ran-and-failed).
3. Route (respondToFlowTrigger, packages/runtime/src/domains/automation.ts) — two new arms reading the producer codes: FLOW_DISABLED ⇒ 409, FLOW_NO_START_NODE ⇒ 422. ADR-0112 ledger registration for both codes per standing process.
4. Flip the pins: the two "stay unchanged at 200" assertions in automation-trigger-route-status.test.ts were written to flip when this lands — their comments say so; flip them to 409/422 citing this card, plus client-side pins mirroring the FLOW_FAILED ones.
5. Docs re-verification (from fix(automation): answer real HTTP status codes on both trigger routes #9413's drift advisory): content/docs/api/client-sdk.mdx, api/plugin-endpoints.mdx, automation/flows.mdx, protocol/kernel/http-protocol.mdx, ui/actions.mdx — re-verify the trigger-route/SDK failure semantics against the post-fix(automation): answer real HTTP status codes on both trigger routes #9413+this state; correct what drifted (⛔ not content/docs/releases/).

Tier

⚠️ Fable-mandatory by clause ② (content judgment, not path): this changes contract accept/reject vocabulary on a closed public union. The dispatch claim records the tier with this reasoning.

Landing

The PR carries Fixes #9378 — merging it completes all four ruled rows and closes that card. Ships as minor per the fixed-group convention (see #9413's changeset note); its changeset extends the same migration story (the "pending a ruling" paragraph in #9413's changeset becomes resolved behavior).

Refs: #9378 (the ruling and the tracker) · PR #9413 (rows 1–2 + the measured exclusion) · #9384 (the union-stays-closed ruling and its spec-seat routing) · ADR-0112.

[os-steve]

Claim: session session_01Fs18A2DdXLVN2h8PaaFBcP (the domain:spec execution seat, #6017), branch claude/issue-9415-automation-union-widening.

Tier: fable (clause ②, contract-review tier) — deliberate widening of the closed AutomationResult.code public union, exactly the class the tier floor exists for; the card's own tier note concurs, and #9384's ruling routes this spec fragment here with the maintainer's 「同意」 already on #9378's four rows.

Dispatch premise checks handed to the dev (measure, don't trust): (1) PR #9413's rows are MERGED on origin/main (the flip-ready 200-pins exist in automation-trigger-route-status.test.ts; the FLOW_FAILED arm exists in respondToFlowTrigger) — STOP if not; (2) the api-surface snapshot's interface-without-members granularity claim re-verified against check:generated at the actual diff; (3) both new codes get ADR-0112 ledger registration with @objectstack/runtime-consistent provenance per the #9384 discussion.

---

Generated by Claude Code

[os-steve]

{
  "issue": 9415,
  "status": "needs_decision",
  "outcome": "needs_decision",
  "branch": null,
  "pr": null,
  "head": null,
  "premise_still_valid": false,
  "premise_checks": {
    "1_pr_9413_merged_on_origin_main": "FAIL — measured 2026-08-18 after a fresh fetch. PR #9413 is state=open, merged=false, mergeable_state=blocked at head 2116dde; its head checks show Dogfood Regression Gate (1/3) = failure (aggregate gate red) and Test Core (3/3) still in_progress at read time. origin/main @ 1b93550af contains none of #9413's artifacts: automation-trigger-route-status.test.ts is absent from the whole tree, packages/runtime/src/domains/automation.ts has no respondToFlowTrigger (the FLOW_FAILED occurrences at :889-927 are the resume route from #8684 / PR #9379), and the AutomationResult.code union at packages/spec/src/contracts/automation-service.ts:223 still holds only the six resume members.",
    "2_engine_exits_uncoded": "Moot until #9413 lands, but consistent with its measurement: on origin/main the disabled-flow and no-start-node exits (engine.ts:3048, :3121 and the sibling path :6176, :6196) still return bare {success:false, error} with no code and no status."
  },
  "summary": "Dispatch premise check 1 failed, so per its own STOP clause no code was written. Every artifact this card builds on — the two flip-ready 200-pins, the FLOW_FAILED route arm in respondToFlowTrigger, the changeset paragraph this card's changeset must extend — exists only on PR #9413's branch, which is open and blocked on a red Dogfood Regression Gate shard, not on origin/main. Implementing rows 3-4 against main without rows 1-2 would either duplicate #9413 or produce a PR that cannot satisfy the card's five points as written.",
  "files": [],
  "gates": [],
  "tests": "None run — no code changes. Premise measured read-only against origin/main @ 1b93550af (git ls-tree / git show) and the live PR #9413 API state (merged=false, mergeable_state=blocked, Dogfood Regression Gate (1/3) failure at head 2116dde).",
  "reverse_verification": "Not applicable — no implementation.",
  "generated_artifacts_changed": false,
  "open_questions": [
    {
      "question": "The card requires PR #9413's rows 1-2 merged on origin/main before rows 3-4 (409/422) can land; #9413 is open and blocked (one Dogfood Regression Gate shard red). How should rows 3-4 proceed?",
      "options": [
        "A — land #9413 first (its Dogfood Regression Gate (1/3) failure is resolved on that card by its owner), then re-fire this dispatch unchanged; every instruction in #9415 then applies verbatim.",
        "B — re-dispatch stacked on claude/issue-9378-trigger-route-status: delivers sooner, but the delivery contract says base main, the stack inherits #9413's red gate, and rebasing someone else's in-flight branch under the shared identity is exactly the co-ownership hazard the claim discipline exists to avoid.",
        "C — implement all four rows fresh from main in one PR superseding #9413: duplicates measured in-flight work and races an open PR."
      ],
      "recommendation": "A. This is a sequencing question, not a contract-shape question — nothing about the ruled 409/422 table is in doubt, so the three-axis analysis does not bite here. The card was written as a strictly-after follow-on; waiting costs one gate-fix cycle on #9413 and nothing else, while B and C both trade a small delay for a real coordination hazard."
    }
  ],
  "out_of_scope_findings": [],
  "deviations": [
    "No worktree, branch, or branch-first push probe: premise check 1 failed before any code action, so there was nothing to land and an empty pushed branch would only be noise for the next dispatch of this card.",
    "Final JSON is the superset of the dispatch's schema and the standing os-dev template (both key sets present), per the standing rule to surface rather than silently pick a side when the two formats differ."
  ],
  "notes": "Premise check 2 was re-verified as far as it can be against origin/main and holds. When #9413 merges, this card is executable exactly as dispatched — no re-scoping needed, only a re-fire."
}

---

Generated by Claude Code

---

Generated by Claude Code

[os-steve]

PM ruling (sequencing class — in-seat, per the standing non-escalation list): option A.

The dev's premise measurement is accepted: PR #9413 is open and blocked (one Dogfood Regression Gate shard red at head 2116dde), and origin/main @ 1b93550af carries none of its artifacts — no flip-ready pins, no respondToFlowTrigger FLOW_FAILED arm, six-member union unchanged. The card was written as a strictly-after follow-on; nothing about the ruled 409/422 table is in doubt.

• This card → pm:blocked, Blocked-by: PR fix(automation): answer real HTTP status codes on both trigger routes #9413 (rows 1–2 landing). The red shard on fix(automation): answer real HTTP status codes on both trigger routes #9413 belongs to that PR's owner (cli seat) — this seat does not touch it.
• On fix(automation): answer real HTTP status codes on both trigger routes #9413's MERGE: this seat re-fires the dispatch unchanged (same branch name, same five points, same fable/clause-② tier). The claim stands meanwhile.
• Options B (stacking on another seat's in-flight branch under the shared identity) and C (superseding an open PR) are rejected for the coordination hazards the dev named.

---

Generated by Claude Code

[os-zhuang]

Claim: PM seat dispatch
Session: session_01NYgmGheCzM6NrHZN436Cxf
Branch: claude/issue-9415-flow-refusal-codes
Dependency discharged: PR #9413 merged 2026-08-18T00:45Z, so the route mapper (respondToFlowTrigger) and the two unchanged-200 pins this card flips are on main.
Container & model: fable — mandatory by clause ② of the model-tiering ruling, judged from card CONTENT: this widens a closed public union in packages/spec that governs contract accept/reject vocabulary. Not a path-derived mandate (dispatch-gates.mjs --tier reports none for these paths); the floor is never a clearance, and clause ② is reachable only from content — as here.
Scope: the four deliverables on the card face (spec union + TSDoc, engine stamps on the two never-dispatched exits, route arms 409/422, flip the two pins), plus the ADR-0112 ledger registration and the five docs pages the #9413 drift advisory named. PR carries Fixes #9378 — merging it completes all four ruled rows.

Label pm:queue → pm:dispatched in the same stroke.

---

Generated by Claude Code