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.