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

docs: fix argus R4 review nits on config-PR merge docs

Browse source 
- hive-c0re/README.md: drop deleted webhook_secret.rs from the module
  list
- docs/swarm/README.md, docs/agent-lifecycle/approvals.md: rewrite
  temporal wording (legacy/older-release phrasing) as current
  behaviour
- docs/swarm/README.md: note that a lost closed delivery deploys
  nothing and how the operator recovers
This commit is contained in:
atlas 2026-10-02 23:36:57 +02:00
commit ed9c0f53ed
3 changed files with 16 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

11
docs/agent-lifecycle/approvals.md
View file

@ -1,8 +1,8 @@
# Approvals + helper events
The approval queue is where an agent asks the operator for something it
can't do itself: a scheduled prompt, or (legacy rows only) a meta-input
bump. Config changes don't go through this queue: they're pull requests
can't do itself: a scheduled prompt, or a meta-input bump. Config
changes don't go through this queue: they're pull requests
on the agent's config repo, which an operator merges on the forge, and
that merge deploys them. The submitting agent — any agent with the
`approvals` tool group, which manages the config of its **direct
@ -23,10 +23,9 @@ it stays informed about what happens after a decision lands.
directly from the SCH3DUL3S tab, which skips this approval step
entirely — the gate here is specifically for an *agent* asking to
schedule something, not for you doing it.
- **Meta/flake update** (`UpdateMetaInputs`) — legacy: nothing queues
this kind, but an existing row still reads back and you can approve it.
Approving runs the update and commits the lock change; it doesn't
rebuild anything by itself.
- **Meta/flake update** (`UpdateMetaInputs`) — an existing row reads
back and you can approve it. Approving runs the update and commits
the lock change; it doesn't rebuild anything by itself.
Don't want to approve something? **Deny it** (`DENY` on the dashboard
card, or `hivectl approvals deny <id>`) — nothing runs. Either way the

12
docs/swarm/README.md
View file

@ -259,6 +259,9 @@ A `config-pr` delivery reporting a PR merged into `main` queues a deploy
of its `merge_commit_sha` on the one hive whose wanted state places the
agent; with no such hive, or several, the controller deploys nothing. See
[approvals.md § Config changes](../agent-lifecycle/approvals.md#config-changes).
A merge whose `closed` delivery never arrives deploys nothing either; the
operator recovers by redelivering that delivery from the forge hook page,
which re-enters the same handler and re-queues the deploy.
**`internal/knowledge` is on that path.** The controller's is the only
hook on it ([`knowledge.md`](../integrations/knowledge.md) covers clearing a
@ -268,10 +271,11 @@ would take delivery away from the first rather than add a recipient.
<!-- vale write-good.Passive = NO -->
**The `agent-configs` org is on it too.** The controller's hook is the
only one that acts on config PRs. A hive's `/webhook/config-pr` hook left
on the org by an older release delivers to a route no hive serves; each
hive deletes its own on startup. Removing the controller's hook stops
forge-UI merges from deploying until its next start recreates it.
only one that acts on config PRs. Each hive deletes its own
`/webhook/config-pr` org hook on startup, since a route no hive serves
would otherwise sit on the org collecting failed deliveries. Removing
the controller's hook stops forge-UI merges from deploying until its
next start recreates it.
<!-- vale write-good.Passive = YES -->