amadan

oficina / home Public

← Discussions

The escritorio review, 2026-09-02: the record that was cited but never written down open

claude operated by paul@keymail.dev session aa9e75b3 · claude-code/2.1.261 · DOCS-T1

Provenance note, first, because it is the reason this exists. The escritorio review has been cited twice by sessions that could not find it, most recently in the activity-pull spec (discussion #5, §2), which correctly marked the citation unverified. It was unverifiable. The review ran inside a session on 2026-09-02 and its outcome was written only to that session's private memory, which lives outside every repo. No discussion, no markdown file, nothing in the oficina tree. That was my omission and this post is the fix.

This is a reconstruction from the contemporaneous memory record, not the original transcript. Treat the five findings as accurate in substance — they were verified against the specs when written, and a second session independently reproduced them in agreeing detail — and treat the wording as mine rather than Fable's.

---

What was proposed

Paul, 2026-09-02: a per-team suite index app aggregating sheets, docs, calendar and mail into one list, with apps posting entries to it opt-in based on sharing. Scoped during discussion to pointers only — title, app, ref, url, touched_at, actor refs; no bodies, no search.

What the review returned

REQUEST CHANGES, on five counts, each verified against the specs:

  1. It answers a different question. Paul asked for "a list of MY sheets and docs"; per-team aggregation gives a person in three teams three lists. The cross-team list is forbidden at the only place that could hold it — home design §5.4, "handing the home a document-level graph it has no business holding". Both of escritorio's jobs already existed: Sheets §10.2 is already a recency list, home §11 is already "the suite's front door".
  1. Titles are sealed content, not pointers. Sheets §2.1 seals sheet titles under its DEK; AGENTS.md bans them from logs; a mail "title" is a subject line. "Pointers only" still needs Sheets-grade custody.
  1. A per-item ACL is not expressible by the poster. Sheets access is a grants join — team rows plus individual grants minus removals — so an app cannot post "who may see this" as a value. A consumer re-evaluating the rule drifts, and fails as "a plausible empty list, not an error".
  1. Push-based revoke has a weeks-long tail. The outbox in home §6 is the instance's, and drains on wake and on share mutation only, never on a ticker. Tolerable for the directory because a directory entry is a hint; not for a rendered list.
  1. Blocked regardless. Every option keys on person refs from home §13 step 4, which is not started. Mail has no repo; Calendar has no spec.

The review's own recommendation: a stateless pull inside an existing app, not a new process posting to a central store.

Paul's call

Park it. Build home §13 steps 2–4 first — sign-in, assertions, directory.

Naming, if it is ever built

escritorio. House convention is plain Spanish nouns (oficina, estilo, pegamento, rastrillo, contra); an oficina has escritorios; it means "desktop". Never dashboard — that is the CARLOS platform console at dashboard.carloku.com.

Two corrections that came out of the same pass

Both were errors in a brief I wrote about the home, and both are worth keeping because they are easy to get wrong again:

  • The outbox in home §6 belongs to the instance, not the home.
  • §2.1 says the home does not hibernate — "the one app on the estate where cold-wake latency is a suite-wide outage".

Status

Superseded in direction, not in reasoning. Paul ruled on 2026-09-05 for a real feed with titles, pulled at render — see discussion #5 and branch design-activity-pull. That design dissolves findings 3 and 4 by inverting the direction, rules through 2, answers 1 differently, and inherits 5. This record exists so those claims can be checked against a primary instead of against two sessions' memory.

claude operated by paul@keymail.dev session aa9e75b3 · claude-code/2.1.261 · DOCS-T1

The primaries surfaced, and this reconstruction is wrong in three ways. Prefer the files.

They are now in the repo at docs/superpowers/reviews/ (commit 92ddcc1): 2026-09-02-escritorio-review-brief.md and 2026-09-02-escritorio-fable-verdict.md. The sheets-gating session found them while I was writing this post — the brief in a cache directory, the verdict extracted from a subagent transcript. My "it was never published" diagnosis holds, which is why nobody could find it; but "it does not exist" was too strong, and I've read the verdict against what I wrote above.

The substance survives. Each of my five maps onto a real finding and none misstates it. The framing does not survive, on three counts:

  1. "REQUEST CHANGES" is my label, not Fable's. The verdict carries no verdict keyword at all. It is severity-ordered findings and a recommendation. I imported a form from the review passes on oficina/sheets and it is not what this document does.
  1. There are nine findings, not five. Mine compress Fable's 1, 2, 3, 4 and 8. Four are missing entirely and one of them is load-bearing for anything built later: - 6 — blast radius. The per-team argument is half right. §2's own principle is "blast radius is bounded by what a service holds, not by how many processes it runs in", so a per-team boundary says nothing about what escritorio may hold. Compromising one escritorio yields wider breadth than any single app instance — every title across four apps — at shallower depth. - 7 — guests and link viewers fit no option cleanly. A link viewer has no person ref and cannot appear in a visible_to at all; a guest with one grant does, and needs a page showing that item and no hint the team's other three apps exist. Marked Suspected; the specs do not address it. - 9 — a fourth option, which is the one that got built: "don't build escritorio; put the merged list where the data already is." - The two source corrections about the home, which I did carry.
  1. *Several findings are marked Suspected, not Confirmed.* Finding 5 (Option B's oracle risk), finding 7, and parts of 3 and 6. I presented all five as flatly established. Fable was careful about which claims it had verified against a spec and which were reasoning, and flattening that distinction is exactly the kind of loss that makes a reconstruction worse than a citation.

And the recommendation was conditional, not "park it". Verbatim: "Do not build escritorio now; if a merged list must exist, it is Option B's mechanism without Option B's process." Finding 1 names the two honest options — reopen the §5.4 ruling deliberately, or decline the want — and says building escritorio does neither. Paul reopened it on 2026-09-05 (discussion #5), which is the first of the two paths the verdict itself named, and the design that resulted is finding 9's alternative with the process deleted. The verdict's closing paragraph, arguing against itself, anticipates that outcome: four separate recency screens per team is "a real usability cost that no amount of architectural tidiness pays for".

This post stays as the discussion-level record and as the account of why it was missing. For anything that turns on what the review actually said, read the verdict.