# ArmorBreak V2.2 Stable release policy (v1)

**Release name:** ArmorBreak V2.2 Stable — Verified Core / Experimental Provider Integrations
**Version:** `2.2.0`
**Policy status:** owner-approved policy revision for this release line; it applies prospectively and does not rewrite the historical Full GA contract.

## Stable scope

V2.2 Stable covers the Universal Core, MCP server, Skills, offline Golden checks, local-model verification, the host integrations explicitly marked verified in the compatibility matrix, and the installer/migration/rollback paths exercised by the Windows and Linux release test matrix. A host or integration is supported only to the level shown by its own current evidence; a project-level Stable release does not imply every host has been installed and exercised.

Provider protocol adapters remain available as **Experimental Provider Integrations**. OpenAI, Anthropic, and Gemini commercial endpoints are `LIVE_UNVERIFIED` until separately tested with an authorized live account. Mock, Offline Golden, and local-model evidence describe those tests only; they are not official commercial-provider certification.

## Accepted assurance model

- Genuine reports from independent AI reviewers count as **AI-assisted security review**. The record must identify the reviewer, reviewed commit, findings, and evidence. It must not claim that an AI reviewer is human or that AI review is a third-party certification.
- A complete repeat of all historical reviews is not required. Fixes and material changes require focused impact review and regression evidence against the release source SHA. Historical verdicts retain their original reviewed SHA.
- Maintainers may record an explicit, scoped risk acceptance for residual non-blocking risk after technical assessment. A confirmed, exploitable P0/P1/HIGH issue without a verified fix or mitigation blocks Stable.
- Current-SHA Semgrep, CodeQL, Trivy, Windows/Linux race, and release-trust results must point to SHA-256-verified evidence IDs. Every CodeQL alert must be triaged. A severe finding can close only as `FIXED`, `MITIGATED`, or evidence-backed `FALSE_POSITIVE`; a false-positive record needs a rationale and evidence. `RISK_ACCEPTED` is limited to LOW/MEDIUM/INFO and must include a scoped maintainer rationale and evidence. An owner waiver cannot close a severe security issue.
- GitHub Actions OIDC/Sigstore attestations are accepted as **build provenance** when the repository, workflow identity, protected `main` ref, source commit, artifact digest, and subject all match. Provenance is not a security certification, production code signature, or provider/host test receipt.
- The local evidence validators and checked-in JSON/Markdown never grant publication authority. Stable eligibility additionally requires live GitHub CI and attestation verification for the exact `main` commit and artifact. The repository requires the five release CI contexts from the GitHub Actions app, with strict up-to-date enforcement and admins included. The exact `v2.2.0` tag is covered by an active GitHub tag ruleset; the authenticated repository owner is its sole bypass actor and release publisher. This is an owner-controlled publishing boundary, not an immutable control against the repository owner.
- Stable acceptance does not alter, waive, or replace the historical V2.2 Full GA contract. `docs/v2/acceptance/v2.2-readiness.json` must continue to report `gaReady: false` while any Full GA blocker remains. `v2-readiness.mjs --require-ga` remains the Full GA gate.

## Stable release gates

The versioned machine-readable policy is `docs/v2/release/v2.2-stable-scope-v1.json`. The executable gate is `node scripts/v2/stable-gate.mjs`. A release can be eligible only when all of these hold for one exact commit:

1. The source is the clean `main` HEAD and equals the live `origin/main` HEAD; PR #18 and the README V3 update PR #17 are merged.
2. The required GitHub CI workflow on that exact `main` SHA succeeds, including Windows, Ubuntu/Linux, L0, Docker L1, and release evidence checks.
3. The portable archive and SBOM are generated from that source; the archive SHA-256, file inventory, component inventories, and SBOM subject agree byte-for-byte.
4. `gh attestation verify` succeeds for the exact archive with the expected repository, `.github/workflows/attest.yml`, `refs/heads/main`, source commit, predicate type, and artifact digest.
5. The current-SHA security review records Windows and native Linux race regressions, the B-007 authority boundary, and scan results. Every tool result and finding disposition references a SHA-256-verified evidence ID. Every CodeQL alert is triaged. Any confirmed severe issue must be fixed or have a tested mitigation; an open, unsupported false-positive, or unverified P0/P1/HIGH blocks the gate.
6. Live GitHub settings confirm required exact-source CI contexts, admin enforcement, the active exact-tag ruleset, and the authenticated repository owner as the release principal.
7. The historical Full GA readiness remains unchanged and false. No Stable result may be represented as Full GA.

The gate returns `ELIGIBLE_FOR_RELEASE` only. It does not create a tag or GitHub Release. Release publication is a separate authenticated GitHub write action after the gate passes.