fix(lint,cli): the flow-template-path rule reaches os lint and os compile, not just os validate (#3583, #3810) - #3874
Merged
os-zhuang merged 1 commit intoJul 28, 2026
Conversation
…compile` (#3583, #3810) `validateFlowTemplatePaths` was wired by hand into `os validate` and nowhere else — the drift `REFERENCE_INTEGRITY_RULES` exists to end (#3583 §5 D5): one stack, a different rule subset depending on which command the author ran. It mattered more once #3861 gave the rule a gating severity. A `{record.<path>}` token in a CRUD node's `filter` naming an unknown field, or hopping through an un-expanded relation, makes the runtime REFUSE the node (#3810). `os validate` failed on it; `os lint` and `os compile` did not look, so a CI job running either one built and shipped a flow that cannot execute. The rule is now a suite member — it meets the suite's own admission criterion, since a `{record.<field>}` token is a name resolved against the bound object's declared fields. One line reaches all three commands; the hand-wiring in `validate.ts` is deleted rather than duplicated. Checked the three stack shapes the suite is handed before moving the call site: raw `config` (lint), `normalizeStackInput` output, and schema-parsed `result.data` (validate/compile), across all three example apps. They agree finding-for-finding, so the move does not change what is reported. End-to-end on app-showcase: all three commands pass unchanged on the real stack, and with one filter token corrupted to `{record.idd}` all three exit 1 — where previously only `validate` did. Also fixed in the same file: on a clean run `os validate --json` never reported the suite's warnings. `refWarnings` was assembled, printed, and included in the FAILURE payload, but omitted from the success-path `warnings` array — so adding the rule to the suite would have silently dropped its warnings for JSON consumers. Same bug shape as the dropped errors #3861 fixed: computed, then discarded. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EdCvGtER9SzJopS4Yh3Pa1
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
Contributor
📓 Docs Drift CheckThis PR changes 2 package(s): 19 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:
|
github-actions
Bot
added
documentation
os-zhuang
marked this pull request as ready for review
July 28, 2026 13:37
os-zhuang
deleted the
claude/flow-template-paths-reference-integrity-suite
branch
July 28, 2026 13:37
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
2 participants
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.
Why
validateFlowTemplatePathswas wired by hand intoos validateand nowhere else. That is precisely the driftREFERENCE_INTEGRITY_RULESexists to end (#3583 §5 D5): the same stack, checked by a different rule subset depending on which command the author happened to run.It became a real gap after #3861 gave the rule a gating severity. A
{record.<path>}token in a CRUD node'sfilterthat names an unknown field — or hops through an un-expanded relation — makes the runtime refuse the node (#3810).os validatefailed on it;os lintandos compilenever looked. A CI job running either one would build and ship a flow that cannot execute.What changed
The rule is now a suite member. It meets the suite's own stated admission criterion: a
{record.<field>}token is a name written in metadata, resolved against the bound object's declared fields. One line inREFERENCE_INTEGRITY_RULESreaches all three commands, and the hand-wiring invalidate.tsis deleted rather than duplicated.The suite's doc comment now records why this member carries both severities, so the next reader doesn't assume the suite is warning-only.
Verification
Stack-shape parity, checked before moving the call site. The suite is handed three different shapes: raw
config(os lint), and schema-parsedresult.data(os validate/os compile) — while the rule's old call site usednormalizeStackInputoutput. If those disagreed, the move would silently change coverage. Ran all three shapes acrossapp-todo,app-crmandapp-showcase: they agree finding-for-finding.End-to-end on the real showcase stack:
os validate/lint/compileon the clean stack{record.idd}validateexits 1packages/lintsuite green: 515 passed, including a new suite test asserting a filter-position finding survives aserror(the suite's only flow-sourced error, so it pins that both severities pass through).validate.tstypecheck: 0 errors. ESLint clean on all changed files.Also fixed, in the same file
On a clean run,
os validate --jsonnever reported the reference-integrity suite's warnings.refWarningswas assembled, printed to the console, and included in the failure payload — but omitted from the success-pathwarningsarray.Adding this rule to the suite would have silently dropped its warnings from
--jsonfor JSON consumers, sorefWarningsnow appears there. That also surfaces the other five rules' warnings that were being discarded. Same shape of bug as the dropped errors #3861 fixed: computed, then thrown away.Compatibility
No authoring change. Any stack that passes
os validatetoday passes all three commands after this. What changes is thatos lintandos compilestop accepting a flow whose filter the runtime already refuses.Generated by Claude Code