[Epic] Automate Brev Launchable Promotion #7051

Summary

Automate the path from a functionally complete NemoClaw candidate to a qualified Brev Launchable and promotion of the exact tested image into production.

This epic owns the release and image-promotion automation boundary:

exact candidate source
→ immutable staging image
→ real Brev Launchable
→ expandable E2E qualification suite
→ immutable qualification receipt
→ promote the exact tested image
→ move LKG and record evidence

The qualification workflow must remain independently triggerable outside the release process so maintainers, schedules, API clients, and other trusted workflows can exercise the same staging and E2E path.

Why this is a separate epic

#6401 owns reuse of canonical NemoClaw onboarding and lifecycle semantics in the Brev experience. #6409 owns the broader parity, security, lifecycle, and performance test matrix.

This epic owns the automation that builds, deploys, qualifies, and promotes a Brev Launchable image. It provides a home for the initial release gate and for additional qualification-suite coverage issues as they are defined.

Target architecture

flowchart LR
    A["Select functional candidate"] --> B["Dispatch reusable qualification workflow"]
    B --> C["Build immutable staging image"]
    C --> D["Validate image manifest"]
    D --> E["Deploy exact image as Brev Launchable"]
    E --> F["Run qualification suite"]
    F --> G["Publish immutable receipt"]
    G --> H["Validate release readiness"]
    H --> I["Promote exact tested image"]
    I --> J["Move LKG and record promotion"]

    K["Prepare release docs in parallel"] --> H

Initial child issues and dependencies

• Run NemoClaw E2E against an exact staging Brev Launchable #6943 — implement the reusable staging-build, Launchable deployment, E2E, cleanup, and qualification-receipt workflow.
• Update release skills to run docs and Launchable qualification in parallel #7050 — update the maintainer release skills to run docs preparation and reusable Launchable qualification in parallel, then hand verified evidence to tagging.
• brevdev/nemoclaw-image#80 — producer-side exact-SHA staging build and immutable image handoff.

Workstreams

1. Immutable image production and provenance

• Build or reuse a staging image for one exact NemoClaw candidate.
• Emit a versioned manifest containing immutable image and source identity.
• Correlate every request, downstream workflow run, image, workspace, and receipt.
• Reject ambiguous family-head or newest-run inference.

2. Launchable deployment and identity

• Pin or resolve a Launchable to the manifest's immutable image.
• Deploy it from a trusted GitHub workflow using supported Brev interfaces.
• Read back and prove the actual boot image before testing.
• Track external Brev CLI/platform capabilities needed for exact pinning and provenance readback.

3. Qualification-suite coverage

• Establish a dedicated preinstalled/published-image E2E mode that does not overlay source or rebuild NemoClaw.
• Start with installation identity, onboarding, sandbox/gateway readiness, inference, one real agent response, and cleanup.
• Add focused child issues for the desired OpenClaw, Hermes, Deep Code, provider, policy, integration, lifecycle, recovery, security, and performance coverage.
• Define blocking versus informational tests and require explicit exceptions for non-green release-mode coverage.

4. Reusable workflow and evidence

• Support independent workflow_dispatch invocation.
• Support trusted reuse through workflow_call.
• Keep cloud credentials and billable operations inside protected GitHub environments.
• Publish redacted immutable receipts and retain actionable diagnostics.
• Make cleanup unconditional and verify workspace absence.

5. Release and promotion integration

• Compose qualification with docs preparation through the maintainer pre-release skill without serializing the two paths.
• Allow only narrowly audited non-runtime release-note changes between the tested candidate and final release SHA.
• Make the tag/release flow consume an already completed qualification receipt.
• Gate LKG promotion on the applicable receipt.
• Promote the exact tested immutable image into the production family/channel rather than rebuilding it.

6. Rollout and operations

• Begin with protected, explicitly approved shadow runs.
• Measure latency, cost, cleanup reliability, and failure classes.
• Define retry, cancellation, supersession, TTL, and reconciliation behavior.
• Enable blocking promotion only after the shadow results meet the accepted operational bar.

Non-goals

• Reimplement canonical NemoClaw onboarding inside the image repository.
• Treat a source-overlay VM or local GitHub runner smoke as Launchable qualification.
• Claim a separately rebuilt production image is the artifact that was tested.
• Put Brev or cloud credentials on the maintainer's machine or in a coding-agent context.
• Define the complete E2E matrix in this parent issue; focused coverage belongs in child issues.

Epic completion criteria

• A trusted reusable workflow builds an immutable staging image for an exact candidate and consumes its validated manifest.
• A real Brev Launchable boots that exact image and proves its identity.
• The agreed blocking qualification suite passes without altering the baked product.
• Every run emits correlated, redacted evidence and performs verified cleanup.
• The pre-release skill runs docs preparation and qualification concurrently and hands both results to release tagging.
• Any allowed tested-SHA-to-release-SHA delta is narrow, automatic, and auditable.
• LKG cannot be promoted without the applicable successful receipt or an explicitly recorded exception.
• Production promotion reuses the exact tested immutable image.
• Additional suite-coverage issues are tracked under this epic with explicit blocking semantics.
• Shadow rollout demonstrates acceptable cost, latency, security, and cleanup reliability before enforcement.