Keep product requirements current while the work is changing
Track requirement changes so teammates and AI assistants can distinguish current scope, superseded decisions and unresolved proposals.
A product requirement often changes after work starts. The risk is not the change itself. It is that one person works from the new decision while another person, or an AI coding assistant, keeps following the original brief.
Give the project a clear current version and a visible change history.
Record the change in one place
For each material change, capture what changed, why, who approved it and which work it affects. Link to the updated acceptance criteria. Keep proposed changes separate from approved changes until the responsible owner decides.
A useful entry might say: “Invitations now expire after the period in the current security policy. Update the email copy and the expiry-state tests.” It should point to the actual approved rule rather than create a competing copy of it.
Update downstream tasks
Changing the top-level document is only half the job. Find the tickets, briefs and active agent tasks that rely on the old requirement. Notify their owners or update their context before they continue dependent work.
For an agent already running, check what it has completed before redirecting it. Some work may still be useful; other work may need review against the revised criteria.
Review against current acceptance criteria
At delivery, verify which requirements version the implementation follows. Preserve the earlier version for historical explanation, but label it as superseded and link to the replacement.
The change log should explain the project's movement without forcing a reviewer to reconstruct every conversation. If nobody can identify the current requirement quickly, the team has a coordination problem that more detailed task descriptions will not solve.