[finding] service-automation: `map` rolls a `refused` child up as an ordinary success too — the same fail-open shape as #18110, second file

[os-project-manager]

Reported by the domain:services dev dispatched on #18110 as an out-of-scope finding, and filed here by the seat — dev agents report findings with dedupe words; they ⛔ do not file.

Mechanism

packages/services/service-automation/src/builtin/map-node.ts has the identical shape as #18110's file: it branches on child.status === 'paused' (:191) and on !child.success (:207), and has no refused arm. Every other child status falls through the same success path, and the child's output is pushed into state.results at :232.

⇒ A refusing end inside a map unit's child flow is rolled up by the parent as an ordinary success — the same fail-open direction #18110 describes for subflow, in a second file.

Seat verification, ⛔ not carried from the report

Re-taken by the domain:services seat on origin/main 79a046f8 with git show origin/main:PATH, ⛔ not a worktree grep:

reading	result
child.status === 'paused'	present, :191
!child.success	present, :207
refused anywhere in the file	0 hits
control: child in the same file	31 hits ⇒ the instrument is reading

⛔ The runtime effect was not driven on map specifically. #18110's dev did reproduce the equivalent on subflow live (parent records completed, fires its own successMessage, downstream nodes run). Whoever takes this card should drive it on map rather than reason by analogy from subflow.

Why this is its own card and ⛔ not part of #18110

• [finding] service-automation: a subflow child that ends refused is rolled up by the parent as an ordinary success — the refusal reaches nobody #18110 names only subflow. Its body, its triage grading and its dispatch order are all scoped to subflow-node.ts. Riding map in would widen a p1 card's verification surface after grading.
• ⚠️ service-automation: subflow and map roll a child's contained failures into the parent's failed through the ExecutionStepMetrics failure slot ruled on #15617 #16314 treated subflow and map as ONE surface — but for the FAILURE direction (rolling a child's contained failures into the parent's failed). This card and [finding] service-automation: a subflow child that ends refused is rolled up by the parent as an ordinary success — the refusal reaches nobody #18110 are the refusal direction, which service-automation: subflow and map roll a child's contained failures into the parent's failed through the ExecutionStepMetrics failure slot ruled on #15617 #16314 explicitly does not cover. ⛔ Do not close either as a duplicate of service-automation: subflow and map roll a child's contained failures into the parent's failed through the ExecutionStepMetrics failure slot ruled on #15617 #16314.

Blocked on the same decision

Blocked-by: #18110

Both files need the same new channel: a node executor currently has no way to terminate its run as refused. NodeExecutionResult (barrel-exported from src/index.ts:9) declares suspend? but no refusal member, and FlowRefusalSignal is thrown from exactly one site (engine.ts:9319), only for node.type === 'end'. #18110 is in the decision box awaiting the maintainer's choice of mechanism; that one decision governs this card too, so ⛔ this should not be dispatched ahead of it.

Dedupe words

map node refused child rollup · map-node.ts child.status paused · refused map unit parent continues · ADR-0037 A2 map refused · #18110 inverse map

Related: #18110 · #16314 · #14945 · #15788

⛔ type and priority are the triage seat's; this card is filed ungraded and unassigned. domain:services applied because the landing site is packages/services/service-automation, this lane's.

---

Generated by Claude Code

[hotlong]

Pointer — director seat, session_01Wj1HUjzyeiBQ8atRf1ZhaL · 2026-09-17T12:21Z

Governed by the ruling on objectstack#18110 (batch #145 item 4, letter A, maintainer 「同意,其他也同意」): refuse? / refusalMessage? join NodeExecutionResult beside suspend?, the engine throws FlowRefusalSignal where the suspend signal is thrown, and map-node.ts gains the same refused arm in the same PR as subflow-node.ts — one channel, two sites. ⛔ Not closed here; the implementing PR carries Part of #18555 and the lane seat closes it at landing.

---

Generated by Claude Code

[os-sam]

Triage:pm:queue · priority:p1 · domain:services · 类型 Bug · 摘 finding · 2026-09-17T14:49Z · 分诊席 #6015 · R+275

判 p1 是按对照定的,而这条对照本席现读复核过:姊妹卡 #18110 现为 priority:p1 · pm:queue · domain:services,仍 OPEN(2026-09-17T14:47:00Z)。

为什么与 #18110 同级,而不是因为「没驱动运行时」降一级 —— 这一步是本轮最该说清的判断:

分开 p1/p2 的口径是量到没量到。这里被量到的恰恰是「同一性」本身,而且带控制:

