spec(SHARD-WP-0006 T5): track §C as O-8..O-12; refresh decisions/traceability; close-out

Adds O-8 (preset bundles), O-9 (shard sharing vs tenant partition), O-10
(span authz + transclusion ⊕), O-11 (union under unavailability), O-12
(append-log throughput) to §12. Refreshes §14 decisions (event-sourced
coordination, conformance, I-2 verification) and §16 traceability (round-2
review + WP-0006). Flips SHARD-WP-0006 done.

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

SCOPE.md

@@ -22,7 +22,7 @@ Learnings update both SCOPE and INTENT where necessary.
 | 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 architecture, hardened via SHARD-WP-0005) + ArchitectureBlueprint (auth/history) drafted; UseCaseCatalog 84 UCs from research; PRD/TSD scaffolds |
-| Work | `SHARD-WP-0001` active (6 tasks); `SHARD-WP-0002` active (18 tasks: T1–T10 federation + T11–T16 adapter contract + T17 federation-model taxonomy + T18 computational content, re-folded from synthesis v3 + the computational page model); `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) |
+| Work | `SHARD-WP-0001` active (6 tasks); `SHARD-WP-0002` active (18 tasks: T1–T10 federation + T11–T16 adapter contract + T17 federation-model taxonomy + T18 computational content, re-folded from synthesis v3 + the computational page model); `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)
 

spec/CoreArchitectureBlueprint.md

@@ -30,7 +30,10 @@ Everything in shard-wiki follows from one organising decision — that state com
 > **2. Coordination-canonical** — durable state *born inside shard-wiki* that encodes human
 > or cross-shard decisions and exists nowhere else: overlays (the local truth against a
 > read-only shard), curator equivalence bindings, alias tables, merge/reconciliation
-> decisions. It lives in the **Git coordination journal**.
+> decisions. It is recorded as an **append-only decision log in the Git coordination
+> journal** (event-sourced, §8.1); the *queryable current form* of that state (the effective
+> alias table, the equivalence set) is a **derived fold** of the log — i.e. tier 3, not tier 2.
+> What is canonical is the **log of decisions**, not any mutable snapshot of them.
 > **3. Derived-disposable** — everything shard-wiki *computes* from (1)+(2): the union graph,
 > equivalence index, query indexes, projections, views. It can be deleted and recomputed.
 >
@@ -114,7 +117,7 @@ principles fused with the research through-lines.
  X-cut  │  L5  Authorization (PEP/PDP, identity-provider iface) →         │ X-cut
  Prove- │      see ArchitectureBlueprint.md (L0–L4 ladder)                │ Capa-
  nance  ├───────────────────────────────────────────────────────────────┤ bility
-  ▲     │  L4  Union & Projection  (DERIVED, rebuildable cache)           │   ▲
+  ▲     │  L4  Union & Projection  (DERIVED · rebuild=fallback)           │   ▲
   │     │      identity resolution · equivalence/chorus · union graph ·   │   │
   │     │      replication+derivation projections · moldable view registry│   │
   │     │      · derived query index                                      │   │
@@ -127,7 +130,7 @@ principles fused with the research through-lines.
   │     │      provenance envelope · the page shapes                      │   │
   │     ├───────────────────────────────────────────────────────────────┤   │
   │     │  L1  Shard Adapter Contract  ── BOTTOM WAIST ──                 │   │
-  │     │      versioned iface · capability profile (15 spectra) ·        │   │
+  │     │      versioned iface · capability profile (orthogonal) ·        │   │
   │     │      attachment-mode binding · operation verbs                  │   │
   └──── ├───────────────────────────────────────────────────────────────┤ ──┘
         │  L0  Backends (not ours): git repos, wiki/ subdirs, Gitea/      │
@@ -163,19 +166,25 @@ parallel terms.
 - **Capability profile** — a shard binding's position on each of the 15 spectra (§6) plus its
   supported verbs. *The* data structure that drives degradation.
 - **Wiki page model** — the L2 backend-neutral page; the top waist.
