Repository Development · CI-0013

Repository Ecosystem Binding

Workbench, implementation, and consumer repositories develop independently while remaining canonically bound to the applicable global and Component-specific 2HE rules.

Authority chain

2HEGov→Repository Governance→Project Governance→Local implementation→Verified workspace

What stays where?

Canonical in Ecosystem

Shared meaning, global Conventions, Standards, Specifications, Component governance, and reusable evolution remain in 2HE__Ecosystem.

Local in repository

Code, configuration, architecture, implementation instructions, build and test procedures, project status, next work, and binding references remain with the implementation.

Never autonomous

Repository- and project-specific rules may supplement applicable canonical governance but may not silently redefine or contradict it.

Governance levels

Use Global Governance, Repository Governance, Project Governance, and Task CWV. “Local Governance” is not an authority level; “local” describes only a physical checkout, filesystem, runtime, or cache.

New participant bootstrap

  1. Read the repository README, agent instructions, and root Repository_Governance.md.
  2. Activate Universal, Repo, and—when an evidenced project is in scope—Project Bootstrap.
  3. Resolve repository type, Component, artifact, project, or domain.
  4. Read applicable Ecosystem and Component sources, then every scoped Project_Governance.md from broadest to most specific.
  5. Read current architecture, implementation state, open work, next direction, and the verified public workspace when available.
  6. Inspect Git state, then continue and improve the existing system.
Continuity rule: do not copy shared governance into every repository and do not restart the architecture from chat memory. Resolve the current canonical sources and the current local implementation state.