# 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.