@oh-story/dsh 0.1.9 → 0.1.11

package/lib/oh-story/skills/story-long-write/references/style-combat-face.md

@@ -1,6 +1,6 @@
 # 装逼打脸与爽点释放
 
-> 装逼打脸框架、爽点释放法则、无敌文要领、打斗/智斗写作、战斗描写三板斧。用于设计装逼打脸场景和战斗场景时查阅。
+> 写装逼打脸与战斗场景用。规则都是必须执行的操作规范：爽点释放法则 > 装逼框架 > 具体描写技巧；该爽不爽，比毒点还毒。
 
 ---
 
@@ -13,18 +13,11 @@
 | 设计战斗/打斗场景 | 打斗/智斗写作 -> 战斗描写三板斧 |
 | 写无敌文主角 | 无敌文核心要领 |
 | 设计打脸节奏和情绪调动 | 打脸节奏与脑洞创意 -> 情绪调动三阶法 |
-| 设计后宫/爱情线 | 后宫文女主人设设计法 / 男频极简爱情线构型 |
 | 写新媒体/短平快装逼 | 新媒体写作与题材套路 |
 | 搭建装逼舞台 | 舞台搭建法 |
 | 打脸写了但不爽 | 检查：爽点释放到位法则 + 前置小无敌准备了吗 + 对手层级够不够 |
 | 战斗场景枯燥/流水账 | 检查：战斗描写三板斧 + 情绪调动三阶法 + 攻防选择、伤势和动作后果是否清楚 |
 
-## 指令语气
-
-本文件以"战术指令"语气书写。装逼打脸和战斗描写是网文核心商业价值所在，所有规则都是**必须执行**的操作规范。爽点释放法则 > 装逼框架 > 具体描写技巧。核心铁律：**该爽不爽，比毒点还毒**。
-
----
-
 ## 爽点释放到位法则
 
 ### 核心问题
@@ -130,56 +123,6 @@
 
 ---
 
-## 后宫文女主人设设计法
-
-### 核心思路
-后宫文的关键是弱化男主"主动渣"的感觉，让女主自身设定成为推动后宫的主力。
-
-### 设计原则
-1. **女主人设要预设方向**：开书前就设计好每个女主的核心特质
-2. **差异化设计**：不同女主有完全不同的价值观和背景
-3. **同居培养感情**：开局让女主们同住一个屋檐下，彼此成为朋友
-
-### 温水煮青蛙法
-以三个女主为例：
-
-| 角色 | 人设设计 | 在后宫中的作用 |
-|------|----------|---------------|
-| 青梅（正宫） | 传统价值观，占据防守位 | 从小一起长大，天然正宫 |
-| 女主B | 家庭圆满家教开明，理性看待感情 | 不在意名分，只在意快乐 |
-| 女主C | 缺少父爱和社交，爱情观模糊 | 不存在一夫一妻制思想束缚 |
-
-核心逻辑：
-- 青梅占据正宫与防守位
-- 另两个女主不在意后宫，只在意跟主角在一起
-- 把"主角脚踏多条船"的问题转化为"青梅防守 vs 另两人共享"的问题
-- 一点一点突破青梅的防守底线，等反应过来时已经是既成事实
-
----
-
-## 男频极简爱情线构型
-
-### 核心原则
-男频爱情线不需要复杂的情感博弈，核心是"英雄救美 + 事业舞台 + 对手衬托"三要素。
-
-### 极简构型
-1. **英雄救美**：女主陷入困境 -> 主角用金手指/实力解决 -> 建立初始好感
-2. **事业舞台**：主角在事业上展示金手指 -> 女主在场作为重要观众 -> 好感随事业成就升级
-3. **对手衬托**：情敌/对手同时是事业对手 -> 打败对手既是事业胜利也是感情胜利
-
-### 关键操作
-- 女主的每一次好感升级都绑定在主角的事业成就上，不单独写纯感情戏
-- 女主有自己的事业线/目标，不是花瓶——她的事业目标与主角有交叉但独立
-- 情敌的价值在于他同时威胁主角的事业和感情，打脸时有双重爽感
-- 感情节奏跟着事业节奏走：事业低谷时感情拉扯，事业高峰时感情升温
-
-### 爱情线与事业线融合检查
-- 删掉所有爱情线段落，事业线是否还成立？如果不行 = 爱情线拖后腿了
-- 删掉所有事业线段落，爱情线是否还有看点？如果不行 = 爱情线太弱
-- 理想状态：两条线互相增强，拆开各自能看，合在一起更好看
-
----
-
 ## 打斗/智斗写作
 
 ### 打斗的本质

package/lib/oh-story/skills/story-long-write/references/style-genre-modules.md

@@ -37,7 +37,7 @@
 
 ### 题材正文提示卡模板
 
