[Epic] Support native Podman with buildless managed onboarding

## Outcome

At completion, NemoClaw supports Docker and native Podman as pluggable runtime providers for buildless managed onboarding.

The supported path covers every shipped agent:

- OpenClaw
- Hermes
- LangChain Deep Agents Code

All three agents launch from complete immutable managed-image digests on `linux/amd64` and `linux/arm64`. Native Podman support includes NVIDIA CDI GPU access and host-local Ollama, NVIDIA NIM, and vLLM through `inference.local`.

Runtime-specific behavior stays behind provider-neutral lifecycle and bootstrap contracts. The same contracts must admit a socket-free MXC-style provider without Podman branches in central orchestration.

NemoClaw uses existing OpenShell contracts. This epic does not require or authorize changes in `NVIDIA/OpenShell`.

## Product decisions and invariants

- Docker remains supported.
- Stock managed onboarding becomes buildless. Explicit user-supplied `--from` Dockerfiles remain a separate opt-in path.
- `--temp-managed-runtime` remains hidden, default-off, and undocumented until the supported activation gate passes.
- The hidden gate permits qualification. It does not establish a supported surface.
- Buildless activation requires OpenClaw, Hermes, and LangChain Deep Agents Code to pass together.
- Native Podman activation requires all agents, both architectures, GPU access, local inference, lifecycle recovery, installer validation, and protected end-to-end evidence.
- Production Podman registration occurs only in B4-H.
- Central orchestration selects capabilities and opaque runtime providers. It does not branch on Podman.
- Each runtime registers one immutable provider bundle with complete, identity-consistent capabilities.
- Runtime provider state mutation is a mandatory supported-or-unsupported provider facet. The central contract does not accept callbacks or arbitrary privileged commands.
- Provider-owned inference authority is persisted before shared-state commit and re-proved after each lifecycle transition.
- Cleanup uses immutable provider-owned identifiers. Operations fail closed on missing, stale, incomplete, reused, or ambiguous authority.
- Earlier slices remain dormant or internally complete. They do not advertise partial buildless or Podman support.

## Architecture

### Managed images

- Resolve complete all-agent image cohorts by immutable per-platform digest.
- Keep custom Dockerfile onboarding separate from managed-image selection.
- Reject incomplete, mutable, or mixed-cohort image authority.

### Runtime provider bundle

Each provider bundle owns its identity, capabilities, preflight, workload creation, lifecycle, runtime provider state mutation, managed bootstrap, snapshot, recovery, cleanup, and container-engine operations.

Registration fails closed when the bundle is incomplete or internally inconsistent. Docker, Podman, and the MXC-style fixture use the same central contract.

### Transactional lifecycle

- Derive bounded, versioned, credential-free bootstrap plans from agent definitions.
- Keep privileged execution inside the selected provider.
- Persist provider-owned intent and receipts before shared state becomes visible.
- Resume, reconcile, or roll back incomplete work after process or controller failure.
- Re-prove provider, engine, endpoint, image, runtime, route, model, lifecycle generation, and NVIDIA CDI authority after every lifecycle transition.
- Prevent mutable-name lookup from deleting another runtime.

## Work plan

GitHub native subissues are the progress source. Closed tasks represent completed delivery. Open tasks represent work that remains. Reference issues and source-only PRs are not subissues.

### Completed work

| Completed task | Merged PR | Delivered outcome |
| --- | --- | --- |
| #9125 | #7747 | Driver-neutral compute selection groundwork. |
| #9126 | #7756 | Validated immutable managed OCI image publication. |
| #9127 | #7772 | Managed-image selection contracts. |
| #9128 | #8045 | Image-owned managed bootstrap runtime. |
| #9129 | #8047 | All-agent managed-image packaging and publication. |
| #9130 | #8225 | Managed bootstrap ownership and recovery hardening. |
| #9131 | #8226 | Inert protected multi-architecture lane bootstrap. |
| #9132 | #8234 | Protected buildless qualification batch. |
| #9133 | #8261 | Hidden, default-off buildless experiment gate. |
| #9134 | #8276 | B4-A dormant Podman CPU lifecycle. |
| #9135 | #8052 | B4-B dormant Podman managed-bootstrap transaction. |
| #9136 | #8058 | B4-C provider lifecycle and runtime provider state mutation contract. |
| #9137 | #8658 | B4-C2 durable Docker runtime provider state mutation. |
| #9138 | #8061 | B4-D dormant NVIDIA CDI GPU and host-local inference foundation. |
| #9141 | #9123 | Durable host-local inference authority across supported lifecycle transitions. |
| #9142 | #9187 | Dormant protected inference qualification, real Podman state mutation, and candidate execution. |
| #9143 | #9223 | Trusted native qualification collector, canonical executable qualification contract, and generic fail-closed activation catalog. |
| #9144 | #9232 | Trusted-main native qualification executor and receipts; 15/15 assignable protected cases passed, with nine ARM64-GPU cases and the complete aggregate deferred as mandatory pre-activation evidence. |
| #9140 | #9323 | Activated supported buildless managed onboarding for all shipped agents. |

