A new service crate. It reads its queue client secret from the store at start, takes try-outs on the review classifier subject in its queue group, and for each run reads the Anthropic API key from the store, builds the shared context (commits with full messages, diff with lockfiles collapsed), runs one claude --print per classification with no session, no tools, no MCP server and the key in the child's environment only, validates the JSON answer and aggregates the rows. A missing key or a run where no classification got an answer fails the run; one failed classification is an excluded row with its error. One journal line per run names the operator, repo, PR, head SHA, rows and overall verdict. swarm-secret-client gains the two paths the service reads.
1.6 KiB
swarm-review-classifier
The review classifier's try-out service, in the swarm-review-classifier
container on the host that sets deploy.review-classifier.enable. The
design is docs/swarm/review-classifier.md.
swarm-controller reads a PR (its head commit, its commits and its diff) and sends it, with the operator's classifications, as a request on the queue. This service asks a small model one classification at a time and answers with the result table and the overall verdict. It writes nothing to the forge and holds no forge credential.
What a run is
- The shared context first: a system prompt, the PR's commits with their full
messages, and the diff with lockfiles collapsed as
hive-forge diffdoes. Every classification's prompt starts with the same bytes. - One
claude --printper classification, with no session, no tools (--tools ""), no MCP server, its own empty directory andANTHROPIC_API_KEYin its environment only. - An answer is a JSON object with a verdict, a certainty and a reason of at most 500 characters. A failed run, a timeout or an answer that doesn't validate leaves that row without a verdict, and it doesn't count.
- A run with no API key, or with no classification answered, fails as a whole: the caller sees an error, never a verdict.
Credentials
The container holds one file: its own store certificate. With it the service reads its queue client secret at start and the API key at every run, so a key written or removed in the store takes effect on the next run. Its store role reads exactly those two paths.