@fxri/toolkit 1.11.6 → 1.11.7

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

@@ -64,7 +64,7 @@
 ```
 
 - **ID**：`C-<n>`（`C` 表 conventions），**去补零、不带端前缀、只追加不重排不回收**；插入或重排不漂移，废弃条目不回收其 ID（容量不是问题，去补零取的是可读性）
-- **引用**：载体内部引用一律行内代码包裹（如 `` `C-17` ``），便于机械匹配；v1 遗留的裸「第 N 条」在升级时改写（见 §9.2）
+- **引用**：载体内部引用一律行内代码包裹（如 `` `C-17` ``），便于机械匹配；v1 遗留的裸「第 N 条」在升级时改写（见 §10.2）
 - **归属**：取值必须 ∈ {`common`} ∪ 端清单，否则为悬空指针（需修正）
 - **状态**：`生效` / `已废弃`；废弃不删行，改状态即可（与「归档任务不可变」同哲学：留痕优于抹除）
 - **单一事实源**：条文正文去哪看。已指向项目现有规则层（AGENTS / 全局规则 / skills）时填指向；条文就在本载体分册内时填分册名（如 `common.md`）
@@ -112,6 +112,7 @@
 - **形态约束**：非空、不含空格、不含路径分隔符（`/ \ : * ? " < > |`）
 - **保留字**：`index`、`common` 不得作端名
 - **风格**：随项目 `scope` 既有写法（`web` / `server` / `admin` / `前端` 均成立），无全局词表——工具无法预知项目端构成，故不硬编码取值
+- **跨仓归属**：跨仓库改造时任务 `scope` 只标本仓内的端 / 面，不写另一仓的端名——任务档是仓库自述（见 `SPEC.md` §0）
 
 ## 5. 读取判定（分层）
 
@@ -146,9 +147,20 @@
 - 规则层源头变更（AGENTS / 全局规则 / skills 条文改了）：同步检查索引对应行当前语义是否需更新，随该变更同批落盘
 - **内部引用一律写 ID**：载体内部互引（用法说明、分册配套说明等）写 `` `C-<n>` ``，不写「第 N 条」——序号随插入重排漂移，ID 不会
 
-## 9. 存量迁移
+## 9. 表格形态（紧凑为规范形态）
 
-### 9.1 旧单文件 → 目录形态（v0 → v1）
+载体内所有表格（`index.md` 端清单与索引表、`history.md` 演进记录、各分册与任务文件表格）一律采用**紧凑形态**：单元格之间只留一个空格（`| 值 | 值 |`），不做列对齐填充。理由：填充出的空白层在渲染预览时不显示，却在纯文本阅读时把表格撑成难读的宽行——紧凑形态在渲染与源码两侧都最易读。
+
+- **填充态来源**：宿主仓库若对任务区跑 prettier，GFM 表格会被**列对齐填充**（按列内最宽单元格补空格）——格式化器的刻意行为，非本工具写入
+- **判据**：任一行去缩进后若 `行 !== "| " + 各单元格以 " | " 相连 + " |"` 即为填充态；同一判据既用于归一写入、也用于体检检出（`src/conventions/compact.ts`）
+- **写入纪律**：手工建档、沉淀、归档时写表一律用紧凑形态，**不为对齐空格手工补齐**；工具自身写入的表格（`init` 骨架、`upgrade` 改写、`archive` 归档块）本就紧凑
+- **豁免托管**：`toolkit init` 检测到宿主疑似用 prettier 时幂等托管 `.prettierignore`、把任务区**整目录**排除，从源头不再被填充（本包源仓库自身、任务区在仓库外或即仓库根、无 prettier 迹象三种情形跳过；末者报告提示「项目启用 prettier 后重跑 `toolkit init` 会自动补上」）
+- **存量归一**：`toolkit conventions format` 把已存在的填充收敛回紧凑形态——只动单元格间距与列对齐填充、**不改语义**，跳过 fenced code block（代码块内原样保留），保留对齐标记（`:---` / `---:`）与行尾符，**幂等**（已紧凑时原样返回并报 `already-compact`），`--dry-run` 只预览行号不写盘；范围为任务区全部 md（载体三件 + `active/` + `archive/`）。**归一不入 `history.md`**——属形态变更、非规范语义变更
+- **检出告警**：`toolkit conventions status` 与 `toolkit tasks check` 对填充态软告警（前者聚合为一条、后者逐文件一条），指向上述两种处置；只报形态、不阻断（`status` 退出码恒 0、`check` 计 warn）
+
+## 10. 存量迁移
+
+### 10.1 旧单文件 → 目录形态（v0 → v1）
 
 触发：`toolkit tasks check` 报旧 `conventions.md` 存在；或用户直接要求迁移。
 
