@fxri/toolkit 1.12.2 → 1.12.4

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 发布
+
+### 🐛 问题修复
+
+- 金额计算精度丢失
+
+### 📦 其他变更
+
+- 补齐某处兜底逻辑
+```
+
+规则：
+
+- 版本标题 `## {版本号}`；隔一行后接引用行 `> {YYYY-MM-DD} 发布`（标题与日期行之间保留一个空行）
+- 分组标题 = emoji + 组名，一行一组，按**语义分组顺序**输出——重大变更 → 新增功能 → 功能调整 → 优化改进 → 问题修复 → 文档更新 → 清理移除 → 依赖变更 → 其他变更；空组省略
+- 条目一行一条，每条**须以 `- ` 列表标记开头**（仅 `- ` 列表项被逐条收录）；项目语言句式（中文条目句末不加句号），与仓库既有风格一致
+- ⚠️ **务必逐条写成 `- 类型：描述`**：变更集正文里列 0 起首、无 `- ` 标记的裸行会被 changesets 并入相邻条目作缩进续行——整段正文塌成**单一条目**，只有首行参与前缀识别与归类，其余行既不归组也不剥前缀，最终全挤在首行所属的单组里（本仓 v1.12.0 块的成因）；自查入口见 §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,135 @@
----
-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.6.0"
+  author: fxri
+  source: https://github.com/fxri-net/toolkit
+---
+
+# 会话归档、上下文恢复与历史修正
+
+> 本技能版本 1.6.0（随 @fxri/toolkit 同批分发）。被问版本时即报此值（不读磁盘、不跑 CLI）；与 `toolkit skills status` 的磁盘值不一致即说明会话上下文已过期，开新会话即可。
+
+## 何时使用
+
+- **沉淀模式（模式一）**：会话接近尾声，用户表达收尾意图（如「今天先到这 / 收个尾 / 把结论记下来 / 归档本次会话」）
+- **恢复模式（模式二）**：新会话开场，用户表达接续意图（如「恢复上下文 / 继续上次 / 上次做到哪了」）
+- **修正模式（模式三）**：用户发现历史任务时间不准，要批量修正
+- ⚠️ 触发识别靠语义不靠字面（完整触发词见 frontmatter `description`）：用户说「收个尾」可能指收尾工作也可能指会话收尾，需结合上下文判断；无法判断时向用户确认，不猜
+
+**何时不使用**：会话中途的常规方案建档与归档（fxri-plan-to-task）；对某段代码的技术总结（与会话交接无关，不落 .tasks）；日常对话。
+
+## 能力边界
+
+- 所有 agent 的共性约束：新会话读不到其他会话的内部上下文，对话记录本身不可跨会话传递
+- 本技能解法是把记忆**沉淀进仓库文件**（`.tasks/`）；个别 agent 可直读历史会话转录，属非通用高级路径，不依赖
+- 本技能**不直接执行 git 提交**：提交/推送/发版由用户全局规则决定（见 R2）
+
+## 核心规则（先读这段）
+
+### 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，或已成 v3 却残留 v2 独有列 / 表头首格非 `ID` 的**形态残留**时，一律按 `conventions-migration.md` 的迁移与升级链路处置（可中断不丢内容）
+- ⚠️ 兼容读：先找 `conventions/index.md`，不存在再看旧单文件 `conventions.md`（提示可迁移）；两者并存时以目录形态为准
+- 完整细则（三分区结构、形态标记与稳定 ID、表列定义、分层读写判定、修订与迁移步骤、自查清单）见 `../fxri-plan-to-task/references/conventions-spec.md`；形态判据、迁移与升级步骤见同目录 `conventions-migration.md`，文风模板见 `conventions-templates.md`；兄弟路径不存在时改读包内真源——`toolkit skills status` 打印的「技能源」目录下同名文件
+
+### 规范提炼子流程（三模式共用）
+
+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: 待办），不在正文留游离待办
+   - 收尾动作及其固有产物不单独成档，所依据改动缺归档时须补档（见 R2）
+4. **归档**：终结态任务按 task-spec「手工归档步骤」执行（合并归档块 → 降序重排 → 写回 → 删源文件 → 清理空月份目录），或 `toolkit tasks archive` 自动化
+5. **规范沉淀（终点）**：按「规范提炼子流程」执行会话级提炼，写入 conventions 载体
+6. **收尾边界**：沉淀即本技能流程终点，提交、发版、推送按用户规则决定（见 R2）；⚠️ 验收须晚于归档；**逐任务交付**——一个任务至少一次提交、允许多次，不得把多个任务攒成一个提交，也不得为凑一次提交塞入无关改动；提交前向用户展示待提交内容供确认
+7. **回报**：向用户列出本次沉淀的任务清单、归档位置与规范变更，确认无遗漏后再结束
+
+## 模式二：恢复上下文
+
+> 目标：新会话快速重建现场，按「全量索引 → active 精读 → 近窗归档」三层控制上下文成本。
+
+- 关键护栏：近窗按**时间连续性**判定不按数量，被 ≥1 年空洞隔断的旧归档只入索引、不精读；active 任务 `updated` 超 1 年标注「疑似搁置」；**恢复主体只读**，写任务区 / 载体须用户确认后另行执行
+- 完整步骤见 `references/mode-2-recovery.md`
+
+## 模式三：批量修正历史任务时间
+
+> 目标：旧规则沉淀的归档时间与真实发生时刻不符时批量修正；识别靠证据，CLI 只做结构迁移、不推断时间。
+
+- 关键护栏：每条改动须附 R1 级别证据并交用户逐条确认，不自行推断；改值后用 `toolkit tasks normalize --fix` 迁移，再以只读模式核验 0 漂移
+- 完整步骤见 `references/mode-3-time-fix.md`
+
+## 失败模式
+
+| 症状 | 处置 |
+| --- | --- |
+| 会话收尾时多个任务混在一起说不清 | 按任务逐条对应拆开写；对应不上的问用户 |
+| 未尽事项塞进已完成任务正文 | 必须拆独立任务，保持已完成任务归档块干净 |
+| completed 填了收尾时刻而非真实完成时刻 | 按 R1 四级时间源重新取证（git log / 聊天记录时间戳） |
+| 恢复时 active 有游离文件（不在月份目录） | 先按规范移入 `active/{YYYYMM}/` 再读 |
+| 归档历史量太大撑爆上下文 | 走 L2 降级：只出统计 + 近期明细，按需拉取更早 |
+| 新会话仍说「找不到上下文」 | 先查磁盘文件是否存在、是否落在正确月份目录、conventions 载体是否同目录；跨环境场景（换机 / 工作区被 git 清理）才需查是否已 git 提交 |
+| 归档未提交，新会话能恢复吗 | 同机同目录**能恢复**（恢复读磁盘 `.tasks/` 文件，与提交状态无关）；仅跨环境（换机 / checkout、clean 清掉工作区）时未提交内容会丢，恢复才依赖提交 |
+| 多仓会话只在一个仓建档 | 按仓库清单逐仓逐任务补建；任务档只记本仓的改动与动机 |
+| 恢复后看不出任务先后 | 有展示型计划表则按表；无表时按各 active 任务正文的「批次 / 计划位置 / 前置」行重建顺序 |
+
+## 可选加速（不构成依赖）
+
+⚠️ 工具探测顺序（先项目内、后全局）：先 `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` 会打印各技能真源版本）

