@fxri/toolkit 1.12.1 → 1.12.3

package/CHANGELOG.md

@@ -1,5 +1,21 @@
 # 方弦工具集
 
+## 1.12.3
+
+> 2026-10-18 发布
+
+### 📝 文档更新
+
+- 明确 T5 规范词适用范围覆盖 history 留痕行
+
+## 1.12.2
+
+> 2026-10-16 发布
+
+### 📝 文档更新
+
+- 修正历史日志块的条目前缀残留与错挂归组——1.9.2 块一处子项剥离遗留的 `修复：` 前缀，1.9.0 块两处独立修复由父项缩进子项拆为顶层条目
+
 ## 1.12.1
 
 > 2026-10-16 发布
@@ -457,7 +473,7 @@
   - 历史版本块保留当时口径，`changelog format` 不追溯改写；前缀识别与输出语言解耦（全局前缀表全语言共用），变更集条目语言与输出语言不一致时仍正确归组
   - 自定义语言新增可选 `groups`（`[{ slot, title, prefixes? }]`）声明本语言标题与自有前缀；未声明时退化为纯替换，既有配置无需改动
   - ⚠️ 对外契约变化：`--lang en` 的组标题文本变化（如 `### ✨ Minor Changes` → `### ✨ Added`）；`--warn` / `FX_CHECK_WARN` / `check.warnings` 适用范围由任务校验告警扩为「任务校验告警 + 变更集条目缺类型前缀告警」，同一开关一并开关闭；新增公共导出 `SLOT_PREFIXES` / `SemanticSlot`
-  - 修复：发布日期行识别由硬编码「发布/released」改为「当前语言 `released` ∪ 全部内置语言 `released`」后缀集合——自定义语言（日文等）按自身 `released` 识别，内置 zh / en 互跑（如中文日志用 `--lang en` 输出）也不再重复追加日期行
+  - 发布日期行识别由硬编码「发布/released」改为「当前语言 `released` ∪ 全部内置语言 `released`」后缀集合——自定义语言（日文等）按自身 `released` 识别，内置 zh / en 互跑（如中文日志用 `--lang en` 输出）也不再重复追加日期行
 - 技能版本可视化，旧会话可自校验技能内容是否过期
 
   - `toolkit skills status` 常驻打印包内各技能真源版本，`--format json` 新增 `skillVersions` 字段与逐项 `version`，作为磁盘基准值；`toolkit skills install` 报告同样逐项带版本
@@ -509,14 +525,14 @@
   - 自愈改为一次列目录取现场条目类型，不再逐条 `lstatSync`，稳态开销明显下降
   - `toolkit skills status` 末尾汇总按型给出指引：缺失 / 悬空 / 指向错误 / 副本漂移用 `install` 补齐，同名冲突用 `install --force` 覆盖
   - 收窄状态分类口径：同名实体目录只有登记为本包副本时才算「副本已漂移」（裸 `install` 即可刷新），未登记的属用户 / 上游产物，报「同名冲突」并需 `--force` 覆盖
-  - 修复自愈「重建失败」时状态记录被静默写掉的问题：失败条目保留在 `~/.agents/.toolkit-skills.json`，下次运行仍会重试
 
 ### 🐛 问题修复
 
+- 修复自愈「重建失败」时状态记录被静默写掉的问题：失败条目保留在 `~/.agents/.toolkit-skills.json`，下次运行仍会重试
 - 诊断提示污染机器可读输出：链接自愈提示与升级提示改走 stderr，stdout 保持纯 JSON
 
   - `toolkit tasks --format json` 等机器可读输出不再被追加提示文本，可安全 `JSON.parse` 与管道消费
-  - `updateCheck` 的缓存文件带 BOM 时不再误判为损坏而重复联网（与配置文件、技能状态文件同口径剥离 BOM）
+- `updateCheck` 的缓存文件带 BOM 时不再误判为损坏而重复联网（与配置文件、技能状态文件同口径剥离 BOM）
 
 ## 1.8.3
 

package/LICENSE

@@ -1,21 +1,21 @@
-MIT License
-
-Copyright © 2026 唐启云
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
+MIT License
+
+Copyright © 2026 唐启云
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/NOTICE

@@ -1,9 +1,9 @@
-@fxri/toolkit
-Copyright © 2026 唐启云. All rights reserved.
-
-出品方：方弦研究所（唐启云个人项目品牌，非独立法人实体）
-
-商标声明：
-"方弦®"为第42类注册商标（注册号89648411），核定服务项目：计算机出租、计算机软件设计、为他人研究和开发新产品、计算机软件维护、把有形的数据或文件转换成电子媒体、为他人创建和维护网站、网络服务器出租、提供互联网搜索引擎、托管计算机站（网站）、云计算。
-本开源许可（MIT License）不授予商标使用权。
-详见 TRADEMARK.md 了解完整商标信息。
+@fxri/toolkit
+Copyright © 2026 唐启云. All rights reserved.
+
+出品方：方弦研究所（唐启云个人项目品牌，非独立法人实体）
+
+商标声明：
+"方弦®"为第42类注册商标（注册号89648411），核定服务项目：计算机出租、计算机软件设计、为他人研究和开发新产品、计算机软件维护、把有形的数据或文件转换成电子媒体、为他人创建和维护网站、网络服务器出租、提供互联网搜索引擎、托管计算机站（网站）、云计算。
+本开源许可（MIT License）不授予商标使用权。
+详见 TRADEMARK.md 了解完整商标信息。

package/TRADEMARK.md

@@ -1,41 +1,41 @@
-# 商标声明
-
-## 基本信息
-
-| 项目 | 内容 |
-|---|---|
-| 商标名称 | 方弦® |
-| 商标类型 | 文字商标 |
-| 商标说明 | 商标由文字"方弦"组成 |
-| 商标类别 | 第42类（共10项） |
-| 注册号 | 89648411 |
-| 申请人 | 唐启云 |
-| 递交商标局 | 2026-01-12 |
-| 版本 | 基础版 |
-
-## 第42类服务项目
-
-计算机出租；计算机软件设计；为他人研究和开发新产品；计算机软件维护；把有形的数据或文件转换成电子媒体；为他人创建和维护网站；网络服务器出租；提供互联网搜索引擎；托管计算机站（网站）；云计算。
-
-## 权利状态
-
-"方弦®"商标（注册号89648411）已获中国国家知识产权局商标局核准注册，核定使用于第42类上述服务项目，现为注册商标。
-
-## 授权范围
-
-本仓库的开源许可证（MIT License）仅授予代码的使用、修改和分发权利，**不构成对任何商标、服务标记或品牌名称的授权许可**。
-
-任何派生作品、修改版本、商业产品均不得使用"方弦"名称、Logo 或相关标识，除非获得书面授权。
-
-## 使用规范
-
-- 在开源社区讨论、文档引用中提及本项目时，可使用"方弦®"指代本项目名称
-- 未经书面授权，不得在任何商业产品、服务或宣传材料中使用"方弦"标识
-
-## 获取授权
-
-如需将"方弦"商标用于商业用途，请联系：唐启云 <tqy@fxri.net>
-
-## 侵权处理
-
-如发现未经授权使用"方弦®"商标的行为，请通过上述联系方式举报。
+# 商标声明
+
+## 基本信息
+
+| 项目 | 内容 |
+|---|---|
+| 商标名称 | 方弦® |
+| 商标类型 | 文字商标 |
+| 商标说明 | 商标由文字"方弦"组成 |
+| 商标类别 | 第42类（共10项） |
+| 注册号 | 89648411 |
+| 申请人 | 唐启云 |
+| 递交商标局 | 2026-01-12 |
+| 版本 | 基础版 |
+
+## 第42类服务项目
+
+计算机出租；计算机软件设计；为他人研究和开发新产品；计算机软件维护；把有形的数据或文件转换成电子媒体；为他人创建和维护网站；网络服务器出租；提供互联网搜索引擎；托管计算机站（网站）；云计算。
+
+## 权利状态
+
+"方弦®"商标（注册号89648411）已获中国国家知识产权局商标局核准注册，核定使用于第42类上述服务项目，现为注册商标。
+
+## 授权范围
+
+本仓库的开源许可证（MIT License）仅授予代码的使用、修改和分发权利，**不构成对任何商标、服务标记或品牌名称的授权许可**。
+
+任何派生作品、修改版本、商业产品均不得使用"方弦"名称、Logo 或相关标识，除非获得书面授权。
+
+## 使用规范
+
+- 在开源社区讨论、文档引用中提及本项目时，可使用"方弦®"指代本项目名称
+- 未经书面授权，不得在任何商业产品、服务或宣传材料中使用"方弦"标识
+
+## 获取授权
+
+如需将"方弦"商标用于商业用途，请联系：唐启云 <tqy@fxri.net>
+
+## 侵权处理
+
+如发现未经授权使用"方弦®"商标的行为，请通过上述联系方式举报。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fxri/toolkit",
-  "version": "1.12.1",
+  "version": "1.12.3",
   "description": "专为多人 + AI 跨项目协作打造：任务管理 + 多语言 CHANGELOG。",
   "license": "MIT",
   "author": {
@@ -41,6 +41,25 @@
     "NOTICE",
     "package.json"
   ],
+  "scripts": {
+    "dev": "pnpm build:debug && node ./dist/cli.js",
+    "build": "cross-env NODE_ENV=production tsup",
+    "build:debug": "cross-env NODE_ENV=development tsup --config tsup.dev.config.ts",
+    "typecheck": "tsc --noEmit -p tsconfig.typecheck.json",
+    "lint": "eslint . --cache",
+    "lint:fix": "eslint . --fix",
+    "test": "vitest run --exclude \"src/__tests__/warn-threshold.test.ts\"",
+    "test:watch": "vitest",
+    "test:coverage": "vitest run --coverage --exclude \"src/__tests__/warn-threshold.test.ts\"",
+    "test:repo-guard": "vitest run src/__tests__/warn-threshold.test.ts",
+    "verify": "node scripts/verify.mjs",
+    "changeset": "changeset",
+    "sync:changelog-doc": "node scripts/sync-changelog-doc.mjs",
+    "docs:dev": "vitepress dev docs",
+    "docs:build": "vitepress build docs",
+    "docs:preview": "vitepress preview docs",
+    "release": "pnpm build && pnpm publish"
+  },
   "keywords": [
     "toolkit",
     "task",
@@ -65,30 +84,12 @@
     "vitepress": "^1.6.4",
     "vitest": "^4.1.11"
   },
+  "packageManager": "pnpm@10.34.4",
   "engines": {
     "node": ">=20.19.0"
   },
   "publishConfig": {
     "registry": "https://registry.npmjs.org/",
     "access": "public"
-  },
-  "scripts": {
-    "dev": "pnpm build:debug && node ./dist/cli.js",
-    "build": "cross-env NODE_ENV=production tsup",
-    "build:debug": "cross-env NODE_ENV=development tsup --config tsup.dev.config.ts",
-    "typecheck": "tsc --noEmit -p tsconfig.typecheck.json",
-    "lint": "eslint . --cache",
-    "lint:fix": "eslint . --fix",
-    "test": "vitest run --exclude \"src/__tests__/warn-threshold.test.ts\"",
-    "test:watch": "vitest",
-    "test:coverage": "vitest run --coverage --exclude \"src/__tests__/warn-threshold.test.ts\"",
-    "test:repo-guard": "vitest run src/__tests__/warn-threshold.test.ts",
-    "verify": "node scripts/verify.mjs",
-    "changeset": "changeset",
-    "sync:changelog-doc": "node scripts/sync-changelog-doc.mjs",
-    "docs:dev": "vitepress dev docs",
-    "docs:build": "vitepress build docs",
-    "docs:preview": "vitepress preview docs",
-    "release": "pnpm build && pnpm publish"
   }
