更新技术栈规格 是做什么的？
您更新事实（版本、日期、度量、来源）。决策部分您向作者提出并等待批准。如果给出了参数，则仅检查指定的工具；否则检查全部。
1. 清点
从 stack-spec.md 中列出：
- §2 中每个行及其版本行；
- §3 和 §4 中每个版本、发布日期或稳定性声明（"stable"、"release candidate"、"alpha"、"experimental"、工具旁的版本号）；
- Revisit when 中每行作为待测试条件；
- 头部中的版本日期。
2. 对照主要来源逐一检查
来源：注册表、发布说明、官方文档。绝不依赖记忆。
- npm：
npm view <pkg> dist-tags time --json。当前版本 = 至少 14 天前发布的最新版本；将更年轻的版本列为即将发布。 - nixpkgs 工具（Node.js、Biome、nixfmt、Wrangler、Playwright 浏览器）：在
nixos-unstable上运行nix eval --raw nixpkgs#<pkg>.version，并查看项目的发布页面。 - 平台特性（Cloudflare、浏览器支持）：官方文档页面及其日期。
每个工具记录：规格中的版本行、当前版本、以及是否存在重大发布（或规格等待的发布）介于两者之间。
3. 分类每个变更
完整阅读每个重大版本的变更日志或迁移指南，以及规格依赖的文档。然后分类：
- 事实（版本行、日期、包数量）：更新它。
- 理由（声明的缺陷被修复，或新的缺陷被引入）：更新理由文本；在报告中列出。
- 决策（选择本身、现在更好的替代方案、触发的 Revisit when 条件）：不编辑。报告：什么发生了变化、来源、包含成本的选项、建议。等待。
4. 编辑
- 保持规格的风格：简洁、规则在前、理由在后、使用 ISO 日期；将已更改的决策文本标记为 "Amended : …"。
- 新事实 → 在编号列表末尾添加新来源，格式为 "checked "。绝不重新编号来源；只有当没有任何内容引用它时才删除来源。
- 绝不重新编号章节。新主题变成其所在章节的下一个子章节；询问作者该站点是否已使用该编号，并报告所选择的编号。
- 更新头部中的版本日期。
- 不得提及使用该规格的站点、用户或仓库。
5. 验证和提交
- 每个新 URL 或更改后的 URL 可解析：
curl -sIL <url>。 - 不得提及使用该规格的站点、用户或仓库。
- 使用 Jujutsu，每次提交签名，按主题提交（例如 "Record Astro 8"、"Propose TypeScript 7"），提交消息说明变更内容、原因以及检查过的来源。除非被要求，否则不推送。
6. 报告
每个工具：规格版本 → 当前版本。然后：已更新的事实、已更改的理由、附有建议的待决策提案、以及尚未满 14 天的即将发布版本。