Retain only the verified production latest image

docs/deployment/GITEA_CD.md

@@ -107,7 +107,7 @@ been performed during implementation; those are first-run acceptance steps.
    an immutable rollback tag so normal dangling-image cleanup cannot remove it.
 4. Refuse a stale checked-out `main` revision that no longer equals remote main.
    Build an immutable `release-<commit>-<owner>` tag locally, without a registry
-   and without changing `latest` or CI image tags.
+   then point `latest` at the candidate; CI image tags are never changed.
 5. Persist a `prepared` journal with old/new runtime configs. Create an additive
    SQLite online backup under `/data/deploy-backups/<owner>.db`. No data/config
    directory or file is removed, replaced or recursively chowned.
@@ -266,7 +266,7 @@ as an Actions artifact. First bootstrap has no prior healthy version to roll bac
    `192.0.2.10:18787` binding (not loopback).
 4. Open `http://192.0.2.10:18787/api/v1/version`; its `commit` must equal the full
    workflow checkout commit. Check `/ready` returns HTTP 200. The immutable image tag
-   is `pigway-frame-flow:release-<commit>-<transaction>`; compare its image ID in
+   is `pigway-frame-flow:latest`; compare its image ID in
    Container Manager with the running container.
 5. Keep `PROD_DEPLOY_ENABLED=true`. Subsequent main pushes Verify then deploy using
    this same runtime and journal mechanism. The first update records bootstrap as
@@ -366,17 +366,15 @@ complete audit succeeded.
 
 ### Production image retention
 
-After a deployment passes verification and its success journal is saved, Frame Flow
-removes obsolete release and rollback images from the
-configured production image repository. It retains the running version and the
-previous deployment baseline for one-step rollback. Images referenced by any
-container (including stopped containers), images with unrelated tags, and CI
-images are protected. Retention does not prune build cache, volumes, or data.
-Failed deployments do not run retention; cleanup failure produces a warning and
-never rolls back a successfully verified deployment. Historical deployment
-journals remain available for audit, but only the latest rollback image is
-retained locally; older releases require rebuilding before use.
+Production uses `pigway-frame-flow:latest`. Builds first create a unique release
+image, then tag it as latest before activation. The old image is pinned during
+an update so a failed deployment can restore it. Only after the new version
+passes verification are old release/rollback images and duplicate tags removed.
+After successful deployment, only the current production image remains; there
+is no retained historical image for manual rollback. Rebuild a historical
+revision before manually reverting a successful deployment.
 
-The rollback image keeps one tag: its original `release-<commit>-<owner>`
-tag with `-rollback` appended. Duplicate release/legacy rollback tags are removed
-only after the rollback alias exists, and container-referenced tags remain protected.
+Images referenced by other containers (including stopped containers), images
+with unrelated tags, and CI resources remain protected. Cleanup never prunes
+volumes, data, or shared build cache. Cleanup failure is a warning and does not
+roll back a verified deployment. Failed deployments do not run cleanup.