research: Federated Wiki deep dive (journal/fork/neighborhood); UC-70-72

SHARD-WP-0003 T1. Federation model (not a shard candidate): per-page
append-only semantic-action journal with story as derived replay,
fork-with-site-provenance, neighborhood/roster discovery + chorus of forks.
Prior art for shard-wiki's own pillars: coordination journal (UC-71),
overlay-before-mutation (UC-26 fork), union-without-erasure (UC-72).
Attach as REST/file-store hybrid (page JSON + CORS, UC-70). Feeds
SHARD-WP-0002 T1-T5, T11, T13, T16.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

spec/UseCaseCatalog.md

@@ -11,7 +11,8 @@ Promoted from `research/260608-c2-wiki-origins/`,
 `research/260614-notion-deep-dive/`, `research/260614-joplin-deep-dive/`,
 `research/260614-logseq-deep-dive/`,
 `research/260614-localfirst-workspaces-deep-dive/`,
-`research/260614-trilium-deep-dive/`, and `research/260614-wikijs-deep-dive/`.
+`research/260614-trilium-deep-dive/`, `research/260614-wikijs-deep-dive/`, and
+`research/260614-federated-wiki-deep-dive/`.
 See InfoTechPrimers on coulomb.social for use-case catalog conventions.
 
 ## Conventions
@@ -121,7 +122,11 @@ seed, or writable copy per policy — distinct from UC-04 (overlay without copy)
 and UC-03 (projection only). Fork vs overlay vs import decided in
 `SHARD-WP-0002`. Should record a **created-from genealogy edge** in the coordination
 journal so the lineage is navigable as a dimension (UC-49,
-`research/260614-zigzag-deep-dive/findings.md` §9).  
+`research/260614-zigzag-deep-dive/findings.md` §9). The fedwiki deep dive details the
+concrete shape: fork is **own-site-only write + a `fork` journal entry recording the source
+site**, and a forked journal stays **detailed enough to locate the upstream cut-point**
+(`research/260614-federated-wiki-deep-dive/findings.md` §2, §4) — enabling later
+carry-forward/re-fork (UC-28) and modelling the genealogy edge as **provenance** (UC-71/72).  
 **Priority:** Later
 
 ### UC-27 — View multiple versions of equivalent page
@@ -910,6 +915,58 @@ sub-mode beside Notion's REST.
 
 ---
 
+### UC-70 — Attach a Federated Wiki site as a shard (page JSON + CORS)
+
+**Actor:** Orchestrator / adapter  
+**Goal:** Attach a **Federated Wiki** site as a shard via its **page JSON** served over
+**HTTP with CORS** (`/<slug>.json`); project its pages and **fork** them to overlay
+non-destructively.  
+**Source:** federation, intent  
+**Notes:** A fedwiki site is a sovereign server (Node.js, static-file, or serverless)
+serving `{ title, story[], journal[] }` page JSON
+(`research/260614-federated-wiki-deep-dive/findings.md` §1, §3). A **REST/file-store
+hybrid** attachment mode: CORS-readable JSON over HTTP, or a static pile of `.json` files.
+Writes are **own-site-only** — to change a remote page you **fork** it (UC-26), so this
+shard is naturally a read/project + overlay target, never silent remote mutation. Feeds
+SHARD-WP-0002 T14 (attachment mode), T11 (capability profile).  
+**Priority:** Later
+
+### UC-71 — Coordination journal as an append-only semantic-action log with provenance
+
+**Actor:** Core orchestrator  
+**Goal:** Model the coordination journal as a **per-page append-only log of semantic
+actions** (`create`/`add`/`edit`/`move`/`remove`/`fork`) carrying **provenance entries**
+(fork records the source site), with the page state **derived by replaying** the log and
+divergence **located by comparing** logs.  
+**Source:** federation, intent  
+**Notes:** Directly adopts the fedwiki **journal** shape — the story is a materialized
+view of the journal, fork entries serialize a **provenance DAG**, and per-entry sequence
+numbers make the fork cut-point identifiable
+(`research/260614-federated-wiki-deep-dive/findings.md` §2, §6). This is concrete prior art
+for INTENT's coordination journal: a **third merge model** beside git 3-way and CRDT
+auto-merge — a coarse semantic op-log applied manually via fork. Feeds SHARD-WP-0002 T13
+(history portability / merge model) and T1–T5 (federation).  
+**Priority:** Later
+
+### UC-72 — Federate by fork-with-provenance across a neighborhood / chorus
+
+**Actor:** Reader / curator  
+**Goal:** Assemble a **union from sovereign peer shards** discovered by **link and fork**
+(a *neighborhood*) or by an explicit **roster**, **search across that set**, and preserve a
+**chorus of co-equal, provenance-linked versions** without forcing a canonical — pulling
+another's changes by forking them.  
+**Source:** federation, intent  
+**Notes:** Fedwiki's neighborhood (dynamic, link/fork-discovered) vs roster (curated)
+membership and "chorus of voices" no-canonical stance
+(`research/260614-federated-wiki-deep-dive/findings.md` §3, §4) model
+**union-without-erasure** at the coordination layer: divergence is normal and visible,
+reconciliation is an explicit human/policy step (mechanism over policy). Open: does a
+chorus compose with shards that assert a canonical? Feeds SHARD-WP-0002 T1–T5; relates
+UC-05/UC-27 (union/chorus), UC-26 (fork).  
+**Priority:** Later
+
+---
+
 ## B. Knowledge work and collaboration
 
 *Patterns from c2 social conventions and yawex authoring workflows.*
