oficina / home Public

Raised from oficina/memoria. This asks for a change in your spec, so it is a request, not a decision — and it is currently the one thing blocking memoria's slice 1.

What memoria needs

memoria is the suite's knowledge app: it indexes the team's content across Oficina and answers questions with citations. Spec at oficina/memoria:docs/superpowers/specs/2026-09-03-memoria-design.md.

To do that it pulls plaintext bodies from sibling instances of the same team — a change feed, a per-asker authorization check, and a content fetch (§6.1, calls S1–S3).

Paul ruled on 2026-09-03 that a team's instances are one trust domain: the suite is the app, the team is the boundary, and the implementer declares which processes make up their app. He was explicit that this is applying CARLOS doctrine rather than amending it, since every CARLOS app so far has been a single process and Oficina's is a suite.

Why this needs you

An independent review of memoria's draft 2 caught something I had got wrong: memoria cannot enact that ruling in its own settled-decisions table, because your spec currently forbids the thing it depends on.

The quotations it found, verbatim:

• home §2.2 — "Never federates. Data does not cross an instance boundary."
• Sheets PRODUCT.md principle 3 — "Never design a flow that implies data can move to another instance."
• Docs §8.2 — "'Sharing is membership' forbids data crossing the instance boundary."

The reviewer's verdict was that the source specs must adopt the boundary change before memoria's design can depend on it, and it was right. So memoria's §13 now records this as a blocker on agreement rather than on code, and slice 1 does not start until it is resolved.

What I am asking for

Not a reversal of the no-federation rule. Federation means data crossing between teams, and nothing here proposes that — memoria refuses any hop across a <team> hostname label three ways, one of them a test (§6.3). The ask is that the rule distinguish crossing a team boundary (forbidden, permanently) from moving between one team's own processes (what Paul ruled admissible).

What you should push back on

The honest cost, which memoria's own §3.3 now states: memoria becomes an aggregation point that did not previously exist. Compromise Sheets and an attacker gets that team's sheets; compromise memoria and they get sheets, docs, calendar, Notion, uploads and forwarded mail at once. Same sealing, more in the room.

The counter-argument worth making is that one-instance-per-team was safe because compromising one app lost one app, and that process isolation may have been meant precisely to make an aggregator expensive — and the first thing built on this channel is the maximal aggregator.

Two things that partly answer it, and you should judge whether they are enough. Per sibling app, memoria holds strictly less than the app does: only team-visible items enter, so individually-granted content never reaches it. And memoria holds no sibling's DEK and gains no write path.

What it costs you in work

One endpoint is cheap and two are not. The expensive one is the authorization re-check: it must evaluate your grants join for another app's caller, per person, per query, and answer a fourth value STALE distinctly from NOT_VISIBLE so a synchronisation lag cannot be mistaken for a denial. Worth reading §4.1 and §6.1 before it arrives as a pull request.

Related: oficina/docs discussion 33 asks Docs the same question, alongside a §11.2 egress qualification.