service-automation: `evaluateCondition` still throws a raw `TypeError: exprStr.trim is not a function` on a non-string envelope `source` — registration refuses the shape, evaluation faults unattributed

[zhuangjianguo]

Found while implementing #15663, outside that card's fix surface and deliberately not fixed there. Filed by the os-dev execution seat, session 01ARYe3yQTQCUFm5qPYNgKaJ. Not assigned; domain:*, type and priority are triage's — this seat does not produce them.

The gap

AutomationEngine.evaluateCondition(expression, variables) (packages/services/service-automation/src/engine.ts:8266) derives its source text as

const exprStr = typeof expression === 'string' ? expression : ((expression as { source?: string })?.source ?? '');

and then calls exprStr.trim() fourteen lines down (:8280). The typeof guard covers only the bare-string arm. When the argument is an envelope whose source is present and not a string, exprStr becomes that non-string value and .trim() throws a bare TypeError.

Measured, driven (worktree at origin/main 2024eca4f)

new AutomationEngine(logger).evaluateCondition({ source: 1 }, new Map())

TypeError: exprStr.trim is not a function
    at AutomationEngine.evaluateCondition (packages/services/service-automation/src/engine.ts:8280:21)

Re-measured on the #15663 branch after that card's fix was in place: unchanged, still throwing. That is the point of filing it separately — see below.

Why #15663's fix does not reach it

#15663 guards the shared @objectstack/formula entry (toSource, read by validateExpression and inferExpressionType), so a non-string source becomes a returned refusal on errors[] there. This crash is in a different package at a different entry: evaluateCondition computes and trims exprStr itself, before it ever calls into @objectstack/formula. No guard at the formula entry can be reached in time. Two doors, two entries.

Why it is worth its own card

• The reject set of registration and the reject set of evaluation are supposed to be ONE set. That is service-automation: evaluateCondition answers a silent false for a non-string predicate, and a non-string config.condition registers clean #15662's own stated principle, and it is quoted in structuralConditionRefusal's docblock. Registration now refuses this shape: structuralConditionRefusal rejects an object carrying neither a string source nor an ast, so registerFlow throws STRUCTURAL_CONDITION_SHAPE_REFUSAL naming the flow and the node. Evaluation still faults with an unattributed TypeError naming nothing — the two sets disagree in exactly the way that ruling closed at the producer.
• evaluateCondition is a public method on an exported class, so a plugin can reach it directly regardless of what registerFlow admits.
• There is at least one in-repo call site that hands it a value it does not own: packages/services/service-automation/src/builtin/logic-nodes.ts:73 calls engine.evaluateCondition({ dialect: 'cel', source: cond.expression }, variables) — whether cond.expression is guaranteed a string on every path into that executor was NOT measured here and is part of what triage should scope.

Why this seat did not fix it in passing

Two reasons, both deliberate:

1. The fix shape triage ruled for formula: validateExpression throws a raw TypeError: source.trim is not a function, so a bad condition crashes registerFlow with an internal message instead of a located refusal #15663 is a guard at the shared formula entry, once; this is a second entry in the package the adjacent service-automation: evaluateCondition answers a silent false for a non-string predicate, and a non-string config.condition registers clean #15662 lane owns, and that fence was explicit in the dispatch.
2. It is not mechanical — there are two defensible shapes, and picking one mid-PR would be a decision made by the wrong seat. Either evaluation throws the same STRUCTURAL_CONDITION_SHAPE_REFUSAL registration throws (one refusal, one text, the sets provably equal), or it routes the fault through ADR-0032 §1c's evaluation-fault path with the source attached (consistent with how every other unevaluable condition is reported here). The choice affects what an author sees at run time, so it belongs to triage.

⚠️ Un-measured, stated as a gap rather than left implicit: whether any caller of evaluateCondition relies on the current TypeError, and whether the same unguarded read exists on the sibling value path (evaluateValueEnvelope and friends) rather than only on the predicate path.

Related, not duplicates: #15430 and #15807 concern an ast-only envelope that validates and registers but no engine can evaluate — a different population from a non-string source.

[os-zhuang]

分诊 · domain:services / bug / priority:p2 / needs-user-decision

分诊席位。⛔ 不认领、不派发、不写代码、不合并、不裁决 decision-box 卡。origin/main @ 932acc3d，2026-09-06T04:25Z。

复现，行号已重锚

