软件更新日志标准
面向任意软件项目（桌面 / 网页 / 移动端）的更新日志写作与发版一致性标准。
核心原则：更新日志是软件交付物的一部分，不是开发记录，不是文档。
使用边界
本 Skill 只负责"对外软件更新日志"这一件事：
- 日志条目的内容、结构、语气和条数；
- 版本号规则与三处同步；
- 安装包命名；
- 日志的单一数据源与渲染位置；
- 发版前"日志确实进了产物"的校验清单。
不属于本 Skill：
- 内部发布事实、状态门、跨阶段交付编排 → 用
internal-saas-delivery/safe-saas-release； - 交付周期收尾、内部事实与公开说明的映射、交接 → 用
saas-cycle-closeout； - 事故复盘、会议纪要、普通文档润色 → 不触发本 Skill。
与收尾类 Skill 同时适用时：本 Skill 负责日志文本本身与发版一致性，收尾类 Skill 负责状态门与交接，
不要把同一份事实复制成两个权威版本。
铁律：先写日志，再发版
更新日志不是"发版后补的记录"，而是发版流程的第一步：
改代码 → 写更新日志 → 同步版本号 → 完整构建 → 校验日志进了产物 → 从新版本目录发布
日志没进安装包 = 没有完成交付。
真实事故：某版本源码里日志已写好，但忘记重新构建，用户拿到的软件里还是旧日志。
自那以后，"解包校验新日志文本真的在产物里"成为发版必做步骤，而不是可选项。
详见 references/incident-lessons.md。
工作流程
- 建立本次版本的真实变更事实。
按 references/collecting-change-facts.md 从版本控制历史、任务/缺陷清单、
构建配置和上一版条目收集证据。把"用户口头说法"和"可复核证据"分开。
无法判断某条改动是否用户可见时，问用户，不要猜。 - 定版本号。
按 references/versioning-and-packaging.md 判断该跳哪一位。
版本号一旦发给用户就永不复用，严格递增。 - 写条目。
四要素齐全，要点按 references/writing-rules.md 的七条规则写，
从 assets/changelog-entry-template.md 起步，
参照 assets/changelog-entry-example.md 的成稿。 - 放进单一数据源。
新条目加在最顶部，旧条目一个不删。见 references/storage-and-rendering.md。 - 同步版本号三处。
程序内部（如package.json）、软件"关于/设置"页显示、安装包文件名。 - 完整构建。
编译 + 打包全链，不是只跑打包。 - 解包校验日志真的进了产物。
在构建产物或安装包里搜索本版主题或某条要点的原文，搜到才算过。源码里有日志不等于产物里有。 - 从新版本目录启动并实际运行验证。
打开软件内的"更新日志"页面，确认看到的就是本次的版本号和文案。 - 按 references/preflight-checklist.md 逐条核对后再交付。
可选的结构与措辞自检（需要 Node.js，无第三方依赖）：
node scripts/lint_changelog_entry.mjs <entry.md 或 changelog 文件>
脚本只做启发式提示，给出条目行号、要点序号、命中的词和原因；它不保证内容正确，
也不能代替"解包校验产物"这一步。人工复核仍然必需。
退出码：0 无告警，1 有需要复核的问题或没识别到条目，2 用法/读取错误。
它认得三种条目头，写草稿时用其中任一种都能被检查：
4.8.3 ｜ 2026-09-12 ｜ 主题
版本号：4.8.3 （配合 日期：/ 主题：/ 要点： 字段）
## 4.8.3 — 2026-09-12 — 主题
要点用 ·、-、* 或 1. 开头都行；续行缩进即可。
一个文件里有多条时，脚本会一并检查版本是否重复、是否最新在前。
快速对照
| 要素 | 要求 |
|---|---|
| 版本号 | 与程序实际版本号严格一致（如 4.8.3） |
| 日期 | 真实发布日期，YYYY-MM-DD |
| 主题 | 一句话说清这版最核心的变化，≤20 字 |
| 要点 | 3~7 条，每条只讲一件事，按"新功能 → 问题修复 → 体验优化 → 其他说明"排列 |
要点句式：【用户能感知的变化】+【解决了他什么问题】
输出要求
交付时给出：
- 本版版本号、日期、主题、要点全文；
- 版本号三处同步的实际位置与读到的值；
- 是否已执行完整构建、是否已解包校验、是否已实机运行——做了什么就说什么；
- 未确认、未执行和已知边界。
不要声称执行过未执行的构建、解包或实机验证。没有证据时如实标为未执行，
不要写"应该没问题"。