-}
+}

package/skills/README.md

@@ -8,7 +8,7 @@
 
 | 技能 | 版本 | 用途 |
 | --- | --- | --- |
-| [fxri-plan-to-task](./fxri-plan-to-task/SKILL.md) | 1.8.7 | 方案落盘：建档评估（先查后写）→ 建档 → 校验 → 归档 → 任务级规范沉淀（能力终点）；规范载体迁移与升级 |
+| [fxri-plan-to-task](./fxri-plan-to-task/SKILL.md) | 1.8.8 | 方案落盘：建档评估（先查后写）→ 建档 → 校验 → 归档 → 任务级规范沉淀（能力终点）；规范载体迁移与升级 |
 | [fxri-release-changelog](./fxri-release-changelog/SKILL.md) | 1.1.9 | changesets 发版与多语言 CHANGELOG 维护 |
 | [fxri-session-recap](./fxri-session-recap/SKILL.md) | 1.4.1 | 会话收尾全量沉淀 + 规范沉淀 / 新会话三层恢复 / 历史任务时间批量修正 |
 

package/skills/fxri-plan-to-task/SKILL.md

@@ -3,14 +3,14 @@ name: fxri-plan-to-task
 description: 将已确认的实施方案落盘为标准任务文件并跟踪至归档：动手前建档评估（查 active/archive 判同主题）、按模板建档、状态机更新、四级时间源取证、自查校验、任务级规范沉淀与手工归档。当用户确认方案后表达「开始落地/登记记录」的意图，或即将动手改仓库文件时使用——含建档、任务登记、落盘、归档、任务校验、规范载体迁移与升级（conventions 单文件升目录形态、v1 / v2 升 v3）等说法及其口语近义表达（如按这个做吧、记一下、建个任务跟踪）均触发。不用于方案未确认的对话、会话收尾整场沉淀（fxri-session-recap 模式一）、与任务记录无关的普通 TODO、issue 管理或日常提交信息撰写。
 license: MIT
 metadata:
-  version: "1.8.7"
+  version: "1.8.8"
   author: fxri
   source: https://github.com/fxri-net/toolkit
 ---
 
 # 方案落盘：任务建档与归档
 
-> 本技能版本 1.8.7（随 @fxri/toolkit 同批分发）。被问版本时即报此值——不读磁盘、不跑 CLI：报出的值就是本会话上下文里已加载内容的版本，可与 `toolkit skills status` 打印的磁盘基准值对照，不一致即说明会话上下文已过期，开新会话即可。
+> 本技能版本 1.8.8（随 @fxri/toolkit 同批分发）。被问版本时即报此值——不读磁盘、不跑 CLI：报出的值就是本会话上下文里已加载内容的版本，可与 `toolkit skills status` 打印的磁盘基准值对照，不一致即说明会话上下文已过期，开新会话即可。
 
 ## 何时使用
 

package/skills/fxri-plan-to-task/assets/active-task-template.md

@@ -1,13 +1,13 @@
----
-owner: <负责人 git 用户名>
-status: 待办
-created: <创建日 YYYYMMDD>
-updated: <创建日 YYYYMMDD，随每次修改同步>
-completed: ''
-depends_on: []
-scope: <影响范围>
----
-
-# 任务标题
-
-（方案正文：背景、实施方案、影响范围、验证方式）
+---
+owner: <负责人 git 用户名>
+status: 待办
+created: <创建日 YYYYMMDD>
+updated: <创建日 YYYYMMDD，随每次修改同步>
+completed: ''
+depends_on: []
+scope: <影响范围>
+---
+
+# 任务标题
+
+（方案正文：背景、实施方案、影响范围、验证方式）

package/skills/fxri-plan-to-task/references/conventions-spec.md

