P1: Establish repository-creation and public-graduation gate

[BunsDev]

Outcome

Operationalize the rule that a new OpenCoven repository, service, schema, database, control plane, or public package must demonstrate a distinct canonical boundary before creation or graduation.

Required proposal record

Every proposal must state:

• the user/product/protocol outcome;
• existing canonical components evaluated and why they cannot own the work;
• proposed canonicality and explicit non-ownership boundaries;
• owner, technical DRI, backup/succession plan, lifecycle, risk class, visibility, license, security support, and data classification;
• produced and consumed contracts, versioning, immutable pins, migration, rollback, archival, and package/release plan;
• bootstrap, fast/full verification, protected paths, network/secret/side-effect policy, and evidence format;
• 30/90-day graduation or retirement criteria;
• expected effect on portfolio surface and duplicate-ownership risk.

Procedure

1. Start as an issue or initiative proposal; no repository metadata grants implementation authority.
2. Obtain the relevant canonical-domain owner review.
3. Prefer a branch, directory, package, or private incubator inside an existing owner when that is sufficient.
4. If a repository is approved, create it with least privilege and truthful status, then add its manifest and registry entry in one reviewed sequence.
5. Do not make an incubator public until clean-clone verification, security policy, license/provenance, ownership, release status, and R3/R4 protections are evidenced.
6. Fail closed on an ownership conflict and record a supersession/migration decision rather than allowing two canonical claims.

Acceptance criteria

• Proposal and graduation issue forms exist and are schema-backed where practical.
• The governance validator rejects a public repository absent from the current registry.
• A dry-run exercise covers an approved repository, a rejected duplicate control plane, and an incubator that fails graduation.
• Organization repository-creation permissions are reviewed under P0 admin gate: protect the governance plane and install least-privilege organization controls #6.
• No automation can create, publish, transfer, archive, privatize, or delete a repository without explicit authorization and current-state binding.
• Ownership changes preserve historical provenance and effective date.
• The process remains lightweight for R0/R1 supporting repositories and stricter for R3/R4 boundaries.

The gate is intended to prevent architecture drift, not to centralize all implementation in .github or force a monorepo.