Defensive rules pile up
Cautious rules can quietly add up to an assistant that asks before every step. The fix is to rewrite the default, not to add another rule.
The headline
Defensive feedback rules can quietly become a spoon-feeding default. The memory chapter gains a new failure mode covering the pattern, and a process for catching it: when new feedback rules start reading as carve-outs from a default that has grown too cautious, rewrite the default rather than stacking another carve-out on top.
Why
This played out in a real session this week. Over several months, the memory store had accumulated dozens of feedback rules. Each one was individually reasonable, and almost all of them were phrased negatively: never do this, stop doing that, verify the other before reporting done. On top of them sat the standing default: report and read only, and only write, create or delete when explicitly asked.
The cumulative effect was a session that, on every turn, was checking dozens of fences before acting. Carve-outs had started to appear, rules saying explicitly that for a particular project the assistant should commit without asking. That is the signal: the default itself had become the bug. Each carve-out is a half-admission that the default is too cautious, but the default keeps shipping, because nobody rewrites it. They just add another exception.
The fix, applied in the same session, was to rewrite the default. It went from report and read only, to solve the problem when authorised, and ask only when a step is destructive, undecided, or touches shared infrastructure. Then a handful of the most stale or duplicated feedback rules were archived. The change in behaviour was immediate, and noticeable inside a single turn.
What changed in the guide
Chapter 2, on memory, gains a fifth failure mode, called the defensive-rule pileup. It names the pattern, gives the symptom to watch for, which is the carve-out, and prescribes the response: rewrite the default, audit every quarter, retire the obvious rules, and merge the near-duplicates.
The existing four failure modes, which are saving things the codebase already knows, stale current-state memory, index bloat, and two entries saying nearly the same thing, are all about storing the wrong things. This new one is about storing the right things in a way that compounds badly.
Nothing else moved. This is a single-chapter addition. The pillar order, the audience, the format and the weekly update model are all unchanged. If you read the guide last week, you only need to read the new failure mode in chapter two.
How to spot it in your own setup
There are three signals, and any one of them warrants an audit.
One: you’re writing feedback rules faster than you’re retiring them. The store only ever grows. Healthy stores prune.
Two: new feedback rules contradict the standing default. A rule that says “for this, do that without asking” is the carve-out shape. It is saying the default is wrong for that case. If three or four rules do the same, the default is wrong for more than that one case.
Three: the assistant asks before acting on things you have already authorised. That is the symptom you see. The cause is in the feedback rules.
When two or three of these light up, sit down with the memory store for an hour, retire what is stale, merge what overlaps, and rewrite the default itself.
The cards
