From c7002cfcea7a20573665be45192fa3d918f092ee Mon Sep 17 00:00:00 2001
From: tegwick <bernd.worsch@gmail.com>
Date: Sat, 5 Sep 2026 19:59:11 +0200
Subject: [PATCH] Complete CommerceCanon rename and declare concept ownership
 boundary

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b
---
 .claude/rules/credential-routing.md           |   2 +-
 .claude/rules/first-session.md                |  26 +--
 .claude/rules/repo-boundary.md                |   2 +-
 .claude/rules/repo-identity.md                |   6 +-
 .claude/rules/session-protocol.md             |  38 ++--
 .claude/rules/workplan-convention.md          |  53 +++--
 .gitignore                                    |   6 +
 .repo-classification.yaml                     |  17 +-
 AGENTS.md                                     |  73 ++++---
 CLAUDE.md                                     |   2 +-
 INTENT.md                                     | 181 ++----------------
 README.md                                     |  22 ++-
 SCOPE.md                                      |  70 +++----
 .../2026-09-05-commerce-rename-preparation.md |  24 +++
 .../capability.identity.subject-resolution.md |  18 +-
 ...bility.identity.vocabulary-canonicalize.md |  22 +--
 registry/indexes/capabilities.yaml            |   4 +-
 workplans/IDENTITY-WP-0004-commerce-rename.md |  37 +++-
 18 files changed, 279 insertions(+), 324 deletions(-)
 create mode 100644 history/2026-09-05-commerce-rename-preparation.md

