Make the Forge token registry follow the forgeAccess flag #12

New issue

Open

opened 2026-07-31 00:54:39 +01:00 by allod-agent · 0 comments

allod-agent commented

2026-07-31 00:54:39 +01:00

Member

Keep the Forge token registry in step with the Forge opt-out flag, so flipping one boolean does not leave a stale entry that fails a check pointing somewhere else.

forgejo-token-groups.json is hand-written and declares a per-machine HTTPS token target plus a local-auth-refresh entry. It is not derived from forgeAccess. Flip an existing machine to forgeAccess = false and its identity stops generating that secret while the registry still declares the target, so the framework's credential-profiles check fails with a message naming the registry and the generated secret — and never mentioning the flag the operator just changed. One fact, whether this machine has Forge access, lives in two places that nothing keeps in step, which architecture.md principle 8 forbids.

A machine born opted out passes today only because nobody added it to the registry. The migration case is the one that breaks, and it is the case a deployment actually hits.

Two ways to close it

Derive each machine's registry targets from forgeAccess in flake.nix, so the JSON stops carrying the fact at all. Preferred if the registry's other consumers can take a generated value.
Or add a check here asserting that a machine with a null forgeTokenFile has neither a forgejo-token-groups.json target nor a local_auth_refresh entry, with a diagnostic that names the flag.

The agent-token side needs nothing: it appears in credentials.nix but has no registry entry, so there is nothing to drift.

Scope

In scope: the registry-to-flag relationship and its check. Out of scope: the forgeAccess mechanism, and how recipient sets are chosen.

Found while reviewing the opt-out completion in allod/archetypes#17. It predates that work — the original forgeAccess change introduced it — but the opt-out is only now complete enough for a deployment to use, which makes this the moment it starts to matter.

Keep the Forge token registry in step with the Forge opt-out flag, so flipping one boolean does not leave a stale entry that fails a check pointing somewhere else. `forgejo-token-groups.json` is hand-written and declares a per-machine HTTPS token target plus a local-auth-refresh entry. It is not derived from `forgeAccess`. Flip an existing machine to `forgeAccess = false` and its identity stops generating that secret while the registry still declares the target, so the framework's `credential-profiles` check fails with a message naming the registry and the generated secret — and never mentioning the flag the operator just changed. One fact, whether this machine has Forge access, lives in two places that nothing keeps in step, which `architecture.md` principle 8 forbids. A machine born opted out passes today only because nobody added it to the registry. The migration case is the one that breaks, and it is the case a deployment actually hits. ### Two ways to close it - Derive each machine's registry targets from `forgeAccess` in `flake.nix`, so the JSON stops carrying the fact at all. Preferred if the registry's other consumers can take a generated value. - Or add a check here asserting that a machine with a null `forgeTokenFile` has neither a `forgejo-token-groups.json` target nor a `local_auth_refresh` entry, with a diagnostic that names the flag. The agent-token side needs nothing: it appears in `credentials.nix` but has no registry entry, so there is nothing to drift. ### Scope In scope: the registry-to-flag relationship and its check. Out of scope: the `forgeAccess` mechanism, and how recipient sets are chosen. Found while reviewing the opt-out completion in allod/archetypes#17. It predates that work — the original `forgeAccess` change introduced it — but the opt-out is only now complete enough for a deployment to use, which makes this the moment it starts to matter.