the agent said "snapshot drift" but the snapshot was correct - the component had actually regressed

A snapshot mismatch is a question, not a diagnosis: either the snapshot is stale or the component broke. When the agent says drift, read the actual diff before believing it. If the stored snapshot still matches the design, the component regressed - fix the component and leave the snapshot alone.

the agent said "snapshot drift" but the snapshot was correct  -  the component had actually regressed

Steps

1. Open the actual snapshot diff - the rendered output versus the stored snapshot - and read what changed element by element, instead of trusting the agent's drift label.

   Expected: You can describe the concrete change: which element moved, disappeared, or changed text.

2. Check the stored snapshot against the design or spec, not against the current code. If the snapshot matches what the UI is supposed to look like, the snapshot is right and the code is wrong.

   Expected: You have a yes or no answer: the snapshot still represents the intended UI.

3. Find the code change that broke it: check recent commits touching the component and run the component's tests in isolation.

   Expected: You can name the commit or PR that introduced the regression.

4. Fix the component to restore the intended output, then rerun the test without updating the snapshot. It should go green with the original snapshot untouched.

   Expected: The test passes against the original snapshot, proving the snapshot was never the problem.

5. Tell the agent to treat snapshot mismatches as unclassified until it has compared the diff against the design. Add that rule to its triage checklist.

   Expected: The agent's next mismatch report says regression or stale snapshot with evidence, not just drift.

Use this when

• an agent says snapshot drift but the stored value looks correct
• a snapshot test fails and you suspect the component, not the snapshot
• reviewing an agent's proposal to update a snapshot

Not for this skill when

• the design intentionally changed and the snapshot is genuinely outdated
• the snapshot contains environment-specific values (see the timezone skill)
• the diff is unreadable image noise with no discernible element change

Variant phrasings

• agent called it snapshot drift but component regressed
• snapshot was correct, component broke, agent misdiagnosed
• how to tell snapshot drift from a real component regression

Why it happens

Agents learn a shortcut: snapshot mismatch usually means the snapshot is stale, so they label it drift and propose an update. That shortcut fails whenever the code actually broke, because the symptom is identical - a diff between stored and rendered output. The only way to tell the two apart is to judge the diff against the intended design. Skipping that judgment turns the snapshot from a regression alarm into a rubber stamp.

Edge cases

• For image snapshots, keep a reference render from the design tool next to the test so the comparison is one glance, not archaeology.
• If the same snapshot has been updated several times for drift, its stored value may itself be a baked-in regression; check its git history.
• Components with A/B variants need one snapshot per variant, or every experiment looks like drift.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_omFNUeaP1BdM6Zr5yzsNrg