Promote plugin catalog to 0.1.0

[raghubetina]

Summary

• point the public marketplace catalog at the immutable @firstdraft.com/claude-code@0.1.0 package
• bind package publication, provenance, direct-package validation, and the user-selected PAT-less staging discovery smoke
• preserve the unproved full-v14 boundaries and require the public install plus Drawing Board Codespace journey after promotion

Local verification

• Node 24.18.0 / npm 11.16.0
• npm ci --ignore-scripts
• npm run check — 62/62 tests
• exact CLI/package reproduction against d37d8b6775a0b97ce10bd651485bd308fed1dda2
• networked check-plugin-release-order --prospective — coherent consumed catalog identity
• git diff --check

Merge gate

The exact promotion head's hosted Node 24.18.0 job, including the release-order rehearsal, must pass. Do not bypass it administratively.

After merge

Run a fresh isolated public marketplace install, pin the resulting exact Skills main SHA in Drawing Board PR #3, require its real devcontainer CI to pass, then perform the fresh template → Codespace → claude → plain-English request → private repository journey.

[raghubetina]

Post-merge retrospective. The 0.1.0 catalog promotion followed the package-first order that #25 had just
corrected into policy: immutable package published and validated first, catalog pointer second, with
publication provenance and the direct-package check bound into the record. Two details age well: the
user-selected PAT-less staging discovery smoke kept a human-chosen, least-privilege proof in the loop, and
the promotion explicitly required the fresh public-install and Codespace journey afterward rather than
claiming them, which is the gap the later 0.1.1 record (#32) then closed for its own version. Boundaries
(full v14) stayed honestly unproved. Superseded operationally by the 0.1.1 promotion; the ordering discipline
is the durable part.

[raghubetina]

A short sequencing lesson from the first stable catalog promotion.

The promotion merged only after the package it points to already existed immutably on npm and had passed an
isolated direct-package check. Promote-then-publish would create a window where the public catalog names a
version nobody can install, and every installer in that window gets a confusing failure. The rule
generalizes: a pointer may only ever be advanced onto something that already verifiably exists. DNS cutovers,
feature flags, catalog files, latest tags, all the same shape.

The second habit here: the promotion record lists what it does not prove, and schedules it. Promoting the
catalog does not demonstrate that a stranger's fresh install works; that requires its own observation, which
was named as required follow-up at promotion time and later performed and recorded. Writing the missing proof
into the promotion itself is what keeps "we shipped it" and "we know it works" from quietly merging into one
claim.