@@ -164,7 +176,7 @@
 - 端清单在迁移时同步建立：从项目已有 `scope` 取值与实际子项目构成归纳，经用户确认写入端清单节
 - 旧文件已不存在时不重复迁移
 
-### 9.2 v1 → v2 结构升级
+### 10.2 v1 → v2 结构升级
 
 触发：`toolkit conventions status` 报「需升级」；`toolkit tasks check` 报形态告警（标为 v2 缺 `history.md` 或索引表首列非 `ID`；有 `history.md` 但首列仍是 `#`）；或用户直接要求升级。
 
@@ -182,11 +194,11 @@
 - `upgrade` 幂等：已是 v2 时原样返回，不做二次改写
 - 手动迁移时按同一动作序执行
 
-## 10. 兼容读（迁移期）
+## 11. 兼容读（迁移期）
 
-读取时先找 `conventions/index.md`；不存在再看旧单文件 `conventions.md`，存在则按旧单文件内容读取并**在对话中提示可迁移**。两者并存时以目录形态为准，并提示旧文件待清理。v1 与 v2 都按目录形态正常读取，形态差异见 §9.2 的判据（`index.md` + `history.md` + 首列 `ID` 为 v2，否则 v1）。
+读取时先找 `conventions/index.md`；不存在再看旧单文件 `conventions.md`，存在则按旧单文件内容读取并**在对话中提示可迁移**。两者并存时以目录形态为准，并提示旧文件待清理。v1 与 v2 都按目录形态正常读取，形态差异见 §10.2 的判据（`index.md` + `history.md` + 首列 `ID` 为 v2，否则 v1）。
 
-## 11. 自查清单
+## 12. 自查清单
 
 - [ ] `index.md` 首行为形态标记（v2 为 `<!-- toolkit-conventions: v2 -->`）
 - [ ] `conventions/` 存在时必有 `index.md`（缺则为形态异常）
@@ -199,4 +211,5 @@
 - [ ] 分册文件与端清单 + `common` 对应，无孤立文件
 - [ ] 旧单文件 `conventions.md` 已迁移（不存在，或已提示待清理）
 - [ ] 有入口壳时其标记与当前 toolkit 一致（落后或无标记可重跑 `toolkit init` 就地更新）、且未被 `.gitignore` 覆盖（否则 `check` / `conventions status` 告警）
+- [ ] 载体与任务区表格为紧凑形态（无列对齐填充；`toolkit conventions format` 可归一，`check` / `conventions status` 会检出）
 - [ ] 规范写入均经用户确认，且带「确立来源任务」

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

@@ -44,7 +44,7 @@ created: 20260902     # 创建日 YYYYMMDD，须等于文件名日期前缀
 updated: 20260902     # 最近更新日 YYYYMMDD
 completed: ''         # 完成时间 YYYY-MM-DD HH:mm；仅终结态必填
 depends_on: []        # 依赖的任务文件名（可带 .md），目标必须存在且不得成环
