Generate harness memory bootstrap files from the inventory registry at build time #123

New issue

Closed

opened 2026-09-30 21:54:45 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-09-30 21:54:45 +01:00

Generate every harness's memory bootstrap at VM build time from the allod/inventory registry, so a session reads absolute memory.md paths written by the same build that creates the checkouts those paths name.

Primary goals:

Single generator — one home-manager module in this repo reads the checkout map from allod/inventory and writes the pi, codex, and claude bootstrap files with absolute memory.md paths, one per registered memory repo.
Build-time proof — the module fails the build when a registered memory checkout is missing at its declared path, so a wrong location is a build defect instead of a silent session miscount.
One-hop shim — sessions read memory.md directly; the adapters/<harness>/ pointer layer in the memory repos is deleted after one transition cycle.
Fleet reuse — a new VM profile inherits the module and gets an identical memory shim with no per-VM configuration; supporting a future harness means adding one template to the generator, once.

Current state and specifics

The only absolute truth in today's shim is the hand-maintained harness bootstrap file (pi's ~/.pi/agent/AGENTS.md, and equivalents). Everything below it is a chain of relative pointers: the bootstrap names adapter files inside each memory repo, and each adapter says "read ../../memory.md relative to this file." That resolves correctly only while checkouts sit at the registry's canonical paths, and the map of those canonical paths exists only as prose inside memory.md — which a session can read only after the pointer chain has already resolved. A session that mis-resolves has nothing machine-checkable to catch itself against.

Two defects compound this. First, the adapter files have drifted between memory repos: the public repo's adapters carry a gloss ("the repository root") and a recovery clause ("if that path does not resolve, locate the file before continuing"), and the private forks' copies have dropped both, so the recovery instruction exists only where resolution never fails. Second, the resolved path shapes collide across repos (…/allod/memory/memory.md vs …/<name>/memory.md — same filename, different nesting), so a session that resolves the first naturally mirrors that shape onto the second and hits ENOENT. A session this week did exactly that, then compounded it by treating the container directory of public checkouts as a repository when reporting the failure. The claude harness additionally maintains a projects-directory symlink by hand. All of this is position-dependent configuration that the build could own instead.

Scope

In scope: the generator module and per-harness templates (pi, codex, claude); the build-time existence assertion for registered memory checkouts; deletion of the adapters/ layer from allod/memory; a handoff item for each deployment to delete its private memory fork's adapters once its profiles rebuild; and generation of the claude projects symlink instead of hand-maintenance. Out of scope: runtime registry resolution at session start (adds a runtime dependency to the one thing that must never fail silently), any repository renaming or layout change (the memory repos' layouts are already identical and correct), and any change to memory.md content policy.

