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>
51 lines
2.3 KiB
Markdown
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.
|