-scope: app            # 影响范围；多值以半角加号分隔（toolkit+lxgl-web），标签内不使用加号；顿号/逗号列表属误写会触发 check 软告警，中文列表请改用加号
+scope: app            # 影响范围；只标本仓内的端 / 面（跨仓库改造时不含另一仓）；多值以半角加号分隔（web+server），标签内不使用加号；顿号/逗号列表属误写会触发 check 软告警，中文列表请改用加号
 ---
 ```
 
@@ -107,7 +107,8 @@ scope: app            # 影响范围；多值以半角加号分隔（toolkit+lxg
 - **动手前置建档评估**：涉及仓库文件改动的任务，动手前先查 active/archive 判同主题（完整判别表见 SKILL.md 工作流第 1 步）；active 有同主题则更新原文件；archive 有同主题且本次不产生仓库文件改动（重复提议 / 重复执行）则不重复建档，本次产生仓库文件改动（延续 / 扩展 / 重新实现）则重新建档并标注来源链
 - **仓库文件改动口径**：需写入版本控制的工作区文件的增 / 改 / 删（源码、配置、文档、技能、任务区自身均计入）；纯读取、纯执行、纯汇报不计入；拿不准时列出差异问用户，不猜
 - **动作不算，改动才算**：收尾动作（提交、发版、推送、部署）本身及其固有产物（版本号、更新日志、标签）不构成任务、不单独建档；这些动作过程中若出现需改仓库文件才能解决的缺陷（如打包配置错误、发布渠道错误），该修复按普通任务建档
-- **归档块不可变**：已归档块是终结记录（唯一键 + 完成时间已固定），不追加新的工作内容；延续 / 扩展需求走新任务并标注来源链。唯一例外是**事实更正**——后续核实推翻原块结论时，在其正文末尾追加「修订记录」（保留原结论、不动元数据行、附更正时刻与依据），与 conventions 载体「废弃不删行」同属留痕优于抹除
+- **跨仓库改动各自归档（本仓自述）**：任务档是仓库自述，只记本仓的改动与动机；跨仓库是会话属性而非仓库属性，同一会话涉及多仓时各仓各自建档归档，不在一仓记录里承载另一仓的工作痕迹。判据取**视角**（描述的是不是本仓的改动与动机），非词表——依赖包名 / 被调接口名等属本仓事实者照写
+- **归档块不可变**：已归档块是终结记录（唯一键 + 完成时间已固定），不追加新的工作内容；延续 / 扩展需求走新任务并标注来源链。唯一例外是**事实更正**——后续核实推翻原块结论、或协作口径变更导致历史事实字段需更正时，在其正文末尾追加「修订记录」（保留原结论、附更正时刻与依据）；口径变更类更正可改受影响的**事实字段**（如 `scope`），但唯一键 / 完成时间 / 状态 / 负责人仍冻结。与 conventions 载体「废弃不删行」同属留痕优于抹除
 - **验收与 CI 同源，不手写清单**：项目的验收步骤清单只允许一份真源——一条聚合命令（如 `pnpm verify`）背后由脚本定义步骤，本地与全部 CI 流水线共用它；禁止在规则文件、CI 配置里另抄一份步骤枚举。多份手写清单必然漂移，征兆就是「本地自检通过、CI 才报错」，出现该征兆先查清单是否已经漂移
 - 强制约束到**沉淀**为止：归档 + 规范沉淀即流程终点；提交、发版、推送不是必经步骤，是否执行取决于用户的全局 / 个人 / 项目规则；若提交代码，按「归档与沉淀 → 跑项目验收命令 → git commit」的顺序执行，任务记录（归档文件 + conventions 载体）与代码变更落在同一提交
 - **验收须晚于归档**：归档会改写任务区（写归档文件、删 active 源文件、清理空月份目录），而归档本身不做阻断式校验——早于归档跑验收就覆盖不到终态，归档产物等于无人校验。同理，归档块「完成情况」只记改动事实与所用验证命令，不逐条抄写验收输出（归档在前、验收在后，抄结果就成了先写结论后验证）

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

@@ -3,14 +3,14 @@ name: fxri-release-changelog
 description: 基于 changesets 的发版与多语言 CHANGELOG 维护流程：创建变更集、消费发版、把分组标题与条目转为项目语言风格、清理变更集、打标签发布；无 changesets 的项目提供同格式手工模式。当用户表达发版或记录变更意图——含创建变更集、changeset、发版、version、CHANGELOG 格式化等说法及其口语近义表达（如发一版、出个版本、记一下这次改动、生成更新日志）时使用。⚠️ 注意区分：用户说「提交个版本 / 先提交一版 / commit」通常指 git 提交当前改动（走任务收尾后提交），**不是发版**。不用于日常 commit message 撰写、git 提交操作或与发版无关的文档修改。
 license: MIT
 metadata:
-  version: "1.1.7"
+  version: "1.1.8"
   author: fxri
   source: https://github.com/fxri-net/toolkit
 ---
 
 # 发版与 CHANGELOG
 
-> 本技能版本 1.1.7（随 @fxri/toolkit 同批分发）。被问版本时即报此值——不读磁盘、不跑 CLI：报出的值就是本会话上下文里已加载内容的版本，可与 `toolkit skills status` 打印的磁盘基准值对照，不一致即说明会话上下文已过期，开新会话即可。
+> 本技能版本 1.1.8（随 @fxri/toolkit 同批分发）。被问版本时即报此值——不读磁盘、不跑 CLI：报出的值就是本会话上下文里已加载内容的版本，可与 `toolkit skills status` 打印的磁盘基准值对照，不一致即说明会话上下文已过期，开新会话即可。
 
 ## 何时使用
 
@@ -31,7 +31,7 @@ metadata:
 
 ## changesets 流程
 
-1. 记录变更：`npx changeset`（或项目包管理器等价脚本）——**变更描述一律以 `类型：` 前缀开头**（如 `新增：` / `修复：` / `优化：`），并按类型选影响级别（重大→major、新增/修改→minor、优化/修复/清理/文档→patch，完整对照见 `references/changelog-format.md`）。写完可跑 `toolkit tasks check` 早期自查：它扫 `.changeset/` 下待发布变更集，逐文件报出缺前缀条目与条数（免得到发版、变更集源被消费删除后才由 changelog 侧兜底告警——那时已无从补写）
+1. 记录变更：`npx changeset`（或项目包管理器等价脚本）——**变更描述一律以 `类型：` 前缀开头**（如 `新增：` / `修复：` / `优化：`），并按改动的**能力量级**选影响级别（破坏性→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`）时再跑一次同步脚本，否则镜像一致性校验会失败
@@ -57,7 +57,7 @@ metadata:
 | 改动已发布却无归档记录（有提交、无任务档） | 先补归档（fxri-session-recap 模式一）再继续发布后续步骤；发版本身不补建档 |
 | 发版后历史块内出现多余空行（`自举一致性` 类零改动用例失败） | 跑 `toolkit changelog --history format` 归一（**必须带 `--history`**，默认模式不动历史块），再补跑一次镜像页同步脚本 |
 | 格式化时 stderr 报「归类后条目数由 N 降为 M，疑似丢失内容」 | 归类只应搬移条目，减少即疑似丢内容：核对该版本块是否含非纯条目分组（标题下先出现正文）或被保留分组；确认属正常去重可忽略，否则按 references 的归类规则修回 |
