DY
I'd scope the spec to the behavior being changed and the contracts it must preserve. In your caching example, a rule such as "reads may be 30 seconds stale, but a successful write invalidates the entry" gives the agent a boundary while leaving implementation choices open. Decisions that change those boundaries need review and a corresponding specification update. In Reqode, we've made the change itself the handoff: a Change Request groups affected specification revisions, and the coding agent retrieves the relevant context through MCP. The task can stay short because it points to the agreed specifications.