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>
Mine the one research dir not yet promoted (260608-wikiengines-overview) into
the catalog. Adds four heterogeneous-backend attachment scenarios the other
research didn't surface:
- UC-34 attach structured/semantic shard without lossy flattening (SMW, XWiki)
- UC-35 attach shard with coarse write granularity (TiddlyWiki single-file)
- UC-36 supply git-addressable history to internal-history engine (Confluence)
- UC-37 attach static export as read-only backup shard (MediaWiki dump)
Adds a `wikiengines` source token + traceability column and a wikiengines
mapping subsection. The scan mostly reinforced existing UCs and the L0→L4
ladder; its main yield is adapter-contract constraints tracked in SHARD-WP-0002.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
