Problem
TypeSafe answers at most 32 questions per request. The rules guard reserves one for the edit locator and asks one question per rule, so a rules file with more than 31 rules has the rest dropped in file order (MAX_RULES = 31 in src/rules.ts; RuleSet.dropped carries the count). /warden status shows the dropped count, but the rules past the cap are never judged, and a user who wrote rule 35 has no reason to expect it is inert.
31 is enough for most projects. Monorepos and teams that split rules by area hit it.
Proposal
Pick one of these; the first is the recommended default with the second as an opt-in.
A. Scope first, then cap. Rules carry paths: scopes. Before applying the cap, drop rules whose scope does not match the target path. A write to src/api/x.ts never needs the docs/** rules in its request. This raises the effective cap for scoped rule files at no cost and changes nothing for unscoped files. Implement in rulesFor(set, target) or wherever the per-target subset is chosen.
B. Second request past the cap, opt-in. A config key rules.maxRequests (default 1). With 2, rules 32 to 62 go in a second request for the same write, doubling the cost of that judgment. Both verdicts merge into one steer. The trace records two requests. Status shows dropped only when the total exceeds 31 * maxRequests.
C. Warn on the file. Independent of A and B: when the parsed rule count exceeds the cap at load time, notify once per session naming the file and the first dropped rule id, so the author knows.
Acceptance
- A: a target under
src/ with a 40-rule file where 12 rules are scoped to docs/** sends at most 28 questions and drops zero. Unscoped 40-rule file still drops 9.
- B: with
maxRequests: 2 a 40-rule file sends two requests and drops zero; with the default it sends one and drops 9. Steer text merges findings from both.
- C: the notice fires once and names the file and rule id.
npm run check passes. Docs for the new key in docs/configuration.md. CHANGELOG entry under Unreleased.
Non-goals
- Merging rules to fit. A merged rule loses the ability to name which one was violated.
- Raising the per-request question limit; it is the backend's.
Problem
TypeSafe answers at most 32 questions per request. The rules guard reserves one for the edit locator and asks one question per rule, so a rules file with more than 31 rules has the rest dropped in file order (
MAX_RULES = 31insrc/rules.ts;RuleSet.droppedcarries the count)./warden statusshows the dropped count, but the rules past the cap are never judged, and a user who wrote rule 35 has no reason to expect it is inert.31 is enough for most projects. Monorepos and teams that split rules by area hit it.
Proposal
Pick one of these; the first is the recommended default with the second as an opt-in.
A. Scope first, then cap. Rules carry
paths:scopes. Before applying the cap, drop rules whose scope does not match the target path. A write tosrc/api/x.tsnever needs thedocs/**rules in its request. This raises the effective cap for scoped rule files at no cost and changes nothing for unscoped files. Implement inrulesFor(set, target)or wherever the per-target subset is chosen.B. Second request past the cap, opt-in. A config key
rules.maxRequests(default1). With2, rules 32 to 62 go in a second request for the same write, doubling the cost of that judgment. Both verdicts merge into one steer. The trace records two requests. Status showsdroppedonly when the total exceeds31 * maxRequests.C. Warn on the file. Independent of A and B: when the parsed rule count exceeds the cap at load time, notify once per session naming the file and the first dropped rule id, so the author knows.
Acceptance
src/with a 40-rule file where 12 rules are scoped todocs/**sends at most 28 questions and drops zero. Unscoped 40-rule file still drops 9.maxRequests: 2a 40-rule file sends two requests and drops zero; with the default it sends one and drops 9. Steer text merges findings from both.npm run checkpasses. Docs for the new key indocs/configuration.md. CHANGELOG entry underUnreleased.Non-goals