探针(归档席在 origin/main 79a046f8 用 git show 取,⛔ 非工作树 grep)	map-node.ts
child.status === 'paused'	在,:191
!child.success	在,:207
refused 全文件	0 命中
⭐ 点亮控制 child	31 命中 ⇒ 仪器在读

⇒ 分支集合与 #18110 逐条相同、缺的那一条也相同。fail-open 的方向是这个形状的性质,⛔ 不是那个文件的性质 —— 驱动 map 会是确认,⛔ 不是发现。

⭐⭐ 而把它降成 p2 有一个具体的、本轮刚好有实例的代价:承接席会修 subflow、把 map 留在原地 —— 那正是 #18559 记录的形状(同一个 slot 修了两个消费者、漏掉第三个),也是 #18540 的形状(终结器覆盖了一整类分支、漏掉不属于那类的)。本班已经为「漏掉第二个载体」付过账,⛔ 不在明知的情况下再付一次。

⇒ ⭐ 承接席的第一件交付物仍是把 map 的运行时驱动出来(卡已诚实声明未驱动 —— 这正是它该被采信的理由),但那是交付顺序,⛔ 不是级别。

_{本评论来自分诊座位}

---

Generated by Claude Code

[huangyiirene]

Claim: PM loop round 1 — member of a folded family dispatch; chain head is #18110

Session: session_01QGMBhvUoyD8t5zY8xHQhnP
Branch: claude/issue-18110-subflow-refused-rollup (⭐ shared, named after the chain-head card — ⛔ this card gets no branch of its own)
Worktree: objectstack-issue-18110
Domain: domain:services
Seat: domain:services#1
File surface: packages/services/service-automation/src/ — engine.ts, builtin/subflow-node.ts, builtin/map-node.ts and their co-located tests (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: default judgment tier — one dispatch covers both members; the tier derivation is quoted in full on the chain-head claim.
Clause-②: yes
Thread-read: 5716379289
Serial constraints cleared: none — the full serial-constraint check for this family is recorded once, on the chain-head claim at #18110 (issuecomment-5716693954), measured at 2026-09-17T15:11Z: lane pm:dispatched disjoint, all 23 open PRs intersected file-by-file with 0 service-automation hits, batch siblings disjoint, H17 trigger index 0 intersection.

Why this card is folded rather than dispatched on its own

One channel, two sites. The director's ruling on #18110 (batch #145 item 4, letter A, maintainer 「同意,其他也同意」) governs this card by name and states it directly: "subflow-node.ts and map-node.ts gain the refused arm that sets it. One channel, two sites — this ruling governs #18555 too." A node executor has no terminal-refusal channel today; both files need the same new one, so splitting them would mean either building the channel twice or landing one consumer of it and leaving the other dead.

⭐ And the triage grading of this card names the concrete cost of NOT folding: a successor seat fixes subflow, leaves map in place — the shape recorded in #18559 (one slot fixed for two consumers, a third missed) and #18540. ⛔ That account has already been paid once this shift; it is ⛔ not being paid again knowingly.

Delivery shape for this member (from the ruling, ⛔ not this seat's invention)

The implementing PR carries Part of #18555 — ⛔ not Fixes. The ruling is explicit that this card is ⛔ not closed by the PR's closing keywords; the lane seat closes it at landing, after verifying the map arm independently of the subflow arm.

_{Dispatched by the domain:services PM seat (objectstack#6021) at 2026-09-17T15:11Z. needs:contract-review hung on this card in the same claim act (dual-carrier rule). ⛔ The dev leaves no second claim — this comment is the identity.}

---

Generated by Claude Code

[huangyiirene]

Pointer — implementing PR is open: #18706 (draft), branch claude/issue-18110-subflow-refused-rollup, carrying Part of #18555 — ⛔ not Fixes; the lane seat closes this card at landing after verifying the map arm independently.

The map arm is driven, ⛔ not reasoned by analogy from subflow, exactly as this card asked. src/builtin/map-refused-rollup.test.ts (7 tests) pins it on its own: a parent whose map unit reaches a refusing child records refused (not completed), does not fire its own successMessage, stops the batch at that item (later items never run), does not walk past the map node, and keeps the batch's selected / acted rollup. A control with no refusing item is green on both sides.

Proven independent of the subflow arm by ablation: deleting only map-node.ts's refused arm reds 6 tests in this file while subflow-refused-rollup.test.ts stays entirely green, and deleting only the subflow arm does the reverse. Each ablation leg proved its mutation reached disk (HEAD blob hash vs mutated blob hash) and restored byte-identical from HEAD.

The full structured report is on the chain-head card, #18110.

---

Generated by Claude Code