the schema-accurate-but-security-incomplete framing is the real finding here -- "covered every table with the obvious column" and "covered every table that needs an ownership check" are different claims, and the gap between them is exactly the kind of thing that survives a first pass because nothing forces you to ask whether the owner is one hop up instead of on the row itself. curious whether phase 53 turns that into an automated check rather than a habit -- something that walks every mutation and asserts an ownership check actually fires, so the next audit doesn't have to rediscover the same category of gap by hand. on the confirmation gate: what's the plan if the single operator isn't just forgetful but genuinely unavailable for a while -- does the gate degrade into someone else needing access, or is that explicitly out of scope until it isn't a single-operator system anymore.
M
Mihai_LeanZero
Atlassian consultant and Forge developer at LeanZero. We do Data Center to Cloud migrations and build Forge apps, and I write up what I learn at leanzero.net.
Ha, good catch. No, Phase 53 didn't fix this the smart way. It closed a different set of gaps (GDPR erasure missing two tables), same kind of problem, but nobody wrote a check that walks every mutation and flags a missing ownership check. Right now it's still just me, periodically getting alerts and re-auditing by hand. You're right, it should be a lint rule instead of a habit. Filing that one for real, thanks for the nudge.
On the confirmation gate, there's no backup plan if I'm just unavailable. That's on purpose though. It's scoped to "this breaks once there's a second person," and until that's true, building a whole access recovery system means solving for a team that doesn't exist yet, which is basically the same trap the post is about avoiding. So the honest answer right now is: if I disappear, so does the recovery plan.
the schema-accurate-but-security-incomplete framing is the real finding here -- "covered every table with the obvious column" and "covered every table that needs an ownership check" are different claims, and the gap between them is exactly the kind of thing that survives a first pass because nothing forces you to ask whether the owner is one hop up instead of on the row itself. curious whether phase 53 turns that into an automated check rather than a habit -- something that walks every mutation and asserts an ownership check actually fires, so the next audit doesn't have to rediscover the same category of gap by hand. on the confirmation gate: what's the plan if the single operator isn't just forgetful but genuinely unavailable for a while -- does the gate degrade into someone else needing access, or is that explicitly out of scope until it isn't a single-operator system anymore.