-| 一批改动含新增能力 / 参数，却整批按 `修复：` 前缀登记（整块落 `问题修复` 组）——常见于 bump 判定为 patch 时，误以为级别与条目前缀绑定 | 前缀按**变更本身性质**逐条定：新增命令 / 参数 / 产物用 `新增：`、缺陷纠正用 `修复：`。分组只看前缀、与 bump 正交，**patch 也可挂 `新增：`**——仅当改动属「配套修补型」方可在 patch 下用 `新增：` / `修改：`（须在任务档申报、对外不写判定依据），口径见 references 的级别例外 |
+| 一批改动含新增能力 / 参数，却整批按 `修复：` 前缀登记（整块落 `问题修复` 组）——常见于 bump 判定为 patch 时，误以为级别与条目前缀绑定 | 前缀按**变更本身性质**逐条定：新增命令 / 参数 / 产物用 `新增：`、缺陷纠正用 `修复：`。分组只看前缀、与 bump 正交，**patch 也可挂 `新增：`**——bump 按改动的能力量级判（存量能力上的小新增即 patch），口径见 references |
 
 ## 可选加速（不构成依赖）
 

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

@@ -58,19 +58,18 @@
 
 **归类只搬移、不删内容**：归类只重组「纯条目分组」——分组标题下若在首个条目之前出现非空正文，判据不成立，整块保持原样以免丢内容；未参与归位的分组连同标题按原相对顺序附于块末，不臆造归属、不静默丢弃。CLI 在归类前后做条目数自检，减少即告警（正常合并发生在自检之后、不误报）。
 
