coulomb/prj-canon-federation
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
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

2.3 KiB
Raw Blame History

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.