Register shard-wiki capabilities (7 wiki.* registry entries)

Adds capability.wiki.{shard-orchestration, adapter-contract, page-model,
coordination-journal, overlay, federation-models, engine-typed-extensions}
with honest D/A/C/R maturity vectors, relations, and shard-wiki spec/test
evidence; updates registry/indexes/capabilities.yaml. reuse-surface validate: ok.
Source: shard-wiki SHARD-WP-0013 T1.

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

registry/capabilities/capability.wiki.shard-orchestration.md

@@ -0,0 +1,114 @@
+---
+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.