Deferred decisions
Architecturally-significant decisions deliberately deferred, with the trigger that would prompt a revisit. Each page names the current implementation, the alternative being deferred, and what would make us revisit.
These are tracked authoritatively in openspec/current-decisions-for-future-tracking.md. The pages here surface the architecturally-significant subset where new engineers should know the framing before proposing a change.
In this section
- Per-environment Upstash databases — D17. Why the cluster uses a shared Upstash with
keyPrefixisolation instead of one DB per environment. - API e2e CI workflow — D14. Why the multi-instance e2e suite runs on-demand against dev rather than per-PR.
- Generic fanout abstraction — D15. Why the cron-tickle + SQS fanout pattern is not abstracted into a sixth coordination primitive yet.
Decisions tracked in OpenSpec only
Other deferred decisions in openspec/current-decisions-for-future-tracking.md (D1, D2, D3, D4, D5, D7, D8, D9, D10, D11, D12) are spec-level concerns — they affect a single contract, not the platform architecture. They live in OpenSpec and surface in ../../future-state/ pages where relevant. D13 (path-based org scoping) shipped as the dual-check authorization model documented in ../shipped/dual-check-authorization.