Distill the Rule

Findings are perishable; rules compound. A debugging session that ends with "fixed it" has produced one repaired instance. The same session ending with "any suffix/subset helper needs its empty case decided explicitly" has produced a check that prevents the whole class — in every future codebase, forever, for the cost of one sentence. Distillation is the deliberate last step of any surprising piece of work: strip the finding's specifics down to the transferable mechanism, phrase it as a one-line rule with its trigger, and file it where future work will actually meet it.

This is how individual experience becomes leverage — and for an agent with persistent memory, it is the difference between having sessions and having judgment.

What qualifies

Three properties, all required — they filter out both noise and diary entries:

1. Surprise. Your prior was wrong: the code did something you didn't predict, the test was blind where you trusted it, the tool lied. No surprise → the rule already existed in your head; writing it down again adds nothing.
2. Cost. The finding took real time, a real bug, or a real incident to acquire. Cost is the evidence that the rule wasn't obvious.
3. Recurrence shape. The mechanism — not the instance — will appear again. "This function had an off-by-one" has no shape; "boundary semantics of helpers get inherited from the implementation instead of decided" does.

The distillation move

Strip every specific that doesn't carry the mechanism — file names, project names, the particular types — and keep exactly what transfers: