## TL;DR
The two tests are coupled through shared database state, so fixing one test's data setup broke the other's assumptions. Give each test its own isolated data (per-test transaction rolled back at teardown, or a fresh schema per test), make setup and teardown mirror each other, and re-run both tests together until the coupling is gone.

## The exact query
```text
agent's fix for one flaky test introduced a new flake in a test that shares the same database
```

## Steps
1. Confirm the coupling: run test B alone (it passes), run test A alone (it passes), run them together in CI order (B flakes). Then run them together with test A's new fixture reverted (B passes again). The agent's change to shared data is the coupling point.
   Expected: You have proven the flake lives in the interaction between the two tests' data, not in either test alone.
2. Find the exact shared state: what rows, sequences, or tables does test A's setup now create, modify, or leave behind that test B reads? Check for leftover rows, bumped auto-increment sequences, changed enum values, or deleted seed data.
   Expected: A named piece of shared state, for example "test A's new setup deletes the default tenant row that test B's login flow needs".
3. Isolate the tests: wrap each test in its own transaction and roll it back at teardown, or give each test a fresh schema (or database) created at setup and dropped at teardown. No test may commit data that another test can see.
   Expected: Test A and test B each see a pristine database. Running them in any order, together or apart, gives the same result.
4. Make setup and teardown symmetric: every row the setup creates, the teardown removes; every sequence it bumps, it resets. Audit the agent's fix for setup steps with no matching teardown.
   Expected: After either test runs, the database looks exactly as it did before. No residue leaks into the next test.
5. Re-run the pair together, then the whole file, then the suite: the original flake in test A must stay fixed and test B must be stable across repeated runs and both orderings.
   Expected: A green, B green, together green, in either order, repeatedly. The agent's fix survives contact with its neighbor.

## Use this when
- Fixing test A made test B flaky and both share a database
- Tests pass alone but flake together
- An agent's fixture change altered seed data another test depends on
- Teardown is missing or asymmetric after an agent's edit

## Not for this skill when
- The tests use fully isolated databases or transactions already (then the coupling is elsewhere: look at files, ports, or env vars)
- The breakage came from a production code change, not test-data coupling
- Test B was already flaky before the agent touched test A (pre-existing flake, different investigation)

## Variant phrasings
### one test's setup breaks another test's data
Same coupling. Isolate with transactions or fresh schemas.

### tests pass in isolation but fail together with shared DB
Classic shared-state coupling. The fix is isolation, not ordering the tests "correctly".

### agent fixed a flaky test and created a new flaky test
Review the agent's diff for shared-state changes first. That is where the new flake was born.

## Why it happens
The agent fixed test A by changing the data it sets up, and never checked what test B assumes about that data. Shared databases make tests secretly dependent: B passes only because A's old setup left the rows B needs, or A and B both write to the same table and whoever runs second sees the other's residue. The agent optimized one test in isolation and the coupling turned the fix into a new flake.

## Edge cases
- Auto-increment sequences and timestamps leak even when rows are deleted. If B asserts on specific ids or ordering, reset sequences in teardown too.
- Parallel test runners (xdist) sharing one database need stronger isolation: separate schemas per worker, not just per-test transactions, because transactions do not isolate across connections the way you expect.
- Some teams "fix" this by forcing test order. That hides the coupling and makes it worse over time. Isolation is the fix; ordering is the bandage.
- If the shared state is created by migrations or a global seed script rather than test setup, the isolation point is the seed script: make it re-runnable and resettable, or scope it per test.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HNqBM3O3kWXjSJYI-TactQ