P1: Establish access-controlled private governance overlays

[BunsDev]

Outcome

Extend the public governance contract to private OpenCoven repositories and confidential workstreams without copying private inventory, incidents, prompts, memories, credentials, user data, or unpublished plans into the public OpenCoven/.github repository.

The architecture should remain public canonical policy + federated private implementation evidence + access-controlled derived aggregation. This is not authorization to publish private repository names or to create a competing private source of truth.

Design constraints

• Reuse opencoven.agent-repo/v1 wherever possible; do not fork the ownership/risk vocabulary merely because the repository is private.
• Keep private repository manifests adjacent to their implementation.
• Treat a private Project/catalog/dashboard as a projection, not an authority for component implementation or protected OpenCoven mutations.
• Public initiatives may use opaque capability references such as private-overlay: github-delivery; they must not reveal the backing repository, membership, issue titles, paths, incidents, or evidence.
• Preserve provenance and access-control labels when aggregating records.
• No prompt, task, issue, model output, Project field, or manifest may grant itself protected authority.

Required design

1. Define a private-overlay profile that imports the public schema by exact accepted revision and adds only access-classification/provenance fields that are genuinely private-specific.
2. Select an access-controlled aggregation surface—initially GitHub Projects/API-generated views unless measured scale justifies a service catalog.
3. Define read, propose, and administer identities separately:
   • read-only manifest observer;
   • proposal bot with no repository-administration permission;
   • protected-environment reconciler using a short-lived, narrowly scoped GitHub App token only for reviewed settings plans.
4. Specify data minimization, retention, redaction, stale/degraded state, export, backup, and recovery behavior.
5. Bind every aggregate row to source repository, manifest revision, observation time, and access classification.
6. Add negative tests proving private values cannot flow into public generated files, issue bodies, logs, artifacts, or drift reports.
7. Define how private workstreams attach to public initiatives without creating dangling or falsely complete exit criteria.
8. Document migration away from existing duplicate planning/context surfaces only after source ownership is established.

Threat model

Cover at minimum:

• accidental public disclosure through generated files, workflow logs, issue sync, artifacts, or model summaries;
• a compromised aggregator or GitHub App enumerating or mutating repositories beyond its scope;
• confused-deputy application of caller-supplied repository/permission fields;
• stale private manifests falsely satisfying public initiative criteria;
• access revocation not propagating to cached projections;
• central-service outage or schema drift blocking repository-local work;
• private governance history becoming an unnecessary store of personal or sensitive operational data.

Acceptance criteria

• Private overlay schema/profile is reviewed and remains compatible with the accepted public manifest contract.
• No private repository name or confidential field is required in the public registry.
• Aggregation is read-only by default, provenance-bound, access-controlled, and explicitly stale when source observation expires.
• Public-output leakage tests cover generated files, logs, artifacts, issues, and Projects synchronization.
• Bot/App scopes are minimal and separately documented for observe, propose, and apply paths.
• Any administrative apply path is plan-first, protected-environment gated, exact-state bound, auditable, and fail-closed on moved state.
• Revocation, export, backup, restore, and cache purge are tested.
• Private initiative evidence can be verified by authorized reviewers without being copied publicly.
• Repository-local implementation remains functional when aggregation is unavailable.
• No Backstage/catalog service is introduced without a measured need and a separate architecture decision proving it will remain a projection or safely replace the prior authority.

Sequencing

Depends on review/merge of #7 and the administrative baseline in #6. Pilot only after the public schema has at least two successful canonical repository adopters under #8.