Migrate the shared Project schema and Base Project values #2672

Problem

The accepted Base governance design and implementation plan identify package 8 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

Update project_model.py, the Project template and gh project configure for the accepted metadata contract. Keep native Type values Task/Bug/Feature; migrate Priority P0→P1, P1→P2, P2→P3, P3→P4; add a Low/Medium/High Risk tier; reorder/redefine Status so Triage follows Backlog; record before/after Base Project counts. Do not delete existing values or change issue/PR relationships. Repository-specific Projects are migrated by their Stage G adoption issues. Resolve O10's community-triage decision before changing public contributor guidance.

Scope and non-goals

Scope: Update project_model.py, the Project template and gh project configure for the accepted metadata contract. Keep native Type values Task/Bug/Feature; migrate Priority P0→P1, P1→P2, P2→P3, P3→P4; add a Low/Medium/High Risk tier; reorder/redefine Status so Triage follows Backlog; record before/after Base Project counts. Do not delete existing values or change issue/PR relationships. Repository-specific Projects are migrated by their Stage G adoption issues. Resolve O10's community-triage decision before changing public contributor guidance.

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

• cli/python/base_github_projects/project_model.py, base-project-template, basectl gh project configure, Base Project data, docs/github-workflow.md.
• 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 P1 issue, the O10 issue
• Acceptance criteria:
• Shared defaults and the Base Project expose P1–P4, Risk tier Low/Medium/High, and accepted status order/meaning.
• Base Project before/after counts prove each priority migration and risk assignment; no issue is lost or assigned an unsupported value.
• gh project configure and the base-project-template agree with project_model.py and preserve repo-specific areas/initiatives.
• Current native issue types remain Task/Bug/Feature unless a separate decision is accepted.
• docs/github-workflow.md explains the internal status migration and links the separate community-triage decision without silently rewriting public community guidance.
• Validation:
• Add schema/configuration tests for new options and extension preservation.
• Capture Base Project counts before and after migration and read back representative items.
• Run Project doctor/configure dry-run and targeted project tests.
• Risks and rollback: Priority remapping changes urgency semantics; inventory before writing, retain old values where GitHub requires them, and roll back through a reviewed reverse migration rather than deleting options.
• 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.