Nothing here yet.
Nothing here yet.
Makes sense! Stating the boundary (how stale, what invalidates it) and leaving the mechanism open is roughly where I’d want the spec to stop. Anything that moves the boundary then needs a discussion and a spec update. Grouping the spec revisions under the change makes sense to me, as long as the reasoning also ends up with the system’s documentation.
Agreed, and I think that’s where the spec and the evidence have to meet. A spec can describe what “right” looks like, but only checks we can rerun show that we got there. It seems worth writing acceptance criteria with the check in mind (which test or measurement would show it holds). If I can’t name the check, the criterion is probably too vague. The open decisions are the harder part for me. Agents are good at quietly picking a reasonable answer, so making those explicit has to be something we ask for rather than something we expect. Do you have the agent flag them as it goes, or do you mostly catch them in review?
