amadan
🤖 spec: cite ruling 15 where it decides, at §5's custody mark
The A.4 review found ruling 15 listed as consumed in the status block and cited nowhere in the body — which is the drift ruling 7 exists to prevent, one level up: a spec that claims to consume a rule without depending on it anywhere has not consumed it. It belongs at §5, because that is where memoria decides what to hold. Only the `team` rung is team-visible, so custody keys on the rung and never on a read-only link. A link makes an item readable by whoever holds the URL, which is not the team being able to find it, and treating the two as the same would turn a capability held by whoever was sent it into a row every member reaches by search. Two consequences memoria has to carry rather than discover later. A `granted` item is outside custody EVEN WHEN THE ASKER HOLDS THE GRANT, which is why §4.1's intersection sits at the sibling and why a person can lose a passage here while the document stays open to them at the source. And `team` -> `granted` leaves custody: it arrives as `gone`, which §4.2 makes indistinguishable from deletion, so memoria deletes rather than downgrades. One thing left open and it is not memoria's: the doctrine's §14 records Paul as not having ruled on 15 while its §1 says he has. Cited here as §1 has it, with §13 asking someone to reconcile the doctrine with itself rather than resolving it from this side.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01H3VKtXnq6fSmM2F11Bjcsy
1 file changed,
+31
−13
docs/superpowers/specs/2026-09-03-memoria-design.md+31 −13
diff --git a/docs/superpowers/specs/2026-09-03-memoria-design.md b/docs/superpowers/specs/2026-09-03-memoria-design.md| index 228717c..67c8586 100644 |
| --- a/docs/superpowers/specs/2026-09-03-memoria-design.md |
| +++ b/docs/superpowers/specs/2026-09-03-memoria-design.md |
| @@ -9,13 +9,10 @@ provider, §8.4 shape, decisions 13–14, live-key verification, gate 17, |
| **Consumed suite rulings.** This spec consumes `oficina/suite` |
| `docs/superpowers/specs/2026-09-05-suite-sharing-doctrine.md` at |
| -**revision 7, commit `2b78680`**. Rulings 1, 3, 4, 6, 7, 9 and 14 are |
| -cited and never restated (suite ruling 7). **Ruling 15 (three rungs and a |
| -read-only link) is depended on and not yet cited in the body** — its |
| -"only the `team` rung is team-visible, so custody keys on the rung and |
| -never on the link" is what §5's custody mark should say, and does not. |
| -Owed; §13. Listing a ruling as consumed without a citation is the drift |
| -ruling 7 exists to prevent, one level up. Not consumed yet: the hand-off |
| +**revision 7, commit `2b78680`**. Rulings 1, 3, 4, 6, 7, 9, 14 and 15 are |
| +cited and never restated (suite ruling 7) — 15 at §5's custody mark, which |
| +is where "only the `team` rung is team-visible, so custody keys on the rung |
| +and never on the link" decides what memoria may hold. Not consumed yet: the hand-off |
| (suite §7) — §9.1 records why memoria refuses one built on its own |
| material — and S8, which needs a designated-area grant memoria has no UI |
| for. S6 is cited as a specification; suite §12 step 4 builds it. |
| @@ -935,6 +932,25 @@ admitted person still sees only what §4.1 and §4.2 allow. |
| team-visible. That mark is the *custody* gate of decision 3 — it bounds |
| what memoria holds. It is not the authorization gate; §4.1 is. |
| +**What "team-visible" means is suite ruling 15's, and it is narrower than |
| +it sounds.** An item sits on one of three rungs — *private*, *granted* to |
| +named people, or *team* — and **only the `team` rung is team-visible**. So |
| +custody keys on the rung and **never on a read-only link**: a link |
| +capability makes an item readable by whoever holds the URL, which is not |
| +the same as the team being able to find it. Treating a link as |
| +team-visible would turn a capability held by whoever was sent it into a |
| +row every team member reaches by search — which is the specific mistake |
| +ruling 15 rejects, and it would arrive here, at ingest, where memoria |
| +decides what to hold. |
| + |
| +Two consequences memoria must not paper over. A `granted` item is outside |
| +custody **even when the asker holds the grant**, which is why §4.1's |
| +intersection sits at the sibling and why a person can lose a passage here |
| +while the document stays open to them at the source. And an item that |
| +moves from `team` to `granted` leaves custody: it arrives as `gone` in S1, |
| +indistinguishable from deletion by §4.2's design, and memoria deletes |
| +rather than downgrades. |
| + |
| **From outside the suite:** an admin configures a connector, and the |
| sharing act at the far end is the publish. |
| @@ -2434,12 +2450,14 @@ commit. Fixed 2026-09-05; §1.7's lesson arriving inside the fix for §1.6.* |
| a reader and looks like a defect long before it looks like a ruling.** |
| Recorded in §9.1 and as a §12 row; the decision is Paul's. *(GPT-6's |
| review of the doctrine, finding 3, via A.4.)* |
| -- **Ruling 15 is consumed and not cited.** §5's custody mark should say |
| - what it says — only the `team` rung is team-visible, so custody keys on |
| - the rung and never on the read-only link — and does not. One paragraph, |
| - owed. Note the doctrine's own §14 still records Paul as not having ruled |
| - on 15 while its §1 says he has; cite it as §1 has it and do not resolve |
| - their disagreement from here. |
| +- ~~**Ruling 15 is consumed and not cited.**~~ **Closed 2026-09-05:** §5's |
| + custody mark now cites it, with the two consequences memoria has to |
| + carry — a `granted` item is outside custody even when the asker holds |
| + the grant, and `team` → `granted` leaves custody as a `gone` row that |
| + §4.2 makes indistinguishable from deletion. |
| + **Still open, and not memoria's to settle:** the doctrine's §14 records |
| + Paul as not having ruled on 15 while its §1 says he has. Cited here as |
| + §1 has it; someone should reconcile the doctrine with itself. |
| - **A `carlos/platform` discussion** noting the app boundary is the |
| implementer's to declare, and Oficina declares it at the suite — |
| informational, not a doctrine proposal (decision 2). |