用途：在独立仓库 clickupfy/ 中引导可复现的 ClickUpfy 发布流程，不手动创建 tag 或修改版本号。Release Please 是版本、changelog、tag 和 GitHub Release 的唯一来源，GitHub Actions 在 release 创建后编译并发布制品。
开始前：阅读 RELEASING.md，检查 git status --short，保留不属于本次发布的本地改动；依赖未安装时执行 npm ci。除明确授权的恢复操作外，不要直接创建 tag 或编辑版本。
准备改动：使用 Conventional Commits，fix: 建议 patch，feat: 建议 minor，feat!: 或 BREAKING CHANGE: 建议 major，docs:、build:、ci:、refactor: 进入 changelog 但不强行提升版本。推送前运行 npm run validar，校验类型、测试、构建、版本、manifest、changelog 与 workflow 是否存在。
发布：把 Conventional Commits 推送到 main，等待 Release workflow 创建或更新 Release PR，在 PR 中复核版本与 CHANGELOG.md，合并后跟踪同一 workflow 执行，产出不可变 tag vMAJOR.MINOR.PATCH、GitHub Release、Linux x64/macOS x64/macOS arm64/Windows x64 可执行文件、npm registry 上的 @promovaweb/clickupfy、同名 .tgz、SHA256SUMS，公开仓库时还有 provenance attestations。正常流程不要运行 git tag 或 gh release create。
本地校验：npm run release:check，或 npm run release:check -- v0.1.0（只使用与当前版本对应的 tag）；用 npm run build:executable 生成本平台可执行文件并测试，如 ./artifacts/clickupfy-v0.1.0-linux-x64/clickupfy --version，按脚本实际输出的版本、平台、架构调整名称。
故障诊断：缺 Release PR 时检查 workflow 触发条件、Actions 权限以及 bootstrap-sha 或最后 tag 之后是否有 Conventional Commits；CI 未在 Release PR 上运行时可配置可选 secret RELEASE_PLEASE_TOKEN；release 无二进制时重跑同一执行中的失败 job；npm 发布失败时确认 NPM_TOKEN 并重跑，脚本会忽略已存在的版本；制品无效时在受影响平台用 npm ci、npm run validar、npm run build:executable 复现；版本不一致时不要只改一个文件，检查 package.json、package-lock.json、.release-please-manifest.json、CHANGELOG.md 与 tag。
恢复：不要移动或复用已发布的 tag。代码错误时提交修复性 Conventional Commit 并发布新的 patch release；文件缺失或 job 中断时在被打 tag 的提交上重跑 workflow，上传对同一 release 的文件名做幂等替换。仅当自动化无法恢复且有明确授权时才使用 GitHub CLI 手动操作，并在 handoff 中记录原因、tag、被替换文件与执行过的校验。