Summary
A published jig version can currently resolve to different bytes depending on when it is installed.
The Claude marketplace entry uses an unpinned git-subdir source on the default branch, while the packaged plugin manifest declares an explicit semantic version. Claude Code uses that version as the cache key and skips updates while it is unchanged.
Evidence
This explains how two installations both labeled 2.7.0 can contain different code. It also means an existing 2.7.0 installation can skip post-release changes while a new 2.7.0 installation receives them.
Claude Code documents explicit plugin versions as cache keys and supports a ref or sha for git sources: https://code.claude.com/docs/en/plugin-marketplaces#version-resolution-and-release-channels
Desired invariant
A released version identifies one immutable plugin payload. Fresh install, reinstall, release zip, and cached install should agree on the bytes for that version.
Proposed direction
For the stable release channel, pin the Claude marketplace plugin source to the matching release tag, for example ref: v2.7.1, and make release automation update the source ref together with every version-bearing manifest.
Using commit-SHA versioning with no explicit semantic version is another valid model, but it would change jig from stable releases to every-main-commit updates and is therefore not the preferred default.
Audit Codex marketplace behavior at the same boundary so the dual-host packaging contract remains symmetric where host capabilities permit.
Acceptance criteria
- A remote install for version
X.Y.Z resolves plugin content from immutable tag or commit bytes corresponding to vX.Y.Z.
- Release automation updates the source ref and every version-bearing manifest atomically.
- Contract tests fail when a release version and marketplace source ref drift.
- Fresh-install and release-archive smoke tests prove byte or commit identity for the packaged payload.
- The chosen Claude behavior and any Codex-host difference are documented explicitly.
Related
Summary
A published jig version can currently resolve to different bytes depending on when it is installed.
The Claude marketplace entry uses an unpinned
git-subdirsource on the default branch, while the packaged plugin manifest declares an explicit semantic version. Claude Code uses that version as the cache key and skips updates while it is unchanged.Evidence
v2.7.0was tagged at 2026-07-12 16:14 PDT.2.7.0whoseworkflow.pycontained the post-tag fix, even though the taggedv2.7.0does not contain it. See workflow.py transition: prints success but on-disk status reverts to IN_PROGRESS (v2.2.0, linked worktree) #96.a247f76, the built Claude manifest still declared2.7.0, and the marketplace source still had noreforsha.This explains how two installations both labeled
2.7.0can contain different code. It also means an existing2.7.0installation can skip post-release changes while a new2.7.0installation receives them.Claude Code documents explicit plugin versions as cache keys and supports a
reforshafor git sources: https://code.claude.com/docs/en/plugin-marketplaces#version-resolution-and-release-channelsDesired invariant
A released version identifies one immutable plugin payload. Fresh install, reinstall, release zip, and cached install should agree on the bytes for that version.
Proposed direction
For the stable release channel, pin the Claude marketplace plugin source to the matching release tag, for example
ref: v2.7.1, and make release automation update the source ref together with every version-bearing manifest.Using commit-SHA versioning with no explicit semantic version is another valid model, but it would change jig from stable releases to every-main-commit updates and is therefore not the preferred default.
Audit Codex marketplace behavior at the same boundary so the dual-host packaging contract remains symmetric where host capabilities permit.
Acceptance criteria
X.Y.Zresolves plugin content from immutable tag or commit bytes corresponding tovX.Y.Z.Related
2.7.1release.