Scaffold prj-canon-federation per project-repository-flavor v0.1

GOAL.md (8 success gates + retirement conditions), SCOPE.md (authority
boundary, participating repos), README.md, .repo-classification.yaml
(category: project), genesis record, and CFED-WP-0001 foundation workplan
(T01-T10).

Governed by ADR-006 (the-custodian, status: proposed). No canon content
moves before T01 accepts the boundary.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

SCOPE.md

@@ -0,0 +1,51 @@
+# 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.