Validate issue readiness through API and CLI intake #2571

Problem

The accepted Base governance implementation plan assigns this existing issue to package 7a. 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 existing readiness workflow to the accepted issue contract. Validate presence and non-empty contract sections for issues created through the API/CLI, the issue's current native Type at readiness time, the current contract fingerprint, the named slice plan where required and the 30-day Ready freshness rule. Keep the workflow advisory/non-blocking and idempotent: one updatable comment plus one label, with no Project Status writes, auto-close or merge authority. Do not validate Agent Assignment fields.

Scope and non-goals

Scope: Rescope the existing readiness workflow to the accepted issue contract. Validate presence and non-empty contract sections for issues created through the API/CLI, the issue's current native Type at readiness time, the current contract fingerprint, the named slice plan where required and the 30-day Ready freshness rule. Keep the workflow advisory/non-blocking and idempotent: one updatable comment plus one label, with no Project Status writes, auto-close or merge authority. Do not validate Agent Assignment fields.

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

• .github/workflows/project-intake.yml, readiness validator, issue template contract 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 7a 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: .github/workflows/project-intake.yml, readiness validator, issue template contract 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: #2667, #2668, #2576, #2583
• Acceptance criteria:
• The readiness check recognizes the single issue contract and current Task/Bug/Feature type without requiring Agent Assignment.
• A stale fingerprint or Type change after Ready invalidates the readiness result; freshness is measured from the accepted Ready approval.
• The workflow is non-blocking, idempotent, advisory, and never changes Project Status or closes issues.
• Report distinguishes missing sections, open impact questions and stale readiness with actionable evidence.
• Validation:
• Add passing/failing fixtures for web/API-created issues, current Type, missing sections, type change, fingerprint change and 30-day expiry.
• Verify exactly one bot comment/label is updated and no status or closure mutation occurs.
• Run workflow contract tests and git diff --check.
• Risks and rollback: A false Ready signal can start work too early; keep the check advisory and retain manual maintainer readiness review.
• Decision impact: No decision is accepted by implementation alone; record accepted decisions and file a superseding ADR if a change is approved.