Prepare Claude plugin alpha.4 candidate

[raghubetina]

Summary

• align the portable Skill and interview guidance with the current bounded Compiler, including ordinary References and inverses, the admitted Validation subset, supported public Scaffold shapes, and index-only iPhone navigation
• prepare @firstdraft.com/claude-code@0.1.0-alpha.4 while deliberately leaving the public marketplace pinned to published alpha.3
• reconcile the exact bundled @firstdraft.com/cli@0.1.0-alpha.2 registry package by inventory, content, and modes, and require npm trusted publishing for the plugin release

Release boundary

This prepares an unpromoted candidate only. Merging it does not publish a package, create a release tag, promote the public catalog, or deploy First Draft.

The candidate tarball SHA-256 is:

d662b86f33dd75c7a22e89e092c51497b0df9e14958a369d7ac96b85088ac3bd

Verification

• Node 24.18.0 / npm 11.16.0: clean install, audit with 0 vulnerabilities, 53 checks passed
• Node 22.0.0 / npm 10.5.1: clean install, audit with 0 vulnerabilities, 53 checks passed
• exact CLI registry reconciliation: 19 files matched in both lanes
• exact-CLI plugin package reproduction: deterministic and compatible in both lanes
• Skill and assembled Claude plugin validation passed
• git diff --check

[raghubetina]

Post-merge retrospective. The alpha.4 candidate's real work was truthfulness maintenance: realigning the
portable Skill and interview guidance with what the bounded Compiler had just learned (ordinary References
and inverses, the admitted Validation subset, supported public Scaffold shapes, index-only iPhone
navigation), while deliberately leaving the public marketplace pinned to the older release. The teaching
surface tracking the capability matrix is the discipline #34 later made structural. Leaving the catalog
unpinned would have been the easy bundling; keeping candidate preparation separate from public selection was
already the package-first instinct before #25 wrote it down. Nothing to flag retrospectively.

[raghubetina]

A short lesson about a maintenance burden generators create: the teaching surface.

The Skill tells an agent what First Draft can build. The Compiler defines what First Draft can actually
build. Every time the Compiler learns something (inverse associations, a new validation shape), the Skill's
prose is now understating reality, and an agent following it will author Plans below the product's ability.
Let the drift run the other direction (Skill promises what the Compiler cannot do) and agents author Plans
that fail compilation. Either direction, the cost lands on users.

So "align the Skill with the current bounded Compiler" is not a docs chore; it is the release. This PR
updates the guidance in the same candidate that will ship near the capability change, and the repo
eventually grew a capability matrix plus regression checks so the alignment is tested rather than
remembered.

The second, quieter decision: prepare the candidate, but leave the public marketplace pinned. Preparation
and selection are different events with different reversibility, and keeping them separate means a candidate
can be abandoned at zero public cost. If you maintain any AI-facing instructions (a Skill, a CLAUDE.md, a
system prompt), treat them as versioned artifacts that ship with capability changes, not as a wiki someone
updates eventually.