@@ -131,7 +131,7 @@
 ```
 
 - **首列记为行内代码包裹的裸 ID `C-<n>`，不写规则名**（规范名以 `index.md` 索引表为准；规则改名等沿革信息作前置括注记入「修订内容」列，如「（原名「X」）」）。此为硬性要求：`toolkit tasks check` 与 `toolkit conventions status` 检出非 ID 首列并软告警（只报不改——历史行只追加不改旧行的元规则下，补齐须人工确认）
-- **「修订内容」列只记该条自身语义**：新立条目直接写其语义；语义变更写「旧语义」→「新语义」（箭头两侧文本加全角引号）。两条禁令——不得写自指套话（如「（本次起入表）」「新立条目：」，表内每行本就是入表记录、自指零信息量）；不得复述 `index.md` 索引列信息（如「；条文全文落 `common.md`」与索引「单一事实源」列重复，违反 §1.1 不变量 I4）。规范名沿革作前置括注（如「（原名「增量判别」）」）。**措辞归一例外**：属 §9 同类的措辞层归一、非语义变更，可原地改写旧行、不入 `history.md` 留痕行。`toolkit tasks check` / `toolkit conventions status` 检出禁用语料并软告警（只报不改，改写须人工确认）
+- **「修订内容」列只记该条自身语义**：新立条目直接写其语义；语义变更写「旧语义」→「新语义」（箭头两侧文本加全角引号）。两条禁令——不得写自指套话（如「（本次起入表）」「新立条目：」，表内每行本就是入表记录、自指零信息量）；不得复述 `index.md` 索引列信息（如「；条文全文落 `common.md`」与索引「单一事实源」列重复，违反 §1.1 不变量 I4）。规范名沿革作前置括注（如「（原名「增量判别」）」）。**措辞归一例外**：措辞层归一（表格形态归一见 §9，规范词归一见 §13 T5）属非语义变更，可原地改写旧行、不入 `history.md` 留痕行。`toolkit tasks check` / `toolkit conventions status` 检出禁用语料并软告警（只报不改，改写须人工确认）
 - **表头固定**：须恰为 `ID | 修订内容 | 修订来源任务` 三列，逐格一致（含列名与次序）；`toolkit tasks check` / `toolkit conventions status` 检出表头偏离并软告警
 - **表语义边界写死**：载体结构升级（如 v1 / v2 → v3）、入口壳生成 / 删除、条目退休都不入表——表只记**规范语义**变更
 
@@ -372,6 +372,8 @@
 
 同一强度不混用多种措辞——不用「必须」「应该」「不可以」「禁止」等近义词替代上表四词。
 
+适用范围：条文正文、`index.md` 索引行与 `history.md`「修订内容」列。`history.md` 的规范词归一属措辞层（非语义变更），按 §3.2 措辞归一例外原地改写、不新增留痕行；引号内引述的外部文档原文不改。
+
 ### T6 标点与代码
 
 - 标识符、文件路径、文件名、命令、配置项、规则 ID 一律用**行内代码**包裹（如 `C-17`、`index.md`、`toolkit conventions status`、`scope`）

package/skills/fxri-release-changelog/SKILL.md

@@ -1,74 +1,74 @@
----
-name: fxri-release-changelog
-description: 基于 changesets 的发版与多语言 CHANGELOG 维护流程：创建变更集、消费发版、把分组标题与条目转为项目语言风格、清理变更集、打标签发布；无 changesets 的项目提供同格式手工模式。当用户表达发版或记录变更意图——含创建变更集、changeset、发版、version、CHANGELOG 格式化等说法及其口语近义表达（如发一版、出个版本、记一下这次改动、生成更新日志）时使用。⚠️ 注意区分：用户说「提交个版本 / 先提交一版 / commit」通常指 git 提交当前改动（走任务收尾后提交），**不是发版**。不用于日常 commit message 撰写、git 提交操作或与发版无关的文档修改。
-license: MIT
-metadata:
-  version: "1.1.9"
-  author: fxri
-  source: https://github.com/fxri-net/toolkit
----
-
-# 发版与 CHANGELOG
-
-> 本技能版本 1.1.9（随 @fxri/toolkit 同批分发）。被问版本时即报此值——不读磁盘、不跑 CLI：报出的值就是本会话上下文里已加载内容的版本，可与 `toolkit skills status` 打印的磁盘基准值对照，不一致即说明会话上下文已过期，开新会话即可。
-
-## 何时使用
-
-- 记录变更（创建变更集）、消费变更集发版、格式化 CHANGELOG（语义触发，不要求字面一致）：changeset / 变更集 / 发版 / version / CHANGELOG 格式化 / 发一版 / 出个版本 / 记一下这次改动 / 生成更新日志
-- 触发前置条件：**用户明确表达发版或记录变更意图**。⚠️ **git 提交 ≠ 发版**：用户说「提交个版本 / 先提交一版 / 提交一下 / commit 这版」通常指把当前改动 git 提交（涉及任务时先走 fxri-plan-to-task / fxri-session-recap 收尾再提交），**不触发本技能**；纯日常对话出现「版本」字样也不触发
-- 拿不准用户意图时向用户确认，不猜
-
-**何时不使用**：日常 commit message 撰写、git 提交操作、与发版无关的文档修改。
-
-## 前置检查
-
-- ⚠️ 发版不是必经步骤：仅在用户明确要求，或用户全局 / 个人 / 项目规则约定时才进入本技能，不主动发版
-- ⚠️ **发版是收尾动作，不是任务**：本技能不为发版本身建档——发版的输入是「已归档的任务改动」，发版过程及其固有产物（版本号、更新日志、标签）不构成任务、不作为建档对象。例外：过程中暴露的、需改仓库文件才能修复的缺陷（打包配置错误、发布渠道错误、版本号冲突）→ 走 fxri-plan-to-task 先建档再改
-- `.tasks/active/` 存在未归档任务 → 先完成归档再发版（任务归档是发版的前置顺序）
-- **覆盖核对**：本次待发布的改动逐项确认已有归档记录；出现「有改动却无归档记录」→ 先补归档（fxri-session-recap 模式一）再发版
-- 项目根存在 `.changeset/` 目录 → 走「changesets 流程」
-- 不存在 → 走「手工模式」（规范见 `references/changelog-format.md`）
-
-## changesets 流程
-
-1. 记录变更：`npx changeset`（或项目包管理器等价脚本）——**变更描述一律逐条以 `- 类型：描述` 书写**：既要 `类型：` 前缀（如 `新增：` / `修复：` / `优化：`）作归类信号，也要 `- ` 列表标记把每条独立成项（缺标记的裸行会被 changesets 并入相邻条目作缩进续行，整段塌成单一条目、只有首行归组剥前缀）；并按改动的**能力量级**选影响级别（破坏性→major、全新大功能/独立新能力→minor、存量能力上的修补与增量→patch，完整对照见 `references/changelog-format.md`）。写完可跑 `toolkit tasks check` 早期自查：它扫 `.changeset/` 下待发布变更集，逐文件报出缺前缀条目与未加 `- ` 标记的裸行及条数（免得到发版、变更集源被消费删除后才由 changelog 侧兜底告警——那时已无从补写）
-2. 消费发版：`npx changeset version`——自动写版本号与 CHANGELOG
-3. 格式化：按 `references/changelog-format.md` 的语义分组规则归类条目、转换分组标题、润色为项目语言风格（中文示例：`### Patch Changes` 下的 `- 修复：xxx` → `### 🐛 问题修复` 下的 `- xxx`——归类后类型前缀被剥离，类型由分组标题承接）；分组维度与 bump 维度正交，条目归组只看类型前缀
-4. 归一：润色后跑一次 `toolkit changelog --history format`——人工润色（含补写历史块明细）容易在条目之间留空行，该命令按「同组顶层条目逐行相邻」重排历史块；项目另有更新日志镜像页（如 `docs/changelog.md`）时再跑一次同步脚本，否则镜像一致性校验会失败
-5. 清理：删除已消费的 `.changeset/*.md`
-6. 门禁：发布前跑一次项目的验收命令（如 `pnpm verify`）——**关卡设在发布前而非推送前**：发布到包仓库 / 制品库不可逆，推送失败重推即可，故必须拦在不可逆动作之前；任一步失败即中止发版，不进入提交、打标签、发布
-7. 发布：提交版本与 CHANGELOG 改动 → 打 `vX.Y.Z` 标签 → 按项目渠道发布（如 `npm publish`）
-
-⚠️ 自动生成的条目必须人工核对润色，与仓库既有 CHANGELOG 风格保持一致。
-
-## 手工模式（无 changesets 项目）
-
-版本号与 CHANGELOG 全部手工维护：版本标题、发布日期行、分组标题与条目格式见 `references/changelog-format.md`；多语言四段结构（语义分组 / 标题替换映射 / 依赖更新文案 / 发布日期后缀）同文件。
-
-## 失败模式
-
-| 症状 | 处置 |
-| --- | --- |
-| version 后 CHANGELOG 分组标题仍是英文 | 按 references 的映射表补一次格式化 |
-| CHANGELOG 出现「- - 条目」双前缀伪影（变更集条目以 `- ` 开头） | `toolkit changelog version/format` 已自动还原为顶层条目；手工模式按 references 规则手动清理 |
-| 条目与仓库既有风格不一致 | 人工润色为项目语言与句式，勿保留机器直译 |
-| 变更集遗漏（发版后才发现功能未记录） | 补建变更集随下次发版；本次在发布说明中人工补充 |
-| `toolkit tasks check` 报「变更集条目缺类型前缀」 | 打开所列文件，给缺前缀的**顶层条目**按「类型：描述」补前缀（缩进续行随父条目迁属、无需加）；补前缀只改分类信号，不改变 bump 级别 |
-| `toolkit tasks check` 报「变更集条目未加「- 」列表标记」 | 打开所列文件，把裸行逐条改为 `- 类型：描述`（列 0 起首、无 `- ` 标记的行会被 changesets 并入相邻条目作续行，整段塌成单一条目、只有首行归组剥前缀）；若已发版才发现，说明该版本块条目可能已挤在单组且前缀未剥离，按 references 的「人工事实更正」修 `CHANGELOG.md` 并重跑镜像页同步 |
-| 改动已发布却无归档记录（有提交、无任务档） | 先补归档（fxri-session-recap 模式一）再继续发布后续步骤；发版本身不补建档 |
-| 发版后历史块内出现多余空行（`自举一致性` 类零改动用例失败） | 跑 `toolkit changelog --history format` 归一（**必须带 `--history`**，默认模式不动历史块），再补跑一次镜像页同步脚本 |
-| 格式化时 stderr 报「归类后条目数由 N 降为 M，疑似丢失内容」 | 归类只应搬移条目，减少即疑似丢内容：核对该版本块是否含非纯条目分组（标题下先出现正文）或被保留分组；确认属正常去重可忽略，否则按 references 的归类规则修回 |
-| 一批改动含新增能力 / 参数，却整批按 `修复：` 前缀登记（整块落 `问题修复` 组）——常见于 bump 判定为 patch 时，误以为级别与条目前缀绑定 | 前缀按**变更本身性质**逐条定：新增命令 / 参数 / 产物用 `新增：`、缺陷纠正用 `修复：`。分组只看前缀、与 bump 正交，**patch 也可挂 `新增：`**——bump 按改动的能力量级判（存量能力上的小新增即 patch），口径见 references |
-
-## 可选加速（不构成依赖）
-
-⚠️ 工具探测顺序（先项目内、后全局）：先 `pnpm exec toolkit --help`（项目 devDependency，npm 项目等价 `npx toolkit`），失败再 `toolkit --help`（全局安装）；两者都不可用即工具未安装，按各步手工继续，**不安装、不阻塞**。探测成功后用对应前缀执行下列命令：
-
-- `toolkit changelog`：创建变更集（等价 changeset）
-- `toolkit changelog version`：发版并自动做中文分组标题格式化
-- `toolkit changelog format`：仅格式化既有 CHANGELOG
-- `toolkit changelog --history format`：连带追溯改写历史版本块（用户主动要求修正历史块时才加，默认不动）
-- `toolkit changelog --lang <语言> …`：切换输出语言（内置 zh / en，其余可配置扩展）
-- `toolkit tasks check`：扫 `.changeset/` 下待发布变更集并逐文件报出缺前缀条目与未加 `- ` 标记的裸行（流程第 1 步的早期自查入口，归档前的 `tasks check` 即含此项）
-- ⚠️ `changelog` 域开了选项透传，自有选项（`--lang` / `--history` / `--redact` / `--warn`）必须写在子命令**之前**：`toolkit changelog --history format` 生效，写成 `toolkit changelog format --history` 会被 changesets 静默忽略（表现为「无 CHANGELOG 需要更新」）
-- `toolkit skills install` / `toolkit skills status`：把本包 fxri-* 技能分发到目标技能目录（`--scope` 缺省按 CLI 安装位置自动判定全局面 / 项目面；项目面真源落 `<仓库根>/.agents/skills/`、其余候选目录落入口薄壳，随仓库入库后队友 clone 即用）/ 查看链接、副本与项目面现场（技能随包同源分发，与 CLI 同一发布批次；技能内容版本独立编号，`skills status` 会打印各技能真源版本）
+---
+name: fxri-release-changelog
+description: 基于 changesets 的发版与多语言 CHANGELOG 维护流程：创建变更集、消费发版、把分组标题与条目转为项目语言风格、清理变更集、打标签发布；无 changesets 的项目提供同格式手工模式。当用户表达发版或记录变更意图——含创建变更集、changeset、发版、version、CHANGELOG 格式化等说法及其口语近义表达（如发一版、出个版本、记一下这次改动、生成更新日志）时使用。⚠️ 注意区分：用户说「提交个版本 / 先提交一版 / commit」通常指 git 提交当前改动（走任务收尾后提交），**不是发版**。不用于日常 commit message 撰写、git 提交操作或与发版无关的文档修改。
+license: MIT
+metadata:
+  version: "1.1.9"
+  author: fxri
+  source: https://github.com/fxri-net/toolkit
+---
+
+# 发版与 CHANGELOG
+
+> 本技能版本 1.1.9（随 @fxri/toolkit 同批分发）。被问版本时即报此值——不读磁盘、不跑 CLI：报出的值就是本会话上下文里已加载内容的版本，可与 `toolkit skills status` 打印的磁盘基准值对照，不一致即说明会话上下文已过期，开新会话即可。
+
+## 何时使用
+
+- 记录变更（创建变更集）、消费变更集发版、格式化 CHANGELOG（语义触发，不要求字面一致）：changeset / 变更集 / 发版 / version / CHANGELOG 格式化 / 发一版 / 出个版本 / 记一下这次改动 / 生成更新日志
+- 触发前置条件：**用户明确表达发版或记录变更意图**。⚠️ **git 提交 ≠ 发版**：用户说「提交个版本 / 先提交一版 / 提交一下 / commit 这版」通常指把当前改动 git 提交（涉及任务时先走 fxri-plan-to-task / fxri-session-recap 收尾再提交），**不触发本技能**；纯日常对话出现「版本」字样也不触发
+- 拿不准用户意图时向用户确认，不猜
+
+**何时不使用**：日常 commit message 撰写、git 提交操作、与发版无关的文档修改。
+
+## 前置检查
+
+- ⚠️ 发版不是必经步骤：仅在用户明确要求，或用户全局 / 个人 / 项目规则约定时才进入本技能，不主动发版
+- ⚠️ **发版是收尾动作，不是任务**：本技能不为发版本身建档——发版的输入是「已归档的任务改动」，发版过程及其固有产物（版本号、更新日志、标签）不构成任务、不作为建档对象。例外：过程中暴露的、需改仓库文件才能修复的缺陷（打包配置错误、发布渠道错误、版本号冲突）→ 走 fxri-plan-to-task 先建档再改
+- `.tasks/active/` 存在未归档任务 → 先完成归档再发版（任务归档是发版的前置顺序）
+- **覆盖核对**：本次待发布的改动逐项确认已有归档记录；出现「有改动却无归档记录」→ 先补归档（fxri-session-recap 模式一）再发版
+- 项目根存在 `.changeset/` 目录 → 走「changesets 流程」
+- 不存在 → 走「手工模式」（规范见 `references/changelog-format.md`）
+
+## changesets 流程
+
+1. 记录变更：`npx changeset`（或项目包管理器等价脚本）——**变更描述一律逐条以 `- 类型：描述` 书写**：既要 `类型：` 前缀（如 `新增：` / `修复：` / `优化：`）作归类信号，也要 `- ` 列表标记把每条独立成项（缺标记的裸行会被 changesets 并入相邻条目作缩进续行，整段塌成单一条目、只有首行归组剥前缀）；并按改动的**能力量级**选影响级别（破坏性→major、全新大功能/独立新能力→minor、存量能力上的修补与增量→patch，完整对照见 `references/changelog-format.md`）。写完可跑 `toolkit tasks check` 早期自查：它扫 `.changeset/` 下待发布变更集，逐文件报出缺前缀条目与未加 `- ` 标记的裸行及条数（免得到发版、变更集源被消费删除后才由 changelog 侧兜底告警——那时已无从补写）
+2. 消费发版：`npx changeset version`——自动写版本号与 CHANGELOG
+3. 格式化：按 `references/changelog-format.md` 的语义分组规则归类条目、转换分组标题、润色为项目语言风格（中文示例：`### Patch Changes` 下的 `- 修复：xxx` → `### 🐛 问题修复` 下的 `- xxx`——归类后类型前缀被剥离，类型由分组标题承接）；分组维度与 bump 维度正交，条目归组只看类型前缀
+4. 归一：润色后跑一次 `toolkit changelog --history format`——人工润色（含补写历史块明细）容易在条目之间留空行，该命令按「同组顶层条目逐行相邻」重排历史块；项目另有更新日志镜像页（如 `docs/changelog.md`）时再跑一次同步脚本，否则镜像一致性校验会失败
+5. 清理：删除已消费的 `.changeset/*.md`
+6. 门禁：发布前跑一次项目的验收命令（如 `pnpm verify`）——**关卡设在发布前而非推送前**：发布到包仓库 / 制品库不可逆，推送失败重推即可，故必须拦在不可逆动作之前；任一步失败即中止发版，不进入提交、打标签、发布
+7. 发布：提交版本与 CHANGELOG 改动 → 打 `vX.Y.Z` 标签 → 按项目渠道发布（如 `npm publish`）
+
+⚠️ 自动生成的条目必须人工核对润色，与仓库既有 CHANGELOG 风格保持一致。
+
+## 手工模式（无 changesets 项目）
+
+版本号与 CHANGELOG 全部手工维护：版本标题、发布日期行、分组标题与条目格式见 `references/changelog-format.md`；多语言四段结构（语义分组 / 标题替换映射 / 依赖更新文案 / 发布日期后缀）同文件。
+
+## 失败模式
+
+| 症状 | 处置 |
+| --- | --- |
+| version 后 CHANGELOG 分组标题仍是英文 | 按 references 的映射表补一次格式化 |
+| CHANGELOG 出现「- - 条目」双前缀伪影（变更集条目以 `- ` 开头） | `toolkit changelog version/format` 已自动还原为顶层条目；手工模式按 references 规则手动清理 |
+| 条目与仓库既有风格不一致 | 人工润色为项目语言与句式，勿保留机器直译 |
+| 变更集遗漏（发版后才发现功能未记录） | 补建变更集随下次发版；本次在发布说明中人工补充 |
+| `toolkit tasks check` 报「变更集条目缺类型前缀」 | 打开所列文件，给缺前缀的**顶层条目**按「类型：描述」补前缀（缩进续行随父条目迁属、无需加）；补前缀只改分类信号，不改变 bump 级别 |
+| `toolkit tasks check` 报「变更集条目未加「- 」列表标记」 | 打开所列文件，把裸行逐条改为 `- 类型：描述`（列 0 起首、无 `- ` 标记的行会被 changesets 并入相邻条目作续行，整段塌成单一条目、只有首行归组剥前缀）；若已发版才发现，说明该版本块条目可能已挤在单组且前缀未剥离，按 references 的「人工事实更正」修 `CHANGELOG.md` 并重跑镜像页同步 |
+| 改动已发布却无归档记录（有提交、无任务档） | 先补归档（fxri-session-recap 模式一）再继续发布后续步骤；发版本身不补建档 |
+| 发版后历史块内出现多余空行（`自举一致性` 类零改动用例失败） | 跑 `toolkit changelog --history format` 归一（**必须带 `--history`**，默认模式不动历史块），再补跑一次镜像页同步脚本 |
+| 格式化时 stderr 报「归类后条目数由 N 降为 M，疑似丢失内容」 | 归类只应搬移条目，减少即疑似丢内容：核对该版本块是否含非纯条目分组（标题下先出现正文）或被保留分组；确认属正常去重可忽略，否则按 references 的归类规则修回 |
+| 一批改动含新增能力 / 参数，却整批按 `修复：` 前缀登记（整块落 `问题修复` 组）——常见于 bump 判定为 patch 时，误以为级别与条目前缀绑定 | 前缀按**变更本身性质**逐条定：新增命令 / 参数 / 产物用 `新增：`、缺陷纠正用 `修复：`。分组只看前缀、与 bump 正交，**patch 也可挂 `新增：`**——bump 按改动的能力量级判（存量能力上的小新增即 patch），口径见 references |
+
+## 可选加速（不构成依赖）
+
+⚠️ 工具探测顺序（先项目内、后全局）：先 `pnpm exec toolkit --help`（项目 devDependency，npm 项目等价 `npx toolkit`），失败再 `toolkit --help`（全局安装）；两者都不可用即工具未安装，按各步手工继续，**不安装、不阻塞**。探测成功后用对应前缀执行下列命令：
+
+- `toolkit changelog`：创建变更集（等价 changeset）
+- `toolkit changelog version`：发版并自动做中文分组标题格式化
+- `toolkit changelog format`：仅格式化既有 CHANGELOG
+- `toolkit changelog --history format`：连带追溯改写历史版本块（用户主动要求修正历史块时才加，默认不动）
+- `toolkit changelog --lang <语言> …`：切换输出语言（内置 zh / en，其余可配置扩展）
+- `toolkit tasks check`：扫 `.changeset/` 下待发布变更集并逐文件报出缺前缀条目与未加 `- ` 标记的裸行（流程第 1 步的早期自查入口，归档前的 `tasks check` 即含此项）
+- ⚠️ `changelog` 域开了选项透传，自有选项（`--lang` / `--history` / `--redact` / `--warn`）必须写在子命令**之前**：`toolkit changelog --history format` 生效，写成 `toolkit changelog format --history` 会被 changesets 静默忽略（表现为「无 CHANGELOG 需要更新」）
+- `toolkit skills install` / `toolkit skills status`：把本包 fxri-* 技能分发到目标技能目录（`--scope` 缺省按 CLI 安装位置自动判定全局面 / 项目面；项目面真源落 `<仓库根>/.agents/skills/`、其余候选目录落入口薄壳，随仓库入库后队友 clone 即用）/ 查看链接、副本与项目面现场（技能随包同源分发，与 CLI 同一发布批次；技能内容版本独立编号，`skills status` 会打印各技能真源版本）

