re0-release

在待处理的更改上运行此仓库的发布检查清单，确认无误后再打标签并发布。

目标

将“准备并发布版本”变成一个明确的命令，而不是每次都手动重新整理发布检查清单。安装了 sip 时运行它，直接落实精简提交原则，并且绝不自动触发另一个由用户调用的技能。将“提交”和“打标签并推送”视为两个各自独立、需要分别确认的时刻：提交会保留在本地，且可撤销；打标签并推送则是唯一会将内容公开的步骤。

工作流

1. 根据待处理的 diff 确认是否已具备发布条件——检查 AGENTS.md「Shipping checklist」中的所有适用项，但不包括版本号递增和运行 sip，这两项分别是此处的第 2 步和第 3 步：
   • 任何新增或修改的 SKILL.md 都符合要求（frontmatter 包含 name+description；仅在由用户调用时设置 disable-model-invocation；正文包含 Goal/Workflow/Rules/Verification 各节）；
   • README 和 docs/readme/ 下的每个本地化副本都准确列出该技能，调用方式列正确，且顺序符合技能列表的逻辑顺序——plugin.json、scripts/catalog.cjs 和 re0-upgrade 的 catalog 中顺序一致，并与 reorder 保持同步；只有当该技能承载核心论点时，README 的 Problem 移除列表和 Fixes 说明才会将其纳入（大多数技能两者都不涉及——这两处内容都经过筛选）；
   • plugin.json 注册了该技能的路径；
   • 如有重命名，按发布顺序在 re0-upgrade 的弃用检查清单中追加一行 old -> new；
   • 跨技能共享规则（edit-safety、negatives-as-corpus、commit-economy）在所有包含这些规则的副本中保持一致。 报告任何缺漏并停止，不要擅自猜测后续内容。
2. 判定版本号递增类型：新增技能属于 minor；修复或仅修改文档属于 patch；移除技能且没有替代路径属于 major。对于现有技能的增强——这一边界情况——应按类型而非规模判定：相对于该技能先前的规范，旧行为是错误的（修复 → patch；仅用于修复的新流程仍属于 patch），还是正确但范围更窄／缺少一个维度（用户因此获得可使用的新能力 → minor）？说明判定依据，而不只是版本号递增类型。
3. 如果已安装 sip，就运行它并处理其检查结果。如果未安装，则按顺序直接运行其检查——冷读（shower）、仅在存在声明或 eval 时进行真伪检查（factchk/mandela）、一致性（先用 ssotize 审查，只有获批后才整合），然后整理（re0）——并处理检查结果。
4. 将 package.json 的版本号递增至第 2 步判定的版本。
5. 按 commit-economy 起草提交说明——每项真实且持久的变更对应一个项目符号，相关支持性编辑合并其中；不写 diff 或版本号已能证明的内容，不加共同作者标记；格式应符合本地日志惯例；若无惯例，则用一个主题行和每项变更一个 - 项目符号，且每行不换行——从第一稿起就写成定稿，不要在后续编辑中不断追加。如果提交已存在且需要清理，请要求人工运行 re0-git；不要自动调用它。
6. 请求明确确认，然后提交。
7. 编写 .re0/release/RELEASE_NOTES.local.md——这是一个被 git 忽略、永不随发布交付的本地草稿文件，其内容会作为签名标签的说明——遵循以下风格：一个 ## 标题，概括此版本持久的理念，而不是版本号；一段简短的现在时说明，描述当前的事实；只包含此次发布应有的章节（### New、### Also、仅在需要重新映射技能列表时使用的 ### The catalog (N skills)；### Install 始终放在最后，并使用缩进块）；每项外部贡献都在行内注明其 PR 编号和作者 handle（(#123, @handle)）；技能名称和路径使用反引号；不写标签或版本号已能证明的内容。
8. 在打标签和推送之前，另行请求第二次明确确认——这是唯一会将内容公开的步骤。然后执行：git tag -s vX.Y.Z -F .re0/release/RELEASE_NOTES.local.md --cleanup=verbatim，确认 git tag -v vX.Y.Z 报告签名有效，推送 main，再推送标签。
9. 持续观察触发的发布工作流直至完成；报告成功或实际失败，绝不要假定发布已完成。如果失败，修复原因并重新运行。若作者创建的标签有误（说明、签名或目标不正确），应删除并以相同版本号重新创建，而不是递增版本；只有已发布的制品有误时才递增版本。绝不要手动代替工作流完成其工作。
10. 确认发布成功后，逐一处理本次发布中包含的外部贡献：关闭 PR 前，由审核者批准该 PR——若某项贡献经过 squash 或重建后纳入发布，则应关闭而不是合并，因此批准记录的是接受而非拒绝——关闭评论中还应注明发布说明中给出的贡献致谢。任何拥有审核权限的协作者或维护者都可以执行此操作；不必由某一位特定审核者负责。
11. 然后归档已发布的迭代：将其 .re0/iteration/<version>-<workname>/ 文件夹原样移至 .re0/iteration/completed/<version>-<workname>/。.re0/ 被 git 忽略且从不纳入版本控制，因此使用普通文件系统移动命令（mv），不要使用 git mv——后者在未跟踪路径上会直接失败。只有当该迭代从未使用 re0-plan 规划，且没有匹配的迭代文件夹时，才跳过此步骤。

规则

• 切勿臆造或猜测 CLI 命令或标志；在将其写入要执行的步骤之前，先通过官方文档或实际运行进行核实。
• 推送就是整个手动步骤。 切勿手动执行由发布工作流负责的步骤——发布、为发布页面命名标题——尤其不能为了挽救失败的运行而这么做；重新切出作者自己有缺陷的标签（步骤 9）是唯一例外，而且要再次推送，这样工作流仍会完成其余工作。手动执行某个步骤会漏掉工作流在构件之外添加的内容（签名的来源证明、标题约定、dist-tag），但看起来仍像一次成功发布，因此不会触发任何失败，只有与上一个版本进行比较时才会发现问题。
• 如果待处理的差异混杂了无关事项，先说明这一点并提议拆分，再起草消息——不要让一条提交消息承担起差异本身的职责。
• 本地版本匹配条件成立之前，切勿推送（package.json 必须与即将创建的标签一致）；CI 检查是最后一道防线，而非第一道防线。
• negatives-as-corpus — 退役时要移动迭代文件夹，绝不删除。如果发布失败或被回滚，应让文件夹保持原样，不要将实际上未发布的周期退役。

验证

完成前：

1. package.json 中的版本与标签一致。
2. 即使不看差异，提交消息本身也能清楚地说明交接内容。
3. 发布说明遵循项目惯例，且只提及本次发布实际包含的内容。
4. 已确认推送的标签所触发的工作流运行成功完成，而非仅凭推测。
5. 没有手动执行任何由工作流负责的步骤，包括为挽救失败的运行而执行。
6. 本次发布纳入的每项外部贡献，其 PR 在关闭前都已获批准，并附有致谢评论。
7. 已发布周期的迭代文件夹已移至 .re0/iteration/completed/ 目录完成退役；若原本不存在迭代文件夹，则正确跳过此项。
8. 报告任何跳过的步骤或尚未解决的问题。