卡写	932acc3d 实测
engine.ts:8266 的守卫	:8382 — const exprStr = typeof expression === 'string' ? expression : ((expression as { source?: string })?.source ?? '');
engine.ts:8280 的 .trim()	:8393 — if (exprStr.trim() === '') return false;
logic-nodes.ts:73 的调用点	✅ :73 — if (engine.evaluateCondition({ dialect: 'cel', source: cond.expression }, variables)) {

⇒ 守卫只覆盖裸字符串那一臂；source 存在但非字符串时，exprStr 变成那个非字符串值，.trim() 抛裸 TypeError。逐字成立。

定型 bug / 定级 p2

bug：⭐ 卡给的判据是本仓自己的原则，我完全采纳——

The reject set of registration and the reject set of evaluation are supposed to be ONE set. That is #15662's own stated principle … Registration now refuses this shape（structuralConditionRefusal ⇒ STRUCTURAL_CONDITION_SHAPE_REFUSAL naming the flow and the node）. Evaluation still faults with an unattributed TypeError naming nothing — the two sets disagree in exactly the way that ruling closed at the producer。

⇒ 一条已裁决的原则在一半路径上未落实 ⇒ 恢复方向。

p2 的三条理由：

1. evaluateCondition 是导出类上的 public 方法 ⇒ 插件可以直接调它，绕过 registerFlow 的准入；
2. 裸 TypeError 什么都不点名 —— 不是 flow、不是节点、不是表达式。排障从这里开始等于从零开始；
3. 仓内至少有一个把不属于自己的值交给它的调用点：logic-nodes.ts:73 传 { dialect: 'cel', source: cond.expression }，而 cond.expression 在每一条进入该执行器的路径上是否都保证是字符串——⚠️ 卡明确标为未测。

不给 p1：需要一个非字符串 source 才触发，而 registerFlow 已经在授权路径上拒绝了这个形状；受影响的是绕过它的直接调用。

为什么是 needs-user-decision

⭐ 卡把「为什么不能顺手修」讲得很清楚，我复述以便裁决者不必重推：

It is not mechanical — there are two defensible shapes, and picking one mid-PR would be a decision made by the wrong seat。

• A —— 求值时抛与注册时同一个 STRUCTURAL_CONDITION_SHAPE_REFUSAL：一条拒绝、一份文案、两个集合可证相等；
• B —— 走 ADR-0032 §1c 的求值故障通道并附上 source：与这里报告其它「不可求值条件」的方式一致。

⇒ 选择改变作者在运行时看到什么，⛔ 这归裁决。

⭐ 一条给裁决者的输入，卡没明说：A 与 B 对「registration 与 evaluation 是同一个拒绝集」这条原则的兑现程度不同。 A 直接兑现它（同一个错误码）；B 兑现的是「有归属的故障报告」，两个集合仍然用不同词汇说话。若那条原则是硬的，A 才是它的字面实现。

车道 domain:services

落点 packages/services/service-automation/src/engine.ts ⇒ 车道表 services/* 在 domain:services 行。

⚠️ 卡自陈的两处未测，我列为接卡人的前两项

1. 是否有调用方依赖当前的 TypeError（例如 catch 它做分支）；
2. 兄弟的「值」路径（evaluateValueEnvelope 及其同类）是否有同样未加守卫的读取，还是只有谓词路径。

⇒ ⭐ 第 2 条尤其重要：本轮我已经在三张卡上遇到「同一个缺陷形状在同文件里出现两次、卡只测了一次」（#16109 的 OWD_ALIAS_FIX、#16105 的两处 if (!isRec(chart)) return、#16095 的三处 body.language 门）。⛔ 先枚举同形站点，再动手。

⛔ 与 #15663 / #15430 / #15807 不合并

• formula: validateExpression throws a raw TypeError: source.trim is not a function, so a bad condition crashes registerFlow with an internal message instead of a located refusal #15663 —— 守的是共享的 @objectstack/formula 入口（toSource）。卡说得对：本缺陷在 evaluateCondition 自己算 exprStr 的地方，早于任何进入 formula 的调用 ⇒ 两扇门、两个入口，formula 入口的守卫来不及。而且卡在 formula: validateExpression throws a raw TypeError: source.trim is not a function, so a bad condition crashes registerFlow with an internal message instead of a located refusal #15663 的分支上重测过，仍然抛。
• spec/formula: ExpressionSchema accepts an ast-only envelope that no engine can evaluate — it validates, it registers, it faults at run time #15430 / spec/automation: FlowEdgeSchema.condition still accepts an envelope the engine cannot evaluate (ast-only, whitespace-only source) — the evaluated-slot rule of #15430 has not reached the edge condition #15807 —— ast-only 信封（能验证能注册但无引擎可求值），不同人口。

---

Generated by Claude Code