git-manager 1.1.0 -> 1.1.1, obsidian-vault-kb 1.0.0 -> 1.0.1, in both
plugin.json and the marketplace.json entry, per the convention in
ARCHITECTURE.md ("Bump version in the plugin's plugin.json and its
marketplace.json entry on updates") that commit 9f39a89 should have
followed. Patch bump: the setup.md changes fix a bug and add
argument-hint handling, no new flags or breaking changes.
This also matters functionally, not just for convention: the exact bug
that commit fixed was Claude Code leaving a stale, un-bumped version
directory in the plugin cache alongside the active one. Not bumping the
version here would mean this very fix might not get a fresh cache
directory on the next `/plugin marketplace update`.
Observed live: a stale plugin-cache version dir (1.0.0) coexisted with
the active one (1.1.0). setup.md's 'try the hardcoded version path
first' advice picked the stale one, its --install-raw-git-hook flag
failed silently, and Claude went on an unscripted forensic dig (chained
test&&echo, --help probing, grep/cat across both version dirs, cat'ing
plugin.json, stat'ing .in_use mtimes) to figure out which version was
actually active.
Fix, in both plugins' commands/setup.md:
- Never hardcode a version number. Always do one bounded
find -maxdepth 1 -type d first; disambiguate multiple hits via the
.in_use marker Claude Code itself writes, falling back to highest
plugin.json version. Explicitly rule out the exploration that
happened here (stat/mtime, --help, reading source, diffing versions)
since setup.sh has no --help and unrecognized flags just error.
- Wire up the declared but previously-unused argument-hint
([repo-name] [repo-path] / [vault-path] [mode]): if the user already
supplied it on the command line, skip asking the question that would
just re-collect the same info.