Gate backend parity in CI and releases and document supported capabilities #10338

Goal

Make parity regressions across Docker, NVX, and Cloud Hypervisor visible and enforceable in routine development and release acceptance. Part of #10335, step 6.

Scope

• Use the merged Define the cross-backend workload contract #10347 contract and Extract backend-neutral enclave execution policy and lifecycle #10342 shared-core extraction as the baseline. Neither supplies Docker host-executor migration, NVX enclave support, general/private Cloud Hypervisor enclave acceptance, or a full live conformance certificate.
• Run shared deterministic contract/harness checks on relevant PRs and Docker integration routinely.
• Run privileged VM checks on explicitly eligible runners under existing approval and provenance rules; run the complete reviewed three-backend matrix before release.
• Ensure shared-core, entrypoint, schema, broker, networking, storage, and harness changes select all affected backend jobs, not just the backend named in a path.
• Publish comparable backend/workload/scenario/outcome/cleanup reports and retain protected diagnostic evidence safely.
• Make unavailable prerequisites, unsupported capabilities, and not-validated cases explicit; required supported cells must not silently skip to green.
• Keep routine fixture-based checks separate from explicitly authorized credential-bearing real-provider acceptance. Never expose secrets to untrusted PR workloads.
• Update existing architecture, configuration, filesystem-sharing, integration-testing, and backend documentation to reflect verified capabilities, host restrictions, execution ownership, and recovery behavior.
• Preserve preview and acceptance gates until real evidence supports promotion; do not equate passing unit tests or successful boot with isolation acceptance.
• Maintain separate capability status (implemented/gated/unsupported/unverified) and validation outcome/evidence kind. Only reviewed supported cells may be required to pass; record unsupported target cells as outstanding parity work, not skipped successes. Exercise named Cloud Hypervisor public-fixture/release-conformance predicates without widening them or claiming private-repository acceptance.
• Record the actual backend, role/combination, host, artifact identity and applicable gate. A warning-emitting Cloud Hypervisor primary-only unsupported-host fallback is characterized behavior, but its Docker result cannot satisfy a Cloud Hypervisor release cell. Enclave and NVX fallback remains forbidden; artifact-trust failures remain fatal.
• Document the current accounting/storage gaps accurately: disclosure/executor counters are in-memory, tool-call persistence is best-effort, and Docker aggregate writable-output acceptance remains unverified until Migrate Docker enclaves to the shared host-owned execution lifecycle #10340 supplies evidence. Do not advertise durable non-refilling budgets or aggregate enforcement from mocked policy/per-file/tmpfs checks.

Starting points

• /home/runner/work/gh-aw-firewall/gh-aw-firewall/.github/workflows/test-cloud-hypervisor-enclaves.yml
• /home/runner/work/gh-aw-firewall/gh-aw-firewall/.github/workflows/test-cloud-hypervisor.yml
• /home/runner/work/gh-aw-firewall/gh-aw-firewall/docs/enclaves-architecture.md
• /home/runner/work/gh-aw-firewall/gh-aw-firewall/docs/filesystem-sharing-contract.md
• /home/runner/work/gh-aw-firewall/gh-aw-firewall/docs/INTEGRATION-TESTS.md

Acceptance criteria

• Relevant PRs run deterministic checks and required eligible integration checks with backend-complete change selection.
• Release acceptance requires passing supported Docker/NVX/Cloud Hypervisor matrix cells and verified cleanup.
• A single report makes backend-specific failures and missing validation obvious.
• Gating tests prevent silent skips, missing required scenarios, and unapproved privileged/secret-bearing execution.
• Documentation matches observed support and explicitly distinguishes functional/policy parity from isolation strength.
• Existing generated-workflow compilation/post-processing conventions are followed where agentic workflow sources change.
• Reports and gates preserve the contract's support/evidence distinctions and intentional resource/image/GitHub capability differences; missing live identity/resource/recovery evidence remains visible.

Dependencies

The contract (#10339 via #10347) and shared core (#10336 via #10342) are merged. Begin deterministic CI and reporting incrementally with #10341; add backend acceptance as #10340 and #10337 deliver it. Final target-parity release gating depends on those migrations and #10341's accepted matrix, not on treating currently unsupported/unverified cells as already enabled. Any promotion or change to the characterized fallback/accounting behavior must be explicit and reviewed.