package/skills/fxri-release-changelog/references/changelog-format.md

@@ -1,85 +1,85 @@
-# CHANGELOG 格式规范
-
-## 1. 文件结构（中文示例）
-
-```markdown
-## 1.5.3
-
-> 2026-09-03 发布
-
-### 🐛 问题修复
-
-- 修复xxx：……
-
-### 📦 其他变更
-
-- 补齐某处兜底逻辑
-```
-
-规则：
-
-- 版本标题 `## {版本号}`；隔一行后接引用行 `> {YYYY-MM-DD} 发布`（标题与日期行之间保留一个空行）
-- 分组标题 = emoji + 组名，一行一组，按**语义分组顺序**输出——重大变更 → 新增功能 → 功能调整 → 优化改进 → 问题修复 → 文档更新 → 清理移除 → 依赖变更 → 其他变更；空组省略
-- 条目一行一条，每条**须以 `- ` 列表标记开头**（仅 `- ` 列表项被逐条收录）；项目语言句式（中文条目句末不加句号），与仓库既有风格一致
-- ⚠️ **务必逐条写成 `- 类型：描述`**：变更集正文里列 0 起首、无 `- ` 标记的裸行会被 changesets 并入相邻条目作缩进续行——整段正文塌成**单一条目**，只有首行参与前缀识别与归类，其余行既不归组也不剥前缀，最终全挤在首行所属的单组里（本仓 v1.12.0 块的成因）。`toolkit tasks check` 对裸行（前缀开头、连续 2 行起）报软告警，归档前据此自查
-- 同一分组内顶层条目**逐行相邻输出**（条目之间不留空行，缩进子项紧随父条目），分组之间与日期行前后各留一个空行——这是格式化的**不动点**：合规文件重复执行 `toolkit changelog format` 应零改动，`--history` 归一之后同理
-- ⚠️ 变更集条目以 `- ` 开头时，changesets 会写入 `- - 条目` 首行并把后续行缩进 2 空格（伪影）；`toolkit changelog version/format` 会自动还原为顶层条目，手工模式需手动清理
-- 分组标题集合随版本演进而变化；**历史版本块保留当时口径，`toolkit changelog format` 不追溯改写**（只归类 changesets 本次新写入的英文源标题块）
-- ⚠️ **人工事实更正**：已发布版本块原则上不追溯改写；确需更正**事实性错误**（归组误判、错别字等）时允许人工修改——仓库 `CHANGELOG.md` 为真源，已发布的包产物与版本标签是**不可变快照**、不回补，正确版随下次发版由整份 CHANGELOG 带入
-
-## 2. 语义分组归类
-
-分组维度（条目**变更类型**）与版本号维度（bump）正交：条目归入哪一组，只看条目自带的**类型前缀**，与它来自 `Major/Minor/Patch Changes` 哪一块无关。
-
-**类型前缀 → 语义槽位**（全局一份、全语言共用，故任一语言的条目在任何输出语言下都能正确归组）：
-
-| 类型前缀（中 / 英） | 语义槽位 | zh 组标题 | en 组标题 |
-| --- | --- | --- | --- |
-| `重大：` / `Breaking:` | `breaking` | `### 🚨 重大变更` | `### 🚨 Breaking Changes` |
-| `新增：` / `Added:` | `added` | `### ✨ 新增功能` | `### ✨ Added` |
-| `修改：` / `Changed:` | `changed` | `### 🔧 功能调整` | `### 🔧 Changed` |
-| `优化：` / `Improved:` | `improved` | `### ⚡ 优化改进` | `### ⚡ Improved` |
-| `修复：` / `Fixed:` | `fixed` | `### 🐛 问题修复` | `### 🐛 Fixed` |
-| `文档：` / `Docs:` | `docs` | `### 📝 文档更新` | `### 📝 Docs` |
-| `清理：` / `Removed:` | `removed` | `### 🧹 清理移除` | `### 🧹 Removed` |
-| `依赖：` / 源文本 `- Updated dependencies` | `deps` | `### 🔗 依赖变更` | `### 🔗 Dependency Updates` |
-| 无前缀兜底 | `other` | `### 📦 其他变更` | `### 📦 Other` |
-
-**无前缀条目的兜底规则**：按条目**所属源组标题**声明的影响级别归组——`### Major Changes` → `breaking`、`### Minor Changes` → `added`、`### Patch Changes` → `other`；不从版本号推导。
-
-**缺前缀与裸行的检测入口**：`toolkit tasks check` 扫 `.changeset/` 下待发布变更集（`.md` 且非 `README.md`），逐文件报出两类软告警——**缺类型前缀**的顶层条目数与首条行号、以及**未加 `- ` 列表标记**的裸行数与首条行号（后者取列 0 起首、以已识别前缀开头且连续 2 行起的行，阈值 2 避开正常正文误报）；归档前的早期自查，发版时 changelog 侧另有兜底告警。前缀识别取全局表与各配置语言 `prefixes` 的并集（自定义语言不误报），依赖源条目归 `deps` 不计缺前缀，缩进续行随父条目迁属、不参与识别。
-
-**追溯历史块的兜底规则**（`--history`）：历史块没有英文源组标题，改按**所属既有组标题**查槽位——先查当前语言组标题，再查历史组标题表（如 `### 🐛 补丁修复` → `fixed`）；两处都识别不出则整组连同标题保留、不臆造归属。
-
-**依赖条目不走前缀解析**：源组标题 `### Dependent Changes` 整块，以及源文本 `- Updated dependencies`（含缩进子项）一律归入 `deps` 槽位。
-
-**归类后剥离类型前缀**：条目归入槽位后，其已被识别的 `类型：` 前缀被剥离（`- 修复：xxx` → `- xxx`）——前缀只是归类信号，类型已由分组标题承接，留在明细里属冗余。未识别的前缀（如正文里的 `说明：`）与依赖源条目原样保留，剥离后文本为空也不改动。默认模式与 `--history` 追溯模式同此规则。
-
-同一槽位来自多个源块时合并为单组，组内保持条目原出现顺序；缩进续行随父条目整体迁移。
-
-**归类只搬移、不删内容**：归类只重组「纯条目分组」——分组标题下若在首个条目之前出现非空正文，判据不成立，整块保持原样以免丢内容；未参与归位的分组连同标题按原相对顺序附于块末，不臆造归属、不静默丢弃。CLI 在归类前后做条目数自检，减少即告警（正常合并发生在自检之后、不误报）。
-
-**能力量级 → bump**（撰写变更集时按此选影响级别）——版本号由变更集 frontmatter 的 bump 声明决定，**与条目前缀正交**：前缀只负责把条目归入哪一组，不决定版本号。
-
-| 影响级别 | 判定锚点（按改动的**能力量级**，不按条目前缀） |
-| --- | --- |
-| major | 破坏性变更——既有契约 / 行为不兼容 |
-| minor | 新增**全新的大功能 / 独立新能力**——用户升级后获得一整块新的使用方式 |
-| patch | 存量能力上的**修补与增量**——修复、优化、配套补齐，以及新增的**小命令 / 小参数 / 小产物**等，只要不属于「全新大功能」 |
-
-口径要点：
-
-- **判 bump 看能力量级、不看前缀**：`新增：` / `修改：` 只表示条目归入「新增功能」/「功能调整」组，不隐含 minor——新增的小能力照常按 patch 登记，无需例外申报
-- **不得为凑版本号降级**：确属「全新大功能 / 独立新能力」的改动不得为对齐目标版本号而按 patch 记；`重大：`（破坏性）不可降至 patch
-- 条目须**分条登记用户可感知的变更**——新增命令 / 参数分开列，不写抽象能力名（否则用户升级后不知多了什么）
-
-## 3. 多语言扩展
-
-每种语言约定四段结构：
-
-- `groups`（可选）：语义分组表，每项 `{ slot, title, prefixes? }`——`slot` 取自全局语义槽位，`title` 为本语言组标题，`prefixes` 为本语言自有前缀（可选，识别时与全局前缀表取并集）；缺省时退化为纯替换（仅 `replacements` 生效）
-- `replacements`：兜底替换映射表（源标题 → 目标标题）
-- `deps`：依赖更新条目固定文案
-- `released`：发布日期行后缀（中文为「发布」，英文为「released」；同时用于识别既有日期行，故自定义语言填非「发布/released」值也能幂等）
-
-新增语言时先补全四段，再按映射转换标题、润色条目。
+# CHANGELOG 格式规范
+
+## 1. 文件结构（中文示例）
+
+```markdown
+## 1.5.3
+
+> 2026-09-03 发布
+
+### 🐛 问题修复
+
+- 修复xxx：……
+
+### 📦 其他变更
+
+- 补齐某处兜底逻辑
+```
+
+规则：
+
+- 版本标题 `## {版本号}`；隔一行后接引用行 `> {YYYY-MM-DD} 发布`（标题与日期行之间保留一个空行）
+- 分组标题 = emoji + 组名，一行一组，按**语义分组顺序**输出——重大变更 → 新增功能 → 功能调整 → 优化改进 → 问题修复 → 文档更新 → 清理移除 → 依赖变更 → 其他变更；空组省略
+- 条目一行一条，每条**须以 `- ` 列表标记开头**（仅 `- ` 列表项被逐条收录）；项目语言句式（中文条目句末不加句号），与仓库既有风格一致
+- ⚠️ **务必逐条写成 `- 类型：描述`**：变更集正文里列 0 起首、无 `- ` 标记的裸行会被 changesets 并入相邻条目作缩进续行——整段正文塌成**单一条目**，只有首行参与前缀识别与归类，其余行既不归组也不剥前缀，最终全挤在首行所属的单组里（本仓 v1.12.0 块的成因）。`toolkit tasks check` 对裸行（前缀开头、连续 2 行起）报软告警，归档前据此自查
+- 同一分组内顶层条目**逐行相邻输出**（条目之间不留空行，缩进子项紧随父条目），分组之间与日期行前后各留一个空行——这是格式化的**不动点**：合规文件重复执行 `toolkit changelog format` 应零改动，`--history` 归一之后同理
+- ⚠️ 变更集条目以 `- ` 开头时，changesets 会写入 `- - 条目` 首行并把后续行缩进 2 空格（伪影）；`toolkit changelog version/format` 会自动还原为顶层条目，手工模式需手动清理
+- 分组标题集合随版本演进而变化；**历史版本块保留当时口径，`toolkit changelog format` 不追溯改写**（只归类 changesets 本次新写入的英文源标题块）
+- ⚠️ **人工事实更正**：已发布版本块原则上不追溯改写；确需更正**事实性错误**（归组误判、错别字等）时允许人工修改——仓库 `CHANGELOG.md` 为真源，已发布的包产物与版本标签是**不可变快照**、不回补，正确版随下次发版由整份 CHANGELOG 带入
+
+## 2. 语义分组归类
+
+分组维度（条目**变更类型**）与版本号维度（bump）正交：条目归入哪一组，只看条目自带的**类型前缀**，与它来自 `Major/Minor/Patch Changes` 哪一块无关。
+
+**类型前缀 → 语义槽位**（全局一份、全语言共用，故任一语言的条目在任何输出语言下都能正确归组）：
+
+| 类型前缀（中 / 英） | 语义槽位 | zh 组标题 | en 组标题 |
+| --- | --- | --- | --- |
+| `重大：` / `Breaking:` | `breaking` | `### 🚨 重大变更` | `### 🚨 Breaking Changes` |
+| `新增：` / `Added:` | `added` | `### ✨ 新增功能` | `### ✨ Added` |
+| `修改：` / `Changed:` | `changed` | `### 🔧 功能调整` | `### 🔧 Changed` |
+| `优化：` / `Improved:` | `improved` | `### ⚡ 优化改进` | `### ⚡ Improved` |
+| `修复：` / `Fixed:` | `fixed` | `### 🐛 问题修复` | `### 🐛 Fixed` |
+| `文档：` / `Docs:` | `docs` | `### 📝 文档更新` | `### 📝 Docs` |
+| `清理：` / `Removed:` | `removed` | `### 🧹 清理移除` | `### 🧹 Removed` |
+| `依赖：` / 源文本 `- Updated dependencies` | `deps` | `### 🔗 依赖变更` | `### 🔗 Dependency Updates` |
+| 无前缀兜底 | `other` | `### 📦 其他变更` | `### 📦 Other` |
+
+**无前缀条目的兜底规则**：按条目**所属源组标题**声明的影响级别归组——`### Major Changes` → `breaking`、`### Minor Changes` → `added`、`### Patch Changes` → `other`；不从版本号推导。
+
+**缺前缀与裸行的检测入口**：`toolkit tasks check` 扫 `.changeset/` 下待发布变更集（`.md` 且非 `README.md`），逐文件报出两类软告警——**缺类型前缀**的顶层条目数与首条行号、以及**未加 `- ` 列表标记**的裸行数与首条行号（后者取列 0 起首、以已识别前缀开头且连续 2 行起的行，阈值 2 避开正常正文误报）；归档前的早期自查，发版时 changelog 侧另有兜底告警。前缀识别取全局表与各配置语言 `prefixes` 的并集（自定义语言不误报），依赖源条目归 `deps` 不计缺前缀，缩进续行随父条目迁属、不参与识别。
+
+**追溯历史块的兜底规则**（`--history`）：历史块没有英文源组标题，改按**所属既有组标题**查槽位——先查当前语言组标题，再查历史组标题表（如 `### 🐛 补丁修复` → `fixed`）；两处都识别不出则整组连同标题保留、不臆造归属。
+
+**依赖条目不走前缀解析**：源组标题 `### Dependent Changes` 整块，以及源文本 `- Updated dependencies`（含缩进子项）一律归入 `deps` 槽位。
+
+**归类后剥离类型前缀**：条目归入槽位后，其已被识别的 `类型：` 前缀被剥离（`- 修复：xxx` → `- xxx`）——前缀只是归类信号，类型已由分组标题承接，留在明细里属冗余。未识别的前缀（如正文里的 `说明：`）与依赖源条目原样保留，剥离后文本为空也不改动。默认模式与 `--history` 追溯模式同此规则。
+
+同一槽位来自多个源块时合并为单组，组内保持条目原出现顺序；缩进续行随父条目整体迁移。
+
+**归类只搬移、不删内容**：归类只重组「纯条目分组」——分组标题下若在首个条目之前出现非空正文，判据不成立，整块保持原样以免丢内容；未参与归位的分组连同标题按原相对顺序附于块末，不臆造归属、不静默丢弃。CLI 在归类前后做条目数自检，减少即告警（正常合并发生在自检之后、不误报）。
+
+**能力量级 → bump**（撰写变更集时按此选影响级别）——版本号由变更集 frontmatter 的 bump 声明决定，**与条目前缀正交**：前缀只负责把条目归入哪一组，不决定版本号。
+
+| 影响级别 | 判定锚点（按改动的**能力量级**，不按条目前缀） |
+| --- | --- |
+| major | 破坏性变更——既有契约 / 行为不兼容 |
+| minor | 新增**全新的大功能 / 独立新能力**——用户升级后获得一整块新的使用方式 |
+| patch | 存量能力上的**修补与增量**——修复、优化、配套补齐，以及新增的**小命令 / 小参数 / 小产物**等，只要不属于「全新大功能」 |
+
+口径要点：
+
+- **判 bump 看能力量级、不看前缀**：`新增：` / `修改：` 只表示条目归入「新增功能」/「功能调整」组，不隐含 minor——新增的小能力照常按 patch 登记，无需例外申报
+- **不得为凑版本号降级**：确属「全新大功能 / 独立新能力」的改动不得为对齐目标版本号而按 patch 记；`重大：`（破坏性）不可降至 patch
+- 条目须**分条登记用户可感知的变更**——新增命令 / 参数分开列，不写抽象能力名（否则用户升级后不知多了什么）
+
+## 3. 多语言扩展
+
+每种语言约定四段结构：
+
+- `groups`（可选）：语义分组表，每项 `{ slot, title, prefixes? }`——`slot` 取自全局语义槽位，`title` 为本语言组标题，`prefixes` 为本语言自有前缀（可选，识别时与全局前缀表取并集）；缺省时退化为纯替换（仅 `replacements` 生效）
+- `replacements`：兜底替换映射表（源标题 → 目标标题）
+- `deps`：依赖更新条目固定文案
+- `released`：发布日期行后缀（中文为「发布」，英文为「released」；同时用于识别既有日期行，故自定义语言填非「发布/released」值也能幂等）
+
+新增语言时先补全四段，再按映射转换标题、润色条目。

