fix(flows): author conditions as CEL envelopes so they actually evaluate

[yinlianghui]

Description

Every decision node and conditional edge in src/flows/ authored its condition as a bare string. AutomationEngine.evaluateCondition only routes an Expression envelope ({ dialect, source }) to the CEL engine — a bare string falls through to a legacy template path that substitutes {var} braces and then compares both sides as strings. No condition in this app was ever evaluated as an expression.

The failure mode was not a uniform no-op, which is what made it dangerous:

Authored	Actually evaluated	Result
existingStallTask == null	'existingStallTask' === 'null'	always false
record.rating >= 4	'record.rating' >= '4'	always true ('r' > '4')

So opportunity_stagnation selected the right stalled deals (after #560) and then silently dropped every one of them at its idempotency gate — no notification, no follow-up task, and a success run record either way. In the other direction, lead_assignment pinned the Hot branch open and never took the Standard path.

This is #562, split out of #489 while verifying #560.

Type of Change

• Bug fix (non-breaking change which fixes an issue)

Related Issues

Refs #562

Changes Made

• All 41 condition sites across 13 flow files now use the P tagged template from @objectstack/spec, which emits the envelope at authoring time.
• The condition sources are unchanged. They were already valid CEL: the engine merges its variable map onto the CEL scope via ctx.extra (buildScope assigns ctx.extra after scope.record, and the variable map carries a record key), so flow variables resolve by bare name and record is the triggering record. Only the envelope was missing.
• defineFlow() would not have been sufficient. It normalizes the typed edge condition (FlowEdgeSchema.condition is ExpressionInputSchema), but a node's config is z.record(z.string(), z.unknown()) — so every start-node trigger gate would have stayed a bare string. P covers both sites and needs no parse step.
• New guard in test/metadata-references.test.ts: no flow condition may be a bare string, at either site, with a floor on the number of sites inspected so a walker that stops matching cannot make the test vacuous.
• The two case_escalation assertions in test/actions-flows-integrity.test.ts read condition.source instead of the raw value.
• Two conditions that were built by string concatenation across lines (case_escalation, opportunity_approval) are now single multi-line templates — CEL treats the newline as whitespace.

Testing

• Unit tests pass (pnpm test — 169 passing)
• Linting passes (pnpm lint — 1 warning / 9 suggestions, byte-identical to the same run on an unmodified tree)
• Build succeeds (pnpm build); pnpm verify clean end to end
• Manual testing completed
• New tests added

Artifact check — all 46 condition sites in dist/objectstack.json (more than the 41 source sites because demo_bootstrap generates edges with flatMap) are cel envelopes, zero bare strings, and every source parses against the real CEL engine.

Verified on a booted server (pnpm start, fresh DB, temporary 1-minute cron on opportunity_stagnation)

• The sweep now creates 30 follow-up tasks, one per stalled deal — it created zero before this change, stopping at the check_not_nudged decision node every iteration.
• The count holds at 30 across later ticks, and each subject appears exactly once, so the idempotency gate now opens on the first pass and closes on every pass after it.
• The guard was checked against a deliberate regression: reverting one condition to a bare string fails the new test with the flow name, node id, and offending source.

Additional Notes

Not verified end to end: the lead_assignment Hot/Standard branch. Its trigger is record-after-create, the REST data route requires auth, and the seeded leads' next_followup_date values are seed literals rather than flow output — so there was no zero-auth path to exercise it on a live server. What is verified is the mechanism (identical evaluateCondition → edge-condition path, proven end to end by the stagnation sweep) and the expressions themselves (record.rating >= 4 → true and record.rating < 4 → false against the packaged CEL engine using the exact context shape the automation engine builds).

Dead config left in place: a decision node's config.condition (singular) is never read — the executor reads config.conditions (plural, an array of {expression, label}) and so always returns branchLabel: 'default'. That is currently harmless because no edge carries label: 'default', which makes traverseNext fall back to the full edge set. Restructuring it would change routing, so it is out of scope here, but if anyone ever labels an edge default, that edge will monopolise the branch and bypass every conditional edge. Noted on #562.

Upstream, not fixable here: node config is an untyped z.record(z.string(), z.unknown()), so no node-level expression can ever be normalized by schema parsing; and evaluateCondition's legacy path silently string-compares instead of failing, which is what turns an unresolved identifier into a wrong branch rather than an error. Both are recorded on #562.

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
hotcrm	Ignored		Jul 31, 2026 3:48am