feat(automation): schema-aware flow-condition validation at registration (#1928)

[os-zhuang]

What

Brings the registerFlow runtime path up to parity with objectstack build: a flow condition that references an unknown field, likely-typos a field name, or does arithmetic/ordering on a text/boolean field against a number is now surfaced at registration — so a flow registered dynamically (API / Studio, bypassing the build lint) still gets the #1928 guardrails.

This is the real, tractable version of the "authoring-time feedback" follow-up noted in #3178. (There is no validate_expression agent tool in the codebase to wire into; the flow-registration path is the actual runtime authoring surface.)

Stacked on #3178 (base = claude/cel-js-arithmetic-null-2xtg4s). It consumes the tier-4 fieldTypes/flattened-scope check added there. GitHub will retarget this to main once #3178 merges; the diff stays just this change.

Design — strictly additive, zero regression

• New opt-in bridgeAutomationEngine.setObjectSchemaResolver(resolver), mirroring the existing setFunctionResolver. AutomationServicePlugin wires it to objectql.registry.getObject in start(), before the flow pull, so registry-sourced flows are covered too.
• validateFlowExpressions keeps its fatal set unchanged (syntax, brace-in-CEL, unknown-function still throw). When a resolver is wired, a second schema-aware pass runs only on syntactically-valid conditions and its findings (field-existence, tier-3 typo, tier-4 type mismatch) are logged as advisory warnings — never thrown. So a wired resolver can never break a flow that used to register cleanly, and the whole thing is a no-op when unwired.
• Flow conditions bind the record's fields flat → the check runs in flattened scope: flow variables stay dyn (never flagged), equality stays runtime-safe.
• parseObjectFieldSchema normalizes the registry's field shape (name-keyed map — the ServiceObject shape — or {name,type}[]) into the validator's hint.

Why advisory (not fatal) at registration

The build gate (objectstack build) is strict and fails the build. Runtime registerFlow is deliberately lenient — a running system should log a suspicious dynamically-registered flow, not refuse to register it (and a resolver fed a partial field list must never hard-break registration). Same guardrail, appropriate severity per surface.

Testing

• @objectstack/service-automation — 316 green (+10):
  • 6 engine cases: tier-4 / tier-3 / tier-2 each log an advisory warning and do not throw; sound conditions (number arithmetic, equality, flow variables) stay clean; a malformed condition still hard-fails; no-op without a resolver.
  • 4 parseObjectFieldSchema cases: map shape, array shape, non-string type → dyn, invalid input.
• Full existing suite unchanged (306 → 316); DTS build type-checks clean.

Refs: #1928, ADR-0032. Builds on #3178 (tier-4), #1930 / #1931 / #1933.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Hnji7EEYR2mGt6pY53a8Bm

---

Generated by Claude Code

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
spec	Ready	Preview, Comment	Jul 18, 2026 8:15am

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): packages/services.

6 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:

• content/docs/automation/webhooks.mdx(via packages/services)
• content/docs/kernel/runtime-services/audit-service.mdx(via packages/services)
• content/docs/kernel/runtime-services/index.mdx(via packages/services)
• content/docs/kernel/runtime-services/settings-service.mdx(via packages/services)
• content/docs/plugins/packages.mdx(via packages/services)
• content/docs/protocol/kernel/i18n-standard.mdx(via packages/services)

Advisory only. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs origin/main → pass the list as args.docs.