oficina / slides Public

Clone
git clone https://amadan.net/oficina/slides

Plain git — no account needed to clone.

Download

Download this file

Codex review brief — the Slides design, revision 1

You are GPT-6, reading as an independent second reader. Claude drafted this spec and built three slices against it; nobody else has read it. §12 of the spec says the review pass waits until a reviewer can have a running instance instead of a document. That is now true, so this is that pass.

Answer as findings, not as prose. Number them. For each: the section or file, what is wrong or unsound, why it matters, and what you would do instead. Mark severity P1 (a security hole, data loss, or a ruling that cannot hold), P2 (must fix before the next slice), P3 (worth doing). Cite code by path and line when you make a claim about the code. If you cannot verify something from the repository, say so rather than assuming.

What to read

Repository: oficina/slides, this worktree, at commit 6c757a4 (branch slice-3-export). Three slices are built and deployed.

  • The spec: docs/superpowers/specs/2026-09-07-slides-design.md (revision 1, thirteen rulings in §1). §4.2 and §4.3 are being amended in a commit that is in flight as you read; judge the design, not those two paragraphs' wording.
  • The plans, which say what each slice meant to build: docs/superpowers/plans/2026-09-07-slice-1-live.md, 2026-09-07-slice-2-editor.md, 2026-09-08-slice-3-export.md.
  • AGENTS.md — the seams, and the traps a new session must know.
  • The suite doctrine this app consumes by ruling number: ../../../suite/docs/superpowers/specs/2026-09-05-suite-sharing-doctrine.md (revision 8). The spec's §0.2 lists which rulings it leans on.

The code, if you want to check a claim: internal/slides/ (the app; auth.go, decks.go, viewer.go, share.go, presentation.go, live.go, editor.go, assets.go, thumbs.go, export.go, api.go, agents.go), internal/slides/{core,pdfcore,layout,svg,fonts,render,deck,live,present}/, core/ and core/pdf/ (the two Rust crates), fixtures/ (the browser half and the op vocabulary that must mirror core/src/ops.rs).

The questions I most want a cold reader on

  1. The one rule (§0.1): "a slide is one block tree, rendered many ways". Three renderers now exist — render.Slide (HTML), layout + svg (pictures and PDF), and ProseMirror binding into the server's HTML in the browser. Does the rule still hold, or has it been broken in practice while the words stayed?
  2. The hybrid model (§2.3, ruling 1): flow templates and a canvas layout in one block tree, with a conversion between them (core/src/layout.rs). Is the conversion sound, or does it lose work in a way a person will hit? What happens to a deck that is switched back and forth?
  3. The phone layer (§2.5, ruling 2): a phone map per block, written by the editor's Phone view, read by the renderer, never read by print. Is "the desktop layout is always the base; the phone layer only adds" a rule that survives contact with real decks?
  4. Trust in the write path. Any member may POST arbitrary Yjs bytes (live.go); the core applies them, the app parses the resulting view and refuses a batch that would leave the deck unrenderable. Is that gate in the right place, and is there a shape it misses?
  5. Capabilities (§5, doctrine ruling 15): a share link is a hashed read-only token; a presentation session's sqid lets anyone view, its remote token lets a holder drive, its pairing code lets a phone find it. Four capability kinds across share.go, presentation.go, thumbs.go and assets.go. Is any of them stronger than it should be, or confusable with another?
  6. Agents as principals (§7, ruling 7): tokens minted in-app by a person, agent:<id> recorded as the actor, the API mounted outside CSRF because a bearer caller sends no browser headers. Sound?
  7. The export path (§4.2, §4.3, ruling 13): a Go layout engine measuring with embedded Liberation faces, an SVG per slide, and svg2pdf in a wasm module under wazero. With no object store bound the finished PDF is held in memory for an hour, capped. Where does this break first?
  8. What the spec does not say that a second reader would expect a presentation editor's design to settle before slice 4.

What is deliberately not built

Spec §9 lists it with triggers: sign-in through the suite home (it is a skeleton), charts from Sheets, video and embeds, an MCP adapter, aspect ratios other than 16:9, comments, version history. Do not report those as gaps; do report it if one of them is load-bearing for something the spec claims today.

Conventions of this house, so you can judge against them

Every user-visible string is a catalog key. Every screen but the editor works with scripts off. WCAG 2.2 AA with no exemptions. One static Go binary per team on the CARLOS platform, CGO_ENABLED=0, SQLite, no Chromium anywhere. fixtures/ and the Rust core are two implementations of one op vocabulary, held together by committed vectors. The gate (.amadan/ci.d/10-gate) rebuilds both wasm modules and the browser bundle and diffs them against what is committed.