Rule 17: What the Contract can't hold
The Contract keeps what the software must do. A regenerated component also needs to know which approaches the team already tried and ruled out.
I agree with Rule 17. If an agent can rebuild a component from the Contract in an afternoon, a component that has rotted is no longer a sunk cost. You delete it and regenerate it. "Born at ZAR" shows this working, and I think most teams will end up there.
My pushback is about what survives the regeneration.
The Contract holds the what. Teams learn the how.
The Contract describes what the software must do, and keeps that executable. Regeneration holds up because anything in the Contract will still be true of the new code.
A lot of what a team learns isn't in the Contract, though, and can't be. It's knowledge about how, and it usually arrives as a negative:
- "We tried caching this lookup and it served stale prices."
- "Never drop a column in the same deploy that stops writing it."
- "Don't call the payment provider from the request path; we did, and a slow provider took the checkout down with it."
None of these is a behavior the Contract can test. The software behaved correctly in every case. Each one was an operational failure: a deploy order, a latency spike, a cache that was right most of the time. So the tests stay green when a regenerated component brings the old approach back, because the tests never knew about it.
With a human rewriting the code, this knowledge often survives anyway, because someone remembers. With an agent regenerating from the Contract, nobody remembers unless the knowledge is written down where the agent reads it. Without that, every regeneration is free to repeat a mistake the team has already paid for.
The extension: a second artifact, next to the Contract
I'd add one thing to Rule 17. Keep a short log of rejected approaches next to the Contract. Each entry gets three things:
- What was tried, or what must not be done. One sentence.
- Why. The failure it caused, or the reason it was ruled out. Without the reason, the next person or agent can't tell whether the rule still applies.
- Scope. The paths or components it applies to. A rule about the billing module shouldn't fill the context of an agent working on the docs site.
The regenerating agent reads the entries scoped to the code it's about to rebuild before it writes anything. The Contract says what the new component must do. The log says which ways of doing it the team has already ruled out.
The log should stay small and specific. It's not a style guide or a list of preferences. An entry earns its place by recording something that broke, or a decision someone made on purpose with a reason they can state.
Most teams already have this knowledge. It's scattered across review comments ("please don't do this, we use X"), post-mortems, ADRs and a few people's heads. Writing it down is mostly a matter of collecting it, plus the habit of adding an entry whenever a review or an incident produces a new "don't".
The same gap shows up in Rule 27
Rule 27 says blast radius decides how much human review a change gets. I agree, and I'd measure blast radius in two ways.
The usual way is the call graph: how many things depend on the code that changed. That's a good gate, but static call graphs miss callers bound through interfaces, dependency injection or dynamic dispatch. When we checked a call-graph tool against the TypeScript compiler's own references on our codebase, it reported zero callers for functions that had several. An empty caller list should mean "unknown", not "safe".
The second way is the log above. "This change touches an area where the team made a hard call before" is often a better signal for human review than call-graph size. A one-line change to a retry policy that the team argued about for a week deserves a human. A 400-line change to an isolated, well-tested formatter may not.
Where this leaves Rule 17
Keep it regenerable, and keep the reasons regenerable too. The Contract lets you throw away the code without losing what the software does. The log of rejected approaches lets you throw it away without losing what the team learned while building it.
I'd be curious whether ZAR ran into this when regenerating components, or whether the Contract was detailed enough that it never came up.