diff --git a/.claude/rules/credential-routing.md b/.claude/rules/credential-routing.md
index c0458cd..8d8bcb0 100644
--- a/.claude/rules/credential-routing.md
+++ b/.claude/rules/credential-routing.md
@@ -19,7 +19,7 @@ Requires the `warden` CLI from `~/ops-warden` (`uv tool install .` or `uv run wa
 
 | Agent runtime | How to orient |
 | --- | --- |
-| **Codex / Grok** (shell, HTTP State Hub) | `warden route` commands above; inbox `to_agent=identity-canon` is for coordination, not secret vending |
+| **Codex / Grok** (shell, HTTP State Hub) | `warden route` commands above; inbox `to_agent=commerce-canon` is for coordination, not secret vending |
 | **Claude Code** (MCP when available) | `get_domain_summary("custodian")` for workplans; **still** use `warden route` for credential ownership |
 | **llm-connect** (inference service) | Never put secret retrieval in prompts; route custody to OpenBao/operator paths surfaced by `warden route` |
 
diff --git a/.claude/rules/first-session.md b/.claude/rules/first-session.md
index 81c86a8..68b4152 100644
--- a/.claude/rules/first-session.md
+++ b/.claude/rules/first-session.md
@@ -1,11 +1,11 @@
 ## First Session Protocol
 
-Triggered when `get_domain_summary("infotech")` shows **no workplans**.
+Triggered when `get_domain_summary("financials")` shows **no workplans**.
 The project is registered but work has not yet been structured.
 
 **Step 1 — Read, don't write**
-- `~/the-custodian/canon/projects/infotech/project_charter_v0.1.md` — purpose, scope
-- `~/the-custodian/canon/projects/infotech/roadmap_v0.1.md` — planned phases
+- `~/the-custodian/canon/projects/financials/project_charter_v0.1.md` — purpose, scope
+- `~/the-custodian/canon/projects/financials/roadmap_v0.1.md` — planned phases
 - Scan repo root: README, directory structure, existing code or docs
 
 **Step 2 — Survey in-progress work**
@@ -15,24 +15,24 @@ Look for TODOs, open branches, half-finished files. Note done vs. started but in
 Propose 1–3 workplans — each a coherent strand, weeks to months, anchored to a
 roadmap phase. **Wait for approval before creating.**
 
-**Step 4 — Write the workplan file; fix-consistency registers it (ADR-001)**
+**Step 4 — Write the workplan file; Repo Manager projects it (ADR-001)**
 ```
-workplans/IDENTITY-WP-NNNN-<slug>.md   ← write this, commit it
+workplans/COMMERCE-WP-NNNN-<slug>.md   ← write this, commit it
 ```
-Then register by running the consistency check — do **not** call
-`create_workplan`/`create_task` yourself; manual registration duplicates what
-C-06 creates from the file:
+Then run the deterministic, forge-derived sync — do **not** call
+`create_workplan`/`create_task` yourself:
 ```bash
-statehub fix-consistency --repo identity-canon
+uv run --project ~/repo-manager rmgr sync --path . --push
 ```
-C-06 creates the hub workplan + tasks and writes `state_hub_workstream_id`
-(legacy frontmatter name — holds the workplan UUID) and `state_hub_task_id`
-back into the file.
+Repo Manager writes deterministic `state_hub_workstream_id` and
+`state_hub_task_id` values, pushes the file, verifies `primary/railliance01`,
+and asks central to derive that exact Forgejo commit. If connectivity is down,
+the queued receipt is pending evidence; rerun the same command later.
 
 **Step 5 — Record the setup**
 ```
 add_progress_event(
-    summary="First session: structured infotech into N workplans, M tasks",
+    summary="First session: structured financials into N workplans, M tasks",
     event_type="milestone",
     topic_id="fe2aaa78-9c20-4feb-b3d2-4fe0529572a3",
     detail={"workplans": [...], "tasks_created": M}
diff --git a/.claude/rules/repo-boundary.md b/.claude/rules/repo-boundary.md
index 172e45f..ecb6988 100644
--- a/.claude/rules/repo-boundary.md
+++ b/.claude/rules/repo-boundary.md
@@ -1,6 +1,6 @@
 ## Repo boundary
 
-This repo owns **identity-canon** only. It does not own:
+This repo owns **commerce-canon** only. It does not own:
 
 <!-- TODO: List what belongs in adjacent repos, e.g.:
 - SSH key management → railiance-infra/
diff --git a/.claude/rules/repo-identity.md b/.claude/rules/repo-identity.md
index e04bb9e..daf464a 100644
--- a/.claude/rules/repo-identity.md
+++ b/.claude/rules/repo-identity.md
@@ -1,5 +1,5 @@
-**Purpose:** Othogonal vocabulary and canonical model for identity related concepts.
+**Purpose:** Counterparty and commercial-relationship semantics, importing shared concepts from InfoTechCanon.
 
-**Domain:** infotech
-**Repo slug:** identity-canon
+**Domain:** financials
+**Repo slug:** commerce-canon
 **Topic ID:** fe2aaa78-9c20-4feb-b3d2-4fe0529572a3
diff --git a/.claude/rules/session-protocol.md b/.claude/rules/session-protocol.md
index e7b757b..f60e1c2 100644
--- a/.claude/rules/session-protocol.md
+++ b/.claude/rules/session-protocol.md
@@ -11,7 +11,7 @@ cat .custodian-brief.md
 ```
 Then call the MCP tool for richer cross-domain context when MCP tools are exposed:
 ```
-get_domain_summary("infotech")
+get_domain_summary("financials")
 ```
 If MCP tools are unavailable in the current agent session, use the REST API:
 ```bash
@@ -22,14 +22,14 @@ If the hub is offline: `cd ~/state-hub && make api`
 **Step 2 — Check inbox**
 With MCP tools:
 ```
-get_messages(to_agent="identity-canon", unread_only=True)
+get_messages(to_agent="commerce-canon", unread_only=True)
 ```
 Mark read with `mark_message_read(message_id)`. Reply or act on coordination
 requests before proceeding.
 
 Without MCP tools:
 ```bash
-curl -s "http://127.0.0.1:8000/messages/?to_agent=identity-canon&unread_only=true" \
+curl -s "http://127.0.0.1:8000/messages/?to_agent=commerce-canon&unread_only=true" \
   | python3 -m json.tool
 curl -s -X PATCH "http://127.0.0.1:8000/messages/<id>/read" \
   -H "Content-Type: application/json" -d '{}'
@@ -44,8 +44,8 @@ For each file with `status: ready`, `active`, or `blocked`, note pending
 
 **Step 4 — Present brief**
 
-1. **Active workplans** for `infotech` — title, task counts, blocking decisions
-2. **Pending tasks** from `workplans/` + any `[repo:identity-canon]` hub tasks
+1. **Active workplans** for `financials` — title, task counts, blocking decisions
+2. **Pending tasks** from `workplans/` + any `[repo:commerce-canon]` hub tasks
 3. **Goal guidance** — if `goal_guidance` in summary:
    - `needs_workplan`: surface as top action — *"Repo goal '{title}' has no workplan yet"*
    - `alignment_warnings`: flag if active work is not aligned with current goal
@@ -58,14 +58,24 @@ If no workplans: follow First Session Protocol (`first-session.md`).
 
 > State Hub is a *read model*. **Never register workplans or tasks by hand**
 > (`create_workplan`, `create_task`) — write the workplan file in `workplans/`
-> and run `fix-consistency`; C-06 registers the workplan and tasks and writes
-> IDs back into the file. Manual registration creates duplicates when
-> fix-consistency runs. Work structure belongs in repo files (ADR-001).
+> and run `uv run --project ~/repo-manager rmgr sync --path . --push`.
+> Repo Manager assigns missing deterministic IDs; central derives the exact
+> pushed Forgejo commit. Manual registration creates duplicate ownership.
+> Work structure belongs in repo files (ADR-001).
 >
 > Legacy: `create_workstream` and `/workstreams/` remain as metered aliases —
 > see `workplan-convention.md` (compatibility footnote).
 
 **Session close:**
+1. Update workplan/task statuses in repo files.
+2. If marking a workplan **finished**: hand off residuals as **live work
+   records** first (intake with `origin: residual` + `origin_ref: <WP-id>`, or
+   a child workplan / decision / engagement). Do not leave actionable leftovers
+   only as prose or in `SCOPE.md`. See work-record-types § Residuals.
+3. Log progress (below).
+4. `uv run --project ~/repo-manager rmgr sync --path . --push` when workplan
+   files changed. Use `statehub fix-consistency` separately for a deep audit.
+
 With MCP tools:
 ```
 add_progress_event(summary="...", topic_id="fe2aaa78-9c20-4feb-b3d2-4fe0529572a3", workplan_id="<uuid>")
@@ -80,13 +90,7 @@ If workplan files were modified, ensure the local copy is up to date first,
 then sync from the repo checkout:
 ```bash
 git pull --ff-only
-statehub fix-consistency
+uv run --project ~/repo-manager rmgr sync --path . --push
 ```
-For repos where implementation runs on a remote machine (e.g. CoulombCore),
-use the pull-before-fix mode from any shell with the State Hub CLI:
-```bash
-statehub fix-consistency --repo identity-canon --remote
-```
-**C-15** (DB task ahead of file) is normal in multi-machine workflows — writeback
-will sync the file to match DB.  **C-16** (repo behind remote) blocks all writes
-until you pull — intentional to prevent clobbering remote progress.
+The sync refuses uncommitted workplan files and a branch behind its upstream.
+This prevents a workstation projection from getting ahead of the forge source.
diff --git a/.claude/rules/workplan-convention.md b/.claude/rules/workplan-convention.md
index 8cc558e..127babc 100644
--- a/.claude/rules/workplan-convention.md
+++ b/.claude/rules/workplan-convention.md
@@ -1,7 +1,7 @@
 ## Workplan Convention (ADR-001)
 
-File location: `workplans/IDENTITY-WP-NNNN-<slug>.md`
-ID prefix: `IDENTITY-WP-`
+File location: `workplans/COMMERCE-WP-NNNN-<slug>.md`
+ID prefix: `COMMERCE-WP-`
 
 Work items originate as files in this repo **before** being registered in the hub.
 
@@ -12,24 +12,35 @@ repo state, and `finished` when implementation is complete. `stalled` and
 `needs_review` are derived health labels, not stored statuses.
 
 Closed workplans may be moved to `workplans/archived/` with a completion-date
-prefix: `YYMMDD-IDENTITY-WP-NNNN-<slug>.md`. The frontmatter id remains
+prefix: `YYMMDD-COMMERCE-WP-NNNN-<slug>.md`. The frontmatter id remains
 unchanged; the prefix is only for quick visual reference.
 
 Small opportunistic tasks discovered during another session use **Ad Hoc Tasks**:
-`workplans/ADHOC-YYYY-MM-DD.md`, workplan slug `adhoc-YYYY-MM-DD`, and task ids
-`ADHOC-YYYY-MM-DD-T01`, `T02`, etc. Use adhocs only for low-risk work completed
-directly. Promote anything requiring analysis, design, approval, dependencies, or
-multiple planned phases into a normal workplan.
+`workplans/ADHOC-YYYY-MM-DD.md`, workplan id
+`COMMERCE-WP-ADHOC-YYYY-MM-DD`, and task ids
+`COMMERCE-WP-ADHOC-YYYY-MM-DD-T01`, `T02`, etc. `IDENTITY-WP` includes its final
+`-WP` token. Unqualified historic `ADHOC-*` ids are grandfathered and must not
+be copied into new records. Use adhocs only for low-risk work completed directly.
+Promote anything requiring analysis, design, approval, dependencies, or multiple
+planned phases into a normal workplan.
 
-Ecosystem todos from other agents arrive as `[repo:identity-canon]` hub tasks —
-visible at session start. Pick one up by creating the workplan file, committing,
-and running `statehub fix-consistency` — C-06 registers the workplan in the hub.
-Never register by hand with `create_workplan` (legacy MCP alias: `create_workstream`).
+Ecosystem todos from other agents arrive as `[repo:commerce-canon]` hub tasks —
+visible at session start. Pick one up by creating the workplan file, then run
+the fast authoritative projection path:
+
+```bash
+uv run --project ~/repo-manager rmgr sync --path . --push
+```
+
+Repo Manager assigns only missing deterministic identifiers. Central reads the
+exact pushed Forgejo commit and updates its replaceable projection. Never
+register by hand with `create_workplan` or `create_task`. Use
+`statehub fix-consistency` separately for a deep audit.
 
 Task blocks use this shape:
 
 ```task
-id: IDENTITY-WP-NNNN-T01
+id: COMMERCE-WP-NNNN-T01
 status: wait | todo | progress | done | cancel
 priority: high | medium | low
 state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit
@@ -38,6 +49,22 @@ state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit
 Status progression is `todo` → `progress` → `done`; use `wait` for waiting or
 blocked work and `cancel` for stopped work.
 
+### Residuals (role, not kind)
+
+When finishing a workplan, **actionable leftovers must become live work
+records** before `status: finished`. Residual is not a registered kind and
+must not be parked only in `SCOPE.md` or finished-file prose.
+
+| Shape | Capture as | Links |
+| --- | --- | --- |
+| Small Green/Blue parkable | intake (queue YAML / `*-IN-*`) | `origin: residual`, `origin_ref: COMMERCE-WP-NNNN` |
+| Multi-step | next workplan | name parent WP; optional promote from residual intake |
+| Founder gate / time | decision / engagement | same origin fields when from residual intake |
+
+Fleet listing of residuals is a State Hub concern (`list_intakes` + origin
+filters; planned `statehub residuals`). Canon:
+`the-custodian/canon/standards/work-record-types_v0.1.md` § Residuals.
+
 Workplan frontmatter carries `state_hub_workstream_id` — a legacy field name
 kept for compatibility; it holds the hub workplan UUID and is written by
 fix-consistency. Do not edit or rename it.
@@ -46,7 +73,7 @@ fix-consistency. Do not edit or rename it.
 
 **Workplan** is the fleet term — see
 `the-custodian/canon/standards/workplan-terminology-fleet_v0.1.md`.
-**Workplan** is legacy only: some API routes (`/workstreams/`), params
+**Workstream** is legacy only: some API routes (`/workstreams/`), params
 (`workstream_id`), MCP aliases (`create_workstream`), and the frontmatter field
 above remain until `STATE-WP-0069` retires them via legacy-meter. Treat those
 identifiers as workplan IDs. Prefer `GET /workplans/` and `workplan_id` in new
diff --git a/.gitignore b/.gitignore
index 36b13f1..71ee8eb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -174,3 +174,9 @@ cython_debug/
 # PyPI configuration file
 .pypirc
 
+
+# state-hub: track .claude/rules
+# Claude Code local state (track shared rules; ignore machine-specific files)
+.claude/*
+!.claude/rules/
+!.claude/rules/*.md
diff --git a/.repo-classification.yaml b/.repo-classification.yaml
index 6e71aa7..45f3df4 100644
--- a/.repo-classification.yaml
+++ b/.repo-classification.yaml
@@ -1,17 +1,16 @@
 repo_classification:
   standard: Repo Classification Standard
   version: '1.0'
-  classified_at: '2026-06-22'
-  classified_by: human
+  classified_at: '2026-09-05'
+  classified_by: codex
   category: research
-  domain: infotech
+  domain: financials
   secondary_domains:
   - government
+  - infotech
   capability_tags:
-  - identity
-  - access-control
-  - terminology
   - canon
+  - terminology
   - governance
   business_stake:
   - technology
@@ -22,4 +21,8 @@ repo_classification:
   - intention
   - control
   - adaptation
-  notes: Identity canon; standard §13.3 — human confirmed.
+  notes: >-
+    CommerceCanon continues identity-canon history under CUST-ADR-006 accepted
+    2026-08-17 and CFED-WP-0001-T03. Financials is primary for counterparty and
+    commercial semantics; government and infotech capture its regulatory and
+    imported technical boundaries. Research category is retained during migration.
diff --git a/AGENTS.md b/AGENTS.md
index 9804538..0413887 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -1,25 +1,27 @@
-# identity-canon — Agent Instructions
+# commerce-canon — Agent Instructions
 
 ## Repo Identity
 
-**Purpose:** Othogonal vocabulary and canonical model for identity related concepts.
+**Purpose:** Counterparty and commercial-relationship semantics, importing shared concepts from InfoTechCanon.
 
-**Domain:** infotech
-**Repo slug:** identity-canon
+**Domain:** financials
+**Repo slug:** commerce-canon
 **Topic ID:** `fe2aaa78-9c20-4feb-b3d2-4fe0529572a3`
-**Workplan prefix:** `IDENTITY-WP-`
+**Workplan prefix:** `COMMERCE-WP-`
 
 ---
 
 ## State Hub Integration
 
-The Custodian State Hub tracks work across all domains. Interact via HTTP REST —
-there is no MCP server for Codex agents.
+The Custodian State Hub tracks work across all domains. Codex uses HTTP REST and
+the `statehub` CLI by default. MCP is opt-in because the current Codex MCP bridge
+adds severe call latency; the full administrative MCP surface remains available
+to clients that need it.
 
 | Context | URL |
 |---------|-----|
 | Local workstation | `http://127.0.0.1:8000` |
-| Remote (railiance01, in-cluster) | `http://10.43.68.154:8000` |
+| Remote via tunnel | `http://127.0.0.1:18000` |
 | Optional local edge relay | http://127.0.0.1:18080 |
 
 When an operator has enabled the edge relay, set API_BASE to the relay URL.
@@ -27,6 +29,19 @@ Queueable writes return an explicit queued receipt if the central hub is
 unreachable. Treat that as pending local evidence, then ask the operator to run
 statehub outbox status/replay after connectivity returns.
 
+Codex workspace-write sandboxes need network access enabled to reach the host's
+loopback listener. Bootstrap this once with `make -C ~/state-hub configure-codex`
+and restart Codex. The canonical REST health endpoint is `/state/health`, not
+`/health`. If a sandboxed loopback probe fails, retry it with escalated execution
+before declaring State Hub unavailable; a managed Codex permission profile may
+still enforce isolated networking. Experimental MCP can be enabled explicitly
+with `make -C ~/state-hub configure-codex WITH_MCP=1`.
+
+Repository files cross machine boundaries through committed Forge revisions:
+workstation agents push to Forgejo and cluster infrastructure reads a verified
+commit into ephemeral storage. Neither side reads or writes the other's
+checkout. `local_path` and `host_paths` describe host-local observations only.
+
 ### Orient at session start
 
 ```bash
@@ -38,7 +53,7 @@ curl -s "http://127.0.0.1:8000/workplans/?topic_id=fe2aaa78-9c20-4feb-b3d2-4fe05
   | python3 -m json.tool
 
 # Check inbox
-curl -s "http://127.0.0.1:8000/messages/?to_agent=identity-canon&unread_only=true" \
+curl -s "http://127.0.0.1:8000/messages/?to_agent=commerce-canon&unread_only=true" \
   | python3 -m json.tool
 ```
 
@@ -87,7 +102,7 @@ curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
 
 **Start:**
 1. `cat .custodian-brief.md` — domain goal and open workplans (offline-safe)
-2. Check inbox: `GET /messages/?to_agent=identity-canon&unread_only=true`; mark read
+2. Check inbox: `GET /messages/?to_agent=commerce-canon&unread_only=true`; mark read
 3. Scan workplans: `ls workplans/` — note `status: ready`, `active`, or `blocked` files and open tasks
 4. Check human-needed tasks: `GET /tasks/?needs_human=true`
 
@@ -97,13 +112,19 @@ curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
 
 **Close:**
 1. Update workplan file task statuses to reflect progress
-2. Log: `POST /progress/` with a summary of what changed
-3. After workplan file changes, run:
+2. If finishing a workplan: hand off **residuals** as live work records first
+   (intake with `origin: residual` + `origin_ref: <WP-id>`, or a next workplan /
+   decision / engagement). Do not park leftovers only in prose or `SCOPE.md`.
+   Canon: `the-custodian/canon/standards/work-record-types_v0.1.md` § Residuals.
+3. Log: `POST /progress/` with a summary of what changed (name handoff ids)
+4. After workplan file changes, run:
    ```bash
-   statehub fix-consistency
+   uv run --project ~/repo-manager rmgr sync --path . --push
    ```
-   Coding agents should run this directly; ask the operator only if the CLI or
-   State Hub API is unavailable. This syncs task status from files into the hub DB.
+   This assigns only missing deterministic identifiers, verifies the pushed
+   Forgejo commit and `primary/railliance01`, then requests one central
+   reconciliation. A queued receipt is pending evidence; rerun after
+   connectivity returns. Use `statehub fix-consistency` for a separate deep audit.
 
 ---
 
@@ -128,7 +149,7 @@ Requires the `warden` CLI from `~/ops-warden` (`uv tool install .` or `uv run wa
 
 | Agent runtime | How to orient |
 | --- | --- |
-| **Codex / Grok** (shell, HTTP State Hub) | `warden route` commands above; inbox `to_agent=identity-canon` is for coordination, not secret vending |
+| **Codex / Grok** (shell, HTTP State Hub) | `warden route` commands above; inbox `to_agent=commerce-canon` is for coordination, not secret vending |
 | **Claude Code** (MCP when available) | `get_domain_summary("custodian")` for workplans; **still** use `warden route` for credential ownership |
 | **llm-connect** (inference service) | Never put secret retrieval in prompts; route custody to OpenBao/operator paths surfaced by `warden route` |
 
@@ -169,10 +190,10 @@ get wrong.
 Work items originate as files in this repo — not in the hub. The hub is a
 read/cache/index layer that rebuilds from files.
 
-**File location:** `workplans/IDENTITY-WP-NNNN-<slug>.md`
+**File location:** `workplans/COMMERCE-WP-NNNN-<slug>.md`
 
 **Archived location:** finished workplans may move to
-`workplans/archived/YYMMDD-IDENTITY-WP-NNNN-<slug>.md`. The `YYMMDD` prefix is
+`workplans/archived/YYMMDD-COMMERCE-WP-NNNN-<slug>.md`. The `YYMMDD` prefix is
 the completion/archive date; the frontmatter `id` does not change.
 
 **Ad Hoc Tasks:** small opportunistic fixes discovered during a session use
@@ -184,11 +205,11 @@ anything needing analysis, design, approval, dependencies, or multiple phases.
 
 ```yaml
 ---
-id: IDENTITY-WP-NNNN
+id: COMMERCE-WP-NNNN
 type: workplan
 title: "..."
 domain: infotech
-repo: identity-canon
+repo: commerce-canon
 status: proposed | ready | active | blocked | backlog | finished | archived
 owner: codex
 topic_slug: ...
@@ -208,7 +229,7 @@ derived health labels, not frontmatter statuses.
 ## Task Title
 
 ` ` `task
-id: IDENTITY-WP-NNNN-T01
+id: COMMERCE-WP-NNNN-T01
 status: wait | todo | progress | done | cancel
 priority: high | medium | low
 state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit
@@ -221,5 +242,13 @@ Status progression: `todo` → `progress` → `done`; use `wait` for waiting/blo
 
 To create a new workplan:
 1. Write the file following the format above
-2. Notify the custodian operator to run `make fix-consistency REPO=identity-canon`
+2. Notify the custodian operator to run `make fix-consistency REPO=commerce-canon`
    (or send a message to the hub agent via `POST /messages/`)
+
+
+## CommerceCanon workplan prefix and provenance
+
+New workplans use COMMERCE-WP-. Existing IDENTITY-WP identifiers, including the
+pre-cutover rename plan, retain their identity. Finished IDENTITY-WP files must
+not be rewritten merely to change their historical repo/domain fields.
+This extension overrides a generator that infers the majority historical prefix.
diff --git a/CLAUDE.md b/CLAUDE.md
index aeabcbf..e024541 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -1,4 +1,4 @@
-# identity-canon — Claude Code Instructions
+# commerce-canon — Claude Code Instructions
 
 @SCOPE.md
 @.claude/rules/repo-identity.md
diff --git a/INTENT.md b/INTENT.md
index 0166c2a..01fc9d6 100644
--- a/INTENT.md
+++ b/INTENT.md
@@ -1,168 +1,23 @@
-# INTENT.md
+# Intent
 
-## Purpose
+CommerceCanon provides researched, implementation-neutral semantics for
+counterparties, legal/commercial roles, commercial relationships and commitments,
+payment references, and counterparty assurance.
 
-`identity-canon` exists to research, clarify, and define a canonical terminology and conceptual data model for identity, user, organization, community, and relationship management across multi-tenant, multi-vendor, multi-community systems.
+Each concept has one owner. Commerce imports shared concepts from InfoTechCanon
+rather than redefining actors, accounts, identifiers, authorization, or evidence.
+For example, Commerce owns Registry Identifier as a specialization of the shared
+Identifier; Adjudication Outcome is imported from the evidence model.
 
-The project is intentionally focused on the **research and terminology layer**. It does not implement user management, identity provisioning, authentication, authorization, or UI workflows directly. Instead, it provides the conceptual foundation that later implementation projects can rely on.
+This repository continues the research and Git history of identity-canon under
+CUST-ADR-006, accepted 2026-08-17. Existing identity research migrates to its owning
+canon through the project ledger. Research remains provenance; draft definitions
+require destination review before publication.
 
-## Core Intent
-
-The core intent is to develop a clear, orthogonal vocabulary and canonical model for describing:
-
-* natural persons, users, accounts, identities, personas, and profiles
-* organizations, enterprises, sub-organizations, vendors, tenants, customers, and legal entities
-* communities, families, households, teams, spontaneous groups, and social graphs
-* actors, agents, bots, service accounts, and delegated representatives
-* memberships, affiliations, followers, ownership, representation, delegation, and trust relationships
-* weak and strong synonymity between identities, accounts, identifiers, and real-world actors
-* the distinction between social, legal, operational, and authorization-relevant relationships
-
-The project should help avoid the common collapse of overloaded terms such as `user`, `group`, `role`, `tenant`, `organization`, `account`, and `identity`.
-
-## Strategic Role
-
-`identity-canon` is a reference project for future identity-related systems and implementation repositories.
-
-It should provide:
-
-1. a researched corpus of relevant standards, concepts, and terminology;
-2. a canonical vocabulary suitable for humans and agents;
-3. a conceptual model for user, organization, community, and identity management;
-4. a basis for later schemas, APIs, CLI tools, UI workflows, and adapter implementations;
-5. a shared language for connecting IAM, social graph, enterprise directory, community, family, and authorization concepts.
-
-The repository should serve as a stable conceptual anchor before implementation-specific decisions are made.
-
-## Intended Users
-
-The primary users of this repository are:
-
-* system architects designing multi-tenant identity and user-management systems;
-* developers implementing user, organization, tenant, and community management components;
-* security and IAM engineers integrating systems such as Keycloak, Keycape, LLDAP, Authelia, privacyIDEA, OpenBao, SCIM, OIDC, SAML, LDAP, OpenFGA, Cedar, or related tools;
-* product designers creating CLI and UI workflows for managing users, organizations, communities, and relationships;
-* AI agents that need a precise terminology reference when generating schemas, documentation, workflows, or implementation plans.
-
-## Scope
-
-`identity-canon` covers research, terminology, and conceptual modeling.
-
-In scope:
-
-* literature and standards research;
-* terminology analysis;
-* canonical concept definitions;
-* comparison of overlapping terms across IAM, directory services, social graphs, enterprise systems, and authorization models;
-* conceptual diagrams and model descriptions;
-* model constraints and design principles;
-* synonymity and entity-resolution concepts;
-* scope, tenant, organization, community, family, and group distinctions;
-* relationship semantics such as membership, affiliation, representation, delegation, following, ownership, and trust;
-* recommendations for future implementation repositories.
-
-Out of scope:
-
-* implementation code;
-* production APIs;
-* database migrations;
-* UI components;
-* CLI commands;
-* adapter implementations;
-* direct integration with Keycloak, LDAP, SCIM, OIDC, SAML, OpenFGA, or other systems;
-* operational identity lifecycle tooling.
-
-Implementation repositories may later consume the results of `identity-canon`, but this repository remains implementation-neutral.
-
-## Design Principles
-
-### 1. Do not start with “user”
-
-The term `user` is overloaded. The canonical model should avoid using `user` as the root concept. Instead, it should distinguish actors, natural persons, accounts, identities, profiles, personas, credentials, and principals.
-
-### 2. Separate social, legal, operational, and authorization semantics
-
-An organization may be a legal entity, a tenant, a community, a billing customer, an employer, a vendor, or an authorization scope — but these meanings must not be collapsed into one concept.
-
-### 3. Model relationships explicitly
-
-Membership, affiliation, following, ownership, representation, delegation, administration, and trust should be modeled as distinct relationship types, not hidden inside groups or roles.
-
-### 4. Treat synonymity as an assertion, not a destructive merge
-
-Weak and strong synonymity should be represented as scoped, evidenced assertions between identifiers, accounts, identities, or actors. Identity linking should preserve source, confidence, scope, evidence, and revocation state.
-
-### 5. Keep concepts orthogonal
-
-The model should minimize conceptual overlap. If two terms are similar, the repository should explain the distinction or deliberately collapse them with clear justification.
-
-### 6. Remain implementation-neutral
-
-The canonical model should be compatible with common IAM, directory, social graph, and authorization systems, but should not mirror any single product’s terminology too closely.
-
-## Research Areas
-
-The repository should collect and analyze knowledge from at least the following areas:
-
-* SCIM, LDAP, and directory schemas;
-* OpenID Connect, SAML, WebAuthn, and federation models;
-* NIST digital identity guidelines and identity assurance terminology;
-* Keycloak, ZITADEL, Ory, Authelia, LLDAP, and related IAM systems;
-* ActivityPub, FOAF, WebID, Solid, and social graph models;
-* Google Zanzibar, OpenFGA, Cedar, Cerbos, and relationship-based authorization;
-* W3C DID and Verifiable Credentials;
-* entity resolution, identity matching, and synonymity;
-* GDPR-relevant concepts such as pseudonymization, data minimization, and identity linkage.
-
-## Expected Outputs
-
-The repository should eventually contain:
-
-* a curated research corpus;
-* a glossary of canonical identity-management terms;
-* a terminology conflict map;
-* a conceptual entity and relationship model;
-* synonymity and identity-linking model notes;
-* comparison notes against major standards and tools;
-* model design principles;
-* candidate schema sketches;
-* recommendations for downstream implementation projects.
-
-## Downstream Relationship
-
-`identity-canon` may later inform projects such as:
-
-* `user-engine` — operational user and account management;
-* `user-accounts` — user-facing account and preference UI;
-* `user-manager` — administrative user-management UI;
-* `identity-connect` — adapters to IAM and directory systems;
-* `actor-graph` — relationship and synonymity graph engine;
-* `access-control` or related authorization projects;
-* tenant, organization, community, and family management tooling.
-
-These projects should treat `identity-canon` as a conceptual reference, not as an implementation dependency unless a later explicit schema package is extracted.
-
-## Non-Goals
-
-`identity-canon` is not intended to become:
-
-* a replacement for Keycloak, LDAP, SCIM, OIDC, SAML, or OpenFGA;
-* a complete authorization policy language;
-* a production identity provider;
-* a database product;
-* a UI framework;
-* a CLI implementation;
-* a social network implementation.
-
-Its value lies in making the terminology and conceptual structure clear enough that such systems can later be designed and integrated coherently.
-
-## Guiding Question
-
-The guiding question of `identity-canon` is:
-
-> What is the smallest clear set of orthogonal concepts needed to model persons, accounts, identities, organizations, tenants, communities, families, agents, and their relationships across enterprise IAM, social systems, and multi-tenant platforms?
-
-## Status
-
-This repository begins as a research and terminology project. Its early work should prioritize clarity, comparison, and conceptual grounding over premature schema or implementation design.
+New commercial content requires a demand signal with named consumer evidence.
+Potential consumers include fin-hub, target-revenue, adaptive-pricing, and
+qonto-assistant; their adoption is not a federation completion gate.
 
+CommerceCanon provides semantics and research. Runtime services, APIs, CLI tools,
+application integrations, and speculative expansion require separate demand and
+work records. Ecosystem policy remains in Custodian canon.
diff --git a/README.md b/README.md
index 1693ac6..fdf84a2 100644
--- a/README.md
+++ b/README.md
@@ -1,12 +1,16 @@
-# identity-canon
+# commerce-canon
 
-Orthogonal vocabulary and canonical model for identity-related concepts.
+CommerceCanon owns counterparty and commercial-relationship semantics and imports
+shared identity, organization, access, governance, and evidence concepts from
+InfoTechCanon. Custodian canon governs both domain canons.
 
-Start with:
+This repository continues the history of `identity-canon` under accepted
+CUST-ADR-006. The federation migration is coordinated by
+[CFED-WP-0001](../prj-canon-federation/workplans/CFED-WP-0001-foundation.md).
+The existing glossary and research remain migration inputs until the destination
+models pass their canon review gates; the rename alone does not publish them.
 
-- `INTENT.md` for purpose and project boundaries;
-- `ResearchProposal.md` for the research method and expected deliverables;
-- `research/CorpusIndex.md` for the source-note corpus;
-- `canon/CanonicalGlossary.md` and `model/ConceptualModel.md` for the current
-  draft canon;
-- `workplans/` for State Hub-tracked work.
+Start with [INTENT.md](INTENT.md), [SCOPE.md](SCOPE.md), the
+[research corpus](research/CorpusIndex.md), and [workplans](workplans/).
+The [migration ledger](../prj-canon-federation/ledger/README.md) records concept
+destinations. The new canon layout is tracked by CFED-WP-0001-T04.
diff --git a/SCOPE.md b/SCOPE.md
index 359c8a7..85b54cd 100644
--- a/SCOPE.md
+++ b/SCOPE.md
@@ -1,54 +1,32 @@
-# SCOPE
+# Scope
 
-## One-liner
+CommerceCanon owns counterparty and commercial-relationship semantics under
+CUST-ADR-006. Its shared technical concepts are imported from InfoTechCanon.
 
-Orthogonal vocabulary and canonical model for identity-related concepts.
+## In scope
 
-## Core Idea
+- Preserve the existing research corpus, scenarios, terminology, Git history,
+  and finished IDENTITY-WP workplans as provenance.
+- Implement the commerce assignments in the federation ownership ledger.
+- Establish the canon layout, kernel boundary, and reciprocal interface cards.
+- Separate commercial records from login accounts and model commercial binding
+  explicitly, carrying forward design principles P14 and P15.
+- Grow through named consumer demand; record implementation in local workplans.
 
-`identity-canon` is a research and terminology repository. It defines an
-implementation-neutral vocabulary and conceptual model for identity, accounts,
-actors, organizations, tenants, communities, families, agents, relationships,
-and synonymity across IAM, directory, federation, social graph, authorization,
-decentralized identity, and entity-resolution domains.
+## Out of scope
 
-## In Scope
+- Re-own identity, organization, access-control, governance, or general evidence
+  concepts; redefine Adjudication Outcome in CommerceCanon.
+- Implement runtime identity or payment services, production APIs, or a CLI.
+- Author Family beyond the separately owned seed or speculative new commercial
+  concepts. Consumer adoption is separately owned.
 
-- Maintain research notes, source summaries, terminology inventories,
-  conflict maps, canonical glossary entries, conceptual model notes, scenario
-  tests, open questions, downstream recommendations, and State Hub workplans.
-- Compare overlapping terms across standards, product documentation, social
-  graph models, authorization systems, and privacy/entity-resolution research.
-- Keep canonical definitions separate from external product mappings.
-- Record decisions, progress, and workplan status through State Hub.
-- Verify changes with markdown review, `git diff --check`, and ADR-001
-  consistency checks.
+## Migration status
 
-## Out of Scope
+The repository rename preserves history. The old mixed glossary remains a
+migration input until CFED-WP-0001-T04/T05/T06/T07 establish the destination
+layout, models, and provenance distribution. Rename completion does not imply
+those publication gates have passed.
 
-- Implement identity providers, account-management services, provisioning
-  adapters, authorization engines, UI components, CLI commands, databases, or
-  production APIs.
-- Own unrelated adjacent systems or operational identity lifecycle tooling.
-- Make irreversible operational decisions without human approval.
-- Treat draft canon artifacts as finalized schemas before source-note backfill
-  and scenario review.
-
-## Current State
-
-- Status: active research scaffold.
-- The repository is currently documentation-only. It has no package manifest,
-  build system, runtime app, or executable test suite.
-- `IDENTITY-WP-0002` seeded the first terminology, canon, model, scenario,
-  open-question, and downstream recommendation artifacts. The next research
-  pass should backfill individual source notes and revise the draft canon from
-  evidence.
-
-## Getting Oriented
-
-- Start with: INTENT.md
-- Research proposal: ResearchProposal.md
-- Corpus index: research/CorpusIndex.md
-- Draft canon: canon/CanonicalGlossary.md and model/ConceptualModel.md
-- Agent instructions: AGENTS.md
-- Workplans: workplans/
+See INTENT.md, research/CorpusIndex.md, and the federation ledger. New plans use
+COMMERCE-WP-; existing IDENTITY-WP identifiers and finished files remain intact.
diff --git a/history/2026-09-05-commerce-rename-preparation.md b/history/2026-09-05-commerce-rename-preparation.md
new file mode 100644
index 0000000..7103409
--- /dev/null
+++ b/history/2026-09-05-commerce-rename-preparation.md
@@ -0,0 +1,24 @@
+# CommerceCanon rename preparation — 2026-09-05
+
+CUST-ADR-006 and CFED-WP-0001 authorize renaming identity-canon in place to
+commerce-canon. State Hub repository UUID is
+8c82baea-bb40-435d-ac42-ec7a7c20dbb8; verified Forgejo repository ID is 46.
+The three finished IDENTITY-WP workplans remain unchanged. New plans after
+cutover use COMMERCE-WP; the pre-cutover IDENTITY-WP-0004 retains its ID.
+
+Preparation baseline: 43c5c21a7a7e273241d9c7622db4e926ac9aadfa. This is a
+preparation record, not evidence that the rename completed. Record the final
+operation ID, cutover date/head, continuity verification, registered-host
+outcomes, and metadata commit in the rename workplan at execution.
+
+Identity and evidence content move to InfoTechCanon through the ownership ledger;
+commercial content stays here. Research and historical references remain
+provenance. Runtime implementation and downstream adoption are separately owned.
+
+
+## Cutover completed
+
+Operation 615e7b44-d84e-4feb-92c5-1708feaf1e65 completed 2026-09-05 on source
+40d5792fafbb2de778eabb56cfeaf00aecd058e1, retaining Forge ID 46 and the existing
+State Hub UUID. Both registered checkouts were moved and verified. See
+IDENTITY-WP-0004 for continuity evidence, metadata changes and residual handoffs.
diff --git a/registry/capabilities/capability.identity.subject-resolution.md b/registry/capabilities/capability.identity.subject-resolution.md
index c4afcad..4e49eeb 100644
--- a/registry/capabilities/capability.identity.subject-resolution.md
+++ b/registry/capabilities/capability.identity.subject-resolution.md
@@ -2,7 +2,7 @@
 id: capability.identity.subject-resolution
 name: Identity Subject Resolution
 summary: Resolve who or what is acting in a context by mapping principals, accounts, actors, and identifiers to a stable subject model.
-owner: identity-canon
+owner: commerce-canon
 status: draft
 domain: helix_forge
 tags:
@@ -16,7 +16,7 @@ maturity:
     target: D5
     confidence: medium
     rationale: >
-      Subject/principal terminology is explored in identity-canon conflict maps
+      Subject/principal terminology is explored in commerce-canon conflict maps
       and conceptual model, but dedicated use-case grounding is incomplete.
   availability:
     current: A0
@@ -65,17 +65,17 @@ discovery:
   use_cases:
     - UC-RS-004
   research_memos:
-    - identity-canon/terminology/TerminologyConflictMap.md
-    - identity-canon/model/ConceptualModel.md
+    - commerce-canon/terminology/TerminologyConflictMap.md
+    - commerce-canon/model/ConceptualModel.md
 
 availability:
   current_level: A0
   target_level: A4
   current_artifacts:
-    - identity-canon/model/ConceptualModel.md
-    - identity-canon/canon/CanonicalGlossary.md
+    - commerce-canon/model/ConceptualModel.md
+    - commerce-canon/canon/CanonicalGlossary.md
   target_artifacts:
-    - identity-canon/packages/subject-resolution-sdk
+    - commerce-canon/packages/subject-resolution-sdk
   consumption_modes:
     - informational
 
@@ -89,8 +89,8 @@ relations:
 
 evidence:
   documentation:
-    - identity-canon/canon/CanonicalGlossary.md
-    - identity-canon/scenarios/ScenarioTests.md
+    - commerce-canon/canon/CanonicalGlossary.md
+    - commerce-canon/scenarios/ScenarioTests.md
   tests: []
   consumer_feedback: []
   bug_reports: []
diff --git a/registry/capabilities/capability.identity.vocabulary-canonicalize.md b/registry/capabilities/capability.identity.vocabulary-canonicalize.md
index 1ead200..efc431c 100644
--- a/registry/capabilities/capability.identity.vocabulary-canonicalize.md
+++ b/registry/capabilities/capability.identity.vocabulary-canonicalize.md
@@ -2,7 +2,7 @@
 id: capability.identity.vocabulary-canonicalize
 name: Identity Vocabulary Canonicalization
 summary: Define and maintain an implementation-neutral vocabulary for identity-related concepts across overlapping domains.
-owner: identity-canon
+owner: commerce-canon
 status: draft
 domain: helix_forge
 tags:
@@ -16,7 +16,7 @@ maturity:
     target: D6
     confidence: medium
     rationale: >
-      identity-canon has researched overlapping terminology across IAM,
+      commerce-canon has researched overlapping terminology across IAM,
       directory, federation, and authorization domains, but use-case saturation
       is not yet demonstrated.
   availability:
@@ -70,18 +70,18 @@ discovery:
     - UC-RS-004
     - UC-RS-006
   research_memos:
-    - identity-canon/ResearchProposal.md
-    - identity-canon/canon/CanonicalGlossary.md
+    - commerce-canon/ResearchProposal.md
+    - commerce-canon/canon/CanonicalGlossary.md
 
 availability:
   current_level: A0
   target_level: A2
   current_artifacts:
-    - identity-canon/canon/CanonicalGlossary.md
-    - identity-canon/terminology/TerminologyConflictMap.md
-    - identity-canon/model/ConceptualModel.md
+    - commerce-canon/canon/CanonicalGlossary.md
+    - commerce-canon/terminology/TerminologyConflictMap.md
+    - commerce-canon/model/ConceptualModel.md
   target_artifacts:
-    - identity-canon/packages/identity-vocabulary
+    - commerce-canon/packages/identity-vocabulary
   consumption_modes:
     - informational
     - markdown research artifacts
@@ -96,8 +96,8 @@ relations:
 
 evidence:
   documentation:
-    - identity-canon/INTENT.md
-    - identity-canon/canon/CanonicalGlossary.md
+    - commerce-canon/INTENT.md
+    - commerce-canon/canon/CanonicalGlossary.md
   tests: []
   consumer_feedback: []
   bug_reports: []
@@ -125,7 +125,7 @@ D4/A0/C2/R0 vector that contrasts with implementation-ready entries.
 
 ## Current reuse mode
 
-Consumers read canon, terminology, and model artifacts in the identity-canon
+Consumers read canon, terminology, and model artifacts in the commerce-canon
 repository. The value is planning reuse through shared vocabulary, not runtime
 integration.
 
diff --git a/registry/indexes/capabilities.yaml b/registry/indexes/capabilities.yaml
index d7f13d2..7c0ae8d 100644
--- a/registry/indexes/capabilities.yaml
+++ b/registry/indexes/capabilities.yaml
@@ -9,7 +9,7 @@ capabilities:
   vector: D3 / A0 / C1 / R0
   domain: helix_forge
   status: draft
-  owner: identity-canon
+  owner: commerce-canon
   path: registry/capabilities/capability.identity.subject-resolution.md
   tags:
   - identity
@@ -24,7 +24,7 @@ capabilities:
   vector: D4 / A0 / C2 / R0
   domain: helix_forge
   status: draft
-  owner: identity-canon
+  owner: commerce-canon
   path: registry/capabilities/capability.identity.vocabulary-canonicalize.md
   tags:
   - identity
diff --git a/workplans/IDENTITY-WP-0004-commerce-rename.md b/workplans/IDENTITY-WP-0004-commerce-rename.md
index 43494ea..686ebef 100644
--- a/workplans/IDENTITY-WP-0004-commerce-rename.md
+++ b/workplans/IDENTITY-WP-0004-commerce-rename.md
@@ -2,9 +2,9 @@
 id: IDENTITY-WP-0004
 type: workplan
 title: "Rename identity-canon to commerce-canon with continuous history"
-domain: infotech
-repo: identity-canon
-status: active
+domain: financials
+repo: commerce-canon
+status: finished
 owner: codex
 topic_slug: canon
 created: "2026-09-05"
@@ -49,7 +49,7 @@ The snapshot is evidence, not permission to rename a subsequently changed head.
 
 ```task
 id: IDENTITY-WP-0004-T02
-status: progress
+status: done
 priority: high
 state_hub_task_id: "8606bbbb-716d-5011-950e-29dc9ea3c2d8"
 ```
@@ -100,7 +100,7 @@ coordinated. No operation journal has been started.
 
 ```task
 id: IDENTITY-WP-0004-T04
-status: progress
+status: done
 priority: high
 state_hub_task_id: "2082388e-2096-5138-a7a6-40c9f71e1fb5"
 ```
@@ -127,7 +127,7 @@ retain verification evidence and do not delete repository history.
 
 ```task
 id: IDENTITY-WP-0004-T05
-status: wait
+status: done
 priority: medium
 state_hub_task_id: "c78ce770-3e0c-505d-8eff-538fd305da52"
 ```
@@ -156,3 +156,28 @@ The CI smoke uses dynamic GITHUB_REPOSITORY and has no hardcoded slug.
 The registered railiance01 checkout is inspected separately; its path will not
 be rewritten in State Hub without proving its actual filesystem disposition.
 The user renewed instruction to continue once signing was provisioned.
+
+
+## Completion — 2026-09-05
+
+Operation `615e7b44-d84e-4feb-92c5-1708feaf1e65` completed through the supported
+journal. Forge ID 46 and State Hub UUID are unchanged; old slug is a protected
+alias. The exact cutover head was `40d5792fafbb2de778eabb56cfeaf00aecd058e1`.
+A fresh clone verified that head before source-synced. Both local and railiance01
+checkouts moved to commerce-canon; registered paths and every existing remote
+now address commerce-canon. The remote's legacy `gitea` remote name is retained
+but points at the canonical Forgejo URL rather than the retired forge.
+
+The State Hub redirect defect was fixed under STATE-WP-0089, tested (46 passing
+rename tests), and deployed as main-fe6b8d9 / Helm revision 60. Replay reconciled
+the operator-side rename without changing IDs or directly editing the DB.
+
+README/INTENT/SCOPE, financials classification, capability repository references,
+and agent instructions now use CommerceCanon. New plans use COMMERCE-WP;
+all three prior finished plans remain byte-for-byte unchanged.
+
+Live residual handoffs before closure: CFED-WP-0001-T09 owns the remaining fleet
+sweep and projection acceptance; REUSE-WP-0021 owns reuse-surface's source URLs,
+local roster and generated caches/index. Canon/model/corpus publication remains
+in CFED-WP-0001-T04 through T13. The rename's completion does not assert that
+those separate federation gates have passed.