Close REUSE-WP-0020: evidence-binder live, 64 capabilities federated

evidence-binder published their repaired index at e462775 and correctly held
the re-enable request until it was visible on Forgejo. Pre-checked this time
before touching production: backing entries return 200, and a local compose of
all 61 sources gave 64 capabilities with zero warnings and no duplicate IDs.

Public endpoint now serves 61 sources / 64 capabilities, with both
capability.evidence.binding and capability.evidence.rect-registry at
D3 / A2 / C3 / R3.

Open T09 for the gap this exposed: enabling a source does not invalidate the
composed index. The endpoint kept serving a stale compose, reporting
stale: false throughout, until POST /v1/federated/compose was called by hand.
A repo can be correctly registered and silently invisible.

SCOPE.md: refresh the federated counts, record the deployed image, and correct
the multi-domain claim — member rows have begun carrying their own domain
(evidence-binder publishes domain: infotech) even though the manifest is still
composed under helix_forge.

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

SCOPE.md

@@ -217,7 +217,9 @@ index, CLI automation, and the production hub.
 
 ## What Is Not Possible Yet
 
-- **Multi-domain federation** — all indexed capabilities remain `helix_forge`
+- **Multi-domain federation** — the federated index is still composed under a
+  single `helix_forge` manifest domain, though member rows have begun carrying
+  their own (`evidence-binder` publishes `domain: infotech`)
 - **Planning analytics breadth** — `report gaps` shipped (REUSE-WP-0015-T03);
   no roadmap views or standardization tracker beyond `overlaps` and compose
   collision warnings
@@ -239,14 +241,16 @@ See `tools/README.md` for command reference.
   hub-registered (inter-hub registration disabled on hub), **62/62**
   publish-check pass, **62/62** capability coverage (`has` or explicit `none`).
 - **Federation:** `registry/federation/sources.yaml` — **61** enabled sources;
-  `registry/indexes/federated.yaml` — **61** composed capability rows
+  `registry/indexes/federated.yaml` — **64** composed capability rows
   (inter-hub excluded; core-hub included; 0 duplicate-ID warnings at last compose).
 - **CLI / service:** `reuse_surface/` — validate, query, export, overlaps,
   catalog, federation, graph, hub client, establish/update/stats, `serve`
   (FastAPI hub).
 - **Production hub:** `https://reuse.coulomb.social` — **61** enabled repo
-  registrations; `GET /v1/federated` serves **61** capabilities from published
-  raw URLs (compose refreshed 2026-07-07).
+  registrations; `GET /v1/federated` serves **64** capabilities from published
+  raw URLs (compose refreshed 2026-08-21). Runs image
+  `forgejo.coulomb.social/coulomb/reuse-surface:main-b035664` (Helm revision 8);
+  `/health`, `/v1/repos`, `/v1/federated`, and `/v1/reuse-events` all answer.
 - **Specs:** `specs/FederationHubAPI.md`, `schemas/hub-registration.schema.yaml`.
 - **Docs:** `docs/CapabilityRegistryConcept.md`, `docs/RegistryFederation.md`,
   `docs/IntentScopeGapAnalysis.md`, deploy guide `docs/deploy/reuse-kubernetes.md`.

WORK-RECORDS.md

@@ -75,6 +75,6 @@
 | task | REUSE-WP-0020-T03 | wait | — | workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md |
 | task | REUSE-WP-0020-T04 | wait | — | workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md |
 | task | REUSE-WP-0020-T05 | done | — | workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md |
-| task | REUSE-WP-0020-T06 | todo | — | workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md |
+| task | REUSE-WP-0020-T06 | done | — | workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md |
 | task | REUSE-WP-0020-T07 | done | — | workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md |
 | task | REUSE-WP-0020-T08 | done | — | workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md |

workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md

@@ -4,11 +4,11 @@ type: workplan
 title: "CoulombCore retirement cutover: federation sources, image, and compose resilience"
 domain: infotech
 repo: reuse-surface
-status: active
+status: finished
 owner: claude
 topic_slug: helix-forge
 created: "2026-08-20"
-updated: "2026-08-20"
+updated: "2026-08-21"
 ---
 
 # CoulombCore retirement cutover
@@ -119,7 +119,7 @@ raising.
 
 ```task
 id: REUSE-WP-0020-T03
-status: wait
+status: done
 priority: medium
 ```
 
@@ -149,13 +149,27 @@ Suggested ids: `capability.evidence.binding`,
 
 ```task
 id: REUSE-WP-0020-T04
-status: wait
+status: done
 priority: medium
 ```
 
-Blocked on T02 and T03. `evidence-binder` was set `--no-enabled` on the
-production hub to restore service. Once its index is valid and compose is
-hardened, re-enable and confirm `/v1/federated` returns 61 sources.
+**Done 2026-08-21.** `evidence-binder` fixed and published their index at
+`e462775` (their EBIND-WP-0002), correctly holding the re-enable request until
+the Forgejo index was actually visible.
+
+Pre-checks first this time, given T01's outcome: both backing entry files
+return `200`, and a local compose of all 61 sources produced 64 capabilities
+with **zero warnings and no duplicate IDs**. Only then was the source enabled.
+
+Confirmed on the public endpoint — 61 sources, **64 capabilities**,
+`composed_at 2026-08-21T08:45:24Z`, `evidence-binder` source count 2, both
+`capability.evidence.binding` and `capability.evidence.rect-registry` at
+`D3 / A2 / C3 / R3`.
+
+**Re-enabling alone was not enough**, and this is the finding worth keeping:
+after `hub update --enabled`, the endpoint still served a cached compose —
+62 capabilities, `composed_at` from before the change. It took an explicit
+`POST /v1/federated/compose` to pick the source up. See T09.
 
 ## Repoint The Production Deployment To A Forgejo Image
 
@@ -353,6 +367,35 @@ T05 calls for verifying the image workflow is green.
 **Done 2026-08-20.** Replaced the literals with a `_recent_date()` helper
 derived from `STALE_DAYS`. Full suite: 179 passed.
 
+## Invalidate The Composed Index When A Registration Changes
+
+```task
+id: REUSE-WP-0020-T09
+status: todo
+priority: medium
+```
+
+Found closing T04. Enabling a federation source on the hub does **not**
+invalidate the composed index. After `hub update --repo evidence-binder
+--enabled`, `GET /v1/federated` kept serving the previous compose — 62
+capabilities, stale `composed_at` — until `POST /v1/federated/compose` was
+called by hand.
+
+The consequence is quiet and bad: **a repo can be correctly registered and
+still be invisible for as long as the cache holds**, with nothing in the
+response indicating anything is pending. `stale: false` was reported
+throughout. The webhook path (REUSE-WP-0019-T02) covers *content* changes in a
+member's `registry/indexes/`, but nothing covers a *registration* change made
+through the hub's own API.
+
+Fix: have the write paths on `/v1/repos` (create, and update where `enabled`,
+`url`, or `required` change) mark the composed index dirty, so the next
+`GET /v1/federated` recomposes — or at minimum report `stale: true` so a caller
+can tell the served view no longer matches the registrations behind it.
+
+Add a hub test: register or enable a source, then `GET /v1/federated` without
+`refresh`, and assert the new source's capabilities are present.
+
 ---
 
 ## Verification