From 7f975c25747fd4335dbfdf8b563a7450a93bb35f Mon Sep 17 00:00:00 2001
From: DKChan <524912269@qq.com>
Date: Wed, 30 Sep 2026 06:44:34 +0800
Subject: [PATCH] =?UTF-8?q?audit-fix:=20=E6=8B=8D=E6=9D=BF=E7=82=B9?=
 =?UTF-8?q?=E6=B8=85=E5=8D=95=E9=80=90=E6=A1=88=E5=85=A8=E5=91=88=E6=89=A9?=
 =?UTF-8?q?=E5=86=99=E2=80=94=E2=80=94=E5=8D=81=E7=82=B9=E5=90=84=E5=B8=A6?=
 =?UTF-8?q?=E7=8E=B0=E7=8A=B6=E8=AF=81=E6=8D=AE/=E5=85=A8=E9=83=A8?=
 =?UTF-8?q?=E5=A4=87=E9=80=89=E6=A1=88(=E5=90=AB=E6=B7=98=E6=B1=B0?=
 =?UTF-8?q?=E6=A1=88=E4=BE=9D=E6=8D=AE)/=E5=90=84=E6=A1=88=E4=BB=A3?=
 =?UTF-8?q?=E4=BB=B7=E8=81=94=E5=8A=A8/=E5=88=A4=E5=AE=9A=E8=A6=81?=
 =?UTF-8?q?=E7=82=B9=EF=BC=9BB=E7=B1=BB=E8=A1=A8=E6=94=B9=E9=80=9F?=
 =?UTF-8?q?=E8=A7=88=E5=B9=B6=E6=8C=87=E8=B7=AF=E7=AC=AC=E5=85=AD=E8=8A=82?=
 =?UTF-8?q?=E4=B8=BA=E8=A3=81=E5=86=B3=E5=BA=95=E7=A8=BF?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../gdd-concept-coverage-audit-2026-09-30.md  | 157 ++++++++++++++++--
 1 file changed, 144 insertions(+), 13 deletions(-)

diff --git a/design/research/gdd-concept-coverage-audit-2026-09-30.md b/design/research/gdd-concept-coverage-audit-2026-09-30.md
index f71e30c1..d38cd9bd 100644
--- a/design/research/gdd-concept-coverage-audit-2026-09-30.md
+++ b/design/research/gdd-concept-coverage-audit-2026-09-30.md
@@ -343,7 +343,9 @@
 | C25/C26/C27 悬空指路 | HUD框架:177 / 排雷玩法:218 / node-reward:22 | 术语表条目：若设置与本地化确认不承接，HUD 侧删「术语表」改自持或指 design/dev 约定文档；探测接口行改指 registry aux_items 机制桥接；营地呈现行改指元进度+待立 spec | 与 B 类落点④联动 |
 | 半落地 19｜接触带微光承接 | HUD框架（「可挖域指示」域，:22 负责表/:239 验收行扩为正文节） | 按 v3.1 指路承接：正文节补亮灭时机（挖掘期出现、减动效停格已定于 art-bible §3.2）、与悬停金框/类型微光的边界——art-bible 侧画法已归位，只欠 GDD 承接节 | 若沿 v3.1 的既有指路，承接落点即 HUD框架；改指排雷玩法则需回改 art-bible 指路行（与拍板点 5 联动） |
 
-### B 类｜落点需要选择的收口（进第六节拍板）
+### B 类｜落点需要选择的收口（速览）
+
+> 本表只给落点候选一览；**逐案全呈（含淘汰案与依据、各案数据/代价/联动、判定要点）以第六节拍板清单为裁决底稿**，两节条目一一对应。
 
 | 缺口 | 候选落点 | 各自代价/联动 |
 |---|---|---|
@@ -358,20 +360,149 @@
 
 ---
 
-## 六、待用户拍板点清单
+## 六、待用户拍板点清单（逐案全呈版）
 