package/skills/fxri-session-recap/SKILL.md

@@ -1,143 +1,143 @@
----
-name: fxri-session-recap
-description: 会话收尾的工作记忆沉淀 + 新会话开场恢复 + 历史任务时间修正：收尾时把整场会话的全部任务完整建档归档，按四级时间源还原真实完成时间，沉淀规范进 conventions 载体；新会话开场按三层恢复（全量索引 + active 精读 + 近窗归档）重建现场并核对规范；也可批量修正历史归档时间。当用户表达会话收尾意图（如今天先到这、收个尾、归档本次会话、把结论记下来）、接续意图（如恢复上下文、继续上次、上次做到哪）、或修正历史任务时间时使用。不用于会话中途的常规方案建档（那是 fxri-plan-to-task 的职责）、与工作交接无关的代码技术总结。
-license: MIT
-metadata:
-  version: "1.4.1"
-  author: fxri
-  source: https://github.com/fxri-net/toolkit
----
-
-# 会话归档、上下文恢复与历史修正
-
-> 本技能版本 1.4.1（随 @fxri/toolkit 同批分发）。被问版本时即报此值——不读磁盘、不跑 CLI：报出的值就是本会话上下文里已加载内容的版本，可与 `toolkit skills status` 打印的磁盘基准值对照，不一致即说明会话上下文已过期，开新会话即可。
-
-## 何时使用
-
-- **沉淀模式（模式一）**：会话接近尾声，用户表达收尾意图——「今天先到这 / 收个尾 / 先这样吧 / 把结论记下来 / 归档本次会话 / 总结本次」，或其近义表达（不要求字面一致）
-- **恢复模式（模式二）**：新会话开场，用户表达接续意图——「恢复上下文 / 继续上次 / 上次做到哪了 / 接着上次的干」，或其近义表达
-- **修正模式（模式三）**：用户发现历史任务时间不准，要批量修正——「修正历史任务时间 / 历史归档时间不对」
-- ⚠️ 触发识别靠语义不靠字面：用户说「收个尾」可能指收尾工作也可能指会话收尾，需结合上下文判断；无法判断时向用户确认，不猜
-
-**何时不使用**：会话中途的常规方案建档与归档（fxri-plan-to-task）；对某段代码的技术总结（与会话交接无关，不落 .tasks）；日常对话。
-
-## 能力边界
-
-- 所有 agent 的共性约束：新会话读不到其他会话的内部上下文，对话记录本身不可跨会话传递
-- 本技能解法是把记忆**沉淀进仓库文件**（`.tasks/`）；个别 agent 可直读历史会话转录，属非通用高级路径，不依赖
-- 本技能**不直接执行 git 提交**：归档 + 沉淀即流程终点，提交/推送/发版由用户全局规则决定（见「收尾边界」）
-
-## 核心规则（先读这段）
-
-### R1 四级时间源（沉淀一切时间字段的唯一口径）
-
-「会话当时的真实时间」不可凭空估算。任何时间字段（created/completed/updated）按以下优先级取证：
-
-| 级 | 时间源 | 取证 | 适用 |
-| --- | --- | --- | --- |
-| 0 | 任务完成当场打点 | 任务完成时立即执行命令取时间（Windows `Get-Date -Format "yyyy-MM-dd HH:mm"`，macOS/Linux `date "+%Y-%m-%d %H:%M"`） | 会话内即时归档（首选，源头消灭补记） |
-| 1 | 聊天记录可见的准确时间戳 | 用户贴过的日志/终端输出时间戳、用户口述的确定时刻 | 收尾补档且上下文有可信时间 |
-| 2 | 任务改动的 git 提交时间 | `git log --format="%h %ci" <file>` 按提交时间取证 | 任务有对应提交 |
-| 3 | 系统当前时间兜底 | 当场执行命令取时，**正文标注「时间为收尾补记」** | 前三级皆不可得 |
-
-规则：
-- 第 3 级是兜底不是默认——能用前三级必须用；用第 3 级必须显式标注，避免「看似精确实则编造」的时间
-- 归档块完成时间可以早于归档动作时间，这是特性不是异常（补档/历史修正场景）
-- 完成时间晚于当前系统时间或恰为零点整会被 CLI 告警，说明时间源取错，需重新取证（前者含跨时区容差：晚于当前时刻 14 小时以上才告警）
-
-### R2 统一收尾链路（能力终点 = 沉淀）
-
-```
-任务终结 → 归档 → 规范沉淀（硬终点） → 验收 → 提交/发版/推送（可选，需用户确认）
-```
-
-- 归档是中间步骤，**规范沉淀才是流程终点**
-- 沉淀时机固定：归档完成后、任何收尾动作（验收 / 提交 / 发版 / 推送）前，规范与归档文件同批落盘
-- ⚠️ **验收须晚于归档**：归档会改写 `.tasks/`，且归档本身不做阻断式校验——早于归档跑验收就覆盖不到终态，归档产物等于无人校验；归档块「完成情况」只记改动事实与所用验证命令，不逐条抄写验收输出
-- 提交、发版、推送**不是必经步骤**，是否执行取决于用户全局/个人/项目规则；若提交代码：先归档、后跑项目验收命令、再提交，归档文件与代码变更落在同一 git 提交
-- **动作不算、改动才算**：收尾动作（提交、发版、推送、部署）本身及其固有产物（版本号、更新日志、标签）不构成任务、不单独建档；其所依据的改动须有归档记录，缺则补档
-- **跨仓库会话各自归档**：整场会话涉及多个仓库时，各仓的改动在**各自仓库**里建档归档（任务档是仓库自述，只记本仓的改动与动机）；不因「同一次会话」而把另一仓的工作痕迹合并进本仓记录，`scope` 只标本仓内的端 / 面
-
-### R3 规范落点：`.tasks/conventions/` 载体（两级沉淀同一载体）
-
-- 唯一落点 `.tasks/conventions/`（纯 Markdown 随 git 走）：`index.md` 唯一入口（形态标记 + 端清单 + 活跃索引表，首列为稳定 ID `C-<n>`），`history.md` 承载语义演进记录（独立文件、仅追加），`retired.md` 承载退休台账（条目作废时迁入、冻结语义，按需创建），`common.md` 承载所有端通用条文，`<端名>.md`（或分类标签分册）承载各端专属条文；每条规范带来源任务与日期，可审计
-- **任务级**（fxri-plan-to-task 归档时）：单任务产出可升格规范才追加，无则完全静默
-- **会话级**（本技能收尾时）：聚合全会话候选，与已有规范**合并去重**——跨任务重复模式在此补，用户明示规则兜底
-- **归属判定**：先问「是否**所有端都适用**」→ 是则归 `common`；否则逐端确认后写入命中的端分册。⚠️ 禁止跨端合并归属（真全端才升 `common`，只适用几端则各端各记一条）；`common` 的语义是「所有端」不是「不确定归哪端」的暂存区
-- **端名**：与任务 frontmatter `scope` 取值**逐字一致**（任务写 `scope: web+server` → 读 `web.md` + `server.md`，无论命中与否**恒叠加 `common.md`**；`scope` 中非端值且存在同名分册者按分类标签分册加载）；`index.md` 顶部「端清单」是端的**唯一权威**，不扫目录
-- 写前**必须用户确认**；同义规范不重复记录，只补差异或合并增强
-- **表格形态**：载体与任务区表格一律**紧凑形态**（单元格间只留一个空格，不做列对齐填充）；手工写表不为对齐补空格，已有填充用 `toolkit conventions format` 归一（幂等、跳过代码块、不改语义），源头由 `toolkit init` 托管的 `.prettierignore` 排除任务区
-- 一次性决策留在任务正文，不进规范（升格标准：重复出现 ≥2 次，或用户明示「以后都要这样」）
-- **内容修订 vs 形态迁移**：语义变更走「`history.md` 追加留痕 + index 行更新」；条目作废走**迁出 + 三层清理**（索引行删除并迁入 `retired.md` 冻结语义、物理删除分册内该条小节、外部单一事实源同步删改，不留「已废弃」占位）；使用者项目存旧单文件 `conventions.md` 且要求迁移时走**迁移三段式**（建目录搬原文 → 逐条提归属建议 → 用户确认后拆分册）；载体为 v1 / v2（无首行形态标记，或标记为 `v2` / 索引表首列非 `ID` / 缺 `history.md`）时走 **v1 / v2→v3 升级**——优先 `toolkit conventions upgrade`（可 `--dry-run` 预演），亦可按链路手工执行；均可中断不丢内容；已成 v3 标记却残留 v2 独有列（「状态」「确立来源任务」）或 `history.md` / `retired.md` 表头首格非 `ID` 者属**形态残留**（非升级触发），`toolkit tasks check` / `toolkit conventions status` 软告警提示人工归一
-- ⚠️ 兼容读：先找 `conventions/index.md`，不存在再看旧单文件 `conventions.md`（提示可迁移）；两者并存时以目录形态为准
-- 完整细则（三分区结构、形态标记与稳定 ID、`index.md` 表列定义、`history.md` / `retired.md` 结构、分层读写判定、内容修订、表格形态（紧凑）、两种形态、迁移与 v1 / v2→v3 升级步骤、自查清单）见 `../fxri-plan-to-task/references/conventions-spec.md`；fxri-plan-to-task 未一并安装、该兄弟路径不存在时，改读包内真源——`toolkit skills status` 打印的「技能源」目录下 `fxri-plan-to-task/references/conventions-spec.md`
-
-### 规范提炼子流程（三模式共用）
-
-1. 对照 conventions 载体收集候选：会话中用户明示的规则、与已有规范重复印证的决策、跨任务重复模式
-2. 输出候选清单（每条含来源任务、建议归属与理由），交用户确认
-3. 用户确认后写入载体：`index.md` 补索引行（首列稳定 ID `C-<n>` / 归属），条文归位到 `common.md` 或命中的端分册 / 分类标签分册；语义变更先在 `history.md` 追加一行留痕，条目作废按三层清理迁入 `retired.md`
-4. 无候选时完全静默，不强加流程
-
-## 模式一：沉淀本次会话
-
-> 目标：会话结束后，任何人（或新会话 AI）只看仓库就能还原本次做了什么、为什么、还剩什么，且时间与会话真实发生时刻一致。
-
-1. **全量回放**：按时间线完整回放本会话，产出**全部任务候选清单**（含结论、决策及理由、代码改动、未尽事项、用户明示要求记录的内容；与工作产出无关的闲聊不记）。⚠️ 决策及其理由必须记——决策散在对话里，会话一关就丢
-2. **事前核对（新增，防漏档的关口）**：把任务候选清单（每条附时间证据来源：0/1/2/3 级）**先输出给用户确认无遗漏**，确认后才开始落盘——用户切会话漏档的痛点在结构上解决
-3. **逐条落盘**（先查后写；格式与目录规范见 `../fxri-plan-to-task/references/task-spec.md`；fxri-plan-to-task 未一并安装、该兄弟路径不存在时，改读包内真源——`toolkit skills status` 打印的「技能源」目录下 `fxri-plan-to-task/references/task-spec.md`）：
-   - 会话工作有对应任务 → 更新原文件：正文追加结论与决策，时间字段按 R1 校准
-   - 无对应任务但有独立成果 → 按 fxri-plan-to-task 规范建档，created 取任务真实创建日
-   - 未尽事项 → 拆独立任务文件（status: 待办），不在正文留游离待办
-   - 收尾动作（提交、发版、推送、部署）本身及其固有产物（版本号、更新日志、标签）不单独成档；其所依据的改动缺归档记录时须补档
-4. **归档**：终结态任务按 task-spec「手工归档步骤」执行（合并归档块 → 降序重排 → 写回 → 删源文件 → 清理空月份目录），或 `toolkit tasks archive` 自动化
-5. **规范沉淀（终点）**：按「规范提炼子流程」执行会话级提炼，写入 conventions 载体
-6. **收尾边界**：沉淀即本技能流程终点。提交、发版、推送不是必经步骤，是否执行取决于用户规则；⚠️ 验收须晚于归档——若提交代码，先归档、再跑项目验收命令、后提交，任务归档文件 + conventions 载体与本次代码变更落在**同一个 git 提交**；提交前向用户展示待提交内容供确认
-7. **回报**：向用户列出本次沉淀的任务清单、归档位置与规范变更，确认无遗漏后再结束
-
-## 模式二：恢复上下文
-
-> 目标：新会话快速重建现场。恢复范围覆盖全部任务（含已归档），但按层级控制上下文成本。
-
-1. **L0 全量索引**：`toolkit tasks --view all`（无 CLI 时读目录）——active 全部 + archived 全部历史一行一条 + `toolkit tasks stats` 周期统计；一眼看清全貌，不漏任何历史任务
-2. **L1 工作层精读**：逐文件读 `.tasks/active/` 全部任务（决策、进展、阻塞）。⚠️ **搁置识别**：active 任务 `updated` 距今 >1 年时标注「疑似搁置（距今 X 年）」，建议用户确认收尾或放弃，不当「进行中」呈现
-3. **L2 近窗精读**：读最近归档。**近窗按时间连续性判定，不按数量**：先定位最新归档块的完成时间，只精读从该时刻向前连续活跃的归档（归档月份 ≤ 6 个月或归档块 ≤ 200 条时精读全文）；**被 ≥1 年空洞隔断的旧归档一律只入 L0 索引，不精读、不列为「最近完成」**；超阈值降级为统计（按月/负责人汇总 + 近期明细），防止历史膨胀撑爆上下文
-4. **按需拉取**：更早历史（含空洞隔断的旧归档）不主动展开，在 L0 索引可见；用户点名、或 AI 判断相关时用 `--owner`/`--date` 过滤检索；用户明确说「全部恢复」才全量列出
-5. **规范核对与提炼**：读 conventions 载体（存在时）纳入现场——常驻只读 `index.md`（`history.md` 与各分册按需读），再按任务 `scope` 命中加载 `common.md` 与端分册；载体为 v1 或 `check` / `toolkit conventions status` 报形态告警时提示用户可升级；对照近期任务按「规范提炼子流程」提议增改——⚠️ 恢复主体只读，写载体是用户确认后的独立动作
-6. **输出**：全部任务索引摘要 → 进行中/阻塞任务（含搁置标注）→ 最近完成（连续活跃期内，不含空洞旧档）→ 未完事项 → 规范现场 → **建议的下一步**
-7. 全程不写任务区文件；对存疑内容向用户确认后再动
-
-## 模式三：批量修正历史任务时间
-
-> 目标：旧规则沉淀的归档时间与真实发生时刻不符时批量修正。识别靠证据，CLI 只做结构迁移不推断时间。
-
-1. **取证**：对照 git log（`git log --format="%h %ci"`）与聊天记录时间戳，列出疑似错时任务清单，每条附证据（属于 R1 哪一级）
-2. **确认**：清单交用户逐条确认正确时间，不自行推断
-3. **改值**：active 任务直接改文件 completed；已归档任务改归档块元数据行的完成时间
-4. **迁移核验**：`toolkit tasks normalize --fix` 自动把改动后的归档块迁移到正确日期文件（已完成能力：按 completed 合并降序、清理空文件空目录）；再 `toolkit tasks normalize` 只读核验 0 漂移
-5. **规范观察**：批量回读历史任务时发现的重复模式，按「规范提炼子流程」列为候选（确认后写入载体，与修正动作同批）
-6. **收尾边界**：同上（沉淀终点，提交可选需确认）
-
-## 失败模式
-
-| 症状 | 处置 |
-| --- | --- |
-| 会话收尾时多个任务混在一起说不清 | 按任务逐条对应拆开写；对应不上的问用户 |
-| 未尽事项塞进已完成任务正文 | 必须拆独立任务，保持已完成任务归档块干净 |
-| completed 填了收尾时刻而非真实完成时刻 | 按 R1 四级时间源重新取证（git log / 聊天记录时间戳） |
-| 恢复时 active 有游离文件（不在月份目录） | 先按规范移入 `active/{YYYYMM}/` 再读 |
-| 归档历史量太大撑爆上下文 | 走 L2 降级：只出统计 + 近期明细，按需拉取更早 |
-| 新会话仍说「找不到上下文」 | 先查磁盘文件是否存在、是否落在正确月份目录、conventions 载体是否同目录；跨环境场景（换机 / 工作区被 git 清理）才需查是否已 git 提交 |
-| 归档未提交，新会话能恢复吗 | 同机同目录**能恢复**（恢复读磁盘 `.tasks/` 文件，与提交状态无关）；仅跨环境（换机 / checkout、clean 清掉工作区）时未提交内容会丢，恢复才依赖提交 |
-
-## 可选加速（不构成依赖）
-
-⚠️ 工具探测顺序（先项目内、后全局）：先 `pnpm exec toolkit --help`（项目 devDependency，npm 项目等价 `npx toolkit`），失败再 `toolkit --help`（全局安装）；两者都不可用即工具未安装，按各步手工继续，**不安装、不阻塞**。探测成功后用对应前缀执行下列命令：
-
-- `toolkit tasks`：模式二 L0 全量索引（替代人工翻目录）
-- `toolkit tasks stats`：模式二周期统计
-- `toolkit tasks archive`：模式一第 4 步自动化（含排他锁防并发；可 `--dry-run` 预演）
-- `toolkit tasks normalize`：模式三迁移核验（`--fix` 迁移 / 只读检查）
-- `toolkit tasks check`：落盘后校验
-- 任务目录非默认 `.tasks` 时加 `--dir <path>`
-- `toolkit skills install` / `toolkit skills status`：把本包 fxri-* 技能分发到目标技能目录（`--scope` 缺省按 CLI 安装位置自动判定全局面 / 项目面；项目面真源落 `<仓库根>/.agents/skills/`、其余候选目录落入口薄壳，随仓库入库后队友 clone 即用）/ 查看链接、副本与项目面现场（技能随包同源分发，与 CLI 同一发布批次；技能内容版本独立编号，`skills status` 会打印各技能真源版本）
+---
+name: fxri-session-recap
+description: 会话收尾的工作记忆沉淀 + 新会话开场恢复 + 历史任务时间修正：收尾时把整场会话的全部任务完整建档归档，按四级时间源还原真实完成时间，沉淀规范进 conventions 载体；新会话开场按三层恢复（全量索引 + active 精读 + 近窗归档）重建现场并核对规范；也可批量修正历史归档时间。当用户表达会话收尾意图（如今天先到这、收个尾、归档本次会话、把结论记下来）、接续意图（如恢复上下文、继续上次、上次做到哪）、或修正历史任务时间时使用。不用于会话中途的常规方案建档（那是 fxri-plan-to-task 的职责）、与工作交接无关的代码技术总结。
+license: MIT
+metadata:
+  version: "1.4.1"
+  author: fxri
+  source: https://github.com/fxri-net/toolkit
+---
+
+# 会话归档、上下文恢复与历史修正
+
+> 本技能版本 1.4.1（随 @fxri/toolkit 同批分发）。被问版本时即报此值——不读磁盘、不跑 CLI：报出的值就是本会话上下文里已加载内容的版本，可与 `toolkit skills status` 打印的磁盘基准值对照，不一致即说明会话上下文已过期，开新会话即可。
+
+## 何时使用
+
+- **沉淀模式（模式一）**：会话接近尾声，用户表达收尾意图——「今天先到这 / 收个尾 / 先这样吧 / 把结论记下来 / 归档本次会话 / 总结本次」，或其近义表达（不要求字面一致）
+- **恢复模式（模式二）**：新会话开场，用户表达接续意图——「恢复上下文 / 继续上次 / 上次做到哪了 / 接着上次的干」，或其近义表达
+- **修正模式（模式三）**：用户发现历史任务时间不准，要批量修正——「修正历史任务时间 / 历史归档时间不对」
+- ⚠️ 触发识别靠语义不靠字面：用户说「收个尾」可能指收尾工作也可能指会话收尾，需结合上下文判断；无法判断时向用户确认，不猜
+
+**何时不使用**：会话中途的常规方案建档与归档（fxri-plan-to-task）；对某段代码的技术总结（与会话交接无关，不落 .tasks）；日常对话。
+
+## 能力边界
+
+- 所有 agent 的共性约束：新会话读不到其他会话的内部上下文，对话记录本身不可跨会话传递
+- 本技能解法是把记忆**沉淀进仓库文件**（`.tasks/`）；个别 agent 可直读历史会话转录，属非通用高级路径，不依赖
+- 本技能**不直接执行 git 提交**：归档 + 沉淀即流程终点，提交/推送/发版由用户全局规则决定（见「收尾边界」）
+
+## 核心规则（先读这段）
+
+### R1 四级时间源（沉淀一切时间字段的唯一口径）
+
+「会话当时的真实时间」不可凭空估算。任何时间字段（created/completed/updated）按以下优先级取证：
+
+| 级 | 时间源 | 取证 | 适用 |
+| --- | --- | --- | --- |
+| 0 | 任务完成当场打点 | 任务完成时立即执行命令取时间（Windows `Get-Date -Format "yyyy-MM-dd HH:mm"`，macOS/Linux `date "+%Y-%m-%d %H:%M"`） | 会话内即时归档（首选，源头消灭补记） |
+| 1 | 聊天记录可见的准确时间戳 | 用户贴过的日志/终端输出时间戳、用户口述的确定时刻 | 收尾补档且上下文有可信时间 |
+| 2 | 任务改动的 git 提交时间 | `git log --format="%h %ci" <file>` 按提交时间取证 | 任务有对应提交 |
+| 3 | 系统当前时间兜底 | 当场执行命令取时，**正文标注「时间为收尾补记」** | 前三级皆不可得 |
+
+规则：
+- 第 3 级是兜底不是默认——能用前三级必须用；用第 3 级必须显式标注，避免「看似精确实则编造」的时间
+- 归档块完成时间可以早于归档动作时间，这是特性不是异常（补档/历史修正场景）
+- 完成时间晚于当前系统时间或恰为零点整会被 CLI 告警，说明时间源取错，需重新取证（前者含跨时区容差：晚于当前时刻 14 小时以上才告警）
+
+### R2 统一收尾链路（能力终点 = 沉淀）
+
+```
+任务终结 → 归档 → 规范沉淀（硬终点） → 验收 → 提交/发版/推送（可选，需用户确认）
+```
+
+- 归档是中间步骤，**规范沉淀才是流程终点**
+- 沉淀时机固定：归档完成后、任何收尾动作（验收 / 提交 / 发版 / 推送）前，规范与归档文件同批落盘
+- ⚠️ **验收须晚于归档**：归档会改写 `.tasks/`，且归档本身不做阻断式校验——早于归档跑验收就覆盖不到终态，归档产物等于无人校验；归档块「完成情况」只记改动事实与所用验证命令，不逐条抄写验收输出
+- 提交、发版、推送**不是必经步骤**，是否执行取决于用户全局/个人/项目规则；若提交代码：先归档、后跑项目验收命令、再提交，归档文件与代码变更落在同一 git 提交
+- **动作不算、改动才算**：收尾动作（提交、发版、推送、部署）本身及其固有产物（版本号、更新日志、标签）不构成任务、不单独建档；其所依据的改动须有归档记录，缺则补档
+- **跨仓库会话各自归档**：整场会话涉及多个仓库时，各仓的改动在**各自仓库**里建档归档（任务档是仓库自述，只记本仓的改动与动机）；不因「同一次会话」而把另一仓的工作痕迹合并进本仓记录，`scope` 只标本仓内的端 / 面
+
+### R3 规范落点：`.tasks/conventions/` 载体（两级沉淀同一载体）
+
+- 唯一落点 `.tasks/conventions/`（纯 Markdown 随 git 走）：`index.md` 唯一入口（形态标记 + 端清单 + 活跃索引表，首列为稳定 ID `C-<n>`），`history.md` 承载语义演进记录（独立文件、仅追加），`retired.md` 承载退休台账（条目作废时迁入、冻结语义，按需创建），`common.md` 承载所有端通用条文，`<端名>.md`（或分类标签分册）承载各端专属条文；每条规范带来源任务与日期，可审计
+- **任务级**（fxri-plan-to-task 归档时）：单任务产出可升格规范才追加，无则完全静默
+- **会话级**（本技能收尾时）：聚合全会话候选，与已有规范**合并去重**——跨任务重复模式在此补，用户明示规则兜底
+- **归属判定**：先问「是否**所有端都适用**」→ 是则归 `common`；否则逐端确认后写入命中的端分册。⚠️ 禁止跨端合并归属（真全端才升 `common`，只适用几端则各端各记一条）；`common` 的语义是「所有端」不是「不确定归哪端」的暂存区
+- **端名**：与任务 frontmatter `scope` 取值**逐字一致**（任务写 `scope: web+server` → 读 `web.md` + `server.md`，无论命中与否**恒叠加 `common.md`**；`scope` 中非端值且存在同名分册者按分类标签分册加载）；`index.md` 顶部「端清单」是端的**唯一权威**，不扫目录
+- 写前**必须用户确认**；同义规范不重复记录，只补差异或合并增强
+- **表格形态**：载体与任务区表格一律**紧凑形态**（单元格间只留一个空格，不做列对齐填充）；手工写表不为对齐补空格，已有填充用 `toolkit conventions format` 归一（幂等、跳过代码块、不改语义），源头由 `toolkit init` 托管的 `.prettierignore` 排除任务区
+- 一次性决策留在任务正文，不进规范（升格标准：重复出现 ≥2 次，或用户明示「以后都要这样」）
+- **内容修订 vs 形态迁移**：语义变更走「`history.md` 追加留痕 + index 行更新」；条目作废走**迁出 + 三层清理**（索引行删除并迁入 `retired.md` 冻结语义、物理删除分册内该条小节、外部单一事实源同步删改，不留「已废弃」占位）；使用者项目存旧单文件 `conventions.md` 且要求迁移时走**迁移三段式**（建目录搬原文 → 逐条提归属建议 → 用户确认后拆分册）；载体为 v1 / v2（无首行形态标记，或标记为 `v2` / 索引表首列非 `ID` / 缺 `history.md`）时走 **v1 / v2→v3 升级**——优先 `toolkit conventions upgrade`（可 `--dry-run` 预演），亦可按链路手工执行；均可中断不丢内容；已成 v3 标记却残留 v2 独有列（「状态」「确立来源任务」）或 `history.md` / `retired.md` 表头首格非 `ID` 者属**形态残留**（非升级触发），`toolkit tasks check` / `toolkit conventions status` 软告警提示人工归一
+- ⚠️ 兼容读：先找 `conventions/index.md`，不存在再看旧单文件 `conventions.md`（提示可迁移）；两者并存时以目录形态为准
+- 完整细则（三分区结构、形态标记与稳定 ID、`index.md` 表列定义、`history.md` / `retired.md` 结构、分层读写判定、内容修订、表格形态（紧凑）、两种形态、迁移与 v1 / v2→v3 升级步骤、自查清单）见 `../fxri-plan-to-task/references/conventions-spec.md`；fxri-plan-to-task 未一并安装、该兄弟路径不存在时，改读包内真源——`toolkit skills status` 打印的「技能源」目录下 `fxri-plan-to-task/references/conventions-spec.md`
+
+### 规范提炼子流程（三模式共用）
+
+1. 对照 conventions 载体收集候选：会话中用户明示的规则、与已有规范重复印证的决策、跨任务重复模式
+2. 输出候选清单（每条含来源任务、建议归属与理由），交用户确认
+3. 用户确认后写入载体：`index.md` 补索引行（首列稳定 ID `C-<n>` / 归属），条文归位到 `common.md` 或命中的端分册 / 分类标签分册；语义变更先在 `history.md` 追加一行留痕，条目作废按三层清理迁入 `retired.md`
+4. 无候选时完全静默，不强加流程
+
+## 模式一：沉淀本次会话
+
+> 目标：会话结束后，任何人（或新会话 AI）只看仓库就能还原本次做了什么、为什么、还剩什么，且时间与会话真实发生时刻一致。
+
+1. **全量回放**：按时间线完整回放本会话，产出**全部任务候选清单**（含结论、决策及理由、代码改动、未尽事项、用户明示要求记录的内容；与工作产出无关的闲聊不记）。⚠️ 决策及其理由必须记——决策散在对话里，会话一关就丢
+2. **事前核对（新增，防漏档的关口）**：把任务候选清单（每条附时间证据来源：0/1/2/3 级）**先输出给用户确认无遗漏**，确认后才开始落盘——用户切会话漏档的痛点在结构上解决
+3. **逐条落盘**（先查后写；格式与目录规范见 `../fxri-plan-to-task/references/task-spec.md`；fxri-plan-to-task 未一并安装、该兄弟路径不存在时，改读包内真源——`toolkit skills status` 打印的「技能源」目录下 `fxri-plan-to-task/references/task-spec.md`）：
+   - 会话工作有对应任务 → 更新原文件：正文追加结论与决策，时间字段按 R1 校准
+   - 无对应任务但有独立成果 → 按 fxri-plan-to-task 规范建档，created 取任务真实创建日
+   - 未尽事项 → 拆独立任务文件（status: 待办），不在正文留游离待办
+   - 收尾动作（提交、发版、推送、部署）本身及其固有产物（版本号、更新日志、标签）不单独成档；其所依据的改动缺归档记录时须补档
+4. **归档**：终结态任务按 task-spec「手工归档步骤」执行（合并归档块 → 降序重排 → 写回 → 删源文件 → 清理空月份目录），或 `toolkit tasks archive` 自动化
+5. **规范沉淀（终点）**：按「规范提炼子流程」执行会话级提炼，写入 conventions 载体
+6. **收尾边界**：沉淀即本技能流程终点。提交、发版、推送不是必经步骤，是否执行取决于用户规则；⚠️ 验收须晚于归档——若提交代码，先归档、再跑项目验收命令、后提交，任务归档文件 + conventions 载体与本次代码变更落在**同一个 git 提交**；提交前向用户展示待提交内容供确认
+7. **回报**：向用户列出本次沉淀的任务清单、归档位置与规范变更，确认无遗漏后再结束
+
+## 模式二：恢复上下文
+
+> 目标：新会话快速重建现场。恢复范围覆盖全部任务（含已归档），但按层级控制上下文成本。
+
+1. **L0 全量索引**：`toolkit tasks --view all`（无 CLI 时读目录）——active 全部 + archived 全部历史一行一条 + `toolkit tasks stats` 周期统计；一眼看清全貌，不漏任何历史任务
+2. **L1 工作层精读**：逐文件读 `.tasks/active/` 全部任务（决策、进展、阻塞）。⚠️ **搁置识别**：active 任务 `updated` 距今 >1 年时标注「疑似搁置（距今 X 年）」，建议用户确认收尾或放弃，不当「进行中」呈现
+3. **L2 近窗精读**：读最近归档。**近窗按时间连续性判定，不按数量**：先定位最新归档块的完成时间，只精读从该时刻向前连续活跃的归档（归档月份 ≤ 6 个月或归档块 ≤ 200 条时精读全文）；**被 ≥1 年空洞隔断的旧归档一律只入 L0 索引，不精读、不列为「最近完成」**；超阈值降级为统计（按月/负责人汇总 + 近期明细），防止历史膨胀撑爆上下文
+4. **按需拉取**：更早历史（含空洞隔断的旧归档）不主动展开，在 L0 索引可见；用户点名、或 AI 判断相关时用 `--owner`/`--date` 过滤检索；用户明确说「全部恢复」才全量列出
+5. **规范核对与提炼**：读 conventions 载体（存在时）纳入现场——常驻只读 `index.md`（`history.md` 与各分册按需读），再按任务 `scope` 命中加载 `common.md` 与端分册；载体为 v1 或 `check` / `toolkit conventions status` 报形态告警时提示用户可升级；对照近期任务按「规范提炼子流程」提议增改——⚠️ 恢复主体只读，写载体是用户确认后的独立动作
+6. **输出**：全部任务索引摘要 → 进行中/阻塞任务（含搁置标注）→ 最近完成（连续活跃期内，不含空洞旧档）→ 未完事项 → 规范现场 → **建议的下一步**
+7. 全程不写任务区文件；对存疑内容向用户确认后再动
+
+## 模式三：批量修正历史任务时间
+
+> 目标：旧规则沉淀的归档时间与真实发生时刻不符时批量修正。识别靠证据，CLI 只做结构迁移不推断时间。
+
+1. **取证**：对照 git log（`git log --format="%h %ci"`）与聊天记录时间戳，列出疑似错时任务清单，每条附证据（属于 R1 哪一级）
+2. **确认**：清单交用户逐条确认正确时间，不自行推断
+3. **改值**：active 任务直接改文件 completed；已归档任务改归档块元数据行的完成时间
+4. **迁移核验**：`toolkit tasks normalize --fix` 自动把改动后的归档块迁移到正确日期文件（已完成能力：按 completed 合并降序、清理空文件空目录）；再 `toolkit tasks normalize` 只读核验 0 漂移
+5. **规范观察**：批量回读历史任务时发现的重复模式，按「规范提炼子流程」列为候选（确认后写入载体，与修正动作同批）
+6. **收尾边界**：同上（沉淀终点，提交可选需确认）
+
+## 失败模式
+
+| 症状 | 处置 |
+| --- | --- |
+| 会话收尾时多个任务混在一起说不清 | 按任务逐条对应拆开写；对应不上的问用户 |
+| 未尽事项塞进已完成任务正文 | 必须拆独立任务，保持已完成任务归档块干净 |
+| completed 填了收尾时刻而非真实完成时刻 | 按 R1 四级时间源重新取证（git log / 聊天记录时间戳） |
+| 恢复时 active 有游离文件（不在月份目录） | 先按规范移入 `active/{YYYYMM}/` 再读 |
+| 归档历史量太大撑爆上下文 | 走 L2 降级：只出统计 + 近期明细，按需拉取更早 |
+| 新会话仍说「找不到上下文」 | 先查磁盘文件是否存在、是否落在正确月份目录、conventions 载体是否同目录；跨环境场景（换机 / 工作区被 git 清理）才需查是否已 git 提交 |
+| 归档未提交，新会话能恢复吗 | 同机同目录**能恢复**（恢复读磁盘 `.tasks/` 文件，与提交状态无关）；仅跨环境（换机 / checkout、clean 清掉工作区）时未提交内容会丢，恢复才依赖提交 |
+
+## 可选加速（不构成依赖）
+
+⚠️ 工具探测顺序（先项目内、后全局）：先 `pnpm exec toolkit --help`（项目 devDependency，npm 项目等价 `npx toolkit`），失败再 `toolkit --help`（全局安装）；两者都不可用即工具未安装，按各步手工继续，**不安装、不阻塞**。探测成功后用对应前缀执行下列命令：
+
+- `toolkit tasks`：模式二 L0 全量索引（替代人工翻目录）
+- `toolkit tasks stats`：模式二周期统计
+- `toolkit tasks archive`：模式一第 4 步自动化（含排他锁防并发；可 `--dry-run` 预演）
+- `toolkit tasks normalize`：模式三迁移核验（`--fix` 迁移 / 只读检查）
+- `toolkit tasks check`：落盘后校验
+- 任务目录非默认 `.tasks` 时加 `--dir <path>`
+- `toolkit skills install` / `toolkit skills status`：把本包 fxri-* 技能分发到目标技能目录（`--scope` 缺省按 CLI 安装位置自动判定全局面 / 项目面；项目面真源落 `<仓库根>/.agents/skills/`、其余候选目录落入口薄壳，随仓库入库后队友 clone 即用）/ 查看链接、副本与项目面现场（技能随包同源分发，与 CLI 同一发布批次；技能内容版本独立编号，`skills status` 会打印各技能真源版本）