Validate pull request impact, acceptance and release-note evidence #2572

Problem

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

Rescope the PR-body checker to the accepted PR template: linked issue and declared slice, plan/acceptance trace, validation evidence, all ten impact categories (including Demo Impact), risk/rollback/notes and a release-note line or reasoned none. Keep the .ai-context/ checklist item only until package 14 removes that obsolete check; retain all other checks. Start non-required and warn-only; this validator cannot approve or merge.

Scope and non-goals

Scope: Rescope the PR-body checker to the accepted PR template: linked issue and declared slice, plan/acceptance trace, validation evidence, all ten impact categories (including Demo Impact), risk/rollback/notes and a release-note line or reasoned none. Keep the .ai-context/ checklist item only until package 14 removes that obsolete check; retain all other checks. Start non-required and warn-only; this validator cannot approve or merge.

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

• PR body validator/workflow, .github/pull_request_template.md, PR contract tests and docs/github-workflow.md.
• 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 7b 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: PR body validator/workflow, .github/pull_request_template.md, PR contract tests and docs/github-workflow.md.; 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: #2669, #2573, #2680
• Acceptance criteria:
• Each PR rule has passing/failing fixtures and reports stable, actionable findings.
• A PR linked to a multi-PR issue declares one named slice; single-PR linkage uses the appropriate close keyword.
• All ten impact dispositions and release-note/none are checked for presence, not semantic quality.
• The existing .ai-context/ item is isolated so package 14 can remove only that rule while preserving the rest.
• The check remains non-required until a documented burn-in and maintainer promotion decision; it cannot approve, merge or change issue status.
• Validation:
• Add fixtures for missing/wrong issue link, missing slice, all ten impact categories, Demo Impact, validation, release note/none, and legacy .ai-context/ item.
• Verify warning-only behavior and prove the check has no write/merge permissions.
• Run workflow contract tests and git diff --check.
• Risks and rollback: A shallow presence check can create false confidence; report findings as structural evidence and never equate them with reviewer approval.
• Decision impact: No decision is accepted by implementation alone; record accepted decisions and file a superseding ADR if a change is approved.