-- **Page identity vs placement** — a page is an entity (identity); it may have N placements
-  (paths/shards). Addressing, equivalence, and transclusion key on identity (I-9).
-- **Provenance envelope** — the metadata wrapper every artifact carries: source shard,
-  freshness, liveness, authorization context, overlay status, divergence, derivation lineage.
-- **Coordination journal** — the L3 Git-backed record of change flows for a space, and the
-  durable home of all **coordination-canonical** state (§1): overlays, curator equivalence
-  bindings, alias tables, merge/reconciliation decisions. This state is born inside shard-wiki,
-  exists nowhere else, and is *not* derived — it must be committed, never recomputed.
+- **Page identity vs placement vs equivalence** — a page is an entity with a *stable handle*
+  (identity); it may have N placements (paths/shards); **addressing and transclusion key on
+  identity, but equivalence keys on content fingerprint *across* identities** (§7.2, I-9). The
+  three are distinct mechanisms — never conflate identity with a fingerprint.
+- **Provenance envelope** — the metadata each artifact carries (source shard, freshness,
+  liveness, authz context, overlay status, divergence, lineage), stored **layered**: a
+  page-level envelope + span-level *deltas*, so per-span cost is near-zero when uniform (§7.3).
+- **Coordination journal** — the L3 Git-backed, **append-only decision log** for a space: the
+  durable home of all **coordination-canonical** state (§1, §8.1) as *events* (overlay-created,
+  binding-made, alias-set, merge-decided), plus the content change-flow record. It is event-
+  sourced — committed, never overwritten; the queryable current coordination state is a derived
+  fold of it (§8.1).
 - **Overlay** — a non-destructive local edit against a remote/read-only/limited shard,
   representable as draft/patch/commit/MR before destructive apply. Coordination-canonical: an
   unapplied overlay is the local truth and lives in the journal.
-- **Projection** — a derived view of shard content, typed on two axes (§8): *kind*
-  (replication | derivation) × *liveness* (static … irreducibly-live).
+- **Projection** — a derived view of shard content. The default is a **plain lazy
+  replication-projection** (a freshness-stamped cache); only *source* content needing
+  transform/evaluate uses the **derivation-projection** extension point with its two-axis
+  typing (kind × liveness) and the moldable view registry (§8.4–§8.5).
 - **Federation model** — the selected coordination strategy for a space (§ taxonomy, T17).
 - **Shard mode** — read-only · write-through · mirrored · projected · cached · canonical
   (a *policy* selection constrained by the capability profile).
@@ -308,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)
@@ -391,6 +428,42 @@ operations (fork, import, reconcile, overlay-apply, space-branch) and **is** the
 the journal supplements (begins-now / mirrors-forward / snapshots-replica) or imports
 (backfill open file history). History portability is a spectrum, handled per profile (axis 5).
 
+**The journal is an append-only decision log; current coordination state is a derived fold
+(review B-3).** The first draft said coordination-canonical state "lives in the journal"
+without saying how Git — excellent for history, poor for mutable structured state — represents
+an alias table or an equivalence graph. Resolution: **event sourcing.** The journal stores
+*decisions as events* (`overlay-created`, `binding-made`, `alias-set`, `merge-decided`,
+`page-forked`), append-only and git-addressable (so history/patch/review/backup over
+coordination state come for free — I-6 is *strengthened*, not bypassed). The **queryable
+current state** (the effective alias table, the live equivalence set) is a **derived fold** of
+the log — tier-3 disposable, indexed like any other derived structure (§8.7), rebuilt by
+replaying the log. So "all equivalences touching X" is an index lookup, not an O(scan) of Git.
+This is the clean form of the §1 three-state model: **the log is canonical; its folded current
+state is derived.**
+
+**Concurrency: who may append (review B-1).** A multi-tenant L4 deployment runs several
+orchestrator instances, so "the journal is local Git, single writer" is not given. The model:
+
+- **One *append authority* per information space.** Appends to a space's log are serialized
+  through a single logical writer (a per-space lease/leader; instances without the lease forward
+  their append intents to it). This makes the log a **totally-ordered event sequence** per space
+  — the ordering authority §8.6 relies on — without a distributed transaction. Spaces are
+  independent, so this scales horizontally *across* spaces (the unit of partition is the space /
+  root entity, matching the tenant partition, I-13); it is a per-space serialization point, not
+  a global one.
+- **Git is the durable, addressable form; appends are commits** (or fast objects batched into
+  commits) under the lease — no concurrent-writer merge races because there is one writer at a
+  time per space.
+- **Read-your-writes** holds within a space because every reader resolves current state from
+  the same ordered log (or its fold); across spaces there is no shared state to be inconsistent.
+- **HA / failover:** the lease is time-bounded and re-grantable; a failed append-authority is
+  replaced and resumes from the log's head (the log is the recovery point). A partition that
+  splits the authority degrades that *space* to read-only until a single writer is re-elected —
+  it never forks the log (availability yields to log integrity; an explicit, stated trade).
+- **Open residual (→ §12, O-3-adjacent):** whether very high append rates need per-space log
+  *sharding* (sub-logs merged by a deterministic order) is an implementation spike, not an
+  architectural change.
+
 **History must stay recoverable *and* bounded (review C-3).** "Every write is a commit" + open
 L0 means an unbounded, bot-/vandalism-amplified journal that eventually degrades Git itself.
 Recoverability (I-10) is non-negotiable, so the answer is *compaction, not deletion*:
