spec: promote federation UCs; add SHARD-WP-0002 architecture workplan

Promote UC-26 through UC-33 from federation research into UseCaseCatalog.
Add SHARD-WP-0002 with ten decision topics (remix primitives, equivalent
page identity, history, composition, notification, lifecycle, transclusion,
consensus presets, capability matrix) targeting spec/FederationArchitecture.md.

SCOPE.md

@@ -19,10 +19,10 @@ Learnings update both SCOPE and INTENT where necessary.
 |-------|-------|
 | Code | Python package scaffold (`src/shard_wiki/`, smoke tests only) |
 | Intent | `INTENT.md` established; authorization-in-core amendments drafted |
-| Research | yawex prior-art exploration (`research/260608-yawex-prior-art/`) |
+| Research | yawex prior art; c2 origins; federation concepts; wikiengines overview (`research/260608-*/`) |
 | Demand | NetKingdom integration asks captured, not yet negotiated |
-| Spec | Access/history architecture blueprint drafted; PRD/TSD/UCC scaffolds |
+| Spec | Architecture blueprint drafted; UseCaseCatalog 25 UCs from research; PRD/TSD scaffolds |
-| Work | `SHARD-WP-0001` active — 6 design tasks, all todo |
+| Work | `SHARD-WP-0001` active (6 tasks); `SHARD-WP-0002` active (10 tasks) |
 
 ## In Scope (today)
 
@@ -52,6 +52,9 @@ live in core.
 
 ## Current Planning
 
-Design work is tracked in `workplans/SHARD-WP-0001-yawex-requirements.md`.
+Design work is tracked in `workplans/SHARD-WP-0001-yawex-requirements.md`
-Specification outputs from that workplan land in `spec/`. Inbound integration
+(yawex-derived resolution, namespaces, overlays) and
-asks remain in `demand/` until reviewed and promoted into spec or workplans.
+`workplans/SHARD-WP-0002-federation-architecture.md` (federation architecture,
+decisions, tradeoffs). Specification outputs land in `spec/`. Inbound
+integration asks remain in `demand/` until reviewed and promoted into spec or
+workplans.

research/260608-c2-wiki-origins/README.md

@@ -0,0 +1,23 @@
+# 260608 — c2 wiki origins (Ward Cunningham)
+
+Date: 2026-06-08
+
+## What this is
+
+Research into the beginnings of the wiki movement through Ward Cunningham,
+the Portland Pattern Repository, and the original **WikiWikiWeb** at c2.com.
+
+Focus: popular terms, social conventions, and documented use cases from and
+about the c2 wiki. **Federation is explicitly out of scope** for this
+exploration (separate research planned).
+
+## Contents
+
+| Path | Role |
+|------|------|
+| `findings.md` | Terms glossary, use-case catalog, design principles, sources |
+
+## Status
+
+Initial exploration complete. Findings may inform `spec/` and future
+workplans; not yet promoted to specification.

research/260608-c2-wiki-origins/findings.md

