Build and deploy local Dockerfiles through the shared executor #799

Parent

Build runner spec (#798)

What to build

Move the existing local Dockerfile workflow behind the shared build module while keeping build and deploy working end to end. This is the prefactoring slice: it earns the interface with an actual built image, rather than landing an unused runner framework. Preserve ordinary existing Compose behavior through upstream translation.

Acceptance criteria

• Keep two caller operations: capture one Build's inputs and execute that opaque capture. Hide temporary paths, subprocess orchestration, builder setup, image import, and cleanup. Keep Service selection/dependency orchestration in the Compose adapter and Deploy in the client. Share execution code through a library that does not couple the CLI application to the daemon application or browser-facing configuration rules; introduce no provider framework.
• Execute Dockerfiles through a pinned Docker-managed BuildKit container, provision required tools automatically, load the result into the execution host's Docker containerd image store, and verify the expected single-platform content. Local calls require Docker but no Ployz daemon. Default to the Docker execution host's native Linux platform; validate explicit single-platform requests and refuse multiple Dockerfile platforms.
• Return observed immutable image identity, requested tags, actual platform coverage, and local location. Bind each attempt's result to exact content so a later build updating the requested tag cannot substitute its image before deployment or dependency use. A validation-only result is distinct and produces no successful image/transfer claim.
• Keep existing ordinary Compose build selection, profiles, dependencies/cycle refusal, local/external/inline Dockerfiles, local and Service image contexts, arguments, secrets, explicit SSH key files, stage targets, labels/tags, and no-cache/pull controls working. Bind dependencies to the outputs for this command. Reuse upstream translation rather than narrowing the current path to a hand-picked flag map; name any parent-spec-authorized unsupported setting before execution.
• Keep standalone build, Direct Image Transfer, and explicit registry publication distinct, preserving current validation and publication flag behavior. Update build and deploy callers together. Every required Build must finish before Service Container, Hook Container, or application-volume mutations; preserve prepare-once Deploy, ordinary/Data Loss Confirmation, and partial outcomes. Failed or cancelled builds leave remaining build/deploy work explicitly unattempted.
• Remove the builder container after execution while retaining its dedicated cache. Serialize direct local calls sharing that cache; preserve bounded cancellation and the default thirty-minute execution timeout. Do not reuse builder/cache state while termination is uncertain. Retained images remain usable after builder teardown.
• Use rung-2 capture/build/client checks, including captured input A executing after edits B and exact-image binding after tag reuse; reuse existing build/secret/dependency/validation tests. Use a registered rung-4 exercise for an actual local Dockerfile build, image execution/Deploy, and builder recreation with a cache hit. Recording subprocess tests alone are not proof of an image. Record the runnable test and rung in the affected product evidence.

Blocked by

• None — can start immediately.