Canonical governance
Evolution and applicability
The ecosystem keeps a stable Current Working Version while allowing governed change. Applicability selects the smallest coherent governing set for each task instead of loading every Convention indiscriminately.
GitHub main is the repository SSOT and CWV. The governed
workflow that promotes validated work into main is its SSE —
Single Source of Evolution.
Living evolution
Every promoted change records its semantic status, scope, evidence and evolution datetime. Temporary branches are harvested, verified and then removed so they do not become shadow sources of truth.
Product development traceability
Released product versions and material architectural changes retain a concise, reviewable development history. That history links the Current Working Version to the conversations, XRTs, specifications, architecture decisions, issues, pull requests, validation evidence and releases that materially shaped it.
Git remains the complete technical record. A product history is the
semantic index that explains why the implementation became its current
form. Products may keep one canonical machine-readable source such as
history/history.json and derive README, Pages, App and Lookup
surfaces from it.
Governance levels and default promotion
The authority levels are Global Governance, Repository Governance, Project Governance, and the Task CWV. “Local Governance” is not a level; “local” describes only a physical checkout, filesystem, runtime, or cache.
An operative repository change normally proceeds after validation through
focused commit, branch push, pull request, and permitted integration. The
participant announces this once without stopping for a confirmation.
Reply REVIEW-BEFORE-PUSH to pause before push and
PR-PUSH to resume. LIVE remains separate unless Repository or
Project Governance records a scoped standing deployment authorization.
In that case, NO-LIVE skips only the current task's deployment.
Secrets, destructive history, unrelated targets, and failed-check bypass
remain excluded.
Governance change closure
A governance change is not active merely because it was discussed,
captured in an XRT, documented in one scoped repository file, or implemented in one repository.
Every material governance work cycle must inspect the canonical Ecosystem
sources and end as CANONICALLY PROMOTED,
SCOPED SPECIALIZATION, or
BLOCKED — NOT GOVERNED.
Global changes update the canonical source, applicability routing, bootstraps and agent templates, Guide surfaces, validation, history, and authoritative publication state before completion is claimed.
Source integrity and decision codes
When a task depends on an exact document, the participant distinguishes verified access from text-only extraction, derived web copies, and an inaccessible original. Search snippets, mirrors, product pages, or older documents are never silently presented as the requested source.
User choices receive stable topic-scoped codes such as
PDF-UPLOAD or DEPLOY-WAIT. The user can answer
with the code alone, and delayed replies remain unambiguous even when
several decisions coexist.
Applicability routing
The general foundation always applies. Repository type, component, participant, domain, project and work type activate additional governing sources. Dependencies are resolved before implementation begins.
main govern; this page is their
generated human-facing representation.