One investigator per shard
When several CI shards fail at once, the instinct is to debug them one by one. Fan out instead: one investigator per shard, in parallel, then synthesise.
A CI run comes back red across five Playwright shards. The slow way is to open the first failure, fix it, push, wait, and repeat. By the time you reach shard five you have forgotten what shard one looked like.
Fan out, then synthesise
Treat each failing shard as an independent investigation. Give each one a focused question: what failed, is it reproducible locally, and what is the root cause. Run them at the same time. Only once every shard has a diagnosis do you decide what to actually change.
This matters because failures cluster. Three of the five shards usually share one cause - a flaky selector, a shared fixture, a timeout that is too tight. You see the cluster only when you read all five findings side by side. Fixing them one at a time hides the pattern.
The trap: duplicate test data
The recurring miss in this workflow is the sibling instance. You fix a selector or a test-data file in one place, declare the pattern handled, and move on - while an identical copy sits two directories over. Before calling any pattern-based fix done, grep the whole repository for siblings.
Verify before you claim
An investigator that reports "fixed" has told you what it intended, not what it did. Read the diff. Re-run the shard. Evidence before assertions, every time.