In a source checkout of abcd itself, the plugin-root binary and any abcd on PATH are the last published version, so they are stale by construction and fall further behind with every commit, and the failure is not always a refusal. Three hits in one session while cutting v0.7.0: launch ship refused on its surface guard, correctly and loudly; changelog --json returned an empty cut against a tree with 181 shipped records, no error, a plausible wrong answer briefly read as evidence about the release; and capture would have written records through a schema that predates the origin and production_mode disclosure pair the record gates now require. The plugin skill pages document a resolution ladder that reaches the plugin binary first and falls through to go run ./cmd/abcd only when nothing earlier resolves, and in this checkout the first rung exists and answers, so the fallback written for exactly this case is unreachable by following the ladder literally. The convention every agent in this repository needs is that every abcd invocation here is go run ./cmd/abcd from the repo root; it belongs in the committed record, in AGENTS.md and as a loader domain that fires on prompts naming an abcd verb, rather than in a per-machine handover note. Carried from the session handover into autonomous-run-2026-09-01; the skill pages' resolution order is the other half and stays with iss-2608230943088357.

Frontmatter

.abcd/work/issues/resolved/iss-2609012028144617-in-a-source-checkout-of-abcd-itself-the.md
open on GitHub ↗ · commit history ↗

mentions1

• iss-2608230943088357The plugin-root binary predates the verbs its own command surface documents, and the failure is an unknown-command error rather than a named refusal. Verified 2026-08-23: the commands/update.md page instructs the reader to run the plugin-root binary first, and that binary on this machine is v0.6.1, whose help lists no update verb at all. Running it as documented gives 'abcd: unknown flag: --yes', and running the bare verb gives 'abcd: unknown command "update" for "abcd"'. The page's own resolution ladder recovers the situation, since a source checkout falls through to go run ./cmd/abcd, but only for a reader who knows to keep going: the first rung produces an error that looks like a malformed invocation rather than a stale install. This refines iss-228, which records the same root cause with a different consequence -- a plugin-root binary sitting a month stale so ahoy's first resolution rung reported pre-iss-171 gaps with no staleness signal. That entry is about wrong gap reporting; this is about a documented command surface pointing at a binary that cannot serve it. The general shape is that the plugin surface and the plugin binary ship from one release but a repository checkout can be arbitrarily far ahead of the installed plugin, so every commands/*.md page documenting a verb newer than the reader's plugin has this failure mode, and update is merely the first to be noticed. Two directions, neither adopted: have the command pages degrade legibly when the resolved binary lacks the verb, by checking for it before invoking; or have the binary answer an unknown verb by naming its own version and vintage, so the error says stale rather than wrong. Worth deciding whether this is inherent to plugin-versus-checkout skew and therefore only a documentation problem, or whether the unknown-command path should carry install context.