The published image predates -enable-injection, so the levers #56 added cannot be reached from any release

[lex00]

-enable-injection exists on main and in no published image.

$ git log -1 --format='%h %ci' v0.3.0
87f35cb 2026-08-02 11:47:31 -0600
$ git log -1 --format='%h %ci %s' --grep=injection main
67151c5 2026-08-02 19:37:01 -0600 feat: the failure-injection levers get an HTTP surface (#66)

#66 landed seven hours after v0.3.0 was tagged, so :v0.3.0 and :latest both predate it.

What it costs

kubemicrovm-ops just tried to use the levers and could not. Its harness runs m80 inside k3d, so the flag goes in the deployment args — and an unknown flag is not ignored, it exits. The whole stand-up crashloops on the emulator:

m80 did not become ready. Its last output:
  -max-account-memory-mib int
  ...
  -serve-sts
  ...

That is the failure mode of #65 exactly, one release later and one flag along. It was diagnosed in seconds this time only because #65's fix made the rollout print m80's own flag list — which is worth something, but the second occurrence of a pattern is the one that says the pattern is the problem.

The consumer has shipped with injection off by default and a comment explaining why, so nothing is broken there. But just break-it — the check that a failed build and a failed connector are reported rather than hung on — cannot run in CI against a published image, which means the failure paths stay untested by the one consumer that wanted them.

Ask

A release from main carrying #66. Minor, since -enable-injection is a new flag.

The pattern, which is the more useful part

Both #55 and #65 were the published image lagging main on something a consumer needed, and #54 has carried "the published image matches main" as an unchecked box throughout. Each has been closed by cutting a release, which fixes the instance and not the shape.

Two candidates:

Release on merge to main, so the tag is never the question. The conformance suite and scripts/smoke.sh already gate the image, so the machinery for deciding whether main is releasable is there.

Or fail loudly when it drifts — a check that a flag on main is absent from :latest, run on a schedule, since that is the exact form all three instances took.

The first is a real change in release posture and worth deciding deliberately. The second is a day's work and would have caught all three.

[lex00]

Fixed by v0.4.0.

$ docker manifest inspect ghcr.io/intentius/m80:v0.4.0 | jq -r '.manifests[].platform.architecture'
amd64
arm64

Gate rehearsed on main via workflow_dispatch before tagging, which is what that path is for — go vet, gofmt, race tests, conformance against the binary, conformance against the built container, and scripts/smoke.sh walking the README quick start. All three jobs green on the tag run too.

Along with #66 it carries #69 (the image-tag data race), #71 (the unrecorded-request rule), #72 and #73.

kubemicrovm-ops has taken it: image pin moved to v0.4.0, injection on by default, and its just break-it step — a failed build and a failed connector, asserted to be reported rather than hung on — runs in CI for the first time.

On the pattern

Leaving the second half of this issue open, because cutting the release did not address it. Three instances now (#55, #65, #74), all the same shape, each closed by a release.

Worth noting what actually contained this one: #65's fix made the m80 rollout print the binary's own flag list on failure, so the consumer diagnosed a stale image in seconds rather than an afternoon. That is not prevention, but it is the cheapest thing that has helped so far, and it argues for the second option in the issue — a check that a flag on main is absent from :latest — over the release-on-merge posture change, which is a bigger decision than this issue should settle on its own.

[lex00]

The instance is fixed and verified: v0.4.0 is published multi-arch and carries -enable-injection, and kubemicrovm-ops has taken it — image pin moved, injection on by default, and its just break-it step (a failed image build and a failed connector, asserted to be reported rather than hung on) runs in CI for the first time.

Closing this rather than leaving it open on its second half, because that half is not about a stale image and does not belong under a title that says it is. Filed as #75: three instances of the same drift, and the two candidate fixes — release on merge, or a check that fails when :latest lacks a flag main defines.

#75 also records the thing that actually contained this one, which was not prevention: #65's fix made the rollout print m80's own flag list, so the consumer diagnosed it in seconds rather than an afternoon.