| 1 | # Review brief — the "next three" slice spec |
| 2 | |
| 3 | You are carrying out the **§Review pass** that `AGENTS.md` requires: |
| 4 | |
| 5 | > Every spec and every branch is reviewed by the highest-capability model |
| 6 | > available before it is approved or merged. Not the model that happened |
| 7 | > to write it. |
| 8 | |
| 9 | You did not write this spec. Attack it. |
| 10 | |
| 11 | ## Read, in this order |
| 12 | |
| 13 | 1. `AGENTS.md` — binding. Quote it rather than paraphrasing it; a |
| 14 | paraphrase of a binding rule has produced a confident false positive |
| 15 | here before. |
| 16 | 2. `PRODUCT.md` |
| 17 | 3. `docs/superpowers/specs/2026-08-30-sheets-design.md` — the design. |
| 18 | §1 is the settled-decisions table, §4.2 is the row/column identity |
| 19 | section, §5 is the formula engine, §13 is sequencing, §14 is |
| 20 | "Deliberately not built yet" with a written trigger per row. |
| 21 | 4. `docs/superpowers/specs/2026-09-03-sheets-next-three.md` — **the spec |
| 22 | under review.** |
| 23 | 5. The code it describes: `internal/sheets/calc/`, `handlers_grid.go`, |
| 24 | `handlers_table.go`, `handlers_format.go`, `handlers_sheets.go`, |
| 25 | `viewspec.go`, `store/`, `templates/table.html`, `templates/sheet.html`. |
| 26 | |
| 27 | ## What to attack |
| 28 | |
| 29 | Verify every factual claim against the code and the design, and say |
| 30 | which are wrong. In particular: |
| 31 | |
| 32 | - **§2.1's claim that 32 functions are registered**, and that the named |
| 33 | missing ones are genuinely missing. Count them yourself. |
| 34 | - **§3.1's claim that the cell API is already tab-scoped and that |
| 35 | `openTab` checks the tab against the sheet.** If a route bypasses |
| 36 | `openTab`, name it — that is a live authorisation bug, not a spec |
| 37 | defect. |
| 38 | - **§3.3's claim that no migration is needed.** Check the `tabs` table |
| 39 | and its columns against what add/name/switch would write. |
| 40 | - **§4.1's claim that the table view has no formatting at all**, and |
| 41 | §4.2's claim that `POST .../format` is form-ready. |
| 42 | - **§5.3's claim that `loadView` is called from exactly one place.** |
| 43 | - **§5's closing bug claim about the 100×26 window.** Is a cell past row |
| 44 | 100 genuinely invisible on the grid page, and genuinely reachable? |
| 45 | |
| 46 | Then judge the spec itself: |
| 47 | |
| 48 | - Does anything here **relitigate a settled §1 ruling**, or contradict |
| 49 | §4.2, §5 or §14? |
| 50 | - Is any of the three a **subsystem wearing a feature's name**? §13 |
| 51 | caught three of those already; the spec claims tabs is moderate |
| 52 | because the plumbing exists. Test that claim. |
| 53 | - Are the **triggers** in §6 checkable, or are they wishes? A deferred |
| 54 | thing without a real trigger is a thing forgotten. |
| 55 | - Is §1's decision E (one format route, two callers) actually achievable |
| 56 | given how `handleFormatPost` decodes today, or does it need a shape |
| 57 | the spec has not thought about? |
| 58 | - **What is missing.** Name anything that should be in the top three and |
| 59 | is not, and anything in §5's "Paul's to rule" list that does not in |
| 60 | fact need a ruling. |
| 61 | - Is the sealing rule respected throughout? A tab name is content |
| 62 | (§2.1). Does anything in this spec put one in a log, an error string, |
| 63 | a URL or a metric label? |
| 64 | |
| 65 | ## How to answer |
| 66 | |
| 67 | Write to `./REVIEW-OUT.md`: |
| 68 | |
| 69 | - A verdict line: **APPROVE**, **APPROVE WITH CHANGES**, or **REQUEST |
| 70 | CHANGES**. |
| 71 | - Findings, most serious first. For each: the claim, whether it is true, |
| 72 | the evidence (file and line), and what to do. |
| 73 | - Say plainly which of the three you would cut, if any, and why. |
| 74 | |
| 75 | Be specific and cite paths. Do not be agreeable. |
| 76 | |
amadan