Watch

iris 07b62612b0 docs: restructure into topic subdirectories, collapse duplicated index

Per mara's go-ahead on hyperhive#3902 ("getting started is good, but
terminal rendering does not go in there i think"):

Moved 21 top-level docs/*.md files into 7 new topic subdirectories
(existing web-ui/, turn-loop/, swarm/, tools/, crates/ untouched):
  getting-started/  setup.md
  agent-lifecycle/  agent-hierarchy.md, approvals.md, persistence.md
  trust-boundary/   boundary.md, security.md
  integrations/     forge.md, matrix.md, github.md, knowledge.md
  networking/       gateway.md, network.md, snapshot-store.md
  scheduler/        jobq.md, coordinator.md, ci.md, observability.md
  process/          conventions.md, gotchas.md, pr-review-gate.md
  web-ui/           terminal-rendering.md (moved into the EXISTING dir,
                    per mara's correction to the original getting-started
                    guess -- it's UI implementation detail, not onboarding)

The physical layout now matches docs/README.md's own topical headers,
which already amounted to this taxonomy -- see the scoping comment on
the issue for the two findings that motivated this (a genuine
duplication between CLAUDE.md's old "Reading paths" list and
docs/README.md's grouped one, since drifted out of sync with each
other; and the flat layout not matching the grouping we already had).

Fixed every cross-reference this moved across the whole repo (~120
files: docs/ internal links at every depth, Rust doc comments, nix
module option docs, crate READMEs) -- verified two ways: a grep sweep
confirming zero remaining references to any old path, and a script
that resolves every markdown link in docs/**/*.md + CLAUDE.md +
README.md against the filesystem and reports anything that doesn't
exist (zero broken links).

Collapsed CLAUDE.md's "Reading paths" section (the duplicate) down to
a pointer at docs/README.md, now the single index. Rewrote
docs/README.md itself to use the new subdirectory paths and added the
one doc it was missing that CLAUDE.md's old copy had (pr-review-gate.md).

Classified all 22 docs/*.md files first via a haiku subagent (mara's
suggestion) on two axes -- proposed grouping and operator-vs-
implementation focus -- before finalizing the taxonomy; spot-checked
the report and found internal inconsistencies (its classification
table disagreed with its own summary section for a few files), so this
taxonomy is my original proposal + the one correction mara gave
directly, not a blind application of the subagent's table. The
operator-focus data it gathered is still useful for a follow-up
content pass (docs skewing 'mixed' rather than pure operator-facing),
not addressed in this PR -- structure only.

nix fmt clean, both pre-push lints clean.

2026-09-02 01:55:37 +02:00

3.1 KiB

Raw Blame History

Lifecycle and approvals tools

Two tool groups govern agent lifecycle management and config changes. Both are scoped to direct children only (topology-enforced: the server rejects any name that is not a direct child of the calling agent per topology.json). Privileged agents (e.g. ruth) may operate on any sub-agent — the topology scope applies to all others.

`lifecycle` tool group

No operator approval required. Direct children only.

`kill(name)`

Graceful stop. Container state is preserved; recreating the agent reuses prior config and credentials.

`start(name)`

Start a stopped sub-agent.

`restart(name)`

Stop + start in one call.

`update(name)`

Rebuild: re-applies the current hyperhive flake + agent.nix, then restarts. Idempotent — safe to call repeatedly. Used in response to needs_update system events.

`list_containers()`

List all descendant containers (children + their subtrees) with running status. Topology-scoped to descendants only.

`approvals` tool group

Config changes and new-agent spawns route through the operator approval queue. Direct children only (topology-enforced).

`request_init_config(name, description?)`

Step 1 of spawning a new direct child agent. Queues an InitConfig approval; on operator approve, hive-c0re seeds the proposed config repo at /agents/<name>/config/agent.nix with a default template and delivers a config_ready system event. Then edit agent.nix, commit, and the operator spawns the agent (the dashboard ◆ R3QU3ST SP4WN button / Spawn approval, routed via HostRequest::RequestSpawn), which creates the container from that config.

Subsequent config changes go through a forge PR on the agent's agent-configs/<name> repo (queues a MergeConfigPr approval on open/update — no MCP tool involved), not a tool call. See docs/agent-lifecycle/approvals.md.

Fails if a proposed config repo for name already exists. name is ≤ 9 characters.

`request_update_meta_inputs(inputs?, description?)`

Queue an approval to run nix flake update [inputs...] on the meta flake. Pass specific input names (e.g. ["bitburner-agent"]) or omit / pass [] for all inputs. Returns immediately; the lock update runs on operator approval.

Does NOT trigger container rebuilds — call update(name) on affected agents after the approval resolves.

Boundary summary

Operation	Requires approval?	Scope
`kill` / `start` / `restart` / `update`	No	Direct children
`list_containers`	No	All descendants
`request_init_config`	Yes (InitConfig)	New direct child only
`request_update_meta_inputs`	Yes (MetaUpdate)	Meta flake (global)

3.1 KiB Raw Blame History

Lifecycle and approvals tools

lifecycle tool group

kill(name)

start(name)

restart(name)

update(name)

list_containers()

approvals tool group

request_init_config(name, description?)

request_update_meta_inputs(inputs?, description?)