Filed from infra#89, which is closing — the decision and the code both live here, not in infra.
Why this is unblocked
infra#88 asked which mechanism should back per-user credential storage. That was answered by this repo's own ADR-015 (Accepted, 2026-06-03): envelope encryption in PG18, chosen over a vault-write service account and over Supabase. The decision was made the same day infra#88 was filed and never linked back, which is why infra#89 sat blocked for two months against a question that was already settled.
Re-checked 2026-08-11: ADR-015's reasoning was classification-based — runtime per-user writes are not config and do not belong in a vault-sync model — not blast-radius-based. So the fact that a working write-capable AgentSecrets service account now exists (infra#224) does not reopen it. Recording that explicitly so it isn't re-litigated on the wrong grounds.
Current state
internal/adapters/secrets/ contains only file.go — the PVC-backed FileStore. Nothing of ADR-015 is implemented.
Scope
Envelope-encryption store in PG18 per ADR-015
Retire the PVC FileStore
Runtime read/write path for per-user credentials
Reboot-validated cutover — prove credentials survive a restart with no silent fallback to the PVC path
Extend the isolation test so a missing/failed store fails closed rather than degrading
Blast radius
Per-user YouTube credential path only. Single-user today, so the worst realistic case is a re-auth, not data loss. That is exactly why this is a good time to do it — the cost of getting it wrong is at its historical minimum.
Refs
tapir ADR-015 (this repo, Accepted 2026-06-03)
infra#89 (closed), infra#88 (closed)
infra docs/superpowers/specs/2026-08-11-backlog-verification.md
Filed from infra#89, which is closing — the decision and the code both live here, not in infra.
## Why this is unblocked
infra#88 asked which mechanism should back per-user credential storage. That was answered by **this repo's own ADR-015 (Accepted, 2026-06-03)**: envelope encryption in PG18, chosen over a vault-write service account and over Supabase. The decision was made the same day infra#88 was filed and never linked back, which is why infra#89 sat blocked for two months against a question that was already settled.
Re-checked 2026-08-11: ADR-015's reasoning was **classification-based** — runtime per-user writes are not config and do not belong in a vault-sync model — not blast-radius-based. So the fact that a working write-capable AgentSecrets service account now exists (infra#224) does **not** reopen it. Recording that explicitly so it isn't re-litigated on the wrong grounds.
## Current state
`internal/adapters/secrets/` contains only `file.go` — the PVC-backed `FileStore`. Nothing of ADR-015 is implemented.
## Scope
- [ ] Envelope-encryption store in PG18 per ADR-015
- [ ] Retire the PVC `FileStore`
- [ ] Runtime read/write path for per-user credentials
- [ ] **Reboot-validated** cutover — prove credentials survive a restart with no silent fallback to the PVC path
- [ ] Extend the isolation test so a missing/failed store fails closed rather than degrading
## Blast radius
Per-user YouTube credential path only. Single-user today, so the worst realistic case is a re-auth, not data loss. That is exactly why this is a good time to do it — the cost of getting it wrong is at its historical minimum.
## Refs
- tapir ADR-015 (this repo, Accepted 2026-06-03)
- infra#89 (closed), infra#88 (closed)
- infra `docs/superpowers/specs/2026-08-11-backlog-verification.md`
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Filed from infra#89, which is closing — the decision and the code both live here, not in infra.
Why this is unblocked
infra#88 asked which mechanism should back per-user credential storage. That was answered by this repo's own ADR-015 (Accepted, 2026-06-03): envelope encryption in PG18, chosen over a vault-write service account and over Supabase. The decision was made the same day infra#88 was filed and never linked back, which is why infra#89 sat blocked for two months against a question that was already settled.
Re-checked 2026-08-11: ADR-015's reasoning was classification-based — runtime per-user writes are not config and do not belong in a vault-sync model — not blast-radius-based. So the fact that a working write-capable AgentSecrets service account now exists (infra#224) does not reopen it. Recording that explicitly so it isn't re-litigated on the wrong grounds.
Current state
internal/adapters/secrets/contains onlyfile.go— the PVC-backedFileStore. Nothing of ADR-015 is implemented.Scope
FileStoreBlast radius
Per-user YouTube credential path only. Single-user today, so the worst realistic case is a re-auth, not data loss. That is exactly why this is a good time to do it — the cost of getting it wrong is at its historical minimum.
Refs
docs/superpowers/specs/2026-08-11-backlog-verification.md