07b62612b0
Per mara's go-ahead on hyperhive#3902 ("getting started is good, but
terminal rendering does not go in there i think"):
Moved 21 top-level docs/*.md files into 7 new topic subdirectories
(existing web-ui/, turn-loop/, swarm/, tools/, crates/ untouched):
getting-started/ setup.md
agent-lifecycle/ agent-hierarchy.md, approvals.md, persistence.md
trust-boundary/ boundary.md, security.md
integrations/ forge.md, matrix.md, github.md, knowledge.md
networking/ gateway.md, network.md, snapshot-store.md
scheduler/ jobq.md, coordinator.md, ci.md, observability.md
process/ conventions.md, gotchas.md, pr-review-gate.md
web-ui/ terminal-rendering.md (moved into the EXISTING dir,
per mara's correction to the original getting-started
guess -- it's UI implementation detail, not onboarding)
The physical layout now matches docs/README.md's own topical headers,
which already amounted to this taxonomy -- see the scoping comment on
the issue for the two findings that motivated this (a genuine
duplication between CLAUDE.md's old "Reading paths" list and
docs/README.md's grouped one, since drifted out of sync with each
other; and the flat layout not matching the grouping we already had).
Fixed every cross-reference this moved across the whole repo (~120
files: docs/ internal links at every depth, Rust doc comments, nix
module option docs, crate READMEs) -- verified two ways: a grep sweep
confirming zero remaining references to any old path, and a script
that resolves every markdown link in docs/**/*.md + CLAUDE.md +
README.md against the filesystem and reports anything that doesn't
exist (zero broken links).
Collapsed CLAUDE.md's "Reading paths" section (the duplicate) down to
a pointer at docs/README.md, now the single index. Rewrote
docs/README.md itself to use the new subdirectory paths and added the
one doc it was missing that CLAUDE.md's old copy had (pr-review-gate.md).
Classified all 22 docs/*.md files first via a haiku subagent (mara's
suggestion) on two axes -- proposed grouping and operator-vs-
implementation focus -- before finalizing the taxonomy; spot-checked
the report and found internal inconsistencies (its classification
table disagreed with its own summary section for a few files), so this
taxonomy is my original proposal + the one correction mara gave
directly, not a blind application of the subagent's table. The
operator-focus data it gathered is still useful for a follow-up
content pass (docs skewing 'mixed' rather than pure operator-facing),
not addressed in this PR -- structure only.
nix fmt clean, both pre-push lints clean.
2.1 KiB
hive-forge-notify
Per-agent Forgejo notification poller: a long-running daemon
(hive-forge-notify) that watches the agent's unread notification list
and turns each thread into a todo the harness surfaces in
get_loose_ends. This is why an agent wakes up when someone comments
on its issue or requests its review.
When to use it
Look here when changing what a forge notification says when it
reaches an agent, or when it reaches one at all: the poll cadence, the
self-echo filter, the comment / review / new-item / state-change
wrapper formats, body-excerpt truncation, and the assigned-issue
rollup all live in notify.rs. The behaviour contract — activation
gates, filtering rules, the review-request override — is documented in
docs/integrations/forge.md, "Notification poller".
Shape
One bin, three modules:
main.rs— argument-free entry point. ReadsHIVE_AGENT_SOCKET, initialises tracing, hands off tonotify::run.notify.rs— the poller: forge client setup, the 30s loop, the formatters, mark-read, and the in-process delivery-dedupe map.todo_client.rs— one-shot JSON-line client for the harness's in-agent socket. No retry schedule of its own; see the module doc.
Why it is a separate process
It used to be a tokio::spawn inside the hive-agent serve loop. It
never needed anything from the serve loop except a socket path, and
running it in-process meant a harness restart also took forge
notifications down, and linked the whole forge/HTTP dependency tree
(forgejo-api, reqwest, time, url) into the serve-loop binary.
It is now a sibling daemon alongside hive-bash-daemon and
hive-matrix-daemon, with the same contract: it talks to the harness
over the in-agent todo socket and nowhere else.
Forge's own read-state is the durable, cross-rebuild record of what has been delivered — there is no persisted cursor to migrate or corrupt. A restarted poller re-scans only the genuinely-still-unread set, which is tiny by construction because delivery marks the thread read.