| 1 | # Review brief: media roadmap |
| 2 | |
| 3 | You are GPT-6 reviewing a design roadmap independently of its author. Your |
| 4 | output is a findings report, not an edit. Do not modify any file. |
| 5 | |
| 6 | ## What to read |
| 7 | |
| 8 | 1. The roadmap under review: |
| 9 | `docs/superpowers/specs/2026-09-07-media-platform-roadmap-design.md` |
| 10 | (in this worktree). |
| 11 | 2. The prior planning it descends from, as text below (amadan discussions |
| 12 | #107, #112, #113 on carlos/platform). |
| 13 | 3. The platform code it cites, in this worktree: `internal/edge/edge.go`, |
| 14 | `internal/edge/cache.go`, `internal/edge/static.go`, |
| 15 | `internal/edge/storedoor.go`, `internal/edge/purge_header.go`, |
| 16 | `internal/provision/provision.go`, `internal/caps/`, |
| 17 | `internal/objstore/`, `internal/schedule/`, `internal/activator/`, |
| 18 | `infra/modules/region-host/main.tf`, `.amadan/ci.d/20-cross@5`, |
| 19 | `go.mod`. |
| 20 | 4. The private specs it cites, at |
| 21 | `/home/paulca/github.com/carlosframework/platform-infrastructure/platform-design/superpowers/specs/` |
| 22 | (ignore `.worktrees/`): the object-storage primitive (2026-08-10), |
| 23 | app capabilities (2026-08-03), app config and secrets (2026-08-02), |
| 24 | route-scoped config delivery (2026-08-16), static platform host |
| 25 | (2026-08-23), multi-region ingress (2026-08-20), remote host Pi |
| 26 | (2026-08-04), unit economics (2026-08-11). |
| 27 | 5. The suite doctrine the roadmap must not contradict: |
| 28 | `/home/paulca/amadan.net/oficina/suite/docs/superpowers/specs/2026-09-05-suite-sharing-doctrine.md`, |
| 29 | especially rulings 3, 6, 8 and 15, §4.2, §8, and leak item 11. |
| 30 | 6. The home identity design: |
| 31 | `/home/paulca/amadan.net/oficina/home/docs/superpowers/specs/2026-08-30-home-design.md` §5. |
| 32 | |
| 33 | ## What matters most |
| 34 | |
| 35 | - **Doctrine.** Does the public/secret/private mapping in §2 honour the |
| 36 | suite doctrine, in particular ruling 3 (authorisation never cached) and |
| 37 | leak item 11? Is the ask-the-app subrequest for private media sound, |
| 38 | and what does it leak or cache that the roadmap does not admit? |
| 39 | - **Security of the serving class.** The bucket-policy grant, the Ed25519 |
| 40 | signed links (URL shape, what the signature covers, prefix scope, |
| 41 | rotation), the separate media origin and headers, the per-route cache. |
| 42 | Look for a way to read a private or secret object without |
| 43 | authorisation, to poison a cache entry, or to make one tenant's cache |
| 44 | evict another's. |
| 45 | - **The relay.** TURN REST credentials with the per-account secret held |
| 46 | on every region box. Is there a better shape that keeps verification |
| 47 | local to the relay? Anything wrong about the port plan, placement, or |
| 48 | the egress claim under ruling 6? |
| 49 | - **Feasibility on the fleet as it is**: `t4g.small` ARM boxes, no cgo in |
| 50 | the Go tree, no package installs today. Are the helper-binary rule in |
| 51 | §3, the transform engine candidates, and the media worker on the |
| 52 | Ireland `t4g.medium` realistic? Name what will fall over first. |
| 53 | - **Staging and order.** Is anything in a later stage secretly required |
| 54 | by an earlier one? Is anything in stage 1 that could wait? |
| 55 | - **Claims about the code.** Every `file:line` and every "the platform |
| 56 | already does X" claim: check it. Report each one that is wrong. |
| 57 | - **What is missing** that an app building on this would hit in the |
| 58 | first month. |
| 59 | |
| 60 | ## How to report |
| 61 | |
| 62 | Number findings. For each: severity (P1 breaks a trust guarantee or |
| 63 | makes a stage unbuildable as written; P2 is a contract or claim defect to |
| 64 | fix before the stage spec; P3 is advisory), the section it concerns, the |
| 65 | problem, the evidence with citations, and a proposed correction. End |
| 66 | with a one-paragraph verdict: accept as a roadmap, accept with the |
| 67 | listed corrections, or request changes. Do not soften findings, do not |
| 68 | pad with praise, and do not restate the roadmap. |
| 69 | |
| 70 | ## Prior planning, verbatim |
| 71 | |
| 72 | ### #107 Media handling: a `kind:media` serving class over an app's store |
| 73 | |
| 74 | (Brainstormed 2026-08-31. Decided: build the serving class first; media |
| 75 | serves public and private; kind:media caches for itself. Open questions |
| 76 | 1 to 3 were: what private means, how the edge is granted read, where the |
| 77 | signing key lives. Open 4 and 5: abuse surface for transforms, who pays |
| 78 | for derivatives. The roadmap answers all five.) |
| 79 | |
| 80 | ### #112 A P2P WebRTC app has no relay |
| 81 | |
| 82 | Meet is browser-to-browser WebRTC, rooms capped at four, signalling over |
| 83 | HTTP on the app's instance. Platform has no UDP, no TURN, ports |
| 84 | capability is 1 to 1023 with no protocol. Asked: is the direction a |
| 85 | platform-hosted relay (A) or per-team bring-your-own TURN (B) under |
| 86 | suite ruling 6? Meet's later requirements: STUN is the minimum and |
| 87 | cannot be a third party's under ruling 6; TURN next with short-lived |
| 88 | HMAC credentials as platform config; SFU later; credentials scoped per |
| 89 | account; nearest-region placement; keep the "platform relay is not |
| 90 | egress, third-party relay is" distinction. |
| 91 | |
| 92 | ### #113 No upgrade over a tunnel-backed host |
| 93 | |
| 94 | `infra/remote-host.md`: a tunnel-backed host cannot carry `Connection: |
| 95 | Upgrade`. Asked: confirm as a design constraint; can an app know or |
| 96 | refuse its placement? Meet defaults to SSE plus POST if unanswered. |
| 97 | |
amadan