An audit trail that recorded nothing that mattered
The audit loop walked only top-level DTO keys while every real setting lived inside two JSON blobs, both on the audit's exclusion list.
The safety net had a hole
The test, the audit log, the scanner, the CI run — covering less than I assumed it did.
Three bugs in one feature, found by toggling a single notification preference through the UI and reading the table.
The audit's exclusion list contained the two JSON blobs, and the audit loop only walked top-level DTO keys — but every field on every settings tab lives inside those two blobs. So it faithfully recorded the handful of fields nobody changes and ignored everything else. On top of that, a file-size setting compared a Prisma BigInt against a DTO number, JSON.stringify throws on BigInt, and the catch returned "changed", so every save logged two phantom rows. And the audit-log endpoint ignored tenancy entirely, which I proved with an organisation-admin token reading every row, including other organisations' and platform-wide ones.
An audit feature that runs and writes rows and audits the wrong things is worse than none, because it produces a document people will trust.