@@ -490,8 +563,10 @@ mechanism (not policy) that makes concurrent editing safe (review bug B-2).
 **The consistency guarantee — causal, anchored on the journal:**
 
 - **Read-your-writes for coordination-canonical state.** Once an overlay/binding/merge is
-  committed to the journal, this client always sees it (the journal is the client's own causal
-  spine). This is a *strong* local guarantee, cheap because the journal is local Git.
+  appended to the space's decision log, every reader of that space sees it — because the log is
+  a **single totally-ordered sequence per space** (one append authority, §8.1), and all readers
+  resolve current state from that one order. The guarantee holds across orchestrator instances,
+  not just within one process; it is cheap because ordering is per-space, never global.
 - **Causal consistency across the derived tier.** The union/index/projections reflect a causal
   cut of `(sharded inputs seen so far, journal)`. Effects never appear before their causes; a
   projection that has seen journal commit *C* has seen everything *C* depends on.
@@ -570,14 +645,37 @@ comparison across all pages of all shards is O(N²) and is forbidden. Instead:
    ≈O(N) candidates.
 2. **Verification** — candidate pairs are confirmed by full fingerprint / span-set overlap and
    any curator binding. Confirmed equivalences become union edges.
-3. **Incremental maintenance** — a changed page is re-bucketed and only its *new* candidate set
-   is re-verified; equivalence is maintained per-change, never recomputed globally.
+3. **Incremental maintenance — the delta is *not* additive (review B-4).** A changed page may
+   *leave* buckets as well as *enter* them, and leaving a bucket can **break an existing
+   equivalence edge** another page relied on. So a change is processed as: (i) recompute the
+   page's bucket membership; (ii) for buckets it **left**, re-verify the pairs that depended on
+   the shared bucket and **retract** edges no longer supported; (iii) for buckets it **entered**,
+   verify the new candidate pairs and **add** edges; (iv) **propagate** to the equivalence
+   neighbours of any retracted/added edge (equivalence is transitive-ish via chorus sets, so a
+   retraction can split a set). Maintenance is per-change and bounded by the page's
+   neighbourhood, but it covers retraction and propagation — not just additions.
 
 **The index is itself derived** (disposable, recomputable) and per-tenant-partitioned (§9).
 Its parameters (LSH band/row counts, shingle size, precision/recall) are tunable; the accepted
 **false-negative rate of blocking** is a known, tracked limitation (§12) — blocking trades a
 small miss rate for tractability, and curator bindings are the escape hatch for misses.
 
+**Verifying I-2 (`derived = f(canonical)`) — eventually, not on faith (review B-4).**
+Incremental maintenance can drift from a from-scratch fold over time (a missed retraction, a
+dropped event, a bug). I-2 is therefore an **eventually-verified** property, not a free one,
+and the architecture names the mechanism that verifies it:
+
+- **A digest of the derived tier.** Each partition's derived tier carries a rolling content
+  digest (a Merkle-style hash over union nodes/edges/index entries) maintained alongside the
+  incremental updates.
+- **A background consistency-checker** periodically recomputes the digest over a *sampled* (or,
+  on a slow cadence, full) fold of canonical state and compares. A mismatch localises the drift
+  to a partition/region and triggers a **scoped recompute** of just that region — cheap relative
+  to a global rebuild, and self-healing.
+- **So I-2 holds *eventually and verifiably*:** the incremental engine is the fast path, the
+  checker is the guarantee, and divergence is detected and repaired rather than silently
+  accumulating. The exact sampling rate / digest granularity is an implementation spike (§12).
+
 ### 8.8 Cache freshness & invalidation
 
 Replication-projection caches remote shard content; cache invalidation is the actual hard part
@@ -668,19 +766,30 @@ The configurable presets are:
   (constrained by the capability profile).
 - **Reconciliation cadence & conflict exposure** — push/poll/manual; show-conflicts vs
   auto-merge-when-supported.
