# Review brief: edge asset cache spec

Spec: `docs/superpowers/specs/2026-10-24-edge-asset-cache-design.md` (rev 3).
Repository: carlos/platform at the commit named in the run prompt.

You are an independent second reader. The author is another model. Review
the spec adversarially against the code in this tree and report what is
wrong, not what is good.

## Fixed points (do not re-argue)

- Paul's rulings R1 to R3 in spec §13.
- The scope in §0 and §2: pull-through only, build assets only, not the
  media roadmap's stage 1, no third-party CDN.
- The author's calls marked "my call" may be challenged only with a
  concrete failure (a mechanism that breaks, an attack that works, a
  cost that is unbounded), not on taste.

## What to look for

1. Mechanisms that cannot do what the spec says against the current code.
   Cite file:line.
2. Attacks that work: cross-tenant reads, a personalised response cached
   for someone else, a stale or wrong owner's bytes served, a cache that
   one tenant can use to hurt another, a gate or import gate bypassed, a
   client forging the fill marker.
3. Interleavings: deploys with generation-managed routes, moves of a host
   between boxes (instance moves), replicas, aliases, a home disarmed or
   restarted, a purge racing a fill, an edge offline then back.
4. Cost: anything that adds per-app or per-box reads of the deployment
   bucket beyond what §4.2 states, or unbounded disk, memory or fills.
5. Provider boundary (§9) and rollout safety in a mixed fleet (§10).
6. Gaps in §12's tests that would let one of the above ship.

## Output

Numbered findings, most severe first. For each: severity (P1 blocks the
design, P2 must be fixed in the spec, P3 worth noting), the claim, the
evidence with file:line, and the smallest change to the spec that fixes
it. End with one line: "accept" if no P1 or P2 remain, otherwise
"reject".