compute_prepared_tag (src/runner/prepare.rs:7-17) hashes only the base-image string and the prepare commands:

hasher.update(image.as_bytes());
for cmd in prepare { hasher.update(b"\n"); hasher.update(cmd.as_bytes()); }
// -> anvil-prepared:<sha[..12]>

No OS, no architecture — even though the runner reports both at registration (src/commands/runner.rs:451-452, std::env::consts::{OS,ARCH}).

Why it’s fine today and won’t stay fine

An amd64 runner and an arm64 runner with the same base image and prepare block compute the identical tag. Today each only ever sees its own local daemon (image_exists_locally checks locally), so they build the same tag independently and never collide.

Two things break that:

1. fangorn/anvil#359 (share prepared images via the registry). Push anvil-prepared:abc123 built on amd64; an arm64 runner pulls abc123 and gets amd64 bytes. image_exists_locally reports a hit, and the step runs the wrong-arch image (Exec format error, or silent emulation). #359 cannot land until the tag is platform-scoped — this is a correctness prerequisite, not an optimization.
2. The base-image string is a lie across arches. hexpm/elixir:1.20.2-...-trixie resolves to different per-arch layers via its multi-arch manifest. Same string in the hash, different actual base bytes. So even the “same base image” assumption the hash encodes is only true within one arch.

Ask

Fold os and arch into the tag hash — the runner already has both. Tag becomes sha256(os ++ arch ++ base_image ++ commands). Cheap, backward-compatible (old images just miss and rebuild once), and it turns #359 from a landmine into a straightforward pull.

This is distinct from fangorn/anvil#357 (which is about the contents a command fetches drifting over time); this is about the platform axis being absent entirely.

Part of fangorn/anvil#354.