Review brief: media roadmap

You are GPT-6 reviewing a design roadmap independently of its author. Your output is a findings report, not an edit. Do not modify any file.

What to read

1. The roadmap under review: docs/superpowers/specs/2026-09-07-media-platform-roadmap-design.md (in this worktree).
2. The prior planning it descends from, as text below (amadan discussions #107, #112, #113 on carlos/platform).
3. The platform code it cites, in this worktree: internal/edge/edge.go, internal/edge/cache.go, internal/edge/static.go, internal/edge/storedoor.go, internal/edge/purge_header.go, internal/provision/provision.go, internal/caps/, internal/objstore/, internal/schedule/, internal/activator/, infra/modules/region-host/main.tf, .amadan/ci.d/20-cross@5, go.mod.
4. The private specs it cites, at /home/paulca/github.com/carlosframework/platform-infrastructure/platform-design/superpowers/specs/ (ignore .worktrees/): the object-storage primitive (2026-08-10), app capabilities (2026-08-03), app config and secrets (2026-08-02), route-scoped config delivery (2026-08-16), static platform host (2026-08-23), multi-region ingress (2026-08-20), remote host Pi (2026-08-04), unit economics (2026-08-11).
5. The suite doctrine the roadmap must not contradict: /home/paulca/amadan.net/oficina/suite/docs/superpowers/specs/2026-09-05-suite-sharing-doctrine.md, especially rulings 3, 6, 8 and 15, §4.2, §8, and leak item 11.
6. The home identity design: /home/paulca/amadan.net/oficina/home/docs/superpowers/specs/2026-08-30-home-design.md §5.

What matters most

• Doctrine. Does the public/secret/private mapping in §2 honour the suite doctrine, in particular ruling 3 (authorisation never cached) and leak item 11? Is the ask-the-app subrequest for private media sound, and what does it leak or cache that the roadmap does not admit?
• Security of the serving class. The bucket-policy grant, the Ed25519 signed links (URL shape, what the signature covers, prefix scope, rotation), the separate media origin and headers, the per-route cache. Look for a way to read a private or secret object without authorisation, to poison a cache entry, or to make one tenant's cache evict another's.
• The relay. TURN REST credentials with the per-account secret held on every region box. Is there a better shape that keeps verification local to the relay? Anything wrong about the port plan, placement, or the egress claim under ruling 6?
• Feasibility on the fleet as it is: t4g.small ARM boxes, no cgo in the Go tree, no package installs today. Are the helper-binary rule in §3, the transform engine candidates, and the media worker on the Ireland t4g.medium realistic? Name what will fall over first.
• Staging and order. Is anything in a later stage secretly required by an earlier one? Is anything in stage 1 that could wait?
• Claims about the code. Every file:line and every "the platform already does X" claim: check it. Report each one that is wrong.
• What is missing that an app building on this would hit in the first month.

How to report

Number findings. For each: severity (P1 breaks a trust guarantee or makes a stage unbuildable as written; P2 is a contract or claim defect to fix before the stage spec; P3 is advisory), the section it concerns, the problem, the evidence with citations, and a proposed correction. End with a one-paragraph verdict: accept as a roadmap, accept with the listed corrections, or request changes. Do not soften findings, do not pad with praise, and do not restate the roadmap.

Prior planning, verbatim

#107 Media handling: a kind:media serving class over an app's store

(Brainstormed 2026-08-31. Decided: build the serving class first; media serves public and private; kind:media caches for itself. Open questions 1 to 3 were: what private means, how the edge is granted read, where the signing key lives. Open 4 and 5: abuse surface for transforms, who pays for derivatives. The roadmap answers all five.)

#112 A P2P WebRTC app has no relay

Meet is browser-to-browser WebRTC, rooms capped at four, signalling over HTTP on the app's instance. Platform has no UDP, no TURN, ports capability is 1 to 1023 with no protocol. Asked: is the direction a platform-hosted relay (A) or per-team bring-your-own TURN (B) under suite ruling 6? Meet's later requirements: STUN is the minimum and cannot be a third party's under ruling 6; TURN next with short-lived HMAC credentials as platform config; SFU later; credentials scoped per account; nearest-region placement; keep the "platform relay is not egress, third-party relay is" distinction.

#113 No upgrade over a tunnel-backed host

infra/remote-host.md: a tunnel-backed host cannot carry Connection: Upgrade. Asked: confirm as a design constraint; can an app know or refuse its placement? Meet defaults to SSE plus POST if unanswered.