dsh-trim-cot-leakage

精简思维链泄漏

思维链泄漏是指叙述视角属于写作会话而非代码仓库的文字：引用只有该会话才能看到的产物，叙述改动过程而非当前状态，或与已经离开的审阅者争辩。如果一段文字包含事实性分句，修复方式绝不能只是删除：应逐一改写，使每条事实在 HEAD 处都成立，然后删除周围的会话记录；如果一段文字不包含事实性内容（审计代码、控制流叙述），则直接删除。必读背景：dsh-prose-standard 规定了本技能所应用的完整命题规则；已归档的已提交产物引用说明记录了引用规则的历史缘由。这是指导，不是脚本。

唯一的检验方法

对于每段可疑文字，都要问：**读者处于 HEAD，且无法访问任何会话记录、PR 讨论串或未提交草稿时，能否弄清所有引用并验证所有主张？**如果不能，就从代码仓库的视角改写保留的事实，并删除其余内容。如果能，无论听起来多么像在讲历史，它都不属于泄漏——但可解析性只能满足本技能的要求：对于当前状态页面（README、文档、JSDoc），可解析的改动故事仍然是在叙述改动过程，第 3 类规定应将其移至获准的位置。

分类

1. 已经失效的设计会议引用——(decision 7)、(audit C2)、design §4.7、plan §1.4、阶段标签（T4、W3、P-I）、“the design ledger”、(B ruling)。如果该决定有已提交的归属文档，则注明其名称和路径；否则删除引用，并改写其中的事实性分句，使其能独立成立。
2. 堆栈和 PR 视角——“a later PR in this stack”、“this PR adds”、“the previous commit”。说明已发布的机制或扩展点；延期工作移至 TODO 标记或 issue 引用。
3. 改动叙述和版本标记——“used to”、“no longer”、“the old X”，以及指示性标记（“v1”、“this cut”、“today”、“now”，用于与过去状态对比）。说明当前行为；修复后的回归问题应改写为现在时的反事实（“没有 X，就会发生 Y”），而不是仓库历史（“过去会发生 Y”）。
4. 审阅流程叙述——“Rejected in review:”、“the reviewer confirmed”、草稿序号（“v5 of this note”）、轮次归因。将保留下来的决定和理由写成普通事实；删除是谁在何时说的内容。
5. 面向审阅者的辩解——“the cast is safe — it simply…”、“this is correct because…”。为自身正确性辩解的注释是在回应审阅者，而不是维护者。说明使代码安全的不变量；如果代码本身已清楚展示这一点，则删除注释。
6. 复述和推导记录——控制流叙述（“first we X, then we Y”）、测试演练、对显而易见分支的证明。删除；只保留不显而易见的约定或不变量。
7. 含糊措辞和计划残留——“probably fine for now”、“should be enough”、没有标记的延期事项。将其提升为 TODO/FIXME 或改写为实际限制；删除含糊措辞。
8. 写作语言疏漏——语言原本为英语的文字中，残留未翻译的工作语言片段（端、设计稿、---- 私有 ---- 分隔符），或中文对应内容中出现相反情况。翻译或删除。

什么不属于泄漏

未经辅助的引用检查会双向失误：既会删除长期有效的引用，也会保留已失效的引用。按以下规则保留；示例对每条规则都有说明：

• 问题引用 — #1470、TODO(name):、“issue #N owns the follow-up” 在 HEAD 上仍有效；任何位置都应保留，包括 README。不要将其移到 Agent Notes。
• Agent Notes 和事后复盘中的已合并 PR 和问题引用 — 根据文档标准中的变更故事路由规则，这些属于认可的证据。
• 抑制理由 — oxlint-disable … -- reason、coverage-ignore 理由、空 catch 说明都是必需的文字；应修正不实的理由，绝不能将其删除。
• 反事实回归钉点 — “without X, Y happens”、“a naive X would…”。
• 测量界限 — “(measured: 512 nests ≈ 0.15s)”用于校准常量；证据词“measured”不可或缺。
• 运行时的旧／新状态 — “the old connection drains before the new one accepts” 描述的是运行时生命周期，而非变更历史。
• 注释变更故事部分中的历史阶段名称 — “the first cut shipped X” 在此处符合当前状态要求；指示性时间标记（“this cut”）则在任何地方都禁止。
• 按设计指向仓库外部的引用 — 标准章节（RFC 9110 §10.1.5）、Figma 画板名称；§ 禁令针对未提交的内部草稿，不适用于外部标准或负责维护自身 § 编号的已提交文档。
• 项目语气和文体形式 — 作为项目口吻的“we”；注释中的“考虑过的替代方案”部分。

工作流

1. 按照 dsh-prose-standard 确定范围和排除项：必须明确指定范围；绝不触碰 vendor/ 或 .agents/notes/archived/。已记录的 fixture 和快照是衍生内容，不是文字目标：应修改所属源文件或场景，并且只有在获准的行为变更需要新证据时才重新生成。
2. 先以只读方式审计：运行回忆探测组（添加 --hidden 以搜索 .agents/），并用已知的正例和近似的反例校准每项探测，然后再相信其输出；接着从语义上判断每个命中项。这些探测组只是探测手段，并非定义——原始清理的每轮审查都发现了探测组遗漏的案例，因此还要通读范围内文字最密集的内容（模块 JSDoc、README、Agent Notes），不要预先设定模式。
3. 按表面优先修复所属源：生成的目录 → 追踪所有使用方，修复源 JSDoc 或生成器模板，然后重新生成所有衍生内容；类型等价围栏 → 修复源 JSDoc，然后重新粘贴两份双语页面（verify-type-equiv 会钉住它们）；双语文字 → 尽量少改对应文本，并通过轻量流程重新记录；双语围栏 → 按照 dsh-doc，将修正后的逐字代码块按字节原样复制到双方，然后重新记录这对内容；模型或用户可见字符串 → 通过 dsh-prose-standard 处理，只有在有所属行为证据时才更改，否则保持不变并报告延期处理。
4. 删除任何内容前，列出该段落所表达的命题（prose-standard），并检查过度修正陷阱：避免删改导致将义务变成认可、将假设说成已发布功能、删除真实事实或丢失证据来源。
5. 验证：重新运行探测组，预期只留下认可保留项、本技能自身目录以及所属注释引用的证据；确认每个剩余引用在 HEAD 上均有效；对改动过的表面运行相应检查（文档运行 doc-sync，以及 verify-type-equiv、verify-translation-pairing）。