diff --git a/.custodian-brief.md b/.custodian-brief.md deleted file mode 100644 index 27f6fa8..0000000 --- a/.custodian-brief.md +++ /dev/null @@ -1,27 +0,0 @@ - -# 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 diff --git a/.gitignore b/.gitignore deleted file mode 100644 index e4e0199..0000000 --- a/.gitignore +++ /dev/null @@ -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 diff --git a/.repo-classification.yaml b/.repo-classification.yaml deleted file mode 100644 index 3205797..0000000 --- a/.repo-classification.yaml +++ /dev/null @@ -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. diff --git a/AGENTS.md b/AGENTS.md deleted file mode 100644 index 2f55397..0000000 --- a/AGENTS.md +++ /dev/null @@ -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//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": "", - "task_id": "" - }' -``` - -Omit `workplan_id` / `task_id` when not applicable. - -### Update task status - -```bash -curl -s -X PATCH "http://127.0.0.1:8000/tasks/" \ - -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/" \ - -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: `, 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} - - - - ---- - -## 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-.md` - -**Archived location:** finished workplans may move to -`workplans/archived/YYMMDD-PRJ-WP-NNNN-.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: "" # 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: "" # 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. diff --git a/GOAL.md b/GOAL.md deleted file mode 100644 index d9a3af2..0000000 --- a/GOAL.md +++ /dev/null @@ -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. diff --git a/README.md b/README.md index 0b87fbf..236fbd4 100644 --- a/README.md +++ b/README.md @@ -1,18 +1,3 @@ # prj-canon-federation -Temporary project repository coordinating the split of `identity-canon` into an -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. +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. \ No newline at end of file diff --git a/SCOPE.md b/SCOPE.md deleted file mode 100644 index b5ef6ad..0000000 --- a/SCOPE.md +++ /dev/null @@ -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. diff --git a/history/2026-08-16-genesis.md b/history/2026-08-16-genesis.md deleted file mode 100644 index 799caf3..0000000 --- a/history/2026-08-16-genesis.md +++ /dev/null @@ -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. diff --git a/workplans/CFED-WP-0001-foundation.md b/workplans/CFED-WP-0001-foundation.md deleted file mode 100644 index bd545f7..0000000 --- a/workplans/CFED-WP-0001-foundation.md +++ /dev/null @@ -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.