| 1 | # Brief: what are the next three features for Oficina Sheets? |
| 2 | |
| 3 | You are one of two independent voices answering this. Your answer will be |
| 4 | compared against the other's, and the disagreements are the most useful |
| 5 | part, so do not hedge toward a safe consensus list. Argue for what you |
| 6 | think is right and say what you would cut. |
| 7 | |
| 8 | ## What you must read first |
| 9 | |
| 10 | Read these, in this order, from the repository root. Do not answer from |
| 11 | the summary below — it is a map, not a substitute, and a recommendation |
| 12 | that contradicts a settled ruling is worthless. |
| 13 | |
| 14 | 1. `PRODUCT.md` — what this product is for and who it is for. |
| 15 | 2. `AGENTS.md` — binding house rules. Note §Review and the shipping |
| 16 | cadence, and the mechanical rules about data and the frontend. |
| 17 | 3. `docs/superpowers/specs/2026-08-30-sheets-design.md` — the design. |
| 18 | Its §1 is the settled-decisions table (dated, attributed, with the |
| 19 | rejected alternative beside each). **Do not propose relitigating one.** |
| 20 | §13 is the sequencing and the agreed slip order. §14 is |
| 21 | "Deliberately not built yet", and every row there carries a written |
| 22 | trigger — a proposal that fires one of those triggers is a strong |
| 23 | candidate; a proposal that ignores one is not. |
| 24 | 4. `internal/sheets/` — the actual code. In particular |
| 25 | `handlers_grid.go`, `viewspec.go`, `store/`, `calc/`, and the |
| 26 | `static/*.js` chrome modules. |
| 27 | |
| 28 | ## What is already shipped and working |
| 29 | |
| 30 | Live at https://sheets.bds.oncarlos.com as of 2026-09-03: magic-link |
| 31 | sign-in, a sheet list with shape-only thumbnails, a Jspreadsheet grid, |
| 32 | live sync across tabs over SSE, a scriptless table view, sharing (team |
| 33 | grants, roles, hashed link tokens), version history, server-side undo, |
| 34 | comments, non-destructive sort and filter, XLSX import and export, |
| 35 | per-person light/dark, a menu bar and formatting toolbar (bold, italic, |
| 36 | alignment, number formats, fill and text colour from an OKLCH palette, |
| 37 | column width and row height). |
| 38 | |
| 39 | ## What is being fixed right now, so do not propose it |
| 40 | |
| 41 | Another session has these in hand tonight and they are not candidates: |
| 42 | |
| 43 | - Dropdown menus opened against the viewport edge; the sheet list had a |
| 44 | 40px gap; the Format panel was ragged. **Fixed and pushed.** |
| 45 | - **Cut and Copy are dead menu items**, the vendored grid's paste |
| 46 | silently drops cells, and there is no Paste at all. |
| 47 | - **`calc.Translate` exists, is tested, and nothing calls it.** Spec |
| 48 | §4.2 rules "Copy / drag-fill → Translation pass at paste time", and it |
| 49 | was never wired: filling `=A1*2` down B1:B3 writes `=A1*2` into all |
| 50 | three cells and shows 20, 20, 20 instead of 20, 40, 60. Being fixed. |
| 51 | |
| 52 | ## The question |
| 53 | |
| 54 | **Name the top three features to build next, in priority order.** |
| 55 | |
| 56 | For each one give me: |
| 57 | |
| 58 | - **What it is**, in two sentences, in plain language a user would |
| 59 | recognise. Not a subsystem name. |
| 60 | - **Why it is in the top three** — measured against PRODUCT.md's |
| 61 | principles and against what a person can and cannot do with the app |
| 62 | today. "Google has it" is not a reason. |
| 63 | - **What it costs**: which packages it touches, whether it needs a |
| 64 | migration, whether it needs a spec ruling from Paul, and roughly how |
| 65 | big it is. Be honest when something is a subsystem wearing a feature's |
| 66 | name — §13 already caught three of those. |
| 67 | - **What breaks if we get it wrong**, and the one thing that would make |
| 68 | you drop it from the list. |
| 69 | - **What you would build FIRST inside it** — the smallest slice whose |
| 70 | absence would still leave a coherent product. |
| 71 | |
| 72 | Then, separately: |
| 73 | |
| 74 | - **Name one thing on the shipped list that is quietly unfinished** and |
| 75 | matters more than your third pick. The app has a habit of features |
| 76 | that render perfectly and do nothing; two were found tonight. |
| 77 | - **Name one thing you would NOT build**, from §14 or from the obvious |
| 78 | Google-Sheets checklist, and say why it is a trap here specifically. |
| 79 | |
| 80 | ## Constraints that bound every answer |
| 81 | |
| 82 | - A sheet's contents are sealed at rest. No plaintext cell, title or tab |
| 83 | name reaches SQLite, object storage, a log line, an error string or a |
| 84 | metric label. A feature that needs server-side search over cell text |
| 85 | has to explain how. |
| 86 | - Migrations are additive-only. |
| 87 | - No frontend build step. Jspreadsheet CE is vendored. 300-line cap per |
| 88 | JS module we write, test-enforced. |
| 89 | - Every drag-only affordance needs a menu equivalent, and the scriptless |
| 90 | table view is the product rather than a fallback. |
| 91 | - calc's dependency graph is keyed on POSITION, not stable ids |
| 92 | (`store/handle.go`'s `cellKey`). Anything that MOVES a row — insert, |
| 93 | delete, drag-reorder, destructive sort — silently changes what every |
| 94 | existing formula points at. §14 makes "calc's key space rebuilt on |
| 95 | stable ids" the trigger. Treat a proposal that needs row-moving as |
| 96 | needing that subsystem first, and say so. |
| 97 | |
| 98 | Answer in Markdown. Be specific, cite file paths and spec sections, and |
| 99 | keep it under 1500 words. |
| 100 | |
amadan