package/skills/fxri-session-recap/references/mode-2-recovery.md

@@ -0,0 +1,13 @@
+# 模式二：恢复上下文
+
+> 由 `../SKILL.md`「模式二」按需加载。时间取证口径见主文件 R1，规范载体结构与提炼流程见主文件 R3 与「规范提炼子流程」，本文件不重复。
+
+> 目标：新会话快速重建现场。恢复范围覆盖全部任务（含已归档），但按层级控制上下文成本。
+
+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` 报形态告警时提示用户可升级（升级链路见 `../../fxri-plan-to-task/references/conventions-migration.md`）；对照近期任务按主文件「规范提炼子流程」提议增改——⚠️ 恢复主体只读，写载体是用户确认后的独立动作
+6. **输出**：全部任务索引摘要 → 进行中/阻塞任务（含搁置标注）→ 最近完成（连续活跃期内，不含空洞旧档）→ 未完事项 → **多任务执行顺序**（会话留有展示型计划表则按表；无表时按各 active 任务正文的「批次 / 计划位置 / 前置」行重建）→ 规范现场 → **建议的下一步**
+7. 全程不写任务区文件；对存疑内容向用户确认后再动

package/skills/fxri-session-recap/references/mode-3-time-fix.md

@@ -0,0 +1,12 @@
+# 模式三：批量修正历史任务时间
+
+> 由 `../SKILL.md`「模式三」按需加载。时间取证口径见主文件 R1（四级时间源），本文件不重复。
+
+> 目标：旧规则沉淀的归档时间与真实发生时刻不符时批量修正。识别靠证据，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. **收尾边界**：同上（沉淀终点，提交可选需确认）