diff --git a/TODO.md b/TODO.md
index eeb6e03..4bb237b 100644
--- a/TODO.md
+++ b/TODO.md
@@ -707,3 +707,35 @@ Nothing here is urgent; all are low-risk, no-downtime changes.
       description says this repo "is in process of being merged into
       https://packages.sury.org/php/" - a future migration to watch for,
       not an action item yet.
+
+- [ ] **Gitea: no redirect from the old `jayfield` username to `jens`** — found 2026-07-26
+      User asked why every repo's owner now shows as `jens` after the
+      2026-07-26 admin-user rename - answer: expected, not a bug. There
+      was only ever one Gitea account (id `1`); Gitea tracks repo
+      ownership by that numeric id, not by username string, so renaming
+      the one account that owned all 89 repos instantly relabels every
+      one of them - nothing was moved or duplicated. Confirmed via
+      `gitea admin user list` (exactly one account, `jens`, same id) and
+      the repo-search API (all 89 repos show `owner id: 1`).
+      While checking, found `README.md`'s claim that the old
+      `/jayfield/...` paths still `200` via Gitea's automatic
+      rename-redirect no longer holds - both `/jayfield` (bare profile)
+      and `/jayfield/docs-alpha.jayfield.org` now `404` live, and
+      Gitea's own `user_redirect` table (`gitea.db`, queried directly
+      via `sqlite3` inside the container) is empty. Either the redirect
+      was never actually persisted or something since cleared it;
+      inconclusive which. **No functional impact** - this repo's own
+      `origin` and every other reference already use `/jens/...` - just
+      means old bookmarked/shared `/jayfield/...` links 404 instead of
+      redirecting. `README.md` still needs correcting to drop that
+      "returns 200" claim.
+      Also discussed creating a Gitea **organization** named `jayfield`
+      (the username is unclaimed now that no redirect reserves it) -
+      would NOT restore the old redirect or retroactively own anything;
+      it'd be a brand-new entity, and existing repos would only move
+      under it via an explicit, one-by-one transfer (which changes every
+      clone URL from `/jens/repo` to `/jayfield/repo`, including this
+      very repo's `origin`). Real motivation would be team-based
+      permissions if `alex` ever needs genuine admin rights on some
+      repos rather than everything depending on the one personal `jens`
+      account - not pursued now, no action taken.