REA 更新日志更新
用于发布说明准备和贡献者归属。请阅读仓库根目录下的 docs/releasing.md 以了解发布权限和现有的检查点检查。此技能用于准备说明；它不授权合并、打标签或发布。
撰写前的清单
获取完整的提交历史和标签。从发布 PR 的 基础分支 上的 .release-please-manifest.json 中选择已发布的基线标签，并将该分支的精确 SHA 固定为编辑目标。REA 标签格式为 rea-agents-VERSION。使用提议的版本，包括其预发布后缀；不要更改 always-bump-minor 策略来模仿 OpenClaw 的日历版本。
node scripts/release-notes.mjs inventory \
--repository morluto/rea --base rea-agents-PREVIOUS \
--target FULL_BASE_BRANCH_SHA --version VERSION \
--manifest /tmp/rea-VERSION.contributions.json
node scripts/release-notes.mjs record \
--manifest /tmp/rea-VERSION.contributions.json \
--summary \
--output /tmp/rea-VERSION.record.md
请阅读清单，而不仅仅是现有的机器人草稿。它包含侧分支提交、与范围内的合并提交关联的 GitHub PR、提交者/协作者，以及已确认的关闭议题及其报告者。GitHub 连接是分页的。网络错误会停止生成；恢复后重新运行到一个新的输出文件中。现有输出文件永远不会被覆盖。
未解决的提交身份将保留为带有 user: null 的名称/邮箱；切勿猜测句柄或感谢合并者作为替代。报告保留未知身份。这是一个经过审查的元数据快照，不是人类编写补丁的独立证明。对于未归因的身份、不寻常的合并策略、回迁、还原或 GitHub 未关联的引用，请检查源 PR 和差异，并报告限制。当前收集器使用已确认的 PR-议题关闭关系来给议题报告者授予信用；未关联的议题提及不会自动获得信用。不要声称仅仅被盘点的工作在还原后仍会发布。
面向用户撰写并保留信用
仅重写 CHANGELOG.md 中最新的 ## [VERSION] 部分，保留其版本/日期/链接标题。使用单行 Markdown 列表项，放在以下标题下：
### Highlights：一些决定发布价值的用户成果；小型发布没有配额。### Changes：功能和有意义的行为变更。### Fixes：可靠性、正确性、兼容性和安全性的修复。### ⚠ BREAKING CHANGES：适用时保留，并附上现有检查点验证器要求的迁移指南和原始 PR/提交引用。
按分析人员工作流或用户影响对相关工作进行分析。用简短、具体的条目解释最终产生的行为。Highlights 总结发布内容；避免在 Changes 中重复其完整描述。内部清理、测试、CI 和常规文档通常仅属于溯源文件。在做出断言前阅读不明确的 PR/差异。区分模拟提供者检查与实际提供者验证。
在公开说明中为每个代表的贡献给予一次信用，附带其链接和 Thanks @...，对象包括其已验证的人类作者、已知协作者和已确认的关闭议题报告者。汇总可以将所有这些信用保留在一行中。当 Highlights、详细条目或迁移文档引用相同的工作时，将致谢放在其中一条中，而不是全部。包含议题链接。直接提交的条目携带提交链接和已知的人类信用。
排除 GitHub 机器人和已知的代理账户。REA 观察到的 Anthropic、Cursor 和 Codex 协作者尾部解析为 @claude、@cursoragent 和 @codex，GitHub 类型为 User；信用政策排除它们，同时保留其元数据。
根据 REA 维护者的要求，省略 @morluto 的自我致谢，同时在清单中保留其作者身份。其他人类贡献者仍然有资格。
使用明确的 GitHub 链接进行跨仓库引用，以避免歧义的 #NNN 号码。未知的句柄保持未知；它们不是虚构的信用。
在此发布的末尾，逐字附加生成的 record --summary 溯源链接。链接的清单包含所有发现的范围内 PR 和直接贡献，包括从散文中省略的内部工作。不要将完整的 record 输出粘贴到公开说明中：它会重复致谢并掩盖面向用户的变更。完整的记录仍可供审查。不要手动编辑生成的信用以使验证通过。当产品历史发生变更时，刷新清单；仅修正文本时可以重用快照。
使用 Release Please 最终确定
在修改实时发布 PR 之前，务必获得对该 PR 更新的授权。本地准备和验证可以独立进行。
-
在选定的开放发布 PR 上添加
rea:release-notes-finalized标签，然后 再编辑其分支/主体。主要提议推送会尊重此标签。这是我们工作流的保护机制，不是 Release Please 的autorelease: snooze机制。正在运行的提议必须在编辑前完成。不要在最终确定的说明上触发手动准备。 -
在该发布分支上，将审查过的清单保存为
docs/releases/VERSION.contributions.json。这是持久的公开发布溯源文件，不是临时规划文件。不要添加凭据或本地环境转储。使现有版本产物保持一致。 -
运行现有的检查点验证器和新的检查器：
node scripts/release-notes.mjs check \ --manifest docs/releases/VERSION.contributions.json node scripts/release-notes.mjs render \ --manifest docs/releases/VERSION.contributions.json \ --output /tmp/rea-VERSION.notes.md检查器支持内联 PR 主体，包括其周围的元数据，最长可达 GitHub 的 65,536 字符限制。如果说明超出此限制，检查器会失败，而不是截断信用；Release Please 的溢出链接主体尚未集成。
-
用渲染后的部分更新发布 PR 主体，同时保留其 Release Please 的头部/尾部和组件/版本结构。使用主体文件进行
gh pr edit --body-file；仅更改CHANGELOG.md不会更改 Release Please 的发布主体。仅推送授权更改。 -
重新获取 PR 主体到文件并运行
check --pr-body FILE。审查完整的差异并等待当前的 CI。发布创建前会再次检查主体。避免在发布过程中进一步编辑主体。
最终确定标签会冻结机器人刷新，但不会冻结主分支。清单目标之后的新产品更改需要在发布前刷新说明。工作流会检查目标的祖先关系，并只允许在该目标之后进行发布元数据路径的更改。它还需要清单目标等于被审查的合并提交的第一个父提交，因此中间的主分支提交需要新的清单。同时审查允许的发布元数据路径内的差异：路径保护并不能证明包依赖/脚本编辑只是版本变更。 要继续自动提议，请移除最终确定标签并让机器人重新生成；期望编辑更改将被替换。 没有贡献清单的现有发布保留其当前的发布路径。切勿重新标记或重新发布包以纠正发布文本。