feat(validate): did-you-mean warnings for field typos in flow conditions (#1928)#1933
Merged
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
📓 Docs Drift CheckThis PR changes 2 package(s): 18 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:
|
…ons (#1928) Flow/automation conditions flatten the record's fields to top-level, so a bare `status` is correct — but a bare NON-field identifier is either a flow variable or a typo. When it's a near-miss of a known field, the build now emits a non-blocking `did you mean X?` warning instead of staying silent, closing the silent-skip gap for misspelled trigger-condition fields (#1877 family) without the false-positive risk of a hard gate (a real flow variable won't be edit-distance-close to a field name, so it stays quiet). - `ExprValidationResult` gains `warnings`; `firstUndeclaredReference(source, knownFields)` generalizes the bare-ref detector (record scope = no fields, flattened scope = trigger object's fields declared so only non-field refs surface). - `ExprIssue` gains `severity`; `objectstack compile` prints warnings and fails only on errors. Verified: a typo'd flow condition warns + still builds; all example apps build clean with zero warnings (flow variables like `expiring_deals` stay quiet). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
os-zhuang
force-pushed
the
feat/flow-condition-typo-warnings
branch
from
June 16, 2026 02:38
dcf3493 to
a1b2c24
Compare
os-zhuang
added a commit
that referenced
this pull request
Jun 16, 2026
…ckend (ADR-0052 §5) (#1955) Ends the split-brain. There were two parallel record-collaboration/timeline implementations: sys_comment/sys_activity (DB-backed, default-loaded, the ChatterPanel's actual source of truth) and @objectstack/service-feed (an in-memory, non-durable, UI-unconsumed parallel feed whose nested REST route was never even mounted). Decision (ADR-0052 §5): keep sys_comment as canonical and retire service-feed. - Delete the @objectstack/service-feed package (in-memory adapter, feed_item/ feed_reaction/record_subscription objects, FeedServicePlugin). - Remove the `feed` capability from the CLI CAPABILITY_PROVIDERS resolver and the cli → service-feed dependency; drop it from the changeset package list. - Fix a stale comment in system-file.object.ts. - ADR-0052 §5 records the decision + rationale (durable/UI-wired wins over an unshippable better-model); the unified typed timeline lives on sys_activity. No app depended on service-feed (CLI was the only referencer). The vestigial spec contracts (feed.zod/feed-api.zod/IFeedService) are woven into component.zod/ protocol.zod/objectql and are a separate type-surface cleanup (follow-up). NOTE: the CLI build is red on main from a pre-existing CEL drift in validate-expressions.ts (#1933 area, in-flight in another worktree), unrelated to this change — this commit touches none of those files. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This was referenced Jul 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Tier 3 of #1928 — stacked on #1931 (base will retarget to
mainonce #1931 merges).Problem
Flow / automation conditions flatten the record's fields to top-level, so a bare
statusis correct. But a bare non-field identifier is either a flow variable or a typo — and a misspelled trigger-condition field (stagee == "closed_won") makes the flow silently never fire (the #1877 family). #1931 deliberately left flow conditions out of its hard gate because flow variables aren't schema-knowable, so a bare ref there can't be soundly classified as an error.Fix — a non-blocking warning channel
When a bare non-field identifier in a flow condition is a near-miss of a known field (edit distance), emit a
did you mean \status`?**warning** — never failing the build. A genuine flow variable (expiring_deals,new_opportunity`) isn't edit-distance-close to a field name, so it stays quiet.ExprValidationResultgainswarnings;ExprIssuegainsseverity.firstUndeclaredReference(source, knownFields)generalizes feat(validate): flag bare field refs in record-scoped CEL sites (#1928) #1931's detector: record scope passes no fields (any bare ref is an error); flattened scope declares the trigger object's fields so only non-field refs surface for the did-you-mean check.objectstack compileprints warnings and fails only on errors.Verification
⚠ Expression warnings (1) … did you mean \stage`?and **still builds** (✓ Build complete`).@objectstack/formula, 4 in@objectstack/cli. Suites green (formula 105, cli 417).This completes the #1928 tiers that can be done without runtime-fidelity risk: tier 1 (record-scope bare refs, hard error — #1931) + tier 3 (flow-condition typos, advisory warning — here). Tier 4 (full type-soundness) remains deferred.
Refs #1928. Stacked on #1931; sibling runtime fix #1930.
🤖 Generated with Claude Code