@@ -1170,6 +1227,9 @@ CamelCase and `[[free links]]`. Markdown-first link semantics TBD.
 | UC-67 | | | | ⊕ | ✓ |
 | UC-68 | | | | ⚓ | ✓ |
 | UC-69 | | | | ⚓ | ✓ |
+| UC-70 | | | ✓⊞ | | ✓ |
+| UC-71 | | | ✓⊞ | | ✓ |
+| UC-72 | | | ✓⊞ | | ✓ |
 | UC-08 | ✓ | | |
 | UC-09 | ✓ | | |
 | UC-10 | ✓ | | |
@@ -1578,6 +1638,38 @@ layer. Architecture logged for `SHARD-WP-0002` (T11/T14): storage-module abstrac
 second adapter-contract prior art, engine-maintained Git mirror as attach+write surface,
 GraphQL introspection for capability discovery + selective projection.
 
+### federated-wiki mapping
+
+(⊞ UC-70–UC-72 are placed in the **federation** matrix column — Federated Wiki was first
+surfaced in `research/260608-federation-concepts/` — but their deepened lineage is the
+**Federated Wiki deep dive**, `research/260614-federated-wiki-deep-dive/findings.md`.)
+
+| Federated Wiki mechanism (findings §) | Catalog UC |
+|---------------------------------------|------------|
+| Page JSON `{title, story[], journal[]}` over HTTP+CORS; static-file sites (§1, §3) | UC-70 (new) |
+| Per-page append-only **journal** of semantic actions; story = derived replay; `fork` = provenance entry (§1, §2) | UC-71 (new) |
+| **Neighborhood** (link/fork-discovered) + **roster** (curated) + chorus of forks (§3, §4) | UC-72 (new) |
+| **fork** = non-destructive copy with source-site attribution (§2, §4) | UC-26 (enriched) |
+| Forked journal carries upstream cut-point → carry-forward + re-fork (§2) | UC-28 (enriched) |
+| **Happenings** = time-bounded collaboration leaving durable forks (§3) | UC-30 (enriched) |
+| Chorus of co-equal, provenance-linked versions; no canonical (§4) | UC-05 / UC-27 (enriched) |
+| Story-item (paragraph) write granularity; stable 16-hex item `id` (§1, §5) | links UC-35 |
+| Journal-replay op-log = third merge model (vs git 3-way, CRDT) (§5, §8) | links UC-36 / UC-64 |
+
+Note: Federated Wiki is the one studied system whose *core job is shard-wiki's own* — a
+**union of pages from sovereign sites preserving provenance, assembled non-destructively**.
+It is therefore prior art not for a *shard* but for three of our **pillars**: the
+**coordination journal** (its per-page append-only **journal** of semantic actions, with
+the **story** as a derived replay view, UC-71), **overlay-before-mutation** (its **fork** —
+own-site-only writes, source-site attribution, UC-26), and **union-without-erasure** (its
+**neighborhood/roster** membership and **chorus** of provenance-linked forks, UC-72). As a
+shard it attaches as a **REST/file-store hybrid** (page JSON + CORS, UC-70). **Boundary
+recorded:** adopt the *model* (journal shape, fork-with-provenance, neighborhood) not the
+client-only union-assembly locus or slug-as-identity; layer our cross-shard identity (T16)
+above fedwiki's fork-DAG provenance edges. Architecture logged for `SHARD-WP-0002`
+(T1–T5, T11, T13, T16): journal-as-coordination-journal, story-item write granularity,
+journal-replay as a third merge model, fork entries as identity≠placement provenance edges.
+
 ---
 
 ## Open questions
@@ -1630,5 +1722,9 @@ GraphQL introspection for capability discovery + selective projection.
     live from the shard's tree/templates, and how is per-attribute provenance recorded?
 22. For an **engine-maintained Git mirror** (UC-68), is the mirror or the engine DB the
     source of truth, and how do we write-by-commit without racing the engine's own sync?
+23. Should the **coordination journal** (UC-71) adopt fedwiki's exact semantic-action
+    vocabulary (create/add/edit/move/remove/fork) at item granularity, or an abstract op
+    set other shards can also emit — and does a **chorus / no-canonical** union (UC-72)
+    compose with shards that assert a canonical? (Federated Wiki dive §9.)
 23. How does shard-wiki **honor/surface a shard's path-based access rules** (UC-06) in a
     projection without re-implementing its ACL engine? (Wiki.js dive §9.)