T07: full gitea sweep — CoulombCore runs two registry services, not one

gitea.coulomb.social also serves a PyPI package index, so the container-image
finding was half the exposure.

Classified every operational reference by whether anything can still act on it.
Live and must move: reuse-surface's Deployment image, and kaizen-agentic, which
never migrated at all — it publishes to gitea PyPI and its README and five docs
instruct users to pip install from it, with no forgejo equivalent in the repo.
issue-core already dual-publishes and only needs its legacy gitea target retired.

Deliberately left alone: tests asserting historical facts, inventory snapshots,
asset registers and a Dockerfile comment. They record that gitea existed, which
remains true after it is switched off; rewriting them would destroy history to
tidy a grep.

Flagged unswept: CI runners, and any credential lane authenticating to gitea.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

DECISIONS.md

@@ -90,9 +90,30 @@ This fails in the most inconvenient way available. Running pods survive
 decommission because their images are already pulled locally — **so nothing
 breaks on the day**. The failure arrives at the next restart, reschedule, node
 reboot or scale-up, as `ImagePullBackOff`, at a moment chosen by circumstance
-rather than by us. And one of the two is **State Hub's own migration job** — the
-service this entire project exists to retire in an orderly way, unable to run its
-schema migration.
+rather than by us.
+
+**Corrected 2026-08-20, same day.** The first version of this entry treated both
+references as equally live and said State Hub would be "unable to run its schema
+migration". That overstated it, and the two cases are not alike:
+
+- **`reuse-surface` is the real one.** A *live Deployment* pulling
+  `gitea.coulomb.social/coulomb/reuse-surface:e3ae22e` — a commit from
+  **2026-07-07 18:25**, now **22 commits** behind main (2026-07-30). Its CI
+  moved to `REGISTRY: forgejo.coulomb.social` at **21:25 the same day**, three
+  hours later, and has been publishing `:latest` and `:main-<short>` there ever
+  since. The producer migrated; the consumer never did.
+- **`state-hub` is largely a false alarm.** Its *Deployment* already runs
+  `forgejo.coulomb.social/coulomb/state-hub:main-d8808bf` — correctly migrated,
+  current tag scheme. The only gitea reference is a **completed one-shot Job**
+  (`state-hub-alembic-init`, 1 succeeded, completions 1, created 2026-07-06)
+  that does not re-run on its own. It matters only if something recreates it
+  from a chart template still carrying the old image, which is worth fixing but
+  is not an outage waiting to happen.
+
+The correction is recorded rather than edited away because the *method* produced
+it: enumerating workload image references found both, and only checking each
+one's liveness separated a live staleness from a historical artifact. **An image
+reference is not a dependency until something can act on it.**
 
 `forgejo.coulomb.social` already runs on railiance01, so the destination exists
 and the work is retag, push, update manifest. Routed to `railiance-platform`.

WORK-RECORDS.md

@@ -22,3 +22,4 @@
 | task | SHR-WP-0002-T04 | todo | — | workplans/SHR-WP-0002-predecessor-and-deployment-reality.md |
 | task | SHR-WP-0002-T05 | todo | — | workplans/SHR-WP-0002-predecessor-and-deployment-reality.md |
 | task | SHR-WP-0002-T06 | todo | — | workplans/SHR-WP-0002-predecessor-and-deployment-reality.md |
+| task | SHR-WP-0002-T07 | todo | — | workplans/SHR-WP-0002-predecessor-and-deployment-reality.md |

workplans/SHR-WP-0002-predecessor-and-deployment-reality.md

@@ -238,6 +238,7 @@ decision route rather than adding it unilaterally.
 id: SHR-WP-0002-T07
 status: todo
 priority: high