-**类型 → 建议 bump**（撰写变更集时按此选影响级别）：
+**能力量级 → bump**（撰写变更集时按此选影响级别）——版本号由变更集 frontmatter 的 bump 声明决定，**与条目前缀正交**：前缀只负责把条目归入哪一组，不决定版本号。
 
-| 类型前缀 | 建议 bump |
+| 影响级别 | 判定锚点（按改动的**能力量级**，不按条目前缀） |
 | --- | --- |
-| `重大：` | major |
-| `新增：` / `修改：` | minor |
-| `优化：` / `修复：` / `清理：` / `文档：` | patch |
+| major | 破坏性变更——既有契约 / 行为不兼容 |
+| minor | 新增**全新的大功能 / 独立新能力**——用户升级后获得一整块新的使用方式 |
+| patch | 存量能力上的**修补与增量**——修复、优化、配套补齐，以及新增的**小命令 / 小参数 / 小产物**等，只要不属于「全新大功能」 |
 
-**级别例外口径**（仅涉 `新增：` / `修改：`；人工裁决、无自动门禁）：
+口径要点：
 
-- 类型前缀为 `新增：` / `修改：` 的改动，仅当属「**配套修补型**」——即补原作本应具备的配套（既有能力缺失的配套命令 / 参数 / 忽略规则等），而非独立的新能力——方可按 patch 判定
-- 「**版本号取舍型**」（为凑版本号而记，或主观降级的独立新能力）不适用本口径，仍按上表类型字典的默认级别（`新增：` / `修改：` → minor）
-- 采用例外时须在任务档显式申报「已知与惯例相左」，事后可追溯；对外（变更集正文、CHANGELOG）不写判定依据，只登记变更本身
+- **判 bump 看能力量级、不看前缀**：`新增：` / `修改：` 只表示条目归入「新增功能」/「功能调整」组，不隐含 minor——新增的小能力照常按 patch 登记，无需例外申报
+- **不得为凑版本号降级**：确属「全新大功能 / 独立新能力」的改动不得为对齐目标版本号而按 patch 记；`重大：`（破坏性）不可降至 patch
 - 条目须**分条登记用户可感知的变更**——新增命令 / 参数分开列，不写抽象能力名（否则用户升级后不知多了什么）
 
 ## 3. 多语言扩展

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

@@ -3,14 +3,14 @@ name: fxri-session-recap
 description: 会话收尾的工作记忆沉淀 + 新会话开场恢复 + 历史任务时间修正：收尾时把整场会话的全部任务完整建档归档，按四级时间源还原真实完成时间，沉淀规范进 conventions 载体；新会话开场按三层恢复（全量索引 + active 精读 + 近窗归档）重建现场并核对规范；也可批量修正历史归档时间。当用户表达会话收尾意图（如今天先到这、收个尾、归档本次会话、把结论记下来）、接续意图（如恢复上下文、继续上次、上次做到哪）、或修正历史任务时间时使用。不用于会话中途的常规方案建档（那是 fxri-plan-to-task 的职责）、与工作交接无关的代码技术总结。
 license: MIT
 metadata:
-  version: "1.2.5"
+  version: "1.3.0"
   author: fxri
   source: https://github.com/fxri-net/toolkit
 ---
 
 # 会话归档、上下文恢复与历史修正
 
-> 本技能版本 1.2.5（随 @fxri/toolkit 同批分发）。被问版本时即报此值——不读磁盘、不跑 CLI：报出的值就是本会话上下文里已加载内容的版本，可与 `toolkit skills status` 打印的磁盘基准值对照，不一致即说明会话上下文已过期，开新会话即可。
+> 本技能版本 1.3.0（随 @fxri/toolkit 同批分发）。被问版本时即报此值——不读磁盘、不跑 CLI：报出的值就是本会话上下文里已加载内容的版本，可与 `toolkit skills status` 打印的磁盘基准值对照，不一致即说明会话上下文已过期，开新会话即可。
 
 ## 何时使用
 
