Adopt the accepted governance profile in the Base repository #2684

Problem

The accepted Base governance design and implementation plan identify package 12/base as a required deliverable. This issue translates that package into a reviewed, bounded issue/PR train; it does not authorize implementation before the issue reaches Ready.

Expected behavior

Apply the accepted governance profile to basefoundry/base after shared contracts and policy gates are reviewed. Migrate the Base Project values, repository manifest settings, templates/workflows and reviewer rules that are explicitly in the Stage G profile. Record before/after Project and branch-protection state. This issue does not duplicate the package issues' implementation; it verifies Base's end-to-end adoption and records any remaining gaps as separate issues.

Scope and non-goals

Scope: Apply the accepted governance profile to basefoundry/base after shared contracts and policy gates are reviewed. Migrate the Base Project values, repository manifest settings, templates/workflows and reviewer rules that are explicitly in the Stage G profile. Record before/after Project and branch-protection state. This issue does not duplicate the package issues' implementation; it verifies Base's end-to-end adoption and records any remaining gaps as separate issues.

Non-goals: Do not silently expand scope, activate unreviewed policy, mirror issue fields onto PRs, grant agents merge/release authority, or make changes outside the named affected areas. Any new product decision or materially new work gets a separate issue and decision record.

Affected areas

• Base manifest, .github/ policy/templates, Base Project, AGENTS.md/METHOD.md and docs governance.
• Accepted source: governance design and implementation plan, PR #2664
• Parent tracker: #2665

Impact and evidence

1. Product intent: Implements only the accepted governance design and plan; any product-requirement change must be filed separately.
2. Architecture and contracts: Destination is the package-specific section of the merged governance design/implementation plan plus the affected canonical contract named above.
3. User guidance: The issue identifies likely guidance paths; the implementation PR must name updated user/FAQ/README paths or give a change-specific reason why none is affected.
4. CLI/API and reference: The affected-area list determines whether CLI/API/reference docs change; the implementation PR must cite the exact reference path or justify no impact.
5. Operations and safety: No privileged automation or merge authority is implied; the PR must list operational/security effects and any rollback.
6. Validation and testing: The issue lists the planned tests; the PR must report executed validation and explain any unavailable test.
7. Examples and downstream use: The implementation PR must identify affected examples/consumers or give evidence that this change has no downstream surface.
8. Governance and contributor process: This package changes or preserves the contributor/governance contract as described in Scope; links must point to the canonical rules.
9. Decision records: No new decision is accepted by this issue; any durable deviation requires a proposed decision record and explicit maintainer acceptance.
10. Release notes: The PR must include a user-facing release-note line or a reasoned none; this issue does not pre-decide that disposition.

These are issue-stage dispositions to refine during Triage. Before Ready, every category must have its exact destination or evidence-based no-impact reason; the PR repeats the ten-category evidence for actual changes.

Open questions

• None known. If implementation exposes an unresolved contract, return this issue to Triage and record the decision before implementation continues.

Plan

• S1: One focused PR for this issue. Use Fixes #N only if no additional slice is needed; if the maintainer approves multiple PRs, name each S1…Sn here before the first is opened and use Part of #N.
• Dependencies: the P2 issue, the P3b issue, the P5a issue, the P6 issue, the P8a issue, the P9 issue, the P16a issue, the P16b issue, the P17 issue, the P19 issue, the P20 issue
• Acceptance criteria:
• Base repository manifest and Project match the accepted ecosystem profile and shared schema.
• Before/after Project counts, options, branch rules and profile values are recorded and independently read back.
• No agent merge rights, approval requirement, silent Project-value deletion or stale governance instructions remain.
• The Base-specific issue and PR templates, checks and reviewer rules are exercised on a representative issue/PR train.
• Uncovered needs are filed as separate issues rather than expanding this rollout silently.
• Validation:
• Run Base Project doctor and configuration checks; inspect live values and representative issue fields.
• Run the governance contract suite and dry-run checks against the Base repo.
• Verify branch protection and current title inventory before/after.
• Risks and rollback: Rollout may expose a profile mismatch; stage changes per reviewed PR and restore prior values/settings through explicit reviewed rollback.
• Decision impact: No decision is accepted merely by implementing the issue. Record the relevant accepted decision/ADR and file a superseding record if the maintainer approves a change.