+state_hub_task_id: "07636ddf-a26b-4760-8353-2532af9fd938"
 ```
 
 **The registry dependency, found 2026-08-20 and not previously tracked.**
@@ -249,8 +250,71 @@ is the complete set).
 
 Nothing breaks on decommission day, because running pods already hold their
 images. It breaks at the next restart, reschedule or scale-up, as
-`ImagePullBackOff`. One of the two is **State Hub's own migration job** — this
-project's subject, unable to run its schema migration.
+`ImagePullBackOff`.
+
+**The two are not equally urgent** (corrected 2026-08-20 after checking each
+reference's liveness):
+
+- **`reuse-surface` — live and stale.** A running Deployment on the old
+  registry, pinned to a 2026-07-07 commit and **22 commits behind** main. Its CI
+  switched to forgejo three hours after that commit and has published there ever
+  since; the deployment was never repointed. **This is the one that must move
+  before 2026-08-31.**
+- **`state-hub` — mostly a false alarm.** The Deployment is already on
+  `forgejo.coulomb.social/coulomb/state-hub:main-d8808bf`. The gitea reference is
+  a *completed* one-shot Job that will not re-run by itself; the residual risk is
+  a chart template recreating it. Worth cleaning, not urgent.
+
+There was **no repository rename**. This is a registry migration (gitea →
+forgejo, early July) in which producers moved and some consumers did not.
+
+### Full sweep, 2026-08-20 — CoulombCore runs *two* registry services
+
+The first pass looked at container images. `gitea.coulomb.social` also serves a
+**PyPI package index** (`/api/packages/coulomb/pypi`), confirmed by
+`railiance-fabric/fabric/interfaces/railiance-forge-python-package-index.yaml`.
+Both die on 2026-08-31.
+
+Sweeping every repo for `gitea.coulomb.social` in operational files (yaml, sh,
+py, Makefile, Dockerfile, toml, json) and classifying by whether anything can
+still act on it:
+
+**Live, must move before 2026-08-31**
+
+| Reference | What breaks |
+| --- | --- |
+| `reuse-surface` Deployment image | Next restart → `ImagePullBackOff`. Also 22 commits stale |
+| `kaizen-agentic` Makefile + README + 5 docs | **Never migrated at all.** Publishes to gitea PyPI and instructs users to `pip install --extra-index-url …gitea…`. No forgejo equivalent exists in the repo |
+
+**Live but already dual-pathed — retire the old half**
+
+| Reference | Note |
+| --- | --- |
+| `issue-core/Makefile:240` publishes to gitea PyPI | Line 250 already publishes to forgejo. The gitea target is legacy and should go |
+
+**Owned by the thing being decommissioned — expected**
+
+`railiance-forge` (`manifests/gitea-ingress.yaml`, `helm/gitea-registry-values.yaml`,
+`tools/gitea-runner-status.sh`) owns gitea itself; these retire *with* it.
+
+**Not live — leave alone**
+
+Tests asserting historical facts (`railiance-fabric`, `markitect-main`,
+`reuse-surface/tests/test_forge_host.py`, `railiance-platform/tests/…`),
+inventory snapshots and asset/data registers (`disaster-control`,
+`domain-tree`, `railiance-fabric` snapshots), agent session blobs, and
+`issue-core/Dockerfile:5` (a comment). These *record* that gitea existed, which
+stays true after it is switched off. Rewriting them would destroy history to
+tidy a grep.
+
+**One to check, not ours:** `railiance-platform/argocd/bootstrap/01-railiance-tenants-project.yaml:14`
+permits `sourceRepos: https://gitea.coulomb.social/coulomb/*.git`. railiance01
+has no ArgoCD `applications` resource type, so this appears inert — but it is a
+bootstrap file and should be confirmed rather than assumed.
+
+**Not swept:** CI runners and any credential lane authenticating *to* gitea.
+`ops-warden`'s catalog carries `forgejo-admin-api-token`; whether a
+gitea-specific equivalent exists was not checked.
 
 `forgejo.coulomb.social` is already on railiance01, so the work is retag, push,
 update manifest. Routed to `railiance-platform`; ownership of the `reuse-surface`