fix(version): sync plugin manifests with package.json on version bump

[grlee]

Problem

The plugin manifests have been frozen at 0.3.0 across four releases:

File	main HEAD
package.json	0.5.2
.claude-plugin/plugin.json	0.3.0
.claude-plugin/marketplace.json (metadata + plugins[0])	0.3.0
server/index.ts MCP server version literal	"0.3.0"

Each chore: bump version to X commit (#93, #97, #100, #102) only touched package.json. As a result:

• Marketplace clients reading .claude-plugin/marketplace.json see version 0.3.0.
• The MCP server registers itself with the SDK (new McpServer({ ..., version })) as 0.3.0 regardless of installed version.
• Anyone debugging "what version of claude-buddy do I have?" gets a misleading answer.

Fix

• New scripts/sync-version.ts makes package.json the single source of truth and writes the manifest files to match. Supports --check for CI drift detection (non-zero exit on mismatch).
• New "version" lifecycle script in package.json — bun pm version <bump> (or npm version <bump>) now runs the sync and git adds the manifest files into the auto-generated version commit. No follow-up commit needed.
• server/index.ts now imports version from package.json instead of a hardcoded literal, using the standard JSON import attribute syntax.
• Catches up the manifest files to the current 0.5.2.

Verification

• bun run typecheck passes (the with { type: "json" } import resolves cleanly).
• bun test passes — 246/246 tests, no failures.
• bun run sync-version --check exits 0 after this PR (drift resolved).
• Re-running bun run sync-version is idempotent — reports "all version fields already at 0.5.2" and does not modify any file.
• Smoke test: bun -e 'import pkg from "./package.json" with { type: "json" }; console.log(pkg.version)' prints 0.5.2.

Known minor side-effect

scripts/sync-version.ts uses JSON.stringify to write the manifest files. On the first future drift event (i.e. the next bun pm version <bump>), the existing — em-dash escapes in the description fields will be re-encoded as raw — characters. This is a one-time cosmetic round-trip; both forms are semantically identical JSON. Not addressed in this PR to keep the diff scoped to the version-sync fix, but happy to add normalization beforehand if you'd prefer the first sync commit to be purely version-only.

Future-proofing

CI could add bun run sync-version --check as a guard so this regression cannot recur. Happy to add in a follow-up if desired.

[ramarivera]

Hey @grlee — triaging the queue post-rename. Good news: this is not superseded — current main still has no version-sync mechanism, so the idea stands. It does need a refresh though: main is now at 0.6.0, the plugin was renamed claude-buddy → coding-buddy, and npm trusted publishing landed (#132/#133), so the manifest contents your script touches have changed. A rebase updating the hardcoded bits should make this land smoothly.

🤖 Created with the help of AI (Claude Fable 5).

[ramarivera]

Thanks for this @grlee — the diagnosis and the design were both right, and the drift had gotten worse since you filed: the plugin manifests were at 0.8.0 and the MCP handshake in server/index.ts was at 0.6.0 while the package shipped 0.9.3.

This PR now conflicts with main and lives on a fork, so I could not rebase it. I have landed the same approach in #174 — scripts/sync-version.ts with a --check mode, the npm version lifecycle hook, and server/index.ts importing pkg.version instead of a literal — plus a CI step running --check so drift cannot land again, and tests. Your PR is credited in the commit message and the PR body.

Two review findings on top of the original: the metadata.version setter needed to create an absent metadata block (otherwise --check could report drift the fixer would never repair), and scripts/** had to be added to the tsconfig include or the script CI depends on would never be typechecked.

Closing this in favour of #174 is up to @ramarivera. Either way — this was the right call and it is now shipped.

🤖 Created with the help of AI (Claude Opus 5).