### Remaining delivery

| Position | Work issue | Delivery PR | Exit condition |
| --- | --- | --- | --- |
| 6/6 · B4-H | #9145 | #9923 | Complete the deferred exact 24/24 trusted aggregate, then register supported native Podman and publish evidence-matched documentation. |

## Implementation source PRs

These PRs contain source material for delivered or remaining work. They are not subissues or accepted delivery ancestry unless a remaining work issue names them as source material.

- Initial broad implementations: #7772 was narrowed and merged; #7872 is the closed, unmerged all-agent native Podman monolith.
- Superseded B4-E1 source: #8069 is closed and #8076 remains source material. Accepted B4-E1 delivery landed through #9123 under #9141.
- Delivered reconstruction sources: #8079 fed B4-E2/#9187; #8062 and #8063 fed B4-F/#9223; #8064 and #8067 fed the final B4-G delivery in #9232.
- Buildless source record: #7944 is closed and unmerged; its replacement work landed through the completed history above.

## Current batch: B4-H

B4-G is complete through issue #9144 and merged PR #9232. Its GitHub-verified squash commit `8cdc3c41eadf51cd817df9a0f738656d8c940be5` landed on `main` from exact PR head `54a3c3b548d86035b752e499b227719f3eb961c2`. It delivered the PRA-1 trusted-main controller, pinned native Podman toolchain, canonical 24-case executor, installer and per-case receipts, credential-free unprivileged candidate execution with Docker unavailable, exact cleanup, and fail-closed aggregation. It did not register, select, advertise, or document production Podman.

Accepted B4-G evidence and exception:

- All required PR checks passed at the exact merged head. Full PR CI run `32021563119` and codebase growth guardrail run `32021562210` passed, and all 28 review conversations were resolved.
- Protected run `31984240689`, attempt `1`, at historical candidate commit `504fcf718a8ece560c021c5ed4656851ef419e84` passed all 15 cases that received authorized runners: all six AMD64/ARM64 CPU cases and all nine AMD64 RTX PRO 6000 GPU cases.
- Nine ARM64-GPU cases received no runner identity. B4-G therefore made no 24/24, latest-head protected-run, or complete aggregate claim.
- The repository administrator exception covered only the unavailable pre-merge ARM64-GPU executions and aggregate receipt. Those nine cases and the exact complete aggregate remain mandatory before production activation on the physical DGX Spark or another proper ARM64 NVIDIA-GPU runner.
- As of `2026-08-17T11:58:12Z`, post-merge validation for `8cdc3c41eadf51cd817df9a0f738656d8c940be5` was not green: installer hash, conflict resolution, and documentation staging had passed; `CI / Main`, E2E, platform evidence, code scanning, code quality, and base images were pending; portable-profile rootless run `32027086196` failed in the registry-container `conmon` path and the Ollama registry DNS path. That failure was not yet classified.

Issue #9145 owns one outcome: activate supported native Podman and publish evidence-matched installer and support documentation.

B3-E issue #9140 is complete through merged PR #9323. GitHub merge commit `390e3bbeb328589f27cf7f901ebfcf2117586305` landed on `main` from exact PR head `0943a7dccd77661555286e2b9cf36b0438787e9b` on 2026-08-23. B4-H delivery is PR #9923, based directly on that landed `main` commit. Supported activation still cannot complete until the trusted controller accepts the full native matrix for the exact activation candidate.

B4-H must:

- start from the latest accepted `main` and use one exact candidate PR head, target-base SHA, trusted workflow SHA, run, attempt, job, artifact, and digest identity throughout qualification;
- use the trusted-main controller from #9232 to obtain all 24 required case receipts and the canonical aggregate before enabling any production selector or support claim;
- register one complete, identity-consistent Podman provider bundle without provider-name switches in central orchestration;
- preserve Docker support, Kubernetes behavior, and the socket-free MXC-style provider seam;
- expose only the hosts, architectures, GPU paths, inference runtimes, agents, and lifecycle operations covered by the accepted aggregate;
- remove or replace the temporary experiment gate only after the activation evidence passes;
- publish installer behavior and support documentation that match the shipped evidence; and
- re-prove exact cleanup and that name-only deletion cannot remove a managed runtime.

