The Contract Maintenance Agent

A contract that was accurate on the day it was written can go stale without anyone deciding to let it. Code gets patched, an edge case gets handled, a guarantee quietly stops holding, and the contract sitting next to all of that doesn't update itself. The contract maintenance agent's job is to find that drift: betweencontract.yaml, the current code and tests, the generated siblings contract.json andcontract.md, and any other repo-level artifact that changed the capability's context. It's specifically watching for stale assumptions sitting in constraint_history, behavior that's been added but never captured, and guarantees the implementation no longer actually meets.

It works in a fixed sequence: identify the capability path and readcontract.yaml first, before looking at anything else. Compare that contract against the current code, tests, and docs that shape how the capability behaves. Flag any missing contract updates before suggesting implementation changes, because fixing the code first and the contract later is exactly the order that lets drift compound. If contract.yaml changes, it requires contract.json and contract.md to be re-synced before the work counts as finished, and it tells the practitioner to run cdad validate <path>afterward, plus cdad validate --all --strict before merge whenever the repository holds more than one contract.

The part of this prompt that does the most practical work is its versioning rule. When a contract is outdated, it names the exact field that needs revision and the version bump that fits it:PATCH for clarifications or documentation-only corrections that don't change runtime expectations,MINOR for backward-compatible additions like a new optional input, output, or constraint, and MAJOR for removed guarantees, breaking behavioral changes, stricter requirements, or dependency shifts that could break whatever depends on this capability. That's a meaningfully harder judgment than most changelog conventions ask for, because it requires actually understanding what the contract promised before deciding how badly a change breaks that promise.

Its output always follows the same shape: the drift findings first, then the exact contract fields that must change, then the version bump recommendation, then the specific validation command the practitioner should run next. Nothing here is left as a vague "you might want to update this."

This is the maintenance layer that keeps the rest of the model honest over time. A capability that scored well on its legibility audit the day it was contracted can quietly slide backward if nobody's watching for drift, which is a large part of whycdad check is meant to run again and again. The contract maintenance agent is what closes that loop between one check and the next, before the gap gets big enough to matter.