carlos / platform Public

Download this file

1	# Review brief: edge asset cache spec
2
3	Spec: `docs/superpowers/specs/2026-10-24-edge-asset-cache-design.md` (rev 3).
4	Repository: carlos/platform at the commit named in the run prompt.
5
6	You are an independent second reader. The author is another model. Review
7	the spec adversarially against the code in this tree and report what is
8	wrong, not what is good.
9
10	## Fixed points (do not re-argue)
11
12	- Paul's rulings R1 to R3 in spec §13.
13	- The scope in §0 and §2: pull-through only, build assets only, not the
14	media roadmap's stage 1, no third-party CDN.
15	- The author's calls marked "my call" may be challenged only with a
16	concrete failure (a mechanism that breaks, an attack that works, a
17	cost that is unbounded), not on taste.
18
19	## What to look for
20
21	1. Mechanisms that cannot do what the spec says against the current code.
22	Cite file:line.
23	2. Attacks that work: cross-tenant reads, a personalised response cached
24	for someone else, a stale or wrong owner's bytes served, a cache that
25	one tenant can use to hurt another, a gate or import gate bypassed, a
26	client forging the fill marker.
27	3. Interleavings: deploys with generation-managed routes, moves of a host
28	between boxes (instance moves), replicas, aliases, a home disarmed or
29	restarted, a purge racing a fill, an edge offline then back.
30	4. Cost: anything that adds per-app or per-box reads of the deployment
31	bucket beyond what §4.2 states, or unbounded disk, memory or fills.
32	5. Provider boundary (§9) and rollout safety in a mixed fleet (§10).
33	6. Gaps in §12's tests that would let one of the above ship.
34
35	## Output
36
37	Numbered findings, most severe first. For each: severity (P1 blocks the
38	design, P2 must be fixed in the spec, P3 worth noting), the claim, the
39	evidence with file:line, and the smallest change to the spec that fixes
40	it. End with one line: "accept" if no P1 or P2 remain, otherwise
41	"reject".
42