fix(nix): wire hive-forge-notify into the agent package set

The new daemon's package was added to `nix/packages/default.nix` and
referenced from the forge agent module, but not to the `inherit` list in
the flake's `agentPackages` module — so `hyperhive.packages` never gained
the attribute and every agent container failed to evaluate.

Also drop the crate's `[[bin]]` section: the binary name defaults to the
package name and the path to `src/main.rs`, so all of it was restating
cargo's defaults. The comment explaining why this is a separate process
moves to the top of the manifest, where it isn't attached to a section
that no longer exists.
This commit is contained in:
atlas 2026-07-26 20:59:53 +02:00 committed by mara
commit ee52ddc027
2 changed files with 7 additions and 10 deletions

View file

@ -1,3 +1,9 @@
# `hive-forge-notify` — long-running per-agent Forgejo notification
# poller. Was a `tokio::spawn` inside the `hive-agent` serve loop; it is
# its own process now so a harness restart (or a claude-side stall) does
# not take forge notifications down with it, and so its dependency tree
# (forgejo-api, reqwest, time, url) is not linked into the serve-loop
# binary. Talks to the harness only over the in-agent todo socket.
[package]
name = "hive-forge-notify"
edition.workspace = true
@ -19,13 +25,3 @@ tokio.workspace = true
tracing.workspace = true
tracing-subscriber.workspace = true
url.workspace = true
# `hive-forge-notify` — long-running per-agent Forgejo notification
# poller. Was a `tokio::spawn` inside the `hive-agent` serve loop; it is
# its own process now so a harness restart (or a claude-side stall) does
# not take forge notifications down with it, and so its dependency tree
# (forgejo-api, reqwest, time, url) is not linked into the serve-loop
# binary. Talks to the harness only over the in-agent todo socket.
[[bin]]
name = "hive-forge-notify"
path = "src/main.rs"