The dogfood release gate is unrunnable for every sibling repo whenever aprender is not on main #2701

Found while running pmat's 3.32.0 pre-release protocol. This is the revisit trigger the shim itself names, and it has now fired.

Reproduction, today

$ cd /home/noah/src/aprender && git rev-parse --abbrev-ref HEAD
fix/benchmark-matrix-determinism

$ ls scripts/dogfood.sh
ls: cannot access 'scripts/dogfood.sh': No such file or directory

$ git cat-file -e origin/main:scripts/dogfood.sh && echo present-on-main
present-on-main          # 1,419 lines

$ bash ~/.claude/skills/dogfood/dogfood.sh
dogfood: the canonical runner is not reachable.
  looked for: /home/noah/src/aprender/scripts/dogfood.sh
exit 2

The file is not deleted. It is on main, and the checkout is on a feature branch. A release gate for the entire fleet is therefore a function of which branch an unrelated repository happens to have checked out.

Why this is the trigger, not a new problem

~/.claude/skills/dogfood/dogfood.sh says so itself, verbatim:

REVISIT TRIGGER — the one signal that this arrangement has outgrown itself: the first time dogfood is invoked on a crate whose OWN repo is checked out but aprender is NOT. That means the protocol is being asked to serve the fleet from a repo that is not present, and the correct answer is to move it into shared infra — not to copy the runner back here.

That condition is now met — with a nuance worth recording, because it is worse than the one anticipated: aprender is checked out. It is simply on the wrong branch. The trigger as written checks for an absent repository; the failure mode that actually occurs is an absent file in a present repository, which is far easier to hit and gives no signal that anything is wrong until a release is blocked.

History says this recurs

aprender#2640 removed a second divergent copy of this runner (nine silent divergences, every hunk a real hardening, neither copy safe to delete). The fix chosen there was this shim. That got the diagnosis right — one canon, not two — and the cure wrong: the target is a path in another repository's working tree.

It has already cost a real release once. Measured 2026-08-23, mid-release: aprender sat on fix/wgpu-feature-surface-contract, scripts/dogfood.sh was absent, and pmat's release gate exited 2. Three edits to shared directories were silently lost the same day for the same underlying reason.

pmat's response was to vendor the protocol into its own repo (scripts/dogfood/, files prefixed pmat- so symlinks into a shared skills dir cannot collide). That works, and it means pmat is not blocked — but it is one crate solving it for itself. Every other repo reaching for this skill today gets a release gate that cannot run, and a release protocol that cannot run is indistinguishable from no release protocol.

Ask

Move the runner somewhere its availability does not depend on a working tree — shared infra, an installed artifact, or a per-repo vendored copy on pmat's model. Explicitly not a second copy under ~/.claude/skills/: not in git, not PR-reviewed, not CI-reachable, not diffable, which is what produced #2361 and #2640.

Whatever is chosen, two properties are worth making non-negotiable, because both were absent here:

• Resolution must not depend on any repository's checked-out branch. Reading from git show main:scripts/dogfood.sh would already be strictly better than reading the working tree, if the shim stays.
• The shim's own guard must detect the failure that actually happens. It checks "is aprender present"; it needs to check "is the runner reachable", which is the weaker and correct precondition.

Filed from pmat's 3.32.0 pre-release, where this was hit and worked around rather than fixed.