vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: a config change is a PR from a clone, not an edit in place

Browse source 
Seven places described an authoring flow that does not exist: the
manager editing and committing a child's config in the bind-mounted
config dir. mara, on the snapshot issue: "the pr workflow is the main
one, anything else is legacy … the config dir in agent container is
read only copy to see own config … changes need to go through local
clone and via forge".

Two of the seven are the request_init_config MCP tool description and
its args struct, which are rendered into the system prompt of every
agent holding the approvals tool group. A wrong tool description is not
a stale comment; it is an instruction the whole hive reads as fact,
which is why the claim kept being repeated back.

The init tool creates the repo and seeds it. Nothing else. Tailoring
the seeded template is not a separate mechanism - it is the ordinary
config-change flow, a PR reviewed like any other.

Prose only; the code already implements the PR flow (an approval's
commit_ref is a PR number). Where a doc justified the parent's
read-write mount on the child's config dir with the authoring model,
the justification is removed rather than replaced: that mount is a
defect tracked on its own issue, and it should not read as intentional
while it waits.
This commit is contained in:
atlas 2026-08-04 22:40:22 +02:00
commit bed7ae6d5a
6 changed files with 65 additions and 47 deletions
Download patch file Download diff file Expand all files Collapse all files

10
docs/persistence.md
View file

@ -319,10 +319,12 @@ A parent agent gets each direct child's `state`, `harness`, and
`lifecycle.rs`). The RW on `state` is deliberate, not an oversight: a
parent manages its children, which includes writing into a child's
state for recovery (e.g. seeding notes, clearing a stuck sentinel) as
well as reading it. `config` is RW because the parent authors proposed
config changes for the child (the approval flow commits into the
child's config repo), and `harness` is RW for the same management
reasons. Per-child isolation still holds: a container only ever has
well as reading it. `config` and `harness` are RW too, but **nothing
justifies that for `config`**: a config change is a PR on the child's
config repo, made from a clone, so the bind-mounted `config` dir is a
read-only *copy* for reading a child's config — not a tree anyone edits
in place. Narrowing it is tracked separately, and depends on relocating
where `InitConfig` seeds. Per-child isolation still holds: a container only ever has
its *own* dirs plus its direct children's bind-mounted, never a
sibling's.