Brief: what are the next three features for Oficina Sheets?

You are one of two independent voices answering this. Your answer will be compared against the other's, and the disagreements are the most useful part, so do not hedge toward a safe consensus list. Argue for what you think is right and say what you would cut.

What you must read first

Read these, in this order, from the repository root. Do not answer from the summary below — it is a map, not a substitute, and a recommendation that contradicts a settled ruling is worthless.

1. PRODUCT.md — what this product is for and who it is for.
2. AGENTS.md — binding house rules. Note §Review and the shipping cadence, and the mechanical rules about data and the frontend.
3. docs/superpowers/specs/2026-08-30-sheets-design.md — the design. Its §1 is the settled-decisions table (dated, attributed, with the rejected alternative beside each). Do not propose relitigating one. §13 is the sequencing and the agreed slip order. §14 is "Deliberately not built yet", and every row there carries a written trigger — a proposal that fires one of those triggers is a strong candidate; a proposal that ignores one is not.
4. internal/sheets/ — the actual code. In particular handlers_grid.go, viewspec.go, store/, calc/, and the static/*.js chrome modules.

What is already shipped and working

Live at https://sheets.bds.oncarlos.com as of 2026-09-03: magic-link sign-in, a sheet list with shape-only thumbnails, a Jspreadsheet grid, live sync across tabs over SSE, a scriptless table view, sharing (team grants, roles, hashed link tokens), version history, server-side undo, comments, non-destructive sort and filter, XLSX import and export, per-person light/dark, a menu bar and formatting toolbar (bold, italic, alignment, number formats, fill and text colour from an OKLCH palette, column width and row height).

What is being fixed right now, so do not propose it

Another session has these in hand tonight and they are not candidates:

• Dropdown menus opened against the viewport edge; the sheet list had a 40px gap; the Format panel was ragged. Fixed and pushed.
• Cut and Copy are dead menu items, the vendored grid's paste silently drops cells, and there is no Paste at all.
• calc.Translate exists, is tested, and nothing calls it. Spec §4.2 rules "Copy / drag-fill → Translation pass at paste time", and it was never wired: filling =A1*2 down B1:B3 writes =A1*2 into all three cells and shows 20, 20, 20 instead of 20, 40, 60. Being fixed.

The question

Name the top three features to build next, in priority order.

For each one give me:

• What it is, in two sentences, in plain language a user would recognise. Not a subsystem name.
• Why it is in the top three — measured against PRODUCT.md's principles and against what a person can and cannot do with the app today. "Google has it" is not a reason.
• What it costs: which packages it touches, whether it needs a migration, whether it needs a spec ruling from Paul, and roughly how big it is. Be honest when something is a subsystem wearing a feature's name — §13 already caught three of those.
• What breaks if we get it wrong, and the one thing that would make you drop it from the list.
• What you would build FIRST inside it — the smallest slice whose absence would still leave a coherent product.

Then, separately:

• Name one thing on the shipped list that is quietly unfinished and matters more than your third pick. The app has a habit of features that render perfectly and do nothing; two were found tonight.
• Name one thing you would NOT build, from §14 or from the obvious Google-Sheets checklist, and say why it is a trap here specifically.

Constraints that bound every answer

• A sheet's contents are sealed at rest. No plaintext cell, title or tab name reaches SQLite, object storage, a log line, an error string or a metric label. A feature that needs server-side search over cell text has to explain how.
• Migrations are additive-only.
• No frontend build step. Jspreadsheet CE is vendored. 300-line cap per JS module we write, test-enforced.
• Every drag-only affordance needs a menu equivalent, and the scriptless table view is the product rather than a fallback.
• calc's dependency graph is keyed on POSITION, not stable ids (store/handle.go's cellKey). Anything that MOVES a row — insert, delete, drag-reorder, destructive sort — silently changes what every existing formula points at. §14 makes "calc's key space rebuilt on stable ids" the trigger. Treat a proposal that needs row-moving as needing that subsystem first, and say so.

Answer in Markdown. Be specific, cite file paths and spec sections, and keep it under 1500 words.