reuse-surface/registry/capabilities/capability.wiki.adapter-contract.md

id, name, summary, owner, status, domain, tags, maturity, external_evidence, discovery, availability, relations, evidence, consumer_guidance

id	name	summary	owner	status	domain	tags	maturity	external_evidence	discovery	availability	relations	evidence	consumer_guidance
capability.wiki.adapter-contract	Capability-Aware Shard Adapter Contract	A versioned backend interface where each binding declares a verified capability profile (positions on capability spectra), so federation ops degrade by capability.	shard-wiki	draft	helix_forge	wiki adapter capability contract conformance shard-wiki	discovery availability current target confidence rationale D5 D6 high Fifteen capability spectra with an orthogonal core + implication rules, plus a normative contract spec (TSD Section A); derived from a ~23-system synthesis. current target confidence rationale A2 A5 medium AdapterContract + a read/write FolderAdapter + a conformance suite that verifies declared profile == observed behaviour exist as a source module.	completeness reliability level name confidence basis satisfied_expectations broken_expectations out_of_scope_expectations C2 Partial medium scope_vs_intent_and_consumer_expectations versioned interface with declared, conformance-verified capability profiles one concrete adapter (file-store) passes the conformance suite only one substrate implemented (git-IS-store, REST, CRDT adapters planned) hosting backends level confidence basis known_reliability_risks R1 low consumer_quality_signals single adapter implemented so far	intent includes excludes use_cases Mediate heterogeneity at one narrow waist: a backend participates by implementing a versioned interface and declaring a verified position on each capability spectrum. capability profile as data (orthogonal-core spectra + implied positions) operation verbs (read/write/diff/merge/notify/.../derive-projection/execute) a conformance suite (profiles verified, not self-asserted) assuming uniform backend capabilities shard-wiki UseCaseCatalog UC-34..UC-43, UC-50, UC-57, UC-60..UC-69 (shard attachment & adapter binding)	current_level target_level current_artifacts consumption_modes A2 A5 shard-wiki/src/shard_wiki/adapters/ source module	depends_on supports capability.wiki.page-model capability.wiki.shard-orchestration	documentation tests shard-wiki/spec/TechnicalSpecificationDocument.md (Section A) shard-wiki/spec/CoreArchitectureBlueprint.md (Section 6) shard-wiki/tests/test_folder_adapter.py shard-wiki/tests/test_conformance.py	recommended_for not_recommended_for known_limitations exposing any page store as a capability-described, conformance-checked shard backends that cannot honestly describe their capabilities reference implementation covers the file-store substrate only so far

Capability-Aware Shard Adapter Contract

The bottom narrow waist of shard-wiki: a versioned interface plus a verified capability profile per binding. Core logic is written once against capabilities (not per-backend), and the conformance suite rejects profiles whose declared abilities don't match observed behaviour.

Assessment notes

Discovery

Fifteen spectra reduced to an orthogonal core with implication rules (CoreArchitectureBlueprint Section 6.5); normative in TSD Section A.

Availability

adapters/ ships the contract, a folder adapter, and assert_conformant.