Before you start
This guide follows DD-142 · Handle expired checkout sessions in Atlas Commerce. It is the connected example used across the work-item, run and review screens.
- Read the acceptance criteria, not only the task title.
- Check that the run and evidence belong to the same work item.
- Keep credentials and customer data out of review notes.
1. Check the brief
Open the Brief tab and establish what the change should achieve. For DD-142, the customer must be able to recover from an expired payment session without losing their basket.
Compare the proposed work with the acceptance criteria and constraints. A successful test result is not evidence that an unrelated change belongs in the task.
Review question
Does the change preserve the basket and give the customer a clear way to restart payment?
2. Inspect the run
Open Run #084. Read the execution stages, verification summary and available output before opening the review.
- Scope
- The work-item identifier and project should match the brief you are reviewing.
- Evidence
- Check what was verified and any remaining notes. A green status is a starting point, not a substitute for reading the result.
- Changed files
- On the Review tab, inspect the recovery logic, tests and payment-form changes. The displayed diff is an illustrative excerpt, not the complete implementation.
3. Record a decision
Open the Review tab. The example includes a non-blocking copy note: “Try again” could become “Restart payment”. Decide whether that needs a change before approval.
Approve in preview
Choose this when the proposed change meets the brief and you accept any remaining notes.
Request changes in preview
Choose this when a concrete correction is needed. Add a review note explaining what to change and how to verify it; the note is required for this outcome.
Example review note
Rename the retry action to “Restart payment”. Confirm that the basket remains intact and keyboard focus reaches the recovery action.
Submit the decision and read the confirmation. The preview changes only this page; it does not update a repository, send a message or persist after reload.
Open example reviewTroubleshooting
Why does requesting changes need a note?
A request needs an actionable correction. The example form marks an empty review note invalid and moves focus to it. Add the expected change, then submit again.
Why did my decision disappear after reloading?
Review decisions are temporary demo state. Reloading restores the example. Saving decisions, enforcing permissions and notifying collaborators require your own application backend.
Can I open every queue item as a full workflow?
DD-142 has the connected Brief, Run and Review screens. Other queue entries demonstrate list and inspector states; they do not each have a separate workflow page.
What should I include when asking for help?
Include the page, the work-item identifier, the action you tried and what appeared instead. Use fictional or redacted details; do not share API keys, private repository content or personal data.
Next steps
Return to the review inbox to inspect another item, or try the support-request form with fictional details.
Building with the theme? View theme documentation for setup, customization and integration guidance.