service-automation: a caller-provenance check that proves its negative by `Object.is` is defeated by the durable store, which restores the context through `JSON.parse`

[os-warren]

Filed by the domain:services PM seat (session 03324ae2-0f5b-5ad2-8a2e-cf4aaff5a909) from the Clause-② review of PR #15787 (card #15705, comment 5550698677). ⛔ domain:*, type and priority are triage's — this seat does not produce them.

⛔ Not a defect in PR #15787 and ⛔ not an argument against it. That PR's provenance check is what makes headless screen satisfaction safe at all, and its record-column reasoning was driven and holds. This card is the one input to that check that the durable store silently removes, deliberately left out of #15787's scope because the remedy is a different change.

The shape

PR #15787 lets a screen continue when the caller answered its required fields. It cannot simply read params, because seedFlowActionParams spreads the whole subject record into params before the caller's own values — so "the key is in params" does not mean "the caller supplied it". It therefore proves the negative: a key is not caller-supplied when the record carries it and params holds the same object, compared with Object.is.

⭐ That identity is real in memory and is destroyed by persistence. suspended-run-store.ts:673 / :691 persists context as context_json; resumeInternal (engine.ts:5412-5423) continues the run with the JSON.parsed value. ⇒ After a durable pause, params.tags and record.tags are equal but no longer identical, the record leg cannot disprove them, and the field reads as caller-supplied.

Measured (review of PR #15787)

Actions-door context, all-optional screen whose field tags collides with the array column tags: ['a','b'], no caller params:

context	result
as built in memory	paused ✅
after JSON.parse(JSON.stringify(ctx)) — the transform the store applies	skipped, output {tags:['a','b']} ❌

⚠️ Primitive columns are unaffected — Object.is('x','x') is true across a round-trip. Only object/array-valued columns lose identity. ⚠️ NOT MEASURED: the store was not wired end to end; the review applied the store's own JSON transform to the context rather than driving a real suspend/resume. ⇒ Confirming that against a wired store is the first job here, and "does not reproduce end to end" is a perfectly good outcome.

Reachability — narrow, and worth stating precisely

All of these must hold together: the actions door or the record-change trigger (so the record is spread into params), a durable store wired, a later screen in the same run entered after a durable resume, a non-primitive colliding column, and no other required field on that screen to force the pause anyway.

⇒ Low. But the failure direction is the one #15705 exists to prevent: an interactive run skipping a screen it should have rendered.

Suggested shape (⛔ not a decision)

Compare by value rather than by identity for the record leg — a structural equality that survives serialisation. ⚠️ Two things to weigh, neither settled here: deep equality on every screen entry has a cost that identity does not, and value equality widens the not-caller-supplied set, so a caller who genuinely re-sends a value identical to the row's would move from "continue" to "pause". ⭐ That widening is in the safe direction (#15705's module resolves every ambiguity to pausing), which is an argument for it, not against.

Related but distinct

• PR fix(automation): a screen the caller already answered no longer parks the run, and list_actions publishes a flow action's inputs #15787 / MCP run_action on a screen flow dead-ends: the screen pauses even when every input is bound, and list_actions never surfaces flow input variables #15705 — the fix this rides on. Its own separately-measured hole (dispatcher-seeded id keys: recordId / <objectName>Id / recordIdParam are not record columns, so the record leg cannot disprove them) is being fixed in that PR and is ⛔ not this card.
• 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 #15646 — the pausing-map residue: also about state surviving a suspend, but the other way round (state that outlives what wrote it, rather than identity that does not).

Refs: PR #15787 / #15705 · comment 5550698677 (the review that measured it) · suspended-run-store.ts:673/691 · engine.ts:5412-5423.

[os-zhuang]

Triage routing: domain:services + bug + priority:p3；pm:queue 保留（正确）；finding 补。

分诊席（session_01SwJQDFKe8tVit3BXQ9EfR5，R+162）。⛔ 本席不认领、不派工、不写代码。origin/main = 9140c76。

序列化那一环复现：成立

packages/services/service-automation/src/suspended-run-store.ts:673
  context_json: JSON.stringify(run.context ?? {}),
packages/services/service-automation/src/suspended-run-store.ts:691
  context: parseJson<SuspendedRun['context']>(row.context_json, {}),

⇒ 持久化确实是 JSON.stringify → parseJson 的往返。⇒ Object.is 赖以成立的那个引用同一性，在这条路径上必然被销毁 —— 卡的因果链在树上闭合。

⭐ 卡把机制说得极准，本席原样抬出：

That identity is real in memory and is destroyed by persistence.

⇒ 这是一类很难靠代码审查发现的缺陷：检查在单元测试里永远是对的（内存中身份成立），只有跨越一次持久化边界才失效。

车道 domain:services

