# Review brief — the "next three" slice spec

You are carrying out the **§Review pass** that `AGENTS.md` requires:

> Every spec and every branch is reviewed by the highest-capability model
> available before it is approved or merged. Not the model that happened
> to write it.

You did not write this spec. Attack it.

## Read, in this order

1. `AGENTS.md` — binding. Quote it rather than paraphrasing it; a
   paraphrase of a binding rule has produced a confident false positive
   here before.
2. `PRODUCT.md`
3. `docs/superpowers/specs/2026-08-30-sheets-design.md` — the design.
   §1 is the settled-decisions table, §4.2 is the row/column identity
   section, §5 is the formula engine, §13 is sequencing, §14 is
   "Deliberately not built yet" with a written trigger per row.
4. `docs/superpowers/specs/2026-09-03-sheets-next-three.md` — **the spec
   under review.**
5. The code it describes: `internal/sheets/calc/`, `handlers_grid.go`,
   `handlers_table.go`, `handlers_format.go`, `handlers_sheets.go`,
   `viewspec.go`, `store/`, `templates/table.html`, `templates/sheet.html`.

## What to attack

Verify every factual claim against the code and the design, and say
which are wrong. In particular:

- **§2.1's claim that 32 functions are registered**, and that the named
  missing ones are genuinely missing. Count them yourself.
- **§3.1's claim that the cell API is already tab-scoped and that
  `openTab` checks the tab against the sheet.** If a route bypasses
  `openTab`, name it — that is a live authorisation bug, not a spec
  defect.
- **§3.3's claim that no migration is needed.** Check the `tabs` table
  and its columns against what add/name/switch would write.
- **§4.1's claim that the table view has no formatting at all**, and
  §4.2's claim that `POST .../format` is form-ready.
- **§5.3's claim that `loadView` is called from exactly one place.**
- **§5's closing bug claim about the 100×26 window.** Is a cell past row
  100 genuinely invisible on the grid page, and genuinely reachable?

Then judge the spec itself:

- Does anything here **relitigate a settled §1 ruling**, or contradict
  §4.2, §5 or §14?
- Is any of the three a **subsystem wearing a feature's name**? §13
  caught three of those already; the spec claims tabs is moderate
  because the plumbing exists. Test that claim.
- Are the **triggers** in §6 checkable, or are they wishes? A deferred
  thing without a real trigger is a thing forgotten.
- Is §1's decision E (one format route, two callers) actually achievable
  given how `handleFormatPost` decodes today, or does it need a shape
  the spec has not thought about?
- **What is missing.** Name anything that should be in the top three and
  is not, and anything in §5's "Paul's to rule" list that does not in
  fact need a ruling.
- Is the sealing rule respected throughout? A tab name is content
  (§2.1). Does anything in this spec put one in a log, an error string,
  a URL or a metric label?

## How to answer

Write to `./REVIEW-OUT.md`:

- A verdict line: **APPROVE**, **APPROVE WITH CHANGES**, or **REQUEST
  CHANGES**.
- Findings, most serious first. For each: the claim, whether it is true,
  the evidence (file and line), and what to do.
- Say plainly which of the three you would cut, if any, and why.

Be specific and cite paths. Do not be agreeable.