amadan
The boundary test is two-sided, and sharing is not a divergence
Both corrections from docs-e6 reviewing as a declared consumer. The assertion boundary test had been written as "a claim may ride the assertion only if the instance would behave identically given a hostile value" — and theme, its own passing example, fails that as literally worded, since a hostile value produces an ugly page. A test whose example fails it is a gap a future reader smuggles something through. It also assumed the validation that made it true: a free-string theme interpolated into CSS is an injection, not an ugly page. The precise version is two-sided. A claim may ride the assertion only if the instance makes no trust decision based on it, validating against a closed enumerated set and treating a failed match as absent; AND the home already holds it for its own purposes, so carrying it adds nothing to what the home knows. Theme passes both. A role fails the first. A list of which documents you can see would pass the first and fail the second, handing the home a document-level graph it has no business holding — which is the constraint the one-sided test could not see. And the shared-instance decision is not a divergence. The instance boundary rule governs content and the home holds none; factor XI already says centralised infrastructure is glue. Writing an apology for it invites a reviewer to fix something working as designed. The correction worth keeping: blast radius is bounded by what a service holds, not by how many processes it runs in — this draft had reached for process isolation as the safety property when the real ones are the leak profile and the authorization re-check. Provisioning now leads with the structural argument rather than the definitional one: the home holds no provisioning credential, so an RCE on sign-in reaching instance creation is impossible by construction rather than unlikely by policy. Both questions are filed at carlos/pegamento #1 as proposed doctrine.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01APtNStXDZ5H2fAc1ZuGqtS
1 file changed,
+72
−27
docs/superpowers/specs/2026-08-30-home-design.md+72 −27
No CI script — run details
Intent
diff --git a/docs/superpowers/specs/2026-08-30-home-design.md b/docs/superpowers/specs/2026-08-30-home-design.md| index 816596f..0b971dc 100644 |
| --- a/docs/superpowers/specs/2026-08-30-home-design.md |
| +++ b/docs/superpowers/specs/2026-08-30-home-design.md |
| @@ -50,28 +50,45 @@ blind, replaceable* — and `AGENTS.md` opens with this rule verbatim. |
| ## 2. What the home is, and the divergence it requires |
| -The home is **one shared instance**, not one per account. That is a |
| -deliberate divergence from CARLOS's central shape and from rastrillo's own |
| -rule that *"a CARLOS app serves one team… isolation by process and file, |
| -never by WHERE clause."* |
| - |
| -**Why it is legitimate here.** The home is not an app; it is the glue |
| -between apps, and its whole purpose is answering questions that span |
| -instance boundaries. An instance-per-person home could not answer "which |
| -teams does this person belong to" without becoming the federation story |
| -Pegamento explicitly refuses. Pegamento's doctrine already sorts this: the |
| -**person-facing archetype** — registry, vault — is a shared service by |
| -construction, and the family runs four of them. |
| - |
| -**What the divergence costs, named rather than waved past.** The home has a |
| +The home is **one shared instance**, not one per account — and **this is not |
| +a divergence**, which the first draft got wrong by writing an apology for it |
| +(corrected by docs-e6, 2026-08-30; proposed as a doctrine ruling at |
| +`carlos/pegamento` #1). |
| + |
| +**The instance boundary rule governs content, and the home holds none.** |
| +Rastrillo's *"a CARLOS app serves one team… isolation by process and file, |
| +never by WHERE clause"* and Pegamento §1's four boundaries are all |
| +boundaries *around content*. A registry has nothing for the rule to bite on. |
| +Factor XI says it outright — *centralised infrastructure is glue: thin, |
| +blind, replaceable* — and centralised is in the sentence. Pegamento already |
| +assumes this without ruling it: §4 observes that Eleven's `home/` and Kass's |
| +`internal/store/` are the same service built twice, and neither is |
| +instance-per-person. |
| + |
| +Sharing is also what makes the service possible at all: an |
| +instance-per-person home could not answer "which teams does this person |
| +belong to" without becoming the federation story §3 refuses. |
| + |
| +**Blast radius is bounded by what a service holds, not by how many processes |
| +it runs in.** That sentence is the correction. This draft originally reached |
| +for process isolation as the safety property; for a service holding no |
| +content the safety properties are the leak profile (§3) and the |
| +authorization re-check (§6). |
| + |
| +**What sharing costs, named rather than waved past.** The home has a |
| suite-wide blast radius: it is the one process whose failure touches |
| -everybody. Three things bound it: |
| +everybody. Four things bound it, and the first two are structural rather |
| +than aspirational: |
| - **It holds no content.** The worst case is disclosure of §3's leak list, |
| not of anybody's work. |
| - **Losing it costs a convenience, not access** — for the directory (§6). |
| Sign-in is the exception, and §5 says so out loud rather than pretending |
| otherwise. |
| +- **Split origins mean a directory compromise reaches no credentials** (§4), |
| + and **every instance re-checks authorization on every request** (§6), so a |
| + compromised directory grants nothing. A compromised home costs the graph |
| + and a convenience outage. It does not cost a document. |
| - **It stays small.** Every proposed feature is weighed against "does this |
| belong in an instance instead?", and the answer is usually yes. A home |
| that grows features grows blast radius. |
| @@ -219,10 +236,28 @@ to hold an authorization model (§2), and a leaked assertion buys exactly |
| what a stolen session buys anyway — so narrowing reduces no blast radius |
| while adding a second assertion type and a second audience-binding surface. |
| -**The boundary test for any new claim**, so that line stays holdable: *a |
| -claim may ride the assertion only if the instance would behave identically |
| -given a hostile value.* A wrong theme is ugly; a wrong capability is a |
| -breach. Theme passes (§8); a role would not. |
| +**The boundary test for any new claim**, so that line stays holdable. It is |
| +**two-sided**, and the first draft wrote only the half it needed for theme |
| +(corrected by docs-e6, 2026-08-30): |
| + |
| +> A claim may ride the assertion only if **(a)** the instance makes no trust |
| +> decision based on it, validating it against a **closed enumerated set** and |
| +> treating a failed match as *absent* rather than as the raw value; **and |
| +> (b)** the home already holds it for its own purposes, so carrying it adds |
| +> nothing to what the home knows. |
| + |
| +Theme passes both. A role fails (a) — the instance grants on it. A list of |
| +"which documents you can see" would sail past (a) and fail (b), because it |
| +hands the home a document-level graph it has no business holding, which is |
| +§2's constraint rather than an instance concern. |
| + |
| +**Two things the first wording got wrong**, recorded so they are not |
| +reintroduced. "The instance would behave identically" is false even for |
| +theme — a hostile value produces an ugly page, which is different behaviour |
| +— and a test its own passing example fails is a gap a future reader smuggles |
| +something through. And "hostile value" silently assumed the validation that |
| +makes it safe: a free-string theme interpolated into CSS is an injection, |
| +not an ugly page. Hence the closed set in (a), stated rather than assumed. |
| ### 5.4 What the instance does with it |
| @@ -321,14 +356,24 @@ provisioning is not Pegamento, and flags Eleven's home — a blind vault *and* |
| a graph-aware provisioning broker in one binary — as "the one place |
| blindness breaks", adding "Pegamento does not repeat that conflation." |
| -The divergence is deliberate and bounded: the enqueue is opaque, reads |
| -nothing from the directory, stores its payload sealed and separately, and |
| -**the drain runs outside the home process entirely**, under a human's |
| -credential. The conflation the doctrine warns about is a *blind* service |
| -that also knows person↔instance — this home already knows person↔instance in |
| -the directory, which §6 discloses, so the enqueue adds no knowledge the |
| -service lacks. **Revisit trigger:** the queue moves to its own binary if the |
| -home ever grows a second reason to hold a console credential. |
| +**The load-bearing fact is that the home holds no provisioning credential.** |
| +The queue is opaque; the drain runs outside the home process entirely, under |
| +a human's console credential. So the genuinely dangerous version of the |
| +conflation — an RCE on an internet-facing sign-in surface reaching instance |
| +creation — is **impossible by construction, not unlikely by policy.** |
| + |
| +*(A secondary argument, kept because it is true and dropped as the lead |
| +because it is weaker: the conflation §9 warns about is a blind service that |
| +also knows person↔instance, and this home already knows person↔instance in |
| +the directory. That is an argument about what the doctrine meant, and a |
| +reviewer may simply disagree — where the credential argument survives any |
| +reading. docs-e6, 2026-08-30.)* |
| + |
| +Asked as a question at `carlos/pegamento` #1: if what §9 protects is the |
| +credential rather than the knowledge, the doctrine could say so — *a blind |
| +service may know that somebody asked for an instance; it may not be able to |
| +create one.* If instead the knowledge is the problem, the queue moves to its |
| +own binary. **Revisit trigger:** that ruling, either way. |
| --- |