| Filename | Latest commit message | Latest commit date |
|---|---|---|
7d217f8267
mara ruled on #4849 (c88934): "remove create_repo tool". The tool ran in
hive-c0re with the hive's core token, so it only ever worked for agents
on the hive that runs the forge.
Removed:
- the create_repo MCP tool and CreateRepoArgs (hive-agent-mcp)
- wire variants Request::CreateRepo and Response::RepoCreated
(hive-core-agent-sock)
- hive-c0re's handle_create_repo, its valid_repo_name check and the
dispatch arm
- forge::create_agent_repo and apply_operator_branch_protection, which
had no other caller, plus AGENTS_ORG and OPERATORS_TEAM, whose only
users they were
- the tool's docs (docs/tools/forge.md repo management, docs/turn-loop/
mcp.md, the conventions tool-group table) and the doc comments that
named it (hive-sock-client's response timeout, ensure_repo_creation_
disabled, the security doc's merge-gate bullet)
ToolGroup::Forge is kept with no tools, the same way
|
||
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
hive-sock-client
One JSON-line-over-unix-socket client, shared by every daemon that speaks to a hyperhive socket.
The wire protocol is the same everywhere: connect, write one line of JSON, read one line of JSON back. Before this crate existed, five daemons each carried their own copy of that — two of them byte-identical — and the retry, response-handling and error-context behaviour drifted between them.
The crate is generic over the request and response types, so it is protocol-agnostic: the host-served control socket and the harness's in-agent socket both use it, with their own wire-type crates.
Shapes
request/request_retried— write, then decode the response line.request_retriedadditionally reports how many retries it took, for callers (MCP tool handlers) that want to tell the model a socket flake happened so it doesn't retry at the LLM level.notify— write, half-close, drain the response line and discard it. For fire-and-forget ops where the reply carries nothing the caller acts on. The drain is not optional: without it the server's write-back lands on a closed socket.
Retry is a policy value, not a fork
Retry::RideOutRestart backs off 2/4/8/16/30s (60s total), sized to ride
out a service restart. It is for callers with no natural retry of their
own — a stall there costs a surfaced tool error and the tokens to handle
it.
Retry::None fails fast. It is for callers already inside a poll loop,
where the poll interval is the retry and a second backoff would only
stack sleeps and delay the rest of the batch.
Two named policies, not a configurable schedule: nobody needs a third yet, and naming them keeps the reason for the choice at the call site.
Error contract
Errors always name the socket path. That detail is load-bearing: a permission problem on a socket that reads as "is the daemon running?" sends the operator to fix the wrong thing.
A refused or missing socket additionally gets a "may be restarting" hint, and an exhausted retry schedule records how long it tried, so a surfaced error reads as the likely transient it usually is.
Serialisation and deserialisation failures are never retried — retrying identical bytes reproduces the same failure. They are raised outside the retry loop, so only connect/IO/short-read failures ever reach it.