vh
e52def115c
Archived 15 entries (Recent decisions 14, Tried and abandoned 1) oldest-first to archival-memory.md; 5 held back on the open-deferred-work guard and 164 on the 14-day guard, so the index stays over the soft cap at 477 lines. An over-cap file that keeps live decisions beats a scannable one that lost a belayed item. Four new detail files cover the day: the ops log and its four self-inflicted failure modes, the Booth's two dead controls and the four-iteration layout probe, the Gitea org grant plus the dead claude-bot token that had been misreporting permissions, and the disk triage that rescued a LoRA adapter from a directory this box sweeps at three days. lv-mccarthy's run outcome remains unverified after two days and is the first line of the in-flight section and step 1 of the handoff.
2.4 KiB
[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.