Refresh canonical CommerceCanon federation source and registration evidence

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b

workplans/REUSE-WP-0021-commerce-canon-source-rename.md

@@ -4,12 +4,12 @@ type: workplan
 title: "Follow the CommerceCanon repository rename in federation sources"
 domain: infotech
 repo: reuse-surface
-status: ready
+status: active
 owner: codex
 origin: residual
 origin_ref: IDENTITY-WP-0004
 created: "2026-09-05"
-updated: "2026-09-05"
+updated: "2026-09-06"
 state_hub_workstream_id: "0d1beafd-e638-5bb9-b91d-13543ac42a04"
 ---
 
@@ -24,7 +24,7 @@ repository's source/refresh evidence.
 
 ```task
 id: REUSE-WP-0021-T01
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "b7803b7d-0b70-5aac-8f6a-2704794fccf2"
 ```
@@ -47,7 +47,7 @@ service, or capability-semantic migration is authorized by this task.
 
 ```task
 id: REUSE-WP-0021-T02
-status: todo
+status: wait
 priority: low
 state_hub_task_id: "ceba0cd4-3992-5f16-bdd2-1f054055d10b"
 ```
@@ -59,3 +59,32 @@ closed DB records); binding upload returned 422. Reconcile these through the
 supported identifier/projection tooling, preserving work-record identity and
 history, then rerun the audit. This is an index-repair follow-up, not a failure
 of the completed commerce-canon Forge/State Hub rename.
+
+## Source refresh result — 2026-09-06
+
+T01 passes: source manifest and roster use commerce-canon; the federation
+composer refreshed that source with no warnings. Both capability.identity ids
+and vectors are unchanged; 60 unrelated local index rows are preserved.
+The live reuse service has an enabled commerce-canon registration and retains
+the old registration disabled with a replacement note. Its fresh composed index
+serves both ids from canonical URLs and cache paths, with no target warnings.
+Existing federation tests: 15 passed. CFED-WP-0001-T09 owns consolidated evidence.
+
+## Binding repair limitation — 2026-09-06
+
+T02 remains live and waiting for supported legacy-binding restoration. Null
+frontmatter fields were deliberately cleared in commit 8b04f91. Current primary
+workplans remain finished under existing UUIDs:
+
+- REUSE-WP-0017: a2d83504-fcd0-4561-8688-b77a01cb7f06
+- REUSE-WP-0018: cd8683ff-6e6c-4f6c-a62f-565bd55113ea
+- REUSE-WP-0019: 569be717-34f8-4039-bb26-497685f60159
+
+Repo Manager ensure_missing_work_record_identifiers(execute=False) rejects the
+blank scalar (expected None, found empty string); moreover its deterministic
+UUIDs differ from all three existing identities. Ordinary assignment is not a
+restoration mechanism. State Hub stringifies null as None and classifies it as
+a stale UUID. Do not manually substitute identifiers or run a derived-identity
+migration to quiet this audit. T02 must use a reviewed restoration tool that
+verifies existing primary records and historical source provenance. These
+archived binding defects do not invalidate the source-coordinate refresh.