The bar for showing m80 to anyone: hardened, cold-runnable, known to work

[lex00]

Blocks #21. Nothing about m80 goes to codriverlabs — or anyone — until this is met.

Three criteria, each of which has to be something we can point at rather than assert.

Hardened

• The conformance suite gates every pull request, not just releases (ci: gate on conformance and on the README actually working #53)
• Failure-injection levers reachable from outside the process — a consumer pointed at the container cannot currently provoke a failed build or a connector failure code, because the levers are Go-only. See the separate issue.
• A second pair of eyes on the concurrency work in internal/vms. It is correct under -race today, but one person wrote it and one person reviewed it.
• Decide what m80 does when it is asked something the model allows and no recording covers. Today the answer is scattered — some paths guess, some 501, some model-check. Recorder: address a VM's own hostname, then record the endpoint behavior #42 showed how wrong a reasonable guess can be.

Runnable cold by someone new

• The quick start goes from docker run to a running VM without guessing (ci: gate on conformance and on the README actually working #53)
• That walkthrough is executed in CI, so it cannot rot (scripts/smoke.sh)
• Someone who is not us follows it, on a machine that is not ours, and we watch. Everything above is us checking our own homework.
• The docs site says the same things as the README. They have drifted before.

Known to work

• 100 conformance checks against fixtures recorded from live AWS, 29/29 operations
• 50 of 63 cases of KubeMicroVM's own UAT suite, with every failure accounted for
• The published image matches main. It does not today — see the release issue.
• More than one consumer. KubeMicroVM is the only real one, and a gap that only KubeMicroVM's usage would expose is a gap we cannot see.
• A run on Linux. Everything so far has been macOS plus CI.

The last unchecked item in each section is the honest one: we have checked our own work thoroughly and nobody else has checked it at all.

[lex00]

"The published image matches main" is done — v0.2.0 is out and scripts/smoke.sh passes against it (#55). The release gate runs both the conformance suite and the smoke test against the candidate container before publishing, so it cannot drift again silently.

[lex00]

Two of the unchecked items got evidence today, from standing m80 up under the kubemicrovm-ops kit rather than under m80's own harness.

"The published image matches main. It does not today." It is worse than one stale tag. Neither ghcr.io/intentius/m80:v0.2.0 nor :latest has -serve-sts:

$ docker run --rm --entrypoint /usr/local/bin/m80 ghcr.io/intentius/m80:v0.2.0 -help
flag provided but not defined: -serve-sts

A consumer following the documented KubeMicroVM setup with a pulled image gets a CrashLoopBackOff on m80 itself, and the operator never becomes ready. Building from main and passing M80_IMAGE is the workaround; the kit's local-target page says so, which it should not have to.

"More than one consumer. KubeMicroVM is the only real one." There is now a second, and it exercised m80 differently enough to be worth the checkbox. kubemicrovm-ops deploys a declared estate rather than driving the UAT suite, so it reached m80 through the operator's reconcile loop across three deployment tiers. The paths that got hit: CreateMicrovmImage through to SUCCESSFUL with a floci-minted bucket and build role, a MicroVMReplicaSet scaling to two concurrent VMs both reaching Running, and CreateNetworkConnector reaching ACTIVE.

m80's validation messages did real work in that run. Two mistakes in the kit were caught by m80 rejecting them exactly as the service would:

• Value null at 'baseImageArn' failed to satisfy constraint: Member must not be null — the CRD schema marks nothing required, so this applied cleanly and only m80 objected.
• Value 'null' at 'configuration.vpcEgressConfiguration.networkProtocol' failed to satisfy constraint: Member must satisfy enum value set: [IPv4, DualStack] — the CRD types that field as an open string.

Both are cases where the emulator was stricter than the schema and right to be. That is the fidelity claim doing something useful for a consumer, which is the thing #54 is actually asking for evidence of.

[lex00]

"The published image matches main" is now true — v0.3.0 is cut from main and both :v0.3.0 and :latest carry -serve-sts. See #65 for what was wrong and how it was found.

That leaves #54's honest four:

• Failure-injection levers reachable from outside the process (Failure-injection levers have no HTTP surface, so a container consumer cannot reach them #56)
• A second pair of eyes on internal/vms
• What m80 does when asked something the model allows and no recording covers
• Someone who is not us following the docs, on a machine that is not ours

Plus "more than one consumer", which has moved: kubemicrovm-ops now drives m80 through the operator's reconcile loop across three deployment tiers, on every push, on a hosted runner. That is not the same as an outside consumer, but it is a second usage shape rather than a second copy of the first.

[lex00]

Two more items done, and the remaining two need a person rather than a commit.

Failure-injection levers reachable from outside the process — done, #56 merged. POST /_m80/inject behind -enable-injection. Verified against the container rather than in-process: armed a build over HTTP, created the image with the AWS CLI, watched the version settle FAILED.

The docs site says the same things as the README — done in the same PR. It had drifted, and in the worst possible place: -serve-sts appeared in four doc pages and nowhere in the README, while being the flag that decides whether the KubeMicroVM operator starts at all. Found by diffing the runtime flags each surface names rather than by reading, which is the only way this item stays closed — it is on the list precisely because they have drifted before.

That leaves these, and neither is something the repo can do to itself:

• A second pair of eyes on internal/vms. The item's own wording is "one person wrote it and one person reviewed it", so what closes it is a reviewer who is neither. I can do an adversarial pass over the concurrency and write up what I find, but it would be a third opinion of the same kind, not the independent one being asked for. Worth saying which is wanted.
• Someone who is not us follows the quick start, on a machine that is not ours, and we watch. No substitute for this exists. scripts/smoke.sh proves the walkthrough works; it cannot prove it is followable.

Two others are decisions rather than work:

• A run on Linux. Every container run is a Linux run, and CI is Linux, so what is actually unchecked is a native Linux desktop. If that is the bar, it needs a Linux box. If container-plus-CI is enough, the item can be closed as written.
• More than one consumer. kubemicrovm-ops now drives m80 through the operator's reconcile loop across three tiers on every push. That is a second usage shape rather than a second party, so whether it counts is a judgement call — it does not close the underlying worry, which is a gap only an outsider's usage would expose.

What m80 does when asked something the model allows and no recording covers is the last one that is real work, and it is a design decision before it is a patch: today some paths guess, some 501, some model-check. I can survey every such path and propose one rule, but picking the rule is a call worth making deliberately rather than inferring from what the code happens to do.

[lex00]

A run on Linux — done, with one caveat about what it proves.

Full suite, race detector, a natively-built binary and the whole conformance run, inside Linux on arm64 — an architecture CI has never covered, since GitHub runners are amd64:

Linux 6.12.76-linuxkit aarch64 GNU/Linux
go version go1.25.12 linux/arm64

go test ./...            all packages pass
go test -race ./internal/...   clean
go build -o /tmp/m80 ./cmd/m80 && /tmp/m80
    m80 starting version=dev addr=:4290 operations="29/29 implemented"
go run ./conformance/cmd/conformance -endpoint http://localhost:4290
    pass 100, fail 0, unimplemented 0, skipped 0, error 0
    coverage: 29/29 operations exercised

So m80 builds and behaves identically on a second architecture and a second operating system, which is more than the item asked for and was worth checking — a Go program with a clock abstraction and a concurrent store is exactly the shape where an arch difference would show up if one existed.

What it is not: a person sitting at a Linux desktop using it. If the item means "the code runs on Linux", it is closed by the above. If it means "someone has actually worked with it there", that is the same requirement as the cold-run item and should fold into it rather than stand separately — one person on a Linux box closes both.