@oh-story/dsh 0.1.9 → 0.1.11

package/lib/oh-story/skills/story-review/references/character-relations.md

@@ -151,7 +151,7 @@
 
 检查角色行为是否只是为了让剧情往某方向发展。如果角色"恰好"做了推进剧情的事但没有自身动机，标记为"人设偏移"，必须为该行为补充角色层面的合理理由。
 
-### 第二步：情绪目标确认
+### 第二步：目标情绪确认
 
 写每段前明确三个要素：
 1. 本段目标情绪：这段剧情要让读者产生什么情绪？
@@ -368,6 +368,54 @@
 
 ---
 
+## 后宫文女主人设设计法
+
+### 核心思路
+后宫文的关键是弱化男主"主动渣"的感觉，让女主自身设定成为推动后宫的主力。
+
+### 设计原则
+1. **女主人设要预设方向**：开书前就设计好每个女主的核心特质
+2. **差异化设计**：不同女主有完全不同的价值观和背景
+3. **同居培养感情**：开局让女主们同住一个屋檐下，彼此成为朋友
+
+### 温水煮青蛙法
+以三个女主为例：
+
+| 角色 | 人设设计 | 在后宫中的作用 |
+|------|----------|---------------|
+| 青梅（正宫） | 传统价值观，占据防守位 | 从小一起长大，天然正宫 |
+| 女主B | 家庭圆满家教开明，理性看待感情 | 不在意名分，只在意快乐 |
+| 女主C | 缺少父爱和社交，爱情观模糊 | 不存在一夫一妻制思想束缚 |
+
+核心逻辑：
+- 青梅占据正宫与防守位
+- 另两个女主不在意后宫，只在意跟主角在一起
+- 把"主角脚踏多条船"的问题转化为"青梅防守 vs 另两人共享"的问题
+- 一点一点突破青梅的防守底线，等反应过来时已经是既成事实
+
+
+## 男频极简爱情线构型
+
+### 核心原则
+男频爱情线不需要复杂的情感博弈，核心是"英雄救美 + 事业舞台 + 对手衬托"三要素。
+
+### 极简构型
+1. **英雄救美**：女主陷入困境 -> 主角用金手指/实力解决 -> 建立初始好感
+2. **事业舞台**：主角在事业上展示金手指 -> 女主在场作为重要观众 -> 好感随事业成就升级
+3. **对手衬托**：情敌/对手同时是事业对手 -> 打败对手既是事业胜利也是感情胜利
+
+### 关键操作
+- 女主的每一次好感升级都绑定在主角的事业成就上，不单独写纯感情戏
+- 女主有自己的事业线/目标，不是花瓶——她的事业目标与主角有交叉但独立
+- 情敌的价值在于他同时威胁主角的事业和感情，打脸时有双重爽感
+- 感情节奏跟着事业节奏走：事业低谷时感情拉扯，事业高峰时感情升温
+
+### 爱情线与事业线融合检查
+- 删掉所有爱情线段落，事业线是否还成立？如果不行 = 爱情线拖后腿了
+- 删掉所有事业线段落，爱情线是否还有看点？如果不行 = 爱情线太弱
+- 理想状态：两条线互相增强，拆开各自能看，合在一起更好看
+
+
 ## 质量检查清单
 
 每次完成角色关系/感情线设计后，逐项核查：

package/lib/oh-story/skills/story-review/references/dialogue-mastery.md

@@ -47,6 +47,10 @@
 | 所有角色说话方式一样 | 模糊 |
 | 对话说服人物 | 现实中没人被几句话说服，用突发状况代替 |
 | 情绪写完方向变了 | 需回退到情绪拆分 |
+| 捧哏工具人、鹦鹉复读对方原话 | 配角只剩接话功能 |
+| 高位者长篇自证、说话不分场合 | 身份和处境塌了 |
+| 情绪水肿咆哮、生死场景嘴碎 | 越吵越不紧张 |
+| 悬念正攒着就被台词说破 | 期待提前泄掉 |
 
 ---
 

package/lib/oh-story/skills/story-review/references/review-quality.md

@@ -97,6 +97,7 @@
 ### 五维评分标准
 
 每个维度 0-100 分，根据评分结果选择精修策略。
+严重度：critical、high＝必须修；medium＝建议看；low＝仅提示。
 
 ### 维度 1：核心一致度
 检查：关键冲突、关键行动、人物动机是否前后一致。
@@ -124,7 +125,7 @@
 | 问题 | 严重度 | 修复 |
 |------|--------|------|
 | 机械按字数切段或主语过密 | medium | 按戏剧单元重排段落，段首点名、段中代词/省略、关键转折再点名 |
