#3333 · milestone v10.0.0

Two GitHub releases, one distribution channel

The GitHub "Pre-release" badge protects nobody, because installation never reads GitHub Releases. This is the fix, and it is CC's own mechanism rather than a new one.

before 1 channel after 2 channels schema change needed none proven by live install

Why merging the alpha would have moved everyone

marketplace.json   source: "./plugins/ork"     relative, resolves at main
release-please     stamps $.plugins[0].version  on every release
                   ─────────────────────────────────────────────
                   merge 10.0.0-alpha to main
                        ↓
                   every marketplace user is now on the alpha

And the obvious fix looked blocked: test-marketplace-schema.sh allows exactly six plugin fields and hard-rejects anything else, so a sibling ref key was refused before CC ever saw it.

What CC actually accepts, derived by typed probe

A plain accept/reject test proves nothing here, because unknown keys inside source are silently ignored. A recognized field must reject a wrong type; that is the discriminator.

ProbestringnumberVerdict

The pin lives inside source, and source is already one of the six allowed fields. So the six-field gate never needed relaxing; it was never the obstacle.

{"source":"github",     "repo": required, "ref": optional, "sha": 40-hex}
{"source":"git-subdir", "url": required,  "path": required, "ref": optional}

The proof: two refs, two versions

Validation only shows a file parses. This shows the pin governs. Same repo, same path, different ref, run against the real 2.1.226 binary in an isolated CLAUDE_CONFIG_DIR.

plugin install ork-pinned-old@orkdiff      ref v9.7.0  ->  Version: 9.7.0
plugin install ork-tracking-main@orkdiff   ref main    ->  Version: 9.8.0

Both installed, coexisted, and resolved differently. Had they both reported the same version the design would be worthless, and validation alone would never have told us.

Resolver: what each channel gives a user

Move main's version and watch what each channel serves.

ork · ref v9.8.0
9.8.0
pinned, unaffected by main
ork-alpha · ref main
10.0.0-alpha
tracks main, opt-in only

The guard, and the trap it exists for

release-please addresses the entry to stamp by array index ($.plugins[1].version). Reorder the two entries and the version stamp silently lands on the pinned stable channel, whose version would then disagree with the tag it points at. CC validates that agreement at load, so it would surface as a broken install for stable users, not a red CI job.

tests/schemas/test-alpha-channel.sh          8 assertions

  ork exists · ork-alpha exists
  ork is pinned, and not to "main" or "HEAD"
  ork's version agrees with its pin       (v{version} == ref)
  release-please stamps ork-alpha's index, never ork's
  both channels resolve the same repo and path
  ork-alpha tracks main