# Brainstorm — Fable's answer Read in the brief's order, then `handlers_grid.go`, `viewspec.go`, `grid.go`, `store/handle*.go`, `store/history.go`, `calc/registry.go`, `calc/graph.go`, `calc/translate.go`, the four chrome modules, and the `sheet.html`, `table.html` and `comments.html` templates. I did not open `BRAINSTORM-GPT.md`; the brief wants two independent voices. ## 1. Insert and delete a row or a column **What it is.** Right-click a row, or open Edit, and put a new empty row above it; every formula still points at the numbers it pointed at before. Delete works the same way, and a formula that referred to the deleted row shows `#REF!` rather than a wrong number. **Why it is first.** It is the most basic act in a spreadsheet after typing, and the app cannot do it: `grid.js` sets `allowInsertRow: false`, no route touches `Row.Position`, and `handle_open.go`'s binder comment says exactly why. What people do instead is retype a block one row down — which writes an input event per moved cell, detaches every comment (`comments.row_id`) from the data it was about, and leaves history describing a hundred edits nobody made on purpose. PRODUCT.md's job is "put numbers in a shared grid"; a grid you cannot make room in is a form. **What it costs.** This is §14's subsystem wearing a feature's name, and I am saying so: calc's key space rebuilt on stable ids. Today `calc.Ref` carries positions, `refKey` and `rangeCells` compute `CellKey{pos+1}` deep inside Eval, `rawText` and `cells.input_sealed` hold A1 text, and `events.payload_sealed` holds A1 text. Moving a row therefore needs one of two designs, and **Paul has to rule which**: - *(a)* rewrite the A1 text of every affected formula at insert time — Excel's mechanism. Cheap to start, but either the log grows by one event per rewritten formula or it does not and a restored old formula points at the wrong row. - *(b)* bind references to `(row_id, col_id)` at write time, persist the id-bound form, render A1 from the position map. This is what §4.2 already claims the design does. Insert becomes one `UPDATE` on `rows.position` and no graph change. Events written before the change stay A1 and are "coarse before the horizon", which §4.3's retention language already permits. I would argue for (b). Touches `calc/ref.go`, `eval.go`, `fn_lookup.go`, `graph.go`; `store/handle*.go`, `events.go`, `history.go`; `xlsx/export.go` (renders A1); `grid.js`, the Edit and Insert menus, and `table.html` for the scriptless twin. No SQL migration is forced; one additive column marking payload encoding is likely. It is the largest item here by a factor of three and needs a §1 ruling plus a §Review pass on the spec change before code. **What breaks.** A wrong binding silently repoints every formula — the exact failure §14 names — and nothing on screen says so. The one thing that would make me drop it: if the dogfood sheets turn out to be append-only (rows added at the bottom, never between), `EnsureRow` already covers that and the subsystem can wait for a second ask. **First slice.** Insert one row above / one column left, on the id-bound key space, from the Edit menu and from a form on the table view. Delete and `#REF!` second. No destructive sort at all (see below). ## 2. The functions people's existing spreadsheets already use **What it is.** `=SUMIF(A:A,">100",B:B)`, `=COUNTIF`, `=YEAR(A2)`, `=EOMONTH`, `=ISBLANK`, `=TEXT` — the everyday tail. A workbook you import stops showing `#NAME?` where its author had totals. **Why it is second.** The engine registers 32 functions (`calc/registry.go` and `fn_*.go`: SUM through VLOOKUP, NOW, TODAY); spec §5 said "~120 to start"; the LibreOffice corpus has 60 entries over 30 of them. An unknown name evaluates to `#NAME?` (`eval_call.go`), so `xlsx.Import` faithfully turns a real budget into a sheet of errors and the person blames the app, not the gap. This is the cheapest item on the list and has the best test story in the repo: `tools/gencorpus` produces vectors from LibreOffice headless (gate 4), so every function ships proven against a real spreadsheet rather than our reading of a spec. **What it costs.** `calc` only. New family files, self-registering; a shared criteria matcher for `">100"` and `"*x*"`; date functions ride the serial model `format/dates.go` already displays. Corpus regen. No migration, no UI, no ruling, no chrome. A few sessions. **What breaks.** A function that disagrees with LibreOffice on a corner case — the corpus catches it if the case is in the corpus, which is the discipline `volatile-excluded.txt` already models. I would drop it only if the event log showed the dogfood sheets were literal-only, and it does not. **First slice.** SUMIF, COUNTIF, AVERAGEIF, SUMIFS, COUNTIFS; DATE, YEAR, MONTH, DAY, DAYS, EOMONTH, WEEKDAY; ISBLANK, ISNUMBER, ISTEXT, ISERROR; TEXT, VALUE. About twenty. ## 3. A second tab **What it is.** A `+` on the tab strip, a name you can change, and a strip you can switch with. Importing a three-worksheet file gives you three tabs, not one. **Why it is third.** It fires a written trigger — §14: "a second tab is reachable in the UI" — and the tab strip in `sheet.html` says in a comment that it deliberately has no `+` for exactly that reason. The `tabs` table (sealed name, position) exists; the API routes already carry `{tabID}`; `xlsx.Import` reads `GetSheetList()[0]` and stops. Real workbooks have tabs, and the import form's hint is an honest apology that should retire. **What it costs.** Medium, no migration, no ruling. The page routes (`/table`, `/history`, `/comments`, `/view`) use `SheetSummary.TabID` = first tab (`sheetsvc.go`); they need a tab parameter. Create and rename are forms, so the scriptless path is free. Import loops over worksheets. **Cross-tab references (`Sheet2!A1`) are not in this** and I would refuse to build them before pick 1: real `Row.ID`/`Col.ID` are globally unique, so an id-bound key space is already tab-agnostic and cross-tab refs become "one handle per sheet". Built on the position key space they would be a second binding to unpick later. **What breaks.** A tab you can create in the grid but not from the table view — principle 2. Drop it if none of the dogfooders' imported files has a second worksheet. **First slice.** `+`, rename, switch, and import of every worksheet. No reorder, no delete, no cross-tab refs. ## Quietly unfinished: the grid shows A1:Z100 and says nothing `sheetsvc.go` sets `defaultWindowRows = 100`, `defaultWindowCols = 26`; `handlers_sheets.go:142` hands exactly those to the page; `grid.js` fetches exactly those; `snapshot` (`grid.go`) drops every cell outside them. Meanwhile `handleCellPost` accepts row 4,999, the table paginates to 500, import caps at 200,000 cells, the thumbnail (`preview.go`) draws the sheet's *true* shape, and export carries everything. Plan 2 item 5 promised the window would be "extendable by an explicit button"; there is no such button in `grid.js` or `sheet.html`. So an imported 300-row sheet opens showing 100 rows, with no line of copy anywhere saying rows 101–300 exist. That is principle 1 broken by omission, and it matters more than tabs because it makes the shipped product wrong rather than merely smaller. Smallest fix: the page passes the tab's extent (from `GridRows()`, plus a buffer, clamped at `maxWindowRows`), the grid sizes to it, and a status line says "rows 1–500 of 1,240" with a "Show more" button as the menu equivalent. About sixty lines. Virtualise later. ## Would not build: destructive sort §14 defers it behind the key-space subsystem. I would not build it even after pick 1 lands, and I think the trigger is wrong. §4.2 rules "values move, ids stay with positions", so a sort is a cell-content rewrite: 500 rows by 10 columns is 5,000 sealed input events per sort in a log Litestream ships continuously; undo is own-edits, cell-level (§7), so undoing a sort is 5,000 undos or a new compound event kind; and comments anchor to `row_id`, so the note about Acme's row stays at position 7 while Acme's numbers move to 30 — the anchoring that stable ids were bought for, defeated by the sort semantics in the same section. The non-destructive view (`viewspec.go`) already gives people what they want and tells them the truth about it. The Google pull is "sort should stick"; it does. If Paul wants it anyway, the trigger should read "a compound event kind with its own undo", not "stable ids". ## What I would cut from a longer list Comments visible in the grid (a per-cell count is shape, not content; worth an afternoon, not a slot), presence, freeze panes, find, undo for formatting, conditional formatting, charts. All real; none moves the dogfood job.