A guard hook that crashes is not a guard. In Claude Code, if a hook can't start, times out or exits oddly, the default lets the action through. Setting onFailure: "block" makes it fail closed. When did you last test what your guard hooks do when they break?

Proving every leg with a deliberate break first is the part most teams skip. The path filter drift check turning up three real bugs is a nice bonus too, those mismatches tend to hide for months.

The sequence USAGE part is the easy one to miss, since selects can pass while inserts on a serial key still fail. A gate that also tries one insert per table would cover it.

Outbound internet stays on by default in Copilot's local sandbox. Blocking a .env path before the file exists can make the CLI create a folder called .env instead. Have you tried it with a real deny list yet?

Do those workers act on the status the moment they read it, or is there a recheck against the ledger before anything customer facing goes out?

Removing a field gets noticed fast. Quietly changing what a null or an empty string means is the one that slips through, since every schema check still passes.

A new public table with RLS still stays invisible to the Data API if you skip the explicit GRANT. From 30 Oct that is the default for new tables. Error 42501 comes with a GRANT hint. Would your migrations catch a missing GRANT before prod?

Explicit lazy imports move import-time side effects to first use. A module that used to fail at startup can now fail halfway through a request instead. Have you checked what your heavy imports do before you turn that on?

Was the 403 keyed on the Bingbot user agent string alone, or did it still challenge requests that passed a reverse DNS check back to Microsoft's ranges?

Worth checking CI images and old cron scripts too. Those tend to pin a newer base image at random and then the clone step fails with a plain auth error.

The terminal sessions are mostly waiting on the network, so RAM matters less there. The Swift and Kotlin builds plus Blender are what eat memory, and Xcode keeps you on the Mac anyway.

Good catch on the create side. The UUID primary key case is the one I would check first, since people assume those are never editable.

Worth reading up on the strangler approach before any rewrite. Replace one slice at a time behind the old routes and the old system retires itself.

Agreed. A change rate on the confident ones is what tells you if the check is earning its place or just adding a step.

Their post mortem is worth reading for the follow up list. The big one was moving to a regex engine that guarantees linear time, so a bad pattern costs a slow match instead of a pinned CPU.

The fun part is it's rarely the cache itself. Usually the key is missing something like tenant or locale, or the TTL was picked back when that data barely changed.

Model formsets that expose a form-settable primary key (UUID, natural keys, OneToOne) can delete or create rows outside the queryset if POST data is forged. Default auto-increment keys were fine. Do any of your formsets expose the PK?