prj-canon-federation/SCOPE.md
tegwick 45e7e6d352 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>
2026-08-16 02:39:37 +02:00

51 lines
2.3 KiB
Markdown

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