+- **Conflict-resolution preset** — chorus / designated-canonical / git-merge / vote-to-merge /
+  overlay-only (the *resolution* policy over §8.6's core detection; per space or equivalence set).
+- **Freshness / invalidation mode** — event-driven / validator-poll / TTL / hybrid, and
+  stale-but-fast vs block-for-fresh on read (§8.8; constrained by the operational envelope).
+- **History compaction** — squash policy for low-value churn, gc/repack cadence, per-shard
+  offload (§8.1), always preserving recoverable endpoints.
+- **Tenant partition mapping** — tenant ↔ root-entity, and any explicit cross-root federation
+  (§9.1, I-13).
 - **Execution policy** — derive/execute off (default) / sandboxed / per-shard-allowed.
 - **Authorization mode** — the L0–L4 ladder.
 - **Projection materialization** — lazy/eager; snapshot vs view-time; recording retention.
 
-Core ships sane defaults (L0 open; fork+journal; lazy replication-projection; overlay-before-
-mutation; execution off) and never hard-codes any of the above.
+Core ships sane defaults (L0 open; fork+journal; lazy replication-projection; event-driven+TTL
+freshness; overlay-before-mutation; execution off; one tenant = one root) and never hard-codes
+any of the above. (**Preset bundles** that package coherent knob-sets per persona are tracked
+as O-8, §12 — flexibility without bundles is operator burden.)
 
 ---
 
 ## 11. Concrete module structure (bridge to implementation)
 
 A proposed package layout for `src/shard_wiki/`, mapping 1:1 to the layers so the dependency
-rule (downward only; L4 rebuildable) is enforceable by import lint:
+rule (downward only; the derived tier is incrementally maintained, rebuild = fallback) is
+enforceable by import lint:
 
 ```
 src/shard_wiki/
@@ -689,7 +798,9 @@ src/shard_wiki/
   adapters/       # L1 bottom waist: AdapterContract (versioned iface), CapabilityProfile,
                   #   attachment-mode binding; concrete adapters:
     git/  folder/  gitea/  obsidian/  webdav/  notion/  …   # each: profile + verbs
-  coordination/   # L3: GitJournal, OverlayEngine (draft→patch→MR), reconcile
+  coordination/   # L3: DecisionLog (append-only, git-backed, per-space append authority/
+                  #   lease), OverlayEngine (draft→patch→MR), reconcile
+                  #   (current coordination state = a derived fold → lives in union/)
   federation/     # L3: FederationModel strategies (fork_journal, vcs_ping,
                   #   graph_join, feed, activitypub, engine_mirror)
   union/          # L4 (derived): IdentityResolver, EquivalenceGraph, UnionGraph,
@@ -735,6 +846,11 @@ direction** and a **revisit trigger** — the thing that, if observed, forces a
 | O-5 | **Axis-interaction completeness** (§6.5) | the named interaction table is the contract; extend deliberately | a real adapter needing an interaction not in the table |
 | O-6 | **Span-address portability across projection** (§7.2) | shard-scoped native-id wrapping now; tumbler later | cross-shard transclusion that native ids can't satisfy |
 | O-7 | **Squash-compaction vs. perfect auditability** (§8.1) | compact the *path*, preserve reachable states; configurable | a compliance need for every intermediate keystroke |
+| O-8 | **Policy-knob proliferation → operator burden** (§10) | ship named **preset bundles** ("personal vault" / "team wiki" / "enterprise federation") over the policy surface | operators mis-configuring interacting knobs |
+| O-9 | **Shard sharing across roots vs tenant partition** (§9.1, I-13) | shard exclusive to one root by default; explicit shared-read binding otherwise (avoids double-caching a rate-limited shard) | a shard legitimately needed live in two tenants |
+| O-10 | **Span-level authz under transclusion** (aggregation/inference leak; ⊕ across boundaries, §7.3/§9) | a transcluded span inherits the **stricter** of source & host authz; provenance ⊕ composes the source-page envelope under the host | a real cross-authz transclusion |
+| O-11 | **Union under shard unavailability** (§8.8 covers stale, not down) | **partial union** + per-shard "unavailable" provenance + last-known-projection where policy allows | an SLA need on partial reads |
+| O-12 | **Per-space append-log throughput ceiling** (§8.1 append authority) | single writer per space scales across spaces; per-space log sharding if needed | a single space exceeding one writer's append rate |
 
 These are the spec-writing inputs for `SHARD-WP-0002`; none blocks the architecture, each
 scopes an implementation spike.
@@ -775,6 +891,14 @@ Decided:
   (§6.5). (Decided.)
 - **Three states; derived = f(canonical)** — sharded + coordination canonical, derived
   disposable (§1). (Decided; supersedes the earlier "edges vs middle" framing.)
+- **Event-sourced coordination, one append authority per space** — coordination-canonical state
+  is an append-only **decision log** in the git journal; current state is a derived fold; a
+  per-space append lease gives a totally-ordered log and read-your-writes across orchestrator
+  instances (§8.1). (Decided — resolves the single-vs-multi-writer keystone.)
+- **Profiles are verified, not asserted** — a versioned **conformance suite** gates adapter
+  admission; capability-as-data acts on verified data (§6.6). (Decided.)
+- **I-2 is eventually-verified** — incremental maintenance is the fast path; a digest +
+  background consistency-checker detects and self-heals drift (§8.7). (Decided.)
 - **Incremental-first, rebuild-as-fallback** — the derived tier is continuously maintained from
   change events; full rebuild is rare and need not be cheap (§8.7). (Decided — resolves the
   earlier "union graph persistence" open item: **persisted, per-tenant, incrementally
@@ -818,6 +942,11 @@ Still open (carried to §12 / policy):
   B-3→§9.1+I-13 (tenant isolation), C-1/C-2→§8.7/§8.8 (incremental + indexed + invalidation),
   C-3→§8.1 (history scaling), D-1→§6.5 (orthogonal core), D-2→§7.3 (layered provenance),
   D-3→§8.4 (common-case projection), D-4→§11 (policy module + rail discipline); open items→§12.
+- **Round-2 review & hardening II** — folds in
+  `history/260615-core-architecture-blueprint-review-2.md` via **`SHARD-WP-0006`**:
+  A-1…A-4→§3/§4/§10/§11 (overview reconciled to the body), B-1+B-3→§8.1 (event-sourced
+  coordination + per-space append authority), B-2→§6.6 (adapter conformance suite),
+  B-4→§8.7 (incremental retraction/propagation + I-2 digest/checker); C-1…C-4→§12 (O-8…O-11).
 - **Research** — §6 (spectra) ← `260614-shard-spectrum-synthesis` v3; §8.3 (federation
   taxonomy) ← v3 §2.5; §8.4–§8.5 (two-axis projection, view registry, computational scope) ←
   `260614-computational-page-model-synthesis`; §7 page shapes ← the engine + modern-tool +

workplans/SHARD-WP-0006-architecture-hardening-2.md

@@ -4,13 +4,14 @@ type: workplan
 title: "core architecture hardening II (round-2 review fixes)"
 domain: whynot
 repo: shard-wiki
-status: active
+status: done
 owner: tegwick
 topic_slug: whynot
 created: "2026-06-15"
 updated: "2026-06-15"
 depends_on:
   - SHARD-WP-0005
+state_hub_workstream_id: "badb83f8-2806-4018-9d7f-d4666d3510ba"
 ---
 
 # SHARD-WP-0006 — Core architecture hardening II
@@ -42,8 +43,9 @@ where mutable coordination state actually lives*.
 
 ```task
 id: SHARD-WP-0006-T1
-status: todo
+status: done
 priority: high
+state_hub_task_id: "b0b4087b-ec19-4ae7-94b1-9a813a6133b9"
 ```
 
 Make the overview match the hardened body (review A-1…A-4):
@@ -64,8 +66,9 @@ Make the overview match the hardened body (review A-1…A-4):
 
 ```task
 id: SHARD-WP-0006-T2
-status: todo
+status: done
 priority: high
+state_hub_task_id: "fd17f7b9-ca9e-4c86-95c0-9b51cb2df7b5"
 ```
 
 Settle the keystone (review B-1 + B-3 together). Decide and document:
@@ -91,8 +94,9 @@ Settle the keystone (review B-1 + B-3 together). Decide and document:
 
 ```task
 id: SHARD-WP-0006-T3
-status: todo
+status: done
 priority: high
+state_hub_task_id: "900c8234-ca73-4225-b2c5-77d218ded28c"
 ```
 
 Fix B-2. Make capability-as-data trustworthy: add to the adapter contract (§6) a
@@ -109,8 +113,9 @@ add the conformance obligation to the acceptance posture.
 
 ```task
 id: SHARD-WP-0006-T4
-status: todo
+status: done
 priority: medium
+state_hub_task_id: "adf4ed28-8338-49ed-a552-c9fbe11c43ee"
 ```
 
 Fix B-4. In §8.7: correct the incremental equivalence algorithm — a changed page must
@@ -127,8 +132,9 @@ not merely asserted; on mismatch, recompute the affected partition. State that I
 
 ```task
 id: SHARD-WP-0006-T5
-status: todo
+status: done
 priority: medium
+state_hub_task_id: "18cb718a-e507-41d0-ae14-b144a56e3d57"
 ```
 
 Add review §C as open problems in §12 (each with chosen direction + revisit trigger):