A Playwright aria snapshot fails after you intentionally rename the Export button; how do you get it green without weakening the check?

## First, read the failure A failed `toMatchAriaSnapshot` prints a diff between the template you stored and the tree the page produced, in the same YAML you wrote. That diff is the entire triage step, and it is worth reading line by line before touching anything: ``` - - button "Export CSV" + - button "Download statement" ``` Two lines is a clean, intended rename. Ten changed lines after a one-word rename is a different story, and it means the change did more than the ticket said. ## Regenerating the expectation Once the diff is understood, re-run the affected test with `--update-snapshots`, abbreviated `-u`. Playwright regenerates the expectation from the page's current accessibility tree: for a file-backed snapshot it rewrites the `.yml` under the test file's snapshot directory, and for an inline template it produces the updated template for the test source. ```bash npx playwright test tests/statement.spec.ts --update-snapshots ``` Scope matters. Running the flag over the whole suite regenerates every template that currently fails, which is exactly how an unrelated regression gets blessed on a busy branch. Run it for the spec, or the project, that your change touches. ## Review the regenerated template as code The regenerated YAML is text, so it lands in the pull request as ordinary added and removed lines. Use that: - Check that every removed line corresponds to something you meant to change. - Look hardest at *disappearances*. A rename shows a minus and a plus; a lost heading or a dropped region shows only a minus, and that is the shape of a real regression. - Check heading levels and states, `[level=1]`, `[disabled]`, `[checked]`, which change silently and read as noise if you are skimming. - Ask whether the new template is still as tight as it was, rather than having absorbed volatile content the old one had deliberately relaxed into a regex. ## When updating is the wrong move 1. **The change was not intended.** The correct fix is in the application, not in the expectation. 2. **The template is flapping**, changing on runs where nothing changed. That is a stability problem, solved by scoping the locator tighter or relaxing volatile values into regular expressions, not by repeated regeneration. 3. **You cannot explain the diff.** Regenerating an expectation you do not understand converts an assertion into a record of whatever the page happened to do. ## A workflow that holds up 1. Reproduce the failure locally and read the YAML diff. 2. Decide, per changed line, intended or regression. 3. If intended, regenerate with `-u` scoped to that spec. 4. Re-run without the flag, so the updated template is proved green on its own. 5. Commit the template change together with the application change, so a reviewer sees the rename and its expectation in one diff. ## Why this discipline is the whole value Deleting the assertion, or loosening it until nothing can fail, removes the only check that noticed the export button's label at all. The structural snapshot earns its keep precisely because it fails on renames, so the answer to a rename is to record the new name deliberately, not to stop looking.