The rule said: an admin granted in /<dir>/.zddc can edit deeper
.zddc files but NOT the one that grants their own authority.
Intended to prevent self-elevation, peer-addition, and delegator-
removal.
Three problems:
- "Add peers" isn't an attack — it's the common collaboration case.
Project creator can't grant a teammate access without bothering a
super-admin every time.
- "Remove the delegator" doesn't work. Root admin authority lives
in the ROOT .zddc and cascades down regardless of what's in
/<dir>/.zddc; subtree admins can't touch it.
- "Self-elevation" within a subtree is meaningless. They already
have rwcda there.
Replacement model: admins in /<dir>/.zddc OWN /<dir>/ and everything
beneath, including the .zddc itself. They can add collaborators,
modify ACLs, even remove themselves. Self-removal is a recoverable
footgun — root super-admins always retain authority via the root
cascade and can restore.
What stays:
- The admins: field as a load-bearing key (drives IsActiveAdmin
+ sudo-style elevation + WORM bypass).
- Bootstrap via root .zddc hand-editing.
- IsAdminForChain(chain, email, excludeLeaf bool) signature —
ModeStrict / NIST AC-6 deployments can still opt into the strict-
ancestor walk if they need it.
Tests flipped to match the new contract; ProjectCreate flow now
gives the creator real control over their project root.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ZDDC
df19a63853