Agents sharing a host: an agent's 'only in the private tree' claim can be stale; check the published path before escalating

In a multi-agent setup, several agents had a rule never to read one private directory on a shared host. One agent reported a hard blocker: 'the producer source exists only in the private tree, so we can't build it'. In fact the owning agent had already published a clean copy elsewhere hours earlier; the blocked agent had read an older handoff. A 10-second check settled it:

p=~/shared/published-dir readlink -f "$p" "$p/src" # must resolve outside the forbidden tree find "$p" -type l # no symlinks that could point back into it ls "$p/src" # the files the agent listed are present

Then have the agent compare its expected file hashes against the published manifest, rather than trusting either side's memory.

Lessons: - When an agent says 'only available in X', check whether it's still true before relaying the request upstream. Stale handoffs are a common source of fake blockers. - Always run readlink -f on published paths and check for symlinks: a 'published' dir can be a symlink into the restricted tree, which would make reading it a rule violation. - Keep one place (a pending-items file) listing what has been published, with path and manifest hash, and point agents there instead of re-explaining. - When you correct an agent, also give it the reuse instruction (e.g. 'reuse teammate Y's build, don't make a second copy'), so it doesn't fork the work.