service-automation: `subflow` and `map` roll a child's contained failures into the parent's `failed` through the `ExecutionStepMetrics` failure slot ruled on #15617

[os-zhuang]

Services half of the #15617 ruling (director seat, decision batch #55, maintainer 「同意」 on option 1, 2026-09-06). Blocked-by: #15617 — the spec half must land first (the failure slot on ExecutionStepMetricsSchema and the reconciled FlowRunSummary paragraphs).

What this card lands

• packages/services/service-automation/src/subflow-node.ts rolls the child run's failed into the new failure slot alongside the selected / acted / unmeasuredEffect it already rolls up; the map node does the same for its per-row children (re-check: the card says map may not share the same roll-up path — measure it, do not assume).
• The run-level failed fold therefore counts a delegating node's contained child failures. Measured target (from spec: FlowRunSummary's two paragraphs disagree for a subflow parent — failed is declared a node fold, while the summary is declared to answer "what did this run cause" and roll a child's totals up #15617): parent loop { subflow(child) } with one child failing per five rows answers failed=1, not 0; the control (a child that fails rather than contains a failure) keeps answering exactly as today (call: {runs:5, failures:1}, parent failed=1) — pin both.
• PR service-automation: populate the contained-failure visibility contract — FlowRunSummary.failed fold, loop iteration through try_catch, $error.iteration / $error.item, failed= on the summary line #15609's narrowed wording ("no node execution of this run failed") is widened back to the summary's declared question once this lands; the changeset says what moved on the wire total.
• patch on @objectstack/service-automation unless the seat measures a surface move; Clause-② re-derived from the diff (the wire total's semantics move — declare honestly).

Re-check before claiming

grep -n "unmeasuredEffect\|ExecutionStepMetrics" packages/services/service-automation/src/subflow-node.ts
grep -n "failures" packages/spec/src/automation/execution.zod.ts   # the slot must exist on main before this claim

[os-trump]

Two line items handed to this card from the spec half's contract review (#15617 / PR #16635)

domain:spec seat, session session_01F8SRGcf2eKTK7RRpWCGxwf, 2026-09-07T14:59Z. ⛔ No label or field on this card is changed by this seat — it stays pm:blocked behind #15617, and this is a note so two items do not arrive as surprises when it unblocks.

The at-tier contract review of the spec half surfaced work that is this card's content, not the spec half's. Both are recorded here rather than left as 「noted, not filed」 with no taker.

1. ⭐ A roll-up site the spec half's PR body does not name

The reviewer measured that the PR's verified site list is 2 of 3: subflow-node.ts and map-node.ts are named, but AutomationEngine.creditChildRun (engine.ts:5351-5371) is the only path by which a durably-PAUSED subflow/map child that later completes reaches the parent's step (call sites :5485 up-bubble, :5560 down-delegation). The contract's semantic sentence covers that child; the spec changeset's "what this does not do yet" does not. ⇒ When this card rolls the child's contained failures up, that third site is in scope — a two-site implementation would silently miss every child that paused and resumed.

2. run-summary.ts:143 must be decoupled here, and the spec half now says so explicitly

node.status is derived from node.failures > 0. Once the slot folds rolled-up failures into nodes[].failures, that derivation stops meaning what it says. ⚠️ The reviewer confirmed landing the declaration without the decoupling makes nothing currently-true false — the fold reads only selected/acted/unmeasuredEffect, so node.failures stays own-only until this card lands — so there is no rush item on the spec half. But the spec half deliberately landed the instruction: FlowRunNodeSummary.status's describe now reads "judged on this node's OWN executions … success with failures > 0". That sentence is the decoupling spec for this card.

3. A docs cross-reference that goes stale on the spec half's merge

content/docs/automation/flows.mdx:1030 carries the parenthetical "that inconsistency in the declaration is #15617". That goes false the moment #15617 merges — the declaration is then reconciled and the only remaining gap is this engine half. The docs drift check's own comment says it cannot see this row, so nothing mechanical will catch it. ⇒ Re-point it at this card (or drop it) as part of this card's diff. The ruling already assigns the widening of PR #15609's narrowed wording to this lane once both halves land; this is the same class of cleanup.

⚠️ One thing to read before implementing, because it is the spec half's known trap

The spec contract says a child that FAILED is the delegating step's own single failure with nothing rolled up — and that this holds whether or not the child also contained failures before it failed (its summary.failed, contained and fatal alike, stays on its own row). The reviewer's concrete warning: an implementer who adds failures: child.summary.failed to the rolled object in subflow-node.ts:132-142 double-counts on the failed arm, because acted genuinely does ride up on that arm through the same object (:144-147) while failures must not. The spec half is being patched to state this explicitly rather than by analogy — ⛔ implement from the merged contract text, not from the acted precedent.

---

Generated by Claude Code