| 1 | # Review brief: Meet design (round 2 reviews revision 2 against CODEX-FINDINGS-MEET.md) |
| 2 | |
| 3 | You are GPT-6 reviewing an app design spec independently of its author. |
| 4 | Your output is a findings report, not an edit. Do not modify any file. |
| 5 | |
| 6 | ## What to read |
| 7 | |
| 8 | 1. The spec under review: |
| 9 | `docs/superpowers/specs/2026-09-07-meet-design.md`. |
| 10 | 2. The rulings it consumes, which are fixed. Report a mechanism that |
| 11 | fails one; do not re-argue one. |
| 12 | - The suite doctrine at revision 8: |
| 13 | `/home/paulca/amadan.net/oficina/suite/docs/superpowers/specs/2026-09-05-suite-sharing-doctrine.md`, |
| 14 | rulings 1, 3, 5, 6, 9, 15 and §8 (egress). Ruling 16 (a link token |
| 15 | stored hashed) is on branch `worktree-worktree-token-at-rest` of |
| 16 | that repo; `git -C /home/paulca/amadan.net/oficina/suite show |
| 17 | origin/worktree-worktree-token-at-rest:docs/superpowers/specs/2026-09-05-suite-sharing-doctrine.md`. |
| 18 | - `oficina/suite` discussion 3 (every participant signs in; guest |
| 19 | grant at sign-in; Paul, 2026-09-06) and discussion 4 (agents as |
| 20 | their own principal). `amadan discuss show oficina/suite 3`. |
| 21 | - The CARLOS media roadmap: |
| 22 | `/home/paulca/amadan.net/carlos/platform/docs/superpowers/specs/2026-09-07-media-platform-roadmap-design.md` |
| 23 | on main, and the stage 4a relay spec, §2 in particular, on branch |
| 24 | `relay-stun-turn-spec`: |
| 25 | `git -C /home/paulca/amadan.net/carlos/platform show relay-stun-turn-spec:docs/superpowers/specs/2026-09-07-relay-stun-turn-design.md`. |
| 26 | - `carlos/platform` discussion 113 (no upgrade over a tunnel-backed |
| 27 | host; SSE plus POST). `amadan discuss show carlos/platform 113`. |
| 28 | 3. The code the spec claims to reuse. Check every claim: |
| 29 | - Docs sign-in: `/home/paulca/amadan.net/oficina/docs/internal/docs/auth.go`. |
| 30 | - Docs live-sync transport and hibernation: |
| 31 | `/home/paulca/amadan.net/oficina/docs/internal/docs/stream.go` and |
| 32 | `/home/paulca/amadan.net/oficina/docs/docs/superpowers/specs/2026-09-01-live-sync-design.md` §3, §6, §8. |
| 33 | - Sheets fan-out hub and link handler: |
| 34 | `/home/paulca/amadan.net/oficina/sheets-core/internal/sheets/live/hub.go`, |
| 35 | `/home/paulca/amadan.net/oficina/sheets-core/internal/sheets/handlers_link.go`. |
| 36 | - Calendar sealing and the feed route mounted outside the session: |
| 37 | `/home/paulca/amadan.net/oficina/calendar/.claude/worktrees/reminder-wake/internal/calendar/seal/`, |
| 38 | `/home/paulca/amadan.net/oficina/calendar/.claude/worktrees/reminder-wake/internal/calendar/routes.go`. |
| 39 | - Slides drive surface, which §8 adopts: |
| 40 | `/home/paulca/amadan.net/oficina/slides/.claude/worktrees/slice-1/docs/superpowers/specs/2026-09-07-slides-design.md` §6, §7. |
| 41 | - The scaffold in this repo: `AGENTS.md`, `internal/calls/`, |
| 42 | `internal/callstest/`, `go.mod` (rastrillo v0.26.0). |
| 43 | 4. WebRTC facts the spec relies on: host candidates only without STUN; |
| 44 | ICE restart via `setConfiguration` plus `restartIce`; TURN REST |
| 45 | credential shape; `getDisplayMedia` renegotiation. |
| 46 | |
| 47 | ## What matters most |
| 48 | |
| 49 | - **§3.2, the one departure from Docs' `auth.go`.** The allowlist gates |
| 50 | membership, not whether a magic link is sent, so an outsider can sign |
| 51 | in at all. What does that open: enumeration, mail volume, a |
| 52 | non-member with a session and nothing to do? Is the return-path rule |
| 53 | tight enough? Does a grant minted at sign-in survive the doctrine's |
| 54 | "authorization is never cached" once the roster comes from the home? |
| 55 | - **§4.3, the message table.** For each type, who may send it, who |
| 56 | receives it, and what the server reads. Find a message a waiting |
| 57 | guest can get to a member other than `knock`, a way to exceed the cap, |
| 58 | a way to make the server relay to a peer in another room, or a way to |
| 59 | spoof `from`. |
| 60 | - **§5, media.** Is the ICE list built correctly from the relay |
| 61 | contract's §2? Does the three-hour mint and the two-and-a-half-hour |
| 62 | re-mint hold against a four-hour hard deadline checked on allocate |
| 63 | and refresh? Is the floor in §5.5 stated honestly? Does §0.1's |
| 64 | falsifiable claim survive §4.3 (the server relays SDP, which names |
| 65 | codecs and candidate addresses) and the logs? |
| 66 | - **§2, `member` derived per request.** Is that the doctrine's ruling 3 |
| 67 | or a cache in disguise? What happens to a guest grant when its person |
| 68 | becomes a member, or a member is removed from the allowlist mid-call? |
| 69 | - **§9, the scriptless floor.** The suite's rule is that screens work |
| 70 | with scripts off. The spec draws the line at the holding screen and |
| 71 | the room. Is that the right line, and is the scriptless holding page |
| 72 | described well enough to build? |
| 73 | - **Claims about other repos.** Every path, section number, ruling |
| 74 | number, discussion number and "already does X" claim: check it. |
| 75 | Report each one that is wrong. |
| 76 | - **Slices in §12.** Is each slice bounded, testable as described in |
| 77 | §13, and free of a dependency on a later slice? |
| 78 | |
| 79 | ## How to report |
| 80 | |
| 81 | Write the report to standard output only. Number findings R1-1 onward. |
| 82 | For each: severity (P1 breaks a trust guarantee or a consumed ruling; |
| 83 | P2 a contract or claim defect to fix before the plan; P3 advisory), the |
| 84 | section, the problem, the evidence with citations, a proposed |
| 85 | correction. End with a verdict: accept, accept with corrections, or |
| 86 | request changes. Do not soften, do not pad, do not restate the spec. |
| 87 | |
amadan