coulomb/commerce-canon
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Complete CommerceCanon rename and declare concept ownership boundary
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b
This commit is contained in:
tegwick 2026-09-05 19:59:11 +02:00
parent 40d5792faf
commit c7002cfcea
18 changed files with 279 additions and 324 deletions
Download patch file Download diff file Expand all files Collapse all files

2
.claude/rules/credential-routing.md
View file

@ -19,7 +19,7 @@ Requires the `warden` CLI from `~/ops-warden` (`uv tool install .` or `uv run wa
| Agent runtime | How to orient | | 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 | | **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` | | **llm-connect** (inference service) | Never put secret retrieval in prompts; route custody to OpenBao/operator paths surfaced by `warden route` |

26
.claude/rules/first-session.md
View file

@ -1,11 +1,11 @@
## First Session Protocol ## 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. The project is registered but work has not yet been structured.
**Step 1 — Read, don't write** **Step 1 — Read, don't write**
- `~/the-custodian/canon/projects/infotech/project_charter_v0.1.md` — purpose, scope - `~/the-custodian/canon/projects/financials/project_charter_v0.1.md` — purpose, scope
- `~/the-custodian/canon/projects/infotech/roadmap_v0.1.md` — planned phases - `~/the-custodian/canon/projects/financials/roadmap_v0.1.md` — planned phases
- Scan repo root: README, directory structure, existing code or docs - Scan repo root: README, directory structure, existing code or docs
**Step 2 — Survey in-progress work** **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 Propose 1–3 workplans — each a coherent strand, weeks to months, anchored to a
roadmap phase. **Wait for approval before creating.** 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 Then run the deterministic, forge-derived sync — do **not** call
`create_workplan`/`create_task` yourself; manual registration duplicates what `create_workplan`/`create_task` yourself:
C-06 creates from the file:
```bash ```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` Repo Manager writes deterministic `state_hub_workstream_id` and
(legacy frontmatter name — holds the workplan UUID) and `state_hub_task_id` `state_hub_task_id` values, pushes the file, verifies `primary/railliance01`,
back into the file. 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** **Step 5 — Record the setup**
``` ```
add_progress_event( 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", event_type="milestone",
topic_id="fe2aaa78-9c20-4feb-b3d2-4fe0529572a3", topic_id="fe2aaa78-9c20-4feb-b3d2-4fe0529572a3",
detail={"workplans": [...], "tasks_created": M} detail={"workplans": [...], "tasks_created": M}

2
.claude/rules/repo-boundary.md
View file

@ -1,6 +1,6 @@
## Repo boundary ## 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.: <!-- TODO: List what belongs in adjacent repos, e.g.:
- SSH key management → railiance-infra/ - SSH key management → railiance-infra/

6
.claude/rules/repo-identity.md
View file

@ -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 **Domain:** financials
**Repo slug:** identity-canon **Repo slug:** commerce-canon
**Topic ID:** fe2aaa78-9c20-4feb-b3d2-4fe0529572a3 **Topic ID:** fe2aaa78-9c20-4feb-b3d2-4fe0529572a3

38
.claude/rules/session-protocol.md
View file

@ -11,7 +11,7 @@ cat .custodian-brief.md
``` ```
Then call the MCP tool for richer cross-domain context when MCP tools are exposed: 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: If MCP tools are unavailable in the current agent session, use the REST API:
```bash ```bash
@ -22,14 +22,14 @@ If the hub is offline: `cd ~/state-hub && make api`
**Step 2 — Check inbox** **Step 2 — Check inbox**
With MCP tools: 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 Mark read with `mark_message_read(message_id)`. Reply or act on coordination
requests before proceeding. requests before proceeding.
Without MCP tools: Without MCP tools:
```bash ```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 | python3 -m json.tool
curl -s -X PATCH "http://127.0.0.1:8000/messages/<id>/read" \ curl -s -X PATCH "http://127.0.0.1:8000/messages/<id>/read" \
-H "Content-Type: application/json" -d '{}' -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** **Step 4 — Present brief**
1. **Active workplans** for `infotech` — title, task counts, blocking decisions 1. **Active workplans** for `financials` — title, task counts, blocking decisions
2. **Pending tasks** from `workplans/` + any `[repo:identity-canon]` hub tasks 2. **Pending tasks** from `workplans/` + any `[repo:commerce-canon]` hub tasks
3. **Goal guidance** — if `goal_guidance` in summary: 3. **Goal guidance** — if `goal_guidance` in summary:
- `needs_workplan`: surface as top action — *"Repo goal '{title}' has no workplan yet"* - `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 - `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** > State Hub is a *read model*. **Never register workplans or tasks by hand**
> (`create_workplan`, `create_task`) — write the workplan file in `workplans/` > (`create_workplan`, `create_task`) — write the workplan file in `workplans/`
> and run `fix-consistency`; C-06 registers the workplan and tasks and writes > and run `uv run --project ~/repo-manager rmgr sync --path . --push`.
> IDs back into the file. Manual registration creates duplicates when > Repo Manager assigns missing deterministic IDs; central derives the exact
> fix-consistency runs. Work structure belongs in repo files (ADR-001). > 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 — > Legacy: `create_workstream` and `/workstreams/` remain as metered aliases —
> see `workplan-convention.md` (compatibility footnote). > see `workplan-convention.md` (compatibility footnote).
**Session close:** **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: With MCP tools:
``` ```
add_progress_event(summary="...", topic_id="fe2aaa78-9c20-4feb-b3d2-4fe0529572a3", workplan_id="<uuid>") 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: then sync from the repo checkout:
```bash ```bash
git pull --ff-only 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), The sync refuses uncommitted workplan files and a branch behind its upstream.
use the pull-before-fix mode from any shell with the State Hub CLI: This prevents a workstation projection from getting ahead of the forge source.
```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.

53
.claude/rules/workplan-convention.md
View file

@ -1,7 +1,7 @@
## Workplan Convention (ADR-001) ## Workplan Convention (ADR-001)
File location: `workplans/IDENTITY-WP-NNNN-<slug>.md` File location: `workplans/COMMERCE-WP-NNNN-<slug>.md`
ID prefix: `IDENTITY-WP-` ID prefix: `COMMERCE-WP-`
Work items originate as files in this repo **before** being registered in the hub. 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. `needs_review` are derived health labels, not stored statuses.
Closed workplans may be moved to `workplans/archived/` with a completion-date 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. unchanged; the prefix is only for quick visual reference.
Small opportunistic tasks discovered during another session use **Ad Hoc Tasks**: 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 `workplans/ADHOC-YYYY-MM-DD.md`, workplan id
`ADHOC-YYYY-MM-DD-T01`, `T02`, etc. Use adhocs only for low-risk work completed `COMMERCE-WP-ADHOC-YYYY-MM-DD`, and task ids
directly. Promote anything requiring analysis, design, approval, dependencies, or `COMMERCE-WP-ADHOC-YYYY-MM-DD-T01`, `T02`, etc. `IDENTITY-WP` includes its final
multiple planned phases into a normal workplan. `-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 — Ecosystem todos from other agents arrive as `[repo:commerce-canon]` hub tasks —
visible at session start. Pick one up by creating the workplan file, committing, visible at session start. Pick one up by creating the workplan file, then run
and running `statehub fix-consistency` — C-06 registers the workplan in the hub. the fast authoritative projection path:
Never register by hand with `create_workplan` (legacy MCP alias: `create_workstream`).
```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 blocks use this shape:
```task ```task
id: IDENTITY-WP-NNNN-T01 id: COMMERCE-WP-NNNN-T01
status: wait | todo | progress | done | cancel status: wait | todo | progress | done | cancel
priority: high | medium | low priority: high | medium | low
state_hub_task_id: "<uuid>" # written by fix-consistency — do not edit 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 Status progression is `todo` → `progress` → `done`; use `wait` for waiting or
blocked work and `cancel` for stopped work. 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 Workplan frontmatter carries `state_hub_workstream_id` — a legacy field name
kept for compatibility; it holds the hub workplan UUID and is written by kept for compatibility; it holds the hub workplan UUID and is written by
fix-consistency. Do not edit or rename it. 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 **Workplan** is the fleet term — see
`the-custodian/canon/standards/workplan-terminology-fleet_v0.1.md`. `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 (`workstream_id`), MCP aliases (`create_workstream`), and the frontmatter field
above remain until `STATE-WP-0069` retires them via legacy-meter. Treat those 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 identifiers as workplan IDs. Prefer `GET /workplans/` and `workplan_id` in new

6
.gitignore vendored
View file

@ -174,3 +174,9 @@ cython_debug/
# PyPI configuration file # PyPI configuration file
.pypirc .pypirc
# state-hub: track .claude/rules
# Claude Code local state (track shared rules; ignore machine-specific files)
.claude/*
!.claude/rules/
!.claude/rules/*.md

17
.repo-classification.yaml
View file

@ -1,17 +1,16 @@
repo_classification: repo_classification:
standard: Repo Classification Standard standard: Repo Classification Standard
version: '1.0' version: '1.0'
classified_at: '2026-06-22' classified_at: '2026-09-05'
classified_by: human classified_by: codex
category: research category: research
domain: infotech domain: financials
secondary_domains: secondary_domains:
- government - government
- infotech
capability_tags: capability_tags:
- identity
- access-control
- terminology
- canon - canon
- terminology
- governance - governance
business_stake: business_stake:
- technology - technology
@ -22,4 +21,8 @@ repo_classification:
- intention - intention
- control - control
- adaptation - 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.

73
AGENTS.md
View file

@ -1,25 +1,27 @@
# identity-canon — Agent Instructions # commerce-canon — Agent Instructions
## Repo Identity ## 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 **Domain:** financials
**Repo slug:** identity-canon **Repo slug:** commerce-canon
**Topic ID:** `fe2aaa78-9c20-4feb-b3d2-4fe0529572a3` **Topic ID:** `fe2aaa78-9c20-4feb-b3d2-4fe0529572a3`
**Workplan prefix:** `IDENTITY-WP-` **Workplan prefix:** `COMMERCE-WP-`
--- ---
## State Hub Integration ## State Hub Integration
The Custodian State Hub tracks work across all domains. Interact via HTTP REST — The Custodian State Hub tracks work across all domains. Codex uses HTTP REST and
there is no MCP server for Codex agents. 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 | | Context | URL |
|---------|-----| |---------|-----|
| Local workstation | `http://127.0.0.1:8000` | | 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 | | 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. 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 unreachable. Treat that as pending local evidence, then ask the operator to run
statehub outbox status/replay after connectivity returns. 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 ### Orient at session start
```bash ```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 | python3 -m json.tool
# Check inbox # 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 | python3 -m json.tool
``` ```
@ -87,7 +102,7 @@ curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
**Start:** **Start:**
1. `cat .custodian-brief.md` — domain goal and open workplans (offline-safe) 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 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` 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:** **Close:**
1. Update workplan file task statuses to reflect progress 1. Update workplan file task statuses to reflect progress
2. Log: `POST /progress/` with a summary of what changed 2. If finishing a workplan: hand off **residuals** as live work records first
3. After workplan file changes, run: (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 ```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 This assigns only missing deterministic identifiers, verifies the pushed
State Hub API is unavailable. This syncs task status from files into the hub DB. 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 | | 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 | | **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` | | **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 Work items originate as files in this repo — not in the hub. The hub is a
read/cache/index layer that rebuilds from files. 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 **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. the completion/archive date; the frontmatter `id` does not change.
**Ad Hoc Tasks:** small opportunistic fixes discovered during a session use **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 ```yaml
--- ---
id: IDENTITY-WP-NNNN id: COMMERCE-WP-NNNN
type: workplan type: workplan
title: "..." title: "..."
domain: infotech domain: infotech
repo: identity-canon repo: commerce-canon
status: proposed | ready | active | blocked | backlog | finished | archived status: proposed | ready | active | blocked | backlog | finished | archived
owner: codex owner: codex
topic_slug: ... topic_slug: ...
@ -208,7 +229,7 @@ derived health labels, not frontmatter statuses.
## Task Title ## Task Title
` ` `task ` ` `task
id: IDENTITY-WP-NNNN-T01 id: COMMERCE-WP-NNNN-T01
status: wait | todo | progress | done | cancel status: wait | todo | progress | done | cancel
priority: high | medium | low priority: high | medium | low
state_hub_task_id: "<uuid>" # written by fix-consistency — do not edit 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: To create a new workplan:
1. Write the file following the format above 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/`) (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.

2
CLAUDE.md
View file

@ -1,4 +1,4 @@
# identity-canon — Claude Code Instructions # commerce-canon — Claude Code Instructions
@SCOPE.md @SCOPE.md
@.claude/rules/repo-identity.md @.claude/rules/repo-identity.md

181
INTENT.md
View file

@ -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 New commercial content requires a demand signal with named consumer evidence.
Potential consumers include fin-hub, target-revenue, adaptive-pricing, and
The core intent is to develop a clear, orthogonal vocabulary and canonical model for describing: qonto-assistant; their adoption is not a federation completion gate.
* 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.
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.

22
README.md
View file

@ -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; Start with [INTENT.md](INTENT.md), [SCOPE.md](SCOPE.md), the
- `ResearchProposal.md` for the research method and expected deliverables; [research corpus](research/CorpusIndex.md), and [workplans](workplans/).
- `research/CorpusIndex.md` for the source-note corpus; The [migration ledger](../prj-canon-federation/ledger/README.md) records concept
- `canon/CanonicalGlossary.md` and `model/ConceptualModel.md` for the current destinations. The new canon layout is tracked by CFED-WP-0001-T04.
draft canon;
- `workplans/` for State Hub-tracked work.

70
SCOPE.md
View file

@ -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 ## Out of scope
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.
## 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, ## Migration status
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.
## 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 See INTENT.md, research/CorpusIndex.md, and the federation ledger. New plans use
adapters, authorization engines, UI components, CLI commands, databases, or COMMERCE-WP-; existing IDENTITY-WP identifiers and finished files remain intact.
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/

24
history/2026-09-05-commerce-rename-preparation.md Normal file
View file

@ -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.

18
registry/capabilities/capability.identity.subject-resolution.md
View file

@ -2,7 +2,7 @@
id: capability.identity.subject-resolution id: capability.identity.subject-resolution
name: 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. 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 status: draft
domain: helix_forge domain: helix_forge
tags: tags:
@ -16,7 +16,7 @@ maturity:
target: D5 target: D5
confidence: medium confidence: medium
rationale: > 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. and conceptual model, but dedicated use-case grounding is incomplete.
availability: availability:
current: A0 current: A0
@ -65,17 +65,17 @@ discovery:
use_cases: use_cases:
- UC-RS-004 - UC-RS-004
research_memos: research_memos:
- identity-canon/terminology/TerminologyConflictMap.md - commerce-canon/terminology/TerminologyConflictMap.md
- identity-canon/model/ConceptualModel.md - commerce-canon/model/ConceptualModel.md
availability: availability:
current_level: A0 current_level: A0
target_level: A4 target_level: A4
current_artifacts: current_artifacts:
- identity-canon/model/ConceptualModel.md - commerce-canon/model/ConceptualModel.md
- identity-canon/canon/CanonicalGlossary.md - commerce-canon/canon/CanonicalGlossary.md
target_artifacts: target_artifacts:
- identity-canon/packages/subject-resolution-sdk - commerce-canon/packages/subject-resolution-sdk
consumption_modes: consumption_modes:
- informational - informational
@ -89,8 +89,8 @@ relations:
evidence: evidence:
documentation: documentation:
- identity-canon/canon/CanonicalGlossary.md - commerce-canon/canon/CanonicalGlossary.md
- identity-canon/scenarios/ScenarioTests.md - commerce-canon/scenarios/ScenarioTests.md
tests: [] tests: []
consumer_feedback: [] consumer_feedback: []
bug_reports: [] bug_reports: []

22
registry/capabilities/capability.identity.vocabulary-canonicalize.md
View file

@ -2,7 +2,7 @@
id: capability.identity.vocabulary-canonicalize id: capability.identity.vocabulary-canonicalize
name: Identity Vocabulary Canonicalization name: Identity Vocabulary Canonicalization
summary: Define and maintain an implementation-neutral vocabulary for identity-related concepts across overlapping domains. summary: Define and maintain an implementation-neutral vocabulary for identity-related concepts across overlapping domains.
owner: identity-canon owner: commerce-canon
status: draft status: draft
domain: helix_forge domain: helix_forge
tags: tags:
@ -16,7 +16,7 @@ maturity:
target: D6 target: D6
confidence: medium confidence: medium
rationale: > 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 directory, federation, and authorization domains, but use-case saturation
is not yet demonstrated. is not yet demonstrated.
availability: availability:
@ -70,18 +70,18 @@ discovery:
- UC-RS-004 - UC-RS-004
- UC-RS-006 - UC-RS-006
research_memos: research_memos:
- identity-canon/ResearchProposal.md - commerce-canon/ResearchProposal.md
- identity-canon/canon/CanonicalGlossary.md - commerce-canon/canon/CanonicalGlossary.md
availability: availability:
current_level: A0 current_level: A0
target_level: A2 target_level: A2
current_artifacts: current_artifacts:
- identity-canon/canon/CanonicalGlossary.md - commerce-canon/canon/CanonicalGlossary.md
- identity-canon/terminology/TerminologyConflictMap.md - commerce-canon/terminology/TerminologyConflictMap.md
- identity-canon/model/ConceptualModel.md - commerce-canon/model/ConceptualModel.md
target_artifacts: target_artifacts:
- identity-canon/packages/identity-vocabulary - commerce-canon/packages/identity-vocabulary
consumption_modes: consumption_modes:
- informational - informational
- markdown research artifacts - markdown research artifacts
@ -96,8 +96,8 @@ relations:
evidence: evidence:
documentation: documentation:
- identity-canon/INTENT.md - commerce-canon/INTENT.md
- identity-canon/canon/CanonicalGlossary.md - commerce-canon/canon/CanonicalGlossary.md
tests: [] tests: []
consumer_feedback: [] consumer_feedback: []
bug_reports: [] bug_reports: []
@ -125,7 +125,7 @@ D4/A0/C2/R0 vector that contrasts with implementation-ready entries.
## Current reuse mode ## 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 repository. The value is planning reuse through shared vocabulary, not runtime
integration. integration.

4
registry/indexes/capabilities.yaml
View file

@ -9,7 +9,7 @@ capabilities:
vector: D3 / A0 / C1 / R0 vector: D3 / A0 / C1 / R0
domain: helix_forge domain: helix_forge
status: draft status: draft
owner: identity-canon owner: commerce-canon
path: registry/capabilities/capability.identity.subject-resolution.md path: registry/capabilities/capability.identity.subject-resolution.md
tags: tags:
- identity - identity
@ -24,7 +24,7 @@ capabilities:
vector: D4 / A0 / C2 / R0 vector: D4 / A0 / C2 / R0
domain: helix_forge domain: helix_forge
status: draft status: draft
owner: identity-canon owner: commerce-canon
path: registry/capabilities/capability.identity.vocabulary-canonicalize.md path: registry/capabilities/capability.identity.vocabulary-canonicalize.md
tags: tags:
- identity - identity

37
workplans/IDENTITY-WP-0004-commerce-rename.md
View file

@ -2,9 +2,9 @@
id: IDENTITY-WP-0004 id: IDENTITY-WP-0004
type: workplan type: workplan
title: "Rename identity-canon to commerce-canon with continuous history" title: "Rename identity-canon to commerce-canon with continuous history"
domain: infotech domain: financials
repo: identity-canon repo: commerce-canon
status: active status: finished
owner: codex owner: codex
topic_slug: canon topic_slug: canon
created: "2026-09-05" created: "2026-09-05"
@ -49,7 +49,7 @@ The snapshot is evidence, not permission to rename a subsequently changed head.
```task ```task
id: IDENTITY-WP-0004-T02 id: IDENTITY-WP-0004-T02
status: progress status: done
priority: high priority: high
state_hub_task_id: "8606bbbb-716d-5011-950e-29dc9ea3c2d8" state_hub_task_id: "8606bbbb-716d-5011-950e-29dc9ea3c2d8"
``` ```
@ -100,7 +100,7 @@ coordinated. No operation journal has been started.
```task ```task
id: IDENTITY-WP-0004-T04 id: IDENTITY-WP-0004-T04
status: progress status: done
priority: high priority: high
state_hub_task_id: "2082388e-2096-5138-a7a6-40c9f71e1fb5" state_hub_task_id: "2082388e-2096-5138-a7a6-40c9f71e1fb5"
``` ```
@ -127,7 +127,7 @@ retain verification evidence and do not delete repository history.
```task ```task
id: IDENTITY-WP-0004-T05 id: IDENTITY-WP-0004-T05
status: wait status: done
priority: medium priority: medium
state_hub_task_id: "c78ce770-3e0c-505d-8eff-538fd305da52" 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 The registered railiance01 checkout is inspected separately; its path will not
be rewritten in State Hub without proving its actual filesystem disposition. be rewritten in State Hub without proving its actual filesystem disposition.
The user renewed instruction to continue once signing was provisioned. 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.