Review brief: escritorio's visibility model

You are reviewing a design decision that has not been made yet, not code. Your job is to attack three options, then recommend one. Be adversarial. A "looks fine" review is a failed review.

Read these first (do not trust this brief's summary of them)

• /home/paulca/amadan.net/oficina/home/docs/superpowers/specs/2026-08-30-home-design.md — the suite home's design. §0, §2.2, §3, §6 and ruling 9 are the load-bearing parts. Quote it rather than paraphrasing; do not invent rules it does not state.
• /home/paulca/amadan.net/oficina/home/AGENTS.md
• /home/paulca/amadan.net/oficina/sheets-core/AGENTS.md — the sibling app's binding rules, for house conventions.

What is being designed

escritorio — a proposed new app in the Oficina suite (sheets, docs, calendar, mail + the home). It is one instance per team, like Sheets is. It is the team's front door. It does two things:

1. Launch links out to Sheets, Docs, Calendar, Mail for that team.
2. Show one merged list of that team's items across those apps.

Settled already: the index is pointers only — title, app, item ref, URL, touched_at, actor person refs. No body text, no snippets, no cross-app full-text search. Adding body text later is a separate decision.

Why this app exists at all: the home is centralised and must stay blind (§0: "it never learns what is in anything"; §2.2: "Never renders content from an instance"). So the home can never show a merged document list. The claim being tested is that a per-team instance may hold what the centralised home may not, because it shares a blast radius with the content it indexes. Attack that claim first. If it is wrong, the whole app is wrong.

Platform constraints (verify against the specs, don't take my word)

• Apps are rastrillo apps and hibernate. A request wakes them; there are no timers while asleep. The home's spec drains its outbox "on wake and on each share mutation, not on a ticker" for exactly this reason.
• Identity comes from the home as an assertion; sub is an opaque person ref, stable across email change. Instances store person refs against grants.
• The home's directory is "a hint, never an authority" (ruling 9). Instances re-check authorization on every request.

The question

Escritorio must not show you the title of something you cannot see. Sheets and Docs are the authority on sharing. How does escritorio filter?

Option A — app posts the ACL; escritorio renders locally. Each pushed entry carries the person refs who may see it. Escritorio filters from its own copy. No network on page load. Escritorio holds the sharing graph. Between a revoke and the next push it can show a title to someone just un-shared.

Option B — escritorio asks the app at render time. Escritorio stores entries with no ACL. On each page load it asks each app "of these refs, which may this person see?" The app stays sole authority; a stale escritorio cannot leak. Page load fans out to ~4 apps, each of which may be hibernating.

Option C — Option A, plus revoke is a priority push. A revoke jumps the outbox rather than waiting for the next ordinary push. Lag becomes seconds. Escritorio still holds the graph.

Attack these specifically

1. Is the per-team-instance justification sound, or does escritorio just re-create the aggregation risk the home was designed to avoid, one team at a time? Does a team's escritorio have a larger blast radius than any single app instance, since it spans four of them?
2. Are titles actually low-value? "Q3 layoffs — final", "Acquisition of X — term sheet". Argue the case that pointers-only is not the cheap concession it appears to be, and say what that implies for the choice.
3. Option B and hibernation. Is a cold wake of four apps on every front-door load merely slow, or actually disqualifying? Does a short-TTL cache rescue it, and if so does the cache re-introduce exactly Option A's staleness — i.e. is B secretly A with worse latency?
4. Option C's priority push. Does it work when the receiver hibernates? Trace it. What happens to a revoke if escritorio is asleep, if the push fails, or if the pushing app dies mid-queue? Is "seconds" defensible or marketing?
5. Option A/C custody. Escritorio holding visible_to person-ref lists is a new copy of the sharing graph, per team. What does publishing escritorio's database reveal, in the home spec's own "publish the database and see" form? Write that sentence for each option.
6. The unit is per-TEAM, but the user's stated want was "a list of MY sheets and docs". A person in three teams gets three escritorios and still has no single list. Is per-team the right unit, or does this design answer a different question than the one asked? This may be the most important finding available to you — do not skip it.
7. Anything a fourth option would fix that none of A/B/C do. Propose it if you find one; say so plainly if you don't.
8. YAGNI. Should any of this be built now, or does the suite need the home's sign-in and directory (spec §13 steps 2–4) to exist first? Is escritorio blocked on work that has not started?

Output

• Findings, ordered by severity. For each: the claim, why it is wrong or risky, and what it costs. Mark each confirmed (you verified it against a file) or suspected (reasoning only).
• Then: one recommendation — A, B, C, or a fourth option — in a short paragraph, with the single strongest argument against your own choice stated honestly.
• Do not write code. Do not edit any file.