archlang: Command for Claude Code

Release check

Walk this checklist before pushing a v* tag. Report each item as pass/fail with the evidence you observed. Do NOT push anything — this command only verifies.

Checklist

1. Establish the TRUE latest release first. Never take the current version from a doc, a plan or the prompt. Probe:

   npm view @chanmeng666/archlang version
   git tag --sort=-v:refname | head
   gh release list --limit 3
   grep -m3 '^## ' CHANGELOG.md
   

   The target must be strictly greater than all of them (an npm version is immutable), and its semver class must match what changed — read git log <lasttag>..main and git diff --stat <lasttag>..main. New grammar/keyword, E_*/W_* code or public field ⇒ MINOR at least. Diff that log against [Unreleased] so no merged change is missing from the notes.

2. Versions consistent.

   • Root package.json version matches the newest CHANGELOG.md heading.
   • Ask whether the shim changed: git diff <lasttag>..main -- packages/mcp. ANY mcp-visible change (including a tool description, its README, a server.json field) needs a bump in packages/mcp/package.json AND both version fields of packages/mcp/server.json — release.yml skips a version already on npm.
   • The shim's baked resources (spec.llm.md, llms-full.txt, the GBNF, both schemas) are copied at pack time and refresh ONLY with a version bump — a legitimate reason to bump with an empty diff. Its core dep range is pinned as the string ^ + the root version, so every core release reddens packages/mcp/test/lockstep.test.ts on purpose: re-pin, rebuild, bump. Never relax it.
   • Publish order is core → shim. The shim's link tool loads @chanmeng666/archlang/link, so the shim must not publish while npm's latest core lacks ./link (npm view @chanmeng666/archlang exports). release.yml enforces it: packages/mcp/scripts/check-core-exports.ts fails the shim publish when npm's copy of the range's minimum lacks a subpath the server loads.
   • Claude Code plugin manifest (plugins/archlang/.claude-plugin/plugin.json): its version is the core's and its npx pin is the shim's exact version. After the version bumps run npm run gen:plugin and commit the manifest; check:drift fails on a stale one. The release PR pins a shim version that is not on npm until the tag's release.yml publishes it, so a plugin installed from main can fail to launch its server for those few minutes; accepted. Confirm npm view @chanmeng666/archlang-mcp version equals the pin once the tag run finishes.
   • Same range pin for editors/vscode (editors/vscode/test/lockstep.test.ts).
   • The served <arch-plan> (docs-site/public/arch-plan.js) names the core version in its jsDelivr URL: after the version bump run npm run gen:arch-plan (or npm run gen:all) and commit it with the plugin manifest; check:drift fails on a stale one.
   • packages/web-component's peer range on the core is a caret range (packages/web-component/test/peer-range.test.ts). A core MAJOR (2.0) fails that test on purpose: check that compile, diagnosticToJson and THEMES still exist with the same shapes, then move the range.
   • packages/font-cjk: release.yml publishes it before the core and refuses a version/pin mismatch with the core's exact optionalDependencies pin.