amadan
spec: carlos db, record the service-principal 403 in §6
A dated revision note under 'Who may open it': the shared cliRoute closed-door 403 precedes any account lookup and reveals only that the door exists. Paul may overrule it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 file changed,
+13
−0
docs/superpowers/specs/2026-09-02-carlos-db-design.md+13 −0
CI passed — run details
diff --git a/docs/superpowers/specs/2026-09-02-carlos-db-design.md b/docs/superpowers/specs/2026-09-02-carlos-db-design.md| index 08856f2cf..0cae85745 100644 |
| --- a/docs/superpowers/specs/2026-09-02-carlos-db-design.md |
| +++ b/docs/superpowers/specs/2026-09-02-carlos-db-design.md |
| @@ -346,6 +346,19 @@ No legitimate caller loses anything — an app reads its own database |
| live, and CI has no business pulling production data. `admin` is refused |
| **deliberately**, despite already reaching `store grant`. |
| +> **Revision, 2026-10-01 (implementation; Paul may overrule).** Service |
| +> principals get a 403, not the 404 above. The two door routes are |
| +> registered with the zero role Set, the repo's closed-door mechanism |
| +> since 2026-08-18, and the shared `cliRoute` gate answers every service |
| +> credential with one constant 403 ("closed to service credentials") |
| +> BEFORE any account or app lookup. The body is the same for every role, |
| +> account and app, so it reveals only that the door exists, which is |
| +> public in the code, and nothing about this app or account. Members who |
| +> are not in the account, and unknown apps and instances, still get the |
| +> byte-identical 404. A literal 404 would need either a role Set the |
| +> handler then overrides, or a change to the shared gate for every closed |
| +> door. |
| + |
| Every successful open writes an `s.audit` row naming account, app, host, |
| database and the replicated TXID served. |