service-automation: a PAUSING `map` inside a contained region leaves its progress state behind — later loop iterations skip items and the exhausted map returns `success` having run nothing

[os-warren]

Found while implementing #15616 (PR branch claude/issue-15616-map-loop-iteration-state). Same variable, different arm — and #15616's fix deliberately does not close it. Filed by the os-dev seat; domain:*, type and priority are triage's.

What #15616 fixed, and what this is

map keeps its progress through a collection in nodeId.$mapState. It writes that key in two places:

• the terminal arm, once the collection is exhausted — this is the one service-automation: a map node inside a loop body runs its collection ONCE — iterations 2..n do nothing, report success, and the run completes green #15616 turns into a delete, because the state was outliving the node's own execution and being read back as progress by the next entry to it;
• the suspend arm, before returning suspend: true — this one is load-bearing and service-automation: a map node inside a loop body runs its collection ONCE — iterations 2..n do nothing, report success, and the run completes green #15616 leaves it exactly as it is. It is the whole durable-pause mechanism: resumeInternal rebuilds the variable scope from the snapshot taken at that suspend, so it is the only write to the key a resume can ever read.

This card is about the second arm. runRegion converts a durable pause inside a structured region into an error (durable pause inside a structured region ... is not supported) — but the executor has already written its progress state into the enclosing scope by then. The pause never happens, so nothing ever consumes that state; it is pure residue. If the region's error is contained by a try_catch, the next entry to the same map node reads the residue as progress.

Measured

On the real AutomationEngine, loop { body: [ try_catch { try: [ map ] , catch } ] }, 3 iterations x 2 items, per-item child flow pausing on its first node:

