generated from coulomb/repo-seed
tegwick
27da940df1
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>
shard-wiki
Git-based Markdown wiki orchestrator and federation layer.
shard-wiki joins heterogeneous wiki-shaped page stores (shards) into a
coherent information space while preserving provenance, capabilities, and
history. It is an orchestration layer, not a wiki engine.
Status
Early-stage: Python scaffold, intent and specification groundwork, active design
workplan. See SCOPE.md for current maturity.
Documentation
| Document | Purpose |
|---|---|
| INTENT.md | Aspiration and boundaries |
| SCOPE.md | What we achieve now |
| AGENTS.md | Agent working guide |
| docs/repository-layout.md | How this repo organizes information |
Quick start
pip install -e ".[dev]"
pytest
Layout
research/ explorations (yymmdd-prefixed)
demand/ inbound unreviewed requirements
spec/ implementation specifications
workplans/ State Hub–registered tasks
docs/ stakeholder documentation
wiki/ collaborative knowledge (wiki UI when connected)
issues/ ticket mirrors
history/ archived material (yymmdd-prefixed)