plugins/skill-quality/.claude-plugin/plugin.json on main (3018a5089d, merged from #1096) contains two version members:
4: "version": "0.11.0",
5: "version": "0.12.0",
Impact
The advertised release is parser-dependent: last-wins readers (jq, Python json.load) resolve 0.12.0; first-wins readers retain 0.11.0; duplicate-rejecting consumers can reject the manifest outright. That can prevent or misidentify a plugin update. Surfaced by external review on #1096 after merge.
Fix
Delete line 4. The intended release is 0.12.0, which is what the CHANGELOG's top section and the marketplace catalog already describe.
Root cause, so the same shape does not recur
Introduced while resolving the second main merge in #1096. Both sides of that conflict carried "version": "0.11.0" — main had released 0.11.0 in #1450 and the branch also claimed 0.11.0 — so git treated the version line as common context outside the conflict region and left only the differing description inside it. A scripted replacement of the conflict region emitted a fresh version + description pair, adding a second version above the surviving common-context one.
Both verification steps in play were blind to it by construction:
python -c "json.load(...)['version']" returns the last-wins value, so it printed the expected 0.12.0.scripts/validate-plugins.sh validates against the manifest schema, which duplicate keys do not violate under a last-wins parser.
Worth considering as a follow-up: a duplicate-key check over plugins/*/.claude-plugin/plugin.json in the plugin gate. Python exposes it cheaply via json.load(..., object_pairs_hook=...), which is what identified this instance. A manifest-level guard would catch the whole class rather than this one occurrence.
plugins/skill-quality/.claude-plugin/plugin.jsononmain(3018a5089d, merged from #1096) contains twoversionmembers:Impact
The advertised release is parser-dependent: last-wins readers (
jq, Pythonjson.load) resolve0.12.0; first-wins readers retain0.11.0; duplicate-rejecting consumers can reject the manifest outright. That can prevent or misidentify a plugin update. Surfaced by external review on #1096 after merge.Fix
Delete line 4. The intended release is
0.12.0, which is what the CHANGELOG's top section and the marketplace catalog already describe.Root cause, so the same shape does not recur
Introduced while resolving the second
mainmerge in #1096. Both sides of that conflict carried"version": "0.11.0"— main had released 0.11.0 in #1450 and the branch also claimed 0.11.0 — so git treated the version line as common context outside the conflict region and left only the differingdescriptioninside it. A scripted replacement of the conflict region emitted a freshversion+descriptionpair, adding a secondversionabove the surviving common-context one.Both verification steps in play were blind to it by construction:
python -c "json.load(...)['version']"returns the last-wins value, so it printed the expected0.12.0.scripts/validate-plugins.shvalidates against the manifest schema, which duplicate keys do not violate under a last-wins parser.Worth considering as a follow-up: a duplicate-key check over
plugins/*/.claude-plugin/plugin.jsonin the plugin gate. Python exposes it cheaply viajson.load(..., object_pairs_hook=...), which is what identified this instance. A manifest-level guard would catch the whole class rather than this one occurrence.