Provide primary-agent and enclave parity across Docker, NVX, and Cloud Hypervisor #10335

Goal

Provide consistent, regression-tested support for primary agents, script enclaves, and agent enclaves across Docker, NVX, and Cloud Hypervisor, reusing Cloud Hypervisor's policy, authenticated host execution, lifecycle, bounded-storage, recovery, and conformance machinery wherever possible.

Parity means equivalent externally observable behavior and enforced policy, not identical isolation strength between containers and VMs. Maintain one workload backend per run, with separate isolated workload instances; supporting Docker infrastructure is outside that constraint. Preserve the characterized, warning-emitting Cloud Hypervisor primary-only fallback on CloudHypervisorUnsupportedHostError; it never applies with enclaves, artifact-trust failures stay fatal, and NVX never falls back.

Starting point

The baseline is now established by merged #10347 (contract, closes #10339) and #10342 (shared execution core, closes #10336). The authoritative role/capability matrix, resource and accounting semantics, and verification obligations are in the merged cross-backend workload contract.

Docker implements all three roles through existing container/broker-managed execution. NVX still rejects enclaves. Cloud Hypervisor enclave combinations remain limited to named public-fixture/release-conformance acceptance predicates; general and private-repository use is not accepted. The shared-core extraction does not migrate Docker, enable NVX, or relax those gates. Implemented, gated, unsupported, and unverified are distinct states; mocks or structural validation cannot promote them.

Delivery steps

Each item is also linked as a native GitHub sub-issue:

• Define and characterize the cross-backend workload contract #10339 — Define and characterize the cross-backend workload contract. Merged in Define the cross-backend workload contract #10347.
• Extract shared execution policy and enclave lifecycle from Cloud Hypervisor #10336 — Extract shared execution policy and enclave lifecycle from Cloud Hypervisor. Merged in Extract backend-neutral enclave execution policy and lifecycle #10342.
• Migrate Docker enclaves to the shared host-owned execution lifecycle #10340 — Migrate Docker enclaves to the shared host-owned execution lifecycle.
• Implement NVX script and agent enclaves using the shared execution core #10337 — Implement NVX script and agent enclaves using the shared execution core.
• Extract a shared Docker, NVX, and Cloud Hypervisor conformance suite #10341 — Extract a shared Docker, NVX, and Cloud Hypervisor conformance suite.
• Gate backend parity in CI and releases and document supported capabilities #10338 — Gate backend parity in CI and releases and document supported capabilities.

Required invariants

• Primary-agent workspace, environment, proxy, working-directory, exit-status, and cancellation behavior remains compatible.
• Script enclaves have no external networking. Agent enclaves reach only their dedicated API proxy and explicitly authorized GitHub gateway.
• Repository seeds are immutable; writable state must become invocation-private and aggregate-bounded; workloads are non-root and resource-bounded. Docker aggregate host-output storage acceptance remains unverified and is a migration deliverable, not a guarantee supplied by Extract backend-neutral enclave execution policy and lifecycle #10342.
• Preserve Docker's configurable resource limits; the extracted fixed VM policies must not silently replace them. Aggregate writable-state enforcement, per-file limits, tmpfs limits, and separately bounded host artifact/image state have different scopes.
• Preserve the characterized disclosure, invocation, tool-call, and model-budget semantics. The disclosure ledger and executor invocation counters are in-memory; tool-call persistence is best-effort and may refill on restart after failed writes or unreadable/corrupt state. Durable non-refilling accounting is not supplied by either merged PR; any strengthening needs explicit behavior and recovery criteria rather than an assumed guarantee.
• Results are canonical, schema-valid, bounded, and released only after confirmed cleanup. Uncertain cleanup preserves recoverable state.
• Private output cannot escape through stdout, diagnostics, audit records, or artifacts.
• Preserve existing Docker capabilities, including supported dynamic GitHub delegation. Document and test intentional capability differences; do not silently reduce all backends to the smallest acceptance subset.

Sequencing and dependencies

1. Define and characterize the cross-backend workload contract #10339 is complete via Define the cross-backend workload contract #10347; use its merged contract as the baseline.
2. Extract shared execution policy and enclave lifecycle from Cloud Hypervisor #10336 is complete via Extract backend-neutral enclave execution policy and lifecycle #10342; consume the extracted interfaces rather than repeating extraction.
3. Migrate Docker enclaves to the shared host-owned execution lifecycle #10340 and Implement NVX script and agent enclaves using the shared execution core #10337 follow the shared-core extraction and may proceed in parallel once its interfaces stabilize.
4. Extract a shared Docker, NVX, and Cloud Hypervisor conformance suite #10341 starts after characterization, supplies migration gates throughout extraction and backend implementation, and completes when all three adapters pass.
5. Gate backend parity in CI and releases and document supported capabilities #10338 introduces CI incrementally; final release gating requires the shared suite and supported backend matrix to pass.

Definition of done

• Target parity is Docker, NVX, and Cloud Hypervisor passing primary-only, primary + script-only, primary + agent-only, and primary + both scenarios on eligible hosts. "Script-only" and "agent-only" enable only that enclave role alongside the normal primary agent; they are not standalone enclave CLI modes.
• The same scenario definitions and behavioral assertions exercise all three backends, supplemented by backend-specific confinement tests.
• Coverage includes failure, cancellation, exhaustion, crash recovery, orphan cleanup, and private-output sentinel checks—not only happy-path launches.
• Deterministic checks run on relevant PRs; authorized real-backend and release checks enforce supported matrix cells.
• Reports distinguish passed, failed, and not validated; missing prerequisites never count as success.
• Existing preview, host eligibility, approval, and artifact-provenance gates remain enforced. Each capability promotion requires separately reviewed acceptance evidence; passing a named public-fixture gate does not accept general or private-repository VM execution. Report unsupported/unverified target cells as remaining work, never as achieved parity.