Marks #13, #7/M1, A2/#6, A1/#3 and A3/#5 resolved, and records the limits this
batch accepts rather than leaving them for the next reviewer to rediscover.
Retracts the last of the two false claims flagged in the serve-path docs pass:
the kill switch now does "keep a stream dead" for the token's reconstructable
life. The other -- monitoring does not "never trust client progress" -- is still
false and stays flagged until decision A5 lands.
Newly documented accepted limits:
- A user cutoff cannot cut an API-key-owned pour. API-key credentials carry no
issue time, so they take the zero credential time and IsRevoked's documented
fail-open contract applies. Deliberate, logged, and better than substituting
time.Now(), which actively defeats the cutoff.
- Two central replicas revoking the same key can still race the Redis mirror,
because mirrorToRedis is an unconditional SET rather than an atomic merge.
Same-process writes are serialized by opMu; cross-replica convergence needs
A6's shared picture.
- The over-cap TTL setting affects future revocations only. Monotonic expiry
means it cannot shorten an existing kill; only an explicit unrevoke clears one,
and the enforcer may recreate it while the over-count persists.
- Per-login logout cuts are still unavailable: cutting one device's live streams
needs per-login identity in the stream credential, which is the
authorization-generation model rather than the iat model chosen here.
Records that the enforcer's repeat kill is non-extending and why: with monotonic
expiry and a 30s evaluation loop, a plain long TTL would renew a wrong kill
indefinitely for as long as any stale record survived.
Part of #305.
CoffeeKnyte
4288c7c5c6