@oh-story/dsh 0.1.9 → 0.1.10

package/lib/oh-story/skills/story-import/SKILL.md

@@ -12,9 +12,9 @@ metadata: {"openclaw":{"source":"https://github.com/zenstory-ai/oh-story-claudec
 
 ---
 
-> Agent 兼容性：只检查当前运行时的 canonical 目录：Claude `.claude/agents/{agent}.md`、OpenCode `.opencode/agents/{agent}.md`、Codex `.codex/agents/{agent}.toml`、Antigravity `.agents/agents/agent-name/agent.md`（`agent-name` 为目标 agent 名），不得因其他端文件存在而误判。Codex 使用同名 `agent_type`；Antigravity 使用 `invoke_subagent` + `TypeName`。对应运行时未暴露 custom-agent registry / `invoke_subagent` 或返回未知 agent 时，必须降级 solo/direct。检测到 `.zcode/` 时同样直接 solo/direct，因为 ZCode 3.3.4 不执行项目 custom agents；报告 `Fallback: project custom agents unavailable -> solo`。Claude/OpenCode 兼容面保留 `subagent_type`。
+> Agent 兼容性：只检查当前运行时的 canonical 目录：Claude `.claude/agents/{agent}.md`、OpenCode `.opencode/agents/{agent}.md`、Codex `.codex/agents/{agent}.toml`、Antigravity `.agents/agents/agent-name/agent.md`（`agent-name` 为目标 agent 名），不得因其他端文件存在而误判。Codex 使用同名 `agent_type`；Antigravity 使用 `invoke_subagent` + `TypeName`。对应运行时未暴露 custom-agent registry / `invoke_subagent` 或返回未知 agent 时，必须降级 solo/direct。检测到 `.zcode/` 时同样直接 solo/direct，因为 ZCode 3.3.4 不执行项目 custom agents；报告 `Fallback: project custom agents unavailable -> solo`。Claude 用 `subagent_type`；OpenCode 用 `subagent` 工具的 `agent` 参数。
 >
-> Spawn 版本提示（不阻断 spawn）：先读取项目根 `.story-deployed` 的 `agents_version`。与本版 `agents_version: 30` 不一致时（标记缺失、字段缺失/非整数、小于或大于 30）**照常按文件存在性检查并 spawn**，同时报告 `Notice: agents bundle 版本不匹配（项目 {N}，本版 30）` 并提示重新运行 `/story-setup` 后新开会话；大于 30 时额外提示先更新 oh-story-claudecode，不要用本地旧版 setup 降级覆盖。只有 agent 文件缺失、或运行时不暴露 custom agent 时才降级 solo/direct，报告 `Fallback: ... -> solo`。
+> Spawn 版本提示（不阻断 spawn）：先读取项目根 `.story-deployed` 的 `agents_version`。与本版 `agents_version: 32` 不一致时（标记缺失、字段缺失/非整数、小于或大于 32）**照常按文件存在性检查并 spawn**，同时报告 `Notice: agents bundle 版本不匹配（项目 {N}，本版 32）` 并提示重新运行 `/story-setup` 后新开会话；大于 32 时额外提示先更新 oh-story-claudecode，不要用本地旧版 setup 降级覆盖。只有 agent 文件缺失、或运行时不暴露 custom agent 时才降级 solo/direct，报告 `Fallback: ... -> solo`。
 
 ## 核心原则
 
@@ -31,7 +31,7 @@ metadata: {"openclaw":{"source":"https://github.com/zenstory-ai/oh-story-claudec
 
 ### 原则 2：复用不重复
 
-深度分析阶段调用现成的拆解管道，不重新发明：长篇运行 `/story-long-analyze` 的完整拆解管道，短篇运行 `/story-short-analyze` 的拆解管道。拆解方法论与输出模板由对应 analyze skill 自带，story-import 不执行拆解方法论、不维护这些文件。
+深度分析复用现成管道：长篇由 `/story-long-analyze` 识别旧成果、增强或续跑，短篇运行 `/story-short-analyze`。方法与模板由 analyze skill 自带，story-import 不另维护。
 
 ---
 
@@ -102,19 +102,17 @@ metadata: {"openclaw":{"source":"https://github.com/zenstory-ai/oh-story-claudec
 在进入 Phase 2 之前，先检测项目是否已部署 story-setup 基础设施：
 
 - 先读取 `.story-deployed` 并执行顶部 Spawn 版本门禁；旧版 `chapter-extractor` 文件即使仍在磁盘上也不可复用。
-- 只有 `agents_version: 28` 通过后，才在当前运行时的 canonical 目录检查 Phase 2 `chapter-extractor`：Claude/OpenCode/Antigravity 为同名 Markdown，Codex 为同名 TOML。
+- 只有 `agents_version: 32` 通过后，才在当前运行时的 canonical 目录检查 Phase 2 `chapter-extractor`：Claude/OpenCode/Antigravity 为同名 Markdown，Codex 为同名 TOML。
 - 如果 `.story-deployed` 的 `target_cli` 包含 `zcode`，项目 agents 缺失是 ZCode 3.3.4 的预期状态：不要提示重复部署，直接以串行 solo/direct 进入分析并报告 fallback。
 
-**部署标记缺失、版本无效/过期，或当前端的 agent 不可用，且不是已部署 ZCode 项目时**，提示用户：
+**部署标记缺失、版本无效/过期，或当前端的 agent 不可用，且不是已部署 ZCode 项目时**，这样问用户：
 
-> 「检测到当前项目尚未部署写作基础设施。建议先运行 `/story-setup` 再回来导入，否则深度分析阶段无法使用并行 chapter-extractor agent。」
-
-给用户两个选择：
+> 「这个项目还没装好写作环境。装好后由专门的分析助手逐段拆书，主对话不会被整本书塞满；不装也能导，只是全部在主对话里做，慢一些，结果一样完整。你想：1. 先装环境（推荐）：运行 `/story-setup`，装完再说"导入" 2. 直接导入，慢一点也行」
 
 1. **先去 setup**：暂停导入，运行 `/story-setup`，部署完成后重新触发 `/story-import`；
-2. **继续导入**：接受 Phase 2 降级为串行处理（长篇逐章摘要不并行，速度较慢，但产物完整）。
+2. **继续导入**：Phase 2 降级为主线程串行处理（长篇逐章摘要由主线程自己写，速度较慢，但产物完整）。
 
-用户选择记入上下文，Phase 2 据此决定是否走并行模式。
+用户选择记入上下文，Phase 2 据此决定是否派 chapter-extractor。有子代理时，导入属自动续跑，按 story-long-analyze 的「有限并行」档派发（每轮 3 批）；用户明确要求时改用串行或不限批次顺序。
 
 ### Step 6：原文备份
 
@@ -124,26 +122,32 @@ metadata: {"openclaw":{"source":"https://github.com/zenstory-ai/oh-story-claudec
 
 ## Phase 2：深度分析
 
-按 Phase 1 判定的篇幅类型，调用对应 analyze skill 的**完整拆解管道**；不要做「复用方法论」式的半流程，要驱动整条管道跑完，拿到全套结构化产物。
+按 Phase 1 判定的篇幅类型进入对应 analyze skill。先检查已有拆文资产；可验证的旧成果直接复用，只有缺失范围或本次导入确实依赖的新分析才进入对应 Stage。全新项目再驱动完整管道。
 
 | 篇幅 | 调用的拆解管道 | 产物目录 |
 |------|--------------|---------|
-| 长篇 | story-long-analyze 的完整管道（Stage 0-6） | `拆文库/{导入书名}/` |
+| 长篇 | story-long-analyze 的统一管道（旧成果直用 / 按需增强 / 全新或部分续跑） | `拆文库/{导入书名}/` |
 | 短篇 | story-short-analyze 的拆解管道（Stage 2-6） | `拆文库/{导入书名}/` |
 
 ### 调用契约
 
-#### 长篇：自动续跑过 Stage 1 停靠点
+#### 长篇：先兼容识别，再决定是否续跑
+
+先运行 story-long-analyze Phase 1 的只读检查器（`inspect_existing_assets.py`），登记实际文件和覆盖范围；检查建议不能覆盖下列语义规则：
 
-story-long-analyze 在 Stage 0+1（黄金三章）后会**自动停靠**并用 AskUserQuestion 询问是否继续全量拆解（对应 story-long-analyze 的「Stage 1 停靠点」）。但导入场景需要 Stage 2-6 的全套产物（逐章摘要 / 聚合分析 / `剧情/节奏.md` / `剧情/情绪模块.md` / 设定关系 / 汇总报告 / 文风），缺一不可——否则 Phase 3 迁移会拿到半成品。
+新生成或按当前契约续跑的长篇进度保持 `schema_version: 2`；旧成果直接使用不以缺少该字段为失败。
 
-**当前拆文契约**：`_progress.md` 必须是 `schema_version: 2`，且 `剧情/节奏.md` 与 `剧情/情绪模块.md` 是导入必备权威产物。任一缺失都先修复或重跑对应 Stage，不得用摘要文件拼出看似完整的导入工程。
+- **旧成果已完成且足以重建写作工程**：直接进入 Phase 3-L。旧 `_progress.md` 版本、缺少 `chapter_index.csv`，或缺少本次新增字段，都不能单独成为重拆理由。
+- **旧成果可以导入，但缺少当前写作/对标功能需要的 `剧情/节奏.md`、`剧情/情绪模块.md` 等资料**：先用现有逐章、剧情、关系、报告和文风做 Stage 3+ 按需增强，不回读原文。不得重跑已完成章节，也不得用空壳文件让门禁通过。
+- **只完成一部分或新旧产物混存**：验证并保留已完成部分，从首个缺失的连续章节块续跑，最后统一聚合。进度记录与实际文件冲突时，以可验证文件为准并记录冲突。
+- **全新导入**：运行 Stage 0-6 完整管道。
 
-因此调用 story-long-analyze 时**必须在一开始就以「完整拆解、一次跑完、不要停下询问」模式驱动管道**，命中其「跳过询问」路径（用户开头明确说「完整拆解 / 一次跑完 / 系统拆解 / 别问」时不停靠），让管道自动从 Stage 2 续跑到 Stage 6。
+导入需要自动完成本次判定出的必需范围，不把 Stage 1 停靠询问甩给用户。全新导入命中「完整拆解、一次跑完」路径；旧成果增强或部分续跑只执行缺失 Stage/章节块。原有用途当前不消费新增分析时，缺少新增字段只记录能力限制，不阻断导入。
 
-- 措辞示例：启动深度分析时声明「以『完整拆解、一次跑完、不要停下询问』模式拆解本书，确保 Stage 2-6 全部产出」。
-- **兜底**：若运行环境实际仍停在 Stage 1 询问处，story-import 自动选择「继续全量拆解」，**绝不把停靠询问甩给用户**。
-- 环境检测（Phase 1）发现未部署 chapter-extractor agent 且用户选择「继续导入」时，Stage 2 逐章摘要降级为串行处理，产物仍完整，仅速度变慢。
+- 措辞示例（全新）：启动深度分析时声明「以『完整拆解、一次跑完、不要停下询问』模式拆解本书，确保 Stage 2-6 全部产出」。
+- 措辞示例（旧成果）：声明「先复用并校验现有成果，只补当前导入缺失的章节或分析，不覆盖用户原成果」。
+- **兜底**：若全新导入实际仍停在 Stage 1，story-import 自动选择继续；若旧成果任务停靠，则按已登记的缺失范围继续，不能扩大成全书重跑。
+- 环境检测（Phase 1）发现未部署 chapter-extractor agent 且用户选择「继续导入」时，Stage 2 由主线程按相同连续章节块契约串行处理，不能退回每章一次独立调用；产物仍完整，仅速度变慢。
 
 #### 短篇：单一全量管道
 
@@ -190,6 +194,8 @@ story-short-analyze 的拆解管道（Stage 2-6）本身**无 Stage 1 停靠点*
 │   ├── 世界观/         # 背景设定.md / 力量体系.md / 地理.md / 金手指.md（子目录形态）
 │   └── 势力/           # {势力名}.md（每势力一文件）
 ├── 拆文报告.md
+├── chapter_index.csv    # 机械章界、原文定位、源 hash 与解析器版本
+├── 人物关系图/          # 人物关系图.md（Mermaid 中文图）；有中文字体时另有 PNG
 ├── 文风.md          # Stage 6 文风：写作技法视图 + 原文范例锚点
 └── _progress.md
 ```
@@ -214,12 +220,12 @@ story-short-analyze 的拆解管道（Stage 2-6）本身**无 Stage 1 停靠点*
 
 | 阶段 | 名称 | 输入 | 输出 | 完成标志 |
 |------|------|------|------|----------|
-| 0 | 概要提取 | 原始文本 | 概要.md + 章节索引 | 章节结构识别完成 |
+| 0 | 概要与机械索引 | 原始文本 | 概要.md + `chapter_index.csv` | 章节结构、定位、源 hash 与解析器版本记录完成 |
 | 1 | 黄金三章 | 前 3 章原文 | 第1章_深度拆解.md / 第2章_深度拆解.md / 第3章_深度拆解.md → **停靠产出快速预览.md**（导入场景自动续跑，不停下询问） | 3 章拆解完成 |
-| 2 | 逐章摘要 | 分块章节文本 | 章节摘要.md（含情节点+角色+**关键信息与扩写技法**）。每章10-40情节点（密度150-200字/个，按字数动态调节）。角色过滤（龙套不提取、别名归类）。**并行 chapter-extractor agent 模式**（未部署 agent 时降级串行）。**计数验证：摘要数 == 章节数**。 | 所有章节处理完成 |
-| 3 | 聚合分析 | 全部章节摘要 | `剧情/*.md` + `剧情/README.md` + `剧情/故事线.md` + **`剧情/节奏.md` + `剧情/情绪模块.md`**。**故事框架识别**（前置）。**两步法剧情聚合**（先从摘要识别剧情大纲，再按大纲分配情节点）。**关键信息推进索引**、**情绪触动点与爆发节奏**、**读者需求 / 情绪引擎 / 可复现模块**。**角色合并**（跨章节去重+别名归一）。**角色分级**（主角/反派/核心配角/功能角色）。**散落情节兜底**（6步，含覆盖率验证）。**质量检查**（置信度>=0.85/覆盖率85%-95%/重叠率<=35%）。 | 质量检查通过 |
-| 4 | 设定+关系 | 阶段 3 合并后角色数据+情节点 | 设定/*.md + 角色/*.md。**两阶段角色模型**。**别名解析**（置信度≥0.85自动合并）。 | 设定和关系提取完成 |
-| 5 | 汇总报告 | 全部输出 | 拆文报告.md（含「读者需求 / 情绪引擎」「关键信息与扩写技法总览」「节奏与情绪触动点」「可复现模块」，并指向 `剧情/节奏.md` / `剧情/情绪模块.md`） | 报告生成完成 |
+| 2 | 连续章节块提取 | 待处理连续原文、旧成果与跨块状态 | 同次产出 `章节/第N章_摘要.md`（含情节点序列）和 `_analysis_cache/批次-*.md`；每批最多 3 章，长章缩到 1-2 章；每章 10-20 个情节点，长章最多 30 | 可用正文覆盖完整，摘要数与可用章节数一致 |
+| 3 | 聚合分析 | 批次观察、必要逐章事实与可复用旧资料 | `剧情/*.md` + `剧情/README.md` + `剧情/故事线.md` + **`剧情/节奏.md` + `剧情/情绪模块.md`**。在现有资料中补强因果链、客观事件/多次披露、信息差、事件/情绪/篇幅三维节奏及机制成立条件 | 质量检查通过 |
+| 4 | 设定+关系 | 批次观察、阶段 3 归一实体与必要逐章事实 | 设定/*.md + 角色/*.md + 人物关系图。关系记录方向、触发、双方得失、阶段状态和证据 | 设定和关系提取完成 |
+| 5 | 汇总报告 | 全部权威底层结果 | `拆文报告.md`：一份可独立阅读的人类主报告，嵌入可用人物关系图，不重新阅读全文 | 报告生成完成 |
 | 6 | 文风 | 拆文报告.md + 章节/第1-3章_深度拆解.md + 章节/*_摘要.md + 原文/原文.txt | 文风.md（本书历史写法分析） | 文风落盘 `拆文库/{导入书名}/文风.md`，保留为导入分析，不复制到本书 `对标/` |
 
 ### 短篇拆文管道
@@ -228,14 +234,14 @@ story-short-analyze 的拆解管道（Stage 2-6）本身**无 Stage 1 停靠点*
 
 短篇为单一全量管道（Stage 2-6 严格串行），产物落盘 `拆文库/{导入书名}/`：Stage 2 结构+情节节点 → Stage 3 情感线+爆点 → Stage 4 反转+写作手法 → Stage 5 人物+开头结尾 → Stage 6 综合评估，最终汇总为 `拆文报告.md`、`情节节点.md`、`写作手法.md`，另有 `_meta.json` 记管道元数据与结构计数。
 
-长篇分块沿用 story-long-analyze：Stage 2 用 chapter-extractor agent 并行，其余阶段按该 skill「分块策略」的章数阈值执行，story-import 不另定一套。
+长篇组块、旧成果复用和恢复全部沿用 story-long-analyze。Stage 2 每个连续章节批次只调用一次 chapter-extractor，同次生成逐章事实与跨章观察；story-import 不另定一套。
 
 ### 恢复机制
 
 - 中断时通过进度文件追踪进度
 - 新会话读取进度文件定位断点
-- 从断点所在块的起始章节恢复
-- 长篇进度文件格式沿用 story-long-analyze 拆解管道的进度段落约定，包含当前阶段、最后处理章节、已完成阶段列表、更新时间
+- 先验证断点批次已经落盘的逐章文件和跨章缓存；完整则补记进度，缺失或损坏才从该批次起章恢复
+- 长篇进度文件沿用 story-long-analyze 的 `_progress.md` 受管区：批次表、阶段表和 `最终状态`
 
 ### 质量检查
 
@@ -310,7 +316,7 @@ story-short-analyze 的拆解管道（Stage 2-6）本身**无 Stage 1 停靠点*
 
 #### Step 5：同步世界观设定
 
-当前拆文契约已按主题输出 `拆文库/{导入书名}/设定/世界观/*.md` 与 `设定/势力/*.md`。导入时原样同步到项目；`世界观/` 必须包含 `背景设定.md`。`力量体系.md` 小于 200 字并已并入 `背景设定.md` 时可省略；否则缺失当前必需产物时停止并提示重跑 story-long-analyze Stage 4。不再现场拆分扁平文件。
+当前拆文契约按主题输出 `拆文库/{导入书名}/设定/世界观/*.md` 与 `设定/势力/*.md`，导入时原样同步；`世界观/` 必须有 `背景设定.md`，短小力量体系可并入。当前产物缺失时停止并提示修复 Stage 4；检查器确认的旧成果则从已有扁平设定转换到当前项目路径，标注来源，不回写或覆盖拆文库。
 
 #### Step 6：大纲生成
 
@@ -401,7 +407,7 @@ story-short-analyze 的拆解管道（Stage 2-6）本身**无 Stage 1 停靠点*
    > 项目 `追踪/` 里已有不属于当前协议的早期文件时不必手工清理：`init` 会先把它们按原样整体移入 `追踪/_旧追踪存档/`，再在原地建当前协议。旧内容保留供作者查阅，不参与解析，当前状态完全由本次导入输入决定；校验失败的 `init` 不移动任何文件。
 
    ```text
-   {PYTHON} {story-import skill 根}/scripts/tracking_commit.py init --project {项目根} --input {初始化事务.json}
+   {PYTHON} {story-import skill 根}/scripts/tracking_commit.py init --project {项目根} --input {项目根}/.story/work/init.json
    {PYTHON} {story-import skill 根}/scripts/tracking_commit.py check --project {项目根}
    ```
 
@@ -437,8 +443,8 @@ story-short-analyze 的拆解管道（Stage 2-6）本身**无 Stage 1 停靠点*
 
 **缺失处理**：
 
-- 已选外部对标缺 `剧情/节奏.md` 或 `剧情/情绪模块.md` → 不登记、不生成半套对标视图；报告 `module_or_rhythm_required_missing` 并提示对 `{对标书名}` 重跑 `/story-long-analyze` Stage 3+。本书核心工程迁移不因此回滚。
-- 其它结构化子目录缺失 → 按既有导入缺失项提示，不阻塞项目创建
+- 已选外部对标缺 `剧情/节奏.md` 或 `剧情/情绪模块.md` → 导入报告里告诉作者「《{对标书名}》的拆文缺节奏和情绪资料，这本对标暂时用不上；重新拆一次（`/story-long-analyze`）补齐后再接入」，并停止该对标召回；不得用摘要或报告生成空壳。本书核心工程迁移不回滚。两份老权威产物都存在时正常同步，缺少本次新增内嵌字段不阻断。
+- 其它结构化子目录缺失 → 在导入完成报告里用白话提示，不阻塞项目创建
 
 #### Step 10：文风同步
 
@@ -497,66 +503,56 @@ story-short-analyze 的拆解管道（Stage 2-6）本身**无 Stage 1 停靠点*
 
 ### Step 1：质量检查
 
-按篇幅对照对应的质量检查清单：
+按篇幅对照对应的质量检查清单。这是你自己的自检，不念给作者：全部通过就不提；没通过先修，修不了才用故事话告诉作者影响和办法。
 
 - **长篇**：完整导入质量清单见 [references/structure-mapping-long.md](references/structure-mapping-long.md) 末尾（含正文文件数对照、核心角色独立快照、作者/读者时间线隔离、`tracking_commit.py check` 通过、卷划分已经用户确认等）。
 - **短篇**：质量清单见 [references/structure-mapping-short.md](references/structure-mapping-short.md) 末尾的质量检查清单（含 `正文.md` 单文件存在且格式合规、`设定.md` 含核心框架+本书续写基线、未误建长篇专属目录等）。
 
-### Step 2：缺失项提示
+### Step 2：导入完成报告
 
-输出导入结果摘要和待补充项，按篇幅分支。
+报告写给作者：导进来了什么、哪几处请他核对、要他拍板的事、下一步怎么说。字段名、脚本名、校验结果、字数口径、伏笔/事件编号不进报告；编号只能跟着故事描述出现（如「玉佩的来历（F003）」）。核对项要落到具体人和事，一次最多 5 条。
 
-**长篇导入完成报告**：
+**长篇**：
 
-```
-=== 导入完成报告（长篇）===
-书名：{导入书名}
-源文件：{X} 章，{Y} 万字
-项目目录：{路径}
-
-## 已生成文件
-- 正文：{N} 章
-- 角色文件：{M} 个
-- 大纲：大纲.md + {V} 个卷纲 + {N} 个细纲
-- 追踪：唯一结构化 state + 核心角色独立派生快照 + 伏笔当前视图 + 时间线双视图 + 空逐章记录目录 + 固定 7 栏上下文
-- 设定：{世界观文件数} 个
-- 外部对标：{未绑定 / 已从 `拆文库/{对标书名}/` 同步到 `对标/{对标书名}/` / 绑定失败及修复动作}
-
-## 待补充项
-- [ ] 细纲中的章首/章尾钩子需要补充
-- [ ] 题材定位的核心梗三分法需要确认
-- [ ] 伏笔追踪中的伏笔已复核
-- [ ] `追踪/时间线/读者已知.md` 未泄露 `作者真相.md` 中尚未揭示的事实
-- [ ] 卷划分已确认（原文无明确卷界时）
-- [ ] `拆文库/{导入书名}/` 未被复制到项目 `对标/`，本书未登记为自身对标
-- [ ] 若绑定外部对标，`设定/题材定位.md` 的 `主对标书` 与 `对标书列表` 只包含独立 `{对标书名}`，且同步来源与目录名一致
-
-## 下一步操作
-- 运行 `/story-review lean` 审查导入结果
-- 运行 `/story-long-write` + "日更" 开始续写
-```
+<!-- author-report -->
+```md
+=== 《{导入书名}》导入完成 ===
+导进来了：第 1–{N} 章，约 {Y} 万字{；第 {N+1} 章只写了一半，按你的决定{接着残章写 | 先补完}}。项目在 `{项目目录}`。
+
+我整理出了：
+- 人物：{M} 个角色档案，主要人物写到第 {N} 章时的处境已记下（如「{角色}：{一句话现状}」）
+- 大纲：全书大纲、{V} 卷卷纲、每章细纲
+- 还没收的线：{K} 条（如「{伏笔的故事描述}」）
+- 时间线：真相和读者目前知道的分开记，续写时不会提前泄底
+- 设定：{设定文件数} 份世界观资料
+- 对标书：{没有绑定 | 已接入《{对标书名}》 | 没接上：原因和补救}
+
+请你核对：
+1. {最拿不准的一处，写成具体问题，如「第 5 章的黑衣人和第 2 章的车夫是同一人吗？」}
+2. {如「还没收的线里有没有漏的？我列的是：……」}
 
-**短篇导入完成报告**：
+需要你决定：{仅在有待定事项时写，如「原文没分卷，我按剧情分成 3 卷（1–40 / 41–95 / 96–{N} 章），这样分可以吗？」}
 
+下一步：说「日更」就从第 {N+1} 章接着写；想先检查导入质量，说「审一下」。
 ```
-=== 导入完成报告（短篇）===
-标题：{短篇标题}
-源文件：{Y} 字
-项目目录：{路径}
-
-## 已生成文件
-- 正文.md（单文件，{Y} 字）
-- 设定.md（核心框架 + 本书续写基线）
-- 小节大纲.md（{N} 个小节）
-- 外部对标：{未绑定 / `对标/{对标书名}/` 已同步 / 绑定失败及修复动作}
-
-## 待补充项
-- [ ] 所有 [待补充] 标记的文件已复核
-- [ ] 小节大纲的章首/章尾钩子需要补充
-- [ ] 核心反转的铺垫线索已确认
-
-## 下一步操作
-- 运行 `/story-short-write` Phase 3 开始续写
+
+**短篇**：
+
+<!-- author-report -->
+```md
+=== 《{短篇标题}》导入完成 ===
+导进来了：全文约 {Y} 字，分成 {N} 个小节。项目在 `{项目目录}`。
+
+我整理出了：
+- 设定：核心框架和续写要守住的人物、情绪基调
+- 小节大纲：{N} 节，每节讲了什么
+- 对标书：{没有绑定 | 已接入《{对标书名}》 | 没接上：原因和补救}
+
+请你核对：
+1. {标了 [待补充] 的地方，写成问题，如「女主最后原谅他了吗？原文没写明」}
+2. {核心反转前埋的线索我找到的是：……，有没有漏的？}
+
+下一步：{没写完：运行 `/story-short-write` 说「接着写」，从第 {N+1} 节往下写 | 已完本：想改稿说「审一下」}。
 ```
 
 ### Step 3：项目激活

package/lib/oh-story/skills/story-import/references/character-state-reverse.md

@@ -10,7 +10,7 @@
 |---|---|
 | `拆文库/{书名}/角色/{角色名}.md` | 身份、能力、目标、成长弧线、出场记录 |
 | `拆文库/{书名}/角色/角色关系.md` | 截至最后完整章的关键关系 |
-| `拆文库/{书名}/章节/第N章_摘要.md` | 最后位置、最新状态、已知信息与未结事项 |
+| `拆文库/{书名}/章节/第N章_摘要.md` | 从 `涉及` 锁定相关章，从 `状态变化`、`信息变化`、`局面结果` 和 `章尾钩子` 提取最后位置、最新状态、已知信息与未结事项；旧摘要缺字段时回退其关键事件与情节点 |
 | `拆文库/{书名}/剧情/*.md` | 阵营/身份转折、阶段目标和长期冲突 |
 | 初始化事务中的伏笔与时间线候选 | 核对角色未结事项及其可知范围 |
 

package/lib/oh-story/skills/story-import/references/state-tracking.md

@@ -1,75 +1,10 @@
-# 状态追踪协议
+# 角色状态记录格式
 
-> 本文件定义"本节速记"的提取逻辑和"角色状态记录"的格式。写作 skill 在写前准备的状态筛选步骤中加载此文件。
-
----
-
-## 本节速记
-
-写作每一章/每一节前，从所有已加载的上下文中筛选出只与本节相关的信息。目的是避免全量加载导致 LLM 上下文被无关信息稀释。
-
-### 筛选逻辑
-
-从上下文中提取三类信息：
-
-1. **当前状态**：本章涉及角色的最新能力、关系变化、公众形象
-2. **历史因果**：与本章事件直接相关的伏笔成因、前史事件
-3. **世界约束**：本章涉及的世界观规则（力量体系、社会规则、地理限制）
-
-### 筛选标准
-
-**只保留"如果不知道这个，本章会写错"的信息。**
-
-具体判断方法：
-- 本章细纲中提到了某个角色 → 保留该角色的当前状态
-- 本章有伏笔回收 → 保留伏笔的埋设细节和前文铺垫
-- 本章涉及特定地点/能力/规则 → 保留相关世界观约束
-- 纯背景知识（与本章事件无因果关联） → 丢弃
-
-### 输出格式
-
-筛选后输出一个简洁的"本节速记"：
-
-```
-## 本节速记（第{N}章）
-
-### 角色状态
-{角色A}：{一句话当前状态，含最近变化}
-{角色B}：{一句话当前状态}
-
-### 相关伏笔/前史
-{伏笔1}：{埋设细节，{埋设章节}}，本章需要{回收/推进}
-
-### 世界约束
-{约束1}：{与本章相关的规则/设定}
-```
-
-**示例（demo《让你管账号，你高燃混剪炸全网》第 10 章）：**
-```
-## 本节速记（第10章）
-
-### 角色状态
-江晨：火箭军文工团宣传兵，《诸君，且听龙吟》已爆红，正从军宣新人升为军内认可的创作者
-钟嘉嘉：军报记者，采访稿已经过审，与江晨从采访关系转为稳定合作
-周薄森：文工团副团长，已从担心江晨惹事转为认可其创作能力
-
-### 相关伏笔/前史
-五天百万粉任务：第1章发布，第10章仍未结算；本章只推进声量，留到第11章结算
-专业团队重拍：本章用高清专业版“缺了灵魂”反衬江晨手机原版不可替代
-
-### 世界约束
-军宣作品采用要经过组织决策；江晨可以靠作品效果赢得认可，不能跳过军内流程直接拍板
-```
-
----
-
-## 角色状态记录格式
-
-> ⚠️ **本节仅适用于长篇写作。** 短篇通常不需要独立角色状态追踪。
+> story-import 反推角色状态（character-state-reverse.md）时按本格式写 `追踪/角色状态/{角色名}.md`。
 
 动态状态按核心角色拆成 `追踪/角色状态/{角色名}.md`，由 `tracking_commit.py` 根据事务 JSON 整份覆盖；静态原始人设仍在 `设定/角色/{角色名}.md`。只为后续会复用的主角、反派、核心配角建快照，不为路人、一次性功能角色建文件。
 
-### 格式
+## 格式
 
 ```markdown
 # 江晨｜当前状态
@@ -98,7 +33,7 @@
 - 钟嘉嘉所谓“只猜对一半”仍未解释
 ```
 
-### 更新规则
+## 更新规则
 
 1. 每章只记录身份、位置、目标、身心状态、能力资源、关系、已知信息、未结事项中真正发生变化的内容。
 2. 核心复用角色发生变化时，在同一事务的 `character_changes` 写变化，并在 `character_snapshots` 提交其**截至当前已写最后一章**的完整快照；工具以快照是否存在判断核心/临时角色，整份覆盖核心角色小文件，不追加历史。

package/lib/oh-story/skills/story-import/references/structure-mapping-long.md

@@ -33,6 +33,8 @@ Phase 3-L 长篇结构迁移的详细映射规则和模板。将 `拆文库/{导
 | `剧情/散落情节.md` | `大纲/大纲.md` 附录或对应卷纲 | 合并到相关卷的大纲 |
 | — | `追踪/上下文.md` | 由初始化事务生成续写状态卡（固定 7 栏），≤12288 字节 |
 
+旧拆文的目录或字段名与上表不同时，先建立一次“旧路径 → 当前目标”的来源映射，再按实际可读内容转换；不要为了改名复制出第二套拆文真源。`剧情/节奏.md`、`剧情/情绪模块.md` 或主题化设定缺失时，旧内容能支持的导入步骤照常执行，对应摘要写「未知/待增强」；只有用户要启用依赖这些资料的新对标召回时，才回到 story-long-analyze 做按需增强。
+
 ---
 
 ## 正文标准化规则
@@ -263,17 +265,17 @@ A<->B：关系类型 | 情感 | 描述（50-200字）| 演变轨迹
 
 | 摘要字段 | 细纲字段 | 转换方式 |
 |---------|---------|---------|
-| 关键事件 | 核心事件 | 直接复用 |
+| 关键事件 + 局面结果 | 核心事件 | 合并为“谁采取什么行动 → 局面如何变化”；旧摘要没有 `局面结果` 时只用 `关键事件` |
 | 章节字数 | 字数目标 + 字数口径 | 对原文章节运行 `storyctl.py wordcount measure`，写入 `actual` 与 `visible_chars_v1` |
-| 章节基调 / 情绪曲线 | 目标情绪 | 从摘要提取；缺失写 `[待补充]` |
-| 第一个情节点 | 章首钩子 | 只作为证据，设计目标标 `[待补充]` |
+| `基调：` | 目标情绪 | 读取紧张/轻松/悲伤/热血/爽/甜/温馨/恐怖/压抑/其他枚举；缺失写 `[待补充]` |
+| 章尾钩子 | 章首承接证据 | 作为下一章开篇需要承接的等待；新的章首钩子设计目标仍标 `[待补充]` |
 | 爽点类情节点 | 爽点 | 从情节点类型推断；没有则写“无显性爽点 / [待补充]” |
-| 情节点起承转合 | 内容概括（起因/发展/转折/高潮/结尾） | 按情节点顺序归纳；证据不足写 `[待补充]` |
+| 情节点起承转合 + 因果 | 内容概括（起因/发展/转折/高潮/结尾） | 按情节点顺序归纳，用因果链校正起因与转折；证据不足写 `[待补充]` |
 | 主线/支线/任务线索 | 情节安排（主线/辅线/事件线/感情线/逻辑线） | 从剧情单元索引与摘要反推；无证据的辅线/感情线写“无”或 `[待补充]`，不得杜撰 |
-| 出场角色 / 关键物件 | 人物关系和出场顺序 | 按摘要出现顺序列出；关系变化只写有证据的“前 → 后”，缺失写 `[待补充]` |
-| 全部情节点 | 情节细化 / 情节点序列 | 按表格逐行写（# / 情节点 / 功能标签 / 执行边界）；功能或边界不明写 `[待补充]`，不反推逐点字数配额 |
+| 涉及 + 状态变化 | 人物关系和出场顺序 | `涉及` 给出候选人物，`状态变化` 只写有证据的“前 → 后”；关键物件从证据或旧情节点补充，缺失写 `[待补充]` |
+| 全部情节点 | 情节细化 / 情节点序列 | 按表格逐行写（# / 情节点 / 功能标签 / 执行边界）；保持原顺序，功能或边界不明写 `[待补充]`，不反推逐点字数配额 |
 | 胜负/反转/收益损失 | 行动成本（可无）/收益归属 | 有明确证据才填写；行动成本可无、不硬造；否则 `[待补充]` |
-| 最后一个情节点 / 悬念类情节点 | 结尾设定和钩子 | 收束状态可归纳；章尾钩子设计目标标 `[待补充]` |
+| 章尾钩子 + 局面结果 | 结尾设定和钩子 | 局面结果写收束状态，章尾钩子写已存在的等待；未来设计仍标 `[待补充]` |
 
 ---
 
@@ -410,7 +412,7 @@ A<->B：关系类型 | 情感 | 描述（50-200字）| 演变轨迹
 | `拆文库/{对标书名}/剧情/节奏.md` | `{项目}/对标/{对标书名}/剧情/节奏.md` | 日更选择 `rhythm_reference` 的必备权威文件；缺失则不登记该对标 |
 | `拆文库/{对标书名}/剧情/情绪模块.md` | `{项目}/对标/{对标书名}/剧情/情绪模块.md` | 日更选择 `selected_emotion_module` 的必备权威文件；缺失则不登记该对标 |
 | `拆文库/{对标书名}/剧情/*.md` | `{项目}/对标/{对标书名}/剧情/*.md` | 剧情单元、故事线、散落情节等剧情资产；与权威节奏/情绪文件冲突时以后者为准 |
-| `拆文库/{对标书名}/章节/*.md`（第N章_摘要.md + 黄金三章 第1-3章_深度拆解.md）| `{项目}/对标/{对标书名}/章节/*.md` | 匹配章证据，含「关键信息与扩写技法」 |
+| `拆文库/{对标书名}/章节/*.md`（第N章_摘要.md + 黄金三章 第1-3章_深度拆解.md）| `{项目}/对标/{对标书名}/章节/*.md` | 匹配章证据；摘要读取概要、关键事件、局面结果、涉及、状态变化与情节点序列（含类型、主题标签与基调），黄金三章另含深度写法 |
 | `拆文库/{对标书名}/角色/*.md` | `{项目}/对标/{对标书名}/角色/*.md` | 角色功能位、关系与反应层参考 |
 | `拆文库/{对标书名}/设定/` | `{项目}/对标/{对标书名}/设定/` | 世界观、势力、金手指等设定约束参考 |
 | `拆文库/{对标书名}/拆文报告.md` | `{项目}/对标/{对标书名}/拆文报告.md` | 人类可读摘要投影 |

package/lib/oh-story/skills/story-import/references/tracking-transaction.md

@@ -18,23 +18,25 @@ Markdown 只负责给作者和 Agent 阅读，工具不再反向解析 Markdown
 先按运行环境探测 Python 3 解释器（依次尝试 `python3`、`python`、`py -3`）。追踪事务脚本使用当前 skill 根目录；字数与章节闭环统一使用 `story-long-write` skill 根目录：
 
 ```text
-{PYTHON} {当前 skill 根}/scripts/tracking_commit.py init   --project {书项目根} --input {初始化事务.json}
+{PYTHON} {当前 skill 根}/scripts/tracking_commit.py init   --project {书项目根} --input {书项目根}/.story/work/init.json
 {PYTHON} {当前 skill 根}/scripts/tracking_commit.py check  --project {书项目根}
+{PYTHON} {当前 skill 根}/scripts/tracking_commit.py draft  --project {书项目根} --chapter {N}
 {PYTHON} {story-long-write skill 根}/scripts/storyctl.py chapter check   --project {书项目根} --chapter {N}
-{PYTHON} {story-long-write skill 根}/scripts/storyctl.py chapter commit  --project {书项目根} --chapter {N} --input {逐章事务.json}
-{PYTHON} {story-long-write skill 根}/scripts/storyctl.py chapter accept-current-length --project {书项目根} --chapter {N} --input {逐章事务.json}
+{PYTHON} {story-long-write skill 根}/scripts/storyctl.py chapter commit  --project {书项目根} --chapter {N} --input {书项目根}/.story/work/第{NNN}章/tracking.json
+{PYTHON} {story-long-write skill 根}/scripts/storyctl.py chapter accept-current-length --project {书项目根} --chapter {N} --input {书项目根}/.story/work/第{NNN}章/tracking.json
 ```
 
 - `init`：只在 `_tracking-state.json` 不存在时执行，绝不覆盖已初始化项目。
-- `wordcount measure` / `wordcount checkpoint`：纯测量入口；不写正文、不写 tracking、不做语义判断。长篇正文流程一次写完整章，**不在章中调用测量**，长度由 `chapter check` 一次收口；这两个入口供导入、审查等其他场景使用。
-- `chapter check`：重新读取当前正文与细纲目标，返回确定性长度状态、现有 blocking quality、`state_revision` 和当前可执行动作，不保存 approval。`under` 不提供自动补写；`over` 额外返回一次净删型 `compress-once` 及进入内带/用户带所需的机器删除区间。
+- `draft`：按当前 state 把逐章事务预填到 `.story/work/第NNN章/tracking.json`（修订号、模式、章名、`context` 四项当前值），并输出各文本字段的字数上限与在场核心角色的当前快照；调用方只填 `delta` 与有变化角色的快照。
+- `wordcount measure` / `wordcount checkpoint`：纯测量入口；不写正文、不写 tracking、不做语义判断。长篇正文只在前组写完后由父流程调用一次 `checkpoint`（见 workflow-chapter 步骤 6），整章长度由 `chapter check` 收口。
+- `chapter check`：重新读取当前正文与细纲目标，返回确定性长度状态、现有 blocking quality、`state_revision` 和当前可执行动作，不保存 approval。`under` 不提供自动补写；`over` 额外返回一次净删型 `compress-once` 及回到内部区间或作者给定区间所需的删除字数。
 - `chapter commit`：再次读取当前文件、重新计数并重跑 blocking quality；只接受用户带内章节，把简短字数记录与逐章事务一起原子提交。
 - `chapter accept-current-length`：只接受带外但 quality pass 的章节；接受动作发生时重新读取、重新计数并立即原子提交，不保存可陈旧的历史决议。
 - `check`：严格验证 state schema、逐章记录连续性/规范名/体积、固定 7 栏、角色快照硬上限、派生文件集合，以及所有派生视图与 state 的逐字一致性。
 
 每本书由 `追踪/.tracking-commit.lock` 串行写事务，`expected_state_revision` 再拒绝基于旧状态构造的 stale transaction。两个不同事务并发时至多一个修订成功。字数记录也在锁内对当前正文和目标重新验证，正文或目标变化会让预先构造的记录直接失败。
 
-事务 JSON 是临时输入，不是项目产物：成功前必须保留；提交成功且紧随其后的 `check` 通过后立即删除，不能把 `init_transaction.json`、`chapter_*_transaction.json` 等输入长期留在书项目根目录。若文件写入失败，`_tracking-state.json` 尚未推进；修正环境后直接重跑**同一份** `commit`。append 重跑只接受内容完全相同的既有逐章记录，不维护 `dirty/pending/repair` 状态机。
+事务 JSON 是临时输入，不是项目产物：只写在书目录 `.story/work/` 下（逐章事务放 `.story/work/第NNN章/tracking.json`），不写系统 `/tmp`、书根、`大纲/` 或 `正文/`；成功前必须保留，提交成功后即可删除（`storyctl.py chapter commit` / `accept-current-length` 成功时自动删除该章目录；直接调用 `tracking_commit.py commit` 时由调用方删除）——之后 `check` 失败按下文提交 `mode=revision` 新事务修复，不需要原事务。若文件写入失败，`_tracking-state.json` 尚未推进；修正环境后直接重跑**同一份** `commit`。append 重跑只接受内容完全相同的既有逐章记录，不维护 `dirty/pending/repair` 状态机。
 
 校验失败与写入失败处理方式不同：校验失败（字段非法、退役结构、容量超限）要按报错改事务本身，重跑同一份结果不变。派生视图被手改或外部改动导致 `check` 报 `derived view differs from _tracking-state.json` 时，重新提交**该章**的 `mode=revision` 事务让工具整份重建，`expected_state_revision` 取 `追踪/_tracking-state.json` 的 `state_revision` 字段——`check` 失败时只往 stderr 打 ERROR，不输出 JSON；不手改派生文件，也不删 `_tracking-state.json` 重来。手写出的逐章记录会让同章 `append` 永久报 `chapter delta N already exists with different content`——删掉那个手写文件后重跑原事务即可。
 

package/lib/oh-story/skills/story-import/scripts/check-outline-contract.js

@@ -18,11 +18,13 @@
 const fs = require('fs')
 const path = require('path')
 
-// 权威模板：references/workflow-setup.md「细纲（全书每章）」
+// 权威模板：references/workflow-setup.md「排纲自查与细纲」里的细纲模板
+// 必填只留有证据或事故撑腰的核心字段；阶段位置、章节定位、结构公式、本章标价、闭环状态、
+// 写手自由区、契约风险、镜头准入、信息差触发点与「分辨率」列是可选的阅读体验字段——
+// 写了照样消费，没写不拦（#383 隔离实验：只补目标情绪与主角目标就复现了补满全部字段的收益）。
 const FIELDS = [
-  '核心事件', '字数目标', '字数口径', '阶段位置', '单元ID/位置', '目标情绪',
-  '主角目标/关键选择', '章节定位', '本章结构公式', '章首钩子', '爽点',
-  '本章标价', '闭环状态', '本章禁止提前释放', '写手自由区', '契约风险',
+  '核心事件', '字数目标', '字数口径', '单元ID/位置', '目标情绪',
+  '主角目标/关键选择', '章首钩子', '爽点', '本章禁止提前释放',
 ]
 const SUBSECTIONS = ['内容概括', '情节安排', '人物关系和出场顺序', '情节细化']
 const FIVE_ACT = ['起因', '发展', '转折', '高潮', '结尾']
@@ -101,7 +103,7 @@ function checkSettingRefs(text, name, file, projectRoot) {
     name,
     missing.length ? `引用的路径不是可用文件：${missing.join('、')}` : `${refs.size} 处项目内引用全部存在`,
     '细纲引用的每个项目内 .md 文件都真实存在——不许把槽位指向查无实据的权威文件',
-    '修正引用路径；或按「创作自主权分级」先把缺的设定落档（B 级直接补、C 级进《供给单》提案），再在细纲引用。'
+    '修正引用路径；或按新增物三级先把缺的设定落档（「写了要报」直接补并登记、「先问作者」进排纲底稿的供给自查提案），再在细纲引用。'
   )
 }
 
@@ -173,8 +175,8 @@ function verify(file, projectRoot = null) {
   let header = null
   for (const line of lines) {
     const cells = parseTableRow(line)
-    // 四列是旧表（# / 情节点 / 功能标签 / 执行边界），五列是现行模板（中间多一列「分辨率」）。
-    // 两种都收：功能标签固定在第 3 列，执行边界一律取最后一列，旧细纲不因加列而失效。
+    // 现行模板默认四列（# / 情节点 / 功能标签 / 执行边界（禁＋放）），需要时在功能标签后加「分辨率」列成五列。
+    // 两种都收：功能标签固定在第 3 列，执行边界一律取最后一列。
     if (cells && (cells.length === 4 || cells.length === 5) && PLOT_HEADER_FIRST.test(cells[0])) {
       header = cells
       break
@@ -189,21 +191,21 @@ function verify(file, projectRoot = null) {
     headerOk,
     name,
     header ? `表头：${header.join(' | ')}` : '未找到 | # | 情节点 | 功能标签 | [分辨率] | 执行边界 | 表头',
-    '情节细化使用五列表格：# / 情节点（谁做了什么） / 功能标签 / 分辨率 / 执行边界（四列旧表仍收，但新建细纲按五列模板走）',
-    '只把情节点序列改成五列表格，逐点补功能标签、分辨率与执行边界；不增删情节点本身。'
+    '情节细化使用表格：# / 情节点（谁做了什么） / 功能标签 / 执行边界（禁＋放）；需要时可在功能标签后加「分辨率」列',
+    '只把情节点序列改成这张表，逐点补功能标签与执行边界；不增删情节点本身。'
   ))
 
-  // 「放」半边：五列表的执行边界必须至少一个点解除限制（模板既有要求），
-  // 全是禁令的情节点表实测会把整章压成同一个温度（015 章十一个点全「不许」）。
-  if (headerOk && header.length === 5) {
+  // 「放」半边：五列表或表头写明「禁＋放」的四列表，执行边界必须至少一个点解除限制，
+  // 全是禁令的情节点表实测会把整章压成同一个温度（015 章十一个点全「不许」）。表头没写「禁＋放」的四列表不追溯。
+  if (headerOk && (header.length === 5 || /放/.test(header[header.length - 1]))) {
     const rows = []
     for (const line of lines) {
       const cells = parseTableRow(line)
-      if (cells && cells.length === 5 && /^\d+$/.test(cells[0])) rows.push(cells)
+      if (cells && cells.length === header.length && /^\d+$/.test(cells[0])) rows.push(cells)
     }
     if (rows.length) {
       const released = rows.filter((cells) => {
-        const match = cells[4].match(/(?:^|[。；;\s])放\s*[：:]([^]*?)(?=(?:禁|放)\s*[：:]|$)/)
+        const match = cells[cells.length - 1].match(/(?:^|[。；;\s])放\s*[：:]([^]*?)(?=(?:禁|放)\s*[：:]|$)/)
         if (!match) return false
         const value = match[1].replace(/[\s。；;，,、\[\]【】]/g, '')
         return value.length > 0 && !/^(?:无|暂无|待补充|待定|无缺口)$/.test(value)
@@ -303,8 +305,24 @@ function resolveChapter(project, chapter) {
   return { file: path.join(dir, hit) }
 }
 
-// --supply：批末验证《供给单》已落卷纲——定位单元卡块，确认其中有「供给自查」小节。
+// --supply：批末验证供给自查已落盘。新书写在卷纲旁的 排纲底稿_{单元ID}.md；老卷纲写在单元卡块内。
+function hasSupplyHeading(text) {
+  return text.split(/\r?\n/).some((line) => {
+    const heading = line.replace(/\*\*/g, '').match(/^#{1,6}\s+(.+)$/)
+    return Boolean(heading) && /^供给自查(?:\s|[（(]|$)/.test(heading[1])
+  })
+}
+
 function verifySupply(volumeFile, unitId) {
+  const draftFile = path.join(path.dirname(volumeFile), `排纲底稿_${unitId}.md`)
+  const draft = readUtf8(draftFile)
+  if (draft.ok) {
+    const ok = hasSupplyHeading(draft.text)
+    return {
+      schema_version: 1, verifier: 'story-long-write.outline-supply', file: path.resolve(draftFile), unit: unitId, ok,
+      evidence: ok ? '排纲底稿含「供给自查」小节' : `${path.basename(draftFile)} 里没有「供给自查」小节——每批出细纲前须做供给自查（含「无缺口」情形），见 workflow-setup.md「排纲自查与细纲」步骤 3`,
+    }
+  }
   const read = readUtf8(volumeFile)
   if (!read.ok) {
     return { schema_version: 1, verifier: 'story-long-write.outline-supply', file: path.resolve(volumeFile), unit: unitId, ok: false, evidence: read.error || '卷纲文件为空' }
@@ -345,7 +363,7 @@ function verifySupply(volumeFile, unitId) {
     file: path.resolve(volumeFile),
     unit: unitId,
     ok,
-    evidence: ok ? '单元卡含「供给自查」小节' : `剧情单元 ${unitId} 的卡内没有「供给自查」小节——每批出细纲前须产出《供给单》（含「无缺口」情形），见 workflow-setup.md「按剧情批出细纲」步骤 3`,
+    evidence: ok ? '单元卡含「供给自查」小节' : `没有 排纲底稿_${unitId}.md，剧情单元 ${unitId} 的卡内也没有「供给自查」小节——每批出细纲前须做供给自查（含「无缺口」情形），见 workflow-setup.md「排纲自查与细纲」步骤 3`,
   }
 }