| `ubuntu-latest` | Container step jobs | glas-harness `container-smoke` |
| `container-build` | Docker build/push jobs | forgejo-actions-probe `image-build` |
### Registry / image CI (from prior probe)
- Org secrets `REGISTRY_USER` / `REGISTRY_TOKEN` via `PUT /api/v1/orgs/coulomb/actions/secrets/{name}` with plaintext `data` (HTTPS API).
- Host runner has **no**`docker` CLI and **cannot**`apk add` (non-root). Use **static docker binary** in the job step.
-`actions/checkout@v4`**fails** on host runner — use `git clone` in the job until resolved.
## Routing that does not work yet
| Gap | Impact | Mitigation for next repos |
| --- | --- | --- |
| `tegwick` Gitea user not on Forgejo | SSH as `git@92.205.130.254` (Gitea) ≠ `git@92.205.62.239` (Forgejo); keys are per-forge | Register operator keys on Forgejo users before cutover; or use `forgejo_admin` interim |
| No automated Gitea→Forgejo mirror | Gitea copy drifts after Forgejo becomes canonical | Staged cutover: freeze Gitea pushes, one-way mirror, or retire Gitea remote after verification |
| `actions/checkout@v4` on host runner | Breaks multi-step workflows that depend on checkout | `git clone` in `run:` step (see image-build probe) |
| Issues/wiki/releases/LFS | Not exercised in pilot | Classify per repo in migration inventory before production repos |
| State Hub `remote_url` field | Still points at `gitea-remote:…` for most repos | Update registration when repo is promoted (separate step; not done for glas-harness) |
## Repeatable procedure (non-production repo)
1. Confirm repo is **not** in a production drain wave or has explicit operator approval.
2. Create empty repo on Forgejo (`auto_init: false` if mirroring existing history).
3. Push all branches/tags from workstation clone (HTTPS or SSH).
4. Add `forgejo-remote` remote; rename Gitea remote to `gitea`; set `origin` to Forgejo.
5. Add `.forgejo/workflows/` smoke (and image workflow if applicable).
6. Verify Actions green on Forgejo runner.
7. Leave Gitea repo read-only; do not delete (safety contract).
8. Record results in this doc or a per-repo row in the migration inventory.