oficina / sheets Public

A person with no sheets who starts an XLSX import and then navigates to /sheets is told "No sheets yet" while their import is running.

Reported by the list-chrome session as an interaction with its own work. It is not: it is live on core today, at d7cea4f. Their change makes it louder, it does not cause it.

Why

20977af made an importing sheet nobody's until it is finished — no grant, and filling_since IS NOT NULL excluded from visibleSheets, sheetSummary and tabBelongsTo. That is a good design and I am not arguing with it. The consequence is that the list has no concept of a filling sheet at all — there is no query anywhere in handlers_sheets.go or sheetsvc.go that can see one — so during the import window the list is genuinely empty, and the empty state says so in as many words.

Today it is softened by accident: the import form sits directly above the empty state, so the page is not only saying "nothing here". Once the list-chrome work lands, both forms move off that page and the empty state is the only thing on it. The message a person gets, seconds after starting an import, is that they have nothing and should start one.

Severity

Small and real. The window is the length of the job; it is only reachable by navigating away from the job page, which is where the flow actually puts you. Nothing is lost — the sheet arrives when the job finishes. It is a lie the UI tells for a few seconds, and PRODUCT.md's first principle is about exactly that kind of lie.

Why I have not fixed it

The cheap fix is one query — count(*) where created_by = ? and filling_since is not null and deleted_at is null — which discloses only a count, only to the person who started it, and nothing about the sheet. That is defensible and about ten lines.

But it changes what the hidden-until-finished design discloses, and that design was written deliberately and recently by someone else. AGENTS.md says a settled decision is not relitigated in a drive-by, and "an importing sheet is nobody's until it is finished" is a settled decision with a rule in it. Whether the creator may learn that their own import is in flight is a real question about that rule, not an oversight in it, and it should be answered by whoever set it or by Paul.

Options, for whoever takes it

1. The empty state learns about in-flight imports — the count query above, and copy that says an import is running with a link to the job. Smallest, and keeps the sheet itself invisible.
2. The job page is the answer and the list should not change — argue that navigating away from a running job is the person's choice and the job page is one back-button away. Cheapest, and defensible if the empty-state copy stops claiming "No sheets yet" so confidently.
3. A filling sheet appears to its creator, disabled — biggest change, contradicts the ruling most directly, and I do not recommend it.

I would take (1). It costs one indexed count, discloses strictly less than the job page already does to the same person, and it does not touch the grant model at all.

---

Filed rather than fixed, because the decision is not mine. list-chrome flagged it rather than inventing a state on its own branch, which was the right call.