-以下每项给全部候选与影响；不替用户拍板。已在飞、由其他批承载的拍板（视野迷雾/收窄/提灯、工兵爆破、雷当量、战斗阶段数值等）不重复列，只在末尾登记流程义务。
+本节是十个拍板点的**完整呈报**：每项自包含——现状与证据、全部备选案（含已淘汰案与淘汰依据）、各案的数据/代价/联动、判定要点；已裁过的面注明「已锁」并写明本点只剩哪一维。已在飞、由其他批承载的拍板（视野迷雾/收窄/提灯、工兵爆破、雷当量、战斗阶段数值等）不在此重复，只在末尾登记流程义务。本报告不替用户拍板。
 
-1. **奖励节点机制口径正主**（对应建议②）：机制口径（三选一/可用池/退役件不入池）放在魔法道具、关卡节点地图、还是维持 node-reward.md 承载+registry 声明？候选影响见建议表②。
-2. **战斗/冒险总结结算的 spec 落点与命名统一**（建议①）：battle.md 扩节、level-clear 扩节、还是新建 ux 文档；三个现用名（战斗总结结算/战斗结算画面/冒险总结结算）保留哪套。
-3. **结算演出覆盖层+轮间节奏化的 spec 落点**（建议③）：战斗表现.md 立节，还是 battle.md。
-4. **营地/商店覆盖层要不要立呈现 spec**（建议④）：立（HUD框架）、随批补义务行、还是维持现状（至少需处理 node-reward:22 的悬空指认）。
-5. **接触带微光「可挖域指示」正文节落点**（建议⑤）：HUD框架（v3.1 指路已指向，承接成本最低）还是排雷玩法（需回改 art-bible 指路行）。
-6. **测量口径（双画像/k 系数/生死带）升不升 GDD 正主**（建议⑥）：难度曲线判读口径节扩正主，还是维持 research/qa 承载。
-7. **整屏样张闸的 GDD 挂点**（建议⑦）：并入 HUD框架 可访问性基线，还是随 06 批条承载。
-8. **「拍板即落正主」要不要立为流程条款**（建议⑧）：doc-conventions.md 增一条，还是不立文。
-9. **「营地检查点」一词的处置**（冲突 C4）：确认系旧口径残留并删除/改写（难度曲线 :115 与 v0.19 行），还是它另有所指需要补定义。
-10. **A 类回写批的执行窗口**：建议表 A 类约 19 项均为既定裁决的文档同步，零新裁决——是否打包为一次「文档卫生批」执行、还是拆散随各自下一次触该文档的批顺带，属排期决定，待用户发话。
+---
+
+### 拍板点 1｜奖励节点机制口径的正主归属（对应建议②）
+
+**现状与证据**：奖励节点到达时「怎么给东西」的机制口径——三选一强制、可用池 = aux 活行 ∩ 工坊解锁集、退役件/失义件不入池、池空直通、按注册序取前 3——目前**唯一完整成文处是 node-reward.md:14-23，一份 UX 呈现 spec**。玩法侧三处全没承载：关卡节点地图.md:110/:168 还是 2026-09-17 旧拍板「功能道具的正式渠道」；魔法道具.md 的 v0.5 拍板④「奖励节点=三选一构筑点」只存在于 :188 版本历史，正文无节；registry「节点奖励」词条停在 2026-09-17 口径。这正是微光事故的形态：定义活在非正主文档。
+
+**备选案**：
+
+- **甲·魔法道具立「奖励节点投放」节（机制归玩法侧系统文档）**。道具内容、持有域、使用窗口的语义本来就归魔法道具（关卡节点地图:110 已声明），投放口径与它同文最顺；拍板依据（2026-09-29 八拍板之③甲④丙）也在该文版本历史里。代价：须先清该文正文欠账（C19：罗盘现役口吻/预读集悬空/新覆盖口径无正文节），等于一批做两件事。联动：node-reward.md 瘦身为纯呈现并加指路；关卡节点地图 :110/:168 改指路；registry 词条补注记。
+- **乙·关卡节点地图「节点兑付」节改写承载**。兑付触发（到达即开、兑付恰一次、零自动推进）本来就是它的正主面。代价：池口径（解锁门控/退役件排除）是道具内容语义，该文自己声明「道具内容、持有域归属与使用窗口语义归魔法道具」（:110）——放它这里会把同一概念拆成两半（触发在关卡节点地图、池口径在魔法道具），拆写正是漂移温床，须双方逐句互指。
+- **丙·维持 node-reward.md 承载 + registry 词条显式声明「机制口径正主=node-reward.md」+ 玩法侧正文清旧口径只留指路**。零搬动、成本最低。代价：机制定义住在 ux/ 呈现层文档，与 02-系统清单的树形惯例（systems=机制层、ux=交互规格层）相抵；若选丙，需要同时追认一条例外「机制口径可由 ux spec 持有」，否则下一轮审计仍会报寄居——例外条款本身就是一个新规则。
+- （淘汰案留档：「退回 2026-09-17 功能道具旧拍板」——已被 2026-09-29 用户拍板②丙取代，无 reopen 依据，不列。）
+
+**判定要点**：树形纪律取向——机制定义要不要必须住 systems 层。若方向是「必须」，路径甲；若接受 ux 承载机制、只求有处可查，路径丙（须连带立例外条款）；路径乙只在「不想动魔法道具」时有意义。
+
+---
+
+### 拍板点 2｜战斗总结结算/冒险总结结算的 spec 落点与命名（对应建议①）
+
+**现状与证据**：两个结算框均已实装（`battle_end_overlay.gd` 胜利金蜡封/失败暮蓝双形态；冒险终局面板迭代 6 T7 已接 GP 合计行）。归属拍板已存在（2026-09-27，06-待办清单:410）：「战斗胜利出现战斗总结结算、展示获得的资源（目前 = GP）；战斗失败出现冒险总结结算、确认后回存档首页」——**归属已锁，本点只裁 spec 正文落在哪份文档+叫什么名**。现状三处散写：battle.md:406（OQ14）/level-clear.md:105（OQ1）各记一遍拍板；06 两条登记接线；spec 正文（布局/数据锚/验收）不存在。命名三名并存：battle.md:113 用「战斗结算画面」、level-clear.md:58 用「战斗总结结算」、level-clear.md:107 把「结算画面」定义为冒险总结结算——同一个词在两份文档指两个面。
+
+**备选案**：
+
+- **甲·battle.md 扩节**：把胜利终局 overlay 节扩写为「战斗总结结算」正主节，并补「冒险总结结算」节（数据锚/出口/确认交互/禁止重复展示项）。优点：胜利面的全部语境（出口表、终局 overlay 组件、数据要求）已在 battle.md，扩写最省。代价：battle.md 已 447 行是 UX 树最长文；冒险总结结算的语境（回存档首页、与 level-clear 的相邻域边界）在 battle 之外。
+- **乙·level-clear.md 扩节**：该文定位就是关卡收束清算面，且已声明冒险结算=相邻域、复用 BattleEndOverlay（:30）。代价：胜利总结结算的进入语境在战斗屏出口，放 level-clear 是「下游文档写上游面」，阅读动线反了。
+- **丙·新建 ux/ 结算文档一文承载两面**：命名、两面边界、与 level-clear/battle 的互指一次写清。优点：最干净，且给将来「结算框加本战统计行」（现拍板面无此项、用户点名才加的开放面）留了家。代价：文档树多一叶，须同步 02-系统清单 索引与链接检查清单；两面已实装，spec 属补写而非先行。
+- **命名分项裁决**（可与落点分开拍）：候选一「战斗总结结算/冒险总结结算」——06 归属拍板记录原文用此名（06:410），有拍板文本背书，改口成本=battle.md OQ14 一处；候选二「战斗结算画面/冒险结算画面」——battle.md OQ14 旧口径，且 06 已把旧归属行判为「登记偏差」（06:410 原文），等于已被半否；候选三按载体名「胜利终局覆盖层/冒险终局覆盖层」——与代码锚一致但丢掉「总结结算」的拍板用语。三案里只有候选一与已锁拍板零冲突。
+
+**判定要点**：后续结算框还会不会扩内容（本战统计行等）——会则丙的一次性成本回本最快；只做收口则甲最省。命名按「与已锁拍板文本零冲突」默认对齐候选一，除非用户点名改口。
+
+---
+
+### 拍板点 3｜结算演出覆盖层+轮间结算节奏化的 spec 落点（对应建议③，孤儿 1）
+
+**现状与证据**：演出层已实装两批——结算演出覆盖层（光带横扫/跨区弹道，迭代 6）与轮间节奏化（段间 0.3s/段内 0.06s 排播队列+轮横幅 0.6s+减动效双态，迭代 8 卡⑦，pacing_queue_test 在册）。成文处只有两条：HUD框架.md:267 版本史一行、06「轮间结算节奏化」条（已实现收口态）。硬约束横跨两域：核心层「零 await」契约（battle_orchestrator.gd 文件头）不可破、减动效开关联动设置面。06 条目按「解决即移除」销项后，这套呈现规则将无任何文档。
+
+**备选案**：
+
+- **甲·战斗表现.md 立「结算演出与轮间节奏」节**。该文就是演出正主（02-系统清单：战斗动画与演出），现为范围草案，正好把第一块**已落地**内容补进去；排播参数、减动效双态、零 await 约束一次收进。代价：该文其余部分仍是草案，状态行需处理成「范围草案·结算演出节已实装」的分层表述（设置与本地化.md 现状同款问题，处理法可复用）。
+- **乙·battle.md 演出相关节扩写**。消费面语境（明细带展开、横幅驻留都在战斗屏）在 battle。代价：battle.md 继续增重；且战斗表现.md 作为演出正主继续没有演出内容——正主空置本身就是一种「有名无实」。
+- （淘汰案留档：「06 条目改为不销项的常设登记」——违反 06「解决即移除」规矩（2026-09-18 用户拍板口径），且让待办清单继续承载规则定义，正是本次事故的根因形态，不列。）
+
+**判定要点**：战斗表现.md 的激活时点——它本来就是迭代 9 视觉落码/后续演出批的正主，若认可「正主就该长肉」，路径甲顺手；若想等演出批整体重开时再写，临时路径乙顶住（需接受将来再搬一次）。
+
+---
+
+### 拍板点 4｜营地覆盖层/商店覆盖层要不要立呈现 spec（对应建议④，孤儿 2/3）
+
+**现状与证据**：两覆盖层均已实装（`camp_overlay_view.gd` 三柜台/钥石余额/最近冒险；`shop_overlay_view.gd` 三商品卡/购买/离开）。机制正主分别在元进度（三柜台结构已定稿）与关卡节点地图（商店房编排节，成文充分），机制面不缺；缺的是呈现面 spec。已出现指路落空实例：node-reward.md:22 指认「营地呈现『已退役/已解锁·能力封存中』」规格——该规格不存在。06 已把营地视觉终稿编入 M-3 迭代 9 卡⑭。商店定价的数值面归难度曲线调参批，呈现面无任何在飞批。
+
+**备选案**：
+
+- **甲·HUD框架 各立一节**。一次补齐两屏，顺带消掉 node-reward:22 悬空指认与 pattern 7「破坏性确认」是否覆盖商店购买的无从查证面。代价：两屏都没有在飞 UX 批，立节后没有批去消化视觉终稿——spec 与实装的漂移风险反而新增一份（写了没人维护）。
+- **乙·随批补「呈现义务」行、spec 后置**。营地侧=迭代 9 卡⑭（视觉终稿批）随批把 spec 一起立——该卡本来就要动营地呈现，零额外排布；商店侧=登记一条「商店覆盖层呈现义务」待办挂关卡节点地图名下，等下一个触商店的批（若有）。优点：各自搭在真实批次上，不空转。代价：商店侧可能长期没有「下一个批」，欠账悬着；且乙仍需先处理 node-reward:22 指认（改为指向元进度+待立 spec）。
+- **丙·维持无 spec（机制正主+代码注释承载）**。最省。代价：node-reward:22 的指认长期悬空；「已退役/能力封存中」的呈现语义无家；下次审计仍报孤儿——等于接受这两屏按「机制文档+代码」裸奔，与 HUD 框架其余屏的成文水准不一致。
+
+**判定要点**：迭代 9 卡⑭的边界愿不愿意从「视觉终稿」扩成「视觉终稿+spec 立节」——愿意则营地走乙（成本最低）、商店至少先改 node-reward:22 指路；想把两屏一次说清则甲。
+
+---
+
+### 拍板点 5｜接触带微光「可挖域指示」正文节落点（对应建议⑤，半落地 19）
+
+**现状与证据**：接触带微光（可挖域的交互反馈光，2026-09-25 用户拍板）的三个承载面在 art-bible 越权清理批 v3.1（0092cbd）后的现状：概念本体（可挖域=8 向相邻未开格）→ 排雷玩法·动作合法性节，已承接 ✓；画法（蓝族浅一档/呼吸/角点画法）→ art-bible §3.2，v3.1 已把该条改写为指路式（:167「概念见《排雷玩法》动作合法性节；呈现义务见《HUD框架》可挖域指示」）；呈现义务 → HUD框架，**指路目标未承接**：该文只有 :22 负责表一行与 :239 验收行，无正文定义节——亮灭时机（挖掘期出现/结算期是否保留/减动效停格）与悬停金框的边界在 GDD 侧零承载。
+
+**备选案**：
+
+- **甲·HUD框架 承接立「可挖域指示」正文节**。v3.1 的指路已经写死指向这里，承接成本最低；与「未开格类型微光」节成对（同圈不同职责的对照句 :140 已在），口径史可并写。代价：无实质代价，仅 HUD 框架再增一节。
+- **乙·排雷玩法 立呈现义务节**。可挖域概念本体归它，把呈现义务贴着本体写。代价：须回改 art-bible 已落籍的指路行（v3.1 产物，:167 两处指路改一处）——改刚落籍批的产物要走一次小修订，成本高于甲。
+- （淘汰案留档：「维持 art-bible 画法+排雷玩法本体+HUD 验收行三点分治」——即指路落空常态化，与 C27 同性质，下次审计仍报；不列。）
+
+**判定要点**：纯树形归属取向，无数据可判。默认路径甲（指路已就位）；只有「呈现义务必须贴着机制本体写」的取向成立时才选乙。
+
+---
+
+### 拍板点 6｜验收测量口径（双画像/k 系数/生死带）升不升 GDD 正主（对应建议⑥，寄居 1）
+
+**现状与证据**：验收判读的三件语言——双画像（盲挖蒙特卡洛=下界、完美档=上界）、真人修正系数 k（真人整关承伤中位÷模拟完美档中位）、生死带（承伤分位带）——定义在 design/research/acceptance-ap6-ac.md（研究文档，无修订流程约束）；难度曲线与Boss 已收编越带回滚阶梯（v0.19 起）并立了判读口径节。**误判实证已有一次**：直入口单关口径锚定的旧带与真实冒险条件率脱节，误导过曲线调参一轮（难度曲线与Boss v0.19 原文留档）。另发现一处断链佐证：07-体验验证清单.md:5 与 registry skill 条目（entities.yaml:312）写「设计权威 docs/proposal-status-vocabulary.md」，docs/ 目录已消亡，文件实居 design/research/——研究文档作权威的指针本身已断链一次。真人 k 系数终稿是 07 登记的在飞义务，验收批马上要用这套语言。
+
+**备选案**：
+
+- **甲·难度曲线与Boss 判读口径节扩为正主**。双画像定义、k 公式、生死带分位定义收进正主；acceptance-ap6-ac.md 加「已收编」注记降为历史提案；顺带把 :5/:312 的 docs/ 旧路径改指 design/research/ 现路径。优点：判读语言进修订流程管住的文档，同类误导有闸；趁 k 终稿前定正主，避免用一次搬一次。代价：判读口径节扩容约十行级；research 文档加注记一处。
+- **乙·维持 research/qa 承载**。零搬动，07 头注已有「研究文档作设计权威」的先例。代价：研究文档不在任何修订纪律内，口径被引用方各自转述时无「正主唯一」可依——本次报告 C 组列出的漂移形态在测量口径上已发生一次（直入口）。
+
+**判定要点**：这套语言是「验收批用一次就换锚」（乙够用）还是「长期判读基建」（甲）——通关率带已两度换锚（2026-09-20 分带、2026-09-30 改带），换锚频率本身说明是后者。
+
+---
+
+### 拍板点 7｜整屏样张闸的 GDD 挂点（对应建议⑦，寄居 3）
+
+**现状与证据**：整屏样张闸=战斗/关卡/菜单/营地四屏的验收闸，四项判据（全局文字 ≥4.5:1/明度三档带/整屏焦点预算/文字禁压纹理）现居三处：06「样张 v3 重跑批」条、任务书-美术圣经v3.5:38、art-bible v3.0。GDD 侧最接近的既有节=HUD框架·可访问性基线（判据第一项就是它的既有底线），但该基线只覆盖战斗屏语境；菜单/营地两屏在 GDD 无任何验收挂点。art-bible v3.0 措辞是「整屏样张闸**首跑**」——语义上是常设闸不是一次性闸。
+
+**备选案**：
+
+- **甲·HUD框架 可访问性基线节扩**：四项判据并入基线表并标注「适用四屏」，任务书/06 只留执行引用。优点：判据进正主，「首跑」之后的每次新屏/大改版都有验收语言可引。代价：基线表从战斗屏语境扩为全屏语境，字号等现有行需注明口径差异。
+- **乙·随 06 批条承载不动**。闸走完即销项，零动作。代价：判据无长期家；下次加新屏（如设置独立屏）时无验收语言可引，要重新发明。
+- （淘汰案留档：「判据全放 art-bible §1.4」——四项里文字对比度/字号属 UI 可读性（HUD 域），全放美术文档会重演刚清完的越权形态；不列。）
+
+**判定要点**：闸是常设（每次整屏样张都跑）还是只跑 v3 一轮——art-bible「首跑」措辞与迭代 9 卡⑤之后的复用场景（资产升档重产批同闸）指向常设；若拍常设则路径甲。
+
+---
+
+### 拍板点 8｜「拍板即落正主」要不要立为流程条款（对应建议⑧）
+
+**现状与证据**：微光事故的根因结论（HUD框架.md:143 口径史注记已写「教训=概念必须落地正主文档，零散复述不是定义」）目前只是样本节里的一句注记，没有流程约束力。同族风险已在册：本报告拍板点 1（奖励节点机制口径在 UX 文档）、寄居 2（提案族概念拍板后若不落正主即复刻事故）。
+
+**备选案**：
+
+- **甲·design/dev/doc-conventions.md 增一条**（路径已核实）。条款示例文本（可直接采纳或改字）：「凡用户拍板产生新的玩法/呈现概念，该批必须在正主文档落定义节（五要素），或在消费文档落指路节并声明正主；批末验收含『新概念落位核对』。」优点：把事故教训变成闸门，成本一行；与既有流程条款（复述确认制、批次执行制）同形。代价：所有未来批多一个验收项。
+- **乙·不立文**。靠微光样本节的口径史注记+本报告备忘。代价：约束靠人记，属同类事故可复发形态；下一批拍视野迷雾时没有闸拦。
+
+**判定要点**：用户既往立流程条款的先例不少（复述确认制/批次执行制/拍板列全备选案均为用户主动立规）——若认可「这是第三类要防的事故」，路径甲；若视为一次性事故，路径乙。
+
+---
+
+### 拍板点 9｜「营地检查点」一词的处置（冲突 C4）
+
+**现状与证据**：难度曲线与Boss.md:115 与 v0.19 版本史行（:333）用「直入口 L2 普通 5% vs 营地检查点 L2 条件 90% 同期并存」作历史实证；冒险结构.md:169 铁律原文「没有关卡重试、没有检查点、没有复活」。「营地检查点」全仓仅难度曲线一处使用，无定义。**本点先裁「它指什么」，处置随之**：
+
+**备选案**：
+
+- **甲·它就是现行「冒险条件通关率」口径的旧称呼**。依据：该句的对举结构（直入口=满血空降进关 vs 营地检查点=打通前一关后到达才测）与判读口径节「冒险条件通关率（打通 k−1 关才到达第 k 关）」定义完全吻合；v0.19 批语境正是旧口径退役换冒险条件口径。若确认：难度曲线 :115 与 v0.19 行的「营地检查点」改写为「冒险条件口径（时称营地检查点）」或径改「冒险条件通关率」，一词收口。
+- **乙·它指 balance_verifier 的「营地循环战役」判定段读数**。依据：判定端三段里有独立的营地循环段。若确认：在难度曲线该处补一句定义并互指工具文档，词保留但不再裸用。
+- **丙·直接删示例括注**。历史实证句的说服力不依赖这个名词，删掉最省。代价：v0.19 行是版本历史（按惯例不回改），实际可改处只有 :115 正文一句。
+
+**判定要点**：无第三种数据可查（词无定义、无其他用例），本质是用户回忆拍板——甲/乙/丙三选一即可，三案改动都在一行级。
+
+---
+
+### 拍板点 10｜A 类回写批的执行窗口
+
+**现状与证据**：建议表 A 类 19 项全部是既定裁决的文档回写（零新裁决），分布在约 14 份文档；其中四份文档同时挂着在飞批或待裁拍板点（难度曲线与Boss←战斗阶段数值讨论批在飞；魔法道具←拍板点 1；battle.md/level-clear←拍板点 2）。执行窗口三案：
+
+- **甲·打包「文档卫生批」一次走完**。独立 worktree 一批改 14 文，逐条对报告 C1-C28 销号，批末全 diff 目检。优点：一次清零，之后所有漂移都是新欠账好追。代价：与在飞批触同文件时冲突面大（四份挂账文档若强行同批，会和在飞批撞工作区）。
+- **乙·全部拆散随批**。各回写随下一次触该文档的批走。优点：零冲突、零新增批。代价：清偿节奏不可控——没有在飞批的文档（数据配置/音频/interaction-patterns/关卡节点图生成/棋盘生成/排雷玩法/增益状态/敌人系统/元进度/设置）可能长期漂着，下次触及时又要重对行号。
+- **丙·两段式（甲乙折中）**：无挂账的约十份文档打包卫生批先走（数据配置/音频/interaction-patterns/关卡节点图生成/棋盘生成/排雷玩法/增益状态/敌人系统/元进度/设置与本地化+06 销项+行动经济）；四份挂账文档（难度曲线与Boss/魔法道具/battle.md/level-clear）的对应条目拆散随各自在飞批或拍板点落定后的批顺带。优点：大头一次清、撞车面归零。代价：报告的销号要分两截管理。
+
+**判定要点**：迭代 9 计划在飞（计划书已成文待 U0）——卫生批若走，插在迭代 9 开工闸之前还是并行，属排期决定。
+
+---
 
 **流程义务登记（不新增拍板）**：06 在飞的两条提案（视野迷雾/收窄/提灯；标雷激励八案）无论拍板结果如何，若拍板方向含新概念（如视野迷雾、工兵爆破、龟缩），按微光样本先落正主节再进实施——此条与拍板点 8 联动。