Cross-Repo Compatibility Validation¶

Verify that a candidate-for-promotion repo is compatible with the current control-plane and its peer repos.

When to run¶

• Before promoting any repo from Stage 0 → Stage 1.
• Before promoting any repo from Stage 1 → Stage 2.
• After any major bump in repo-contract repo_version or control_plane_min/max.

Steps¶

1. Read declared compatibility from the candidate's repo-contract.json:
2. repo_version,
3. control_plane_min, control_plane_max.
4. Read the current control-plane version (this repo's tagged release).
5. Range check.
6. If control_plane_current < control_plane_min → fail (control plane too old).
7. If control_plane_current > control_plane_max → flag (untested combination); requires explicit approver to override.
8. Dependency compatibility. For each peer repo the candidate depends on (e.g., a skills repo depending on a global-rules version), verify each peer satisfies the candidate's expected version pin.
9. Validate automation contract. Run the candidate's automation.validate and ensure exit success.
10. Run security checklist. Scope: any code changed since last validation. Output appended to security-attestation.md.
11. Run regression suite. All declared test suites must pass on a clean checkout of the candidate.
12. Sign validation. Produce a validation artifact (validations/<repo>@<version>-<date>.json) with results, signed by the orchestration agent.

Failure triage¶

Escalation¶

• Two consecutive validation failures on the same candidate → escalate to platform owner.
• Any security control regression → halt promotion immediately and escalate to security owner.