docs(openspec): measure ini repeated-key precedence against Vale 3.21.0 - #340
Merged
Merged
Conversation
Vale 3.21.0 made a key assigned twice inside one matcher keep its LAST assignment (upstream 1e4f6ed), the direction that already held between matchers. The spec still carried the 3.17.1 measurement saying first. The requirement's rule is unchanged; a new scenario pins the shape the vendor contract test measures.
thecodedrift
added
the
skip-changeset
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
1 participant
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.
The
cli-vale-rule-enginespec records, "measured against Vale 3.17.1", that a key assigned twice inside one matcher keeps its first assignment. Vale 3.21.0 changed that to last (upstream 1e4f6ed, "let the project's rule settings win"), the direction that already held between two different matchers. The CLI pins 3.21.0 as of #336,vale-vendor-contract.test.tsasserts last-wins in both orders, andassemble.tssays so; the spec was the one place still stating the old measurement.What changes
The requirement's rule does not change: a disable is declared after the enable it narrows, and assembly is deterministic. Under last-wins that holds in every shape rather than only across matchers.
Delivery
Single PR, no code change; the behaviour already ships. The change is archived here since the spec is the whole work. Archive dry-run per CLAUDE.md: 22 → 23 scenarios on the standing spec, +8/−2 lines, every prior scenario present.
Refs #336