ActionEngine 的 event-mapping(addMapping / dispatch)零生产调用方,且 condition 求值与 visible 契约不一致

[yinlianghui]

Filed unassigned,来自 #3314 的只读排查(为定 visible 归一化判据而通读 ActionEngine)。只记录发现。

现象

packages/core/src/actions/ActionEngine.ts:

1. 这条 API 是 dormant 的。 git grep addMapping -- packages apps examples(排除
CHANGELOG)只命中定义处与 packages/core/src/actions/__tests__/ActionEngine.test.ts
里的 4 处测试调用 —— 没有任何生产代码注册过 event→action 映射,dispatch() 也就
没有真实调用方。

2. dispatch() 的 condition 求值与 visible 的契约有两点不一致:

if (mapping.condition) {
  const evaluator = this.runner.getEvaluator();
  const shouldRun = evaluator.evaluateCondition(mapping.condition);
  if (!shouldRun) continue;
}

• 没有传 throwOnError,所以谓词抛错时 fail-OPEN(动作照跑);同一个类里
  getActionsForLocation 的 visible 是明确 fail-closed 的(谓词不可求值就隐藏)。
• ActionMapping.condition 的类型是 string,拿不到 { dialect: 'cel', source } 信封,
  因此永远走 legacy JS 求值 —— 正是 ActionEngine.getActionsForLocation 把 CEL 信封塌回 legacy JS 求值路径,与每个渲染器的判决不一致 #3314 刚在 visible 上修掉的那条路径。
  裸串在 evaluateCondition 里会被当作整条表达式求值(不是 CEL 引擎)。

为什么是 observation-class

零生产调用方,今天没有用户能碰到这两点中的任何一个。把它当缺陷直接「修」反而是给
一条没人用的 API 增加行为面;真正要先回答的问题多半是这条 event-mapping API 要不要留
(留 → 契约对齐 visible:throwOnError + 接受 Expression 信封;不留 → 按
enforce-or-remove 退役,连同 ActionMapping 类型与那 4 个测试)。

所以只记录,不带 pm:queue,留给 triage 决定方向。

[yinlianghui]

发现分诊轮(持有):前提 live(addMapping/dispatch 全仓零生产调用方)。休眠 API 的去留是 enforce-or-remove 类维护者决策,在未用 API 上修契约只会加行为面;待维护者对 ActionEngine 的 appetite。(objectui 分片 PM,会话 session_01GTRjn8xBqp75dk7kFupVRt)

---

Generated by Claude Code

[claude]

Findings triage (15:47Z fire) — HOLD confirmed, premise re-verified.

Re-checked against origin/main: git grep addMapping -- packages apps examples still returns the definition (ActionEngine.ts:180) plus four test call sites and zero production callers. The dormancy that makes this observation-class rather than a defect is unchanged, so the enforce-or-remove question it really poses is still the maintainer's to answer, and hardening the contract of an API nobody calls would still only widen behaviour. Hold stands; restart condition (a maintainer ruling on ActionEngine's event-mapping API, or a first production caller) unchanged.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[yinlianghui]

补一条本单尚未记录的事实(来自 #3872 / PR #3916 的邻行扫面,非认领,不改本单 observation-class 定级):

dispatch() 的那道门除了本单已记的两点(不传 throwOnError 故 fail-OPEN、类型是 string 拿不到 { dialect, source } 信封)之外,入门判定本身也是真值 —— if (mapping.condition),与 ActionRunner.execute 的 condition 门在 #3872 修掉的是同一个形状:

if (mapping.condition) {                       // ActionEngine.ts:313
  const shouldRun = evaluator.evaluateCondition(mapping.condition);
  if (!shouldRun) continue;
}

mapping.condition: false(以及 0)落在 if (false) 上 —— evaluateCondition 根本没被问过,映射照常派发。方向是过度放行:作者声明「这条 event 映射永不触发」,拿到的是照样触发。同义的 { dialect: 'cel', source: 'false' } 与裸串 'false' 都会被拦下,故同一句话的三种拼法结论不一致。

这不改变本单的定级:addMapping / dispatch 仍是零生产调用方,今天没有用户能碰到,方向问题(契约对齐 visible 还是按 enforce-or-remove 退役)也仍然要先答。只是若裁决为「留」,这条真值判定要和另外两点一起对齐 —— #3872 的裁决语义可直接复用:门问「有没有声明」(取自 toPredicateInput 归一,'' / 纯空白 / 空 source envelope 一律不算已声明,即 #3850 的裁决),verdict 读原始值(toPredicateInput 对已是 ${…} 的字符串二次包裹成恒真,#3871)。PR #3916 里的 hasDeclaredPredicate 就是这个问题在 ActionRunner 内的 module-private 形状;#3850 / #3862 的定义下沉落地后,这里应当改读同一份共享定义,而不是再添第 N 种拼法。

---

Generated by Claude Code