Generate every harness's memory bootstrap at VM build time from the allod/inventory registry, so a session reads absolute `memory.md` paths written by the same build that creates the checkouts those paths name. Primary goals: - **Single generator** — one home-manager module in this repo reads the checkout map from allod/inventory and writes the pi, codex, and claude bootstrap files with absolute `memory.md` paths, one per registered memory repo. - **Build-time proof** — the module fails the build when a registered memory checkout is missing at its declared path, so a wrong location is a build defect instead of a silent session miscount. - **One-hop shim** — sessions read `memory.md` directly; the `adapters/<harness>/` pointer layer in the memory repos is deleted after one transition cycle. - **Fleet reuse** — a new VM profile inherits the module and gets an identical memory shim with no per-VM configuration; supporting a future harness means adding one template to the generator, once. ### Current state and specifics The only absolute truth in today's shim is the hand-maintained harness bootstrap file (pi's `~/.pi/agent/AGENTS.md`, and equivalents). Everything below it is a chain of relative pointers: the bootstrap names adapter files inside each memory repo, and each adapter says "read `../../memory.md` relative to this file." That resolves correctly only while checkouts sit at the registry's canonical paths, and the map of those canonical paths exists only as prose inside `memory.md` — which a session can read only after the pointer chain has already resolved. A session that mis-resolves has nothing machine-checkable to catch itself against. Two defects compound this. First, the adapter files have drifted between memory repos: the public repo's adapters carry a gloss ("the repository root") and a recovery clause ("if that path does not resolve, locate the file before continuing"), and the private forks' copies have dropped both, so the recovery instruction exists only where resolution never fails. Second, the resolved path shapes collide across repos (`…/allod/memory/memory.md` vs `…/<name>/memory.md` — same filename, different nesting), so a session that resolves the first naturally mirrors that shape onto the second and hits ENOENT. A session this week did exactly that, then compounded it by treating the container directory of public checkouts as a repository when reporting the failure. The claude harness additionally maintains a projects-directory symlink by hand. All of this is position-dependent configuration that the build could own instead. ### Scope In scope: the generator module and per-harness templates (pi, codex, claude); the build-time existence assertion for registered memory checkouts; deletion of the `adapters/` layer from allod/memory; a handoff item for each deployment to delete its private memory fork's adapters once its profiles rebuild; and generation of the claude projects symlink instead of hand-maintenance. Out of scope: runtime registry resolution at session start (adds a runtime dependency to the one thing that must never fail silently), any repository renaming or layout change (the memory repos' layouts are already identical and correct), and any change to `memory.md` content policy.

allod-agent referenced this issue from a commit

2026-09-30 22:42:18 +01:00

Drop the adapters layer

allod-agent referenced this issue from a commit

2026-09-30 22:42:18 +01:00

Mark memory repositories in the registry

allod-agent referenced this issue from allod/inventory

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

Mark memory repositories in the registry #20

allod-agent referenced this issue from a pull request from allod/memory that will close it,

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

Drop the adapters layer #75

allod-agent referenced this issue

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

Generate harness memory bootstraps from the registry #124

allod-agent referenced this issue from a commit

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

Generate memory bootstraps from registry

allod-agent commented

2026-09-30 22:52:07 +01:00

Member

Handoff item for each deployment (private memory forks):

Once your profiles rebuild on the allod/archetypes memory-bootstrap generator (allod/archetypes#124), delete your private memory fork's adapters/ layer the same way allod/memory PR #75 does: git rm -r adapters, and drop the adapter section from the fork's README. The harness bootstraps no longer name adapter files; the Claude attribution-ban policy now lives in the archetypes generator's Claude template, so it survives the deletion.

Sequencing across the chain, for the integrator:

Merge allod/inventory#20 (registry memory flag — additive, safe anytime).
Merge allod/archetypes#124 after that; its branch then takes one lock-bump commit for inventory before the rebuild.
Rebuild every fleet VM (rebuild-vm <name> on the hypervisor).
Merge allod/memory#75 — gated on step 3, because sessions on a not-yet-rebuilt VM still resolve the old bootstrap through adapters/.
Each deployment repeats step 4's deletion on its private fork after its own rebuild.

Handoff item for each deployment (private memory forks): Once your profiles rebuild on the allod/archetypes memory-bootstrap generator (allod/archetypes#124), delete your private memory fork's `adapters/` layer the same way allod/memory PR #75 does: `git rm -r adapters`, and drop the adapter section from the fork's README. The harness bootstraps no longer name adapter files; the Claude attribution-ban policy now lives in the archetypes generator's Claude template, so it survives the deletion. Sequencing across the chain, for the integrator: 1. Merge allod/inventory#20 (registry `memory` flag — additive, safe anytime). 2. Merge allod/archetypes#124 after that; its branch then takes one lock-bump commit for inventory before the rebuild. 3. Rebuild every fleet VM (`rebuild-vm <name>` on the hypervisor). 4. Merge allod/memory#75 — gated on step 3, because sessions on a not-yet-rebuilt VM still resolve the old bootstrap through `adapters/`. 5. Each deployment repeats step 4's deletion on its private fork after its own rebuild.