The distinction between requirements and evidence is the part I find most useful. A spec can tell an agent what to build, but it doesn't prove it built the right thing. For production tasks I want acceptance criteria tied to repeatable checks, and open decisions to be explicit rather than silently inferred.
Dmitry Yurkin
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.