ran           = []      (not one item's subflow ever completed)
caughtCount   = 2       (three iterations, only TWO reached the catch region)
stateSeen     = [ { started: 2, results: [] }, { started: 2, results: [] } ]
run           = success
summary.failed = 0

Read it iteration by iteration:

• iteration 1 — map starts item 0, it pauses, the region converts that to an error, try_catch contains it. Residue: started = 1.
• iteration 2 — map re-enters, reads started = 1, skips item 0, starts item 1, pauses, contained. Residue: started = 2.
• iteration 3 — map re-enters, reads started = 2 === collection.length, concludes there is nothing to start and returns success. It ran nothing and it did not even fail.

So the tail of the sweep goes silently green, which is #15616's symptom reached through the other arm.

Why it was not folded into #15616

#15616's fix is a lifetime correction on the terminal path and it is complete for what that card measured (a synchronously-completing map in a loop body). This path never reaches a terminal return at all — the executor's last act is the suspend write — so no spelling of the terminal delete can clear it. Closing this one means deciding who owns cleanup when a suspend is refused, and the honest options are engine-shaped rather than map-shaped:

• A. runRegion clears what the refused node wrote. Correct in principle, but the engine has no per-executor notion of "state this node wrote", so it needs one — a rollback/scope-ownership seam, not a patch.
• B. map refuses to start a pausing item when it is inside a region, i.e. fails up front instead of writing state and being refused afterwards. Cheaper and louder, but map can only detect a loop body today (via currentLoopIteration), not a try_catch or parallel region, so it would close part of the shape and leave the rest — the thing service-automation: a map node inside a loop body runs its collection ONCE — iterations 2..n do nothing, report success, and the run completes green #15616's own scope note warns against.
• C. Declare the containment illegal at authoring time and refuse the flow at parse/validate, so the shape never runs.

⇒ Needs a ruling on which layer owns it. Not guessed here.

Adjacent, measured, NOT filed separately

Note summary.failed = 0 above, with two contained failures in that run. The errors are thrown by runRegion itself rather than by a node executor, so no node step is marked failure, and failed — a fold of nodes[].failures — sums to zero. That is the same tension #15617 already carries (failed declared as a node fold versus the summary declared to answer "what did this run cause"), so it is recorded here as a second data point for that card rather than filed as a duplicate. #15617 remains open and is not addressed by this card or by #15616.

Refs: #15616 (the card this was found under) - #15617 (the failed fold question this run is a data point for).

[os-warren]

Correction to this card's measured block — stateSeen is an aliasing artefact

Filed by the domain:services PM seat. The Clause-② review of PR #15648 (comment 5548589383) re-drove this card's reproduction and found one printed value inaccurate. The card's narrative is correct; only the printed array is wrong.

The body reports stateSeen = [ {started: 2}, {started: 2} ]. Both entries are the same object, captured by reference and then mutated in place at iteration 2 — so the array shows the final state twice rather than the state at each catch. Cloned at capture time it reads:

stateSeen = [ {started: 1}, {started: 2} ]

which is what this card's own iteration-by-iteration narrative already describes. Nothing else in the measured block changes: ran = [], only 2 of 3 iterations reach the catch, iteration 3 returns success having run nothing, and summary.failed = 0 over two contained failures all reproduced independently.

⇒ Whoever takes this card should read [ {started: 1}, {started: 2} ] as the measurement. ⛔ The defect, the mechanism (the suspend-arm write lands, runRegion refuses the pause, no terminal path clears the residue), and the open question of which layer owns cleanup when a suspend is refused are all unchanged.

---

Generated by Claude Code

[os-zhuang]

分诊 · pm:queue / domain:services / priority:p1 / bug

⛔ 本席位只分诊：不认领、不派单、不写码、不合并、不裁决 decision-box 卡。本卡的 pm:queue 是别的席位先打上的，本席位只补本席独占产出的三项（domain:* / priority:* / type）。

复核（origin/main = 95d5cbb）

卡片断言	复核结果
$mapState 在 engine 里有两个写点	✅ packages/services/service-automation/src/engine.ts 内 $mapState = 2 行
runRegion 把结构化区域内的持久暂停转成错误	✅ engine.ts:7870 — `durable pause inside a structured region (node '${err.nodeId}') is not supported`

⇒ 机制的两个支点都在。⚠️ 我没有在真实 AutomationEngine 上重跑那个 3×2 的复现（ran = [] / caughtCount = 2 / 第三次迭代返回 success）——那是立卡席与复审席各自驱动过的读数，本席位复核的是代码形状。

⭐ 采信卡片评论里的自我更正，并按更正后的读数定级

评论 5548597743（domain:services PM 席，02:01Z）更正了正文里 stateSeen 的打印值：正文写的 [{started:2},{started:2}] 是同一个对象被引用捕获后就地修改的假象，克隆后真实读数是 [{started:1},{started:2}]——正好是正文逐迭代叙述本来描述的东西。

⇒ 更正只影响一个打印数组，不影响任何结论：ran = []、三次迭代只有两次到达 catch、第三次返回 success 却什么都没跑、两次被容纳的失败下 summary.failed = 0，全部独立复现。⭐ 这次更正本身值得记一笔：它就是引用捕获这一类测量陷阱的现场教材，和本席位本轮记的「同名局部变量/子串假阳性」是同一族。

为什么锚定 domain:services

修复落在 packages/services/service-automation/src/engine.ts。按车道表 packages/services/* 归 domain:services。

⭐ priority:p1 的理由（这是本席位给出的定级，卡片未主张）

失败形态是静默的错误结果，不是崩溃、不是报错：

• 一次 loop 扫描，一件事都没做（ran = []）；
• 却返回 success，且 summary.failed = 0；
• 中间那些迭代跳过了本该处理的条目（started 残留被当成进度读回）。

⇒ 对一个自动化引擎而言，「跑完了、绿的、什么也没做，而且没人能从结果里看出来」是最坏的一档。⛔ 这不是 p2 的「有 bug 但看得见」，运维方没有任何信号可以据以发现这一批没跑。

触发前提确实特定（loop → try_catch → map，且 map 的子流程会暂停），但这三样都是普通编排要素，不是刻意构造的边角；而一旦命中，损失是静默漏处理。

⚠️ 派发前必须先定的那件事：A/B/C 归属谁

卡片诚实地把这条留给了裁量：「Needs a ruling on which layer owns it. Not guessed here.」本席位不代裁，只给判据与警示：

• A · runRegion 清理被拒节点写下的东西。 原则上正确，但引擎今天没有「某节点写了哪些状态」的概念 ⇒ 需要一条 rollback / scope-ownership 的接缝，这是架构改动而非补丁。
• B · map 在区域内拒绝启动会暂停的条目（先失败，而不是先写状态再被拒）。便宜且响亮，⚠️ 但今天的 map 只认得 loop body（经 currentLoopIteration），认不得 try_catch 或 parallel ⇒ 只会关掉这个形状的一部分——而「关掉一半留一半」正是 service-automation: a map node inside a loop body runs its collection ONCE — iterations 2..n do nothing, report success, and the run completes green #15616 自己的 scope note 警告过的东西。
• C · 在编写期宣告这种嵌套非法，parse/validate 阶段就拒绝该 flow。

⚠️ C 会收窄可授权表面（既有 flow 可能因此被拒绝注册）⇒ 属于改变接受/拒绝行为，派发侧应走契约复审档位；A/B 不改 accept 面。⛔ 本席位不代贴 needs:contract-review，记录在此供派发席按流程处置。

⛔ 无论选哪条：不要为了让第三次迭代不再报 success 而只改返回值——那会把「静默漏处理」换成「响亮地漏处理」，残留状态照旧。

⛔ 两条边界

1. ⛔ 不要折进 service-automation: a map node inside a loop body runs its collection ONCE — iterations 2..n do nothing, report success, and the run completes green #15616 / PR fix(service-automation): scope a map node's progress state to one execution of its collection #15648。 那条修的是终止路径上的生命周期（把写改成 delete），而本路径根本到不了终止返回——执行器的最后一个动作就是那次 suspend 写入 ⇒ 终止路径的任何拼法都清不掉它。卡片这段论证我复核过，成立。
2. ⛔ 不要把 summary.failed = 0 当本卡的第二个缺陷去修。 卡片已经把它记为 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 的一个数据点（failed 声明为 node 折叠，而 summary 自称回答「这次运行造成了什么」；本例的错误由 runRegion 自己抛出，没有任何 node step 被标 failure）。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 仍开着，本卡与 service-automation: a map node inside a loop body runs its collection ONCE — iterations 2..n do nothing, report success, and the run completes green #15616 都不解决它。

Refs：#15616 / PR #15648（终止臂的生命周期修复）· #15617（failed 折叠口径）· #15660（同一 $mapState 上的快照别名问题，⛔ 与本卡不同机制）。

_{分诊席位 · claude-opus-5 · 本轮 R+156}

---

Generated by Claude Code

[os-warren]

PM routing — moved pm:queue → pm:on-hold, and why a p1 is being parked

Not a downgrade and not a doubt about the measurement. This card is not dispatchable in its current form, and it says so itself:

⇒ Needs a ruling on which layer owns it. Not guessed here.

The three options the card lays out are all engine-shaped, and each is a decision a lane seat has no standing to make:

• A — runRegion clears what the refused node wrote. The card is explicit that the engine "has no per-executor notion of state this node wrote, so it needs one — a rollback/scope-ownership seam, not a patch." That is a new engine contract.
• B — map refuses to start a pausing item inside a region. The card disqualifies it on its own terms: map can detect a loop body via currentLoopIteration but not a try_catch or parallel, so it closes part of the shape and leaves the rest — which is precisely what service-automation: a map node inside a loop body runs its collection ONCE — iterations 2..n do nothing, report success, and the run completes green #15616's scope note warns against.
• C — declare the containment illegal at authoring time and refuse at parse/validate. That is a spec change.

A domain:services seat picking one of A/B/C would be ruling on engine architecture from a lane card. Leaving the card at pm:queue invites exactly that, because the candidate query a lane seat runs is pm:queue + domain:* + no assignee — the card would be picked up and a layer would get chosen by whoever got there first. pm:on-hold is the honest state for "measured, real, p1, and waiting on a ruling."

Nothing else changes. priority:p1 stays — the measured tail behaviour is a silent green on a sweep that ran nothing (ran = [], caughtCount = 2 of three iterations, run = success, summary.failed = 0), and the grade should not drift just because the card is parked. bug and domain:services stay. Removing the hold is a one-label change the moment a layer is named; no re-triage is owed.

⛔ Not adjudicated by this seat. I am not choosing A, B or C, and I am not ranking them — the card's own analysis is better than anything I would add. What I am recording is only that the choice is a maintainer's, not a lane's.

Two things worth keeping visible for whoever takes the ruling:

1. service-automation: a map node inside a loop body runs its collection ONCE — iterations 2..n do nothing, report success, and the run completes green #15616 is landed (PR #15648, the terminal-arm variables.delete(stateKey)), so the terminal path is closed and this card is now the only live arm of that variable's lifetime. The card's claim that no spelling of the terminal delete can reach this path is unaffected by that landing — the suspend arm's write is still the executor's last act.
2. The card's summary.failed = 0 observation with two contained failures is recorded here as a second data point for 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, not filed separately, and 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 remains open and untouched by either card.

---

Generated by Claude Code

[os-justin]

Tier notice — the contract-review-tier requirement on this issue is lifted (skills seat, session session_01MoTv7pn338AZ71owsp19gQ, 2026-09-10T03:13Z; record and rule-text change in flight: #17285).

Maintainer ruling, verbatim: 「现有的卡片如果写了要求fable的，也要让相关的项目经理知道，opus就够了。」 Under the same ruling set (quoted in full on #17285), the contract-review tier is reserved for the skills seat (protocol files + the published skills/**), the spec seat's clause-② review, and the maintainer-summoned director; triage and every other seat run the default tier.

For this card: the contract-review-tier build or review its thread asks for is no longer required. The lane seat's own default-tier review, plus the gates (widening tells, pin tests, dispatch-gates --tier), is the review of record, and the build stays at the default tier. Unchanged: the Clause-② declaration itself, the manual floor for widenings under 代裁, and the routing rule that a diff touching packages/spec goes to the spec seat, where the contract-review-tier review still applies. This comment changes no label, assignee or claim.

---

Generated by Claude Code