research: XWiki deep dive (impl, extension interfaces, ecosystem); UC-38/39

Deep dive into XWiki past the landscape scan: component/DI architecture,
document + class/object data model, oldcore, Hibernate storage + xwikircs
history, ObservationManager events, rendering pipeline, multi-wiki; the full
extension-interface surface (components, Java/wiki macros, script services,
UIX/UIXP, JAX-RS REST, event listeners, resource handlers); and the
extensions.xwiki.org ecosystem (XAR/JAR/WebJar, 900+ extensions).

Catalog:
- UC-38 make a wiki engine federation-capable via its native extension API
  (composable integration — first engine-side-direction UC; XWiki is proof)
- UC-39 attach a wiki-as-application-platform shard (bodiless typed pages)
- enrich UC-31 (ObservationManager event-driven sync), UC-34 (XObject model),
  UC-36 (xwikircs internal history) with concrete XWiki specifics

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

spec/UseCaseCatalog.md

@@ -3,8 +3,8 @@
 Status: **draft** · Date: 2026-06-08 · Updated: 2026-06-13
 
 Promoted from `research/260608-c2-wiki-origins/`,
-`research/260608-yawex-prior-art/`, `research/260608-federation-concepts/`, and
-`research/260608-wikiengines-overview/`.
+`research/260608-yawex-prior-art/`, `research/260608-federation-concepts/`,
+`research/260608-wikiengines-overview/`, and `research/260613-xwiki-deep-dive/`.
 See InfoTechPrimers on coulomb.social for use-case catalog conventions.
 
 ## Conventions
@@ -153,7 +153,10 @@ coded core behavior. Relates to UC-28.
 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.  
+Transport is adapter concern; freshness surfaced in UC-24. XWiki deep dive adds a
+concrete push transport: an engine event bus (`ObservationManager`
+`DocumentUpdatedEvent`) consumed by a listener, vs polling REST history
+(`research/260613-xwiki-deep-dive/findings.md` §2.5, §8 Q4).  
 **Priority:** Later
 
 ### UC-32 — Transclude remote span with live freshness
@@ -187,7 +190,9 @@ without silently discarding the structure.
 knowledge objects. Markdown-first must **degrade gracefully**, not flatten:
 needs a passthrough / sidecar-metadata / provenance escape hatch. Page-model
 question deferred to `SHARD-WP-0002` (findings §6 Q1). Distinct from UC-02
-(assumes Markdown-shaped pages).  
+(assumes Markdown-shaped pages). XWiki is the concrete exemplar: pages carry typed
+XObjects against an XClass schema (`research/260613-xwiki-deep-dive/findings.md`
+§2.3); UC-39 covers the extreme where the page is *only* structure.  
 **Priority:** Later
 
 ### UC-35 — Attach a shard with coarse write granularity
@@ -212,7 +217,9 @@ history it otherwise lacks.
 **Notes:** Many engines expose revisions but not portable, git-style history.
 The **coordination journal** supplies the Git-addressable layer (INTENT). Open:
 is the journal authoritative or a mirror reconciled back to the engine
-(findings §6 Q3)? Complements UC-07 divergence and UC-24 provenance.  
+(findings §6 Q3)? Complements UC-07 divergence and UC-24 provenance. XWiki's
+internal RCS table (`xwikircs`) is a concrete instance
+(`research/260613-xwiki-deep-dive/findings.md` §2.4).  
 **Priority:** Later
 
 ### UC-37 — Attach a static engine export as a read-only backup shard
@@ -228,6 +235,35 @@ UC-28 (carry pages *forward* into a new space); here the dump itself is the
 shard. Read-only mode in `spec/ArchitectureBlueprint.md`.  
 **Priority:** Later
 
+### UC-38 — Make a wiki engine federation-capable via its native extension API
+
+**Actor:** Engine developer / integrator  
+**Goal:** Turn an existing wiki engine into a federation participant by hosting a
+shard-wiki adapter *inside* the engine through its own extension interface, rather
+than scraping it from outside.  
+**Source:** wikiengines, intent  
+**Notes:** Realizes INTENT *composable integration* — first UC for the **engine-side**
+direction (others attach engines from outside). XWiki is the proof case: its
+component model (`@Component` + role hint) can replace auth/storage/rights, its
+REST API and `ObservationManager` give transport + change events, and UIX adds
+surfacing — enough to host a high-fidelity adapter
+(`research/260613-xwiki-deep-dive/findings.md` §3). Trade-off vs an external REST
+adapter (needs deploy access, higher fidelity) is open (findings §8 Q3).  
+**Priority:** Later
+
+### UC-39 — Attach a wiki-as-application-platform shard (pages as typed records)
+
+**Actor:** Maintainer  
+**Goal:** Attach an engine where pages are structured records or forms with little
+or no prose body (XWiki AppWithinMinutes apps / XObjects), and represent them in the
+union without inventing a fake Markdown body.  
+**Source:** wikiengines, intent  
+**Notes:** The extreme of UC-34 — not *annotations on prose* but **bodiless
+structured pages**. Forces the question: does the page model require a Markdown body,
+or can a page be purely typed data (`research/260613-xwiki-deep-dive/findings.md`
+§8 Q2)? Affects union views, diff, and search. Deferred to `SHARD-WP-0002`.  
+**Priority:** Later
+
 ---
 
 ## B. Knowledge work and collaboration
@@ -444,6 +480,8 @@ CamelCase and `[[free links]]`. Markdown-first link semantics TBD.
 | UC-35 | | | | ✓ | ✓ |
 | UC-36 | | | | ✓ | ✓ |
 | UC-37 | | | | ✓ | ✓ |
+| UC-38 | | | | ✓ | ✓ |
+| UC-39 | | | | ✓ | ✓ |
 | UC-08 | ✓ | | |
 | UC-09 | ✓ | | |
 | UC-10 | ✓ | | |
@@ -513,12 +551,16 @@ CamelCase and `[[free links]]`. Markdown-first link semantics TBD.
 | Coarse write granularity (TiddlyWiki single-file; whole-space DB writes) | UC-35 |
 | Internal-only revision history (Confluence, MediaWiki) needs portable git history | UC-36 |
 | Static exports / read-only archives (MediaWiki XML dump, archived C2, HTML mirror) | UC-37 |
+| Engine hosts adapter via native extension API (XWiki components/REST/UIX) | UC-38 |
+| Wiki-as-application-platform, bodiless typed pages (XWiki AppWithinMinutes/XObjects) | UC-39 |
 
-Note: the scan mostly **reinforced** existing UCs and the L0→L4 ladder rather than
-adding scenarios — its primary yield is adapter-contract constraints
+Note: the landscape scan mostly **reinforced** existing UCs and the L0→L4 ladder
+rather than adding scenarios — its primary yield is adapter-contract constraints
 (`research/260608-wikiengines-overview/findings.md` §3, §5), tracked in
 `workplans/SHARD-WP-0002-federation-architecture.md`. UC-34–UC-37 are the
-genuinely new attachment scenarios it surfaced.
+attachment scenarios it surfaced. UC-38–UC-39 come from the **XWiki deep dive**
+(`research/260613-xwiki-deep-dive/findings.md` §7), which also enriched UC-31
+(event-driven sync), UC-34 (XObject model), and UC-36 (`xwikircs` history).
 
 ---