@@ -699,6 +699,21 @@ jobs:
           username: ${{ secrets.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
 
+      # ⛔ A pinned tag is created once and never pointed anywhere else:
+      # v<date>, <alias>-v<date> and <alias>-<anchor>. The two steps below pass
+      # this list to scripts/tag-names, which leaves out each pinned tag already
+      # on it. So a second build on one day, or with one pacman version, moves
+      # latest and <alias> only. GHCR is read because every digest is staged
+      # there and both registries get their tags from one command. A list that
+      # cannot be read stops the job, because read as empty it would move every
+      # pinned tag. HISTORY/pinned-tags.md.
+      - name: Read the tags the repository already carries
+        env:
+          TARGET_IMAGE: ${{ needs.resolve.outputs.target_image }}
+        run: |
+          set -euo pipefail
+          scripts/registry-tags ghcr.io "${TARGET_IMAGE#ghcr.io/}" > /tmp/existing-tags.txt
+
       # Only for what built in this run. A carried architecture's tags already
       # point at the image it carries, so they are left exactly where they are.
       - name: Create the per architecture tags
@@ -721,7 +736,13 @@ jobs:
               continue
             fi
             anchor="$(jq -er --arg a "$arch" '.[$a]' <<< "$ANCHORS")"
-            mapfile -t tags < <(scripts/tag-names arch "$arch" "$VERSION" "$anchor" "${images[@]}")
+            mapfile -t tags < <(scripts/tag-names --existing /tmp/existing-tags.txt arch "$arch" "$VERSION" "$anchor" "${images[@]}")
+            # mapfile does not see the exit status of tag-names. The rolling
+            # tags are always printed, so an empty list means it failed.
+            if [ "${#tags[@]}" -eq 0 ]; then
+              echo "scripts/tag-names printed no tag for $arch, and its reason is above" >&2
+              exit 1
+            fi
             args=()
             for t in "${tags[@]}"; do
               args+=(-t "$t")
@@ -748,7 +769,11 @@ jobs:
             echo "the plan names no image, so there is no index to create" >&2
             exit 1
           fi
-          mapfile -t tags < <(scripts/tag-names index "$VERSION" "${images[@]}")
+          mapfile -t tags < <(scripts/tag-names --existing /tmp/existing-tags.txt index "$VERSION" "${images[@]}")
+          if [ "${#tags[@]}" -eq 0 ]; then
+            echo "scripts/tag-names printed no index tag, and its reason is above" >&2
+            exit 1
+          fi
           args=()
           for t in "${tags[@]}"; do
             args+=(-t "$t")
@@ -771,18 +796,27 @@ jobs:
           # fail on its own, and until this step covered it a Docker Hub tag that
           # never arrived, or arrived without every platform, ended a green run.
           verify_index() {
-            local image="$1" dated got expect arch
-            # The dated index tag carries a leading v. scripts/tag-names is the
-            # authority on the spelling, so it is asked rather than
-            # reconstructed: inspecting a tag the publish job never created
-            # would fail every run.
+            local image="$1" latest dated got expect arch
+            # scripts/tag-names is the authority on the spelling, so it is
+            # asked rather than reconstructed: inspecting a tag the publish job
+            # never created would fail every run.
+            latest="$(scripts/tag-names index "$VERSION" "$image" | grep ':latest$')"
             dated="$(scripts/tag-names index "$VERSION" "$image" | grep -v ':latest$')"
-            echo "verifying $dated"
+
+            # ⛔ latest is the index this run wrote. The dated index is pinned:
+            # the first build of the day creates it and a later one leaves it,
+            # so its platforms are that build's. It has to exist, whichever
+            # run created it.
+            if ! docker buildx imagetools inspect "$dated" > /dev/null; then
+              echo "$dated does not exist after the publish" >&2
+              exit 1
+            fi
+            echo "verifying $latest"
 
             # The index must carry every platform the plan put in it, built or
             # carried. An index with a hole in it is the failure this whole
             # topology exists to prevent.
-            got="$(docker buildx imagetools inspect "$dated" --raw \
+            got="$(docker buildx imagetools inspect "$latest" --raw \
               | jq -r '[ .manifests[].platform
                          | select(.os != "unknown")
                          | .architecture + (if .variant then "/" + .variant else "" end) ]
@@ -799,14 +833,14 @@ jobs:
                 continue
               fi
               if ! grep -qw -- "$expect" <<< "$got"; then
-                echo "the index for $dated is missing $expect" >&2
+                echo "the index for $latest is missing $expect" >&2
                 echo "it carries: $got" >&2
                 echo "the digests were staged on ${TARGET_IMAGE}. If that index is" >&2
                 echo "complete and this one is not, the cross-registry copy is what failed." >&2
                 exit 1
               fi
             done
-            echo "::notice::published $dated with platforms $got"
+            echo "::notice::published $latest with platforms $got, and $dated exists"
           }
 
           verify_index "$TARGET_IMAGE"
 
@@ -262,8 +262,8 @@ name anyway, the spelling ArchPOWER itself uses: `powerpc`, `powerpc64`,
 It is a fork of `fwcd/docker-archlinux` in GitHub's data model only. ⛔ Treat it
 as independent. Do not sync from upstream. Do not describe it as a fork.
 
-198 tracked files, 21 scripts, 10 workflows, 35 test files, 7 examples,
-54 documents under `HISTORY/`. Measured 2026-10-15 at this session's last
+199 tracked files, 21 scripts, 10 workflows, 35 test files, 7 examples,
+55 documents under `HISTORY/`. Measured 2026-10-15 at this session's last
 commit, with `git ls-files | wc -l`,
 `ls scripts`, `ls .github/workflows`, `ls tests/static/*.sh tests/image/*.sh`,
 `ls examples | grep -v README` and `find HISTORY -name '*.md'`.
@@ -338,7 +338,7 @@ asserted by `tests/image/50-consumer-contract.sh`.
 | `scripts/check-mirror-lag` | `keep`, or `drop <server>` when the first server of one port's list is more than `MIRROR_LAG_MAX` seconds behind the next one, on any section that reads that list. The resolve job runs it for every port before the anchor. `HISTORY/ghcr-mirror.md` |
 | `scripts/build-pacman-static` | links a static pacman for one architecture, from source, against the pin |
 | `scripts/release-notes` | writes a release body and `SHA256SUMS` from the evidence files beside the assets |
-| `scripts/tag-names` | prints the tags for one architecture, or for the index |
+| `scripts/tag-names` | prints the tags for one architecture, or for the index. ⛔ With `--existing`, leaves out each pinned tag already in the repository, so a pinned tag is created once and never moves. `HISTORY/pinned-tags.md` |
 | `scripts/gen-evidence` | writes the per-platform evidence file |
 | `scripts/check-keyring-pin` | exit 0 current, 3 behind, 4 gone from the mirror, 5 bytes changed, 6 unreachable, 7 a newer package no pinned key signed. `--apply` moves the pin and the package in the tree together |
 | `scripts/check-image-pins` | every `@sha256:` against its `# tag:` marker. `--apply` rewrites |
@@ -350,7 +350,7 @@ asserted by `tests/image/50-consumer-contract.sh`.
 | `scripts/keep-schedules-enabled` | enables every workflow in the tree, so 60 quiet days cannot switch the schedules off |
 | `tests/static/` | 29 files, no container needed |
 | `tests/image/` | 6 files, against a built image |
-| `HISTORY/` | 54 documents, 28 of them reviews. ⛔ never the manual. `CONTINUE.md` is the exception: it is this file |
+| `HISTORY/` | 55 documents, 28 of them reviews. ⛔ never the manual. `CONTINUE.md` is the exception: it is this file |
 | `README.md`, `docs/` | the manual |
 
 ### Running the tests
@@ -720,6 +720,7 @@ manual cross reference remap.
 | 58 | Renovate configured in the tree, and its pin bumps approved and merged once CI passes, behind a guard that refuses anything but a hash, a digest or a version comment. Six Renovate pull requests merged by hand first, each hash checked against its tag | `.github/workflows/bot-merge.yml`, `tests/static/89-bot-merge-guard.sh` |
 | 59 | Tag lists read page by page, every schedule re-enabled daily from two workflows, the watchdog reading the plain run list it had been misreading, and mirror age and reachability reported rather than gating every build | `scripts/registry-tags`, `scripts/keep-schedules-enabled`, `tests/static/40-mirrors-reachable.sh` |
 | 60 | The five ports the GHCR mirror carries read it first, in the build and in the shipped list, with the upstream servers after it. A build compares it with the next server first and builds without it when it is more than 12 hours behind. Three PowerPC anchor files carried markers encoded twice, now repaired, with a test | `HISTORY/ghcr-mirror.md`, `tests/static/66-mirror-lag.sh`, `tests/static/98-text-encoding.sh` |
+| 61 | A pinned tag is created once and never moves: `v<date>`, `<alias>-v<date>` and `<alias>-<anchor>`. `v2026.08.26` had been created by five real builds and `v2026.08.28` by three, and every anchor tag moved each day. The publish reads the target's tags first and creates only the pinned ones that are absent; `latest` and `<alias>` move as before | `HISTORY/pinned-tags.md`, `tests/static/60-tag-families.sh`, `tests/static/35-publish-targets.sh` |
 
 ---
 
@@ -850,6 +851,12 @@ architecture path is no longer a hole in anything. What remains to decide is
 whether a dispatch input naming one architecture is worth the saved runner
 time, given that the others would be rebuilt identically and tagged anyway.
 
+⚠ **A dispatch on a day that already published moves the rolling tags only**,
+since 2026-10-15. `latest` and `<alias>` get the rebuilt image; that day's
+`v<date>` and `<alias>-v<date>` keep the morning's. A consumer who pinned the
+dated tag keeps what they pinned, which is the point of the rule.
+`HISTORY/pinned-tags.md`.
+
 ### 5. Done. See Completed row 54.
 
 ⛔ **The number is kept and the body is gone.**
@@ -1067,6 +1074,13 @@ unexplained; what is new is that a recurrence now turns something red.
 
 ## Where things stand
 
+⭐ **2026-10-15: a pinned tag is created once and never moves.**
+`HISTORY/pinned-tags.md`. `v<date>`, `<alias>-v<date>` and `<alias>-<anchor>`
+had all moved: the dated ones on 2026-08-26 and 2026-08-28, the anchor ones on
+every build. The publish now reads the target's tag list first and creates only
+the pinned tags that are absent. ⚠ The anchor tags that exist stay on the image
+the last build before this change gave them.
+
 ⭐ **2026-10-15: the five ports the GHCR mirror carries build from it first.**
 `HISTORY/ghcr-mirror.md`. The shipped lists of amd64, arm64, armv7, loong64 and
 riscv64 name `ghcr.mirror.archlinux.pkgforge.dev` first and the upstream
@@ -1078,9 +1092,9 @@ when it is more than 12 hours behind; the image still ships it. In short:
   repository in 441 s, against 544 s for scheduled run `38549236313`. Every
   build step was shorter, riscv64 by a third. One sample each.
 - ⚠ No real tag moved in this session. The first scheduled run after this
-  commit is the first real publish from the mirror. ⛔ A dispatch on the same
-  day as the primary cron moves that day's dated tags, because only the backup
-  cron stands down when `v<date>` exists. Not fixed here.
+  commit is the first real publish from the mirror. A dispatch on the same
+  day as the primary cron moved that day's dated tags; the entry above closes
+  that.
 - The arm64 and armv7 `extra` sections measured 21147 s behind, real lag of the
   mirror's own upstream reads, not of this repository. 43200 is the bound.
 
 
@@ -0,0 +1,135 @@
+# Pinned tags are created once
+
+⭐ **Decided 2026-10-15.** A pinned tag is created by the first build that
+names it and is never pointed at another image: `v<date>`, `<alias>-v<date>`
+and `<alias>-<anchor>`. `latest` and `<alias>` move with every build. The
+maintainer asked for the rule that is easier to maintain. This is it: one rule
+for every pinned family, in one place, under one test. The other choice, an
+anchor tag that follows the newest build with its pacman version, is a second
+rule with its own tests.
+
+## What moved
+
+`README.md` said all three pinned families never move. The publish job created
+every tag on every build, and only the backup cron stood down when the day's
+`v<date>` existed. So a second real publish on one day moved that day's dated
+tags. The runs whose `Create tags` job succeeded, read from their logs:
+
+```bash
+gh run list --workflow build-deploy.yml --limit 200 --json databaseId --jq '.[].databaseId'
+gh run view RUN --log | grep -E '^Create tags' | grep -oE 'ghcr\.io/pkgforge-dev/archlinux(-ci)?:v[0-9.]+' | sort -u
+```
+
+| day | real publishes of `v<date>` | runs |
+| --- | --- | --- |
+| 2026-08-26 | 5 | `32992678276`, `33003974783`, `33005958600`, `33008010432`, `33009605655`, all dispatches |
+| 2026-08-28 | 3 | `33184973002` dispatch, `33195147714` schedule, `33206327128` dispatch |
+| every other day with a real publish, 2026-08-29 to 2026-10-14 | 1 | |
+
+⚠ On 2026-08-28 the last of the three added the PowerPC ports, so
+`v2026.08.28` went from five platforms to eight. Completed row 42 of
+`HISTORY/CONTINUE.md` records that as a result. It was also a pinned tag
+moving.
+
+⚠ The anchor tags moved every day, not only on days with two builds. pacman
+stayed at one version for weeks, and each build created
+`<alias>-7.1.0.r9.g54d9411-2` again. Measured 2026-10-15 on GHCR: `x86_64`,
+`x86_64-v2026.10.14` and `x86_64-7.1.0.r9.g54d9411-2` were one digest,
+`sha256:690e2a8d99a37a5f64c6d45d78d367f9211f94c4e2bf698e57c59b78ab758275`,
+and `x86_64-v2026.10.13` was another. So the anchor tag had moved from the
+2026-10-13 image to the 2026-10-14 image.
+
+## Who pins what
+
+GitHub code search, 2026-10-15:
+
+| search | results |
+| --- | --- |
+| `"pkgforge-dev/archlinux:v2026"` | 11. Nine are outside this repository: three release workflows of `VSCodium/vscodium`, their copies in `crow-cli/crow-cli`, and one each in `stoatchat/for-desktop`, `Chillboio-Studios/Dawnchat-For-DESKTOP` and `edgarcnp/homebrew-tap` |
+| `"pkgforge/archlinux:v2026"` | 1, in this repository |
+| `"pkgforge-dev/archlinux:x86_64-v2026"` and the Docker Hub name | 0 |
+| `"pkgforge-dev/archlinux:x86_64-7"` and the Docker Hub name | 0 |
+
+```bash
+gh api -X GET search/code -f q='"pkgforge-dev/archlinux:v2026"' --jq .total_count
+```
+
+The dated index is what consumers pin, and a moved one gives a consumer who
+pinned it another image. No result pins an anchor tag, so freezing those is a
+change nobody found in use.
+
+## How
+
+1. The publish job reads the target repository's tag list with
+   `scripts/registry-tags`, before it creates a tag. GHCR is read because every
+   digest is staged there, and one `imagetools create` gives both registries
+   their tags.
+2. Both tag steps pass that list to `scripts/tag-names --existing`, which
+   leaves out each pinned tag on it and names it on stderr. A tag that is not
+   passed to `imagetools create` cannot move.
+3. The verify step reads the platforms of `latest`, which this run always
+   writes, and requires the dated index to exist. A dated index from an earlier
+   build of the day carries that build's platforms.
+
+⛔ A list that cannot be read stops the publish. Read as empty, it would move
+every pinned tag. That is the same choice as the anchor floor: a guard that a
+transient switches off is not a guard.
+
+The backup cron still stands down when `v<date>` exists. It saves the runner
+time; it is no longer what keeps the dated tag in place.
+
+## What it changes for a consumer
+
+| case | before | after |
+| --- | --- | --- |
+| a second build on one day, a dispatch or a cron | every tag of that day moves | `latest` and `<alias>` move |
+| a build with the same pacman version as yesterday | `<alias>-<anchor>` moves | `<alias>-<anchor>` stays on the first image with that version |
+| a port that published nothing earlier in the day | its `<alias>-v<date>` is created | the same |
+| the emergency path, TODO 4: a dispatch after the day published | moves every tag of the day | moves the rolling tags. The fix reaches `latest` and `<alias>`, and the dated tags keep the morning's image |
+
+⚠ An anchor tag that exists now stays where it is, so each
+`<alias>-7.1.0.r9.g54d9411-2` keeps the image it pointed at when this change
+landed.
+
+⚠ If the first image with a pacman version is defective, its anchor tag keeps
+it. The rolling and the next day's dated tags carry the fix.
+
+## Measured
+
+Dry run `38675434990` on a branch, into the scratch repository, the second
+build of 2026-10-15 there. The first was dry run `38670811239`. Digests read
+anonymously before and after, first 12 hex digits:
+
+| tag in `ghcr.io/pkgforge-dev/archlinux-ci` | before | after |
+| --- | --- | --- |
+| `latest` | `445762b79215` | `6ee338a7249d` |
+| `v2026.10.15` | `445762b79215` | `445762b79215` |
+| `x86_64` | `316148d98390` | `dc77face842c` |
+| `x86_64-v2026.10.15` | `316148d98390` | `316148d98390` |
+| `x86_64-7.1.0.r9.g54d9411-2` | `316148d98390` | `316148d98390` |
+| `aarch64` | `ddf3f281cbab` | `e74f4e376390` |
+| `aarch64-v2026.10.15` | `ddf3f281cbab` | `ddf3f281cbab` |
+| `aarch64-7.1.0.r9.g54d9411-2` | `ddf3f281cbab` | `ddf3f281cbab` |
+| `riscv64` | `aa6be4315646` | `80b633486e7b` |
+| `riscv64-v2026.10.15` | `aa6be4315646` | `aa6be4315646` |
+| `riscv64-7.1.0.r9.g54d9411-2.1` | `aa6be4315646` | `aa6be4315646` |
+
+The rolling tags moved and the pinned ones did not. The tag steps named 21
+pinned tags as kept, which is every pinned tag of the five ports that built,
+four for amd64, arm64 and loong64, six for armv7, two for riscv64, and
+`v2026.10.15`. The verify step read the platforms of `latest`:
+`published ghcr.io/pkgforge-dev/archlinux-ci:latest with platforms amd64 arm/v7 arm64 loong64 ppc ppc64 ppc64le riscv64, and ghcr.io/pkgforge-dev/archlinux-ci:v2026.10.15 exists`.
+
+```bash
+gh run view 38675434990 --log | grep -E '^Create tags' | grep -c 'is pinned and exists'
+```
+
+## What this does not verify
+
+- ⚠ Docker Hub. The list is read from GHCR only. A pinned tag that exists on
+  GHCR and not on Docker Hub, because an earlier copy failed, is not created on
+  Docker Hub again. That earlier run's verify step fails loudly on the missing
+  copy.
+- ⚠ Two aliases of one architecture can diverge if one pinned name exists and
+  the other does not. Both are created by one command, so that needs an earlier
+  partial failure.