agent updated the wrong snapshot file in a monorepo: how to scope
Scopes snapshot updates to the package that actually changed so a healing agent cannot rewrite snapshots across a monorepo. Use when an agent's healing pass updates snapshot files far from the failing test. Not for intentional cross-package snapshot regeneration after a shared dependency changes, which is a planned migration with review.
TL;DR
In a monorepo, an agent healing one package's tests should never touch another package's snapshots. Scope every snapshot update to the failing test's own package: the snapshot path must live under the same package directory as the test. Cross-package snapshot writes get rejected, and intentional cross-package regeneration goes through a planned migration, not the healing lane.
Error
agent updated the wrong snapshot file in a monorepo: how to scopeA healing run for package A's tests rewrote snapshots in package B, hiding a real breakage behind "updated" snapshots.
Steps
- Find the blast radius: list every snapshot file the agent's patch touched and map each to its package. Expected output: a package-by-package list of touched snapshots.
- Revert any snapshot change outside the failing test's package; those updates were never validated. Expected output: cross-package snapshots restored to their committed state.
- Add the scoping rule to the healing config: a snapshot write is allowed only under the same package root as the failing test file. Expected output: an enforced path rule.
- Require the agent to state the package scope of its patch before running tests. Expected output: a declared scope the linter can check.
- Re-run the healing task and confirm the patch touches only the intended package. Expected output: a contained diff with no cross-package snapshot changes.
When to use
- Healing patches touch snapshot files in packages unrelated to the failure.
- You run healing agents across a monorepo with shared snapshot dirs.
- A "fixed" suite hides breakage behind bulk snapshot updates.
When not to use
- A shared dependency changed and snapshots across packages legitimately need regeneration (planned migration, human-reviewed, full suite run).
- The repo is a single package; there is no cross-package scope to enforce.
- Snapshots are per-test and colocated; the scoping rule is then trivially satisfied.
Variant phrasings
Agent ran snapshot update with -u across the whole repo
A global -u is a bulk bless. Scope the update flag to the failing test files only.
Shared snapshot directory confused the agent
If snapshots live in one shared dir, add a package-prefix naming rule so the scoping check has something to match on.
Agent updated snapshots to match buggy output
Snapshots encode intent; updating them to match a bug cements the bug. Require a human or a spec check on any snapshot content change, not just the path.
Why it happens
Snapshot update flags are repo-wide by default, and the agent does not know your monorepo boundaries. It sees failing snapshots, runs the update, and blesses everything that changed, including breakage in packages it was never asked to look at. The scope has to be declared and enforced, because the tooling default is "update all".
Edge cases
- Genuinely shared components render into many packages' snapshots; those need an explicit allowlist of affected packages per migration.
- Snapshot files with hashed names defeat path-based scoping; keep a manifest mapping snapshots to packages.
- The agent can dodge the rule by editing the snapshot content via the test code; the content check (does the new snapshot match intended behavior) still needs a human for semantic changes.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_ikSm2PFXF02HICVicpeOAw