reference-impl 0.13.6 — the plugin manifests rejoin the version they ship

Patch: the last version site that ships is no longer carried by a release note — and the one that was wrong is fixed.

reference-impl/.claude-plugin/plugin.json and the repo-root .claude-plugin/marketplace.json had been stale since 0.13.3, sitting at 0.13.2 against a package.json of 0.13.5. Both are back in lockstep, and a third roster in tests/package-contract.test.ts holds them there.

Why this was a defect and not untidiness

Claude Code pins an installed plugin to the version string in plugin.json and offers an update only when that string changes. It never consults package.json on that path. Version resolution runs plugin.json > marketplace entry > commit SHA, so the stale manifest — not npm's metadata — was the binding fact. Anyone who installed the plugin from this repo was held at 0.13.2, with the content of 0.13.3, 0.13.4 and 0.13.5 unreachable to them.

Shape

The two files are guarded against package.json rather than against each other. claude plugin tag already validates that they agree with one another; nothing validated either against package.json, which is the axis that actually drifted.

They anchor differently because they sit differently. A plugin.json describes the package whose directory encloses .claude-plugin, so its anchor is the parent's package.json. A marketplace entry names its plugin through source, and the repo root has no package.json at all, so each entry resolves through that source — which also means a second plugin added to the catalogue is guarded the day it arrives. A source is relative to the marketplace root rather than to the .claude-plugin directory holding it; resolving it the other way reads as ENOENT rather than as a version failure, so that distinction is pinned in a comment.

Three roster pins rather than two — the plugin manifests, the marketplace files, and the entries within a catalogue — because an entry silently dropped from plugins[] would generate no assertions and read as a pass.

Unlike the two guards added in 0.13.5, which were green on arrival and provable only by mutation, this one was red on arrival against a real pre-existing failure — twice, once per file, each reporting 0.13.2 where 0.13.5 was expected. Six further mutations cover what the arrival red could not: a roster pin firing alone on an in-sync newcomer, firing alongside a freshly generated assertion on a drifted one, the two catalogue pins, and a negative planting a drifted manifest under node_modules to show the skip is load-bearing. Drifting package.json alone fires five assertions across all three rosters, which is the proof that the anchor is external — both sides drifting together is not a blind spot.

⚠ Correction to the 0.13.5 release notes

Those notes said these two files were deliberately not guarded because "they bump on feature releases only and the patch train leaves them behind". That was inherited from an older note rather than measured, and it is wrong on both counts. The version field is functional, as above. And the release history records no such rule: across all 46 reference-impl-v* tags there are five completed lag episodes, of which two closed on a patch release (0.6.5, 0.7.4), while the 0.7.0 minor passed straight through a lag without closing it. Patch trains have both bumped these files and skipped them. The 9.9.9 mutations described there remain accurate as a statement of behaviour — the guard genuinely did not fire on those files at the time — but the stated reason was an unexamined habit, not a rule. The 0.13.5 notes have been annotated in place.

The reference-impl bump list is seven sites now, of which six are self-enforcing: package.json, VERSION, both package-lock.json fields, tests/skills.test.ts, and the two plugin manifests. Only CHANGELOG.md remains unguarded, deliberately, being prose. Neither guard ships — tests/ is not in the published files.