coulomb/shard-wiki
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

spec(SHARD-WP-0006 T3): adapter conformance suite (§6.6)

Browse Source 
Fixes B-2. Capability profiles are verified, not self-asserted: the contract
ships a versioned conformance suite that exercises each declared verb/position
against observed behaviour; passing is an admissibility precondition (lying
profiles rejected at registration); mismatch reported as a capability diff.
Makes I-3 / §6.5 sound rather than aspirational.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Bernd Worsch
2026-06-15 02:01:37 +02:00
parent 08a2148079
commit 3a753a6f3b
2 changed files with 29 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
spec/CoreArchitectureBlueprint.md
View File

@@ -317,6 +317,34 @@ actually consults. They are:
Everything else is a single-axis check. This table *is* the degradation contract: it is small,
enumerated, and testable — the proof obligation behind "core logic written once."
### 6.6 Conformance — profiles are verified, never self-asserted
Capability-as-data (I-3) and the entire degradation contract (§6.5) rest on one assumption:
**the profile tells the truth.** If an adapter declares `merge=git/text` but corrupts merges,
or claims `notify` and never emits, it silently poisons every degradation decision in core —
the failure is invisible because core *believed the data* (review B-2). So the profile is not
taken on trust:
- **The contract ships a versioned conformance suite.** A published battery that, given a live
binding, **exercises each declared verb and each declared spectrum position and checks that
observed behaviour matches the claim** (a `write` round-trips; a `diff` is real; `notify`
actually fires; an "encrypted/opaque" shard genuinely refuses plaintext query; an
implication-rule position, §6.5(b), holds). The suite is versioned *with* the contract, so an
adapter proves conformance against a known contract version.
- **Passing conformance is an admissibility precondition.** A binding that fails (declares a
capability it does not honour) is **rejected at registration**, not run in production with a
lying profile. Capability discovery (§6.4) therefore yields a *verified* profile.
- **Self-reported, then verified.** Adapters still *declare* their profile (discovery stays
cheap); conformance *verifies* the declaration. The two together are what make I-3 and §6.5
sound rather than aspirational — degradation logic acts on verified data.
- **Mismatch is data, not a crash.** A conformance gap is reported as a precise
capability-by-capability diff (what was claimed vs observed), so an adapter author fixes the
profile or the code; degraded-but-honest registration (drop the unsupported claim) is allowed.
This is the same discipline a versioned store interface needs in general (the `Foswiki::Store`
lineage that inspired the contract): a backend may only participate behind the interface if it
*demonstrably* behaves as the interface says.
---
## 7. Top waist — the Wiki Page Model (L2)