.custodian-brief.md

@@ -1,27 +0,0 @@
-<!-- custodian-brief: generated by statehub register; fix-consistency may replace this file -->
-# Custodian Brief - prj-canon-federation
-
-**Project:** prj-canon-federation
-**Domain:** infotech
-**State Hub:** http://127.0.0.1:8000
-**Topic ID:** `cee7bedf-2b48-46ef-8601-006474f2ad7a`
-
-## Open Workplans
-
-### Bootstrap State Hub integration
-
-Workplan file: `workplans/PRJ-WP-0001-statehub-bootstrap.md`
-
-Open tasks:
-- T01 - Review generated integration files
-- T02 - Verify local developer workflow
-- T03 - Seed first real workplan
-
-## Session Start
-
-1. Read `GOAL.md`, `SCOPE.md`, and `AGENTS.md` (prj- flavor: `GOAL.md`, no `INTENT.md`).
-2. Check inbox: `GET /messages/?to_agent=prj-canon-federation&unread_only=true`.
-3. Scan `workplans/`.
-4. Update task statuses in workplan files as work progresses.
-
-Last generated: 2026-08-16

.gitignore

@@ -1,5 +0,0 @@
-# state-hub: track .claude/rules
-# Claude Code local state (track shared rules; ignore machine-specific files)
-.claude/*
-!.claude/rules/
-!.claude/rules/*.md

.repo-classification.yaml

@@ -1,29 +0,0 @@
-repo_classification:
-  standard: Repo Classification Standard
-  version: "1.0"
-  classified_at: "2026-08-16"
-  classified_by: human
-  category: project
-  domain: infotech
-  secondary_domains:
-    - financials
-    - government
-  capability_tags:
-    - canon
-    - terminology
-    - governance
-    - identity
-    - documentation
-  business_stake:
-    - technology
-    - intelligence
-    - legal
-  business_mechanics:
-    - intention
-    - coordination
-    - adaptation
-  notes: >-
-    Temporary prj-flavor repository coordinating the identity-canon split:
-    identity to info-tech-canon as itc-ident, commercial content retained in
-    the same repository renamed to commerce-canon. Governed by ADR-006.
-    Archive when GOAL.md retirement gates are met.

AGENTS.md

@@ -1,199 +0,0 @@
-# prj-canon-federation — Agent Instructions
-
-## Repo Identity
-
-**Purpose:** This repository owns the cross-repository goal, concept-ownership boundary, sequencing, dependency map, migration ledger, risks, acceptance gates, and consolidated evidence for the canon federation effort.
-
-**Domain:** infotech
-**Repo slug:** prj-canon-federation
-**Topic ID:** `cee7bedf-2b48-46ef-8601-006474f2ad7a`
-**Workplan prefix:** `PRJ-WP-`
-
----
-
-## State Hub Integration
-
-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 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.
-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`.
-
-### Orient at session start
-
-```bash
-# Offline brief — works without hub connection
-cat .custodian-brief.md
-
-# Active workplans for this domain
-curl -s "http://127.0.0.1:8000/workplans/?topic_id=cee7bedf-2b48-46ef-8601-006474f2ad7a&status=active" \
-  | python3 -m json.tool
-
-# Check inbox
-curl -s "http://127.0.0.1:8000/messages/?to_agent=prj-canon-federation&unread_only=true" \
-  | python3 -m json.tool
-```
-
-Mark a message read:
-```bash
-curl -s -X PATCH "http://127.0.0.1:8000/messages/<id>/read" \
-  -H "Content-Type: application/json" -d '{}'
-```
-
-### Log progress (required at session close)
-
-```bash
-curl -s -X POST http://127.0.0.1:8000/progress/ \
-  -H "Content-Type: application/json" \
-  -d '{
-    "summary": "what was done",
-    "event_type": "note",
-    "author": "codex",
-    "workplan_id": "<uuid>",
-    "task_id": "<uuid>"
-  }'
-```
-
-Omit `workplan_id` / `task_id` when not applicable.
-
-### Update task status
-
-```bash
-curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
-  -H "Content-Type: application/json" \
-  -d '{"status": "progress"}'
-# values: wait | todo | progress | done | cancel
-```
-
-### Flag a task for human review
-
-```bash
-curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
-  -H "Content-Type: application/json" \
-  -d '{"needs_human": true, "intervention_note": "reason"}'
-```
-
----
-
-## Session Protocol
-
-**Start:**
-1. `cat .custodian-brief.md` — domain goal and open workplans (offline-safe)
-2. Check inbox: `GET /messages/?to_agent=prj-canon-federation&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`
-
-**During work:**
-- Update task statuses in workplan files as tasks progress
-- Record significant decisions via `POST /decisions/`
-
-**Close:**
-1. Update workplan file task statuses to reflect progress
-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
-   ```
-   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.
-
----
-
-{CREDENTIAL_ROUTING}
-
-<!-- REPO-AGENTS-EXTENSIONS -->
-<!-- Append repo-specific agent instructions below this marker.
-     The state-hub template sync preserves content after this line. -->
-
----
-
-## Workplan Convention (ADR-001)
-
-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/PRJ-WP-NNNN-<slug>.md`
-
-**Archived location:** finished workplans may move to
-`workplans/archived/YYMMDD-PRJ-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
-`workplans/ADHOC-YYYY-MM-DD.md` with task ids `ADHOC-YYYY-MM-DD-T01`, etc. Use
-this only for low-risk work completed directly; create a normal workplan for
-anything needing analysis, design, approval, dependencies, or multiple phases.
-
-**Frontmatter:**
-
-```yaml
----
-id: PRJ-WP-NNNN
-type: workplan
-title: "..."
-domain: infotech
-repo: prj-canon-federation
-status: proposed | ready | active | blocked | backlog | finished | archived
-owner: codex
-topic_slug: ...
-created: "YYYY-MM-DD"
-updated: "YYYY-MM-DD"
-state_hub_workstream_id: "<uuid>"   # fix-consistency — do not edit (legacy field name; workplan UUID)
----
-```
-
-Use `proposed` for a new draft, `ready` after review against current repo
-state, and `finished` after implementation. `stalled` and `needs_review` are
-derived health labels, not frontmatter statuses.
-
-**Terminology:** workplan is the fleet term; `workstream` appears only in legacy
-API/MCP/frontmatter bridges until `STATE-WP-0069` retires them — see
-`the-custodian/canon/standards/workplan-terminology-fleet_v0.1.md`.
-
-**Task block format** (one per `##` section):
-
-```
-## Task Title
-
-` ` `task
-id: PRJ-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
-` ` `
-
-Task description text.
-```
-
-Status progression: `todo` → `progress` → `done`; use `wait` for waiting/blocked work and `cancel` for stopped work.
-
-**Residuals when finishing:** actionable leftovers become live work records
-before `status: finished` — usually an intake (`origin: residual`,
-`origin_ref: PRJ-WP-NNNN`) or a spawned workplan. Residual is a *role*,
-not a kind. Fleet list lives on State Hub, not in `SCOPE.md`.
-
-To create a new workplan:
-1. Write the file following the format above
-2. Run `statehub fix-consistency` locally; ask the operator only if the CLI or
-   State Hub API is unavailable.

GOAL.md

@@ -1,106 +0,0 @@
----
-repo: prj-canon-federation
-repo_flavor: project
-project_status: draft
-started: "2026-08-16"
-reviewed: "2026-08-16"
----
-
-# Project goal
-
-## Outcome
-
-Establish a federated canon architecture in which every canonical concept has
-exactly one owner, and no two canons define the same concept.
-
-The project will:
-
-1. accept `ADR-006` (canon federation and concept ownership) and resolve its six
-   open ownership collisions;
-2. rename `identity-canon` to `commerce-canon` in place, retaining git history,
-   State Hub registration, and finished `IDENTITY-WP-*` workplans as provenance
-   for the commercial content that stays;
-3. land identity as an InfoTechCanon model (`itc-ident`), importing rather than
-   redefining `itc-org` and `itc-access` concepts, filling the gap
-   `InfoTechCanonAccessControlModel.md:214` explicitly declines;
-4. bring `commerce-canon` up to the `InfoTechCanonRepositoryLayoutStandard`
-   structure (`canon.yaml`, `infospace/` with kernel/models/standards,
-   `assimilation/`, `mappings/`, `profiles/`);
-5. distribute the identity-canon research corpus as provenance into whichever
-   canon inherits the concepts it supports;
-6. publish cross-canon interface cards so the three canons reference each other
-   explicitly; and
-7. leave no dangling `identity-canon` references anywhere in the fleet.
-
-## Invariants
-
-- **One owner per concept.** No concept is defined by two canons. Downstream
-  canons import; they never redefine.
-- **Custodian canon stays normative.** Ecosystem governance (constitution,
-  values, standards, ADRs) remains in `the-custodian/canon/`; the domain canons
-  hold semantics, not ecosystem policy.
-- **Rename, do not re-found.** `identity-canon` keeps its git history, hub
-  registration, `.repo-classification.yaml` lineage, and finished workplans.
-  Nothing is archived or deleted.
-- **Canon changes are review-gated.** Content moves only after `ADR-006` is
-  `accepted`; each canon's own review gate still applies to its own content.
-- **This repo hosts no canon content.** It coordinates. Concepts live in
-  `info-tech-canon` and `commerce-canon`; decisions promote to Custodian canon.
-- **CommerceCanon grows by demand signal.** New content enters through a demand
-  signal with named consumer evidence, as InfoTechCanon already does. No
-  speculative authoring.
-- **No content is lost in transit.** Every concept present in
-  `identity-canon/canon/CanonicalGlossary.md` at project start is accounted for
-  at project end — moved, imported, or explicitly retired with rationale.
-
-## Success gates
-
-Each gate needs accepted evidence before the project may move to `completed`.
-
-**G1 — Boundary accepted.** `ADR-006` status is `accepted` in Custodian canon,
-with all six open questions resolved and recorded.
-
-**G2 — Ownership ledger complete.** A machine-readable ledger maps every concept
-from the project-start glossary to exactly one owning canon and model. A
-validation pass reports zero concepts with zero owners and zero with two.
-
-**G3 — Rename landed.** `commerce-canon` exists as the renamed repository: forge
-remote, local path, hub repo slug, `.repo-classification.yaml`, and agent
-instructions all updated; git history continuous across the rename.
-
-**G4 — Identity model published.** `itc-ident` exists at
-`info-tech-canon/infospace/models/identity/`, is registered in `canon.yaml`,
-appears in the kernel map, and defines no concept owned by `itc-org` or
-`itc-access`.
-
-**G5 — Commerce canon conforms.** `commerce-canon` satisfies
-`InfoTechCanonRepositoryLayoutStandard`, carries `canon.yaml`, and holds the
-counterparty/commercial model with declared ownership.
-
-**G6 — Corpus preserved.** The `research/`, `terminology/`, and `scenarios/`
-material is present as provenance in the canon that inherited the concepts it
-supports, reachable from that canon's `assimilation/`.
-
-**G7 — Canons cross-reference.** Each canon publishes an interface card naming
-what it imports from and exports to the others. The zero-cross-reference
-condition that motivated this project no longer holds.
-
-**G8 — No dangling references.** A fleet sweep finds no live reference to
-`identity-canon` outside deliberate historical provenance.
-
-## Project retirement
-
-This repository may be archived when:
-
-1. all eight success gates have accepted evidence;
-2. residuals are live work records owned outside this repository (per
-   `work-record-types_v0.1.md` § Residuals) — in particular any deferred
-   consumer adoption by `fin-hub`, `target-revenue`, `adaptive-pricing`, or
-   `qonto-assistant`, which are explicitly *not* gates of this project;
-3. durable decisions are promoted to permanent homes — `ADR-006` in Custodian
-   canon, ownership boundaries in each canon's own kernel documents;
-4. the completion record is written to `history/`; and
-5. a final consistency and link check passes.
-
-Ongoing canon evolution is explicitly **not** a retirement blocker. This project
-ends when the federation exists and is correct, not when the canons are finished.

README.md

@@ -1,18 +1,3 @@
 # prj-canon-federation
 
-Temporary project repository coordinating the split of `identity-canon` into an
+Cross-repo workplan to fold identity from identity-canon to infotech-canon and then renaming it to commerce-canon and build out our commercial canonical knowledge model from there.
-InfoTechCanon identity model and a renamed `commerce-canon`, so that every
-canonical concept in the ecosystem has exactly one owner.
-
-The project is governed by [GOAL.md](GOAL.md). Its background, boundaries, and
-first delivery plan are recorded in
-[history/2026-08-16-genesis.md](history/2026-08-16-genesis.md),
-[SCOPE.md](SCOPE.md), and
-[CFED-WP-0001](workplans/CFED-WP-0001-foundation.md).
-
-The governing decision is
-[ADR-006](../the-custodian/canon/architecture/adr-006-canon-federation-concept-ownership.md)
-in the Custodian canon (status: `proposed` — content moves only once accepted).
-
-This repository holds no canon content. It is designed to be retired when the
-goal and retirement gates in `GOAL.md` are satisfied.

SCOPE.md

@@ -1,51 +0,0 @@
-# Scope
-
-## Project authority
-
-This repository owns the cross-repository goal, concept-ownership boundary,
-sequencing, dependency map, migration ledger, risks, acceptance gates, and
-consolidated evidence for the canon federation effort.
-
-It does not own canon content. Concepts live in the canons themselves.
-
-## Participating repositories
-
-- `the-custodian` — `ADR-006`; durable decisions and standards
-- `info-tech-canon` — receives the identity model (`itc-ident`)
-- `identity-canon` → `commerce-canon` — renamed in place; retains commercial content
-- `state-hub` — repo slug rename, registration, agent-instruction regeneration
-
-Downstream consumers (`fin-hub`, `target-revenue`, `adaptive-pricing`,
-`qonto-assistant`) are **not** participants. They may pull from CommerceCanon
-later via demand signal; their adoption is not a gate of this project.
-
-## In scope
-
-- Concept-ownership boundary across Custodian canon, InfoTechCanon, CommerceCanon.
-- Resolution of the six ownership collisions listed in `ADR-006`.
-- The `identity-canon` → `commerce-canon` rename and all fleet references to it.
-- Landing `itc-ident` in InfoTechCanon with imports, not redefinitions.
-- Bringing CommerceCanon to `InfoTechCanonRepositoryLayoutStandard` structure.
-- Distributing the research corpus as provenance.
-- Cross-canon interface cards.
-
-## Out of scope
-
-- Hosting canon content in this repository.
-- Authoring new commercial concepts beyond what already exists in the glossary.
-  CommerceCanon grows by demand signal after the federation is in place.
-- Building CommerceCanon's service surface (CLI/JSON/API). InfoTechCanon has one;
-  whether CommerceCanon needs one is a later, evidence-driven decision.
-- Moving the Federated Organization Standard out of Custodian canon.
-- Extending `itc-org` with social collectives (`Community`, `Family Or
-  Household`) beyond recording the recommendation — that is an InfoTechCanon
-  workplan if adopted.
-- Consumer adoption of either canon.
-- Retiring or deleting any repository.
-
-## Work-record rule
-
-This project records milestones, dependencies, gates, decisions, and cross-repo
-acceptance. Each participating repository owns its own implementation workplan
-and evidence. Project records link those workplans by stable identifier rather
-than copying their task lists.

history/2026-08-16-genesis.md

@@ -1,83 +0,0 @@
-# Genesis — 2026-08-16
-
-## Why this project exists
-
-The ecosystem was running two independent canons in the same market domain
-(`infotech`) with **no cross-reference in either direction**:
-
-- `info-tech-canon` — InfoTechCanon v0.6.0, `service-baseline`. Kernel, 12
-  models, 3 standards, declared per-model concept ownership, an orthogonality
-  rule ("standards can import but not redefine each other"), and a live
-  CLI/JSON/API surface on `infospace-bench`.
-- `identity-canon` — documentation-only research repo. Three `IDENTITY-WP-*`
-  workplans, all `finished`; no substantive work since the commercial-identity
-  research pass. ~60 concepts in `canon/CanonicalGlossary.md`.
-
-Three findings drove the decision.
-
-**Concept-ownership collision.** `InfoTechCanonOrganizationModel:55` owns
-`Actor, Person, Organization, Group, Role, Membership, ...`;
-`InfoTechCanonAccessControlModel:106` owns `Subject, Principal, ...`.
-identity-canon independently defined all of them. Precisely what InfoTechCanon's
-orthogonality rule exists to prevent.
-
-**An unowned gap.** `InfoTechCanonAccessControlModel:214` explicitly pushes
-identity provisioning, authentication, identity proofing, and account lifecycle
-out of scope, and `:41` does the same for generic organization modelling. So
-`Account`, `Identity Record`, `Identifier`, `Credential`, `Claim`, `Persona`,
-`Tenant`, `Realm`, `Synonymity Assertion` belonged to no model at all.
-
-**Commercial semantics accumulating in technical canon.** About a third of
-identity-canon's glossary is counterparty/commercial modelling, not identity —
-hence its `government` secondary domain. Independently,
-`info-tech-canon/demand/CapabilityProvisionEconomics.md` (accepted 2026-08-15)
-records procurement and economics demand arriving in `ITC-CAP` from consumer
-`resource-control`, domain `financials`. Two unrelated donors pushing commercial
-semantics into a technical canon is a domain boundary, not a coincidence.
-InfoTechCanon's own Purpose/Demand extension names this `ScopePressure`.
-
-## What was decided
-
-`ADR-006` (Custodian canon, status `proposed` at genesis): three federated
-canons — Custodian (ecosystem governance), InfoTech (information-processing
-semantics), Commerce (counterparty and commercial semantics) — importing but
-never redefining each other.
-
-Two shaping choices are worth recording, because both were revisions of an
-earlier plan:
-
-**Rename in place, don't found-and-archive.** The first proposal was to create a
-new `commerce-canon` repo and archive `identity-canon`. Renaming instead keeps
-git history, hub registration, `.repo-classification.yaml` lineage, and the
-three finished workplans attached to the commercial content that *stays*. Only
-identity emigrates. One repo changes name, one gains a model, nothing is
-archived.
-
-**Name it for commerce, not for "business terms".** The working name was
-`business-terms-canon`. "Terms" advertises a glossary, and an open-ended
-glossary is the failure mode — it invites every business-flavoured word in the
-ecosystem to land there with no ownership discipline. The real content is
-counterparty and commercial-relationship semantics with a KYC/AML/procurement
-driver, so the canon is named for that.
-
-## What the boundary rests on
-
-Two of the collisions were resolved by identity-canon's *own* design principles
-rather than by new argument: P1 ("Use Actor As The Participation Root") requires
-importing `itc-org`'s `Actor`; P6 ("Keep Authorization Projections Separate")
-already treats `Authenticated Subject` / `Authorization Principal` as
-projections rather than identity-owned definitions. The boundary largely wrote
-itself from principles already agreed inside the research repo.
-
-Six collisions were **not** resolved at genesis and are listed as open questions
-in `ADR-006` — `Scope`, `Assurance Level`, `Evidence Source`, `Relationship
-Tuple`, `Adjudication Outcome`, and the placement of `Community` / `Family Or
-Household`. Resolving them is the first task of `CFED-WP-0001`.
-
-## Risk being managed
-
-CommerceCanon could repeat identity-canon's failure mode: dormant, zero
-consumers, drifting. Two mitigations are built into the design — it launches
-holding real research-backed content rather than as an empty scaffold, and it
-grows only by demand signal with named consumer evidence, the mechanism
-InfoTechCanon already runs.

workplans/CFED-WP-0001-foundation.md

@@ -1,227 +0,0 @@
----
-id: CFED-WP-0001
-type: workplan
-title: "Canon federation foundation: boundary, rename, and model placement"
-domain: infotech
-repo: prj-canon-federation
-status: ready
-owner: codex
-topic_slug: canon-federation
-created: "2026-08-16"
-updated: "2026-08-16"
----
-
-# Canon federation foundation: boundary, rename, and model placement
-
-## Goal
-
-Establish the concept-ownership boundary, then execute the `identity-canon`
-split: identity to InfoTechCanon as `itc-ident`, commercial content retained in
-the same repository renamed to `commerce-canon`. Every concept ends with exactly
-one owner.
-
-Governed by `ADR-006` in the Custodian canon. No content moves before T01.
-
-## Resolve the boundary and accept ADR-006
-
-```task
-id: CFED-WP-0001-T01
-status: todo
-priority: high
-```
-
-Resolve the six open ownership questions in `ADR-006` and move it to `accepted`.
-This is a human review gate — every later task depends on it.
-
-1. `Scope` — `itc-ident` or `itc-access`? identity-canon P3 makes it
-   first-class; `itc-access` uses "access scope" throughout.
-2. `Assurance Level` vs `itc-gov` `Assurance` — specialization or distinct
-   concept? `Counterparty Assurance Gradient` builds on whichever wins.
-3. `Evidence Source` vs `itc-gov` `Evidence` — likely an `itc-gov`
-   specialization rather than identity-owned.
-4. `Relationship Tuple` — reads as a Zanzibar/OpenFGA-style authorization
-   primitive, so plausibly `itc-access` rather than `itc-ident`.
-5. `Adjudication Outcome` — three candidate owners: `itc-access`
-   `AuthorizationDecision`, `itc-gov` `Decision`, or commerce.
-6. `Community` / `Family Or Household` — absent from `itc-org`, which covers
-   enterprise structures only. Recommendation is to extend `itc-org` rather than
-   place them in `itc-ident`; confirm or overrule.
-
-Record each resolution with rationale in `ADR-006`, then set its status to
-`accepted`.
-
-## Build the concept-ownership ledger
-
-```task
-id: CFED-WP-0001-T02
-status: wait
-priority: high
-```
-
-Produce a machine-readable ledger under `ledger/` mapping every concept in
-`identity-canon/canon/CanonicalGlossary.md` (as of project start) to exactly one
-owning canon and model, with disposition: `import` (defined upstream, referenced
-here), `own` (moves and stays owned), or `retire` (dropped, with rationale).
-
-Include a validation pass that reports concepts with zero owners and concepts
-with two. Zero of both is gate **G2**.
-
-This ledger is the migration's source of truth — T05 and T06 execute from it
-rather than from prose.
-
-## Rename identity-canon to commerce-canon
-
-```task
-id: CFED-WP-0001-T03
-status: wait
-priority: high
-```
-
-Rename the repository in place, preserving git history:
-
-- forge repo rename on Forgejo (`coulomb/identity-canon` → `coulomb/commerce-canon`);
-- local directory and every git remote;
-- State Hub repo slug and registered local path (`make register-path`);
-- `.repo-classification.yaml` — slug, `domain` (revisit `infotech` → likely
-  `financials` with `government` secondary), capability tags;
-- regenerate agent instructions (`make update-agent-instructions`);
-- `GOAL.md`/`INTENT.md`, `SCOPE.md`, `README.md`, `AGENTS.md` prose;
-- workplan prefix decision: keep finished `IDENTITY-WP-*` files unchanged as
-  provenance, use a commerce prefix for new plans.
-
-Add a migration note to `history/` in the renamed repo per the `prj-` standard's
-slug-rename rule.
-
-## Scaffold commerce-canon to the canon layout standard
-
-```task
-id: CFED-WP-0001-T04
-status: wait
-priority: medium
-```
-
-Bring the renamed repository up to `InfoTechCanonRepositoryLayoutStandard`:
-`canon.yaml` (repository, title, status, version, classification, kernel/models/
-standards registries) and an `infospace/` tree with `kernel/`, `models/`,
-`standards/`, `assimilation/`, `mappings/`, `concepts/`, `profiles/`,
-`patterns/`, `validation/`.
-
-Write the CommerceCanon kernel document, including the ownership boundary
-against `itc-org`, `itc-gov`, and `itc-ident` — specifically `Organization`,
-`Ownership`, `Obligation`, `Decision`, `Evidence`, and `Assurance`, which are
-already owned upstream.
-
-Do **not** build a service surface. Whether CommerceCanon needs CLI/JSON/API is
-a later evidence-driven decision (`SCOPE.md`, out of scope).
-
-## Land the identity model in InfoTechCanon
-
-```task
-id: CFED-WP-0001-T05
-status: wait
-priority: high
-```
-
-Create `info-tech-canon/infospace/models/identity/InfoTechCanonIdentityModel.md`
-(`itc-ident`) from the ledger:
-
-- owned concepts per `ADR-006` decision 4 plus T01 resolutions;
-- imports declared explicitly — `Actor`, `Person`, `Agent`, `Organization`,
-  `Group`, `Role`, `Membership` from `itc-org`; `Subject`, `Principal` from
-  `itc-access`;
-- carry over identity-canon's design principles P1–P13 where they survive the
-  boundary, dropping those that only made sense in a standalone canon;
-- register in `canon.yaml` under `models:` and add to the kernel map;
-- update `InfoTechCanonAccessControlModel:214` so the identity boundary now
-  points at `itc-ident` instead of declaring the area unowned.
-
-Verification for gate **G4**: `itc-ident` defines no concept owned by `itc-org`
-or `itc-access`.
-
-## Land the counterparty model in CommerceCanon
-
-```task
-id: CFED-WP-0001-T06
-status: wait
-priority: high
-```
-
-Create the counterparty/commercial model in `commerce-canon` from the ledger's
-`own` entries — `Legal Entity`, `Legal Person`, `Beneficial Owner` and its
-relationship/exemption concepts, `Customer`, `Vendor`, `Commercial
-Relationship`, `Commercial Commitment`, `Payment Instrument Reference`, `Payment
-Mandate`, `Pipeline Pursuit`, `Commercial Record`, `Counterparty Assurance
-Gradient`, `Reputation Signal`, `Performance Evidence`, `Adjudication Outcome`,
-`Registry Identifier`, `Proxy Commercial Identifier`.
-
-Model identifier subtypes as the worked example of the import pattern:
-`itc-ident` owns `Identifier`; CommerceCanon owns `Registry Identifier` and
-`Proxy Commercial Identifier` as specializations of it.
-
-Carry over design principles P14 ("Separate Commercial Records From Accounts")
-and P15 ("Model Commercial Binding Explicitly"), which are commerce-side.
-
-## Distribute the research corpus as provenance
-
-```task
-id: CFED-WP-0001-T07
-status: wait
-priority: medium
-```
-
-Route `research/` (8 subject areas + `CorpusIndex.md`), `terminology/`
-(`TerminologyInventory.md`, `TerminologyConflictMap.md`), and `scenarios/
-ScenarioTests.md` into the `assimilation/` tree of whichever canon inherited the
-concepts each supports. Split where a corpus area serves both.
-
-Preserve provenance — this is research that already ran; it is not re-derived.
-Record the disposition so gate **G6** is checkable.
-
-## Publish cross-canon interface cards
-
-```task
-id: CFED-WP-0001-T08
-status: wait
-priority: medium
-```
-
-Each canon publishes a Canon Interface Card naming what it imports from and
-exports to the others, per `InfoTechCanonCore`'s interface-card mechanism.
-Add the reciprocal references so the zero-cross-reference condition that
-motivated this project no longer holds (gate **G7**).
-
-Include Custodian canon in the map — it governs both domain canons and holds
-`ADR-006`, but owns no domain semantics.
-
-## Sweep fleet references
-
-```task
-id: CFED-WP-0001-T09
-status: wait
-priority: medium
-```
-
-Find and fix every live reference to `identity-canon` across the fleet: repo
-docs, hub records, MCP registrations, `.custodian-brief.md` files, capability
-registries, and `reuse-surface` entries. Deliberate historical provenance
-(genesis notes, completion records, finished workplans) stays.
-
-Gate **G8** is a clean sweep.
-
-## Record open residuals
-
-```task
-id: CFED-WP-0001-T10
-status: wait
-priority: low
-```
-
-Before this workplan is set to `finished`, every actionable leftover becomes a
-live work record outside this repository, per `work-record-types_v0.1.md`
-§ Residuals. Expected residuals:
-
-- `itc-org` extension for social collectives (`Community`, `Family Or
-  Household`), if T01 confirms the recommendation — an InfoTechCanon workplan;
-- CommerceCanon service-surface decision, if demand appears;
-- consumer adoption by `fin-hub`, `target-revenue`, `adaptive-pricing`,
-  `qonto-assistant` — demand-signal driven, explicitly not a gate here.