In abcd's own source checkout the person wants every abcd invocation, the plugin's hooks and command pages included, to run a build of the checkout's HEAD (dogfooding), and in every other repository to run the most recently installed stable release, so the two can always be compared. Today the hooks and the command pages resolve the plugin-root binary first, which is the last published release (v0.13.1 at 2026-10-07), so inside this checkout the guard, the loader and every slash command run stale code unless an agent knows to substitute go run ./cmd/abcd; the DOGFOODING rule in .abcd/rules.json teaches the agent but cannot reach the hooks. Automatic detection of abcd's source was rejected: a repository posing as abcd would get its own code run by the hooks, the hazard the hook shim's PATH rung already refuses (a binary inside the working tree).

Frontmatter

.abcd/work/issues/resolved/iss-2610070547057816-in-abcd-s-own-source-checkout-the-person.md
open on GitHub ↗ · commit history ↗

mentions3

• dcn-26102809052072022026-10-28 — The plugin's hooks and command pages run a build of the checkout's HEAD in a checkout the person lists in ~/.abcd.noindex/dogfood-roots, and the installed release everywhere else, because iss-2610070547057816 records that the person wants exactly that, so no question was put. It does not conflict with AGENTS.md's go run rule: that rule governs the agent's own invocations in a source checkout and leaves the surface half to iss-2608230943088357, which this change addresses for the hooks and command pages (facilitator on delegation, lane D, 2026-10-28).
• iss-2610121240517742In a checkout listed in ~/.abcd.noindex/dogfood-roots, every hook shim but the PreToolUse one hands its event to the dogfood build with no fall-back to the installed release if that build dies. hooks/user-prompt-submit.sh, subagent-stop.sh, pre-compact.sh, post-tool-use.sh and session-end.sh replace the installed binary with the build that hook dogfood-binary names and exec it, and session-start.sh runs it in the release's place; a build that crashes, is killed or exits with an error leaves the rules loader, the router reset, the transcript capture or the session-start checks undone for that event, with nothing run in its stead. The brief's dogfood store section says a hook never runs weaker than the release, and only hooks/pre-tool-use.sh implements that, by handing the command to the installed release when the dogfood guard answers exit 1 or dies. Found in the round-2 security review of the dogfood remote fix (iss-2610070547057816).
• iss-2610241228359748Which abcd runs is confusing because several installs coexist and nothing says which one wins: the plugin can be installed at user scope and at project scope at once, each with its own plugin-root binary, and there is also a PATH binary (ahoy install) and, in abcd's own checkout, a source build (go run). Observed 2026-10-24: the person updated the plugin to v0.15.1, but the update landed as a new project-scope install for this repository while the user-scope install stayed at 0.13.3, and the session went on loading the user-scope copy (command pages still named .../abcd/0.13.3/abcd, its hooks bootstrapped there at 14:23); the 0.15.1 directory had never bootstrapped and held no binary; and the binary inside the 0.13.3 directory reported v0.14.1, so even the directory name did not say which version ran. Nothing in the board, ahoy or the command pages surfaced any of this. The person wants it unified (for example: does a repository-scope plugin win over a user-scope one, and how does the CLI on PATH relate to either?). Earlier rulings each settled one rung on its own (dcn-2609080000000001 the owned-only PATH rung for the hook shims, adr-2609151706587280 the cache-to-PATH attestation, iss-2610070547057816 dogfooding a source build in abcd's own checkout) without addressing the underlying problem: no single, stated precedence across plugin scopes, the plugin-root binary, the PATH binary and a source build.