agent capabilities live in a swarm KV record, set from swarmctl
An agent's capabilities move from the hive's meta repo
(`meta/capabilities.json`, injected as `HIVE_CAPABILITIES`) into the
`capabilities` field of its key in a new `agent-permissions` KV bucket,
which swarm-controller alone writes.
- swarm-queue-client: `agent_permissions` (bucket, key, `AgentPermissions`,
direct-get read, the import subject and its wire types).
- swarm-controller: creates the bucket at start; `GET|PUT|DELETE
/api/agents/{name}/permissions` (deny_unknown_fields and unknown
capability ⇒ 422, duplicate ⇒ 400, agent must be declared by a hive);
answers each hive's one-shot import, writing a key only where there is
none and only for agents that hive's wanted state declares.
- swarmctl: `agent permissions get|set|clear`.
- swarm-nats-auth: a hive reads every key of the bucket and sends its
import on its own subject; the controller subscribes to the imports and
may answer them (`responses`).
- hive-c0re: reads each of its agents' keys every 30s into
/var/lib/hyperhive/swarm-agent-permissions.json and restarts an agent,
gracefully, when its capabilities change. Unset is the compiled-in
default (ruth: manage_root_agent; everyone else: none). A failed read
keeps the stored value. On first boot it seeds that file from
meta/capabilities.json, sends the grants to the controller, and deletes
the file once the controller answers.
Deleted: the capabilities.json reader/writer, `HIVE_CAPABILITIES` in the
rendered meta flake, ruth's capability seed, the capabilities half of the
permissions rebuild job (`PermPayload::Capabilities`/`Combined`), the
dashboard's capabilities table and `capabilities_changed` event, and the
now-unused `Capability::description`.
Part of #5170.
This commit is contained in:
atlas
mara
parent
fcda1f4a04
commit
f862354e43
47 changed files with 1943 additions and 1146 deletions
|
|
@ -253,8 +253,9 @@ the operator review and merge it. By design, no second, mount-shaped
|
|||
path reaches the same file without the review.
|
||||
|
||||
Agents holding the `manage_root_agent` capability (granted per agent in
|
||||
`capabilities.json`; see `hive-sh4re/src/permissions.rs`) get additional
|
||||
host-side bind mounts via `set_nspawn_flags`:
|
||||
the swarm's `agent-permissions` record; see
|
||||
`docs/process/conventions.md#capabilities`) get additional host-side bind
|
||||
mounts via `set_nspawn_flags`:
|
||||
|
||||
- `/var/lib/hyperhive/agents/` → `/agents/` (RW) — **every** agent's
|
||||
proposed repo, not just direct children. The capability means "may
|
||||
|
|
@ -267,16 +268,13 @@ host-side bind mounts via `set_nspawn_flags`:
|
|||
An agent without the capability only has its direct children's config
|
||||
dirs.
|
||||
|
||||
⚠️ nspawn bakes bind flags at container start, so granting or
|
||||
revoking this capability doesn't change any mount until that agent's
|
||||
container is rebuilt/restarted.
|
||||
⚠️ nspawn bakes bind flags at container start, so hive-c0re restarts
|
||||
an agent, after its current turn, when its capabilities change.
|
||||
|
||||
The root agent gets the capability by default, seeded on its autodeploy
|
||||
path (`workers::auto_update::ensure_root_agent`) so the recovery mounts
|
||||
are there from its first container. That seed only fires while
|
||||
`capabilities.json` doesn't exist yet: any grant or revoke through
|
||||
the dashboard creates the file, so a revoked root-agent grant stays
|
||||
revoked and isn't re-applied on the next hive-c0re restart.
|
||||
The root agent holds the capability by default: an agent whose record
|
||||
leaves `capabilities` unset gets the hive's default, which is
|
||||
`manage_root_agent` for `ruth` and nothing for every other agent.
|
||||
Setting `"capabilities": []` for her revokes it.
|
||||
|
||||
Each proposed repo (`/agents/<n>/config/`) is pre-configured
|
||||
with `applied` as a git remote pointing at
|
||||
|
|
|
|||
|
|
@ -391,10 +391,6 @@ Contents:
|
|||
(`{ "alice": ["messaging", "inbox", "execution"] }`). Written by
|
||||
`tool_groups::set_groups`; injected as `HIVE_TOOL_GROUPS` env
|
||||
var into each agent's container.
|
||||
- `capabilities.json` — per-agent capability grants
|
||||
(`{ "ruth": ["manage_root_agent"] }`). Written by
|
||||
`capabilities::set_caps`; injected as `HIVE_CAPABILITIES` env
|
||||
var. Absent agents have no extra capabilities.
|
||||
- `swarm-resource-limits.json` — the caps the swarm sets for this
|
||||
hive's agents
|
||||
(`{ "sock": { "cpu_quota": "400%", "memory_max": "8G" } }`).
|
||||
|
|
@ -418,6 +414,13 @@ Contents:
|
|||
|
||||
The root agent has the meta dir RO-mounted at `/meta/`.
|
||||
|
||||
Outside the meta repo, `/var/lib/hyperhive/swarm-agent-permissions.json`
|
||||
holds the capabilities the swarm grants this hive's agents, as
|
||||
`workers::swarm_permissions` last read them from the swarm's
|
||||
`agent-permissions` bucket (every 30 seconds): a copy, not the
|
||||
record, which `swarmctl agent permissions` sets. `set_nspawn_flags`
|
||||
reads it at every container start.
|
||||
|
||||
hive-c0re renders containers onto `meta#<n>` at creation.
|
||||
|
||||
## Destroy vs purge
|
||||
|
|
|
|||
|
|
@ -334,35 +334,37 @@ that allows the underlying resource access.
|
|||
|
||||
| Capability | Effect |
|
||||
|---|---|
|
||||
| `manage_root_agent` | may manage *any* agent: bind-mounts every agent's state (rw) + config (ro) into the holder's container, plus `/applied` and `/meta` (ro). Takes effect on the holder's next container rebuild/restart |
|
||||
| `manage_root_agent` | may manage *any* agent: bind-mounts every agent's state (rw) + config (ro) into the holder's container, plus `/applied` and `/meta` (ro). Takes effect when the holder's container restarts, which hive-c0re does itself on a change |
|
||||
|
||||
**Config storage** — per-agent capabilities live in
|
||||
`/var/lib/hyperhive/meta/capabilities.json` alongside `tool-groups.json`.
|
||||
Format: `{ "ruth": ["manage_root_agent"] }`.
|
||||
An absent entry means "no extra capabilities." `render_flake` in `meta.rs`
|
||||
reads this file and injects `HIVE_CAPABILITIES` (comma-separated
|
||||
`snake_case` names) into each agent's systemd service env; absent entries emit
|
||||
no env var so agents without capabilities don't trigger a spurious rebuild.
|
||||
**Where they live** — in the swarm, not on the hive: the `capabilities` field
|
||||
of the agent's key in the `agent-permissions` KV bucket
|
||||
(`swarm-queue-client/src/agent_permissions.rs`), which swarm-controller alone
|
||||
writes. Set them with `swarmctl agent permissions get|set|clear <agent>`
|
||||
(`/api/agents/{name}/permissions`). Unset means the hive's default, which is a
|
||||
constant in hive-c0re (`capabilities::default_for`): none, except `ruth`, who
|
||||
gets `manage_root_agent`. `"capabilities": []` grants none.
|
||||
|
||||
**Setting capabilities** — the operator sets capabilities via the
|
||||
C4P4B1L1T13S section in the dashboard's P3RM1SS10NS tab.
|
||||
`hive-c0re::capabilities::set_caps(name, caps)` is the write path.
|
||||
After a change `meta::sync_agents` commits the updated file; the next agent
|
||||
rebuild picks up the new `HIVE_CAPABILITIES` env var.
|
||||
**How a change applies** — every 30 seconds hive-c0re reads the key of each
|
||||
agent it runs (`workers/swarm_permissions.rs`) and stores the result in
|
||||
`/var/lib/hyperhive/swarm-agent-permissions.json`, outside the meta repo. nspawn
|
||||
fixes the bind mounts at container start, so when an agent's capabilities
|
||||
change hive-c0re restarts it after its current turn. A failed read keeps the
|
||||
last stored value; it never falls back to the default.
|
||||
|
||||
**Runtime resolution** — at session start the harness reads `HIVE_CAPABILITIES`
|
||||
and resolves each token to a `Capability` variant, logging and skipping
|
||||
unrecognised ones. An absent or empty var means no extra capabilities.
|
||||
**Moving off `meta/capabilities.json`** — on its first boot with this code a
|
||||
hive copies the file's grants into the stored value, sends them to
|
||||
swarm-controller once (written only for agents with no key, and only for
|
||||
agents that hive's wanted state declares), and deletes the file from the meta
|
||||
repo when the controller answers (`workers/permissions_import.rs`).
|
||||
|
||||
**Capability NOT configurable from `agent.nix`** — same reasoning as tool
|
||||
groups: an agent that could grant its own capabilities via a config commit would
|
||||
bypass the operator approval gate.
|
||||
|
||||
**Adding a new capability** — add a variant to `Capability` in
|
||||
`hive-sh4re/src/permissions.rs` + an arm to `as_str`. Add it to `Capability::ALL`
|
||||
(the source of truth for the permissions UI columns). Implement the access
|
||||
check in the relevant handler (`hive-c0re/src/socket_server/mod.rs`,
|
||||
`coordinator.rs`, or a handler under `hive-c0re/src/dashboard/`).
|
||||
`hive-sh4re/src/permissions.rs` and to `Capability::ALL`. Implement the access
|
||||
check where hive-c0re enforces it (today: `set_nspawn_flags` in
|
||||
`hive-c0re/src/lifecycle/host_config.rs`).
|
||||
|
||||
## Async forms
|
||||
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ Cheap — no build slot:
|
|||
| `SetWanted` | write the durable power intent (`wanted = Up`/`Offline`) as the head node of a power-op DAG. Takes the agent lease even though it's a store write, so the intent write and the tail `Reconcile` are atomic per-agent — two racing power ops can't clobber each other's intent before either reconciles |
|
||||
| `EmitRebuilt` | tail of a rebuild/perm-change — emit the agent's `Rebuilt` manager event (ok/fail per outcome, nothing on cancel). One node per agent _and_ per outcome |
|
||||
| `WriteDropin` | `set_nspawn_flags` + `set_resource_limits` + daemon-reload |
|
||||
| `WritePermFile` | commit `tool-groups.json` / `capabilities.json` (single git commit under `META_LOCK`) + emit the P3RM1SS10NS snapshots |
|
||||
| `WritePermFile` | commit `tool-groups.json` (single git commit under `META_LOCK`) + emit the P3RM1SS10NS snapshot |
|
||||
| `ForgeSweep` | one-shot boot-time forge user/token sweep for every container (`forge::ensure_all`) as a first-class node, so it shows as real work on the dashboard instead of running invisibly in a bare `tokio::spawn`. Agentless |
|
||||
| `MatrixSweep` | matrix user/space sweep (`matrix::ensure_all`): the boot-time instance, plus one every 30 min from a loop in `main.rs`. Holds `Resource::MatrixSweep` (capacity 1), so two passes never overlap; each tick queues its own pass, which waits for the resource if one is already live. Agentless |
|
||||
| `KnowledgePull` | `/knowledge` pull (`knowledge::pull`): at boot (commits that landed while `hive-c0re` was down), on the swarm knowledge-changed event, and hourly as a fallback. Holds `Resource::KnowledgeTree` (capacity 1), so two pulls never overlap on the working tree; each trigger queues its own pass, which waits for the resource if one is already live. Agentless |
|
||||
|
|
|
|||
|
|
@ -12,6 +12,10 @@ This document contains the help content for the `swarmctl` command-line program.
|
|||
* [`swarmctl agent inference get`↴](#swarmctl-agent-inference-get)
|
||||
* [`swarmctl agent inference set`↴](#swarmctl-agent-inference-set)
|
||||
* [`swarmctl agent inference clear`↴](#swarmctl-agent-inference-clear)
|
||||
* [`swarmctl agent permissions`↴](#swarmctl-agent-permissions)
|
||||
* [`swarmctl agent permissions get`↴](#swarmctl-agent-permissions-get)
|
||||
* [`swarmctl agent permissions set`↴](#swarmctl-agent-permissions-set)
|
||||
* [`swarmctl agent permissions clear`↴](#swarmctl-agent-permissions-clear)
|
||||
* [`swarmctl schedule`↴](#swarmctl-schedule)
|
||||
* [`swarmctl schedule add`↴](#swarmctl-schedule-add)
|
||||
* [`swarmctl schedule list`↴](#swarmctl-schedule-list)
|
||||
|
|
@ -66,6 +70,7 @@ Manage agents across the swarm
|
|||
* `create` — Queue creation of a new agent on a hive in this swarm
|
||||
* `mint-forge-token` — Check one agent's forge token, and mint it if it's missing or stale
|
||||
* `inference` — Show the model, effort, subagent models and subagent cap the swarm sets for an agent, or change the model, effort and subagent models
|
||||
* `permissions` — Show or change the capabilities the swarm grants an agent
|
||||
|
||||
|
||||
|
||||
|
|
@ -198,6 +203,77 @@ Clear every field for an agent, so it goes back to its own values
|
|||
|
||||
|
||||
|
||||
## `swarmctl agent permissions`
|
||||
|
||||
Show or change the capabilities the swarm grants an agent.
|
||||
|
||||
The hive running the agent reads them every 30 seconds and, when they change, restarts the agent after its current turn. Unset leaves the agent on its hive's default: none, except `ruth`, who gets `manage_root_agent`.
|
||||
|
||||
**Usage:** `swarmctl agent permissions <COMMAND>`
|
||||
|
||||
###### **Subcommands:**
|
||||
|
||||
* `get` — Show the capabilities the swarm grants an agent, or that it sets none
|
||||
* `set` — Replace the capabilities the swarm grants an agent
|
||||
* `clear` — Clear the agent's permissions, so its hive's default applies again
|
||||
|
||||
|
||||
|
||||
## `swarmctl agent permissions get`
|
||||
|
||||
Show the capabilities the swarm grants an agent, or that it sets none
|
||||
|
||||
**Usage:** `swarmctl agent permissions get [OPTIONS] <AGENT>`
|
||||
|
||||
###### **Arguments:**
|
||||
|
||||
* `<AGENT>` — Agent name
|
||||
|
||||
###### **Options:**
|
||||
|
||||
* `--controller-socket <PATH>` — swarm-controller's unix socket.
|
||||
|
||||
Supplied by the nix module that installs this binary, from the same `socketPath` option the daemon binds; falls back to `SWARM_CONTROLLER_SOCKET`.
|
||||
|
||||
|
||||
|
||||
## `swarmctl agent permissions set`
|
||||
|
||||
Replace the capabilities the swarm grants an agent
|
||||
|
||||
**Usage:** `swarmctl agent permissions set [OPTIONS] --capabilities <CAPABILITIES> <AGENT>`
|
||||
|
||||
###### **Arguments:**
|
||||
|
||||
* `<AGENT>` — Agent name. A hive must declare it
|
||||
|
||||
###### **Options:**
|
||||
|
||||
* `--capabilities <CAPABILITIES>` — The capabilities to grant, comma-separated (`manage_root_agent`). `--capabilities ''` grants none
|
||||
* `--controller-socket <PATH>` — swarm-controller's unix socket.
|
||||
|
||||
Supplied by the nix module that installs this binary, from the same `socketPath` option the daemon binds; falls back to `SWARM_CONTROLLER_SOCKET`.
|
||||
|
||||
|
||||
|
||||
## `swarmctl agent permissions clear`
|
||||
|
||||
Clear the agent's permissions, so its hive's default applies again
|
||||
|
||||
**Usage:** `swarmctl agent permissions clear [OPTIONS] <AGENT>`
|
||||
|
||||
###### **Arguments:**
|
||||
|
||||
* `<AGENT>` — Agent name
|
||||
|
||||
###### **Options:**
|
||||
|
||||
* `--controller-socket <PATH>` — swarm-controller's unix socket.
|
||||
|
||||
Supplied by the nix module that installs this binary, from the same `socketPath` option the daemon binds; falls back to `SWARM_CONTROLLER_SOCKET`.
|
||||
|
||||
|
||||
|
||||
## `swarmctl schedule`
|
||||
|
||||
Manage scheduled prompts.
|
||||
|
|
|
|||
|
|
@ -77,8 +77,8 @@ H0M3 hub (served at
|
|||
`/core.html`), with minimal chrome: a `← home` back-link and a single pane,
|
||||
**K3PT ST4T3**. The page is its own esbuild bundle (`core.js`) that
|
||||
cold-loads `/api/state` and subscribes to `/api/dashboard/stream` for
|
||||
`tombstones_changed`, `capabilities_changed`, and `tool_groups_changed`
|
||||
(the latter two re-render the stale-perms sub-section when permission
|
||||
`tombstones_changed` and `tool_groups_changed`
|
||||
(the latter re-renders the stale-perms sub-section when permission
|
||||
data changes). (Rebuild queue and meta inputs are dashboard tabs — see
|
||||
below.)
|
||||
|
||||
|
|
@ -104,11 +104,10 @@ container is all hive-c0re can actually prove. Fixing it properly
|
|||
needs a recorded destroy — **deferred** to the swarm-controller /
|
||||
snapshot-storage rework where the problem changes shape.
|
||||
|
||||
*Stale permission entries*: agents with explicit capability or
|
||||
tool-group JSON entries but no live container — typically renamed or
|
||||
deleted agents whose entries persisted in `capabilities.json` /
|
||||
`tool-groups.json`. Loaded when the page opens;
|
||||
autorefreshes on `capabilities_changed` + `tool_groups_changed` SSE
|
||||
*Stale permission entries*: agents with explicit tool-group JSON
|
||||
entries but no live container — typically renamed or deleted agents
|
||||
whose entries persisted in `tool-groups.json`. Loaded when the page opens;
|
||||
autorefreshes on `tool_groups_changed` SSE
|
||||
events. Each ghost agent gets a `✕ clear perms` button
|
||||
(`DELETE /api/permissions/{name}`).
|
||||
|
||||
|
|
@ -230,11 +229,13 @@ entry with that id pre-expanded.
|
|||
|
||||
## P3RM1SS10NS tab
|
||||
|
||||
Per-agent permission configuration. Two sections, each rendered as a
|
||||
column-driven checkbox matrix: rows are agents, columns are the
|
||||
permission names fetched from hive-c0re. The column list is
|
||||
authoritative — adding a new tool-group or capability to hive-c0re
|
||||
requires no UI change; the new column appears automatically.
|
||||
Per-agent tool-group configuration, rendered as a column-driven
|
||||
checkbox matrix: rows are agents, columns are the group names fetched
|
||||
from hive-c0re. The column list is authoritative — adding a new
|
||||
tool-group to hive-c0re requires no UI change; the new column appears
|
||||
automatically. Capabilities aren't set here: they're the swarm's,
|
||||
set with `swarmctl agent permissions` (see
|
||||
`docs/process/conventions.md#capabilities`).
|
||||
|
||||
The snapshot carries `agents` (the full manageable roster — live
|
||||
containers ∪ agents with an explicit entry) and `effective` (per-agent
|
||||
|
|
@ -248,29 +249,11 @@ strip those defaults. The `(default)` badge keys off absence from
|
|||
|
||||
Fetches fire on tab activation (not page-load) to avoid unnecessary
|
||||
work when the operator never visits this tab. Live mutations from the
|
||||
rebuild-queue worker are also pushed via the `capabilities_changed` /
|
||||
`tool_groups_changed` SSE events (same payload shape as the GET
|
||||
endpoints), so an open P3RM1SS10NS tab reflects worker-applied changes
|
||||
rebuild-queue worker are also pushed via the `tool_groups_changed`
|
||||
SSE event (same payload shape as the GET endpoint), so an open P3RM1SS10NS tab reflects worker-applied changes
|
||||
without requiring navigation. Tab-activation re-fetches remain as a
|
||||
safety net for reconnect windows.
|
||||
|
||||
**C4P4B1L1T13S** — per-agent capability grants. Capabilities unlock
|
||||
gated MCP tools and system-level access beyond the default agent
|
||||
surface. A saving POST queues a rebuild for the affected agent so the
|
||||
new `HIVE_CAPABILITIES` env var takes effect in the next session.
|
||||
|
||||
The current capabilities are:
|
||||
|
||||
| Name | Effect |
|
||||
|------|--------|
|
||||
| `manage_root_agent` | mounts every agent's state (rw) + config (ro) into this agent's container so it can manage/recover any agent |
|
||||
|
||||
Each row is one agent. Columns are the capability names returned by
|
||||
`GET /api/capabilities` as `caps: Vec<String>`. Checking or unchecking
|
||||
boxes only stages the change in-browser; the browser writes nothing until
|
||||
the operator selects the page-level **save all** button (described below). Row
|
||||
values follow the `effective`/`assignments` rule described above.
|
||||
|
||||
<!-- vale write-good.Passive = NO -->
|
||||
**T00L GR0UPS** — per-agent tool-group permissions. Tool groups are
|
||||
named buckets of MCP tools; each agent starts with a role default
|
||||
|
|
@ -291,10 +274,9 @@ The current tool groups are: `messaging`, `meta`, `inbox`, `lifecycle`,
|
|||
Claude's built-in `WebFetch` and `WebSearch` to `--tools` /
|
||||
`--allowedTools` for that agent session.
|
||||
|
||||
Both tables share the same visual shape: `.cap-table-wrap` /
|
||||
`.tg-table-wrap` outer scroll container, `thead` with a label column
|
||||
(`.cap-agent-col` / `.tg-agent-col`) + one column per permission
|
||||
(`.cap-col` / `.tg-group-col`). Each tbody row is one agent: a name cell
|
||||
The table's shape: a `.tg-table-wrap` outer scroll container, `thead`
|
||||
with a label column (`.tg-agent-col`) + one column per group
|
||||
(`.tg-group-col`). Each tbody row is one agent: a name cell
|
||||
and its checkbox cells, where each checkbox carries `data-baseline` (its
|
||||
render-time state) and the row carries `data-agent` for dirty-tracking.
|
||||
|
||||
|
|
@ -302,18 +284,15 @@ render-time state) and the row carries `data-agent` for dirty-tracking.
|
|||
buttons exist. A single page-level `.perm-save-bar` with a **save all (N
|
||||
agents)** button sits at the bottom of the pane, enabled only when some
|
||||
checkbox diverges from its baseline. Selecting it diffs every checkbox
|
||||
across *both* matrices and POSTs one batch to `POST /api/permissions` as
|
||||
`{ changes: [ { agent, tool_groups?, capabilities? } ] }` — the batch
|
||||
includes only the perm-types that actually changed for each agent (an
|
||||
omitted field leaves that file untouched; an included array fully
|
||||
replaces it).
|
||||
hive-c0re coalesces an agent's capabilities + tool-groups into a
|
||||
single rebuild, so changing both for one agent is one rebuild, not two.
|
||||
and POSTs one batch to `POST /api/permissions` as
|
||||
`{ changes: [ { agent, tool_groups } ] }` — the batch includes only the
|
||||
agents whose groups changed (an included array fully replaces the
|
||||
agent's groups).
|
||||
The batch is atomic: it validates every change first and on any error
|
||||
rejects the whole POST (`{error}`, nothing applied); a clean 200 (`ok`)
|
||||
flips the bar to a queued→rebuilding state and re-fetches both tables.
|
||||
Live `capabilities_changed` / `tool_groups_changed` events re-render the
|
||||
matrices unless the section has unsaved edits, so an in-progress edit set
|
||||
flips the bar to a queued→rebuilding state and re-fetches the table.
|
||||
Live `tool_groups_changed` events re-render the
|
||||
matrix unless it has unsaved edits, so an in-progress edit set
|
||||
isn't clobbered.
|
||||
|
||||
## ST4TS page (`/stats.html`)
|
||||
|
|
@ -767,31 +746,16 @@ below — some endpoints aren't in it yet.
|
|||
`/var/lib/hyperhive/meta/tool-groups.json` and queues a rebuild so
|
||||
`HIVE_TOOL_GROUPS` takes effect. Agent name validated;
|
||||
`guard_agent_name` applied.
|
||||
- `GET /api/capabilities` — returns `{ caps: Vec<String>,
|
||||
assignments: BTreeMap<String, Vec<String>>,
|
||||
descriptions: BTreeMap<String, String> }`. `caps` is the
|
||||
ordered list of all known capability names; `assignments` is the
|
||||
per-agent grant map (absent agents have no extra capabilities);
|
||||
`descriptions` maps each capability name to a short human-readable
|
||||
string surfaced as a column-header tooltip on hover.
|
||||
- `POST /api/capabilities/{agent}` — body `{ caps: ["name", …] }`.
|
||||
Writes the capability set for `{agent}` to
|
||||
`/var/lib/hyperhive/meta/capabilities.json` and queues a rebuild so
|
||||
`HIVE_CAPABILITIES` takes effect. Agent name validated;
|
||||
unknown capability strings rejected (400). `guard_agent_name`
|
||||
applied.
|
||||
- `POST /api/permissions` — batch perm apply for the save-all
|
||||
permissions button. Body
|
||||
`{ changes: [{ agent, tool_groups?: ["name", …], capabilities?: ["name", …] }] }`.
|
||||
Sparse per agent: an omitted field leaves that perm-type untouched,
|
||||
an empty array clears it, a populated array fully replaces it (same
|
||||
replace semantics as the per-agent endpoints above). Each affected
|
||||
agent gets ONE combined `PermChange` queue entry, so changing both
|
||||
an agent's tool-groups and capabilities triggers a single rebuild,
|
||||
not two. **Atomic**: the endpoint validates every change first (agent names via
|
||||
`guard_agent_name`, group + capability names) and on any validation
|
||||
error writes or enqueues nothing (non-2xx `{ error }`); it skips
|
||||
rows with both fields omitted rather than erroring on them.
|
||||
`{ changes: [{ agent, tool_groups?: ["name", …] }] }`.
|
||||
An omitted `tool_groups` leaves the agent untouched, an empty array
|
||||
clears it, a populated array fully replaces it (same replace
|
||||
semantics as the per-agent endpoint above). Each affected agent gets
|
||||
one `PermChange` queue entry. **Atomic**: the endpoint validates every
|
||||
change first (agent names via `guard_agent_name`, group names) and on
|
||||
any validation error writes or enqueues nothing (non-2xx `{ error }`);
|
||||
it skips rows with the field omitted rather than erroring on them.
|
||||
Returns `200 "ok"` on
|
||||
success.
|
||||
- `POST /api/meta-update` — `nix flake update` the selected
|
||||
|
|
@ -841,13 +805,6 @@ payload):
|
|||
operator cancel / retry (`/api/system/reminders/*`), `cancel_loose_end`
|
||||
with Reminder kind, and the scheduler tick after each delivery
|
||||
batch (`reminder_scheduler`).
|
||||
- `capabilities_changed` (seq, caps: `Vec<str>`, descriptions: map,
|
||||
assignments: `BTreeMap<String, Vec<String>>`) — full snapshot of
|
||||
capability grants. Emitted from the rebuild-queue worker after a
|
||||
`PermChange` / Capabilities entry commits the JSON file. Payload
|
||||
matches `GET /api/capabilities` shape so the client can call
|
||||
`renderCapabilities` directly. P3RM1SS10NS tab subscribes; activation
|
||||
re-fetch still runs as a safety net.
|
||||
- `tool_groups_changed` (seq, groups: `Vec<str>`, descriptions: map,
|
||||
assignments: `BTreeMap<String, Vec<String>>`) — full snapshot of
|
||||
tool-group assignments. Emitted from the rebuild-queue worker after
|
||||
|
|
|
|||
Loading…
Reference in a new issue