-项目可在 Phase 2 生成 `设定/题材正文提示卡.md`。没有该文件时，Phase 4 写前先用 `设定/题材定位.md` 匹配 `genre-prose-cards.md` 索引并读取 `genre-prose-cards/{题材}.md` 单卡；仍无匹配再从本文件即时抽取一张轻量卡。卡片保持短，给 `narrative-writer` 传摘要，不把参考文件整段复制进 prompt。
+项目在写第 1 章前生成 `设定/题材正文提示卡.md`。没有该文件时，Phase 4 写前先用 `设定/题材定位.md` 匹配 `genre-prose-cards.md` 索引并读取 `genre-prose-cards/{题材}.md` 单卡；仍无匹配再从本文件即时抽取一张轻量卡。卡片保持短，给 `narrative-writer` 传摘要，不把参考文件整段复制进 prompt。
 
 ```markdown
 ## 题材正文提示卡

package/lib/oh-story/skills/story-long-write/references/style-resolution.md

@@ -12,10 +12,10 @@
 
 ## 加载与传递
 
-1. 从本次正文路径确定书目录（长篇为 `正文/` 的父目录，短篇为 `正文.md` 所在目录）。读该书 `设定/文风.md`；短篇同时读 `设定.md` 的文风约定。无文件就继续，不创建占位文件、不猜其他书。文风无最低字数限制，一句可执行的偏好也有效；空白、纯标题、待补充不算。
-2. `_文风摘要.md` 只能辅助定位，不能独立替代全文。当前会话已读全文时无需反复读；摘要与全文不一致用全文，不让旧摘要压过作者的新修改。
-3. 作者记忆 query 显式传当前书名、已知题材和流程以及需要的 kind，避免只取到 global。只用 active；同一维度窄范围覆盖宽范围，不拼成同时满足的清单。无法判定的同范围冲突才问作者，已能按优先级解决的不询问。
-4. 在现有 prompt 填 `style_resolution`：本次生效的表达要求及来源、被覆盖的默认条款、必须保留的事实/信息边界；只列与任务有关的冲突，无冲突可写“按本书文风”。原样传给正文、去味和文字 reviewer，并传文风全文路径。同一批次复用，当前请求或文风变动时更新。单独调用去味/审稿也执行本步骤，不能靠上一次会话的记忆。
+1. 从本次正文路径确定书目录（长篇为 `正文/` 的父目录，短篇为 `正文.md` 所在目录）。读该书 `设定/文风.md`；短篇同时读 `设定.md` 的文风约定。无文件就继续，不建占位文件、不猜其他书。文风无最低字数限制，一句可执行的偏好也有效；空白、纯标题、待补充不算。
+2. `_文风摘要.md` 只辅助定位，不替代全文。当前会话已读全文时无需反复读；摘要与全文不一致用全文，不让旧摘要压过作者的新修改。
+3. 有作者记忆时 query，显式传当前书名、已知题材和流程以及需要的 kind，避免只取到 global；没有就跳过。只用 active；同一维度窄范围覆盖宽范围，不拼成同时满足的清单。无法判定的同范围冲突才问作者，已能按优先级解决的不询问。
+4. 在现有 prompt 填 `style_resolution`：本次生效的表达要求及来源、被覆盖的默认条款、必须保留的事实/信息边界；只列与任务有关的冲突，无冲突可写“按本书文风”。原样传给正文、去味和文字 reviewer，并传文风全文路径。同批复用，当前请求或文风变动时更新。单独调用去味/审稿也执行本步骤，不靠上次会话的记忆。
 
 ## 检测器如何服从裁决
 

package/lib/oh-story/skills/story-long-write/references/tracking-initialization.md

@@ -2,7 +2,7 @@
 
 ## 初始化事务
 
-新书从第 0 章初始化。`story-import` 导入已有小说时把最后完整章写入 `last_chapter=N`；第 1..N 章不伪造日更记录，常规续写从 N+1 章开始。
+新书从第 0 章初始化：把下面的 JSON 写到 `{书目录}/.story/work/init.json`，跑 `{PYTHON} {skill 根}/scripts/tracking_commit.py init --project {书目录} --input {书目录}/.story/work/init.json`，成功后删掉临时文件。`story-import` 导入已有小说时把最后完整章写入 `last_chapter=N`；第 1..N 章不伪造日更记录，常规续写从 N+1 章开始。
 
 ```json
 {

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

@@ -18,23 +18,26 @@ 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} {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} {当前 skill 根}/scripts/tracking_commit.py draft  --project {书项目根} --chapter {N}
+{PYTHON} {story-long-write skill 根}/scripts/storyctl.py chapter check   --project {书项目根} --chapter {N} [--min-chars {下限} --max-chars {上限}]
+{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` 及进入内带/用户带所需的机器删除区间。
-- `chapter commit`：再次读取当前文件、重新计数并重跑 blocking quality；只接受用户带内章节，把简短字数记录与逐章事务一起原子提交。
-- `chapter accept-current-length`：只接受带外但 quality pass 的章节；接受动作发生时重新读取、重新计数并立即原子提交，不保存可陈旧的历史决议。
+- `draft`：按当前 state 把逐章事务预填到 `.story/work/第NNN章/tracking.json`（修订号、模式、章名、`context` 四项当前值），并输出各文本字段的字数上限与在场核心角色的当前快照。新章（append）调用方只填 `delta` 与有变化角色的快照；已提交章（revision）的 `delta` 与相关角色快照按该章现有逐章记录预填（伏笔、时间线取当前值），调用方在上面改成修订后的完整记录，不清空重写。
+- 作者字数范围：细纲可写一行 `字数范围：2000-2600`（作者明确给了上下限时）；本轮临时给的范围用 `--min-chars` / `--max-chars`（两者同给，优先于细纲）。`wordcount check` / `checkpoint` 与 `chapter check` / `commit` / `accept-current-length` 都认，给了就同时替代默认 ±12% 内部带与 ±15% 用户带，结果里 `band_source` 为 `author`，提交的字数记录多一项 `author_range`。
+- `wordcount measure` / `wordcount checkpoint`：纯测量入口；不写正文、不写 tracking、不做语义判断。长篇正文只在前组写完后由主会话带 `--project` 调用一次 `checkpoint`（目标与字数范围读细纲，见 workflow-chapter 步骤 6），整章长度由 `chapter check` 收口；`remaining_user_range` 按生效区间（作者区间或默认用户带）计算。
+- `chapter check`：重新读取当前正文与细纲目标，返回确定性长度状态、现有 blocking quality、`state_revision` 和当前可执行动作，不保存 approval。顶层 `status`：`ready`（可提交，exit 0）/ `needs_decision`（长度带外，按 `available_actions` 交作者，exit 0）/ `blocked`（有 blocking 正文问题，exit 1）/ `invalid`（正文为空等，exit 1）/ `tool_unavailable`（找不到 node 或检测脚本，见 `quality.tool_errors`，不是正文问题，exit 3）。参数错误或文件缺失输出 `story-chapter-error/v1`（`status: error`，exit 2）。`under` 不提供自动补写；`over` 额外返回一次净删型 `compress-once` 及回到生效区间所需的删除字数。`quality.semantic_advisories` 是语义类 advisory 条数（检测器标 `review: mechanical` 的不计）。
+- `chapter commit`：再次读取当前文件、重新计数并重跑 blocking quality；只接受生效区间内的章节，把简短字数记录与逐章事务一起原子提交。新章与修订都走它。
+- `chapter accept-current-length`：只接受带外但 quality pass 的章节；接受动作发生时重新读取、重新计数并立即原子提交，不保存可陈旧的历史决议。低于字数目标一半（`BELOW_ACCEPT_FLOOR`），或超长却还没做过那一次压缩（`COMPRESSION_REQUIRED`），都拒绝；作者明确拍板时加 `--force`。
 - `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` 时由调用方删除。已有字数记录的章节正文或目标改过后，`tracking_commit.py commit` 拒绝修订事务，须走 `storyctl.py chapter 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`——删掉那个手写文件后重跑原事务即可。
 
@@ -44,7 +47,7 @@ Markdown 只负责给作者和 Agent 阅读，工具不再反向解析 Markdown
 
 仅新书或导入初始化时，执行 `init` 前必须完整读取 [tracking-initialization.md](tracking-initialization.md)，按其中原始 JSON 与导入边界构造事务。已有项目续写直接使用下方逐章事务，不重复读初始化示例。
 
-调用方的逐章 JSON 不写 `wordcount`；正式入口 `chapter commit` 或 `chapter accept-current-length` 在提交当下生成并注入。最终 state 只为已提交章节保留 `metric / target / actual / status / resolution / body_sha256`，不保存 MEASURE/RESOLVE 事件、ID 链、policy fingerprint 或独立 chapter state。
+调用方的逐章 JSON 不写 `wordcount`；正式入口 `chapter commit` 或 `chapter accept-current-length` 在提交当下生成并注入。最终 state 只为已提交章节保留 `metric / target / actual / status / resolution / body_sha256`（生效了作者字数范围时另加 `author_range`），不保存 MEASURE/RESOLVE 事件、ID 链、policy fingerprint 或独立 chapter state。
 
 ## 逐章事务
 
@@ -119,12 +122,13 @@ Markdown 只负责给作者和 Agent 阅读，工具不再反向解析 Markdown
 - `character_snapshots` 中出现的角色视为核心复用角色，必须同时出现在 `character_changes`；已经建立快照的核心角色再次变化时必须提交新快照。
 - 角色快照的四个列表不限制条数，只限制单项长度和最终文件总字节：目标 ≤4096 字节，超过警告；硬上限 8192 字节，超过则在任何写入前拒绝。
 - 没有快照的角色变化视为临时角色，不建立状态文件；`context.active_character_names` 最多 6 人且必须已有当前快照。
+- `context.long_term_constraints` 最多 6 条：要加第 7 条先合并语义重叠项或请作者取舍，不自动删旧约束；永久生效的设定裁定进它，短期强承诺进 `next_chapter_commitments`，过程决策不进续写状态卡。
 - `context.long_term_constraints` 和 `context.continuity_risks` 是整份提交的当前值。凡是上一版有、本次没有的条目，必须逐条列进 `delta.retired_context_items`，否则工具在任何写入前拒绝——漏写不会被当成删除。实际退役的条目由工具写进本章逐章记录的 `## 本章退役登记`，随后仍可回查。
 - 不再复用的核心角色写进 `delta.retired_characters`：工具删除其当前快照与 `角色状态/{角色名}.md`，并在逐章记录留档。同一事务里不能既退役又提交快照，也不能退役仍列在 `context.active_character_names` 的角色。角色阵亡/退场这一章，把变化照写进 `character_changes` 即可，本章退役的角色不必再交一份马上要删的快照，逐章记录仍按核心角色标注。退役只表示不再进入热上下文，正文与逐章记录不受影响。
 - 两类退役都只能在 `mode=append` 提交。退役表示「从此刻起离开当前状态」，而修订事务的逐章记录属于被改写的旧章，落在那里会谎报退役发生的章节；`mode=revision` 必须原样重交当前全部上下文条目，需要退役就放到下一次 append。
 - `伏笔.md` 只呈现已经埋设过的当前状态。未来规划仍留在大纲。
 - `timeline_events.action` 可为 `upsert/delete`。`未揭示` 的 `reveal_chapter` 必须为 `null`；部分/完全揭示只能填写已经发生的实际章节。
-- `mode=revision` 时，逐章记录必须重算为修订后该章仍然成立的完整连续性记录；当前角色、伏笔、时间线和上下文则提交受影响对象截至最新已写章的当前值。
+- `mode=revision` 时，逐章记录必须重算为修订后该章仍然成立的完整连续性记录（用 `draft` 预填的草稿改，漏写的项会从记录里消失，工具在 stderr 警告被清空的栏目；原有的退役登记原样保留）；当前角色、伏笔、时间线和上下文则提交受影响对象截至最新已写章的当前值。
 - 修订导入截止章内的正文时，会新增或覆盖该章的逐章记录；`imported_through_chapter` 不变。
 
 ## 续写状态卡固定格式

package/lib/oh-story/skills/story-long-write/references/workflow-chapter.md

@@ -1,144 +1,104 @@
 # workflow-chapter.md：单章正文工作流（Phase 4-5）
 
-本文件是「写一章正文」的完整流程。SKILL.md 路由到 Phase 4 后按本文件执行；日更批量由 `workflow-daily.md` 控制批次与追踪事务，每章正文仍走本文件。
+每章正文走本文件（日更批次见 `workflow-daily.md`）。**缺文件就停下修，本轮不写**：`tracking_commit.py check` 不过、缺 `_tracking-state.json`、登记了对标却缺情绪模块／节奏时，读 [stop-and-fix.md](stop-and-fix.md) 照做（作者定了不对标不算缺，组装脚本会报「召回降档：成立，无对标」，照它走）；修好再从步骤 1 开始。
 
-项目文件结构、产物映射、缺失处理和对标权威顺序见 [project-files.md](project-files.md)；首次定位、初始化或缺失时先读取并执行。
-
-本文件提到的 agent 都只检查当前端 canonical 目录；Antigravity 使用 `.agents/agents/agent-name/agent.md`（`agent-name` 为目标 agent 名）和 `invoke_subagent` + 同名 `TypeName`，其余端使用各自 Agent 工具。
+**工作目录**：本章临时文件（前组.md、后组.md、writer_prompt.md、tracking.json）只放书目录下 `.story/work/第NNN章/`，不写系统 `/tmp`、`正文/`、`大纲/` 或书根；提交成功后脚本自动删除。
 
 ---
 
 ## 单章写作流程
 
-当用户准备写某一章时：
-
-1. **检查细纲**：读取 `大纲/细纲_第{N}章.md`，取本章「单元ID/位置」的单元ID，再按 SKILL.md「卷纲不整读（取段器）」跑 `outline_view.py --unit {单元ID} --stage write {卷纲路径}` 拿当前剧情单元、卷契约、全卷常任裁定、本卷主推线/战果、终局底牌边界与风险等级——**不整读卷纲**；**写正文一律 `--stage write`**，批次底稿（供给自查／建纲追加／批次级复检）是排纲期底稿，不进写作回路。脚本 exit 1 时按它的提示修，不改用整读绕过。如果不存在或缺少当前章节蓝图的必需字段，**必须先补建细纲再写正文**，不允许跳过细纲直接写作。补建时参考卷纲中本章对应的事件规划和上下文，补齐阶段位置、结构公式、禁止提前释放、内容概括、情节安排、人物关系/出场顺序、情节细化、结尾设定；无法从已有证据判断的字段写 `[待补充]`，不杜撰副线或关系。补建后按 `artifact-protocols.md` 跑 `check-outline-contract.js` 结构验收，失败只补点名字段再复验。
-2. **读取上下文**（按需选择；缺失时遵循各项及 `project-files.md` 的「缺失文件处理」，仅明确标为可选的非主产物跳过。可选快捷路径：对应 agent 已部署、**且降档不成立**时 spawn story-explorer 一次获取上下文。Prompt：`项目目录：{dir}\n查询类型：context_load\n查询参数：准备写第 {N} 章\n追踪状态：last_committed_chapter={check 的值}，state_revision={check 的值}`）：
-   - (1) `正文/第{N-1}章_*.md` — 上一章正文（**脚本代读结尾**；主会话只在承接存疑时才自己读）
-   - (2) `大纲/细纲_第{N}章.md` — 本章细纲（含钩子设计）。**主会话必读全文**（意图确认、必读设定、涉及角色、本节速记都要它）
-   - (2a) 卷纲 — **走 `outline_view.py --unit {单元ID} --stage write`，不整读**（见 SKILL.md「卷纲不整读」）：当前剧情单元、卷契约与终局储备（主推线/战果、终局底牌边界）、全卷常任裁定
-   - (3) `tracking_commit.py check` + `追踪/上下文.md` — `check` 无 ERROR 输出即通过，从它的紧凑 JSON 取 `last_committed_chapter` / `state_revision`，不把完整 state 加入 prompt。**续写状态卡整份不注入 prompt**：脚本只校验 7 栏完整，状态由主会话读全 7 栏后筛进步骤 7 的「本节速记」槽
-   - (4) `设定/角色/{相关角色}.md`、`设定/势力/{相关势力}.md`（如存在）— 本章涉及的角色与势力（按细纲出场筛选）
-   - (5) 对标书路径下 `拆文报告.md`（按对标书路径查找）— 对标参考
-   - (6) `对标/{对标书名}/原文/第{N}章_*.md`（如存在）— 同位置章节参考
-   - (7) `参考资料/{topic}.md`（如存在）— 历史研究资料（由 story-researcher 产出）
-   - (8) 对标书路径下 `剧情/故事线.md`（按对标书路径查找）— 剧情单元索引，用于确定本章涉及哪些剧情单元
-   - (9) 对标书路径下 `剧情/{相关剧情单元}.md`（按对标书路径查找）— 从索引中选择与本章相关的剧情单元文件
-   - (10) 对标书路径下 `设定/世界观/*.md`（glob，按对标书路径查找）— 从当前拆文产出的主题化设定中获取参考；目录缺失则记录缺口并跳过本项，不读取扁平历史路径
-   - (11) 对标书路径下 `剧情/情绪模块.md`（按对标书路径查找）— 仅全量召回时读取；读者需求 / 情绪引擎、爽文套路框架、可复现模块；缺失按 `project-files.md` 的「缺失文件处理」设置 `missing_primary_contract` 并停止准备
-   - (12) 对标书路径下 `剧情/节奏.md`（按对标书路径查找）— 仅全量召回时读取；关键信息推进、情绪触动点、爆发节奏；缺失按 `project-files.md` 的「缺失文件处理」设置 `missing_primary_contract` 并停止准备
-   - (13) `设定/题材正文提示卡.md`（如存在）— 本书正文层题材卡。**加工在 3(c)，本项只列路径与兜底链**，读一次就直接产出 `genre_prose_card`，不在这里先读一遍再去 3(c) 召回一遍；缺失时从 `设定/题材定位.md` + `references/genre-prose-cards.md` 索引 + `references/genre-prose-cards/` 单题材卡目录（按题材分类优先）+ `references/style-genre-modules.md`（兜底）即时生成 `genre_prose_card`，不阻塞写作
-3. **写前准备**（下面的 3 步是核心方法在单章写作中的落地：筛选状态 → 召回模块 → 确认意图）：
-   - **第 0 步：先跑组装脚本**（可用时）。`{PYTHON} {skill 根}/scripts/build_writer_prompt.py --project {项目根} --chapter {N} --out {留档文件}`，脚本统一输出 UTF-8。stdout 的 `====` 分隔线以上是 prompt 正文、以下是核对报告。主会话只填 `［主会话填］` 空槽。退出码 2 ＝ 数据问题，先修数据再重跑，不得手拼绕过；脚本跑不起来才按步骤 7 回落。
-   - **状态筛选**：从 `追踪/上下文.md` 的 `## 核心角色状态` 取当前角色，从 `## 活跃伏笔` 取需回收/推进项，从 `## 下一章承诺` 取本章必须履行项，输出本节速记（参考 state-tracking.md）。久别角色按名读取 `追踪/角色状态/{名}.md`；只有追查变化原因时才定点查逐章增量。续写状态卡或 meta 不存在时按 workflow-daily 的当前协议处理，不手写替代文件
-   - **模块召回、题材卡与文风召回**：写前完整读取 [benchmark-recall.md](benchmark-recall.md)，执行其中 (a)-(g)、成熟项目降档与 explorer 快捷路径。组装脚本的降档结论、情绪/节奏缺失阻断、本书文风全文及主副对标预算均按该文件执行。
-
-   - **指令确认**：综合细纲、本节速记和模块召回结果，用一句话写清本章意图。
-	     - 新版细纲必须消费：阶段位置、单元ID/位置、主角目标/关键选择、结构公式、禁止提前释放、内容概括、情节安排、人物关系/出场顺序、情节细化、结尾钩子，并对照当前剧情单元的卷契约、本卷主推线/战果、终局底牌边界。
-	     - **细纲优先边界**：正文以本章细纲为唯一剧情蓝图；新增物按三档授权（档表见步骤 7）——一档现场材料直接写、二档写并申报、三档（新主线事件、新反转、新金手指规则、提前写后续章剧情、改变细纲已定结果）不写，**不要用「不自造新剧情」一刀切**。后续阶段真相、底牌、关系结论和终局矛盾不得因为章尾钩子提前泄露。反过来，细纲是"要发生什么"的契约、不是正文的形状：正文可自由编排叙述顺序、合并/穿插情节点，不必一个情节点一段、也不必按五段式顺写，把每个点演成场景而不是照抄概括语（见 writing-craft.md「从细纲到正文」）。
-	     - **细纲语义去重**：同一要求在核心事件、五段式、情节安排和情节点中重复，只算一个语义点；生成前合并，不把重复次数当强调，不沿用提纲原句逐项复述。比如多处都写“不带摄像机、先听完再决定拍不拍”，正文只通过一个自然动作或一句人物判断兑现，不能拆成「至于拍不拍，怎么拍…」「不带摄像机，不带采访灯」两轮说明。
-	     - 爽点出手前要有可指认的危机/期待铺垫；装逼/打脸/揭露章要写在场配角的差异反应。
-	     - 高压/生死/悲痛节拍 要收紧对话声线：搞笑担当让位，信息型角色不当科普嘴，对话逐句承接对方情绪。
-	     - 检查任务卡点：本章如果有“办事被卡住”，它必须卡出信息、关系、代价、选择或伏笔变化；没有就不强补。
-	     - 契约风险检查：按 `references/reader-contract-and-progression.md` 判定 契约安全 / 需补强 / 契约破坏；若高光/收益被配角、机构或偶然性拿走且没有可见交换，先修纲再写。
-     - 例：「快节奏打脸——账单暴露→逼问→反证→公开代价；读者等了三章，这章必须一拳到位。」
-4. **资料研究**（按需）：遇到需查证的外部事实且 story-researcher 已部署时，spawn 搜索并输出到 `参考资料/`；不可用则主线程直接执行。研究完成后再继续写作。
-5. **标题预检**：看脚本核对报告里的重名结论，不重做。报出重名或明显重复时才按本章核心事件改名，并同步细纲标题与正文文件名；脚本不可用时自己比对。
-6. **写作准备**：全章细纲先交给 writer，供它统筹编排；默认同一 session 按前后两组交付。
-   - 依实际叙述顺序，在自然转场或因果停顿处分组，不在一句对话或同一动作中间截断。可交错情节点，但不增删批准内容；分组写清当前要完成的片段，不拆逐点字数配额。
-   - writer 先写前组临时 segment；主会话只调用一次 `storyctl.py wordcount checkpoint --file {segment} --target {目标} --chapter {N}`，把 `actual / remaining_user_range` 连同尚未完成的后组交回同一 writer。两组完成后按原文拼接，不回改前组追字数。
-   - 用户明确要求一次成文时，执行安排填「全章」，直接落盘；不额外跑 checkpoint。无论哪种方式，批准内容写完即停，不为字数加剧情。
-   - 组装后的实际长度由步骤 8 的 `chapter check` 收口；欠长不补、超长只净删一次，仍带外交用户决定。
-   - **正文元信息隔离**：`章节：第{N}章`、`上一章：正文/第{N-1}章_*.md`、`匹配第K章`、`细纲文件` 等只用于定位材料。标题行以外的正文不得出现 `第[一二三四五六七八九十百千万两0-9]+章|上一章|上章|前一章|本章|这一章|前文|后文|伏笔|细纲|读者` 这类写作工程词。需要承接前文时，改成角色能感知的事件锚点或相对时间，例如“比第一章那三秒开火更疼”必须写成“比那三秒开火更疼”。例外：角色在故事世界内真实阅读/讨论“第X章”文本，或真实身为作者/读者并谈论读者身份时，可保留相应词。
-7. **正文执行**：
-   - 按本文件顶部规则确认 narrative-writer 已部署。
-   - **组装走脚本，不逐条手拼**：骨架在步骤 3 第 0 步已生成。脚本提供首行、路径、沿用既有格式的标题、文风、上章结尾与可用的情绪/节拍；主会话核对报告后填槽。**细纲全文、卷纲单元卡、续写状态卡都不进 prompt**；agent 已有规则只传指针。可选块缺失留标题并写明原因。
-   - **主会话填八槽**（搜 `［主会话填］`）：执行安排 ／ 本章意图 ／ 参考技法 ／ 本节速记 ／ 涉及角色 ／ `genre_prose_card` ／ 必读设定 ／ `author_preferences`。填法见槽内提示。作者偏好仅作低优先级倾向，不逐条展示或最大化命中，不牺牲连贯、节奏和字数。降档不成立时情绪与节奏槽也是空槽。填完**空槽以外一字不改，整份照抄进 Agent prompt**；`--out` 留档文件供事后比对。
-   - **回落分两种**：①脚本**跑不起来**（python 缺失、脚本报错、用户指定不走脚本）→ 主会话按手动组装规格补齐脚本负责的材料，报告里声明 `Fallback: build_writer_prompt -> 手动组装`。②脚本**退出码 2**（细纲缺失、续写状态卡缺栏、上一章找不到）→ 不是回落，是停下修数据，修完重跑脚本。
-   - 仅在上述手动回落时加载 [writer-prompt-fallback.md](writer-prompt-fallback.md)，按规格组装同样的输入。
-   - 不把本文件整套规则复制进 prompt；细节以已加载 references 和 narrative-writer 模板为准。
-   - agent 按执行安排交付，主会话将最终正文写入 `正文/第XXX章_章名.md`；主会话核对它只消费了批准情节点。如 agent 未部署，由主线程执行同一流程。
-8. **先核时空表，再非对称收口**：
-   - **核时空表**（交付确认）：细纲每个情节点是否**至少出现一次**——有漏即退回补写（补的是批准内容，不是加戏）；横跨多个时空的点须标注，每一处都要有实在内容。若同一场戏被机械切成逐点清单，按形状层判据核对后局部重织；不同场景或因果依赖所需的串行不因表形退回。这些退回属于覆盖/形状修复，不以字数为由发起。
-   - 运行 `{PYTHON} {skill 根}/scripts/storyctl.py chapter check --project {项目根} --chapter {N}`；文件变更重跑，不存决议。
-   - 带内 + pass → 完成步骤 9-12 的语义核对与新增物裁定后再 `chapter commit`；fail / `invalid` → 停止。
-   - `under` + pass → 展示 `accept-current-length / revise-outline-or-target / discard`，不补/重试；接受命令会重读、重数、原子提交。
-   - `over` + pass → 删除区间随 `compress-once` 交 narrative-writer；一次净删，零新语义/契约改动。会话核对情节点与钩子后复检；带内提交，否则上述三动作。
-9. **检查**：章尾是否有往下看的理由（低压/过场章弱钩子或留阶段目标即可，不强求爽点）、爽点是否到位（按章节定位，高压/推进章必查）。两条可证伪核对（不达标→只修复细纲已批准内容）：① 爽点前是否有可指认的危机/期待段落？② 装逼/打脸/揭露章，在场配角是否有差异化反应？质量修复后重跑步骤 8，但不得借质量修复补新剧情追字数。
-10. **元信息扫描**：检查标题行以外的正文，命中 `第[一二三四五六七八九十百千万两0-9]+章|上一章|上章|前一章|本章|这一章|前文|后文|伏笔|细纲|读者` 时必须改写为场景内表达；只有角色在故事世界内真实阅读/讨论“第X章”文本，或真实身为作者/读者并谈论读者身份时例外。
-	11. **禁用词扫描**：先过**最毒句式速查**（实测最易漏，命中即改）：①「不是A，(而)是B」全家族——含「没有X，没有Y(，只是Z)」排比否定、「是B，不是A」反序、「他没X，也没有Y。他只是Z」先抑后扬，；②声线反差「声音不大/不高…却…」；③「，带着……」万能状语；④预告/总结收尾「没人知道…」「(这)才刚刚开始/开头」「正朝着…压过去」「即将拉开序幕」「这一刻…」；⑤叙述里短词加引号强调（他是被请来"把关"的）。再复核 detector 的 `formulaic-parallelism` advisory：跨段「不是A。/也不是B。/只是C。」、`至于X不X，怎么X`、同动词 `不V A，不V B` 即使写在台词里也不能跳过，确属人物当场的功能性表达才保留。然后对照 `references/banned-words.md` 全表：一级词（高频AI腔）命中即替换；二级词（低频/语境相关）高频出现时替换，偶发可参考 `references/anti-ai-writing.md` 定性裁定
-12. **更新追踪**：最终 `chapter check` 后取最新 `state_revision`，按 workflow-daily 构造不含 `wordcount` 的逐章 JSON。长度在用户带内执行 `storyctl.py chapter commit`；用户接受当前自然长度则执行 `storyctl.py chapter accept-current-length`。两条命令都在提交前重新读取正文和目标、重新计数、重跑 blocking quality，并把简短字数记录与追踪事务一起原子提交。写入失败保留原事务重跑；校验失败重构事务。派生视图损坏按 tracking 文档用 revision 修复，禁止手改。本章首次引入复用角色/势力时，仍按 workflow-setup Phase 3 补建静态档案。**判为「收编」的申报项在这一次事务里一并登记**（映射见「Agent 调用：consistency-checker」的三档表）：漏登记等于没写。有「提请作者确认」项时本章暂停提交、不得继续下一章，裁定后按下表处理；判为「修复」的按修复后的结果登记。
-13. **中途快照**（长篇写作安全网）：每连续写完 3 章，在继续前执行以下快照操作：
-   - 执行 `scripts/tracking_commit.py check`，确认 `_tracking-state.json` 有效、逐章记录连续且未超限、所有派生视图一致、续写状态卡恰好 7 栏且 ≤12288 字节；通过后删除本章逐章事务 JSON 与临时 segment，失败时保留事务 JSON 供原样重跑
-   - 用 `ls -la 正文/` 确认最近 3 个章节文件已成功写入磁盘且大小正常（>100 bytes）
-   - 如果发现文件缺失或大小异常，立即重新写入
-   - 快照完成后可继续写作
-
-> **日更模式**：此步骤自动跳过——workflow-daily Step 2 已按章更新上下文.md。
-
-## 检查分工
-
-步骤 7 写手负责编排、内容覆盖和格式自检；步骤 9–11 及本文件质量检查阶段由主会话统筹，语义去味交给一个执行者（已部署的 narrative-writer 审查者或主会话），完成原 Gate、三遍法与抽查项目。确定性收尾由主会话对最终文件运行；其后若修改正文或白名单，只重跑受影响检查和最终 chapter check，不重新安排一轮全篇语义去味。手动组装时也须把此分工传给写手。
-
-## 写作技巧提醒
-
-| 场景 | 技巧 |
-|------|------|
-| 开篇 500 字 | 必须有钩子，不能从天气/风景开始（除非反差极大） |
-| 对话 | 推进剧情或揭示性格，不能只为了凑字数 |
-| 打斗 | 不要流水账，写策略和反转，不写「你一拳我一脚」 |
-| 日常 | 日常要有人物互动和伏笔，不能只是「吃饭睡觉」 |
-| 任务卡点 | 角色办事被卡住，必须卡出信息/关系/代价/选择/伏笔变化；删掉无损就压缩或删除 |
-| 爽点释放 | 铺垫要充分、释放要干脆，读者等得越久释放越要爽 |
-| 爽点密度 | 高压/推进章每 3000-5000 字一个「爽」的情绪节点；低压/关系/修炼/信息整理章不强求，但每章仍要有往下看的理由（见 references/outline-structure-theory.md「章节定位与张弛」） |
-| 长篇结构约束 | 参考 genre-prose-cards.md 与当前题材卡的长线约束 |
-| 章尾 | 每章结尾都要有让读者想翻下一页的东西 |
-| 情绪验证 | 写完每章回头检查：读者到这里应该感受到什么？感受到了吗？没感受到 → 按章节定位补：高压/推进章补冲突或钩子，低压/关系章补关系或情绪质感，别一律加爽点 |
-
-## 字数测量权威
-
-字数权威默认是细纲 `字数目标` + `visible_chars_v1`：内带 ±12%，用户带 ±15%；**本轮用户明确给出上下限时，原样范围优先于自动比例带**。无节奏下限，缺目标即 `invalid`。带内提交，`under` 不补，`over` 最多净删一次；仍带外由用户接受、改目标/细纲或放弃。下一章只看 tracking 提交。
-
----
+新书还没有 `_tracking-state.json` 时先按 [tracking-initialization.md](tracking-initialization.md) 初始化；已有正文却缺它，按 stop-and-fix 停下修。
+
+1. **检查细纲**：读 `大纲/细纲_第{N}章.md` 全文，取「单元ID/位置」，跑 `outline_view.py --unit {单元ID} {卷纲路径}` 取卷契约、全卷常任裁定、当前剧情单元与终局底牌边界（日更同单元本批复用，不重跑）——**不整读卷纲**。细纲缺失或缺九个必填字段时**先补建再写**：按 workflow-outline.md 细纲模板补齐九个必填字段和四个小节，无证据的写 `[待补充]`，补完跑 `check-outline-contract.js` 验收。
+2. **读取上下文**：`tracking_commit.py check`（取 `last_committed_chapter` / `state_revision`，完整 state 不进 prompt）→ `追踪/上下文.md` 全 7 栏 → 细纲点名的 `设定/势力/`、`设定/世界观/` 相关条目（为「必读设定」槽摘句）；角色卡交给写手时只在「涉及角色」列名字、由写手读，主会话自己写时才读。上一章结尾由脚本代读，承接存疑才自己读。久别角色读 `追踪/角色状态/{名}.md`；更旧的信息按 workflow-daily「旧信息查找步骤」定点查。
+3. **写前准备**：
+   - **先跑组装脚本**：`{PYTHON} {skill 根}/scripts/build_writer_prompt.py --project {项目根} --chapter {N} --out`。`====` 以上是 prompt、以下是核对报告；退出码 2 ＝数据问题，修完重跑，不手拼绕过。
+   - **状态筛选**：从续写状态卡取本章在场角色、要碰/要避的伏笔、必须履行的下一章承诺与相关长期约束，写成本节速记。
+   - **召回**：核对报告写「召回降档：成立」时直接用脚本给的情绪/节奏；不成立时才完整读取 [benchmark-recall.md](benchmark-recall.md) 执行全量召回。
+   - **意图确认**：一句话写清本章意图（例：「快节奏打脸——账单暴露→逼问→反证→公开代价」）。对照：细纲是唯一剧情蓝图，新增物按「新增物三级」；底牌不因章尾钩子提前泄露；细纲重复的同一要求只兑现一次；爽点前有可指认的铺垫，打脸/揭露章写在场配角的差异反应。
+   - **契约风险**：细纲或单元卡标了需补强，把单元卡写的补强办法（交换、铺垫或成本）写进本章意图；标了契约破坏，先按 workflow-outline 补纲流程修纲再写；标契约安全的写前不重问，写后在步骤 9 核。
+4. **资料研究**（按需）：需查证外部事实时 spawn story-researcher 输出到 `参考资料/`，不可用则主会话查。
+5. **标题预检**：看核对报告的重名结论；重名或明显重复才按核心事件改名，并同步细纲标题与正文文件名。
+6. **写作准备**：交给写手时按 [agent-calls.md](agent-calls.md)「写一章」分前后两组交付；主会话自己写时也分两组：前组写到 `前组.md` 后跑一次 `storyctl.py wordcount checkpoint --file {前组} --project {项目根} --chapter {N}`，后组按 `remaining_user_range` 收、原文拼接；作者要一次成文才写全章。批准内容写完即停，不为字数加剧情；实际长度由步骤 8 收口。
+7. **正文执行**：已部署 narrative-writer 时按 [agent-calls.md](agent-calls.md)「写一章」填槽交给它，交付后核对它只消费了批准情节点。未部署则主会话自己写：不填槽，按脚本输出与本节速记直接写，新增物自列申报表。写完逐段再看一遍检测器抓不住的三类 AI 腔：用工整对仗或金句替读者点题；叙述者跳出来总结情绪、解释动机、说出细纲的结论；章尾用感悟、升华或预告收。遇到就删，或改成人物的动作、对话、物件，让读者自己看出来。
+8. **核情节点落点，再一次检测收口**：
+   - 细纲每个情节点**至少出现一次**，漏即退回补写批准内容。不以字数为由。
+   - 运行 `{PYTHON} {skill 根}/scripts/storyctl.py chapter check --project {项目根} --chapter {N} --fix-punctuation`：一次整理标点并跑 AI 句式、`check-degeneration.js` 退化、细纲照搬与字数检测（去味管线：检测器 → 选 Gate → 一次定点改写 → 复扫）；文件改动后重跑，不再分别调各检测脚本。
+   - 按返回的 `status` 走：`ready` → 完成步骤 9-12 再提交。`blocked` / `invalid`（退出码 1）→ 就地修净再重跑。`needs_decision`（字数出带）→ 看 `available_actions`：欠字不补不重试，按字数问法请作者选；超字把删除区间随 `compress-once` 交 narrative-writer 一次净删、零新语义，复检仍带外也请作者选。`tool_unavailable`（退出码 3，见 `quality.tool_errors`）→ 不能提交、无绕过，用停下问法告诉作者要装 Node.js 18+ 才能做写后检查。退出码 2（`status: error`）按 `error_code` 修命令。
+9. **检查钩子、爽点与契约**：章尾有往下看的理由（低压/过场章留阶段目标即可）；高压/推进章爽点到位；对着成稿过契约四问——主角是否靠自己的选择挣到本章结果？收益是否被配角、机构或巧合无交换地拿走？有没有提前动用后面的底牌？旧期待付利息、留新期待了吗？任一问不过就按问改：没挣到→让结果落在他的选择或判断上；收益被拿走→补交换或让他拿回控制点；提前用了底牌→换成本卷已解锁的手段；没付利息→给旧期待一个小兑现再留新钩。不达标只修批准内容，修后重跑步骤 8；需补强、契约破坏都在本章汇报里告诉作者。
+10. **元信息扫描**：标题行以外清掉第X章、上一章、本章、前文、后文、伏笔、细纲、读者这类工程词，改成角色能感知的事件锚点（「比第一章那三秒开火更疼」→「比那三秒开火更疼」）；角色真实读到「第X章」或本身是作者/读者的除外。
+11. **检测结果处理**（选 Gate 与定点改写）：严重度读作必须修 / 建议看 / 仅提示——检测器 blocking 与 checker 的 S1/S2 必须修，advisory 与 S3 建议看，S4 仅提示。`quality.blocking_findings` 就地改到净；`advisories` 逐条读原文判断，确属问题才改，不为归零机械改写。`formulaic-parallelism` 连同台词一起复核；细纲照搬里判定保留的补进细纲「复沓锚句」（这是登记，不算改大纲，不用暂停问作者）。禁用词表不整读，拿不准的二级词才查 `references/banned-words.md` 对应条目。改完只重跑步骤 8 复扫，不另安排全篇去味。
+12. **更新追踪**：运行 `{PYTHON} {skill 根}/scripts/tracking_commit.py draft --project {项目根} --chapter {N}`，预填工作目录 `tracking.json`，并给出在场核心角色的当前快照和每类条目的样板（`shapes`）。只填 `delta` 与留空的本章结尾时间、场景：变化的核心角色（含本章首次进场的核心角色，草稿里没有就新建一份）把快照整份改好放进 `character_snapshots`；撤下的长期约束或风险从 `context` 删掉并把原文列进 `delta.retired_context_items`。不读脚本源码或 state 找格式；出错或 `mode=revision` 时才读 [tracking-transaction.md](tracking-transaction.md)。带内执行 `{PYTHON} {skill 根}/scripts/storyctl.py chapter commit --project {项目根} --chapter {N} --input {工作目录}/tracking.json`，作者接受当前长度把 `commit` 换成 `accept-current-length`。报错按提示改完重跑同一命令；体积超目标只是提醒，逐章记录写要点即可，不必为它删改。判为「登记」的申报项在这次事务里一并登记；有「先问作者」项时暂停提交与下一章。「本章没写成的」：细纲没给的追加进本单元排纲底稿「建纲追加」，先问作者的走下方处置表。
+13. **提交后核对**：返回 `tracking_committed: true` 即本章完成。
+
+## 向作者汇报
+
+按 SKILL.md「面向作者的汇报」，下列时机照模板说；`{}` 换成故事里的话，其余内部结论不说给作者。提交成功、本章完成后（日更批量改用 workflow-daily 批末汇报）：
+
+<!-- author-report -->
+```md
+第{N}章《{章名}》写好了，约 {字数} 字。
+这章：{两三句讲发生了什么，停在哪个钩子上}。
+{有需作者留意的新人物/新设定就一句话，如「加了个跑腿的小厮阿福，后面可能还会用」；没有就删掉此行}
+{这章主角的功劳被别人拿走、或提前用了后面的底牌时，一句话说哪里、怎么补或要不要改纲；没有就删掉此行}
+{自查结论一句话：「自查过设定和前文，没发现冲突」或「发现一处前后不一：{什么}，已按前文改正」}
+下一章：第{N+1}章《{章名}》，要接着写吗？
+```
+
+字数一次处理后仍不在范围内时，请作者选，不自行补写：
+
+<!-- author-report -->
+```md
+第{N}章《{章名}》写完了，比目标{少/多}了约 {差额} 字（目标约 {目标} 字，现在 {实际} 字）。{一句原因，如「细纲的事写完就到这儿了，硬凑会注水」}
+你想怎么处理？
+1. 就按现在的长度收下（推荐）
+2. 我改细纲或字数目标，再重写这章
+3. 这章不要了
+```
+
+不到目标一半时选项 1 不标推荐。作者选 1 → `chapter accept-current-length`；选 2 → 等作者改完细纲/目标后回步骤 8；选 3 → 删本章正文与工作目录，不提交。收下被拒时：`BELOW_ACCEPT_FLOOR` 告诉作者差多少字，问补写还是就要这个长度；`COMPRESSION_REQUIRED` 先按 `compress-once` 删一次。作者知道原因仍坚持才加 `--force`。新增内容需要作者拍板（下方处置表「先问作者」）时：
+
+<!-- author-report -->
+```md
+第{N}章{写的时候多出了一样东西 / 写到一半想加一样东西，还没写}，需要你定：{用故事话说是什么}。
+它会牵动{后面哪段剧情或哪个已定安排，如「原定第三卷才揭开的那封信」}。
+1. {留下 / 加上}，我把后面的大纲一起改过来
+2. {删掉 / 不加}，按原细纲写
+我建议选 {1/2}：{一句理由}。
+这章先不算写完，等你定了再往下。
+```
+
+写不下去、要停下时：
+
+<!-- author-report -->
+```md
+第{N}章还没法写：{白话说缺什么，如「这一章还没有细纲」}。
+建议{一个动作，如「我先按卷纲把这章细纲补出来给你看」}，可以吗？
+```
 
 ## 质量检查
 
-检查三个维度：(1) **情绪交付**——每章是否交付了细纲中规划的目标情绪？(2) **契约风险**——按 `references/reader-contract-and-progression.md` 检查因果权 + 结算权、关键节点四问、期待所有权、期待债、终局储备（透支两问）与换书债；章级推进按权威文件的七类状态分档（快节奏保留可见事件/爽点下限），强弱相对本书题材与对标判断，标记 契约安全 / 需补强 / 契约破坏；契约破坏 先修正文或修后续纲。(3) **技术质量**——一致性、格式、禁用词。参考 [references/long-chapter-quality.md](long-chapter-quality.md) 中的通用检查和长篇专项清单。
-
-**新增内容边界**：按 writer 三档执行。现场材料直接使用；既有框架内的新配角、设定或关系细节可写并申报，由下方处置表裁定。新主线事件、反转、金手指规则、伏笔结算、提前写后续剧情或改变细纲结果属于 blocking，停止提交并报告。不得把所有新增关系或具名配角一律判为偏纲。
-
-**正文元信息扫描**：按上方步骤 10 清掉标题行以外的写作工程词，再进入其他检查。`check-degeneration.js` 会确定性复扫这一项。
-
-**写后同轮清零**：正文落盘不是汇报时机——每章落盘后必须在**同一轮**内跑完上方步骤 10-11 扫描、下方确定性收尾脚本与 narrative-writer 审查，blocking 清零才算本章完成；不得先汇报"已写完"再等指示。写后 hook 会对落盘正文自动扫描确定性毒句式并把命中推回——那是兜底网不是替代，hook 报出的命中当轮清零。**唯一豁免**：用户显式说"本章不去味/跳过检查"——豁免时在该章标题行下加一行 `<!-- 去味:跳过 -->`（写后 hook 的毒句式推回与写下一章前的欠账拦截都认这个标记；其余网照常）。
-
-**确定性收尾**：本批正文写完后，主会话对实际落盘文件运行 `node scripts/check-ai-patterns.js --check --fail-on=blocking 正文/第XXX章_*.md` 与 `node scripts/check-outline-copy.js 正文/第XXX章_*.md`（细纲照搬复扫）。blocking 命中先回正文改写并复扫；advisory 与细纲重合逐条读原文判断，确属问题才改，功能性写法标 `[需复核]`——每条都要有结论，不为归零机械改写；细纲重合里判定保留的补进细纲「复沓锚句」，下章起不再复报。其中 `formulaic-parallelism` 必须连同对话一起复核，不能因为 hook 不阻断台词就略过；`stock-reaction-tic` 的候选交下方 narrative-writer 质检 spawn 逐处做「反套话四问」删除测试并直接改——**写手不写验收短文**（验收由质检 spawn 的删除测试承担），质检报告列出候选数、删改数与保留理由即可。
-随后运行 `node scripts/normalize-punctuation.js 正文/第XXX章_*.md`（默认 `--quote-mode keep`）清理无功能省略号、破折号、双连字符和独立分隔线；盐言「」不受影响。主会话以最终落盘文件复扫验收，不以 agent 自检代替。
+字数范围按 SKILL.md 写前必读第 4 条。三个维度：**情绪交付**（交付了目标情绪吗）、**契约风险**（步骤 9 契约四问）、**技术质量**（一致性、格式、禁用词；排查具体问题时才读 [long-chapter-quality.md](long-chapter-quality.md)）。
 
-**退化防护**：正文落盘后运行 `node scripts/check-degeneration.js --check 正文/第XXX章_*.md`。blocking（复读、截断、拒绝语、tier1 工程词泄漏）只重写受影响章节，最多 2 次；仍失败就报告证据让用户定夺。
-advisory 只提示可疑处，先看脚本给出的例外；故事内系统/界面用语、弹幕刷屏、重复台词等有功能则保留。
+**写后同轮清零**：同一轮内完成步骤 8-11，blocking（含写后 hook 推回的毒句式）清零才算本章完成。**唯一豁免**：用户显式说"本章不去味/跳过检查"时，在该章标题行下加一行 `<!-- 去味:跳过 -->`（写后 hook 与下一章前的欠账拦截都认它）。退化类 blocking（复读、截断、拒绝语、工程词泄漏）只重写受影响段落，最多 2 次，仍失败按停下问法请作者定夺；故事内系统用语、弹幕、有功能的重复台词保留。
 
 ### Agent 调用：consistency-checker
 
-质量检查阶段，consistency-checker 已部署时，仅按当前运行时的 canonical agent 目录检查并 spawn，获取 S1-S4 报告。Prompt：`项目目录：{dir}\n检查范围：{本次写作的章节}\n检查类型：事实冲突+伏笔断线+角色属性不一致\n本章新增申报：{writer 交回的申报表原样粘贴，无则写 0}；同时核对正文是否有未申报的跨章事实，尤其新增证词、证据、承诺与关系变化，逐处列出原文和细纲出处。对各新增项跑一遍你现有的实体/设定/时间线/规则边界/跨章因果/代价一致性扫描，冲突按 S1-S4 报出`。不可用则主线程参照 long-chapter-quality.md 直接检查。
+**按需调用**：写手申报表非 `0`，或核对细纲时发现未申报的跨章事实（新证词、证据、承诺、关系变化）才在本章 spawn；否则日更批末核对时整批查一次（workflow-daily Step 3），非日更的单章写作在步骤 12 提交前对本章查一次。Prompt 见 [agent-calls.md](agent-calls.md)。不可用则主会话自己核：申报项与跨章事实是否与细纲、角色卡、已登记追踪冲突；承诺与伏笔有没有被遗忘或无推进；有没有突然塞进大量新设定。
 
-**新增申报三档处置**（在本节做：正文已定稿、tracking 未提交）。checker 只给事实层证据，**分档判定归主会话**——「能不能收编」「会不会偏离后续」是创作判断，checker 明文不做也判不了。逐条按下表处置：
+**新增物处置（主会话）**（正文定稿、追踪未提交时做）。checker 只给事实证据，归哪一栏由主会话判：
 
-| 档 | 判据 | 出口 |
+| 处置 | 判据 | 出口 |
 |---|---|---|
-| **① 收编** | 无 S1/S2；**不需要在卷纲占编号或占行**——不占「本卷伏笔」的 F 编号、不占「本卷故事线」的 L 编号、不在「本卷反转」或「本卷打脸债」里新增行；且不碰卷纲「本卷主推线/战果」「终局底牌边界」，不与 `## 活跃伏笔` / `## 下一章承诺` 打架 | 进步骤 12 那次逐章事务：角色/势力按 workflow-setup Phase 3 补建静态档案；可复用设定增量补进 `设定/世界观/{主题}.md`；伏笔进 `foreshadow_changes`；关系/状态进 `character_changes` + 角色快照；跨章约束进 `constraints`；下章要接的进 `next_chapter_commitments` |
-| **② 修复** | S1 / S2 | 退回 writer 就地改正文或删掉该新增物。最多修复一次；首次写作尚未提交时按修后事实构造首次事务，已有提交的章才用 `mode=revision` |
-| **③ 提请作者确认** | 需要在卷纲新增 F/L 编号或反转/打脸债条目，碰主推线/终局边界、可能与既有承诺冲突，或需作者创作决策 | 在报告列新增物、正文落点、后续义务与冲突出处。本章保留为待审稿，暂停 tracking 提交及下一章；不将待裁定事实混入已提交状态 |
+| **登记** | 无必须修的冲突，也不属先问作者项 | 角色/势力按 workflow-outline.md「细纲后设定补全」补建静态档案、可复用设定补进 `设定/世界观/{主题}.md`，由主会话直接改设定文件（追踪事务不写设定）；伏笔、关系、约束、下章承诺进步骤 12 事务的对应 delta 字段 |
+| **修复** | 有必须修的冲突 | 退回写手就地改正文或删掉该新增物，最多一次 |
+| **先问作者** | 先问作者项（SKILL.md「新增物三级」），或冲突要靠创作决策；「本章没写成的」里标先问作者的也走这行 | 按拍板问法问作者（已写的问留不留，没写的问「还没写，要不要加」）；本章暂停提交及下一章。作者接受则按授权改卷纲/设定（没写的补写）后提交，不接受则删改后提交 |
 
-- 拿不准归第三类。作者接受后，按其授权更新卷纲/设定，再将完整正文事实写入本章首次事务；已有提交的旧章用 `mode=revision`。作者不接受则删改该新增内容、复检后提交。不要先提交缺项 delta、等下批补账。
-- 申报与处置记录随本章报告留存；不自动改写锁定细纲。
-- 申报为 `0` 仍做正文与细纲的正常核对；发现漏报的跨章事实，照本表处置。确实无新增则跳过申报处置。
+申报为 `0` 仍做正文与细纲的正常核对，发现漏报照本表处置。
 
 ### Agent 调用：narrative-writer（去AI味审查）
 
-质量检查阶段，narrative-writer 已部署时可 spawn 文字质量与去AI味检查。Prompt：`项目目录：{dir}\n任务描述：审查+去AI味\n检查分工：你负责本次语义去味及原定自检；最终文件扫描由主会话执行，不在子代理内重复\n检查范围：{本次写作的章节}\n文风路径：{与写作 spawn 同一口径——传 `设定/文风.md` 全文路径，摘要仅作索引}\nstyle_resolution：{与写作一致的本次文风裁决，含全文路径}\n作者偏好：{本章 query 命中的 prose_style/story_design 项}\n删除优先：每条 AI 味项先判能否删除——删后不丢伏笔/钩子/角色/情节/必要信息的直接删，会丢才润色（删除受比例上限与字数下限约束，跌破下限改降AI重写）\n检查项按你自己的 7 Gate、禁止事项与写完后对话自检全量执行，其中否定翻转句式和台词里的工整否定清单不因脚本豁免台词而跳过\n反套话删除测试：对 stock-reaction-tic 报出的每处候选按 writing-craft.md「反套话四问」做删除测试——删后不丢信息/选择/关系/物件变化/物理后果的直接删，保留的在报告里写明它新增了什么；报告列候选数/删改数/保留理由\n写法抽查（删除测试口径，只指认已有问题、不回头补内容）：对爽点/高潮段与 detector 标记处抽查四项——状态台阶（强弱变化有没有台阶）、同类递减（并列同类项是否递减）、密处禁概括（慢镜头段有没有用概括句糊过去）、最重的一句最短；命中即改并在报告列出，不通读全文逐句追问`。不可用则主线程按 `references/anti-ai-writing.md` 与 `references/banned-words.md` 执行。
+**按需调用**：步骤 8 的 `quality.semantic_advisories`（语义类 advisory 条数）≥3，或 blocking 一次就地修改后仍未清零，才 spawn 一次；否则主会话按步骤 11 处理。Prompt 见 [agent-calls.md](agent-calls.md)。不可用（主会话自己写）时不读去味细则：逐条按检测器那条提示改，先判能否直接删（删后不丢伏笔、钩子、角色、情节和必要信息就删），会丢才改写；blocking 改到净，advisory 确属问题才改。语义提示仍多时照常收口，在汇报里建议作者之后另开对话用 `/story-deslop` 精修。
 
-检查后若正文修订改变了连续性事实，必须构造 `mode=revision` 的同章追踪事务并执行 `scripts/tracking_commit.py commit`：
-- 伏笔变化用 `foreshadow_changes` 更新同一 ID 的当前行，不追加重复历史；
-- 时间线变化写入 `timeline_events`，由 `_tracking-state.json` 统一派生 `作者真相.md` 与 `读者已知.md`，不得把作者秘密泄露到读者视图；
-- 核心角色状态变化同时提交该角色截至当前章的完整快照；
-- 事务失败后保留原事务 JSON，修正写入环境并重跑同一 `commit`；成功后执行 `check`，确认 state 与全部派生视图一致，删除该临时事务 JSON 后再继续写作。
+审查在本章提交前改的连续性事实直接进步骤 12 的事务；提交后再改，按 workflow-revision：`draft --chapter {N}` 预填 → 改 → `chapter commit`。