@@ -56,6 +56,7 @@ metadata:
 - ⚠️ **验收须晚于归档**：归档会改写 `.tasks/`，且归档本身不做阻断式校验——早于归档跑验收就覆盖不到终态，归档产物等于无人校验；归档块「完成情况」只记改动事实与所用验证命令，不逐条抄写验收输出
 - 提交、发版、推送**不是必经步骤**，是否执行取决于用户全局/个人/项目规则；若提交代码：先归档、后跑项目验收命令、再提交，归档文件与代码变更落在同一 git 提交
 - **动作不算、改动才算**：收尾动作（提交、发版、推送、部署）本身及其固有产物（版本号、更新日志、标签）不构成任务、不单独建档；其所依据的改动须有归档记录，缺则补档
+- **跨仓库会话各自归档**：整场会话涉及多个仓库时，各仓的改动在**各自仓库**里建档归档（任务档是仓库自述，只记本仓的改动与动机）；不因「同一次会话」而把另一仓的工作痕迹合并进本仓记录，`scope` 只标本仓内的端 / 面
 
 ### R3 规范落点：`.tasks/conventions/` 载体（两级沉淀同一载体）
 
@@ -65,10 +66,11 @@ metadata:
 - **归属判定**：先问「是否**所有端都适用**」→ 是则归 `common`；否则逐端确认后写入命中的端分册。⚠️ 禁止跨端合并归属（真全端才升 `common`，只适用几端则各端各记一条）；`common` 的语义是「所有端」不是「不确定归哪端」的暂存区
 - **端名**：与任务 frontmatter `scope` 取值**逐字一致**（任务写 `scope: web+server` → 读 `web.md` + `server.md`）；`index.md` 顶部「端清单」是端的**唯一权威**，不扫目录
 - 写前**必须用户确认**；同义规范不重复记录，只补差异或合并增强
+- **表格形态**：载体与任务区表格一律**紧凑形态**（单元格间只留一个空格，不做列对齐填充）；手工写表不为对齐补空格，已有填充用 `toolkit conventions format` 归一（幂等、跳过代码块、不改语义），源头由 `toolkit init` 托管的 `.prettierignore` 排除任务区
 - 一次性决策留在任务正文，不进规范（升格标准：重复出现 ≥2 次，或用户明示「以后都要这样」）
 - **内容修订 vs 形态迁移**：旧条目过时走「`history.md` 追加留痕 + index 行更新 + 状态置 `已废弃`」（不删行）；使用者项目存旧单文件 `conventions.md` 且要求迁移时走**迁移三段式**（建目录搬原文 → 逐条提归属建议 → 用户确认后拆分册）；载体为 v1（无标记、索引表首列非 ID）时走 **v1→v2 升级**——优先 `toolkit conventions upgrade`（可 `--dry-run` 预演），亦可按链路手工执行；均可中断不丢内容
 - ⚠️ 兼容读：先找 `conventions/index.md`，不存在再看旧单文件 `conventions.md`（提示可迁移）；两者并存时以目录形态为准
-- 完整细则（载体结构、形态标记与稳定 ID、index 表列定义、`history.md` 结构、读写判定、内容修订、两种形态、迁移与 v1→v2 升级步骤、自查清单）见 `../fxri-plan-to-task/references/conventions-spec.md`；fxri-plan-to-task 未一并安装、该兄弟路径不存在时，改读包内真源——`toolkit skills status` 打印的「技能源」目录下 `fxri-plan-to-task/references/conventions-spec.md`
+- 完整细则（载体结构、形态标记与稳定 ID、index 表列定义、`history.md` 结构、读写判定、内容修订、表格形态（紧凑）、两种形态、迁移与 v1→v2 升级步骤、自查清单）见 `../fxri-plan-to-task/references/conventions-spec.md`；fxri-plan-to-task 未一并安装、该兄弟路径不存在时，改读包内真源——`toolkit skills status` 打印的「技能源」目录下 `fxri-plan-to-task/references/conventions-spec.md`
 
 ### 规范提炼子流程（三模式共用）