Why this exists

The things you wrote get reviewed. The things you didn't never get reviewed at all. That's where the bugs hide — not in the function someone argued about in a PR, but in the function nobody noticed wasn't written. Code review is a spotlight. The negative-space audit is what you do when you finally turn the lights on.

What you get back

  • A ranked list of absences — files, tests, configs, endpoints, hooks, and observability that the shape of the codebase implies should exist.
  • Why each absence matters — the failure mode it opens up, the assumption it leaves unchecked, the on-call ticket it eventually becomes.
  • A triage by likelihood-to-bite — what's most likely to fail first in production, sorted ahead of the merely theoretical.
  • Small starter PRs for the top three gaps — concrete, scoped, mergeable patches you can hand to a human or an agent today.

When to reach for this pattern

Pre-launch hardening, when "done" needs a second opinion. Due diligence on inherited code, when you're about to own something you didn't build. Security review of an unfamiliar codebase, where the missing auth check is more dangerous than the present one. And right before anyone declares a project "done" — because "done" is the moment the holes stop being fixable cheaply.