# 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.