Adopt the accepted governance profile in base-workspace #19

Problem

The accepted Base governance rollout applies to every active basefoundry repository, but this repository needs its own reviewed adoption train. This repository-local issue pairs changes with a PR in base-workspace and is tracked by the Base governance tracker #2665.

Expected behavior

Apply the accepted profile for base-workspace after the shared contracts and rollout gates are reviewed. Use the first-party ecosystem profile: different-tool reviewer mode, versioned repository governance settings, and optional reviewer rules under governance/. Migrate this repository's existing manifest/config to the reviewed governance: schema without overwriting repository-owned values. Migrate the repository's own GitHub Project when one exists, preserving its local areas and initiatives, and record before/after schema and item counts. Keep human maintainer merge authority, zero required approving reviews during the shared-account pilot, and no automated enforcement before the pinned-check gate.

Scope and non-goals

Scope: One repo-specific adoption PR for configuration, applicable templates/workflows, Project data and reviewer guidance; update this issue's exact affected paths during Triage.

Non-goals: Do not implement governance policy before the issue is Ready; do not copy issue Project fields to PRs; do not add a consumer governance/ directory to base-workspace unless the accepted profile requires it; do not enable auto-merge, agent merge, automated fixes or secret access.

Affected areas

• base-workspace manifest, .github/ configuration/templates/workflows, Project and contributor/agent guidance as present.
• Accepted source: governance design and implementation plan, PR #2664.
• Parent tracker: #2665.
• Relevant shared contracts: issue template #2667, PR template #2669, Project migration #2684.

Impact and evidence

1. Product intent: Implements only the accepted governance profile; no product requirements change.
2. Architecture and contracts: The repository's profile and base_manifest.yaml/Project configuration must match the accepted design and schema.
3. User guidance: Update repository contributor or setup guidance where this repository exposes it; otherwise cite the file inventory and give a no-impact reason.
4. CLI/API and reference: Update any repository-specific command/config reference that mentions governance; if none exists, cite the searched paths.
5. Operations and safety: Record previous branch rules/permissions and preserve the maintainer-only merge boundary.
6. Validation and testing: Verify manifest/schema, template/workflow behavior, Project data and branch policy before and after.
7. Examples and downstream use: Identify examples/consumers in this repo; update them or justify no impact.
8. Governance and contributor process: Apply the selected profile and link to the canonical Base issue/PR contracts.
9. Decision records: No new decision is accepted here; deviations require a separate maintainer-approved record.
10. Release notes: Include a user-facing note or a reasoned none; internal process-only adoption may justify none.

Open questions

• During Triage, inventory actual repo files, linked Project, branch rules, issue forms and any repo-specific exceptions. No issue is Ready while the profile or impact is ambiguous.

Plan

• S1: One focused PR in base-workspace linked to this issue and the Base tracker.
• Dependencies: Base packages 1–11, 16–17 and applicable enforcement gates from #2665; no fixed release date.
• Acceptance criteria:
  • Repo profile, manifest/config and Project options match the accepted design; local values are preserved.
  • Before/after Project counts and branch settings are recorded, or a reasoned no-Project/no-branch-rule disposition is documented.
  • The correct ecosystem/consumer defaults are applied, including the reviewer mode and directory contract.
  • Human maintainer merge and security boundaries remain intact; no ungated automation is activated.
  • Relevant tests/checks/docs are updated, with exact paths and evidence in the PR.
• Validation: Validate the manifest; run repository tests and template/workflow contracts; read back Project and branch settings; run git diff --check.
• Risks and rollback: Repository-specific options may be overwritten by shared defaults. Capture them first and stage the reviewed changes; restore the prior settings/config through a reviewed revert if adoption breaks the repository.
• Decision impact: Record only accepted Base decisions; open a new issue for any repository exception that changes the contract.