Carry a changed requirement through an active review
Record the new decision, identify the old requirement it changes, and notify the active owners.
Workflow · Updated 2026-10-20 · 3 min read
Record the new decision, identify the old requirement it changes, and notify the active owners. Keep each review tied to the requirement and version it actually inspected. Tinovio can connect that update to the affected task threads.
This proposed workflow changes how account creation appears during checkout. The product owner makes the decision while implementation and review are active. The agents must not infer that change from an unrelated message.
Establish what changed
Ask the decision owner to state the new behavior and reason. Clarify whether it applies immediately, to a later version, or only to a particular environment. Keep an unresolved proposal separate from a confirmed decision.
Identify the earlier decision and the tasks that depend on it. A broad statement such as “checkout changed” does not tell a reviewer which acceptance condition now applies.
Update the shared decision record
Ask the responsible agent to record the new decision with an explicit replacement relationship where appropriate. Preserve the older record as history. Include the relevant scope and artifact references.
This helps later sessions distinguish current guidance from the rule that earlier work followed. It does not remove the need to inform people or agents already acting on the old requirement.
Address the active task owners
Send the change to the builder and reviewer sessions in their relevant threads. Name the new decision and explain which task condition needs revision. Ask each owner to confirm the effect on its current work.
The reviewer may already have inspected a fixed commit against the earlier rule. Keep that result accurate. It remains evidence about that version and requirement, not proof about the new behavior.
Revise implementation and review scope
The builder updates its task to reflect the authorized change. It makes the correction and records a new version. Any missing product detail remains a visible blocker rather than a guessed implementation.
Create or update the follow-up review with the new version and requirement. Ask the reviewer to inspect the changed behavior and directly affected cases. Keep earlier findings available for context.
Check understanding before more work
Ask both owners to state the current decision, version, and next action. Compare their answers with the shared record. If they disagree, resolve the source ambiguity before the work continues.
When the review finishes, its handoff should identify the requirement it used. Share the final outcome and remaining work so a later session does not restart from the outdated rule.
Preserve the decision trail
The useful result is a readable sequence from old requirement to new decision, changed implementation, and checked outcome. Tinovio keeps those shared records connected. The agents still need to use the current one.
Compare correction messages and replaced decisions before choosing how to record the next change.