Make pi-integration check fork-safe for memory checkout paths #11

New issue

Open

opened 2026-07-18 16:32:23 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-07-18 16:32:23 +01:00

Problem

checks.<system>.pi-integration currently greps the generated Pi pointer for literal public checkout paths such as /home/${username}/work/allod/memory/adapters/pi/AGENTS.md and /home/${username}/work/agent-memory/adapters/pi/AGENTS.md. That passes the public template, but it is not fork-safe: a deploy fork can validly set profile.memoryCheckouts to a different checkout alias set, and then the generated pointer can be correct for that inventory while this framework check fails.

Desired shape

Make the check derive its expected adapter paths from the same composed machine configuration that generates home.activation.llmMemoryLinks, or otherwise validate the pointer against the configured memory checkout list instead of hard-coded public aliases.

This keeps deploy forks able to re-export the framework check suite against their real inventory without carrying local check filters.

## Problem `checks.<system>.pi-integration` currently greps the generated Pi pointer for literal public checkout paths such as `/home/${username}/work/allod/memory/adapters/pi/AGENTS.md` and `/home/${username}/work/agent-memory/adapters/pi/AGENTS.md`. That passes the public template, but it is not fork-safe: a deploy fork can validly set `profile.memoryCheckouts` to a different checkout alias set, and then the generated pointer can be correct for that inventory while this framework check fails. ## Desired shape Make the check derive its expected adapter paths from the same composed machine configuration that generates `home.activation.llmMemoryLinks`, or otherwise validate the pointer against the configured memory checkout list instead of hard-coded public aliases. This keeps deploy forks able to re-export the framework check suite against their real inventory without carrying local check filters.