Run the manual issue review loop with maintainer escalation #2576

Problem

The accepted Base governance implementation plan assigns this existing issue to package 4. 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

Replace the proposed agent state machine/autonomy levels with the manual issue review loop. Planner completes the one issue contract and named slices in Triage; a fresh-session reviewer evaluates impact evidence, acceptance-to-test mapping, risks and open questions; the author responds; disputes go to the maintainer. Initial evaluation is round one and the separate issue limit is three. A maintainer confirms the current contract fingerprint and sets Ready. No bot status writes or autonomous issue transitions.

Scope and non-goals

Scope: Replace the proposed agent state machine/autonomy levels with the manual issue review loop. Planner completes the one issue contract and named slices in Triage; a fresh-session reviewer evaluates impact evidence, acceptance-to-test mapping, risks and open questions; the author responds; disputes go to the maintainer. Initial evaluation is round one and the separate issue limit is three. A maintainer confirms the current contract fingerprint and sets Ready. No bot status writes or autonomous issue transitions.

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

• docs/github-workflow.md, issue readiness runbook, reviewer rules and issue form.
• 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 4 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: docs/github-workflow.md, issue readiness runbook, reviewer rules and issue form.; 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: #2667, #2680, #2583
• Acceptance criteria:
• The runbook names reviewer inputs, fresh-session boundary, versioned rules and required evidence.
• Each finding has an author response and reviewer verification; disputes and round-limit exhaustion go to the maintainer.
• Round count starts at one and stops after three; unresolved intent never becomes Ready by timeout.
• Readiness includes current Type, impact dispositions, tests, risks and no blocking open question.
• The issue loop is manual and does not use the rejected L0-L3 state machine or mutate Project status automatically.
• Validation:
• Run sample issue scenarios for complete, revised, disputed and limit-exhausted reviews.
• Check the issue fingerprint and Ready decision against a changed Type/contract.
• Review manual status setting and no-bot-write boundary.
• Risks and rollback: Manual review may be inconsistent; use versioned prompts and a baseline, and keep the maintainer as the readiness authority.
• Decision impact: No decision is accepted by implementation alone; record accepted decisions and file a superseding ADR if a change is approved.