@@ -0,0 +1,327 @@
+# Findings — Ward Cunningham, c2 wiki, and wiki movement origins
+
+Date: 2026-06-08 · Status: research draft
+
+Scope: beginnings of the wiki movement via the **WikiWikiWeb** (c2.com) and
+its creator **Ward Cunningham**. Emphasis on terms and use cases documented
+in and about the c2 wiki. **Federation concepts are out of scope here.**
+
+---
+
+## 1. Historical anchor
+
+| Fact | Detail |
+|------|--------|
+| First wiki | WikiWikiWeb — launched **25 March 1995** on c2.com |
+| Creator | Ward Cunningham (Cunningham & Cunningham, Portland, Oregon) |
+| Companion site | [Portland Pattern Repository](http://c2.com/ppr/) (PPR) |
+| PPR motto | **"People, Projects & Patterns"** |
+| Original software | Perl CGI script named `wiki`; later called **WikiBase** |
+| Intellectual roots | HyperCard stacks (late 1980s); pattern languages (Cunningham & Beck, OOPSLA 1987, inspired by Christopher Alexander) |
+| Name origin | Hawaiian *wiki* = "quick"; *wiki wiki* = "very quick" — from Honolulu airport Wiki Wiki Shuttle |
+| Intended name alternative | "QuickWeb" rejected in favor of **WikiWikiWeb** as more fun to say |
+| Capital-W convention | **Wiki** (capital W) = this original site; lowercase *wiki* = the technology genre |
+
+Ward's stated purpose (WikiHistory, 2002): make exchange of ideas between
+programmers easier. The wiki was an **automated supplement** to the Portland
+Pattern Repository, not a replacement encyclopedia.
+
+By 2015 the site went read-only after vandalism; Ward migrated toward
+Federated Wiki. That later history is **not** covered here.
+
+---
+
+## 2. What c2 said it was for (primary use cases)
+
+From **WelcomeVisitors**, **WikiHistory**, and community self-description:
+
+### Core mission use cases
+
+1. **Pattern exchange** — publish, discuss, and refine software design patterns
+   (the PPR mission).
+2. **People + projects + patterns** — connect practitioners, project experience,
+   and reusable design knowledge (`PeopleProjectsAndPatterns`).
+3. **Idea exchange among programmers** — fast, lightweight collaborative
+   writing; "a forum where people share ideas."
+4. **Informal history of programming ideas** — accumulated narrative, not a
+   formal reference work (`InformalHistoryOfProgrammingIdeas`).
+5. **Distillation of experience into patterns** — thread discussions refined
+   into document-mode consensus, sometimes culminating in patterns
+   (`ThreadMode` → `DocumentMode` → `PatternMode`).
+
+### Community / onboarding use cases
+
+6. **First wiki experience** — deliberate onboarding path for newcomers
+   (`WelcomeVisitors`, `NewUserPages`, `WikiWikiSandbox`).
+7. **Sandbox experimentation** — safe place to learn editing mechanics.
+8. **Visitor presence** — sign the guest book (`RecentVisitors`).
+9. **Culture acclimation** — expect `CultureShock`; learn local conventions
+   before adding pages.
+
+### Knowledge maintenance use cases
+
+10. **Self-indexing** — wiki indexes itself; community maintains structure
+    (`VolunteerHousekeeper`, categories, road maps).
+11. **Activity awareness** — follow what changed (`RecentChanges`,
+    `QuickChanges`, `RecentChangesJunkie`).
+12. **Discovery** — browse by search, categories, random pages, visual tour,
+    like-pages, starting points.
+13. **Refactoring pages** — merge thread into document, split tangents,
+    improve clarity (`ReFactoring`, `WikiMaster` role).
+14. **Work-in-progress knowledge** — all content explicitly provisional
+    (`WorkInProgress`).
+
+### What c2 explicitly said it was *not*
+
+- **Not Wikipedia** — subjective, conversational, not a dedicated reference
+  site (`WikiIsNotWikipedia`, `WikiPedia` as pointer to the real Wikipedia).
+- **Not a polished encyclopedia** — "Most of all, this is a forum where
+  people share ideas!"
+
+### Subject areas the community grew into (approximate eras, WikiHistory)
+
+| Era | Dominant topics on c2 |
+|-----|----------------------|
+| 1994+ | Patterns, sources, application |
+| 1996+ | General design, architecture, methods |
+| 1997+ | People and organizational aspects of programming |
+| 1998+ | Extreme Programming |
+| 2000+ | Wiki itself (meta-discussion) |
+
+Popular page clusters noted by observers: **DesignPatterns**, **ExtremeProgramming**, **TestDrivenDevelopment**, **AgileManifesto**, **UnitTest**, **AntiPattern**, build tools, languages, organizational culture.
+
+---
+
+## 3. Ward's WikiDesignPrinciples (1995 intent)
+
+From Ward Cunningham's reconstructed **WikiDesignPrinciples** page:
+
+| Principle | Meaning |
+|-----------|---------|
+| **Open** | Incomplete or poorly organized pages may be edited by any reader |
+| **Incremental** | Pages cite other pages, including ones not yet written |
+| **Organic** | Site structure is editable and evolves like page text |
+| **Mundane** | Small number of irregular text conventions for markup |
+| **Universal** | Editing and organizing use the same mechanisms as writing |
+| **Overt** | Formatted output suggests the input needed to reproduce it |
+| **Unified** | Page names from a flat namespace — no extra context to interpret |
+| **Precise** | Titles are precise noun phrases to avoid name clashes |
+| **Tolerant** | Interpretable behavior preferred over error messages |
+| **Observable** | Site activity can be watched and reviewed by any visitor |
+| **Convergent** | Duplication discouraged by finding and citing related content |
+
+Ward later noted additional forced principles (e.g. server robustness) beyond
+the original eleven.
+
+---
+
+## 4. Popular terms glossary
+
+Terms below are **CamelCase page names** as used on c2 unless noted.
+
+### Wiki mechanics & naming
+
+| Term | Meaning on c2 |
+|------|---------------|
+| **Wiki** / **WikiWikiWeb** | The first wiki site; capital-W Wiki = this site specifically |
+| **WikiBase** | The Perl wiki engine behind c2 |
+| **WikiWord** / **WikiWords** | MixedCase token the engine treats as a hyperlink |
+| **WikiName** / **WikiNames** | Page title / link target (often built from WikiWords) |
+| **MixedCase** / **CamelCase** | CapitalizedWordsRunTogether → automatic link |
+| **TextFormattingRules** | Minimal markup conventions (paragraphs, bold, links) |
+| **EditText** / **EditCopy** | Core edit operations |
+| **Undefined page** / **red link** | `PageName?` with `?` — page does not exist yet; click to create |
+| **Flat namespace** | All page names in one space (no hierarchical paths) |
+
+### Content modes (social conventions, not software features)
+
+| Term | Meaning |
+|------|---------|
+| **DocumentMode** | Third-person, unsigned, community-owned text; consensus artifact |
+| **ThreadMode** | Signed, first-person discussion; conversation thread |
+| **PatternMode** | Distilled pattern statements from converged discussion |
+| **OpeningStatement** | Strong initial claim/question that frames a page |
+| **SignedDocumentMode** | Hybrid: document-like but attributed |
+| **ThreadModeConsideredHarmful** | Community norm pushing toward document mode |
+| **InFavorOfDissertation** | Ward's preference for essay-like pages over dialog |
+
+### Roles & community behavior
+
+| Term | Meaning |
+|------|---------|
+| **WikiMaster** | Person who refactors threads into documents (anyone can be one) |
+| **VolunteerHousekeeper** | Community members who maintain indexes and hygiene |
+| **RecentChangesJunkie** | Person who obsessively monitors RecentChanges |
+| **InvitedAuthors** | Early contributors who bootstrapped site culture |
+| **GoodStyle** | Ward's editing advice: factual, concrete, civil, flow over chronology |
+| **ReFactoring** / **RefactorMercilessly** | Rewrite pages for clarity; merge/split threads |
+| **RefactorDontDelete** | Prefer refactoring over deletion |
+| **CultureShock** | Newcomer disorientation from wiki norms |
+
+### Navigation & derived views
+
+| Term | Meaning |
+|------|---------|
+| **RecentChanges** | Chronological edit log — central community nerve center |
+| **QuickChanges** | Short-form recent changes |
+| **RecentEdits** | Minor edits stream |
+| **NotSoRecentChanges** | Older change archives |
+| **FindPage** | Search |
+| **LikePages** | Similar-title suggestions |
+| **RandomPages** | Serendipitous browse |
+| **VisualTour** | Graphical browse aid |
+| **StartingPoints** | Curated entry paths |
+| **WikiCategories** / **RoadMaps** | Community-maintained indexes |
+| **PeopleIndex** / **RecentVisitors** | Who participates |
+| **BackLinks** | Pages linking here (classic derived view) |
+| **AllPages** / **SiteMap** / **SearchPage** | Core derived pages (also present in yawex prior art) |
+| **SisterSites** | Links to other wikis |
+
+### Pattern & programming vocabulary (c2's dominant content)
+
+| Term | Meaning |
+|------|---------|
+| **Pattern** / **DesignPatterns** | Reusable design solution in context |
+| **AntiPattern** | Common bad solution |
+| **ProtoPattern** | Pattern-in-formation |
+| **PortlandPatternRepository** | Pattern submission/distribution site |
+| **PeopleProjectsAndPatterns** | c2's thematic focus |
+| **ExtremeProgramming** / **AgileManifesto** | Major c2 discourse topics (late 1990s–2000s) |
+| **CrcCards** | Design technique; also spawned from Ward's HyperCard work |
+
+### Meta & identity pages
+
+| Term | Meaning |
+|------|---------|
+| **WorkInProgress** | Nothing is finished; everything editable |
+| **WikiIsNotWikipedia** | Identity boundary vs encyclopedic wikis |
+| **WhyWikiWorks** / **WhyWikiWorksNot** | Community theory of success/failure |
+| **WikiZen** | Cultural / philosophical reflection |
+| **WikiOnWiki** | Meta-discussion about wiki itself (sometimes controversial) |
+
+---
+
+## 5. Documented editing & collaboration patterns
+
+From **ThreadMode**, **DocumentMode**, **GoodStyle**, **WhyWikiWorks**:
+
+### ThreadMode contributions (ADD / EDIT / SPLIT / CAPTURE)
+
+1. **ADD** — append signed comment to continue conversation.
+2. **EDIT** — improve flow of others' signed comments (with care).
+3. **SPLIT** — separate tangents onto new pages with summary links.
+4. **CAPTURE** — distill converging ideas into anonymous pattern paragraphs.
+
+### DocumentMode lifecycle
+
+- Page opens with strong **OpeningStatement**.
+- Feedback arrives in ThreadMode.
+- On consensus, a **WikiMaster** (or anyone) replaces thread with
+  DocumentMode synthesis.
+- Newcomers are expected to **rewrite** unclear passages rather than stack
+  clarifying replies.
+
+### WhyWikiWorks (community theory)
+
+Paradoxical strengths cited on c2:
+
+- Anyone can delete anything → only meaningful content survives curation.
+- Low WYSIWYG appeal → filters out drive-by noise; participants self-select.
+- Slow, considered edits → pages evolve over days/weeks.
+- Pedantic community → shared professional camaraderie.
+- "Insecure, indiscriminate, user-hostile, slow" — yet it worked *because*
+  other online communities optimized differently.
+
+---
+
+## 6. Technical & formatting conventions (original c2)
+
+From Ward's etymology correspondence and c2 pages:
+
+- **Double conventions as formatting clues:**
+  - double carriage-return → new paragraph
+  - double single-quote → italic
+  - double capitalized-word (CamelCase) → hyperlink
+- **Flat page namespace** — precise noun-phrase titles.
+- **Minimal markup** — "mundane" rules; overt correspondence between input
+  and rendered output.
+- **Optional attribution** — `UserName` (2000+) to attach edits to a name
+  instead of IP; signing in ThreadMode remained common.
+- **Deletion** — supported but culturally discouraged vs refactoring
+  (`RefactorDontDelete`).
+
+---
+
+## 7. Use-case patterns worth naming (synthesis)
+
+Grouping c2-documented uses into reusable patterns:
+
+| ID | Use-case pattern | c2 evidence |
+|----|------------------|-------------|
+| UC-C2-01 | **Quick idea capture** | Wiki = quick web; incremental linking to unwritten pages |
+| UC-C2-02 | **Collaborative glossary** | Flat namespace of precise terms; WikiWords as vocabulary |
+| UC-C2-03 | **Discussion → consensus doc** | ThreadMode → DocumentMode refactoring |
+| UC-C2-04 | **Pattern mining** | Thread → PatternMode distillation |
+| UC-C2-05 | **Community guest book** | RecentVisitors, people pages |
+| UC-C2-06 | **Change radar** | RecentChanges / QuickChanges monitoring |
+| UC-C2-07 | **Self-curating knowledge base** | Open editing + convergent deduplication |
+| UC-C2-08 | **Sandbox learning** | WikiWikiSandbox for safe first edits |
+| UC-C2-09 | **Serendipitous browse** | RandomPages, VisualTour, LikePages |
+| UC-C2-10 | **Practitioner field notes** | InformalHistoryOfProgrammingIdeas, not encyclopedia |
+| UC-C2-11 | **Team memory for methods** | XP, TDD, patterns, tools discourse |
+| UC-C2-12 | **Soft creation of missing topics** | Red-link `?` pages created on first write |
+
+---
+
+## 8. Boundaries for shard-wiki (light notes, not federation)
+
+Items from c2 origins that align with existing `INTENT.md` themes **without**
+entering federation design:
+
+- **Open editing + recoverable history** — c2 trusted the community; shard-wiki
+  INTENT makes Git history the safety net (stronger than c2's soft norms).
+- **WorkInProgress** — matches overlay/provenance/freshness thinking.
+- **Mechanism over policy** — c2 used social conventions (DocumentMode,
+  GoodStyle) rather than hard gates; shard-wiki keeps policy configurable.
+- **Not an encyclopedia** — c2's `WikiIsNotWikipedia` parallels shard-wiki not
+  owning universal ontology.
+- **Derived views** — BackLinks, RecentChanges, AllPages, SiteMap, Search were
+  first-class on c2; already flagged in yawex research as union-view candidates.
+- **Flat namespace + CamelCase links** — original c2 model; shard-wiki is
+  Markdown-first (wikilink extension question remains open).
+
+**Deferred:** Federated Wiki, sister sites, multi-wiki configuration — separate
+research track.
+
+---
+
+## 9. Sources
+
+| Source | URL / location |
+|--------|----------------|
+| Ward — WikiHistory | https://wiki.c2.com/?WikiHistory (archive 2002) |
+| Ward — WikiDesignPrinciples | https://wiki.c2.com/?WikiDesignPrinciples (archive 2002) |
+| Ward — etymology correspondence | https://c2.com/doc/etymology.html |
+| WelcomeVisitors | https://wiki.c2.com/?WelcomeVisitors (archive 2002) |
+| DocumentMode | https://wiki.c2.com/?DocumentMode (archive 2002) |
+| ThreadMode | https://wiki.c2.com/?ThreadMode (archive 2002) |
+| GoodStyle | https://wiki.c2.com/?GoodStyle (archive 2002) |
+| WhyWikiWorks | https://wiki.c2.com/?WhyWikiWorks (archive 2002) |
+| RecentChanges | https://wiki.c2.com/?RecentChanges (archive 2002) |
+| Wikipedia — WikiWikiWeb | https://en.wikipedia.org/wiki/WikiWikiWeb |
+| Wikipedia — Portland Pattern Repository | https://en.wikipedia.org/wiki/Portland_Pattern_Repository |
+| Observer summary — T.J. Maher (2016) | https://www.tjmaher.com/2016/06/time-capsule-ward-cunninghams-wiki-wiki.html |
+
+---
+
+## 10. Open questions (for later spec work)
+
+1. Which c2 **social conventions** (DocumentMode, GoodStyle, WikiMaster
+   refactoring) belong in shard-wiki core vs reference UI vs `wiki/` content?
+2. How much of the **flat CamelCase namespace** survives in a Markdown-first,
+   path-oriented federation model?
+3. Which **derived views** from c2 are MVP for an orchestrator vs adapter-provided?
+4. Does shard-wiki want an explicit **WorkInProgress / WikiIsNotWikipedia**
+   stance in `spec/ProductRequirementsDocument.md`?
+5. How does c2's **open-by-default** community norm relate to shard-wiki's
+   L0 mode — coincidence of values or intentional lineage?

research/260608-federation-concepts/README.md

@@ -0,0 +1,28 @@
+# 260608 — Federation concepts for unified information spaces
+
+Date: 2026-06-08
+
+## What this is
+
+Research into **federation models** for decentralized but unified knowledge
+spaces — with emphasis on **Federated Wiki** (Ward Cunningham, ~2011+) and
+comparable approaches (git-backed wikis, ActivityPub, Xanadu patterns, yawex
+REMOTE/VIRTUAL).
+
+Complements `research/260608-c2-wiki-origins/` (pre-federation wiki culture)
+and `research/260608-yawex-prior-art/` (Perl engine resolution states).
+
+Focus: terms, architectural patterns, and **mapping to `shard-wiki` INTENT**
+— not implementation specification.
+
+## Contents
+
+| Path | Role |
+|------|------|
+| `findings.md` | Glossary, model comparison, shard-wiki mapping, open questions, sources |
+
+## Status
+
+Initial exploration complete. Use cases promoted to `spec/UseCaseCatalog.md`
+(UC-26–UC-33). Federation architecture design tracked in
+`workplans/SHARD-WP-0002-federation-architecture.md`.

research/260608-federation-concepts/findings.md

@@ -0,0 +1,409 @@
+# Findings — Federation concepts for decentralized, unified information spaces
+
+Date: 2026-06-08 · Status: research draft
+
+Scope: federation models that let independently stored knowledge participate in
+a **joined view** without erasing provenance, sovereignty, or backend
+differences. Primary anchor: **Federated Wiki** and Ward Cunningham's
+post-c2 inversion. Secondary: git-backed wikis, ActivityPub wiki extensions,
+Xanadu hypertext patterns, and yawex multi-wiki resolution.
+
+**Complements:** `research/260608-c2-wiki-origins/` (federation explicitly
+deferred there) and `research/260608-yawex-prior-art/` (REMOTE/VIRTUAL as
+adapter foreshadowing).
+
+---
+
+## 1. Why federation (the problem statement)
+
+Centralized wikis concentrate **meaning** and **records** on one server:
+
+| Problem | Manifestation |
+|---------|---------------|
+| **Ownership** | Contributors build on someone else's host; site shutdown = loss risk |
+| **Consensus pressure** | Early edits must survive notability/deletion fights (Wikipedia model) |
+| **Heat death** | Bounded communities exhaust their charter; maintenance mode → colony collapse |
+| **Reuse friction** | Copy-paste HTML/DB content across sites is slow, lossy, attribution-prone |
+| **Backend lock-in** | One engine, one storage model, one permission model |
+
+Federation responses split along two axes:
+
+1. **Where records live** — per-user site, per-instance repo, personal pod, mirrored git clone.
+2. **How unity is achieved** — fork + spread, git push/pull, protocol activities, projection/cache, orchestrated union.
+
+`shard-wiki` (per `INTENT.md`) targets axis (2) via an **orchestration layer**
+over heterogeneous **shards**, with Git as coordination substrate — not a
+single federation mechanism.
+
+---
+
+## 2. Federated Wiki (Smallest Federated Wiki / SFW)
+
+### 2.1 Historical anchor
+
+| Fact | Detail |
+|------|--------|
+| Origin | Ward Cunningham; launched at IndieWebCamp 2011 |
+| Motivation | Regret that c2's 35,000+ pages lived on Ward's server, not contributors' |
+| c2 migration | WikiWikiWeb moved to Federated Wiki ~2015 after read-only period |
+| GitHub lineage | Fork button inspired by GitHub; "radical code sharing" as model |
+| Current code | [github.com/fedwiki/wiki](https://github.com/fedwiki/wiki) (CoffeeScript; active releases through 2025) |
+
+Ward's framing (Wired, 2012): the wiki's radical idea was an **edit button on
+every page**; federated wiki's radical idea is a **fork button on every page**.
+
+### 2.2 Inverted architecture
+
+Traditional wiki vs federated wiki (Caulfield, NWACC 2014, summarizing Ward):
+
+```
+Traditional:  many people → one server → server owns records → consensus on server
+Federated:    many people → many servers → each owns records → browser composes union
+```
+
+**Meaning is made in the browser.** The client pulls JSON page records from
+multiple origins (CORS) and presents them as one navigable space. Consensus
+emerges through **which versions spread** across the network, not through a
+single server arbiter.
+
+### 2.3 Page model (JSON + journal)
+
+From [viki.wiki JSON schema](https://viki.wiki/json-schema.html):
+
+```
+page = { title, story, journal }
+story = [ item ]           # paragraph-like plugin items
+journal = [ action ]       # edit history that reconstructs story
+action.type = create|add|move|edit|remove|fork
+action.site = origin host  # present when content came from elsewhere
+```
+
+Key properties:
+
+| Property | Implication |
+|----------|-------------|
+| **Data files, not DB render** | Fork copies JSON, not scraped HTML — reuse stays structured |
+| **JSON items, not HTML** | Target site re-renders via plugins; display differences don't break remix |
+| **Journal travels with page** | Attribution/history portable; no separate blame log |
+| **Plugin architecture** | Item `type` selects renderer; missing plugins surfaced to user |
+| **Fork action** | Whole-page copy from remote site into local site with provenance |
+| **Item IDs preserved** | Stable anchors through edits; aliasing guards duplicate IDs |
+
+### 2.4 Interaction patterns
+
+| Pattern | Behavior |
+|---------|----------|
+| **Fork** | Copy remote page to your site; edit locally; original owner may merge back |
+| **Drag-and-drop fork** | Cross-site page transfer in ~15 seconds (OER case) |
+| **Chorus of voices** | Multiple versions of "same" topic coexist; linked, not merged by default |
+| **Neighborhood / river** | Discovery via recent changes across federated sites (e.g. fedwikiriver.com) |
+| **Happening** | Time-bounded collaborative event on a topic-specific subdomain/site |
+
+### 2.5 Mike Caulfield — lifecycle and pedagogy
+
+Caulfield articulated fedwiki's social model beyond Ward's mechanics:
+
+**Kinneavy triangle / knowledge lifecycle** (composition theory):
+
+| Phase | Mode | Typical medium | Fedwiki fit |
+|-------|------|----------------|-------------|
+| **I** | Personal capture | Notes, journal | Each person's site |
+| **You** | Dialogic | Conversation, annotation | Fork chains, cross-site references |
+| **It** | Expository | Stable shared article | Spread of refined forks |
+
+Fedwiki supports **I → You → It** in one system; centralized wikis force **It**
+(consensus) from the first edit.
+
+**Bounded conversations / expected heat death** (2015):
+
+- Wiki sites are **bounded conversations**, not permanent monuments.
+- Sites are **expected to die**; valuable material is **forked into the next happening**.
+- **Reverse bit-rot** — Smalltalk-era term Ward revived: objects/pages improve each
+  time reused across systems (refactor on fork), defying entropy of abandoned forums.
+- Contrast: colony collapse on centralized forums (Blue Hampshire example) vs
+  humane site retirement with selective carry-forward.
+
+**OER reuse** (2015): WordPress copy-paste ~10–15 min/page vs fedwiki fork ~15 sec;
+bottleneck is software, not human willingness to remix.
+
+**Dissent as feature** (Ogden via Wired): Wikipedia forces one perspective;
+fedwiki enables multiple controversial pages, still linked for exploration.
+
+### 2.6 Strengths and limits
+
+| Strengths | Limits |
+|-----------|--------|
+| Personal sovereignty over pages | Requires running a site (mitigated by one-click AWS deploy) |
+| Low-friction remix with provenance | Small niche ecosystem |
+| Multi-perspective knowledge | Weak team-governance / permissions story vs enterprise wikis |
+| JSON portability | Plugin fragmentation; non-Markdown item model |
+| Strong conceptual clarity | Not a general adapter layer for arbitrary backends |
+
+---
+
+## 3. Other federation models
+
+### 3.1 Git-backed distributed wikis (ikiwiki pattern)
+
+[ikiwiki distributed wikis](https://ikiwiki.info/tips/distributed_wikis/) documents
+a **spectrum of decentralization**:
+
+| Level | Setup | Federation mechanism |
+|-------|-------|---------------------|
+| 0 | Single server | None |
+| 1 | HTML mirror | Read-only copy |
+| 2 | Split web + git host | Clone/pull |
+| 3 | Pinger mirrors | Central bare repo + ping-on-edit propagation |
+| 4 | Fully decentralized | Independent wikis push/pull via git to peers |
+
+**Branching a wiki** = clone origin read-only (`git://`), edit locally without
+push-back — explicit fork. Conflicts surface as markers in rendered pages.
+
+**Relevance to shard-wiki:** Strong alignment with **Git-addressable
+coordination** and **coordination journal** in `INTENT.md`. ikiwiki federates
+*homogeneous* git-backed wikis; shard-wiki must also attach non-git shards
+(Obsidian, WebDAV, Gitea wiki, Coulomb, etc.).
+
+**Gollum / GitHub wikis:** Same backing-store idea — pages as files in a repo;
+federation is git sync, not a wiki protocol. Multi-repo Gollum setups are
+operational, not semantic union.
+
+### 3.2 ActivityPub wiki federation (XWiki)
+
+[XWiki ActivityPub Application](https://extensions.xwiki.org/xwiki/bin/view/Extension/ActivityPub%20Application/)
+(v1.7.x) connects XWiki instances to the **fediverse**:
+
+| Capability | Notes |
+|------------|-------|
+| Follow user / wiki actor | Receive Create/Update notifications |
+| Share documents | Push page content to followers; view remote in modal |
+| Messaging / discussions | Note objects threaded as discussions |
+| Like, mention | Social engagement primitives |
+| Webfinger + ActivityPub endpoints | Standard discovery |
+
+**Caveats (documented by XWiki):** Federation "not well supported yet" for
+full activity routing; Mastodon mention of Page entities incomplete; security
+signing partial.
+
+**Contrast with fedwiki:** ActivityPub federates **activities and notifications**
+between **compatible app instances**; content may be copied on share, but the
+model is social-graph + event stream, not per-user fork sovereignty. Closer to
+**fediverse** than **fedwiki** UX.
+
+**Contrast with shard-wiki:** ActivityPub could be an **adapter transport** for
+some shards, but shard-wiki's core is wiki-page semantics (paths, links,
+overlays, provenance), not activity streams.
+
+### 3.3 Xanadu / transclusion lineage
+
+Ted Nelson's [Project Xanadu](https://en.wikipedia.org/wiki/Project_Xanadu)
+(1960s–) pursued **serious electronic literature** with patterns still relevant:
+
+| Pattern | Intent | Modern partial implementations |
+|---------|--------|-------------------------------|
+| **Visible links** | Show destination context, not opaque jumps | Hover previews, Open Graph unfurls |
+| **Parallel documents** | Side-by-side source + derivative | Multi-pane editors (Obsidian, Roam) |
+| **Transclusion** | Live inclusion of remote span with origin pointer | Embeds, block references (weak) |
+| **Transcopyright** | Permissioning for reuse | Mostly unsolved at web scale |
+| **Stable addresses** | Fine-grained, durable pointers | Block UIDs (Roam); URL rot elsewhere |
+| **Bi-directional links** | Backlinks as first-class | Obsidian, Roam, shard-wiki BackLinks UC |
+
+Xanadu is **speculative design / pattern language**, not deployable federation.
+Useful for shard-wiki **provenance, transclusion, and link resolution** thinking —
+especially union BackLinks and projection freshness.
+
+### 3.4 Personal / local-first wikis (TiddlyWiki, Obsidian)
+
+Not federation protocols, but **sovereignty** models:
+
+- **TiddlyWiki** — single-file portable wiki; complete user ownership.
+- **Obsidian** — local vault + optional sync; community plugins for publish/remix.
+
+Shard-wiki INTENT explicitly lists these as shard participants via adapters.
+Federation is **attachment to a root information space**, not replacing the
+local tool.
+
+### 3.5 yawex multi-wiki resolution (cross-reference)
+
+From `research/260608-yawex-prior-art/findings.md`:
+
+| yawex state | Federation reading |
+|-------------|-------------------|
+| `REMOTE` | Jump to another wiki's page — remote shard navigation |
+| `VIRTUAL` | Local processing, remote content — projection |
+| Multi-wiki config | Multiple named wikis = multiple shards |
+
+**Decision already recorded:** inspiration only; shard-wiki designs resolution
+fresh for heterogeneous adapters.
+
+### 3.6 Solid / personal data pods (brief)
+
+Solid aims at **user-controlled pods** + linked data apps. Distributed wiki
+discussions (forum threads, TiddlyWiki-on-Solid experiments) explore **personal
+wikis on pods** vs **team commons**.
+
+| Axis | Solid-style | Fedwiki | shard-wiki |
+|------|-------------|---------|------------|
+| Unit of sovereignty | Pod / user | Site / person | Shard |
+| Unity mechanism | Linked data queries | Browser composition + fork | Orchestrated union + Git journal |
+| Team wiki | Secondary; app-dependent | Weak | Supported via shards + authz |
+
+No mature Solid wiki federation standard emerged; treat as **adjacent personal-
+data sovereignty** research, not direct prior art.
+
+---
+
+## 4. Comparison matrix
+
+| Model | Unit of ownership | Unity mechanism | Consensus model | History / provenance | Heterogeneous backends |
+|-------|-------------------|-----------------|-----------------|----------------------|------------------------|
+| **Centralized wiki** (c2, MediaWiki) | Site operator | Single namespace | On-page consensus | Server revision log | No |
+| **Federated Wiki** | Per-site (per person) | Browser pulls JSON; fork | Spread of versions | Journal per page | No (all SFW-shaped) |
+| **ikiwiki distributed** | Per git clone | git push/pull, pingers | Merge conflicts in git | Git commits | No (all ikiwiki) |
+| **ActivityPub (XWiki)** | Per instance | Activity stream | Social follow/share | Activity + page store | No (XWiki only) |
+| **Xanadu** | Document address | Transclusion | Parallel versions | Version trails (concept) | N/A (unbuilt) |
+| **shard-wiki (INTENT)** | Per shard | Orchestrator union | Configurable policy | Git coordination journal + shard history | **Yes** (adapter contract) |
+
+---
+
+## 5. Glossary (federation track)
+
+| Term | Meaning | Primary source |
+|------|---------|----------------|
+| **Fork** | Copy a page (or site branch) to a new home; divergent editing | Fedwiki, git |
+| **Journal** | Ordered actions reconstructing page state; travels with page | Fedwiki JSON schema |
+| **Story** | Array of typed items (paragraph, image, …) forming page body | Fedwiki |
+| **Happening** | Time-bounded fedwiki collaboration on a topic site | Caulfield |
+| **Bounded conversation** | Site with expected end; not infinite commons | Caulfield |
+| **Reverse bit-rot** | Content improves through reuse across contexts | Caulfield / Ward |
+| **Chorus of voices** | Multiple perspectives on same topic, linked | Ward |
+| **Inverted model** | Records distributed; meaning composed client-side | Ward |
+| **Projection** | Local view of remote content without claiming ownership | shard-wiki / yawex VIRTUAL |
+| **Overlay** | Local edit against remote/canonical without immediate mutation | shard-wiki |
+| **Shard** | Independently meaningful page store with own capabilities | shard-wiki |
+| **Coordination journal** | Git-backed change record for an information space | shard-wiki |
+| **Transclusion** | Include live span from elsewhere with origin visible | Xanadu |
+| **Fediverse** | Network of ActivityPub-speaking apps | XWiki AP, Mastodon |
+| **Pinger / pingee** | Edit-triggered mirror refresh between ikiwiki sites | ikiwiki |
+| **Wiki actor** | Entire wiki as ActivityPub actor | XWiki AP |
+
+---
+
+## 6. Mapping to shard-wiki INTENT (compare, do not equate)
+
+### 6.1 Strong resonances
+
+| Fedwiki / federation idea | shard-wiki concept | Notes |
+|---------------------------|-------------------|-------|
+| Personal ownership of edits | Shard sovereignty | shard-wiki generalizes beyond per-person sites |
+| Fork with provenance | Overlay + patch flows | shard-wiki separates draft from destructive apply |
+| Journal / history with page | Coordination journal + shard revision | Git journal is space-level; shard retains own history |
+| Browser-composed union | Union of pages across shards | Orchestrator presents coherent graph |
+| JSON not HTML for remix | Markdown-first page model | Different format; same structural intent |
+| Lazy pull from remote | Projection | yawex VIRTUAL; explicit freshness |
+| Chorus of voices | Union without erasure | Show provenance, divergence, equivalents |
+| Bounded conversation | Configurable policy | Mechanism not policy — space may be permanent or ephemeral |
+| Reverse bit-rot on reuse | Reconciliation / sync | Policy-driven; not automatic fork |
+| Derived views (recent, links) | UC-05 union views | BackLinks, RecentChanges across shards |
+
+### 6.2 Deliberate divergences (design bugs if conflated)
+
+| Fedwiki assumption | shard-wiki correction |
+|--------------------|----------------------|
+| Every participant runs SFW-shaped JSON site | **Adapter contract** for Gitea, folders, Obsidian, WebDAV, engines |
+| Fork = default edit primitive | **Capability-aware**: read-only shards need overlay, not fork |
+| Client composes in browser only | Orchestrator may serve CLI, agents, CI — not browser-only |
+| Per-site = per-person | Shards may be team repos, org wikis, app databases |
+| No central coordination | **Git-addressable coordination layer** per information space |
+| Plugin item types | Markdown-first; engine-specific render is out of core scope |
+| Implicit spread-as-consensus | **Mechanism over policy** — canonical source is explicit config |
+
+### 6.3 What shard-wiki adds beyond fedwiki
+
+1. **Heterogeneous attachment** — not all shards speak the same page JSON.
+2. **Capability matrix** — read/write/diff/merge/lock/publish per shard.
+3. **Overlay-before-mutation** — respect remote sovereignty and limited backends.
+4. **Semantic wiki sync** — not generic file mirroring.
+5. **Enterprise authz ladder** — L0 open → delegated IAM (without owning identity).
+6. **Divergence detection** — equivalent pages across shards, reconcilable.
+
+### 6.4 What fedwiki teaches that shard-wiki should not lose
+
+1. **Frictionless reuse** — if remix takes 15 minutes, federation fails socially.
+2. **Provenance by default** — history must travel or be reconstructible.
+3. **Multi-perspective truth** — union ≠ single canonical article.
+4. **Expected lifecycle** — information spaces may be ephemeral; plan for carry-forward.
+5. **Personal sovereignty** — contributors must not be hostage to one operator's server.
+
+---
+
+## 7. Use-case promotion (done 2026-06-08)
+
+Promoted to `spec/UseCaseCatalog.md` as UC-26–UC-33. Architecture decisions
+tracked in `workplans/SHARD-WP-0002-federation-architecture.md`.
+
+| Research ID | Catalog UC |
+|-------------|------------|
+| UC-FED-01 Fork page from remote shard | UC-26 |
+| UC-FED-02 View multiple versions of equivalent page | UC-27 |
+| UC-FED-03 Carry forward from closed/archived shard | UC-28 |
+| UC-FED-04 Remix with portable attribution | UC-29 |
+| UC-FED-05 Time-bounded collaboration space | UC-30 |
+| UC-FED-06 Subscribe to remote shard changes | UC-31 |
+| UC-FED-07 Transclude remote span | UC-32 |
+| UC-FED-08 Git-branch information space | UC-33 |
+
+---
+
+## 8. Open questions (for spec / workplans)
+
+1. **Fork vs overlay vs import** — When does shard-wiki copy content into a
+   writable shard vs keep an overlay vs link-only reference?
+2. **Equivalent page identity** — How are "same topic" pages matched across
+   shards (title, path, link graph, explicit alias)?
+3. **Journal format** — Does shard-wiki adopt fedwiki-like action journals,
+   Git commits only, or both per shard type?
+4. **Browser vs server composition** — Where does union merging run for agents
+   and non-UI consumers?
+5. **ActivityPub as adapter** — Optional transport for change notification, or
+   out of scope?
+6. **Ephemeral spaces** — Should information spaces have first-class lifecycle
+   (archived, read-only, merged-into-successor)?
+7. **Plugin/item extensibility** — Markdown extensions vs structured blocks for
+   remixable assessments (fedwiki OER lesson)?
+8. **Consensus without erasure** — Policy presets: fedwiki-spread, git-merge,
+   designated canonical shard, vote-to-merge?
+
+---
+
+## 9. Sources
+
+| Source | URL |
+|--------|-----|
+| Wikipedia — Federated Wiki | https://en.wikipedia.org/wiki/Federated_Wiki |
+| Wired — Wiki Inventor Sticks a Fork | https://www.wired.com/2012/07/wiki-inventor/ |
+| viki.wiki — JSON Schema | https://viki.wiki/json-schema.html |
+| Fedwiki GitHub | https://github.com/fedwiki/wiki |
+| Caulfield — Federated Education (NWACC 2014) | https://hapgood.us/2014/11/06/federated-education-new-directions-in-digital-collaboration/ |
+| Caulfield — Bounded Conversations | https://hapgood.us/2015/01/21/rethinking-wiki-lifecycle-sites-as-bounded-conversations/ |
+| Caulfield — OER Case for Federated Wiki | https://hapgood.us/2015/05/05/the-oer-case-for-federated-wiki/ |
+| ikiwiki — distributed wikis | https://ikiwiki.info/tips/distributed_wikis/ |
+| XWiki — ActivityPub Application | https://extensions.xwiki.org/xwiki/bin/view/Extension/ActivityPub%20Application/ |
+| Maggie Appleton — Xanadu Patterns | https://maggieappleton.com/xanadu-patterns |
+| Wikipedia — Project Xanadu | https://en.wikipedia.org/wiki/Project_Xanadu |
+| shard-wiki — yawex prior art | `research/260608-yawex-prior-art/findings.md` |
+| shard-wiki — c2 origins | `research/260608-c2-wiki-origins/findings.md` |
+| shard-wiki — INTENT | `INTENT.md` |
+
+---
+
+## 10. Traceability
+
+| This document section | Informs (future) |
+|-----------------------|------------------|
+| §2 Federated Wiki | Adapter design, page model, overlay/fork policy |
+| §3.1 ikiwiki | Git coordination journal, mirror/branch modes |
+| §3.2 ActivityPub | Optional notification adapter |
+| §3.3 Xanadu | Link resolution, transclusion, provenance UI |
+| §6 Mapping | Architecture blueprint guardrails |
+| §7 UC seeds | `spec/UseCaseCatalog.md` promotion pass |

research/README.md

@@ -10,4 +10,7 @@ when multiple files or sources are involved. Findings here inform `spec/` and
 
 | Date | Path | Summary |
 |------|------|---------|
-| 2026-06-08 | `260608-yawex-prior-art/` | yawex 0.7.4 Perl wiki prior art; federation design seeds |
+| 2026-06-08 | `260608-yawex-prior-art/` | yawex 0.7.4 Perl wiki prior art; federation design seeds |
+| 2026-06-08 | `260608-c2-wiki-origins/` | Ward Cunningham & WikiWikiWeb origins; terms and use cases |
+| 2026-06-08 | `260608-federation-concepts/` | Federated Wiki, git/ActivityPub/Xanadu federation models |
+| 2026-06-08 | `260608-wikiengines-overview/` | Wiki engine landscape survey (Perplexity-assisted) |

spec/ProductRequirementsDocument.md

@@ -46,9 +46,11 @@ See `INTENT.md` § Strategic Boundaries.
 
 - `research/260608-yawex-prior-art/findings.md` — federation design seeds from
   prior art.
+- `research/260608-federation-concepts/findings.md` — Federated Wiki, git/AP
+  federation models; UC-26–UC-33 in `spec/UseCaseCatalog.md`.
 
 ## 8. Open Items
 
-Pending completion of `SHARD-WP-0001` design tasks and ratification of access
+Pending completion of `SHARD-WP-0001` and `SHARD-WP-0002` design tasks and
-model INTENT amendments. Detailed requirements will be expanded as spec tasks
+ratification of access model INTENT amendments. Detailed requirements will be
-complete.
+expanded as spec tasks complete.

spec/README.md

@@ -8,7 +8,7 @@ Background on document types: InfoTechPrimers on coulomb.social.
 |------|--------|------|
 | `ProductRequirementsDocument.md` | draft scaffold | What the product must deliver |
 | `TechnicalSpecificationDocument.md` | draft scaffold | How the system is built |
-| `UseCaseCatalog.md` | draft scaffold | Observable usage scenarios |
+| `UseCaseCatalog.md` | draft | 25 use cases promoted from c2 + yawex research |
 | `ArchitectureBlueprint.md` | draft | Access, history, and identity architecture |
 
 Promote material from `research/` and reviewed items from `demand/` into spec

spec/TechnicalSpecificationDocument.md

@@ -45,7 +45,12 @@ per information space.
 
 Package scaffold only (`__version__`, smoke tests). Domain model not yet coded.
 
-## 7. Next Specification Work
+## 7. Use Cases
+
+`spec/UseCaseCatalog.md` — 25 use cases (UC-01–UC-25) promoted from c2 wiki
+origins and yawex prior-art research.
+
+## 8. Next Specification Work
 
 Outputs from `SHARD-WP-0001` tasks (page resolution, namespaces, derived views,
 provenance, overlays, link semantics) will be incorporated here as they complete.

spec/UseCaseCatalog.md

@@ -1,47 +1,464 @@
 # UseCaseCatalog
 
-Status: **draft scaffold** · Date: 2026-06-08
+Status: **draft** · Date: 2026-06-08 · Updated: 2026-06-08
 
+Promoted from `research/260608-c2-wiki-origins/`,
+`research/260608-yawex-prior-art/`, and `research/260608-federation-concepts/`.
 See InfoTechPrimers on coulomb.social for use-case catalog conventions.
 
-## UC-01 — Standalone open wiki (L0)
+## Conventions
+
+Each use case lists:
+
+- **Actor** — who initiates the action
+- **Goal** — observable outcome
+- **Source** — research lineage (`c2`, `yawex`, `federation`, `intent`, or combined)
+- **Notes** — shard-wiki-specific constraints or open design points
+
+Priority hints: **MVP** = likely early value; **Later** = important but not first slice.
+
+---
+
+## A. Information space and federation
+
+*shard-wiki orchestration scenarios (INTENT + yawex federation seeds).*
+
+### UC-01 — Standalone open wiki (L0)
 
 **Actor:** Anonymous contributor  
 **Goal:** Read and write wiki pages with full history and no external dependencies.  
-**Notes:** Ward Cunningham / c2-style open mode. Recovery via Git history, not gatekeeping.
+**Source:** intent, c2  
+**Notes:** Ward Cunningham / c2-style open mode (`WhyWikiWorks`). Recovery via Git
+history, not gatekeeping. Aligns with L0 in `spec/ArchitectureBlueprint.md`.
+**Priority:** MVP
 
-## UC-02 — Attach a Git repo shard
+### UC-02 — Attach a shard to an information space
 
 **Actor:** Maintainer  
-**Goal:** Attach a repository or `wiki/` subdirectory as a shard of an information space.  
+**Goal:** Attach a repository, directory, or other backend as a shard of a root entity.  
-**Notes:** Preserve shard sovereignty and adapter capability profile.
+**Source:** intent, yawex  
+**Notes:** yawex `Conf::TestWiki / FriendsWiki` foreshadows multiple roots/shards.
+Preserve shard sovereignty and adapter capability profile.  
+**Priority:** MVP
 
-## UC-03 — Project a remote shard page locally
+### UC-03 — Project a remote shard page locally
 
 **Actor:** Reader  
-**Goal:** View a page from a remote or read-only shard as a local projection with provenance and freshness visible.  
+**Goal:** View a page from a remote or read-only shard as a local projection with
-**Notes:** Lazy projection; no silent mutation.
+provenance and freshness visible.  
+**Source:** intent, yawex  
+**Notes:** yawex `VIRTUAL` state = projection/cache. Lazy projection; no silent
+mutation.  
+**Priority:** Later
 
-## UC-04 — Overlay edit on read-only shard
+### UC-04 — Overlay edit on read-only shard
 
 **Actor:** Author  
-**Goal:** Propose changes to a remote/read-only page as overlay/draft/patch before destructive apply.  
+**Goal:** Propose changes to a remote/read-only page as overlay, draft, or patch
-**Notes:** Overlay-before-mutation principle.
+before destructive apply.  
+**Source:** intent, yawex  
+**Notes:** yawex append/comment workflow; c2 ThreadMode → refactor pattern.
+Overlay-before-mutation principle.  
+**Priority:** Later
 
-## UC-05 — Union browse (BackLinks, RecentChanges)
+### UC-05 — Union derived views
 
 **Actor:** Reader  
-**Goal:** Navigate derived views across all attached shards.  
+**Goal:** Navigate BackLinks, RecentChanges, AllPages, SiteMap, or Search across
-**Notes:** BackLinks over federated link graph is a strong core candidate (see research findings).
+all attached shards as a federated graph.  
+**Source:** intent, c2, yawex  
+**Notes:** Present on both c2 (community nerve center) and yawex core pages.
+BackLinks over the union link-graph is the strongest core candidate; per-shard
+vs union scope remains open (see UC-19–UC-21).  
+**Priority:** Later
 
-## UC-06 — Authenticated team wiki (L2+)
+### UC-06 — Authenticated team wiki (L2+)
 
 **Actor:** Authenticated principal  
-**Goal:** Read/write under role-based authorization with identity from external provider.  
+**Goal:** Read and write under role-based authorization with identity from an
-**Notes:** See `spec/ArchitectureBlueprint.md` capability ladder.
+external provider.  
+**Source:** intent, yawex  
+**Notes:** yawex htpasswd + per-topic `AccessControl` is prior art only;
+shard-wiki delegates authentication, owns authorization
+(`spec/ArchitectureBlueprint.md`).  
+**Priority:** Later
 
-## UC-07 — Detect cross-shard divergence
+### UC-07 — Detect and reconcile cross-shard divergence
 
 **Actor:** Maintainer  
-**Goal:** Identify when equivalent pages in different shards have diverged and reconcile.  
+**Goal:** Identify when equivalent pages in different shards have diverged and
-**Notes:** Union without erasure — conflicts visible, not hidden.
+reconcile them under explicit policy.  
+**Source:** intent  
+**Notes:** Union without erasure — conflicts visible, not hidden. Complements
+UC-27 (multi-version view) and SHARD-WP-0002 consensus-policy task.  
+**Priority:** Later
+
+### UC-26 — Fork page from remote shard into writable shard
+
+**Actor:** Author  
+**Goal:** Copy a page from a remote or read-only shard into a local writable
+shard for independent editing, with provenance preserved.  
+**Source:** federation, intent  
+**Notes:** Fedwiki fork primitive. shard-wiki may realize as import, overlay
+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`.  
+**Priority:** Later
+
+### UC-27 — View multiple versions of equivalent page
+
+**Actor:** Reader  
+**Goal:** See coexisting versions of the same topic from different shards or
+authors without collapsing them into one canonical page.  
+**Source:** federation, intent  
+**Notes:** Fedwiki "chorus of voices"; INTENT union without erasure. Equivalent-
+page identity model TBD (`SHARD-WP-0002`). Links UC-07 divergence detection.  
+**Priority:** Later
+
+### UC-28 — Carry forward pages from closed or archived shard
+
+**Actor:** Maintainer or author  
+**Goal:** Selectively import or re-project valuable pages from an archived,
+read-only, or retired shard into an active information space.  
+**Source:** federation  
+**Notes:** Caulfield bounded conversation / reverse bit-rot. Optional space
+lifecycle policy. Complements UC-02 attach and UC-26 fork at scale.  
+**Priority:** Later
+
+### UC-29 — Remix with portable attribution
+
+**Actor:** Author  
+**Goal:** Reuse content across shards or spaces with attribution and edit
+history intact, without manual copy-paste.  
+**Source:** federation, intent  
+**Notes:** Fedwiki journal travels with page; shard-wiki coordination journal +
+per-shard history. Frictionless reuse principle (~15s not ~15min).  
+**Priority:** Later
+
+### UC-30 — Time-bounded collaboration space
+
+**Actor:** Facilitator  
+**Goal:** Run a collaboration period on a dedicated information space or shard
+subset, then archive it while allowing selective carry-forward.  
+**Source:** federation  
+**Notes:** Fedwiki "happening"; lifecycle is configurable policy, not a hard-
+coded core behavior. Relates to UC-28.  
+**Priority:** Later
+
+### UC-31 — Subscribe to remote shard changes
+
+**Actor:** Maintainer or reader  
+**Goal:** Receive timely notice when pages change on attached remote shards,
+triggering projection refresh or reconciliation review.  
+**Source:** federation, intent  
+**Notes:** ikiwiki pinger/pingee; ActivityPub Create/Update; polling fallback.
+Transport is adapter concern; freshness surfaced in UC-24.  
+**Priority:** Later
+
+### UC-32 — Transclude remote span with live freshness
+
+**Actor:** Author or reader  
+**Goal:** Embed a portion of a remote page inline with visible origin and
+refreshable content.  
+**Source:** federation, intent  
+**Notes:** Xanadu transclusion pattern; stronger than UC-03 whole-page
+projection. Provenance and staleness must be explicit.  
+**Priority:** Later
+
+### UC-33 — Git-branch an information space
+
+**Actor:** Maintainer  
+**Goal:** Fork the coordination journal and attached shard configuration into a
+divergent information space without destroying the original.  
+**Source:** federation, intent  
+**Notes:** ikiwiki wiki-branch pattern; Git-backed coordination per INTENT.
+Space-level fork — distinct from UC-26 page-level fork.  
+**Priority:** Later
+
+---
+
+## B. Knowledge work and collaboration
+
+*Patterns from c2 social conventions and yawex authoring workflows.*
+
+### UC-08 — Quick idea capture
+
+**Actor:** Contributor  
+**Goal:** Capture a thought as a page and link to related pages, including ones
+that do not exist yet.  
+**Source:** c2  
+**Notes:** c2 *incremental* and *open* design principles; Wiki = "quick web."
+Markdown-first wikilink/red-link extension (yawex TRANSFORM) applies.  
+**Priority:** MVP
+
+### UC-09 — Sandbox first edit
+
+**Actor:** New contributor  
+**Goal:** Learn editing mechanics in a safe sandbox without affecting production
+pages.  
+**Source:** c2  
+**Notes:** c2 `WikiWikiSandbox`, `WelcomeVisitors` onboarding path.  
+**Priority:** MVP
+
+### UC-10 — Discussion to consensus document
+
+**Actor:** Contributor (often acting as WikiMaster)  
+**Goal:** Refine a ThreadMode conversation into an unsigned DocumentMode page
+that reflects community consensus.  
+**Source:** c2  
+**Notes:** ADD / EDIT / SPLIT / CAPTURE thread contributions; prefer rewrite
+over stacked clarifications (`DocumentMode`, `GoodStyle`). Mechanism in core
+vs reference UI TBD.  
+**Priority:** Later
+
+### UC-11 — Distill experience into reusable knowledge
+
+**Actor:** Practitioner  
+**Goal:** Turn field notes, threads, or project experience into durable,
+reusable artifacts (patterns, methods, checklists).  
+**Source:** c2, yawex  
+**Notes:** c2 `PatternMode`, PPR "People, Projects & Patterns"; yawex blueprint
+pages (UC-15). Not an encyclopedia (`WikiIsNotWikipedia`).  
+**Priority:** Later
+
+### UC-12 — Practitioner field notes
+
+**Actor:** Contributor  
+**Goal:** Maintain informal, subjective programming and project history that is
+explicitly work-in-progress.  
+**Source:** c2  
+**Notes:** `InformalHistoryOfProgrammingIdeas`, `WorkInProgress`. Complements
+UC-11; distinct from reference-grade documentation in `docs/` or `spec/`.  
+**Priority:** MVP
+
+### UC-13 — Community presence
+
+**Actor:** Visitor  
+**Goal:** Signal participation and discover who is active in the information
+space.  
+**Source:** c2  
+**Notes:** c2 `RecentVisitors`, `PeopleIndex`. Optional attribution at L1+
+(`ArchitectureBlueprint` L1 Attributed mode).  
+**Priority:** Later
+
+### UC-14 — Self-curating knowledge base
+
+**Actor:** Community  
+**Goal:** Improve collective quality through open editing, refactoring, and
+convergent deduplication rather than gatekeeping.  
+**Source:** c2  
+**Notes:** `WhyWikiWorks`, `RefactorDontDelete`, `Convergent` design principle.
+shard-wiki adds Git history as structural safety net beyond social norms.  
+**Priority:** MVP
+
+### UC-15 — Create page from blueprint
+
+**Actor:** Author  
+**Goal:** Instantiate a new page or topic structure from a template, duplicating
+an agreed layout or subtree.  
+**Source:** yawex  
+**Notes:** yawex blueprint pages. Distinct from UC-08 (blank capture) and UC-10
+(refactoring existing discussion).  
+**Priority:** Later
+
+### UC-16 — Append or comment without full edit
+
+**Actor:** Author  
+**Goal:** Add material to a page without replacing the entire body — lightweight
+patch, comment, or append workflow.  
+**Source:** yawex, c2  
+**Notes:** yawex append/comment; c2 ThreadMode ADD. Maps to overlay model (UC-04)
+for read-only/remote shards; direct append where adapter allows.  
+**Priority:** Later
+
+---
+
+## C. Discovery and navigation
+
+*Derived views and browse patterns from c2 and yawex.*
+
+### UC-17 — Change radar
+
+**Actor:** Reader or maintainer  
+**Goal:** See what changed recently across pages and who changed it.  
+**Source:** c2, yawex  
+**Notes:** c2 `RecentChanges`, `QuickChanges`, `RecentChangesJunkie`; yawex
+`RecentChanges` core page. Union scope in UC-05; this UC covers the user need
+at any scope.  
+**Priority:** MVP
+
+### UC-18 — BackLinks navigation
+
+**Actor:** Reader  
+**Goal:** Find pages that link to the current page.  
+**Source:** c2, yawex  
+**Notes:** Link-graph query. Strong core candidate for federated union (UC-05).  
+**Priority:** Later
+
+### UC-19 — All pages and site map browse
+
+**Actor:** Reader  
+**Goal:** Survey the full page inventory or hierarchical site structure.  
+**Source:** c2, yawex  
+**Notes:** yawex `AllPages`, `SiteMap` core pages; c2 `WikiList`, categories,
+`RoadMaps`. Namespace/path model affects presentation (UC-22).  
+**Priority:** Later
+
+### UC-20 — Full-text search
+
+**Actor:** Reader  
+**Goal:** Find pages by content keyword or phrase.  
+**Source:** c2, yawex  
+**Notes:** yawex `SearchPage`; c2 `FindPage`, `SearchHelper`. Core vs
+adapter-provided indexing TBD.  
+**Priority:** Later
+
+### UC-21 — Serendipitous browse
+
+**Actor:** Reader  
+**Goal:** Discover unexpected relevant pages without a specific search target.  
+**Source:** c2  
+**Notes:** `RandomPages`, `VisualTour`, `LikePages`, `StartingPoints`.  
+**Priority:** Later
+
+### UC-22 — Namespace and path navigation
+
+**Actor:** Reader or author  
+**Goal:** Resolve and navigate pages using relative (`../`), absolute (`/`), and
+normalized paths within a topic hierarchy.  
+**Source:** yawex  
+**Notes:** yawex topics-as-directories; page-resolution state space is
+inspiration only for federation design (not inherited as API).  
+**Priority:** Later
+
+### UC-23 — Soft topic creation via red link
+
+**Actor:** Author  
+**Goal:** Follow a link to a nonexistent page and create it on first write.  
+**Source:** c2, yawex  
+**Notes:** c2 `PageName?`; yawex red-`?` link semantics. TRANSFORM to
+CommonMark wikilink + red-link extension.  
+**Priority:** MVP
+
+---
+
+## D. Provenance and page metadata
+
+*yawex `Page::info` and c2 attribution norms.*
+
+### UC-24 — Inspect page provenance
+
+**Actor:** Reader  
+**Goal:** See source shard, modification time, freshness, editor attribution,
+edit count, and whether the page has local overlays or diverges elsewhere.  
+**Source:** yawex, c2, intent  
+**Notes:** yawex `Page::info`; c2 optional `UserName` signing. INTENT explicit
+provenance principle.  
+**Priority:** Later
+
+### UC-25 — Collaborative glossary and precise naming
+
+**Actor:** Community  
+**Goal:** Build a shared vocabulary of precise page titles and linked terms that
+reduce ambiguity across the information space.  
+**Source:** c2, yawex  
+**Notes:** c2 flat namespace + `WikiWord` / `Precise` principle; yawex
+CamelCase and `[[free links]]`. Markdown-first link semantics TBD.  
+**Priority:** Later
+
+---
+
+## Traceability
+
+| UC | c2 research | yawex research | federation research | INTENT |
+|----|-------------|----------------|---------------------|--------|
+| UC-01 | ✓ | | | ✓ |
+| UC-02 | | ✓ | | ✓ |
+| UC-03 | | ✓ | ✓ | ✓ |
+| UC-04 | ✓ | ✓ | ✓ | ✓ |
+| UC-05 | ✓ | ✓ | ✓ | ✓ |
+| UC-06 | | ✓ | | ✓ |
+| UC-07 | | | ✓ | ✓ |
+| UC-26 | | | ✓ | ✓ |
+| UC-27 | | | ✓ | ✓ |
+| UC-28 | | | ✓ | |
+| UC-29 | | | ✓ | ✓ |
+| UC-30 | | | ✓ | |
+| UC-31 | | | ✓ | ✓ |
+| UC-32 | | | ✓ | ✓ |
+| UC-33 | | | ✓ | ✓ |
+| UC-08 | ✓ | | |
+| UC-09 | ✓ | | |
+| UC-10 | ✓ | | |
+| UC-11 | ✓ | ✓ | |
+| UC-12 | ✓ | | |
+| UC-13 | ✓ | | |
+| UC-14 | ✓ | | ✓ |
+| UC-15 | | ✓ | |
+| UC-16 | ✓ | ✓ | |
+| UC-17 | ✓ | ✓ | |
+| UC-18 | ✓ | ✓ | |
+| UC-19 | ✓ | ✓ | |
+| UC-20 | ✓ | ✓ | |
+| UC-21 | ✓ | | |
+| UC-22 | | ✓ | |
+| UC-23 | ✓ | ✓ | |
+| UC-24 | ✓ | ✓ | ✓ |
+| UC-25 | ✓ | ✓ | |
+
+### c2 synthesis mapping
+
+| Research ID | Catalog UC |
+|-------------|------------|
+| UC-C2-01 Quick idea capture | UC-08 |
+| UC-C2-02 Collaborative glossary | UC-25 |
+| UC-C2-03 Discussion → consensus doc | UC-10 |
+| UC-C2-04 Pattern mining | UC-11 |
+| UC-C2-05 Community guest book | UC-13 |
+| UC-C2-06 Change radar | UC-17 |
+| UC-C2-07 Self-curating knowledge base | UC-14 |
+| UC-C2-08 Sandbox learning | UC-09 |
+| UC-C2-09 Serendipitous browse | UC-21 |
+| UC-C2-10 Practitioner field notes | UC-12 |
+| UC-C2-11 Team memory for methods | UC-11, UC-12 |
+| UC-C2-12 Soft creation of missing topics | UC-23 |
+
+### yawex KEEP mapping
+
+| yawex KEEP item | Catalog UC |
+|-----------------|------------|
+| Derived views (BackLinks, RecentChanges, AllPages, SiteMap, Search) | UC-05, UC-17–UC-20 |
+| Topic = namespace hierarchy | UC-22 |
+| Append/comment workflow | UC-04, UC-16 |
+| Blueprint pages | UC-15 |
+| Provenance hooks | UC-24 |
+| Page classes (local/global/virtual) | UC-02, UC-03 (shard roles) |
+| Wikilink / red-link semantics | UC-08, UC-23, UC-25 |
+
+### federation research mapping
+
+| Research ID (findings §7) | Catalog UC |
+|---------------------------|------------|
+| UC-FED-01 Fork page from remote shard | UC-26 |
+| UC-FED-02 View multiple versions of equivalent page | UC-27 |
+| UC-FED-03 Carry forward from closed/archived shard | UC-28 |
+| UC-FED-04 Remix with portable attribution | UC-29 |
+| UC-FED-05 Time-bounded collaboration space | UC-30 |
+| UC-FED-06 Subscribe to remote shard changes | UC-31 |
+| UC-FED-07 Transclude remote span | UC-32 |
+| UC-FED-08 Git-branch information space | UC-33 |
+
+---
+
+## Open questions
+
+1. Which UC items are **MVP for L0 standalone** vs requiring federation or L2+?
+2. Which derived views (UC-05, UC-17–UC-20) are **core orchestrator** vs
+   **adapter-provided**?
+3. Do c2 collaboration patterns (UC-10, UC-14) belong in **core**, **reference
+   UI**, or **`wiki/` social convention** only?
+4. Should UC-12 and `WikiIsNotWikipedia` be elevated into
+   `ProductRequirementsDocument.md` as explicit product identity?
+5. Which federation UCs (UC-26–UC-33) are **MVP** vs deferred until
+   `SHARD-WP-0002` architecture decisions land?
+6. Does UC-32 (transclusion) belong in core orchestrator or adapter/UI layer?

workplans/SHARD-WP-0002-federation-architecture.md

@@ -0,0 +1,297 @@
+---
+id: SHARD-WP-0002
+type: workplan
+title: "federation architecture design"
+domain: whynot
+repo: shard-wiki
+status: active
+owner: tegwick
+topic_slug: whynot
+created: "2026-06-08"
+updated: "2026-06-08"
+depends_on:
+  - SHARD-WP-0001
+---
+
+# SHARD-WP-0002 — Federation architecture design
+
+## Goal
+
+Produce a **federation architecture specification** for shard-wiki: positioning
+against prior art (Federated Wiki, git-backed wikis, ActivityPub), documented
+**decisions and tradeoffs**, and ADR-ready design notes that resolve the open
+questions raised by `research/260608-federation-concepts/` and UseCaseCatalog
+UC-26–UC-33.
+
+Primary deliverable: `spec/FederationArchitecture.md` (created and filled by
+this workplan's tasks).
+
+## Context
+
+- Research: `research/260608-federation-concepts/findings.md`
+- Use cases: `spec/UseCaseCatalog.md` § A (UC-26–UC-33)
+- Aspiration: `INTENT.md` (orchestrator, not engine; mechanism over policy)
+- Related workplan: `SHARD-WP-0001` (page resolution, namespaces, overlays,
+  provenance — federation architecture must align with, not duplicate, those
+  outputs)
+
+**Non-goal:** Implement federation. This workplan produces architecture and
+decision records only.
+
+## Decision topics (overview)
+
+| Topic | Key tradeoff | Primary UCs |
+|-------|--------------|-------------|
+| Orchestrator positioning | Adapter layer vs fedwiki-style homogeneous network | UC-02, UC-26 |
+| Remix primitives | Fork vs overlay vs import vs link-only | UC-04, UC-26, UC-29 |
+| Equivalent page identity | Title/path/alias/graph matching; chorus vs canonical | UC-27, UC-07 |
+| History model | Per-shard journal vs Git coordination journal vs both | UC-29, UC-33 |
+| Union composition | Server orchestrator vs client composition | UC-05, UC-27 |
+| Change notification | Git ping, ActivityPub, poll — adapter transports | UC-31 |
+| Space lifecycle | Permanent vs ephemeral; archive and carry-forward | UC-28, UC-30 |
+| Transclusion depth | Whole-page projection vs inline span | UC-03, UC-32 |
+| Consensus presets | Spread, merge, designated canonical — policy not core | UC-07, UC-27 |
+| Capability matrix | Which federation ops require which adapter capabilities | UC-02–UC-07 |
+
+---
+
+## Architecture positioning and boundaries
+
+```task
+id: SHARD-WP-0002-T1
+status: todo
+priority: high
+```
+
+Write the opening sections of `spec/FederationArchitecture.md`:
+
+- shard-wiki as **orchestration layer** over heterogeneous shards (contrast
+  Federated Wiki homogeneous JSON sites, ikiwiki homogeneous git wikis,
+  ActivityPub activity streams).
+- Explicit **compare, do not equate** mapping from federation research §6.
+- Architectural boundaries: what core owns vs adapters vs UI vs policy config.
+- Relationship to `SHARD-WP-0001` outputs (resolution, namespaces, overlays).
+
+**Tradeoffs to document:** Central Git coordination journal vs fully
+decentralized peer sync; browser-composed union vs server-side orchestrator for
+agents/CLI.
+
+---
+
+## Remix primitives: fork, overlay, import, reference
+
+```task
+id: SHARD-WP-0002-T2
+status: todo
+priority: high
+```
+
+Define when each remix primitive applies and how they interact:
+
+| Primitive | Typical trigger | Writes to remote? |
+|-----------|-----------------|-------------------|
+| **Reference** | Link only | No |
+| **Projection** | Read remote page | No (cache optional) |
+| **Overlay** | Edit read-only shard | No until explicit apply |
+| **Import / fork** | Copy into writable shard | Source unchanged |
+
+Resolve federation research open question #1. Cover capability-limited shards
+(read-only, no diff/merge). Map to UC-26, UC-04, UC-29.
+
+**Tradeoffs:** Fedwiki fork-as-default vs overlay-before-mutation; copy cost
+and attribution portability vs link-only federation.
+
+---
+
+## Equivalent page identity and multi-version presentation
+
+```task
+id: SHARD-WP-0002-T3
+status: todo
+priority: high
+```
+
+Specify how shard-wiki identifies "the same topic" across shards:
+
+- Matching signals: normalized title, path, explicit alias table, link-graph
+  equivalence, manual curator binding.
+- Presentation: chorus-of-voices (UC-27) vs designated canonical (policy).
+- Link to UC-07 divergence detection and reconciliation triggers.
+
+**Tradeoffs:** Automatic matching false positives vs manual curation burden;
+showing all versions vs default canonical with alternates visible.
+
+---
+
+## History, attribution, and coordination journal
+
+```task
+id: SHARD-WP-0002-T4
+status: todo
+priority: high
+```
+
+Define how edit history and attribution flow across federation operations:
+
+- Per-shard revision model (Git commit, engine history, fedwiki-style journal
+  where applicable).
+- Information-space **coordination journal** role for cross-shard operations
+  (fork, import, reconcile, space branch).
+- Portable attribution requirements for UC-29 (frictionless remix).
+
+**Tradeoffs:** Fedwiki journal-per-page vs Git-only; duplication of history vs
+reconstructibility from coordination journal; storage cost of embedded media on
+import.
+
+---
+
+## Union composition layer
+
+```task
+id: SHARD-WP-0002-T5
+status: todo
+priority: medium
+```
+
+Decide where the **union view** is assembled:
+
+- Orchestrator API (server-side graph for agents, CI, non-browser clients).
+- Optional client-side composition (fedwiki-style browser pull) as a consumer
+  pattern, not the only path.
+- Caching, freshness, and invalidation interaction with UC-03, UC-05, UC-31.
+
+**Tradeoffs:** Single composition point (simpler provenance) vs distributed
+composition (fedwiki resilience); cache staleness vs live-pull latency.
+
+---
+
+## Change notification and subscription transports
+
+```task
+id: SHARD-WP-0002-T6
+status: todo
+priority: medium
+```
+
+Specify change-notification as an **optional adapter capability**:
+
+- Transports: git hook / pinger (ikiwiki), ActivityPub Create/Update (XWiki),
+  WebDAV ETag, polling fallback.
+- What a subscription triggers: projection refresh, reconciliation queue,
+  RecentChanges union entry (UC-31, UC-17).
+- Out-of-scope vs in-scope for v1.
+
+**Tradeoffs:** Push freshness vs implementation complexity; ActivityPub as
+notification-only vs content-bearing share; dependency on external fediverse
+infrastructure.
+
+---
+
+## Information space lifecycle
+
+```task
+id: SHARD-WP-0002-T7
+status: todo
+priority: medium
+```
+
+Model lifecycle states for root entities / information spaces:
+
+- Active, read-only archived, retired (detached), merged-into-successor.
+- Carry-forward workflow (UC-28, UC-30): selective import from archived shard.
+- Space-level fork / branch (UC-33): coordination journal + shard config branch.
+
+**Tradeoffs:** First-class ephemeral "happenings" vs permanent spaces only;
+automatic archive vs manual; whether retirement deletes projections or preserves
+read-only union entries.
+
+---
+
+## Transclusion and projection depth
+
+```task
+id: SHARD-WP-0002-T8
+status: todo
+priority: medium
+```
+
+Distinguish projection levels:
+
+| Level | UC | Behavior |
+|-------|-----|----------|
+| Whole-page projection | UC-03 | Lazy full page from remote shard |
+| Block/span transclusion | UC-32 | Inline embed with origin + freshness |
+| Link reference | UC-08 | Pointer only |
+
+Define provenance display requirements and staleness semantics for UC-32.
+Reference Xanadu transclusion patterns without adopting unbuilt Xanadu scope.
+
+**Tradeoffs:** Live transclusion fragility (link rot, remote down) vs snapshot
+on import; core orchestrator support vs Markdown extension + adapter.
+
+---
+
+## Consensus and reconciliation policy catalog
+
+```task
+id: SHARD-WP-0002-T9
+status: todo
+priority: medium
+```
+
+Document **configurable policy presets** (mechanism over policy):
+
+- Fedwiki-spread (versions coexist; popularity implicit).
+- Designated canonical shard (explicit write target).
+- Git-merge reconciliation (ikiwiki-style).
+- Overlay-only (no destructive merge on read-only sources).
+- Vote-to-merge / editorial gate (optional, UI-layer).
+
+Map presets to UC-07, UC-27. Core provides primitives; policy selects preset.
+
+**Tradeoffs:** Default policy for L0 open mode vs team mode; exposing conflicts
+vs auto-merge when backends support it.
+
+---
+
+## Federation operations capability matrix
+
+```task
+id: SHARD-WP-0002-T10
+status: todo
+priority: medium
+```
+
+Produce a capability matrix: which federation operations require which adapter
+capabilities (read, write, diff, merge, lock, version, publish, notify,
+transclude-source).
+
+Cross-check against INTENT capability-aware adapters principle. Identify
+graceful degradation paths for limited backends (read-only participant,
+projection-only, patch target).
+
+Feeds `spec/TechnicalSpecificationDocument.md` adapter contract section.
+
+---
+
+## Acceptance criteria
+
+- `spec/FederationArchitecture.md` exists with all ten topic sections and an
+  explicit **decisions / deferred / open** table per topic.
+- Each decision honors INTENT: mechanism over policy, union without erasure,
+  overlay before mutation, no silent remote mutation, shard sovereignty.
+- UC-26–UC-33 are traceable to architecture sections.
+- Conflicts or dependencies on `SHARD-WP-0001` outputs are listed (e.g.
+  namespace model affects equivalent-page identity).
+- `SHARD-WP-0001` and `SHARD-WP-0002` can proceed in parallel where topics
+  are independent; merge conflicts in spec are resolved before implementation
+  workplan starts.
+
+## Suggested task order
+
+1. T1 positioning (frames everything)
+2. T2 remix primitives + T3 equivalent identity (parallel)
+3. T4 history model
+4. T5 composition + T6 notification (parallel)
+5. T7 lifecycle + T8 transclusion (parallel)
+6. T9 policy catalog + T10 capability matrix (parallel, finalize doc)