Design opt-in governance defaults for Base-supported projects #2584

Problem

The accepted Base governance implementation plan assigns this existing issue to package 15. Its previous scope no longer matches the accepted review-loop and automation boundaries, so this issue has been reconciled to a bounded deliverable and remains in Triage/Backlog until independently reviewed.

Expected behavior

Preserve this as deferred Phase 2 work. Determine which first-party rules generalize to Base-supported projects, and define explicit configure/upgrade PRs, preview and rollback. Do not require live inheritance, a governance/ directory or an Agent block. BanyanLabs is included in Phase 1 using the consumer profile; this issue does not change that accepted rollout.

Scope and non-goals

Scope: Preserve this as deferred Phase 2 work. Determine which first-party rules generalize to Base-supported projects, and define explicit configure/upgrade PRs, preview and rollback. Do not require live inheritance, a governance/ directory or an Agent block. BanyanLabs is included in Phase 1 using the consumer profile; this issue does not change that accepted rollout.

Non-goals: Do not use the rejected Agent Assignment/autonomy state machine; do not expand authority or silently change the accepted design; do not activate enforcement or make status/merge changes before the required gates.

Affected areas

• Future Base-supported project configuration and upgrade design.
• Accepted source: governance design and implementation plan, PR #2664
• Parent tracker: #2665

Impact and evidence

1. Product intent: Implements the accepted governance design; no product-requirement change is authorized here.
2. Architecture and contracts: Destination: package 15 of the accepted plan in PR Revise the Base ecosystem governance design and implementation plan #2664, plus the named issue contract.
3. User guidance: Likely destinations: Future Base-supported project configuration and upgrade design.; the implementation PR must name exact paths or provide a change-specific no-impact reason.
4. CLI/API and reference: Update the applicable reference if behavior/commands change; otherwise the implementation PR states why no CLI/API surface is affected.
5. Operations and safety: The scope states its authority boundary and rollback; no merge/release authority is implied.
6. Validation and testing: Validation steps are listed below; the PR records executed evidence and explains unavailable checks.
7. Examples and downstream use: The PR identifies affected examples/consumers or gives a scoped repository search as evidence of no impact.
8. Governance and contributor process: This issue applies the accepted process rule and does not duplicate Project fields in the body.
9. Decision records: No new decision is accepted by this issue; any deviation requires explicit maintainer approval and a superseding record.
10. Release notes: The PR includes a release-note line or a reasoned none; no user-facing release claim is pre-approved here.

These are issue-stage dispositions; refine exact paths and evidence in Triage before Ready. The implementation PR repeats the ten categories against the actual diff.

Open questions

• None beyond the scope-specific gates above. If evidence changes the accepted contract, return to Triage and obtain a separate maintainer decision.

Plan

• S1: One focused PR for this issue. Use Fixes #N if single-PR; if a maintainer approves more than one PR, name slices S1…Sn before opening them and use Part of #N.
• Dependencies: None; this work is explicitly deferred until a separate maintainer decision.
• Acceptance criteria:
• Design is based on evidence from first-party adoption and the manual/deterministic pilot, not assumed portability.
• Defaults are materialized only through an explicit reviewed configure/upgrade PR; no live inheritance occurs.
• Consumer projects are not required to create governance/ or expose internal reviewer settings.
• Preview, owner-controlled overrides, migrations and rollback are explicit before implementation is separately authorized.
• Validation:
• Review first-party adoption evidence and identify rules that required repository-specific changes.
• Validate a sample consumer migration and rollback plan at design stage only.
• Do not add consumer behavior or templates in this issue.
• Risks and rollback: Premature generalization can burden consumers; keep Backlog until Stage B–G evidence is recorded.
• Decision impact: No decision is accepted by implementation alone; record accepted decisions and file a superseding ADR if a change is approved.