发布改由 main 上的版本号变化触发，而不是打 tag

[forrestlinfeng]

改了什么

.github/workflows/publish.yml 的触发条件从 push: tags: ['v*'] 改成 push: branches: [main]。每次推到 main 时比对 package.json 的版本是否已在 npm 上——不在就发布，在就跳过。README 的两处说明同步更新。

为什么

• tag 可以被移动，而这个 job 持有 npm token。 原来的触发方式把发布权绑在一个可变的引用上。
• 发布意图现在就是"改版本号"这一件事，不需要再记得补一个匹配的 tag。这个包至今没有发布过（npm 上 404、仓库零 tag），原因之一就是那个 tag 从来没人打。

具体做法

项	说明
token 隔离	收进 npm-publish environment，与本仓库其他 workflow 隔离
token 落盘	写进 mktemp 出来的临时 userconfig（chmod 600 + trap 清理），不污染全局 npmrc
provenance	关闭。npm 拒绝来自私有源仓库的 provenance，开着会直接失败
发布后校验	带重试地回查 npm view，确认包真的能从 registry 解析，而不是只看 publish 的退出码
并发	group: npm-publish 且 cancel-in-progress: false，两次连续推送不会让第二次把第一次的发布腰斩
手动运行	workflow_dispatch 仍然跑完除发布外的所有步骤，可以从任意分支彩排

Reviewer 需要知道的

这条 PR 合入后，行为是"main 上出现一个 npm 上没有的版本号就自动发布到公共 npm"。 这是不可撤回的对外动作，而且门槛从"有人刻意打 tag"降到了"有人改了 package.json 的 version 字段"。如果希望保留一道人工闸门，可以给 npm-publish environment 配上 required reviewers——workflow 本身不需要再改。

需要在仓库里配置好 npm-publish environment 及其 NPM_TOKEN secret，否则发布步骤会在 ${NPM_TOKEN:?...} 处明确报错退出，而不是静默跳过。

当前 package.json 是 0.1.0，npm 上不存在，所以合入即会触发首次发布。

验证

npm test 90 passed / 0 failed。workflow YAML 解析通过，触发条件与 job 结构如上。发布路径本身没法在 PR 里演练——需要 environment 和 token 就位后，用 workflow_dispatch 跑一次彩排（它会执行除 publish 外的每一步）。

说明

这两个文件的改动是在本次会话的工作区里发现的未提交内容，不是我写的；我按 /create-pr 的要求把它们提交成了独立分支并开了这条 PR。本次会话我自己的插件改动走的是另一条线，已作为 #26 合入。

🤖 Generated with Claude Code