generated from coulomb/repo-seed
Bootstrap registry/indexes/capabilities.yaml and migrate helix_forge capability entries owned by this repository for federation publishing.
115 lines
3.8 KiB
Markdown
115 lines
3.8 KiB
Markdown
---
|
|
id: capability.wiki.shard-orchestration
|
|
name: Wiki Shard Orchestration
|
|
summary: Present a union of pages across heterogeneous wiki-shaped shards while preserving each shard's provenance, capabilities, and history.
|
|
owner: shard-wiki
|
|
status: draft
|
|
domain: helix_forge
|
|
tags: [wiki, federation, orchestration, union, shard-wiki]
|
|
|
|
maturity:
|
|
discovery:
|
|
current: D5
|
|
target: D6
|
|
confidence: high
|
|
rationale: >
|
|
Grounded in 84 documented use cases and a twice-reviewed whole-system
|
|
architecture (CoreArchitectureBlueprint) derived from ~23 prior-art systems.
|
|
availability:
|
|
current: A2
|
|
target: A5
|
|
confidence: medium
|
|
rationale: >
|
|
InformationSpace orchestrator (attach -> resolve -> read, chorus on
|
|
ambiguity) works as a Python source module; network API and incremental
|
|
union are planned.
|
|
|
|
external_evidence:
|
|
completeness:
|
|
level: C2
|
|
name: Partial
|
|
confidence: medium
|
|
basis: scope_vs_intent_and_consumer_expectations
|
|
satisfied_expectations:
|
|
- attach folder shards and read a union page with layered provenance
|
|
- chorus presentation of equivalent-but-divergent pages (union without erasure)
|
|
broken_expectations:
|
|
- incremental union maintenance and equivalence index not yet built
|
|
- write-through federation transports not yet built
|
|
out_of_scope_expectations:
|
|
- hosting or replacing the underlying wiki engines
|
|
reliability:
|
|
level: R1
|
|
confidence: low
|
|
basis: consumer_quality_signals
|
|
known_reliability_risks:
|
|
- early implementation; 64 tests but no production exposure
|
|
|
|
discovery:
|
|
intent: >
|
|
Let independently stored, differently implemented wikis behave as one
|
|
coherent, versionable, inspectable information space without homogenizing them.
|
|
includes:
|
|
- union resolution across shards (identity-keyed)
|
|
- chorus / designated-canonical presentation of equivalent pages
|
|
- lazy replication projection of remote content with freshness
|
|
excludes:
|
|
- implementing a backend wiki engine (see capability.wiki.engine-typed-extensions)
|
|
- silent remote mutation
|
|
assumptions:
|
|
- canonical truth lives in shards + a git coordination journal; the union is derived
|
|
use_cases:
|
|
- "shard-wiki UseCaseCatalog UC-01..UC-07, UC-26..UC-33 (information space, federation, coordination)"
|
|
|
|
availability:
|
|
current_level: A2
|
|
target_level: A5
|
|
current_artifacts:
|
|
- "shard-wiki/src/shard_wiki/union/"
|
|
- "shard-wiki/src/shard_wiki/space.py"
|
|
target_artifacts:
|
|
- orchestrator network API
|
|
consumption_modes:
|
|
- source module
|
|
|
|
relations:
|
|
depends_on:
|
|
- capability.wiki.adapter-contract
|
|
- capability.wiki.page-model
|
|
- capability.wiki.coordination-journal
|
|
supports:
|
|
- capability.wiki.federation-models
|
|
|
|
evidence:
|
|
documentation:
|
|
- "shard-wiki/spec/CoreArchitectureBlueprint.md"
|
|
- "shard-wiki/spec/FederationArchitecture.md"
|
|
tests:
|
|
- "shard-wiki/tests/test_union.py"
|
|
- "shard-wiki/tests/test_integration.py"
|
|
|
|
consumer_guidance:
|
|
recommended_for:
|
|
- composing multiple Markdown/wiki stores into one provenance-preserving view
|
|
not_recommended_for:
|
|
- replacing a single wiki engine
|
|
known_limitations:
|
|
- resolution is recompute-on-read until the incremental tier lands
|
|
---
|
|
|
|
# Wiki Shard Orchestration
|
|
|
|
shard-wiki's core capability: orchestrate wiki-shaped content across heterogeneous *shards*
|
|
as a union of pages, preserving provenance, capabilities, and history per shard. Canonical
|
|
truth stays at the edges (shards + the git coordination journal); the union is a derived,
|
|
recomputable view (orchestrator, not engine).
|
|
|
|
## Assessment notes
|
|
|
|
### Discovery
|
|
Grounded by `UseCaseCatalog.md` (84 UCs) and the hardened `CoreArchitectureBlueprint.md`.
|
|
|
|
### Availability
|
|
`InformationSpace` provides attach/resolve/read today (source module); a network API is the
|
|
target availability step.
|