amadan
spec: §10.1 resolved — request-coupled purge ships alone, TTL bounds the scheduled-transition staleness
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1 file changed,
+14
−0
docs/superpowers/specs/2026-08-03-unit-tenant-purge-channel.md+14 −0
diff --git a/docs/superpowers/specs/2026-08-03-unit-tenant-purge-channel.md b/docs/superpowers/specs/2026-08-03-unit-tenant-purge-channel.md| index 38bb527df..5c4e5134f 100644 |
| --- a/docs/superpowers/specs/2026-08-03-unit-tenant-purge-channel.md |
| +++ b/docs/superpowers/specs/2026-08-03-unit-tenant-purge-channel.md |
| @@ -888,6 +888,20 @@ privileges.** |
| ships (it is cheap and strictly better isolation) and candidate (a)'s |
| per-route group machinery has to be built alongside it. **This is |
| Paul's call and it is the only thing blocking a plan.** |
| + |
| + **Resolved 2026-08-03: request-coupled purge ships alone.** TTL-bounded |
| + staleness (≤ `DefaultCacheMaxTTL`, 300s) for scheduled sales open/close |
| + transitions is accepted: the parent spec's `SalesEndAt` default change |
| + already covers the common case, and a scheduled transition being up to |
| + five minutes stale on a cached public page is within the same tolerance |
| + the TTL already imposes on every uncached-to-cached transition; the |
| + effective bound per page is the app's own max-age when smaller (titogo's |
| + public pages set max-age=120, so its transitions bound at two minutes). |
| + Candidate (a)'s per-route group machinery is the documented escalation if |
| + production contradicts this. Decision taken in-session under delegated |
| + authority (Paul: "keep going until all those are done"), recorded here |
| + for veto. |
| + |
| 2. **Header name.** `Carlos-Purge` versus reusing the de-facto |
| `Surrogate-Key` vocabulary, which some app frameworks already emit and |
| which would make an app portable between CARLOS and a Fastly-style CDN. |