amadan
spec: codex review brief for Meet revision 1
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
1 file changed,
+86
−0
docs/superpowers/specs/CODEX-REVIEW-BRIEF-MEET.md+86 −0
diff --git a/docs/superpowers/specs/CODEX-REVIEW-BRIEF-MEET.md b/docs/superpowers/specs/CODEX-REVIEW-BRIEF-MEET.md| new file mode 100644 |
| index 0000000..eac65b8 |
| --- /dev/null |
| +++ b/docs/superpowers/specs/CODEX-REVIEW-BRIEF-MEET.md |
| @@ -0,0 +1,86 @@ |
| +# Review brief: Meet design, revision 1 |
| + |
| +You are GPT-6 reviewing an app 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-meet-design.md`. |
| +2. The rulings it consumes, which are fixed. Report a mechanism that |
| + fails one; do not re-argue one. |
| + - The suite doctrine at revision 8: |
| + `/home/paulca/amadan.net/oficina/suite/docs/superpowers/specs/2026-09-05-suite-sharing-doctrine.md`, |
| + rulings 1, 3, 5, 6, 9, 15 and §8 (egress). Ruling 16 (a link token |
| + stored hashed) is on branch `worktree-worktree-token-at-rest` of |
| + that repo; `git -C /home/paulca/amadan.net/oficina/suite show |
| + origin/worktree-worktree-token-at-rest:docs/superpowers/specs/2026-09-05-suite-sharing-doctrine.md`. |
| + - `oficina/suite` discussion 3 (every participant signs in; guest |
| + grant at sign-in; Paul, 2026-09-06) and discussion 4 (agents as |
| + their own principal). `amadan discuss show oficina/suite 3`. |
| + - The CARLOS media roadmap: |
| + `/home/paulca/amadan.net/carlos/platform/docs/superpowers/specs/2026-09-07-media-platform-roadmap-design.md` |
| + on main, and the stage 4a relay spec, §2 in particular, on branch |
| + `relay-stun-turn-spec`: |
| + `git -C /home/paulca/amadan.net/carlos/platform show relay-stun-turn-spec:docs/superpowers/specs/2026-09-07-relay-stun-turn-design.md`. |
| + - `carlos/platform` discussion 113 (no upgrade over a tunnel-backed |
| + host; SSE plus POST). `amadan discuss show carlos/platform 113`. |
| +3. The code the spec claims to reuse. Check every claim: |
| + - Docs sign-in: `/home/paulca/amadan.net/oficina/docs/internal/docs/auth.go`. |
| + - Docs live-sync transport and hibernation: |
| + `/home/paulca/amadan.net/oficina/docs/internal/docs/stream.go` and |
| + `/home/paulca/amadan.net/oficina/docs/docs/superpowers/specs/2026-09-01-live-sync-design.md` §3, §6, §8. |
| + - Sheets fan-out hub and link handler: |
| + `/home/paulca/amadan.net/oficina/sheets-core/internal/sheets/live/hub.go`, |
| + `/home/paulca/amadan.net/oficina/sheets-core/internal/sheets/handlers_link.go`. |
| + - Calendar sealing and the feed route mounted outside the session: |
| + `/home/paulca/amadan.net/oficina/calendar/.claude/worktrees/reminder-wake/internal/calendar/seal/`, |
| + `/home/paulca/amadan.net/oficina/calendar/.claude/worktrees/reminder-wake/internal/calendar/routes.go`. |
| + - Slides drive surface, which §8 adopts: |
| + `/home/paulca/amadan.net/oficina/slides/.claude/worktrees/slice-1/docs/superpowers/specs/2026-09-07-slides-design.md` §6, §7. |
| + - The scaffold in this repo: `AGENTS.md`, `internal/meet/`, |
| + `internal/meettest/`, `go.mod` (rastrillo v0.26.0). |
| +4. WebRTC facts the spec relies on: host candidates only without STUN; |
| + ICE restart via `setConfiguration` plus `restartIce`; TURN REST |
| + credential shape; `getDisplayMedia` renegotiation. |
| + |
| +## What matters most |
| + |
| +- **§3.2, the one departure from Docs' `auth.go`.** The allowlist gates |
| + membership, not whether a magic link is sent, so an outsider can sign |
| + in at all. What does that open: enumeration, mail volume, a |
| + non-member with a session and nothing to do? Is the return-path rule |
| + tight enough? Does a grant minted at sign-in survive the doctrine's |
| + "authorization is never cached" once the roster comes from the home? |
| +- **§4.3, the message table.** For each type, who may send it, who |
| + receives it, and what the server reads. Find a message a waiting |
| + guest can get to a member other than `knock`, a way to exceed the cap, |
| + a way to make the server relay to a peer in another room, or a way to |
| + spoof `from`. |
| +- **§5, media.** Is the ICE list built correctly from the relay |
| + contract's §2? Does the three-hour mint and the two-and-a-half-hour |
| + re-mint hold against a four-hour hard deadline checked on allocate |
| + and refresh? Is the floor in §5.5 stated honestly? Does §0.1's |
| + falsifiable claim survive §4.3 (the server relays SDP, which names |
| + codecs and candidate addresses) and the logs? |
| +- **§2, `member` derived per request.** Is that the doctrine's ruling 3 |
| + or a cache in disguise? What happens to a guest grant when its person |
| + becomes a member, or a member is removed from the allowlist mid-call? |
| +- **§9, the scriptless floor.** The suite's rule is that screens work |
| + with scripts off. The spec draws the line at the holding screen and |
| + the room. Is that the right line, and is the scriptless holding page |
| + described well enough to build? |
| +- **Claims about other repos.** Every path, section number, ruling |
| + number, discussion number and "already does X" claim: check it. |
| + Report each one that is wrong. |
| +- **Slices in §12.** Is each slice bounded, testable as described in |
| + §13, and free of a dependency on a later slice? |
| + |
| +## How to report |
| + |
| +Write the report to standard output only. Number findings R1-1 onward. |
| +For each: severity (P1 breaks a trust guarantee or a consumed ruling; |
| +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. |