[finding] service-automation: a `subflow` child that ends `refused` is rolled up by the parent as an ordinary success — the refusal reaches nobody

[claude]

Reported by the domain:services dev that delivered #15788 (lane 2 of the #14945 ruling 2′) 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/subflow-node.ts branches only on child.status === 'paused'. Every other child status falls through the same success path, so a child run recorded refused returns success: true and the parent walks straight down the subflow node's out-edges.

⇒ An author who writes a refusing end inside a subflow gets the opposite of what the refusal means at the parent level: the parent continues as though the child said yes.

Why it is filed now, and why it is ⛔ NOT a regression of #15788

Before #15788's delivery nothing could write refused at all, so the parent's behaviour was identical (a refusing child merely completed, and the parent continued). ⛔ PR #18109 does not change subflow-node.ts and does not make any existing flow behave differently.

What changed is reachability: the end executor now produces refused, so this path becomes live the moment authors start writing refusals — which is exactly what lane 2 was ruled in to enable. ⚠️ The #14945 ruling says nothing about subflow rollup, so this is ⛔ not a shortfall in that ruling and ⛔ not something #18109 should have ridden in.

Relationship to the sibling card

⚠️ #16314 is the INVERSE direction and is a different card: it is about subflow and map rolling a child's contained failures into the parent's failed through the ExecutionStepMetrics failure slot. This card is about a refused child rolling up as success — the refusal reaching nobody. Same file, opposite failure mode. ⛔ Do not close either as a duplicate of the other.

Not prescribed here

The fix direction is a real fork and belongs to whoever takes this, not to the filer: does a refusing child terminate the parent run as refused, surface as a distinguishable branch the author can route on, or stay a success with the refusal recorded? A refusal is a successful evaluation that says no, ⛔ not a failure, so folding it into the failed rollup #16314 describes would be the wrong answer in a way that is easy to reach for.

Dedupe words

subflow child refused rollup · subflow-node.ts child.status paused · refused subflow parent continues · end node outcome refused subflow · #14945 lane 2 subflow

Related: #16314 · #14945 · #15788 · PR #18109

⛔ domain:*, type and priority are the triage seat's; this card is filed ungraded.

---

os-decision-facets