The B4-G administrator exception authorized landing the dormant trusted controller despite the pre-merge chicken-and-egg condition. It did not waive any activation evidence or authorize production Podman selection.

## Test and evidence gates

### Every batch

- Use the accepted predecessor and the latest target-branch state.
- Keep the PR issue-scoped and exclude unrelated changes.
- Require signed, DCO-compliant, GitHub-verified commits.
- Run affected behavior tests, type checks, repository checks, source-shape and test-size checks, and diff checks.
- Prove dormancy when the batch must not affect a production command, provider registry, or supported surface.
- Run protected end-to-end qualification when the batch changes a product flow or candidate execution path.
- Bind evidence to the latest PR commit and its target-branch base.
- Preserve Docker and Kubernetes behavior unless the batch explicitly owns that change.

### Buildless activation

B3-E must prove:

- OpenClaw, Hermes, and LangChain Deep Agents Code;
- `linux/amd64` and `linux/arm64`;
- immutable all-agent image digests;
- managed onboarding without a stock Dockerfile build;
- nonroot agent identity;
- restart, rebuild, snapshot and restore, clone, backup, recovery, and rollback;
- exact bootstrap receipts and shared-state commit; and
- Docker, macOS, WSL, gateway-isolation, messaging, and security regressions.

### Native Podman activation

Before B4-H production activation, the accepted B4-G/B4-H evidence must prove:

- native Podman with Docker unavailable;
- OpenClaw, Hermes, and LangChain Deep Agents Code;
- supported `amd64` and `arm64` hosts;
- rootful and rootless operation where supported;
- networking, volumes, SELinux labeling, and exact cleanup;
- NVIDIA CDI GPU attachment;
- host-local Ollama, NVIDIA NIM, and vLLM;
- real GPU-backed inference turns;
- restart, rebuild, snapshot and restore, clone, backup, crash recovery, rollback, and name-reuse failure handling;
- installer and preflight behavior; and
- evidence-matched support documentation.

The trusted collector and controller are now on `main` through #9223 and #9232. B4-H must use that trusted-main authority against the exact activation PR head and target-base SHA to obtain the complete 24-case aggregate before registration, selection, advertising, or documentation. Candidate-controlled code never runs in the privileged collector, and a candidate PR cannot self-qualify using workflow code introduced by that PR.

## Related context

These records explain demand, compatibility failures, or dependencies. They are not delivery subissues:

- Native Podman requests: #420 and #7883.
- Compatibility failures: #116, #7320, and #9054.
- System-readiness dependency: #7407.
- Compatibility PRs: #1359, #7353, and #7560.

## Scope boundaries

In scope:

- buildless managed onboarding for all shipped agents;
- complete immutable images and atomic all-agent publication;
- provider-neutral lifecycle and transactional bootstrap;
- Docker and native Podman providers;
- `amd64` and `arm64`;
- snapshot, clone, rebuild, backup, restore, durable recovery, and exact cleanup;
- native Podman GPU access and host-local Ollama, NVIDIA NIM, and vLLM;
- a socket-free MXC-style contract fixture; and
- evidence-backed installer and documentation changes.

Out of scope:

- arbitrary privileged commands or credential rewrite through startup profiles;
- OpenClaw-only or Docker-compatibility-only Podman support;
- production MXC enablement;
- Kubernetes behavior changes beyond regression preservation;
- changes in `NVIDIA/OpenShell` without separate explicit approval; and
- support claims for an untested runtime, host, architecture, GPU, or inference combination.

## Definition of done

The epic closes only when:

- the temporary experiment gate is removed or replaced by an evidence-backed supported surface;
- Docker and native Podman launch all shipped agents through the same provider-neutral contracts;
- real Docker and Podman runtime provider state mutation facets have named production consumers and interruption-recovery evidence;
- stock managed onboarding performs no Dockerfile build;
- native Podman passes the complete multi-architecture GPU and Ollama, NVIDIA NIM, and vLLM matrix;
- lifecycle and crash recovery preserve exact provider-owned authority;
- name-only deletion cannot remove a managed runtime;
- protected end-to-end qualification passes for the activation commit; and
- installer and support documentation match the shipped evidence.