Review brief: stage 4a relay spec

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

What to read

1. The spec under review: docs/superpowers/specs/2026-09-07-relay-stun-turn-design.md.
2. Its parent, which it must honour: the media roadmap docs/superpowers/specs/2026-09-07-media-platform-roadmap-design.md, especially §1, §3, stage 4a, §7 rulings 8, 10 and 11, and §9's stage 4a gate. Rulings are fixed; report a mechanism that fails one, do not re-argue one.
3. The code it fits into, in this worktree: internal/host/bootstrap.go and internal/host/units/carlos-edge.service (units, hardening, enabledUnits); internal/host/agent.go (IMDS reads near line 1761, fast-converge loop near 1304, config generation loop near 985); internal/host/edgesfile.go; internal/host/metrics_loop.go; internal/objstore/walk.go (writeEnv near 554) and internal/appconfig/ (Apply, generation, sync); store.go, internal/console/apistore.go, internal/console/apicli.go (apiAccountApp); internal/release/serial.go; infra/modules/region-host/main.tf; go.mod; AGENTS.md.
4. pion/turn v4's API as documented at pkg.go.dev (ServerConfig, AuthHandler, PermissionHandler, QuotaHandler, EventHandler, RelayAddressGeneratorPortRange, GenerateAuthKey). Check the spec's claims about when pion calls the auth handler and what it does with the returned key.
5. The suite doctrine ruling 6 and §8 at /home/paulca/amadan.net/oficina/suite/docs/superpowers/specs/2026-09-05-suite-sharing-doctrine.md.

What matters most

• The app-facing contract in §2 is what the Meet app will code against today. Is it complete, unambiguous and implementable from the text alone? Does the test vector follow from §4 exactly? Is anything the app needs missing?
• Verification in §4. Look for a way to obtain a TURN allocation without a key an enabled app was given, to use one app's credential for another, to keep using a credential after disable, or to make the relay accept something the authority record does not cover. Check the interaction with pion's long-term credential mechanism.
• Key custody in §4 and §5. Masters in host.env and as console secrets, two hand-staged copies. Is the exposure stated honestly and consistently with roadmap §1's statement that sealed config is decryptable on every host? Does rotation as written ever leave a window where a credential stops working or an old master is accepted too long?
• The unit in §3. Hardening, ports, the allocation range, the EIP as relay address, the certificate for 5349, the authority record and its fifteen-minute lease. Is anything unbuildable as written on a t4g.small sharing the box with the edge?
• Limits and metering. Can one app starve another, exhaust the port range, or relay to somewhere it should not? Can the meters be attributed wrongly?
• Claims about the code. Every file:line and every "already exists" claim: check it. Report each one that is wrong.
• Operability. Can a member, with no box access, enable, see status and disable? Can an operator rotate a master without a call dropping?

How to report

Number findings R1-1 onward. For each: severity (P1 breaks a trust guarantee or makes the stage unbuildable; P2 a contract or claim defect to fix before the plan; P3 advisory), the section, the problem, the evidence with citations, a proposed correction. End with a verdict: accept, accept with corrections, or request changes. Do not soften, do not pad, do not restate the spec.