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

docs: swarm/services.md is one blurb per service, the host detail moves to the service's implementation page

Browse source 
Each service section lost its container, credential and metrics detail to a
Host setup section on its own implementation page, unchanged apart from links.
The four agentAuth option rows that sat above the page title moved into the
telemetry page's metrics option table.
This commit is contained in:
iris 2026-11-14 12:39:40 +01:00 • committed by mara
commit 814edd1d67
1 changed files with 392 additions and 308 deletions
Download patch file Download diff file Expand all files Collapse all files

35
docs/4-implementation/swarm/review-classifier.md
View file

@ -194,7 +194,7 @@ own: opencode merges an agent's permission over `OPENCODE_PERMISSION`, so one
there would offer the model tools again.
The service is `swarm-review-classifier`, and its container is the one
[`services.md`](../../2-handbook/swarm/services.md#review-classifier) describes. It holds no forge
[Host setup](#host-setup) describes. It holds no forge
credential: `swarm-controller` reads the PR and sends it along.
### Swarm-level settings
@ -315,7 +315,7 @@ deleted, still shows as set, because the controller can't read a value to check.
The classifier reads the leaf on every run, so a new key applies from the next
run. The operator can still write the leaves in the secret store's UI
([`services.md`](../../2-handbook/swarm/services.md#review-classifier)).
([Host setup](#host-setup)).
The per-agent equivalent is [`inference.md`](inference.md), where the
controller writes model and effort to a queue KV bucket
@ -765,3 +765,34 @@ These get settled, and filled in here, as the work reaches them:
`secret/swarm/services/review-classifier/forge/token`.
- **Reviewer handoff.** How a later reviewer, human or agent, learns the
classifier passed a PR before it starts its own review.
## Host setup
The review classifier's try-out service, in a `swarm-review-classifier`
container on the host that sets `deploy.review-classifier.enable`.
`allSwarmServices` defaults it on wherever the host has the classifier's store
identity: the host that runs the store has it, and a services host with the
store elsewhere gets the classifier only once it holds a copy of the pair (see
below). Set `deploy.review-classifier.enable` directly to override either way.
The operator sets the key of the runtime the swarm settings choose in the
swarm UI: the **classifier settings** card on `/jobs` takes a key for the
chosen runtime and shows whether one exists and when it changed, never the
key. "Set" means a key exists, not that it works: a run with a bad key
still fails. You can also write the same two keys in the secret store's UI under the
OIDC login, field `api_key`:
- the API key runtime's Anthropic key at
`secret/swarm/services/review-classifier/anthropic-api-key`
- the ACP runtime's provider key at
`secret/swarm/services/review-classifier/acp-provider`
Nothing writes them for you: until the chosen one exists the service runs and
every run fails with `no API key…` or `no ACP provider key…`. The service reads
the key on every run, so writing or removing it takes effect on the next run,
with no restart. Every run spends money on that key.
It needs neither the forge nor a hive on its host. It reaches the queue and the
secret store by name, under its own `review-classifier` leaf. On a host
without the store, that leaf is the one file to copy, as for the other swarm services.
The swarm UI's try-out drives it through swarm-controller.