docs: the handbook follows the three layers: swarm, hives, agents
The handbook's sections were agent-lifecycle, integrations, swarm, tools, trust-boundary and web-ui, which do not follow how the system is built, so a reader could not tell which layer a page is about. Its pages now sit in swarm/, hives/ and agents/, with the accounts an agent can hold outside the system in external-accounts/. - swarm/: forge, matrix and the knowledge repo join the swarm pages, and so does the swarmctl reference. - hives/: the dashboard, hivectl and its reference, and the operator/agent boundary, with a README that takes over the old web-ui and tools pages. - agents/: the roster, persistence, config changes, the agent's own web page (was web-ui/agent) and the security model, with a README. - external-accounts/: GitHub and GitLab. Pages are moved whole; none is split yet. Every reference follows: relative links in the docs, `docs/2-handbook/...` paths in code comments, the nix checks that regenerate the CLI references and the ignore list, and docs/README.md, whose handbook section is now by layer.
This commit is contained in:
parent
263b21021a
commit
0e84fe8bc4
3 changed files with 393 additions and 363 deletions
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
Architecture notes for the `hive-c0re` coordinator daemon's internal subsystems.
|
||||
For the public API surface (dashboard, socket protocol) see `docs/5-project/process/conventions.md`
|
||||
and `docs/2-handbook/agent-lifecycle/persistence.md`.
|
||||
and `docs/2-handbook/agents/persistence.md`.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -328,7 +328,7 @@ boot with no operator action in this process never finds drift of its own.
|
|||
|
||||
Agents build from the swarm's `internal/meta` flake, which swarm-controller
|
||||
commits and the swarm builder builds from (see
|
||||
[Config changes](../../2-handbook/agent-lifecycle/config-changes.md#the-swarms-meta-flake)).
|
||||
[Config changes](../../2-handbook/agents/config-changes.md#the-swarms-meta-flake)).
|
||||
The hive keeps no flake of its own and deploys the closure the swarm builds
|
||||
from it, as the agent's `agent-closures` record declares (`attic/closure.rs`).
|
||||
`agent_set.rs` keeps the
|
||||
|
|
@ -536,7 +536,7 @@ config — all nspawn containers live in `machine.slice`.
|
|||
|
||||
## See also
|
||||
|
||||
- `docs/2-handbook/agent-lifecycle/config-changes.md` — config PRs, meta flake, system messages
|
||||
- `docs/2-handbook/agent-lifecycle/persistence.md` — SQLite schema, state-dir layout
|
||||
- `docs/2-handbook/agents/config-changes.md` — config PRs, meta flake, system messages
|
||||
- `docs/2-handbook/agents/persistence.md` — SQLite schema, state-dir layout
|
||||
- `docs/5-project/process/conventions.md` — wire protocol, recipient sentinels
|
||||
- `docs/2-handbook/agent-lifecycle/agent-roster.md` — the agent roster and privilege
|
||||
- `docs/2-handbook/agents/agent-roster.md` — the agent roster and privilege
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ swarm controller and hive-c0re each build their own graph on it.
|
|||
Two views, one per graph, drawn by the same component: the swarm UI's
|
||||
`/jobs` page shows the swarm controller's graph, and the hive dashboard's
|
||||
**R3BU1LD QU3U3** tab (see
|
||||
[`2-handbook/web-ui/dashboard.md`](../../2-handbook/web-ui/dashboard.md)) shows that hive's. Each
|
||||
[`2-handbook/hives/dashboard.md`](../../2-handbook/hives/dashboard.md)) shows that hive's. Each
|
||||
**row** is one job; the rows nested under it are that job's steps, in
|
||||
order (occasionally a couple run side by side). A step shows one of:
|
||||
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ smuggled out in resource attributes on an otherwise-legitimate export.
|
|||
That's a **different risk from the one the collector fixes**: an agent that
|
||||
held the upstream credential could do everything above _and_ use the token
|
||||
anywhere else. The collector removes the token and keeps the pipe. Agents are inside the trust
|
||||
boundary (`docs/2-handbook/trust-boundary/security.md`: capability = accepted risk), so an agent being
|
||||
boundary (`docs/2-handbook/agents/security.md`: capability = accepted risk), so an agent being
|
||||
able to _send_ is an accepted extension of that boundary — but it's not
|
||||
closed by this design, and don't read anything here as closing it.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue