vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Activity

docs: the agent config meta-flake input is the local applied mirror, not forge git+http

Browse source 
config-changes.md § Meta flake, hive-c0re nix comments and the meta.rs/exec.rs
doc comments still described the declared agent-<n> input as a forge-hosted
git+http repo; meta.rs renders git+file://<applied>.
This commit is contained in:
atlas 2026-10-10 00:42:10 +02:00 • committed by mara
commit 295e8af43a
5 changed files with 33 additions and 36 deletions
Download patch file Download diff file Expand all files Collapse all files

31
docs/agent-lifecycle/config-changes.md
View file

@ -114,27 +114,26 @@ transient.
The hive-c0re-owned repo at `/var/lib/hyperhive/meta/`
declares one flake input per agent (`agent-<n>.url =
"git+http://<forge>/agent-configs/<n>.git"`) and one
"git+file://<applied>"`, the agent's local `applied` mirror) and one
`nixosConfigurations.<n>` output per agent. Each output wraps
`inputs.agent-<n>.nixosModules.default` with the identity +
`HIVE_PORT` / `HIVE_LABEL` / `HIVE_DASHBOARD_PORT` injection module.
Containers run against `--flake /var/lib/hyperhive/meta#<n>`.
The declared input url is the agent's **forge config repo** (the
same `agent-configs/<n>` config PRs merge into), so the meta flake
references a reviewable, reproducible source rather than a local
checkout. hive-c0re authenticates that `git+http` fetch via a git
credential helper that reads the live forge-core token — no token in
the url or the lock. The rebuild paths, however, do **not** re-lock
from the forge: they `--override-input agent-<n>
git+file:///var/lib/hyperhive/applied/<n>`, locking the exact config
`applied/<n>/main` was fast-forwarded to. That keeps a rebuild
reproducible and independent of forge reachability — rebuilds fire on
crash-restart and meta bumps, not just config merges — while the
declared url stays the forge. `sync_agents` re-renders + re-locks the
persistent input; a plain `nix flake lock` leaves an existing applied
override in place (it only re-locks when the declared url itself
changes), so the forge-declared / applied-deployed split is stable.
The declared input url is the agent's **local `applied` mirror**
(`/var/lib/hyperhive/applied/<n>`) of its forge config repo
(`agent-configs/<n>`, the one config PRs merge into). The meta flake
therefore resolves entirely from on-disk state: building, and booting,
never depend on the forge being reachable. hive-c0re fills the mirror
by fast-forwarding `applied/<n>/main` to the merged config commit,
reading the forge with the hive's read token
(`forge::reader_token()`); the forge repo is the review and audit
surface, not a flake input. The rebuild paths re-lock the input with
`--override-input agent-<n> git+file:///var/lib/hyperhive/applied/<n>`,
locking the exact config `applied/<n>/main` was fast-forwarded to.
Rebuilds fire on crash-restart and meta bumps, not just config
merges, so the lock stays on that head. `sync_agents` re-renders and
re-locks the persistent input.
Lock updates are single-phase and commit when the lock changed:
`meta::lock_update_for_rebuild(name)` relocks one agent's input for a