You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-up to the dogfooding issue (OSS-28 / #104). no-em-dashes and no-blocklist-phrases now exist and are scoped to **/README.md. This issue is the decision to widen them.
load-bearing appears 27 times. That is ~2300 findings at level: error, which is why the rules did not ship repo-wide.
Why this is not one decision
The areas differ in kind, and probably want different answers:
packages/cli/src/agent/*.txt is agent-facing recipe text — prose we author and ship as a product surface. The strongest case for enforcement, and the largest single remediation.
TypeScript comments are reachable: Vale reads .ts in its comments-only tier, so a rule sees the comments and never the code. Enforceable without touching source.
openspec/ carries the largest count, and archived changes under openspec/changes/archive/ are historical records. Rewriting them would edit the record of what was proposed at the time, which feat: resolve the CLI invocation as a recipe variable #143's review thread already established we do not do. Archives probably want a permanent exclusion rather than a remediation.
CLAUDE.md and .conventions/ are small enough to fix in one pass.
Also worth settling
Two corrections to the rules as OSS-28 specified them, both measured:
nonword: true is required on no-em-dashes. The snippet in OSS-28 omits it. Without it the rule parses, passes verify, and never fires — Vale wraps every token in word boundaries, and an em dash is non-word on both sides. It is a silent no-op, which is the worst failure mode for a rule nobody re-checks.
landed on was dropped from the blocklist. Measured firing on "the plane landed on time", exactly the literal sense OSS-28 says to protect. we landed already covers "we landed on the second option", so the broader token only added false positives.
The third rule OSS-28 describes — the "not X, Y" antithesis construction — is still unwritten. The issue itself is undecided between three approaches and calls whatever ships a heuristic, so it wants a human call rather than a default.
Suggested order
READMEs are enforced now. Next cheapest is CLAUDE.md plus .conventions/, then TypeScript comments, then the recipe text. openspec/changes/archive/ should be excluded permanently rather than scheduled.
Follow-up to the dogfooding issue (OSS-28 / #104).
no-em-dashesandno-blocklist-phrasesnow exist and are scoped to**/README.md. This issue is the decision to widen them.What widening costs
Measured against the current tree:
packages/cli/src(incl.src/agent/*.txtrecipe text)openspec/.conventions/CLAUDE.md**/README.md(in scope today)load-bearingappears 27 times. That is ~2300 findings atlevel: error, which is why the rules did not ship repo-wide.Why this is not one decision
The areas differ in kind, and probably want different answers:
packages/cli/src/agent/*.txtis agent-facing recipe text — prose we author and ship as a product surface. The strongest case for enforcement, and the largest single remediation..tsin its comments-only tier, so a rule sees the comments and never the code. Enforceable without touching source.openspec/carries the largest count, and archived changes underopenspec/changes/archive/are historical records. Rewriting them would edit the record of what was proposed at the time, which feat: resolve the CLI invocation as a recipe variable #143's review thread already established we do not do. Archives probably want a permanent exclusion rather than a remediation.CLAUDE.mdand.conventions/are small enough to fix in one pass.Also worth settling
Two corrections to the rules as OSS-28 specified them, both measured:
nonword: trueis required onno-em-dashes. The snippet in OSS-28 omits it. Without it the rule parses, passesverify, and never fires — Vale wraps every token in word boundaries, and an em dash is non-word on both sides. It is a silent no-op, which is the worst failure mode for a rule nobody re-checks.landed onwas dropped from the blocklist. Measured firing on "the plane landed on time", exactly the literal sense OSS-28 says to protect.we landedalready covers "we landed on the second option", so the broader token only added false positives.The third rule OSS-28 describes — the "not X, Y" antithesis construction — is still unwritten. The issue itself is undecided between three approaches and calls whatever ships a heuristic, so it wants a human call rather than a default.
Suggested order
READMEs are enforced now. Next cheapest is
CLAUDE.mdplus.conventions/, then TypeScript comments, then the recipe text.openspec/changes/archive/should be excluded permanently rather than scheduled.Refs #104
🤖 Generated with Claude Code
https://claude.ai/code/session_017cEN93Acyp4zBwP3oDnyy1