2026-09-11 19:56:50 +00:00
1 changed files with 21 additions and 3 deletions
@@ -1,8 +1,8 @@
 ---
-status: open
+status: resolved
 opened: 2026-09-10
-located-in: []
-fixed-by:
+located-in: [mesh-catalog]
+fixed-by: mesh-catalog — the operator's own images are pinned by digest
 amended-design:
 ---

@@ -44,6 +44,24 @@ often.
 incidentally is an invariant no bed tests. The harness was not merely serving images; it was
 quietly supplying a property of the system under test, and nothing said so.

+## Fixed, and what the fix does not settle
+
+Each of the nine references now names the digest its tag resolved to, read from the registry that
+serves them. Every manifest in the catalogue is pinned; the host's refusal has nothing left to
+catch, and the check that would have caught this — *no manifest names a tag* — now passes on
+content rather than on a harness's rewriting.
+
+**It is a stopgap and should be read as one.** A digest written into a repository is wrong the
+moment anybody rebuilds, which is exactly the argument
+[`12-a-module-repository`](../../03-DESIGN/01-to-be/12-a-module-repository.md) makes for two
+documents — the repository naming *artifacts*, the mesh holding *digests*. Until something builds
+and publishes, a digest that goes stale is still better than a tag that moves without telling
+anyone: stale fails loudly at the pull, and a moved tag changes what a machine runs while every
+record says nothing changed.
+
+So the open questions below stand. What closed is the immediate fault; what remains is the reason
+it was possible.
+
 ## Open questions

 - What should a manifest name for an image the operator builds themselves? A digest changes on