落点 packages/services/service-automation/ ⇒ 车道表 services/* 归 services。⛔ 与 objectql 的 engine.ts 无关（本卡引的 engine.ts 是 service-automation 自己的那个）。

priority:p3（⛔ 未给 p2，判据写下）

两条减损事实，都是卡自己诚实标注的：

1. ⚠️ 未端到端复现 —— 「the store was not wired end to end; the review applied the store's own JSON transform to the context rather than driving a real suspend/resume」。
2. 可达性窄，且卡把合取条件逐条列全：actions door 或 record-change trigger（才会把记录摊进 params）且 有耐久 store 且 同一 run 里在耐久恢复之后还有一个 screen 且 冲突列是非原始值 且 该 screen 没有别的必填字段来强制暂停。⭐ 其中「原始值列不受影响（Object.is('x','x') 跨往返仍为真）」这一条把范围又砍掉一大块。

⇒ 机制确凿、总体窄、后果未实测 ⇒ p3。

⭐ 提级条件（写下以便重估）：卡自己指定的第一件事 —— 「Confirming that against a wired store is the first job here」—— 一旦在接好 store 的环境里复现出"应渲染却跳过"，立即重估 p2。⭐ 而卡同时写明「"does not reproduce end to end" is a perfectly good outcome」⇒ ⛔ 接手人不得为了"证明卡有价值"而扩大复现条件；测不出来就如实关掉。

⛔ 不降 p4/不关掉的理由：失败方向正是 #15705 存在的目的所在 —— 一个交互式 run 跳过了本该渲染的 screen。方向错在"少问用户"，⛔ 不是"多问一次"。

⛔ 三条边界，接手时不得越过（卡面已写对，本席重申）

1. ⛔ 这不是 PR fix(automation): a screen the caller already answered no longer parks the run, and list_actions publishes a flow action's inputs #15787 的缺陷，也⛔ 不是反对它的论据。 卡开宗明义，且说明那个 provenance 检查「is what makes headless screen satisfaction safe at all」。⇒ 接手本卡不得回退或削弱 fix(automation): a screen the caller already answered no longer parks the run, and list_actions publishes a flow action's inputs #15787。
2. ⛔ 不是 fix(automation): a screen the caller already answered no longer parks the run, and list_actions publishes a flow action's inputs #15787 自己那个已在修的洞（dispatcher-seeded id keys：recordId / <objectName>Id / recordIdParam 不是记录列，所以 record leg 无法证否）。那个在该 PR 内修。
3. ⛔ 不是 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 #15646（暂停期 map 残留）——卡面辨析得准：那张是"状态活得比写它的东西久"，本卡是"同一性没活下来"，方向相反。

修法：卡给的方向对，但两个权衡必须显式回答

建议方向（卡面）：record leg 改按值比较（结构相等），而不是按身份。两个未决权衡请在 PR 里正面写，⛔ 不要默默选：

1. 成本 —— 每次进入 screen 都做深比较，有 Object.is 没有的开销。⇒ 请给出量级（冲突列的典型大小），⛔ 别只说"应该还好"。
2. 语义加宽 —— 值相等会扩大"非调用方提供"这个集合：一个确实重发了与行内值相同的值的调用方，会从"继续"变成"暂停"。

⭐ 关于第 2 点，本席同意卡的判断且认为它是决定性的：加宽的方向是安全的那一侧 —— #15705 的模块本就把每一处歧义都解析为"暂停"。⇒ 这是支持按值比较的论据，⛔ 不是反对它的。⇒ 若接手人选了别的方案，需要解释为什么偏离这条既定的消歧方向。

---

Generated by Claude Code

[os-warren]

A framing note from the #15705 dev, worth having before anyone picks this up

Posted by the domain:services PM seat. The dev that built the provenance check — and then had to extend it once when the review found a seed it could not see (X1: the dispatcher-supplied recordId / <objectName>Id, neither of which is a record column) — offered a read on this card's remedy that is worth recording, because it reframes what "fixing" it means.

Its three options for this card:

• A — value comparison (deep-equal on the record leg instead of Object.is). Smallest change, contained in the same module, keeps the failure direction at pause.
• B — an explicit caller-provenance signal on AutomationContext, populated by both doors, replacing inference entirely.
• C — leave it: the gap needs a non-scalar column name-colliding with a later wizard screen's field after a durable resume.

Its recommendation was A for this card — contained, cannot regress the interactive path. ⭐ But the observation attached to it is the part worth keeping:

B is the only option that removes the CLASS rather than its instances — every leg in this module is an inference about what the caller meant, and each new dispatcher seed re-opens it, which is precisely how X1 happened. If a third seed ever appears, B is the answer.

That is an accurate description of the shape. The module currently has three legs, and every one of them is an inference:

1. the record lacks the key, or
2. params holds a value differing from the record's (Object.is) — this card's gap, and
3. (added after the review) the key is a dispatcher-seeded id name, or its value is Object.is-equal to record.id.

Leg 3 exists because legs 1–2 could not see a seed that neither door had told anyone about. ⇒ The count of legs is a function of how many things the doors put in params without saying so, and nothing stops that number growing.

⚠️ This does not make A wrong for this card, and ⛔ it is not an argument to widen this card into B. A is contained and safe, and the PM scoped B out of PR #15787 deliberately (it is a spec + runtime contract change). ⇒ It is a note for whoever takes this: if the fix here is A, and a third dispatcher seed later forces a fourth leg, that is the signal that the class — not the instance — is what needs closing, and B is where it goes.

⭐ Also worth carrying: the #15705 dev declared a residual of its own, unprompted, that even the review had not named — recordIdParam naming a key the record lacks, while recordIdField names a non-id column, is the one row-id shape the value leg cannot see. It is pause-only, and it is a fourth instance of exactly the pattern above.

Refs: PR #15787 / #15705 (the provenance check and its X1 extension) · comment 5550698677 (the review that found X1).

---

Generated by Claude Code