Generate harness memory bootstraps from the registry #124

Merged

vnprc merged 1 commit from agent/memory-bootstrap into master

2026-09-30 23:31:54 +01:00

allod-agent commented

2026-09-30 22:51:45 +01:00

Member

Owner summary

What changes for a running machine: after rebuild, ~/.pi/agent/AGENTS.md, ~/.codex/AGENTS.md, and ~/.claude/CLAUDE.md name each memory checkout's memory.md directly, with paths derived at build time from the inventory registry's memory-marked entries; the adapters/<harness>/ pointer layer is no longer read.
What stays identical: pointer file locations, the atomic rewrite, the claude projects symlink, status lines, yolo, shell aliases, and memory.md content.
What proves it: four gates pass (below) with the registry flag present, each new eval assertion is pinned by a sabotage witness, and the generated activation script renders the one-hop bootstrap exactly.
If it is wrong: rebuild the VM on the previous archetypes pin — the adapter layer still exists until the memory-repo PR merges, so old behavior is restorable by rebuild alone.
Merge order: requires the allod/inventory registry-flag PR to merge first; a follow-up commit on this branch then bumps the inventory lock (the gates below ran with that branch overridden in, since the lock cannot point at an unmerged worktree).

Deviations from the issue as written

The build-time proof is eval-time, not filesystem existence: a pure-eval Nix build cannot stat the VM's ~/work, and checkouts are cloned by bootstrap-vm only after first activation, so an activation-time existence assertion would strand first boot. The module instead fails evaluation when a registry entry marked memory has no usable checkout path, or is absent from the machine's repos list — the checkout then cannot exist where the bootstrap names it.
The Claude adapter's attribution-ban policy moved into the generated Claude template so it survives adapter deletion.
The claude projects-directory symlink was already generated by ai-agents.nix; no change was needed.

Risk

R3 — cross-repo sequencing (inventory flag → this module → memory adapters deletion) and generated session-start behavior. One cold cross-family review ran after the final code state: FINDINGS: 1 (the disclosed lock-sequencing gate above), COMMENT-FINDINGS: 0; no code defect. Rollback is a straight revert plus rebuild.

Validation

With --override-input inventory <registry-flag branch>, all exit 0:

nix build .#checks.x86_64-linux.pi-integration --no-link -L (includes the new sabotage witnesses: memory-marked entry absent from repos, unsafe checkout, empty derived list)
nix build .#checks.x86_64-linux.dev-inventory-pointer --no-link -L
nix build .#checks.x86_64-linux.profile-definition-contracts --no-link -L
nix eval --raw .#nixosConfigurations.allod-dev.config.system.build.toplevel.drvPath

The composed activation script renders, for each harness, an atomic write of:

# <Harness> Memory
At conversation start, before responding to the first user message, read each configured memory file — proceeding with memory unread is a defect:

1. `/home/<user>/work/allod/memory/memory.md`

with the Claude template additionally carrying the attribution-ban policy. Not run: ./fork-safety.sh (pin witness, lock-bump path) and full allod check (the locked inventory predates the flag; the suite runs clean once the lock bump lands after the inventory PR merges).

Refs allod/archetypes#123

## Owner summary - What changes for a running machine: after rebuild, `~/.pi/agent/AGENTS.md`, `~/.codex/AGENTS.md`, and `~/.claude/CLAUDE.md` name each memory checkout's `memory.md` directly, with paths derived at build time from the inventory registry's memory-marked entries; the `adapters/<harness>/` pointer layer is no longer read. - What stays identical: pointer file locations, the atomic rewrite, the claude projects symlink, status lines, `yolo`, shell aliases, and `memory.md` content. - What proves it: four gates pass (below) with the registry flag present, each new eval assertion is pinned by a sabotage witness, and the generated activation script renders the one-hop bootstrap exactly. - If it is wrong: rebuild the VM on the previous archetypes pin — the adapter layer still exists until the memory-repo PR merges, so old behavior is restorable by rebuild alone. - Merge order: requires the allod/inventory registry-flag PR to merge first; a follow-up commit on this branch then bumps the inventory lock (the gates below ran with that branch overridden in, since the lock cannot point at an unmerged worktree). ## Deviations from the issue as written - The build-time proof is eval-time, not filesystem existence: a pure-eval Nix build cannot stat the VM's `~/work`, and checkouts are cloned by `bootstrap-vm` only after first activation, so an activation-time existence assertion would strand first boot. The module instead fails evaluation when a registry entry marked `memory` has no usable checkout path, or is absent from the machine's `repos` list — the checkout then cannot exist where the bootstrap names it. - The Claude adapter's attribution-ban policy moved into the generated Claude template so it survives adapter deletion. - The claude projects-directory symlink was already generated by `ai-agents.nix`; no change was needed. ## Risk R3 — cross-repo sequencing (inventory flag → this module → memory adapters deletion) and generated session-start behavior. One cold cross-family review ran after the final code state: FINDINGS: 1 (the disclosed lock-sequencing gate above), COMMENT-FINDINGS: 0; no code defect. Rollback is a straight revert plus rebuild. ## Validation With `--override-input inventory <registry-flag branch>`, all exit 0: - `nix build .#checks.x86_64-linux.pi-integration --no-link -L` (includes the new sabotage witnesses: memory-marked entry absent from repos, unsafe checkout, empty derived list) - `nix build .#checks.x86_64-linux.dev-inventory-pointer --no-link -L` - `nix build .#checks.x86_64-linux.profile-definition-contracts --no-link -L` - `nix eval --raw .#nixosConfigurations.allod-dev.config.system.build.toplevel.drvPath` The composed activation script renders, for each harness, an atomic write of: # <Harness> Memory At conversation start, before responding to the first user message, read each configured memory file — proceeding with memory unread is a defect: 1. `/home/<user>/work/allod/memory/memory.md` with the Claude template additionally carrying the attribution-ban policy. Not run: `./fork-safety.sh` (pin witness, lock-bump path) and full `allod check` (the locked inventory predates the flag; the suite runs clean once the lock bump lands after the inventory PR merges). Refs allod/archetypes#123

allod-agent added 1 commit

2026-09-30 22:51:45 +01:00