Before/after change verification — high-level pointers (local fallback)

snapatu tells you what moved between two snapshots of a live page. The detailed, current change-verification standards — when a REVIEW is acceptable to ship vs. needs a rollback, how to handle a flaky third-party link check, and the ticket-attachment convention for a verified change — live in the team wiki (set OUTLINE + OUTLINE_API_URL and the report links them directly). This file is the minimal high-level fallback for when the wiki isn’t configured: direction only, deliberately not step-by-step, so there’s no detailed content to drift out of sync with the wiki.

• FAIL means worse than before — an error status, a new redirect, or a newly broken link; treat it as a stop, not a note, and roll back or fix before closing the ticket.
• REVIEW is the expected result of an intentional edit — read the diff, confirm it matches the change you made, and don’t chase it to PASS by re-running until the noise clears.
• New JS errors are flagged, not failed — third-party scripts (ads, analytics, chat) come and go on their own; check whether the error is from the edit or from a script you don’t control.
• A blocked re-capture (403/429) is not a page fault — retry from a different network or pass a WAF-skip header before concluding the change broke something.
• Dynamic content produces honest noise — a rotating testimonial or a live date will always show as a copy change; that’s the page working as designed, not a defect.
• --ignore-nondeterministic-requests — use it when a no-edit reload still reports new failed requests, so the request-diff doesn’t drown out the copy diff that actually matters.
• snapatu records, it doesn’t roll back — pair the “before” snapshot with your own rollback procedure (a saved revision, a git commit) before making the change, not after.

Full playbook → the team wiki’s before/after change-verification standards.