max / alloy

Stop IMAGE.md explaining astra's absent UPDATE_TARGET as a pending move The registry it named is retired rather than moved: an installed machine updates by applying instructions to itself, so no medium ever names a fleet update source. UPDATE_TARGET is a dev-loop key.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WFBzMprSmNCfvdj2cGZyka

Author: Max Johnson <me@maxj.phd> · 2026-09-08 01:32 UTC

Signed with PGP, not checked

Commit: 77a0b7f1cfe3745c488f3d3edb7f30fc28a0f172

Parent: 053fa79

1 file changed, +3 insertions, -3 deletions

M docs/IMAGE.md +3 -3

			@@ -305,9 +305,9 @@
305	305		fw13 and fw12 both take `UPDATE_TARGET=fw13:5000/alloy:local`, the tag
306	306		`build/dev-push.sh` publishes: fw13 builds its own image and serves it to
307	307		itself, and the tag carries the host name so one registry also feeds fw12 over
308		-	the LAN. astra takes none, because the registry it would name is the one moving
309		-	off astra ahead of its own cut, and naming a destination before that move is
310		-	built would bake a guess into a medium.
	308	+	the LAN. astra takes none, and no medium ever names a fleet update source,
	309	+	because there is not one: an installed machine updates by applying instructions
	310	+	to itself rather than by pulling an image. `UPDATE_TARGET` is a dev-loop key.
311	311
312	312		## Preflight
313	313