Lime 发版流程

核心原则

• 先读 AGENTS.md、internal/aiprompts/quality-workflow.md 和当前 git status --short，再修改版本或发版文件。
• 发版属于高风险流程。删除文件、git commit、git tag、git push、覆盖已有 tag、终止用户进程前，必须按仓库危险操作格式向用户确认。
• 如果工作区已有未提交改动，先把 release candidate 范围判清楚；版本号和 release notes 只是发布 metadata，不能默认代表本次发布全部内容。
• 只有用户明确要求“只更新版本 / 只写 release note / 不提交其它改动”时，才允许只修改和提交发版事实源；否则发版提交必须纳入本次 release candidate 的全部产品 / 文档 / 测试改动，或先停止并让用户确认排除清单。
• 版本号事实源以 package.json、forge.config.mjs、App Server manifest 与 lime-rs/Cargo.toml 的 workspace version 为准，完成后必须跑 npm run verify:app-version。
• Electron 发布 / 签名 / 公证 / updater metadata 的 current 打包事实源是 forge.config.mjs、electron-forge package、electron-forge make 与 Forge 官方 maker；旧 builder 配置 / CLI、自定义 Windows installer maker 与旧 YAML / blockmap updater metadata 按 dead 处理，不得写回 release workflow、docs、quality guard 或 i18n evidence。运行时更新以 electron/updateHost.ts + Electron 内置 autoUpdater 为 current；Windows installer 必须走 Forge Squirrel。
• 发版前默认必须跑通 npm run typecheck。这是发布硬门禁，必须在收尾和任何 commit / tag / push 确认前明确执行并记录结果；不能用 npm run typecheck:electron、npm run lint、局部单测、Rust 测试或 verify:app-version 替代。若用户明确要求“马上递交”或“立即递交”，可以把 typecheck 降级为非阻断项，直接进入发布收口，但最终汇报必须明确注明 typecheck 未执行或未通过。
• 默认发版门禁不要再自动执行裸 npm run lint、裸 npm test 或全量 cargo test --manifest-path "lime-rs/Cargo.toml"。这些命令在当前仓库经常耗时长、续跑差或被大写集噪音阻断；只有用户明确要求“完整矩阵 / 全量门禁 / CI 同款验证”，或当前改动风险确实需要时才执行，并优先使用下方的定向 / 续跑入口。
• Lime 是 GUI 桌面产品；即使静态检查和单测通过，涉及发布也要尽量跑 npm run verify:gui-smoke，跑不了要说明环境限制。
• 用户要求“发版 / 发布 / release”时，默认目标不是只准备版本文件，而是完成一次端到端发布：整理 release candidate、更新版本与 release notes、跑门禁、创建 release commit、创建 tag、推送 main 和 tag。git commit / git tag / git push 仍必须按危险操作格式请求一次明确确认；拿到确认后必须继续执行到底，并做 tag / 远端状态复核，不能把“是否提交 / 是否打 tag / 是否推送”留给用户自己处理。

入口判断