① 项目长远合理性:A(NodeExecutionResult 增 refuse? / refusalMessage?)缩小特例 —— 它把拒绝并入 suspend 已在用的同一条 unwinding 协议,而 FlowRefusalSignal 的 docblock 逐字要求「reuses the mechanism rather than inventing a second unwinding protocol」;B(不导出的内部暗缝)是特例增生,且按 dev 实测,为保住 #4354 的 metrics 上卷它会把同样大的面长回信号内部。
② 实际业务拉动:仓内 两个一方调用点 —— subflow-node.ts(本卡)与 map-node.ts(本席复验同形洞,已立 #18555),两者需要同一条通道;第三方执行器拉动 0,⛔ 未测得。
③ 防 AI 犯错:A 强 —— 公开成员有声明、可评审、紧挨既有 suspend,一条规则覆盖两个站点;B 弱 —— 面藏在 barrel 之外评审看不见,且两个站点要写成两个特例。
④ 创业阶段不扩散:唯一指向 B 的一棱 —— A 在已发布包 @objectstack/service-automation 上加公开成员,把终止-拒绝能力一并发给零实测拉动的第三方执行器。

Prior rulings read: subflow,refused,service-automation,child,ends,rolled,parent,ordinary,success,refusal,reaches,nobody → 35 hits; ADR-0119 D4, ADR-0119 D1, ADR-0006 D3, ADR-0019 D2, ADR-0029 D9.9, ADR-0039 D7, ADR-0044 D3, ADR-0056 D6, ADR-0068 D2 — ⭐ 本席逐个读了与本题最近的两个,⛔ 不是只抄工具输出:ADR-0119 是事务 / 原子批,关键词假阳性;ADR-0019 D2(approval-as-flow-node) 裁的是「approval 是插件贡献的节点而非引擎核心」,其 refusal 条款只管 resume 的授权答复,⛔ 未裁「refused 子运行该不该传播到父运行」。⇒ 无既有裁决答本题,本卡是决策而非执行。

推荐:A,并把本卡实施 PR 的 Clause-② 更正为 yes、走契约复审档复核。自检「只看①选 A;②③④ 是否翻转:③ 同向 A,② 同向 A(两个一方站点要同一条通道),仅 ④ 反向 ⇒ 不翻转,落在 A」。

置信缺口:第三方节点执行器是否真需要这条通道未测(实测拉动 0)。若维护者判定已发布公开面不可动,B 是可执行退路,但须接受 dev 实测的代价:为不丢 #4354 的 metrics 上卷,同样大的面会回流进内部信号,且评审看不见。

---

Generated by Claude Code

[os-sam]

Triage: first grading — (a) ⇒ pm:queue · domain:services(保留)· p1 · Bug

Triage seat (objectstack#6015), session_01U6nJJSVZb476ckbRxmaMCA, R+257, 2026-09-16T22:02Z. ⛔ This seat does not claim, dispatch or write code.

前提复验 —— live,本席自取

读数(origin/main)	结果
唯一的 status 分支	subflow-node.ts:111 — if (child.status === 'paused')
是否有 refused 分支	无 —— 文件里 refused 只出现 2 次,都在注释(:58、:173)
⭐ 其中 :173	「…about which child outcomes reach it. (A refused child — the run…」⇒ 文件自己的注释在谈这个情形,而代码没有分支
控制	同文件 subflow 16 命中 ⇒ 仪器在读

⇒ 其余每个 child status 都落进同一条成功路径。

⭐ priority:p1 —— 本席把理由写全,因为这是本班第一次给 p1

判据不是「影响面大」,是方向:

1. 它把作者的显式拒绝反转成继续。 作者在 subflow 里写了一个 refusing end,父流程照常沿出边走下去 —— 拿到的是其意图的反面,⛔ 不是降级、不是报错。
2. ⭐ 它是 fail-open。 一个 refusal 节点最常见的用途就是闸门(审批、资格、前置条件)。fail-closed 的错误会被人发现;fail-open 的错误不会 —— 流程一路绿着跑完。
3. 它是新可达的。 卡面自陈:service-automation: honour outcome: 'refused' on the flow end node — a terminal refused run status (distinct from failed) with the interpolated message persisted on the run (lane 2 of the #14945 ruling 2′) #15788 交付前 refused 根本写不出来,所以这不是 service-automation: honour outcome: 'refused' on the flow end node — a terminal refused run status (distinct from failed) with the interpolated message persisted on the run (lane 2 of the #14945 ruling 2′) #15788 的回归 —— 是那条能力落地后第一次真正可达。⇒ 它今天就在等第一个写 refusing end 的作者。

⛔ 不是 p0:无在飞事故、无 main 红。
⚠️ ⛔ 也不进决策箱:修它是让拒绝如其所声明地传播 —— 拉回已声明语义,⛔ 不是改变安全/权限边界 ⇒ 车道的活,⛔ 不是人工地板。

type: Bug · finding 摘除。

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

---

Generated by Claude Code

[os-project-manager]

Claim: PM loop round 1
Session: session_01WmBwEiWPff9JZPd5BSGNeH
Branch: claude/issue-18110-subflow-refused-rollup
Worktree: objectstack-issue-18110
Domain: domain:services
Seat: domain:services#1
File surface: packages/services/service-automation/src/builtin/subflow-node.ts + its co-located .test.ts (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: default judgment tier (opus) — cited from THIS dispatch's node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --tier packages/services/service-automation/src/builtin/subflow-node.ts packages/services/service-automation/src/builtin/subflow-node.test.ts at commit 582d3e54: "no path-derived mandate: the surface hits none of the 3 declared glob(s) … floor sonnet · default opus · ceiling fable". Default tier chosen because the card carries a live fix-direction fork, ⛔ not a mechanical repair.
Clause-②: no
Thread-read: 5705214307
Serial constraints cleared: none — measured at 2026-09-17T00:40Z, ⛔ not recalled. (a) This lane's only pm:dispatched card is #16506, assignee zhuangjianguo, file surface plugin-email/src/email-service.queue-delivery.test.ts ⇒ disjoint, and ⛔ not this seat's card. (b) All 19 open PRs intersected file-by-file against this surface: the only service-automation hit is PR #18503 on src/builtin/screen-nodes.ts — a DIFFERENT file, ⛔ package-level adjacency is not a serial constraint. (c) The seat post's cross-seat fence PR #17454 re-measured: closed, and its 45 files carry 0 service-automation (control pnpm-lock.yaml present ⇒ instrument live). (d) Sibling cards dispatched in this same batch — #18091 (plugin-security seeders) and #18424 (service-messaging channels) — are file-disjoint from this one. (e) ⛔ No sibling card pins behaviour this card asserts.

Premise re-verification owed before any edit

⚠️ The card was filed 2026-09-14 and its action surface has MOVED since: b7225477 (#16314 via PR #18261) landed on this exact file. ⇒ Every line number in the card and in triage's grading is a reading of an older tree and must be re-taken on current origin/main.

_{Dispatched by the domain:services PM seat (objectstack#6021) at 2026-09-17T00:40Z. The ruling, its named falsifiable premises and the fork injunction are in the dispatch order.}

---

Generated by Claude Code

[os-project-manager]

os-dev-report

{
  "issue": 18110,
  "status": "needs_decision",
  "branch": "claude/issue-18110-subflow-refused-rollup",
  "pr": null,
  "session": "session_01WmBwEiWPff9JZPd5BSGNeH",
  "premise_still_valid": true,
  "zone2_premises": {
    "P1": "CONFIRMED, re-taken on origin/main 79a046f8 via `git show origin/main:PATH` (not a worktree grep). Only status branch is `if (child.status === 'paused')` at :111 (line number unchanged after b7225477). `refused` appears exactly 2x, BOTH in comments, at :58 and :173. Control `subflow` = 16 hits. File is 193 lines.",
    "P2": "CONFIRMED. `TERMINAL_RUN_STATUSES` (engine.ts:1365) = ['completed','failed','cancelled','timed_out','refused'] — `refused` already published. A top-level refused run is built by ONE method, `finishRefusedRun` (engine.ts:8503-8566), three producers (execute/resumeInternal/executeWithoutRetry). Its envelope: `{ success: true, status: 'refused', refusalMessage, output, durationMs, summary }` — no `error`, no `errorMessage`, no `successMessage`, no `runId`.",
    "P3": "FALSIFIED — see open_questions[0]. The parent's TERMINAL STATE is indeed existing and adds nothing. But the MECHANISM to reach it does not exist: a node executor has NO channel to terminate its run as refused. `NodeExecutionResult` (engine.ts:332-417) declares success/output/error/code/errorClass/warnings/branchLabel/suspend/correlation/screen/childSteps/metrics — and nothing else. `FlowRefusalSignal` is thrown from exactly ONE site, engine.ts:9319, for `node.type === 'end'`, and is deliberately not exported ('Not exported — callers see status: refused', engine.ts:1116). So R1 cannot be reached without giving the engine a new executor-facing refusal channel, and `NodeExecutionResult` IS a published type (barrel-exported from src/index.ts; @objectstack/service-automation v17.4.0, publishConfig.access public, files: [dist]).",
    "P4": "CONFIRMED, no contradiction with R1, so NO fork on this axis. The :173 comment read in full says the slot 'decides nothing new about which child outcomes reach it. (A `refused` child — the run OUTCOME sense, an `end` node saying no — reaches this exit today and has since refusals existed; whether a parent should go on from one at all is a separate open question about this node, not this slot's.)' It NAMES the gap and explicitly leaves the direction open. It proposes no design, so it neither supports nor contradicts R1."
  },
  "summary": "R4 fired; nothing was implemented. The card's defect is REAL and was reproduced live, not only read: a parent whose subflow child ends `refused` records `status: 'completed'`, fires the parent's own `successMessage`, and walks its out-edges (the downstream node ran). Two independent R4 triggers then stopped the work. (1) P3 is falsified: the ruled direction is unreachable without adding a terminal-refusal channel to the node-executor contract, and the two available mechanisms differ in published-surface footprint — `dispatch-gates --tier` prints that widening the public surface owes a contract-review-tier review, which is exactly what the dispatch's `Clause-②: no` rests on. (2) The dispatch's declared file surface (subflow-node.ts + its co-located .test.ts, 'stop on breach') cannot hold the fix: engine.ts must change under every mechanism examined. A third input the ruling did not have: under either mechanism the fix reaches into #18112's undecided region territory, because the existing region boundary would now catch a refusal it was written to describe as an `end` node.",
  "repro": "Measured 2026-09-17 on worktree at 79a046f8 with a scratch vitest probe (deleted before any push; tree verified clean, `git status --porcelain` empty). Child flow: start, then end{outcome:'refused',message:'Refused: {record.name} is a confirmed duplicate'}; parent flow: start, then subflow(child), then recorder, then end; parent successMessage 'Parent completed!'. CHILD ALONE: {\"success\":true,\"status\":\"refused\",\"refusalMessage\":\"Refused: Acme Corp is a confirmed duplicate\"}. PARENT: {\"success\":true,\"successMessage\":\"Parent completed!\",\"output\":{}} — status and refusalMessage both absent. DOWNSTREAM NODES THAT RAN AFTER THE SUBFLOW: [\"ran\"]. PARENT RUN RECORD: [{\"status\":\"completed\"}]. So the parent does not merely continue — it reports a completion and toasts its own success message over the child's refusal.",
  "tests": "No implementation, so no pins and no ablation. Runs made: (1) dependency-closure build `pnpm --workspace-concurrency=2 --filter '@objectstack/service-automation^...' build` under `scripts/pm/os-verify-lock.sh` (OS_VERIFY_LOCK_SLOT=issue-18110) — printed `os-verify-lock: VERDICT command-exit 0 · held the lock 298s · waited 403s`; (2) the scratch probe above, `pnpm --filter @objectstack/service-automation exec vitest run --maxWorkers=2 src/builtin/__probe-refused-rollup.test.ts`, exit captured to disk before reading: exit=0, 'Test Files 1 passed (1)'. Probe deleted. NOT MEASURED: every gate family, because R4 stopped the work before a diff existed.",
  "gates": "none run — no diff exists. `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands` was therefore not run against a changed set; only `--tier` was consulted, on the hypothetical honest file set, and it printed 'no path-derived mandate: the surface hits none of the 3 declared glob(s)' plus 'Clause ② is NOT reachable from paths: a card that changes contract accept/reject behaviour or widens the public surface owes a contract-review-tier REVIEW too (spec seat; default-tier build), judged from the card CONTENT.'",
  "line_budget": "n/a — 0 files changed, 0 lines. No skills/** path touched.",
  "files_changed": [],
  "deviations": [
    "Branch `claude/issue-18110-subflow-refused-rollup` was pushed EMPTY (at 79a046f8) as the standing write-route probe before any edit, per the lane's worktree rule. It carries no commits and no PR. It is visible to `git ls-remote --heads origin | grep issue-18110`; say the word and the next dispatch reuses it, or it can be deleted.",
    "The declared file surface could not be honoured. Reported rather than breached: no file was edited at all."
  ],
  "open_questions": [
    {
      "question": "Which mechanism gives a node executor a terminal-refusal channel? R1's direction is reachable, but only through engine.ts, and the two shapes differ in exactly the axis Zone 1 used to refuse the out-edge option (public-surface widening). This is the P3 falsification.",
      "options": [
        "A — widen the published executor contract. Add `refuse?: boolean` (+ `refusalMessage?: string`) to `NodeExecutionResult` (engine.ts:332), and in `executeNode` throw `new FlowRefusalSignal(node.id, result.refusalMessage)` in the position `suspend` already throws from (engine.ts:9611) — i.e. AFTER the success step is pushed, after the `childSteps` fold and after output write-back. COST: `NodeExecutionResult` is barrel-exported from a published package, so this hands EVERY node executor, third-party ones included, a new capability to terminate its run as refused. That is a public-surface widening, and by the dispatch-gates text quoted under `gates` it owes a contract-review-tier review — it breaks the dispatch's `Clause-②: no`. BENEFIT: it reuses 100% of the existing bookkeeping, so the child's `selected`/`acted`/`unmeasuredEffect` rollup (#4354) is preserved on the refusal path for free, and the subflow step is logged honestly as a success (the node DID evaluate; the child said no). Diff is roughly 2 documented members + a 3-line branch in engine.ts, plus a ~12-line arm in subflow-node.ts.",
        "B — internal seam, nothing published. Export `FlowRefusalSignal` and `isRefusalSignal` at MODULE level from engine.ts only (deliberately NOT added to src/index.ts, whose barrel is the package's single entry point), have subflow-node.ts throw the sentinel, and make `executeNode`'s catch test `isRefusalSignal(execErr)` FIRST and rethrow untouched. COST: the catch is the wrong place for success bookkeeping, so the subflow node gets no step-log entry and the child's metrics rollup is LOST on the refusal path unless the sentinel grows a metrics field — which re-introduces most of A's surface, inside the signal instead. It also special-cases subflow rather than stating a rule. BENEFIT: zero published-surface change; `Clause-②: no` survives intact; capability expansion stays tight, which is the startup-stage axis R1 itself invoked.",
        "C — do not take either yet; re-dispatch with a widened file surface and an explicit mechanism ruling."
      ],
      "recommendation": "A, with `Clause-②` corrected to `yes` and the contract-review tier accepted. Two reasons. First, B's saving is nominal: the moment the sentinel has to carry `metrics` to avoid regressing #4354's rollup on a refusal (a refusing child really can have written rows before its `end` — `finishRefusedRun` itself collects the child's outputs and summary for exactly that reason), B has the same surface as A, only unreviewable because it is hidden from the barrel. Second, A is the shape the engine already documents for itself: the `FlowRefusalSignal` docblock (engine.ts:1112-1116) says it reuses `FlowSuspendSignal`'s unwinding protocol 'rather than inventing a second unwinding protocol', and `suspend` is the executor-facing half of that same protocol. `refuse` beside `suspend` is that sentence finished, not a new idea. ⛔ But the tier call is the seat's, not this dev's — hence needs_decision rather than a PR.",
      "not_a_fork": "R4 (a)-(d) do NOT fire: no new run status value (P2), no new out-edge semantic (nothing authorable, no edge label, no routing), no region rethrow machinery (see open_questions[1] — the EXISTING boundary catches it), and zero packages/spec. R5 is intact: no spec change is needed under any option."
    },
    {
      "question": "Under either mechanism the fix lands inside #18112's undecided region territory. Is that acceptable, or must the fix be fenced to top-level subflow nodes?",
      "options": [
        "Accept and correct the diagnostic. A `subflow` node inside a `loop` / `try_catch` / `parallel` body whose child refuses would, after the fix, unwind into the EXISTING region boundary at engine.ts:9956 — the shipped Option A that R3 names as the interim. No new machinery is needed and nothing is taught to rethrow. But that boundary's message is hard-wired to the only producer it has ever had: \"an 'end' node declaring outcome: 'refused' inside a structured region (node 'ID') is not supported ... Put the refusing 'end' on the top-level graph\". On this path the named node is the SUBFLOW node and there is no `end` node in the region at all, so the sentence would be factually wrong and its prescription unfollowable. Correcting it is a small edit to region-boundary TEXT (not semantics) — but it is region territory, which R3 puts out of scope.",
        "Fence the fix to top-level subflow nodes, leaving a subflow-in-a-region refusal as today's silent success until #18112 is answered. Keeps R3 airtight; leaves half the fail-open hole open, and leaves two behaviours for one shape.",
        "Widen this card to cover the region message, explicitly as a text-only carve-out from R3."
      ],
      "recommendation": "Option 1, carved out in writing: the region boundary's SEMANTICS stay untouched (loud refusal at the boundary, #18112's Option B not implemented, no rethrow taught to any container) and only the diagnostic sentence is generalised to name whichever node carried the refusal. Leaving it as-is ships a message that names a node type the author will not find in their region. ⛔ Flagged rather than done, because R3 is a ruling and this touches the file it fences. Read from source, not measured live — no implementation exists to run it against."
    }
  ],
  "mcp_calls": "0 — no MCP GitHub tool was called, read or write.",
  "api_writes": "1 at the time of writing — POST /repos/objectstack-ai/objectstack/issues/18110/comments (this report). No POST /pulls (no PR), no PATCH, no label write, no assignee write. Budget was 3.",
  "out_of_scope_findings": [
    "to file (3 classes: (a) reproducible defect · 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`): `packages/services/service-automation/src/builtin/map-node.ts` has the IDENTICAL shape as the card's file — `if (child.status === 'paused')` at :191 and `if (!child.success)` at :207, and no `refused` arm — so a refusing child inside a `map` unit is rolled up as an ordinary success too, its output pushed into `state.results` at :232. #16314 treated `subflow` and `map` as one surface for the FAILURE direction; this card names only `subflow`, so map is left untouched here. Same fail-open direction, second file. Not measured live — read from source at 79a046f8. Successor: whichever PR answers the mechanism question above, since both files need the same channel.",
    "noted, not filed: `subflow-child-refusal.test.ts` in the same directory is about a DIFFERENT sense of refusal — the retryable resume-bag codes INVALID_SCREEN_INPUT / INVALID_SIGNAL on the delegation path (#14379), not the `refused` run outcome. It is a naming hazard for whoever writes this card's pins, not a defect. Successor: the next author of a test in this directory — the two senses are already called out at engine.ts:1103-1110, so no new record is needed."
  ]
}

---

Generated by Claude Code

[os-project-manager]

席位复核 + 落入决策箱 —— dev 的 needs_decision 成立,方向裁决撞上人工地板

_{domain:services 席位(objectstack#6021),session_01WmBwEiWPff9JZPd5BSGNeH,R1,写于 2026-09-17T01:13Z。dev 终报 5706865798。⛔ 以下每条读数由本席在 origin/main 79a046f8 上独立复取,⛔ 不采信终报自述。}

Release: session session_01WmBwEiWPff9JZPd5BSGNeH · 因 前提证伪(P3) · 去向 needs-user-decision(决策箱) · assignee 同笔清空。

✅ 缺陷是真的,而且是跑出来的,不是读出来的

dev 用一次性探针实测(探针已删,git status --porcelain 空):子流程单跑 {"status":"refused","refusalMessage":"…"};父流程 {"success":true,"successMessage":"Parent completed!"},status 与 refusalMessage 双双消失,下游节点照跑,父 run 记录 completed。⇒ 父流程不只是「继续」,它盖着子流程的拒绝报了一句自己的成功。分诊判 p1 fail-open 判对了。

🔴 本席派发时下的方向裁决(R1「传播」)到不了 —— P3 被证伪,本席复验证实

读数(本席自取,git show origin/main:PATH)	结果
TERMINAL_RUN_STATUSES(engine.ts:1365)	['completed','failed','cancelled','timed_out','refused'] ⇒ refused 已是已发布终态(P2 成立,R1 不需要新状态值)
new FlowRefusalSignal 抛出点	恰 1 处,engine.ts:9319,只给 node.type === 'end'
NodeExecutionResult 成员	success/output/error/code/errorClass/warnings/branchLabel/**suspend**/correlation/screen/childSteps/metrics —— 无任何拒绝通道
它是不是公开面	🔴 是 —— src/index.ts:9 逐字 barrel 导出 NodeExecutionResult
map-node.ts 对照	child.status === 'paused' :191、!child.success :207、refused 命中 0(控制:child 31 命中 ⇒ 仪器在读)

⇒ 节点执行器今天没有任何办法把自己的 run 终止为 refused。 要做 R1,只能动 engine.ts,而两条路差别恰好落在本席用来否掉「可路由出边」那条选项的同一根轴上:公开面扩张。⇒ 本席的 Clause-②: no 预测在 A 路下不成立。

📐 四棱

① 实际业务需求(实测) —— 拒绝能力是 #15788 / PR #18109 专门交付出来的,这条路今天就可达。两条路都能修好缺陷,分不出高下;真正的分歧是还有谁拿到这个能力。A 把拒绝通道交给每一个节点执行器,含第三方。实测拉动:仓内两个一方调用点(subflow-node.ts 与本轮新发现的 map-node.ts),第三方拉动 0,⛔ 未测得。

② 项目长远合理性 —— 倾向 A,而且依据是文件自己写的。NodeExecutionResult 上已经有 suspend?: boolean:一个已发布成员,作用就是让引擎内部抛一个不导出的 FlowSuspendSignal。FlowRefusalSignal 的 docblock 逐字说它「reuses the mechanism rather than inventing a second unwinding protocol」。⇒ refuse 摆在 suspend 旁边是把这句话写完,不是新发明。 B 则是给 subflow 开特例、不陈述规则;而 dev 实测 B 一旦要保住 #4354 的 metrics 上卷(拒绝的子流程真的可能已经写过行),sentinel 就得长出 metrics 字段 —— 那时 B 的面和 A 一样大,只是藏在 barrel 外面、评审看不见。

③ 防 AI 写错 —— 倾向 A。A 是一个有声明、可评审、紧挨既有成员的公开成员;B 是一条不导出的暗缝。且两个一方站点需要同一条通道:A 是一条规则,B 是两个特例。声明即强制这一条上,A 胜。

④ 创业阶段不扩散 —— 唯一指向 B 的一棱,而且是硬的:A 在已发布包 @objectstack/service-automation v17.4.0 上加公开成员,把能力发给零实测拉动的第三方执行器。创业阶段能力扩张默认从紧。

四棱不同向 ⇒ ⛔ 不满足代裁置信门,⛔ 本席不自裁。 且「协议/公开契约变化」本就在人工地板上。

Governing text: packages/services/service-automation/src/engine.ts 的 FlowRefusalSignal docblock(逐字:"this reuses the mechanism rather than inventing a second unwinding protocol. (Not exported — callers see status: 'refused'.)")+ 同文件 NodeExecutionResult.suspend?: boolean 的既有先例 + src/index.ts:9 的 barrel 导出事实。

🟢 本席已裁的一条(⛔ 不占你的决策)

dev 的第二个问题(region 内的 subflow 拒绝会撞上 engine.ts:9956 那句硬编码诊断,而那句话点名的是「end 节点」,在这条路上根本没有 end 节点 ⇒ 消息事实错误、处方无法执行)—— 本席裁:只改那句诊断的措辞,泛化成点名「实际携带拒绝的那个节点」;region 的语义一个字不动(#18112 的 Option B 仍不实现、不教任何容器 rethrow)。依据:纯文档措辞更正、无契约声明改动,属具名不升级类。⚠️ 它随最终选定的机制一起落地,⛔ 不单独开卡。本席派发令 R3 就此明文让出这一行文本。

---

维护者速读

改了什么 —— 还没改。dev 按令停手,零文件改动、零 PR;分支 claude/issue-18110-subflow-refused-rollup 是空的(0 提交,⛔ 探活不要读成在飞工作)。

为什么改 —— 作者在子流程里写「拒绝」(比如审批闸门说不通过),父流程当没看见,照常往下跑,还报了自己的成功。这是 fail-open:失败会被发现,这种「一路绿着跑完」的错不会。

风险与代价(含回滚) —— 两条路都只动引擎内部行为,都不改任何已发布的状态值,都不碰 packages/spec,一次 revert 可回。真正的代价差在公开面:A 在已发布包上加两个公开成员(等于第三方节点执行器从此也能终止 run);B 不动公开面,但按 dev 实测它八成会为了不丢统计数据把同样的面藏进内部信号里。

席位意见 —— 荐 A,理由是它不是新设计:这个包已经有一个一模一样的成员 suspend,干的就是同一件事(设个标志 → 引擎内部抛信号 → 终止 run),而文件自己的注释写着「复用这套机制,不要发明第二套」。选 A 后本席会把 Clause-② 更正为 yes 并走契约复审档复核。四棱里只有「创业阶段不扩散」指向 B,但 dev 实测 B 省下的面是名义上的。

⚠️ 顺带:同样的洞在 map-node.ts 上原样存在(本席已复验),另立卡,它等的是同一条通道 —— 所以你这一个决定管两张卡。

你要做的(一个动作) —— 回一个字母:A(加公开成员,面扩、可评审)/ B(藏内部,面不扩、评审看不见)/ C(都先别做)。

---

Generated by Claude Code