| Filename | Latest commit message | Latest commit date |
|---|---|---|
58ef299c3c
Nothing submits an approval since scheduled prompts left hive-c0re, so the
queue only acted on rows written before that.
- hive-c0re: the approvals store and its migrations, approve/deny/
resolve actions, the ResolveApproval tail node (and meta_update's
approval_id), POST /api/approve and /api/deny, the approval views on
/api/state, the approval_resolved dashboard event, the orphan GC,
destroy/purge failing pending rows, and the approval rows in
get_loose_ends. DestroyBookkeeping loses the purge flag, which only
worded the approval-failure note.
- The CancelLooseEnd request goes: its only hive-c0re arm was the
approval one. cancel_loose_end handles reminder and todo in the harness.
- Wire types: hive_sh4re::approvals (ReminderStats moves to inbox),
LooseEnd::Approval, CancelLooseEndKind, HelperEvent::ApprovalResolved,
ToolGroup::Approvals, HostRequest::{Pending,Approve,Deny} and
HostResponse.approvals. HOST_SOCK_VERSION goes to 2 for the removed
field.
- hivectl loses the approvals verbs; docs/tools/hivectl-cli.md is
regenerated.
- The system prompt drops approval_resolved.
- The approvals table stays in broker.sqlite, unread, the same way the
operator_questions table was left when its store was removed.
- An `approvals` entry still in tool-groups.json is skipped with a warning
by ToolGroup::parse_list, like any unknown group.
- docs/agent-lifecycle/approvals.md is renamed to config-changes.md so the
code's doc pointers resolve; its content follows in the docs commit.
|
||
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
hive-agent-sock
What's common across the in-container "agent plugins" — the matrix / bash /
subagent MCP daemons and forge_notify today, plus any user-configured MCP
server declared in an agent's agent.nix. Two things live here:
Wire types for the in-agent socket
The socket the hive-agent harness serves inside the container to those
local producers. Any producer can dial it and push its own todos with an
arbitrary subsystem marker — the wire format doesn't restrict the set.
Unlike the host-served sockets, this one never leaves the container.
- the loose-ends-v2 todo op family
- the harness-local reminder op family
More in-agent request families may show up over time — the socket is deliberately named for the agent, not for the todos.
Why in-container: the harness owns the todo + reminder stores locally and
signals its own turn loop directly, so hive-c0re isn't in either path: no
broker round-trip, no long-poll, no marker files. That locality is the
point — it's also what lets these stores travel with the agent for hive
portability.
Don't confuse this with hive-core-agent-sock: that crate is the
host-served core↔agent protocol on /run/hive/mcp.sock (the harness
talking out to hive-c0re). This socket is purely intra-container.
extra_mcp: the services.hyperhive.agent.extraMcpServers spec
Not a socket protocol — a shared config type. Parses
/etc/hyperhive/extra-mcp.json (the nix-rendered
services.hyperhive.agent.extraMcpServers option) and renders each
entry into the shape claude expects in a
--mcp-config blob. Shared by hive-agent (the main session's servers) and
hive-subagent-mcp (the subagent-eligible subset, gated on
availableToSubagents) — both already depend on this crate for the socket
types above, so a new plugin-facing shared type belongs here rather than in
a crate of its own.