skill-authoring §3+§7: four maintenance-pass rules from one staleness incident

[firaen22]

What

Four rules, one incident seen from four sides — a maintenance session on a set of rules files where a measured finding went stale, the re-test that fixed it found something unexpected, and the cleanup afterwards found something else again.

§3 (Provenance and decay)

1. Staleness concentrates in the world-fact rules — audit there first. Rules encoding a fact about the outside world (which model is default, how a CLI behaves, a measured threshold) go stale in days; rules encoding method do not go stale at all. Scope a staleness audit to the former. Evidence: a four-file sweep found 8 of 8 stale instances in the one file carrying world-facts; three method files were clean.
2. An invalidation clause must bind to a surface the work already touches — appended to the existing re-verification-command bullet rather than added beside it. A condition needing a separate act of remembering is inert however precisely written.

§7 (Maintenance)
3. Probe a candidate rule against the bare executor before folding it in. §6's behavioral probe hunts gaps — what the file fails to cause. This asks the inverse, before the rule exists: run the scenario with no rule and with it. If the bare run already produces the behavior the rule is non-discriminating, and belongs in a reference or nowhere.
4. A derived file contradicting reality has not necessarily drifted — read its source first. If the source carries the identical wrong text, fixing only the derivative gets it re-broken by the next write-back.

Why

The four are causally linked, which is why they ship together rather than as four PRs.

A finding measuring rule-following at two file sizes carried the clause "re-test if either file grows past ~250 lines." Both files reached 297 and 318 and were still cited as current — the clause never fired because nothing read it. That is rule 2.

The re-test that eventually ran added a bare-executor control arm the original design lacked, and found 3 of 8 recently-folded rules were reproduced with no rules file at all. That is rule 3 — the one item here backed by a measurement rather than a shape (n=8, one probe per cell; it detects a large effect, not a small one).

The staleness sweep that followed found all 8 stale instances in the one file carrying model names and CLI behavior, none in the three carrying method. That is rule 1.

And one of those stale lines turned out to be copied faithfully from a source file carrying the same error — so fixing the derived file alone would have been undone by the next write-back. That is rule 4.

Notes

• Rules 1 and 4 are deliberately scoped against adjacent existing doctrine: rule 1 scopes the search only, never the fix; rule 4 names its distinction from §4's sync contract (which governs files that disagree — here they agree and are both wrong) and cross-references ground-truth-gates rule 7's mutual-agreement trap rather than restating it.
• Rule 2 is an in-place extension of the existing bullet, per §3's own correct-in-place rule — not a second bullet a reader could hit first.
• A fifth candidate from the same session was dropped after checking: "run the twin search before the completeness claim" is already covered by operational-rigor §5's "a completeness claim without a named, re-runnable search behind it is fabrication-shaped." It was a compliance failure on my side, not a doctrine gap.
• All four ship unprobed per the covenant. Private evidence cited as shape per the README covenant's second branch; no code taken.

.github/checks.py green. Unicode sweep clean.

🤖 Generated with Claude Code