-| 章节字数偏离目标 | **high** | 写作/大纲修复时先回到细纲补足计划内情节点，再展开；去AI味已有正文时不得新增剧情 |
+| 字数不在目标范围 | medium（长篇欠字交作者定）；短篇 **high** | 先核对情节点是否都写到；都写到就不为字数加戏。长篇欠字交作者选、超字最多净删一次；短篇整篇须进入锁定范围，缺情节点才补；去AI味已有正文时不得新增剧情 |
 | 格式混乱（对话/描写不统一）| low | 统一格式 |
 
 ### 维度 4：可读性
@@ -160,19 +161,13 @@
 | AI 腔重 | de_ai | 替换禁用词、改写句式 |
 | 小问题多 | polish | 打磨语言细节 |
 
-### 读者契约与终局储备双向审查
+### 读者契约审查
 
-审稿先问“无毒吗”，再问“好看吗”：**无毒不等于好看**，没有 契约破坏 只代表不踩雷，还要确认情绪兑现足够强。风险标记三档：契约安全（与开篇承诺一致、主角保有关键选择、收益归属清楚）/ 需补强（可能稀释高光或推进过快，但能靠铺垫、交换、代价修复）/ 契约破坏（核心卖点被没收或无关角色夺走期待所有权，需修纲）。
+审稿先问“无毒吗”，再问“好看吗”：没有契约破坏只代表不踩雷，还要确认情绪兑现足够强。
 
-- [ ] 读者契约：本章/本卷是否兑现开篇承诺，还是把核心卖点交给机构、配角或偶然性？风险标记：契约安全 / 需补强 / 契约破坏。
-- [ ] 主角代理权：按因果权 + 结算权审查，而非按出场时长；关键节点核对四问——谁决定事情为什么发生、谁作出不可替代的选择、谁承担或选择关键后果、核心收益/认可/权力结算给谁。配角可执行局部动作，但不能无声夺走期待所有权。
-- [ ] 期待债：承诺是否被偿还、延期并支付利息，还是被解释/流程/设定吞掉？
-- [ ] 终局储备：本单元是否动用了本阶段还不该解锁的终局底牌（宿敌/真相/身份/金手指上限）？是否让某条升级线逼近天花板、后面没台阶接？两问皆否即放行——单章一战多得（多线齐涨）是好设计，不算超速。
-- [ ] 兑现归属：期待所有权是否按承诺结算；自愿让渡只有在“长期净收益为负 + 控制/因果权下降”同时出现时亮红灯，战略性让步的更大控制/未来收益/权力/信息交换是否可见？
-- [ ] 节奏续接：高潮/兑现后是否允许短暂低压和小而可见的收益/奖励，而非机械立即加危机？新元素是否支付换书债、没有逃避旧承诺？
-- [ ] 题材特定风险：履约爽文/能力幻想中，主角是否反复以愚蠢或可避免的无能制造灾难并由他人收拾，损害因果权与结算信任？
+- [ ] 按契约四问审：1. 主角是不是靠自己的选择挣到了结果？2. 核心收益或高光有没有被配角、机构或巧合无交换地拿走？3. 有没有动用本阶段还不该解锁的终局底牌，或把某条升级线顶到天花板？4. 旧期待付了利息没，又给读者留了什么期待？新地图、新机构、新谜团有没有被拿来逃避旧承诺？四问都过＝契约安全，能靠铺垫、交换、成本补上＝需补强，补不上＝契约破坏。
 - [ ] 反向审查：若删除“安全解释”，情绪是否更强？若保留风险情节，是否带来更强期待、代价或爽点？
-- [ ] 综合线：契约、主角代理权、期待债、终局储备是否互相支撑，而不是只做到“无毒”。
+- [ ] 高潮或兑现后是否允许短暂低压和小而可见的收益，而非机械立即加危机？
 
 ---
 

package/lib/oh-story/skills/story-review/references/review-tracking.md

