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

id	type	title	domain	repo	status	owner	origin	origin_ref	created	updated	state_hub_workstream_id
REUSE-WP-0021	workplan	Follow the CommerceCanon repository rename in federation sources	infotech	reuse-surface	active	codex	residual	IDENTITY-WP-0004	2026-09-05	2026-09-06	0d1beafd-e638-5bb9-b91d-13543ac42a04

CommerceCanon source-coordinate handoff

identity-canon was renamed to commerce-canon under CFED-WP-0001-T03 and IDENTITY-WP-0004. Forge repository ID 46 is unchanged, and the old URL is a redirect. Project task CFED-WP-0001-T09 owns fleet acceptance and consumes this repository's source/refresh evidence.

Update source coordinates and verify federation

id: REUSE-WP-0021-T01
status: done
priority: medium
state_hub_task_id: "b7803b7d-0b70-5aac-8f6a-2704794fccf2"

Update registry/federation/sources.yaml and local-repo-roster.yaml to the canonical commerce-canon URL/path. Refresh the affected source cache and registry/indexes/federated.yaml through the repository's federation tooling. Preserve capability.identity.subject-resolution and capability.identity.vocabulary-canonicalize identifiers; a repository rename alone does not redefine capabilities. Source owner/URL/cache metadata should match the newly published commerce-canon registry.

Verify both capability entries remain discoverable with canonical source links, record command/results and commit, and hand evidence back to CFED-WP-0001-T09. Leave historical workplan/completion provenance intact. No credential, runtime service, or capability-semantic migration is authorized by this task.

Repair archived workplan bindings reported during handoff registration

id: REUSE-WP-0021-T02
status: wait
priority: low
state_hub_task_id: "ceba0cd4-3992-5f16-bdd2-1f054055d10b"

The 2026-09-05 handoff registration created this workplan and T01 successfully, but the full consistency audit reported pre-existing invalid None bindings in archived REUSE-WP-0017, REUSE-WP-0018 and REUSE-WP-0019 (C-03, plus C-08 on their 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.