Repository navigation
fix(port): fail an exemption fragment that names more or fewer than one rule - #30
Merged
Merged
Conversation
rules.sed carried the same `run_in_background: true` token rule twice. The first copy consumes every match, so the second could never fire, and no exemption fragment can tell two identical lines apart. Tree unchanged.
…rites Both `interrogate reviewers` line rules matched `task.agentModelOverrides` in `~/.omp/agent/config.yml`, text only the path net further down writes, so neither could fire and one exemption fragment covered both. The surviving rule now matches the `~/.cursor/rules/pstack-models.mdc` path upstream writes, like the runner and judge rules beside it, and is no longer stale. The other copy goes, with the rule that only rewrote its output and both exemptions. Tree unchanged: the per-entry sentence rule consumes the one upstream occurrence first.
Five fragments matched a second rule, either that rule's replacement text or a whole-sentence rule containing the same token. Each now starts with the `s#` opener of the rule it was written for. Two rows were byte-identical copies of another row and go.
…ne rule A stale-rule exemption is a substring of a rules.sed line, so one fragment could match several rules and keep every one of them from failing `rule staleness`. That already hid a swarm Phase B rule once. One resolver now maps each fragment to the rules it matches. `stale exemptions` fails a fragment that matches several rules or none, naming the tsv row and the rules.sed lines, and only a fragment naming exactly one rule exempts anything. The lint runs before the contracts-only exit, so the mutation harness covers it: copying the rule an exemption names must fail it.
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.
Why
The
rule stalenessgate exempts a stale rule by a text fragment. Seven fragments each matched more than one rule, so an exemption written for one stale rule could silently keep a different one from failing the gate. This already happened once, with a swarm rule that went stale behind arun_in_background: truefragment.What changed
stale exemptionsnow fails a fragment that names more or fewer than one rule inrules.sed. The message names the row and the lines.Scope
Blast Radius
It affects only the gate and the rule table. A future edit that makes a fragment ambiguous now fails the gate instead of hiding a stale rule.
Verification
bash omp-port/check-port.shprintscheck-port: PASS, withstale exemptionsat 74 fragments each naming exactly one rule andreproducibleunchanged ate73df47.bash omp-port/test-gate-mutations.shpasses with 17 mutations, each rejected by its own check. A loosened copy of the check made the new mutation report that it unexpectedly passed.