@@ -0,0 +1,10 @@
+# story-review：审查收尾的追踪文件维护
+
+新追踪协议只有一个写入口：本 skill 的 `scripts/tracking_commit.py`；完整事务字段和命令见 `references/tracking-transaction.md`。**full / lean 模式只允许通过该工具修改 `追踪/`；solo 模式不修改任何 `追踪/` 文件。**不得直接 Edit/Write/追加 `伏笔.md`、角色快照、时间线视图、摘要或 `上下文.md`。
+
+1. **先检查状态**：执行 `tracking_commit.py check --project {项目根}`，确认 `_tracking-state.json` 与全部派生视图一致。失败时重跑产生当前目标状态的原事务，不得猜测、手改 Markdown 或另造事务覆盖。
+2. **判定是否需要修订**：只有正文证据表明现有追踪事实错误或缺失时才维护。过期伏笔、漏登记开放钩子、角色当前状态、客观时间线、读者认知都归入其证据所在章的 `mode=revision` 事务。普通审查意见和未来写作建议不进追踪。
+3. **构造完整同章事务**：先跑 `tracking_commit.py draft --project {项目根} --chapter {N}`，草稿已按该章现有记录预填；保留该章原有紧凑增量中仍成立的字段，只修改有证据的变化；核心角色变化同时提交截至当前最后已写章的完整 `character_snapshots`。伏笔对同一 ID `upsert` 当前状态，不增加重复行；时间线同时提交客观事实、读者当前认知和实际揭示状态。
+4. **提交并复检**：执行 `tracking_commit.py commit`，再执行 `check`。确认逐章记录规范且未超限、`上下文.md` 恰好固定 7 栏且 ≤12288 字节、作者/读者时间线及全部派生视图与 state 一致。
+
+例如审查 demo 第 10 章时，若正文明确显示周薄森说专业重拍版“缺了灵魂”、张耀祖拍板继续用江晨手机原版，修订事务可以把该结果写进客观事实和读者已知；钟嘉嘉“只猜对了一半”背后的培养安排如果正文尚未揭示，只能留在作者真相，不能写入读者视图。

package/lib/oh-story/skills/story-review/references/solo.md

@@ -0,0 +1,52 @@
+# story-review：solo 模式
+
+不 spawn Agent。先按 Phase 1 第 4 步识别目标平台并加载对应 rubric；即使是 solo，也必须用平台 rubric、`story-review/references/quality-rubric.md` 或内置审查基准包校准判断。
+
+solo 必须执行基础检查：
+1. 格式合规性检查：按戏剧单元/画面分段而非机械按字数切分（偶发稍长的完整推理、氛围或情绪链不算违规，通篇同阈值切段或碎成提纲才算）；段首建立主语、段中用代词或省略，连续无必要重复同一角色名才算主语过密；无段间空行；对话独立成行；具体数字须确认统计正确且有叙事必要。
+2. 简单的设定一致性 grep（角色名、属性、关键设定、伏笔关键词）+ 推理型一致性检查（规则边界、设定层级、跨章因果链、可滥用漏洞、代价一致性）。
+3. AI 味与禁用词检查：先读 `story-review/references/banned-words.md`，一级禁用词逐个核查、出现即报——预检脚本对高频套话只做密度统计、另查固定句式（否定翻转、破折号、章尾预告等），不会逐个报一级词，不能拿脚本结果代替。再读 `story-review/references/anti-ai-writing.md` 的「AI写作指纹」「10 种 AI 写作模式检测」两节，判断解释腔、告知式情绪、二级词滥用（该文件的改写顺序与范例是改稿用的，审稿不照做）。脚本命中逐条复核是不是功能性写法；两份文件不可读时用内置 AI 味 / 禁用词 fallback 速查。
+4. 通用网文内容评分（优先读取 `story-review/references/quality-rubric.md`，不可读时使用内置通用网文内容 rubric）。
+5. 按统一 Findings Schema 整理问题，再按下方模板写给作者。
+
+### solo 模式输出格式
+
+<!-- author-report -->
+```md
+=== 《{书名}》{审查范围}审查（单人审）===
+这次怎么审的：我一个人审{；原因一句话，如"审稿助手还没装，运行 /story-setup 后可以四个视角审"}，按{番茄 | 起点 | 知乎盐言 | 通用网文}的标准。
+
+总体判断：{可以发 | 改完下面几处再发 | 这一章需要重写}——{一句话理由}
+
+## 格式与设定
+- 分段与人名节奏：{没问题 | 第N章第M段起……}
+- 空行与对话换行：{没问题 | ……}
+- 具体数字：{没问题 | 第N章「……」对不上或没必要}
+- 前后矛盾：{没发现 | 第N章「……」与第M章「……」矛盾}
+- 因果和规则漏洞：{没发现 | ……}
+
+## 必须改（{n} 处）
+1. 第{N}章「{原文引用}」
+   问题：{读者会怎么想、哪里读不通}
+   建议：{具体改法}
+
+## 建议改（{n} 处）
+{同上格式}
+
+## 可以不改（{n} 处）
+{一行一条}
+
+## 需要你决定
+{问题 + 选项 + 我的建议；没有就写"无"}
+
+## 没法判断的地方
+{缺哪份设定或大纲导致没法核对、需要人工查证的外部事实；没有就写"无"}
+
+## 下一批接着核对
+{仅分批审查填写；否则删掉本节}
+
+下一步：{一句话}
+技术备注：Mode {full | lean | solo}→solo · Fallback {…} · Rubric {…} ({file | embedded})
+```
+
+---

package/lib/oh-story/skills/story-review/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-review/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-review/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` 不变。
 
 ## 续写状态卡固定格式