Route InformationSpace.all_pages through a maintained UnionIndex: equivalence is served from the incrementally maintained index (curator bindings re-synced live from the log fold + detected content edges), exposed in decision-log string form so results are a behaviour-preserving superset. The index is built lazily and rebuilt (bounded fallback) when the union mutates (attach/edit invalidate it); reindex() forces a rebuild and verify_index() runs the I-2 self-healing checker. all_pages() gains an optional equivalence_groups source (default = fold) so direct callers are unaffected. SCOPE updated; WP-0011 done. 173 tests green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
6.3 KiB
SCOPE
One-Liner
Git-based Markdown wiki orchestrator and federation layer — early-stage scaffold with intent, research, and specification groundwork; domain model not yet implemented.
Mode Of Operation
Close the gap between this file and INTENT.md by exploring the problem space
(research/), reviewing inbound demand (demand/), refining specifications
(spec/), and implementing through registered workplans (workplans/).
Learnings update both SCOPE and INTENT where necessary.
Current Status
| Layer | State |
|---|---|
| Code | Foundation slice implemented (SHARD-WP-0007): provenance + policy leaves, model (Identity/Placement/Span/Page/CapabilityProfile), adapters (contract + FolderAdapter + conformance suite), coordination (event-sourced DecisionLog), union (resolution + chorus, overlay-aware), InformationSpace orchestrator. Write path added (SHARD-WP-0008): writable adapter, overlay engine (draft→patch→apply-under-drift), edit() unifies write-through + overlay-before-mutation. Native engine implemented (SHARD-WP-0014): engine (kernel + typed-extension runtime + per-shard activation [ADR-0001] + capability-profile-from-extensions + EngineShardAdapter + the ext.struct built-in) — an engine shard attaches to an InformationSpace as a canonical-mode shard. Git-backed coordination log (SHARD-WP-0009): DecisionLog storage factored behind an EventStore; GitEventStore makes the log git-addressable (each space a ref, append = immutable CAS-guarded commit), a per-space AppendAuthority (lease) gives a single-writer total order with re-grantable HA hand-off, cross-process read-your-writes verified, and a verbatim one-time importer (migrate_space/JSONL) replays in-memory logs into git; InformationSpace.git_backed(...) wires it. Derived views (SHARD-WP-0010): views (wikilink + red-link model, BackLinks, RecentChanges, AllPages/SiteMap) — recomputable, provenance-carrying, presentation-free, exposed via InformationSpace.backlinks/recent_changes/all_pages/site_map. Incremental-first derived tier (SHARD-WP-0011): incremental (indexed equivalence via MinHash/LSH blocking + verify, change-driven delta maintenance with retraction/propagation, Merkle-style digest + self-healing I-2 consistency-checker, UnionIndex routed behind InformationSpace.all_pages with rebuild as explicit fallback). 173 tests green, ~97% coverage |
| Intent | INTENT.md established; authorization-in-core amendments drafted |
| Research | yawex prior art; c2 origins; federation concepts; wikiengines overview (research/260608-*/); XWiki/TWiki/Foswiki deep dives (research/260613-*/); Xanadu + ZigZag + Roam + Obsidian + Notion + Joplin + Logseq + local-first workspaces (Anytype/AFFiNE/AppFlowy) + Trilium + Wiki.js + Federated Wiki + Wikibase + git-forge wikis + TiddlyWiki + ikiwiki + Quip + MojoMojo + Oddmuse + UseModWiki deep dives & shard-spectrum synthesis (research/260614-*/) |
| Demand | NetKingdom integration asks captured, not yet negotiated |
| Spec | CoreArchitectureBlueprint (whole-system, hardened via SHARD-WP-0005/0006) + FederationArchitecture + FederationRequirements + TSD §A adapter contract + ArchitectureBlueprint (auth/history) + WikiEngineCoreArchitecture (headless API-first engine, SHARD-WP-0013) drafted; UseCaseCatalog 84 UCs (+ engine capability-structure layer); PRD scaffold |
| Work | SHARD-WP-0001 done (6 ADRs: yawex-derived federation requirements → spec/FederationRequirements.md); SHARD-WP-0002 done (18 tasks → FederationArchitecture.md [T1–T10, T17] + TechnicalSpecificationDocument.md §A adapter contract [T11–T16, T18]); SHARD-WP-0003 done (9 engine dives complete); SHARD-WP-0004 done (all 8 computational-knowledge dives T1–T8 complete + "computational page model" synthesis); SHARD-WP-0005 done (9 tasks: CoreArchitectureBlueprint hardened against the 260615 review); SHARD-WP-0006 done (5 tasks: round-2 hardening — overview reconciled, event-sourced coordination + append authority, adapter conformance, incremental correctness + I-2 verification) |
In Scope (today)
- Establishing repository documentation structure and specification groundwork.
- Federation design informed by yawex prior art (page resolution, namespaces, derived views, provenance, overlays).
- Authorization model design (delegated authentication, core authorization).
- Shard adapter contract and wiki page model (to be specified, then implemented).
- Git-backed coordination journal for information spaces.
- A native, headless, API-first wiki-engine core (small typed-extension core, as a canonical-mode shard backend) — design via SHARD-WP-0013; optimized for data-source integration and agent access.
- State Hub workplan registration and consistency sync.
Out Of Scope (today)
- A wiki-engine UI or rendering pipeline (the engine is headless/API-first; presentation is a consumer concern). A bundled standalone UI is not provided.
- Authentication, credential storage, or user directory implementation.
- Hard-coded editorial, sync, or conflict-resolution policy.
- Generic file mirroring independent of wiki-page semantics.
- Production deployment, multi-tenant operations, or enterprise IAM rollout.
Boundary Rule
shard-wiki orchestrates wiki-shaped content across heterogeneous shards. It
provides mechanisms (federation, projection, overlay, patching, reconciliation);
policy (canonical source, conflict preference, access rules) remains explicit and
configurable. Identity comes from pluggable providers; authorization decisions
live in core.
Current Planning
Design work is tracked in workplans/SHARD-WP-0001-yawex-requirements.md
(yawex-derived resolution, namespaces, overlays) and
workplans/SHARD-WP-0002-federation-architecture.md (federation architecture,
decisions, tradeoffs). Research continues under
workplans/SHARD-WP-0003-engine-dives-batch.md (remaining new-insight wiki
engines + git-forge wikis + classic engines) and
workplans/SHARD-WP-0004-computational-knowledge-systems.md (literate
programming, computational notebooks, live-coding REPLs, image-based/moldable
environments — the executable/computational page-model thread). Specification
outputs land in spec/. Inbound integration asks remain in demand/ until
reviewed and promoted into spec or workplans.