Problem

Git tags and GitHub Releases advance independently of .claude-plugin/marketplace.json#version (and .claude-plugin/plugin.json#version). Because Claude Code's /plugin update reads the version from marketplace.json on main (not from git tags or the Releases API), users cannot receive plugin updates via /plugin update until the manifest version is bumped — even when a tag and a GitHub Release exist.

This appears to be a process gap rather than an intentional design, but I wanted to surface it explicitly.

Observed state (as of 2026-04-14)

So /plugin update mempalace correctly reports "already at the latest version" — the manifest says 3.0.14 everywhere, including inside the tagged commits of v3.1.0 and v3.3.0. The tags moved, the manifest did not.

Adjacent context: PR #855 (chore: bump version to 3.0.15) was closed without merging, which further suggests the intended release procedure is unclear from the outside.

Why this matters

Once #863 (fix for #858 — /compact blocked) is merged, users still won't get the fix through the standard update path until marketplace.json#version is bumped. The same applies to any future fix. The severity of #858 is masked because even motivated users who follow upstream can't pull the fix cleanly.

Reproduction

# GitHub Releases says there's a newer version
gh release list --repo MemPalace/mempalace --limit 3
# → MemPalace v3.3.0  Latest  2026-04-14

# But the manifest on main still says 3.0.14
gh api 'repos/MemPalace/mempalace/contents/.claude-plugin/marketplace.json' \
  --jq '.content' | base64 -d \
  | python3 -c 'import json,sys; print(json.load(sys.stdin)["plugins"][0]["version"])'
# → 3.0.14

# Same inside the v3.3.0 tag
gh api 'repos/MemPalace/mempalace/contents/.claude-plugin/plugin.json?ref=v3.3.0' \
  --jq '.content' | base64 -d | grep version
# → "version": "3.0.14"

In Claude Code:

/plugin
→ mempalace@mempalace — already at the latest version (3.0.14)

Is this intentional?

It is possible tags like v3.3.0 represent pre-release / preview / marketplace-staging builds that deliberately don't bump the manifest. If so, that convention isn't documented anywhere I could find, and the tags being marked Latest on the Releases page makes it look like a published update that simply isn't reaching users.

If it is unintentional, it's a process leak — version-bump commits for the manifest seem to have been dropped from the release workflow.

Suggested fixes (pick whichever fits your model)

1. Release checklist / single script — a make release VERSION=x.y.z that edits both marketplace.json and plugin.json, commits, tags, then pushes. Removes the chance of a tag outrunning the manifest.
2. CI guard — a workflow that runs on push: tags: - 'v*' and fails if git describe --tags HEAD does not match marketplace.json#version. Cheap, catches 100% of the drift.
3. Document the tagging convention — if tags are genuinely not meant to trigger user updates (e.g., "tags are internal milestones; user releases happen only via manifest bumps"), a short note in CONTRIBUTING.md / release docs clarifies it for downstream users and tools.

Happy to open a PR for option 2 if that would be welcome.

Not urgent, but high-leverage

This one is entirely about process rather than code, but it compounds every other bug fix — until it's resolved, fixes land in the repo but not in users' Claude Code installs.