The reported issue
The exact expired-link screen, steps to reproduce, and expected recovery path.
Teams / Software teams
Ship a fix
with evidence.
A worked example: recover an expired password-reset link without leaving the user at a dead end. Give the change, its checks, and the release decision separate owners.
Example workflow. Connections and live agent execution are planned.
Before assigning the task
Give the team these inputs.
The code and product rules
The relevant repository files, test commands, and current reset-token policy.
The boundary
Fix recovery only. Do not change token lifetime, authentication providers, or account permissions.
A brief you can adapt
One task. A defined result.
Task: Handle an expired password-reset link.
Deliver: Focused change + recovery-flow tests.
Done: Explain the expiry and offer a new reset request.
Escalate: Any proposed change to authentication policy.Owners and handoffs
Separate doing from reviewing.
Implementation owner
Reproduce the failure and prepare the smallest change that meets the brief.
QA reviewer
Check expired, valid, and already-used links against the current behavior.
Release owner · You
Review the diff and evidence; decide whether the change can merge and ship.
The working sequence
How the task moves forward.
Reproduce before changing the flow.
Record the current result for a valid, expired, and already-used token. Identify the existing request-reset route and the test coverage that should protect it.
Implement and hand over a focused change.
Reuse the existing reset-request flow. Attach the diff, commands run, results, and any untested paths. Keep tokens and account secrets out of logs and screenshots.
Review recovery and regression evidence.
QA checks the acceptance list and returns failures to the implementation owner. The release owner reviews the final diff and approves the merge and deployment separately.
The handoff
Ask for these artifacts.
- change-summary.md — Affected files, behavior before and after, and remaining risks.
- verification.md — The command and result for each check, plus recovery-flow screenshots.
- The proposed diff — A focused change, with unrelated cleanup left out.
Example acceptance criteria
Check the result against the brief.
- An expired link explains the problem and offers a usable reset-request path.
- A valid link still works; an already-used link does not become reusable.
- Checks cover recovery and existing happy paths, or explicitly identify any gap.
- No reset token, credential, or private account detail appears in attached evidence.
The human decision
Review the work before acting.
The human release owner checks the diff and verification report before authorizing merge or production deployment. A change to expiry rules or account permissions returns to the brief for a new decision.
Put it in your plan
Use this as your first milestone.
Start with a builder and a reviewer. In setup, use “Fix expired reset-link recovery” as the first milestone and add the authentication-policy boundary to the mission.