Join the OCI model to the fleet: dissolve the ContainerRuntime nickname and make a customer-supplied container image expressible

[gunbai-bot]

gunbc had two container vocabularies. The good one — nine OCI modules under dag/extdeps/container/oci, cited to the spec, closed coproducts with typed accept/reject — was consumed by nothing that ships. The one everything used was gunbc.fleet_intent's

type ContainerRuntime = Docker | Podman | Gvisor | Ubicloud | GcloudRun

This joins the first and deletes the second.

The nickname, and why five members were three concepts

ContainerRuntime fused container engines (Docker, Podman), a sandbox whose entire value is the isolation guarantee it adds (gVisor), and two companies that rent you a machine (Ubicloud, Google Cloud Run). Adding an engine and adding a supplier both widened one enum — the case DESIGN's external-upstream-decomposition section rules out with "adding Opera must not widen a generic browser-product enum".

The dissolution splits it along the seams that were already there:

• extdeps.container.engine — the agnostic hub. Defines what a container engine is and enumerates no product; adding one is a new file, never an edit here.
• extdeps.container.docker_engine — the one member that had a live consumer, as a cited product row (extdeps.vendor.docker_inc, and extdeps.software for the Vendor<Software> domain the tree lacked). Its Ubuntu apt distribution keeps its own module: how you install it is not what it is.
• gVisor is a guarantee question — product.fabric.isolation already owns what a tenant is promised and deliberately names no mechanism.
• Ubicloud and Cloud Run are suppliers, with homes in extdeps.cloud.ubicloud / product.supplier.

Four members get no replacement row, and that is delete-first working rather than a loss: Podman, gVisor, Ubicloud and GcloudRun had zero constructors anywhere in the corpus, so nothing refused when they went. Inventing four uncited catalog rows to preserve the shape would have been re-invention, not decomposition.

The surface now carries strictly more truth than Docker did. ExecutionSurface.container_engine: ContainerEngineDeployment? is the cited product plus the privilege mode this host runs it in — the property that decides whether a job escaping its container owns the machine, and the one thing the old enum could not say. srv1 runs rootless. A mode the product does not declare yields no deployment, not a surface asserting one.

The customer-supplied image

product.fabric.customer_image is the first executing consumer of the OCI model. A CustomerSuppliedImage is a reference, a manifest and a configuration; admit_customer_image folds it against an ExecutionTarget and returns admitted-or-a-typed-cause.

The isolation mechanism is not in that file, and its absence is the point. CustomerSuppliedImage has no field naming a runtime or a boundary and no constructor that could carry one — a tenant cannot select the mechanism because there is nowhere to put the selection. The mechanism arrives on the target side, chosen by us.

New in extdeps: extdeps.container.oci.reference, because nothing modelled how a party refers to an image — the only spelling available was a String. It carries the distribution-spec grammar (path-component separators enumerated exactly: ., _, __, -+, so a..b and a___b refuse) and both identifier arms including the mutable one. A tag is a real thing the spec defines; refusing to run one is policy, and policy in an extdeps module is a layer inversion. The spec says what may be written; product.fabric.customer_image says what it will accept.

The refusal that justifies the join module existing at all is LayerCountDisagreement. image-spec requires rootfs.diff_ids to correspond one-for-one with the manifest's layers; accept_image_manifest sees only the first list and accept_image_configuration only the second, so each accepts a pair that disagrees — which is what a substituted layer looks like. Only the join sees it.

Green by execution, with discriminating reds

dag/test/claim/customer_image_admission_witness_test.dag drives the real fold. The target is the real fleet (fleet_container_execution_target() — architecture read from srv1's declared Ampere CPU, engine from the surface), not a target authored to make the test pass, so the amd64 refusal is a claim about what this fleet would actually do. Each refusal case differs from the admitted case in exactly the fact its refusal names.

A fixture that cannot be built returns Absent and every witness fails on it rather than passing vacuously.

Measured, not asserted — claim_batch --claim-run over the 13 rows, all PASS, and the entry closure compiles with 0 blocking diagnostics. Re-derive with:

claim_batch --source-root dag --source-root src/v2 --claim-run \
  --entry dag/test/claim/customer_image_admission_witness_test.dag --functions <the test fns>

The reds were executed, not assumed. Three separate deletions in the admission fold — the layer-count join always agreeing, the digest-pin test skipped, the architecture comparison skipped — each turned exactly one witness red and left the other twelve green. Nothing agrees with the fold's shape instead of testing its decision, and no single defect is reported three times. The procedure is recorded in the witness module so it can be re-derived rather than trusted.

What the first executing consumer immediately found

image_config_entrypoint was written as match c.config { null => [] ; cfg => match cfg.Entrypoint { ... } }. The bare arm binds the Optional, not its payload, so the inner field read refuses at runtime with NoSuchField { type_name: "Optional", field: "Entrypoint" }. It typechecked, it had witnesses, and it was wrong — surfaced the first time anything called it. image_config_first_exposed_port and image_config_has_exposed_port carried the identical defect and are repaired in the same change rather than left for the next consumer.

That is the point of the caution in the brief, arriving on schedule: a join that only typechecked would have reproduced the condition it was fixing.

Named residue, not claimed closed

• IsolationBoundary in fleet_intent still describes our own surface beside product.fabric.isolation's guarantee vocabulary. That is a separate question and is untouched here.
• The KernelFamily / Os fork is compiler-enforced and could not be bridged. An image config's os is extdeps.toolchain.types Os; a ComputeHost's surface carries std.os.types KernelFamily. Any module importing both is refused: variant 'Linux' appears in both 'Os' and 'KernelFamily'. So the bridging match cannot be written anywhere. I did not route around it — the target OS is stated by the caller in the vocabulary the image speaks, the mismatch still refuses loudly, nothing widens silently, and the residue is named in gunbc.fleet_container with the exact diagnostic. Dissolving that fork is a real change and is not this one.
• This makes a customer image expressible and admissible. It does not make CI jobs run in containers; that is gated elsewhere.