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
Autocompact was firing at ~115k on a 1M-context model, repeatedly costing the maintainer working sessions. Root cause: CLAUDE_CODE_AUTO_COMPACT_WINDOW=350000 and CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=35 MULTIPLY.
The fix — deleting the WINDOW key from ~/.claude/settings.json — was correct. It was then reported as fixed while the bug was still live, because an env var cannot be unset in a running process. The user hit the same bug again and reasonably read it as a regression.
Two distinct process defects, both generalizable beyond autocompact.
Defect 1 — "fixed" was allowed to mean "edited"
The verification performed was "the key is gone from settings.json". The verification that mattered was:
env | grep -i compact
Three seconds. It was only run after the user came back and asked.
Checking the config file and claiming it proves the process state is the vacuous-guard defect class — a check that appears to verify X and actually verifies Y. That is precisely what #513 exists to catch in this repo's tests. It shipped inside the workflow that was building the detector.
Proposed rule (/sdlc, Test Failure Recovery or a new short section): before reporting a fix, name the observable that would differ if it were NOT fixed, and go look at that observable. Edited a settings file → read the live process env. Changed a hook → fire it. Changed a threshold → measure it against the real files rather than restating the number. If the only evidence is "I made the edit", the state is submitted, not fixed.
This is cheap, universal, and consumer-relevant — it is not autocompact-specific.
Defect 2 — config/env changes are a review-invisible class
The maintainer asked why neither Fable nor Codex caught it. Neither was ever asked. The change lived in ~/.claude/settings.json: outside the repo, so no diff, no handoff.json, no PR, no review surface at all. Both reviewers only ever see what they are handed.
The knowledge was nevertheless already on disk in this repo:
The maintainer's private memory recorded the live-process-unset problem verbatim, including claude --resume as the real fix.
So this was not a reviewer capability gap. It was a failure to consult an existing review artifact before making an out-of-repo change that no gate covers.
Proposed rule: when a change lands outside the repo (global settings.json, env vars, shell rc, launchctl), it receives no automatic gate. Therefore: read the existing .reviews/ artifacts and memory on that subject BEFORE editing, and state the verification command in the same breath as the change.
Scope note
skills/sdlc/SKILL.md is at 19,356 of its 20,000-byte ceiling, so any addition needs an equal-or-greater trim in the same edit. It is also on the merge denylist, so this cannot ride along on #513 and needs its own PR.
Incident (2026-08-08)
Autocompact was firing at ~115k on a 1M-context model, repeatedly costing the maintainer working sessions. Root cause:
CLAUDE_CODE_AUTO_COMPACT_WINDOW=350000andCLAUDE_AUTOCOMPACT_PCT_OVERRIDE=35MULTIPLY.The fix — deleting the
WINDOWkey from~/.claude/settings.json— was correct. It was then reported as fixed while the bug was still live, because an env var cannot be unset in a running process. The user hit the same bug again and reasonably read it as a regression.Two distinct process defects, both generalizable beyond autocompact.
Defect 1 — "fixed" was allowed to mean "edited"
The verification performed was "the key is gone from settings.json". The verification that mattered was:
Three seconds. It was only run after the user came back and asked.
Checking the config file and claiming it proves the process state is the vacuous-guard defect class — a check that appears to verify X and actually verifies Y. That is precisely what #513 exists to catch in this repo's tests. It shipped inside the workflow that was building the detector.
Proposed rule (
/sdlc, Test Failure Recovery or a new short section): before reporting a fix, name the observable that would differ if it were NOT fixed, and go look at that observable. Edited a settings file → read the live process env. Changed a hook → fire it. Changed a threshold → measure it against the real files rather than restating the number. If the only evidence is "I made the edit", the state is submitted, not fixed.This is cheap, universal, and consumer-relevant — it is not autocompact-specific.
Defect 2 — config/env changes are a review-invisible class
The maintainer asked why neither Fable nor Codex caught it. Neither was ever asked. The change lived in
~/.claude/settings.json: outside the repo, so no diff, nohandoff.json, no PR, no review surface at all. Both reviewers only ever see what they are handed.The knowledge was nevertheless already on disk in this repo:
.reviews/codex-autocompact-verdict.md(PR docs(ai-setup-lanes): Opus 5 becomes Setup A default, Sonnet 5 moves to Setup B #468, 2026-07-24) quotes the official docs stating thatPCT_OVERRIDEonly applies proactively whenCLAUDE_CODE_AUTO_COMPACT_WINDOWis set — i.e. the multiplication, already reviewed and recorded.claude --resumeas the real fix.So this was not a reviewer capability gap. It was a failure to consult an existing review artifact before making an out-of-repo change that no gate covers.
Proposed rule: when a change lands outside the repo (global
settings.json, env vars, shell rc,launchctl), it receives no automatic gate. Therefore: read the existing.reviews/artifacts and memory on that subject BEFORE editing, and state the verification command in the same breath as the change.Scope note
skills/sdlc/SKILL.mdis at 19,356 of its 20,000-byte ceiling, so any addition needs an equal-or-greater trim in the same edit. It is also on the merge denylist, so this cannot ride along on #513 and needs its own PR.Cross-refs
.claude/settings.jsonand what the wizard ships)