# `[2026-09-21]` claude-bot became an org Owner, repos moved to `pfi`, and a dead token had been misreporting permissions for months

**Operator ruling:** claude-bot is an **Owner** in `corviduo` (team 1), `pfi`
(team 4) and `vastblue` (team 5). Verified by reading membership back AND by
exercising it on claude-bot's own token: create/edit/delete in `pfi` all
succeed, `vh/*` correctly still 404s.

⚠ **Why not "admin on vh/*", which is what was originally asked:** `vh` is a
**USER account (id 1), not an organization** — `/orgs/vh` 404s. Gitea has no
namespace-scoped admin for a user namespace. Measured: per-repo `admin`
collaborator grants read but **not** settings (403 on PATCH) — repo settings are
owner-only. So the only working realization of "admin over vh/*" is the
**instance-wide site-admin flag**, which would have given claude-bot the same
blast radius as the token the credential-migration project exists to retire.
Surfaced rather than executed; the operator chose orgs instead.

**`vh/cicada` and `vh/draupnir` transferred into `pfi`** with SHAs preserved,
old paths 301ing, and — verified — **the old ssh remotes still resolve**, since
Gitea redirects git-over-ssh and not just the web URL. Repoint anyway: a remote
living on a redirect depends on the old path staying unclaimed.

⚠⚠ **`~/.config/claude-bot/gitea-token` IS DEAD** — it authenticates as
**nobody** (`/user` → `None`). I had cited its 403s and 404s twice, to the
operator and to a peer, as evidence that claude-bot lacked rights in `vh/*`. The
conclusion survived re-testing with a working credential, but the evidence was
worthless. **A credential that authenticates as nobody returns 403 and 404 for
everything, and that is indistinguishable from a permissions answer.** There
are FOUR token files in that directory; the working one for repo work is
**`gitea-token-repo-create`** (`write:organization`, `write:repository`,
`write:user`).

**Standing authorization (operator, same day):** routine vh-token use for
`vh/*` repo ops no longer gets a flag. Read it from the **vault** —
`secret get 'nh3-dev/.config/gitea/vh-token'` — verified byte-identical to the
disk copy and authenticating as `vh` (id 1, is_admin=True). ⚠ This did not make
the token low-blast-radius; it stopped the class of work being exceptional.

Recorded in auto-memory as `feedback_wrong_resource_before_wrong_peer` and in
`reference_infra_ops_vh_gitea_token_and_sdk_publish`.