Publish and test the governance-aware base manifest schema #1613

Problem

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

Extend the formal JSON Schema for base_manifest.yaml to validate the accepted governance: contract: separate issue/PR review-loop limits (initially three), reviewer mode, Ready freshness and review-policy selection. Keep this issue to schema/default/example and contract-test work; exact CLI flags remain in #2668. Preserve existing manifest keys and compatibility behavior.

Scope and non-goals

Scope: Extend the formal JSON Schema for base_manifest.yaml to validate the accepted governance: contract: separate issue/PR review-loop limits (initially three), reviewer mode, Ready freshness and review-policy selection. Keep this issue to schema/default/example and contract-test work; exact CLI flags remain in #2668. Preserve existing manifest keys and compatibility behavior.

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/schemas/base_manifest.schema.json (or the canonical schema path), manifest examples, schema validation and config reference.
• 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 3a 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/schemas/base_manifest.schema.json (or the canonical schema path), manifest examples, schema validation and config reference.; 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: #2666
• Acceptance criteria:
• The schema accepts valid governance settings and rejects wrong types, out-of-range loop limits, unsupported modes and unknown keys according to the accepted config contract.
• Defaults and bounds for issue and PR limits are separate and documented; both start at three.
• Existing manifests remain valid or receive a clear migration path; schema validation does not rewrite files.
• Examples and contract tests cover ecosystem and Base-supported consumer profiles without requiring a governance/ directory.
• Validation:
• Add positive/negative schema fixtures for all governance keys and defaults.
• Validate current first-party manifest fixtures plus homebrew-base's planned minimal manifest example.
• Run manifest/schema contract tests and git diff --check.
• Risks and rollback: Overly strict schema changes could reject supported repositories; validate all current manifests and roll back the schema change without rewriting manifests.
• Decision impact: No decision is accepted by implementation alone; record accepted decisions and file a superseding ADR if a change is approved.