gplan-2/.qoder/skills/iter/SKILL.md

name, description

name	description
iter	g-plan2 迭代开工总指挥。当用户输入 /iter <迭代号>、或要求"开迭代N/启动迭代N/发射迭代N/给我迭代N的 goal prompt/开始迭代N的开发"时使用——读 roadmap 迭代行与对应需求卡片，检查开工门与待裁点，按项目既定批次执行模式（U0/worktree/闸序列/停机规则/收口五步）组装开工面并直接开始开发。无参数或只说"/iter"时，呈报当前 roadmap 全部迭代的就绪状态供用户选号。

/iter——迭代开工总指挥（g-plan2 批次执行制）

你（执行会话）现在就是本迭代的编排者+施工者。用户输入 /iter <N> 即 U0 开工令——门全解且零待裁点时不要再问"可以开工吗"，直接按本流程执行。唯一的合法前置停顿是第 2 步检查不通过。

发射形态（与内置 /goal 的组合）：/goal 是 harness 内置命令（会话级目标+续跑提醒+完成校验），由用户侧设置。推荐发射形态=/goal 按 iter 技能执行迭代 <N>，直至总收口全绿——/goal 提供"不到目标不收工"的机制级驱策与完成校验，本技能提供批次流程。本技能单独调用亦自足（停机/闸纪律已内建），但目标完成校验只有 /goal 能提供。

批性质（2026-10-17 用户立规，最高优先）：本技能执行的是代码实现批。批内禁写、禁改、禁新增 design/ 整个目录与根规则文件（AGENTS.md/roadmap.md）——那里全是设计文档与规范，对本批只读，是写测试与实现代码的输入依据，不是产出物。需要往外交代的东西一律落 reports/（实现报告/GDD 反哺点清单，细则见 reports/README.md）；发现该改文档的点，写进反哺点清单并停机呈报，不落笔。2026-10-18 用户裁：根目录会话状态文件已废除，本批不再有任何「例外可写」的文件。2026-10-29 补：game/tests/README.md（能力清单）同属禁写面——能力行增删归写卡段（写卡时当场入表，test-conventions §8.3；「最后验证批次」列已废除），本批只读。

闸域：本批开发期的窄测是义务不是许可（AGENTS 红线·改完即测铁规／process-conventions §4）——卡内只测自己改的东西，出红只跑红件最小单元；全量验证归合回后的远端 CI——合并落地 post-merge 钩子自动 git push origin master 触发远端 CI（游戏码批＝不带参数档两域全量），本批零手动全量（闸件清单只写在 tools/run_all_gates.sh 头注一处，本文不重列）。

第 1 步：定位迭代与读卡

1. 读 roadmap.md 主路线表，找到「迭代 」行（注意可能是 迭代 N 或 迭代 N+ 形态；一行可以含多卡，卡号⓪①②③…都在行内）。
2. 逐份读行内引用的需求卡片（reports/需求卡片-*.md），以需求卡片最新版为准；行内描述与需求卡片冲突时，需求卡片优先，冲突本身呈报。
3. 无参数调用时：扫全部迭代行，输出一行一迭代的就绪表（迭代号/卡数/估时/门状态/待裁点数），等用户选号，结束本轮。

第 2 步：开工检查（唯一的合法前置停顿）

逐项核，任何一项不过 → 停下呈报，等用户裁决，不得跳过或代裁：

• 门（进入条件）未解：行内门列写明的依赖（前置迭代出口/前置卡已入库/用户发令句）没有满足证据。典型：门列含「用户发令（未排期）」「待用户裁定」→ 必须停。
• 待裁点 ≠ 0：需求卡片声明待裁点未全裁，或行内有「待用户裁甲/乙」句。
• 迭代估时总量 <5 个工作日：迭代行状态应处「冻结待凑批」——处待开工/进行中且总量不足即编排缺陷，拒启动并呈报凑批方案（可补卡清单）等用户裁（2026-10-25 两层模型：卡片无工作量门槛，冻结线属迭代层）。
• 需求卡片缺失：行内引用的需求卡片文件不存在或版本明显滞后于行内裁决记录。
• 改动—验收对照表缺失或不闭合（2026-10-11 立，2026-10-21 升级）：需求卡片没有改动—验收对照表，或对照表有空行（无真实入口、无判据绑定面），或 T 卡内无对应验收条目 → 不过，停工呈报。判定口径：每个需求点至少一行；每行必须有落点、真实入口、判据绑定面——施工性质的验证工作（如「MC 对账适配」）、完成定义里的笼统验证手段（如「MC 对拍留证」）都不算。禁拿 AGENTS.md「新功能必配新测试」红线代偿——那条只保证写了测试，不保证测得对。2026-10-21 前的旧卡缺对照表 → 停工，退回写卡段补，补完再开工。判据出处行锚（2026-11-05 起）：生效日后（文件名日期不早于该日）的卡，对照表「需求点」格须带 <现行文档相对路径>:<行号> 判据出处行锚（机检=pipeline_gate C5）——行缺锚或锚指向不存在＝停工呈报退写卡段；旧卡不回头改，开工前由写卡段补挂（test-conventions §8.3）。
• 自洽扫描（轻量，非拷打）：声明零待裁点≠逻辑无冲突——读卡后快速核三类：①需求卡片内部矛盾（范围/契约/估时/裁决记录互相打架）；②需求卡片与 roadmap 行冲突（两处说法不一致）；③事实抽查——从需求卡片「现状考证」里抽 3-5 处关键 file:line 到现行代码核对（防需求卡片成文后代码已被其他批改掉，需求卡片变质）。发现疑似冲突 → 逐条列单呈报（哪里矛盾/两种读法各是什么/建议哪边改），用户裁决后才开工；零发现则直接通过，不为此拉长开工。全量拷打（/grilling）不在此步做——那是需求卡片成文时的责任，这里只兜网；但本步必查卡里留没留复核的记录（见下条），记录不在＝上游没跑，停工退写卡段。
• 复核记录缺失（2026-11-05 用户立规）：需求卡片内没有「复核记录」节、或该节申报的复核报告文件在 reports/ 盘上不存在 → 不过，停工呈报退回写卡段。本步不代跑复核、不代补记录、不把缺记录的卡当旧卡放行；生效＝卡片文件名日期 ≥2026-11-06（与 tools/pipeline_gate.py 该条卡片判据同口径），更早的卡不回头改。
• 真人检测遗留项不算门（2026-10-12 用户立规）：往期迭代/批次登记未验的实机目检项（体验验证清单/实现报告总清单在册）不构成开工阻塞——开工呈报带一句提醒即可，禁为此停工等验。
• 设计闭合核验（2026-10-18 五段流水线立规）：逐卡核需求卡片的设计事实源声明——独立小节「## 设计事实源」或头部「来源：…（唯一事实源：…）」句，二者得一即合格（禁按小节名字面判死：库内合规卡多数用后者写法；全文两词皆无＝不过，机检见 tools/pipeline_gate.py 判据 C2）——①卡片声明的事实源文件真实存在（相对仓库根）；②文档源版本与待办清单对应条目状态里的闭合凭据一致（工程类卡=证据指认与待办清单条目实况一致）；③roadmap 迭代行卡片列路径与卡片实际路径一致；④行内预计周期形态合规（「≈N 个工作日」）且量值合规——5–10 个工作日为常规；10–20 个工作日须随带日期特批标记；超过 20 个工作日＝缺陷（硬上限，特批不放行）；低于 5 个工作日＝该行状态必须为「冻结待凑批」，处待开工/进行中即编排缺陷（2026-10-25 两层模型：卡片无门槛、迭代层冻结线）。任一不过 → 停工呈报——这是编排段（iter-plan）缺陷，不是本技能能修的，禁代改卡片或迭代行凑绿。
• 执行形态判定（2026-10-22 用户立规）：读各卡「前置依赖与并行性」节（各卡 §0）定本迭代执行形态——默认＝整迭代单工作区、各卡按 roadmap 行卡片列格内顺序串行推进；仅当卡片声明可并行（且互核无同文件交集）时，该卡组走逐卡工作区例外路径（第 4 步）。判定结果在开工呈报里带一句。

呈报格式：一行一项（哪条不满足/证据在哪/需要用户做什么）。全部通过则宣布「迭代 开工（U0=本次调用）」进入第 3 步。

第 3 步：T0 开工（主区核对＋建迭代工作区）

1. git status 归属核对：主区脏文件分两类——本迭代定义面（下条列名文件）与其他在飞遗产（其余一切）。除定义面外一律禁碰、禁代提交、禁还原。
2. 定义面已入库（目的：worktree 从旧 HEAD 检出必须看得到定义；后续合并不被脏 roadmap 阻塞）：git add 仅限 roadmap.md、待办清单.md、本迭代引用的全部需求卡片文件——指名道姓，禁扫全仓——单独一笔提交，message=docs: 迭代<N>定义已入库。注意：这一步是搬运别的会话已写好的定义文件，不是本批撰写文档（批性质禁令照旧生效）；该笔单独成提交，别和代码提交混在一起，否则合回后 CI 会把本批 diff 推定跨两域、两域都验。
3. 建迭代工作区（整迭代只此一个）：git worktree add ../g-plan2-iter<N> -b iter<N>；冷检出四件套照坑速查执行（拷主区 game/assets/art/ 与 *.import 边车 → --headless --editor --quit 刷导入 → tools/setup_worktree_userdir.sh 建本区独立 user 目录；闸机 code 域起手自检会自动兜底同步素材与熵增预检——tools/sync_worktree_assets.sh，2026-10-30 工程批——四件套照做，脚本兜防漏）。第 4 步各卡都在此工作区内推进；整迭代禁开第二个 worktree（并行例外见第 4 步）。检出工作区零测试，直接开工（2026-10-22 频率规则；全量验证归合回后远端 CI——合并落地 post-merge 钩子推送自动跑，T0 不做基线复读，红绿归因由「卡内只测自己改的东西」与闸机基线比对机制承担）。

第 4 步：迭代内逐卡推进（单工作区）

整迭代一个工作区（第 3 步已建），各卡都在其中推进。执行顺序＝roadmap 迭代行卡片列格内顺序；卡片「前置依赖与并行性」节声明可并行的卡组走下方例外路径，其余串行。何时该把活分出去见下面「子代理使用口径」。

1. 读卡施工：需求卡片 T 卡逐轮推进——读卡→对事实源（file:line 复核）→实装（验收测试随对应 T 卡同轮落地，禁批末补写；同轮把实际对照表写进实现报告，测试写文件:行）→本卡验收测试跑绿、读数写进该笔提交（AGENTS 红线·改完即测铁规）→提交（代拍板随 commit 记录）→进度记录→下一轮。卡内只测自己改的东西（2026-10-22 频率规则）：本卡新增/改动的验收测试自己跑绿、读数写进该笔提交才算这一步完成，没改的不测，轮内不跑闸壳全套。整迭代禁开第二个 worktree。diff 里没有对照表行的行为改动必须标「非行为改动」或指向覆盖行；禁删断言、放宽阈值、缩小扫描面、把真实入口换成下层直调；判据绑不上可观测提交面＝停卡呈报。
2. 卡间依赖：卡片声明「硬等/前置门」的后续卡，须等前置卡收口 commit 落本迭代分支且该卡验收测试跑绿后才准开 T1——迭代内不再以「合并进 master」为门（整迭代只合并一次，见第 5 步）；跨迭代依赖仍由第 2 步开工检查核。
3. 并行例外（逐卡工作区，2026-10-22 用户立规）：仅当卡片「前置依赖与并行性」节声明可并行、且开工检查核过无同文件交集时，该并行卡组按卡各开 worktree（git worktree add ../g-plan2-<卡名worktree>，冷检出四件套照坑速查），subagent 并发 ≤3（用户既定上限）；并行卡各自收口合并进 master（现行逐卡机制原样保留在此例外路径），不受第 5 步「一次合并」约束。
4. 画面类需求的黄金图基线冻结（2026-11-05 立）：卡触碰画面呈现面的（判据=设计段出了预览图），实现轮把该画面纳入渲染闸机器面——截图采集清单扩项＋实跑截图冻结进 game/tests/golden/；冻结（新建与换代同口径）前呈用户对照该卡预览图确认一眼，确认后触发原因写进当批提交说明（tools/golden_baseline_refresh.sh）；此后渲染闸逐像素自动盯、零人工。义务细则=test-conventions §8.2「golden 测试项扩项」；预览图（HTML/SVG 效果图）禁直接充当比对基线。

子代理使用口径（2026-10-21 用户立）

默认口径：实现不外派——写代码、写测试与对照表、合并、停机呈报一律由本会话做；可以外派的是查证与「跑命令取读数」两类主动分出的活，加上合并前那项强制分出的独立验收审计，共三类（见下）。外派出去的活都不改源码、不写实现产出物、不做裁断。并发上限只管数量，这条管范围。

可以分出去的三类（派出前先想清楚要它返回什么，指令里写死返回形态）：

1. 只读考证——第 2 步自洽扫描的第③项（从需求卡片「现状考证」抽 3-5 处关键 file:line 到现行代码核对）、跨模块找某符号的消费方与改动面。只要它汇报「文件:行 + 一句事实」，禁它改文件、禁它下「因此该怎么改」的结论；冲突判定与裁断仍在本会话。
2. 闸跑出红定位——跑批输出量大，把「跑这条命令 + 报红的用例名与第一条失败断言 + 原样贴出那段读数」分出去，修复与复跑收回本会话。判「是不是本批新增红」以第 3 步基线读数为凭据，不拿子代理的「全绿」转述当凭据。
3. 合并前的独立验收审计——见「独立验收审计」一节，属强制分出，实现者不能自审。

不分出去的：单卡实现轮本身、验收测试与改动—验收对照表的同轮编写、合并动作、停机呈报。原因：这几项依赖对卡片全文与设计事实源的完整理解，且施工铁律写了整迭代单工作区；子代理拿到的是转述，写出来的码无法保证对齐卡片。第 4 条的并发上限与执行形态判定管的是多张卡怎么排先后、各用哪个工作区，不是把实现交给子代理——判定为并行时，本会话逐卡开卡、逐卡施工，分出去的仍然只有上面那三类。

取回纪律：子代理的汇报当线索不当证据。凡涉及「跑绿了」「这条断言存在」「文件在这一行」的说法，本会话自己 grep 或自己跑一次才算数——「独立验收审计」一节不采信被审对象自述「已全绿」，正是同一条口径。

闸序列（既定，禁手拼同款命令）

• 卡内（每轮）：只测自己改的东西——本卡新增/改动的验收测试自己跑绿、读数写进该笔提交才算这一步完成，没改的不测；轮内不跑闸壳全套（含 --quick 中段自检档），被改的套件／探针直跑就是那一步的凭据（2026-10-22 频率规则）。
• 调试期出红→只跑出红最小单元确认（单探针/单套件直跑），全套闸只绑批末出口（闸机轮次纪律，AGENTS.md 同源）。
• 全量验证（归合回后 CI，不批末手动跑；顺序＝冻结 → 件核 → 并 master → 重塑 → 主区合回）：合回前先 python tools/reshape_cards.py 把分支压成一卡一笔（master 台账每卡一行，工具自带树一致断言，详见 process-conventions §1.3）；主区 git merge --no-ff iter<N> 落地后 post-merge 钩子自动推送 origin master 触发远端 CI 全量（不带参数档），本批零手动全量——tools/run_all_gates.sh --code 只在调试期出红后按最小单元复跑时手动用。MC 对拍（仅当需求卡片要求且涉核心）仍在批内做。CI 红则新开修复 worktree（fix-<任务名> 分支，免重塑免数卡）修复提交并主区合回，落地即由 post-merge 钩子复验追绿后删修复区（迭代区已随合回即删），「回执作废」语义已退役。doc 三闸不在本批（2026-10-17 起移出——本批不产文档，跑它们只会替别人背红）。
• 闸件清单、顺序与域划分只在该脚本里定义——开工时核对脚本头部现行文本，以它为准，本文不重列。
• MC/verifier 跑批发起前必须用户批准（硬规）；需求卡片写「MC 零跑·静态论证」的卡禁发起跑批。

独立验收审计（合并前必做，2026-10-21 立）

由没参与实现的子代理，或用户点名的另一会话执行；只读需求卡片、实现报告里的实际对照表、本批 diff、测试文件和闸回执，不采信报告里的「已全绿」。单工作区口径（2026-10-22 起）下在迭代总收口、合并前执行一次，审计范围覆盖本迭代全部卡的 diff、对照表与验收断言。至少做三件事：

1. 逐行核对对照表：测试存在、尾缀能 grep 到、真实入口没有绕过改动点；
2. 抽查验收断言：每张 T 卡至少一条，核对断言在当轮真实跑批中执行且通过（闸回执与测试输出为凭）；
3. 检查测试削弱：删除断言、放宽阈值、缩小扫描面、换下层直调，逐处要卡片申报或用户批准。

审计深度按验收档分级（2026-11-04 起）：逐卡读卡内「验收档：高/中/低」申报（test-conventions §8.3）定审计深度——高档＝上面四件事全量（现行口径）；中档＝对照表逐行核对保留、最窄测试复跑省略（以远端 CI 现查读数为执行证据）；低档＝对照表抽查 ≥1/3 行（新增行与改判行必抽）＋复跑省略；测试削弱检查与直查例外核对三档全保留不抽。未申报档位的卡（旧卡）按高档全量执行；档位存疑按高档。梯度表权威＝test-conventions §8.7。

审计报告写 reports/iter<N>-验收审计-<日期>.md，逐行写「通过／缺漏／例外及依据」，逐卡标注验收档与实际执行深度。未通过不得合并；缺漏按实现段零裁断处理（停该卡，退回上游，禁实现期自裁）。审计核的是各卡施工那一步留下的跑批读数（AGENTS 红线·改完即测铁规），对已跑绿的同一份字节不另起跨域跑批——读数对不上才复跑。

停机规则

• 实现段零裁断（2026-10-18 换口径，取代原「禁自答／用户门／机制卡点」三条）：实现段的输入在编排段出口已锁死（卡片零待裁点＋设计闭合凭据齐＋编排五查过）。施工中冒出需求卡片没写清的分歧、冲突、模糊点（含机制卡点）＝上游缺陷——停该卡，呈报退回上游（写卡段或设计段），随呈报附「待办清单对应条目状态回退＋缺口补记」拟稿（写清差什么才能重写卡）；呈报＝缺陷移交不是提问，须把分歧点、两种以上读法与建议案写全，不裸呈问题。禁自答、禁内联提问求裁断、禁 idle 等待轮；待办清单状态回退与缺口补记的落笔归上游段或用户——本批对 design/ 只读，批性质禁令不因停机豁免。该卡停摆不阻塞同迭代其他卡，其余卡继续（单工作区口径：停摆卡不提交，其余卡继续施工；迭代收口合并须等停摆卡闭合、或用户裁拆批后整体进行）。
• 需求卡片内预设停机点（S1/S2…）→ 合法停机呈报等裁（裁断点在卡片审问阶段已由用户预设，属预授权面）。
• 异常分级：L1 自救重试一次 → L2 记录继续（连续 3 次同红灯升级）→ L3 停机写报告等用户。环境故障与测试红是工程问题，走分级处置，不属裁断。
• 代拍板白名单保留：授权发生在卡片审问阶段，实现只执行预授权（随 commit 留痕）；超白名单事项记入实现报告「实现决定记录」节备案，不另立追认单。
• 特批机制不进本技能：实现段无特权，禁以任何「用户特批」名义在施工中放行跳步。

第 5 步：合并与收口

1. 每卡收口（工作区内，不合并）：本卡验收测试跑绿＋提交（代拍板随 commit 记录）＋进度记录即完成；禁逐卡合并、禁逐卡跑全量域闸。
2. 迭代总收口（一次合并）：全部卡收口后 → 冻结（代码与断言不再动）→ 全仓件核 grep → master 已被推进则在迭代工作区 git merge master 解冲突 → 重塑：python tools/reshape_cards.py --branch iter<N> --card 卡<k>=<该卡最后一笔> …（把分支线性史压成一卡一笔＋可选一笔纯文档收尾；原史自动留 backup 分支，见 process-conventions §1.3）→ 独立验收审计通过（见上节）→ 主区 git merge --no-ff iter<N>（合回守卫数卡校验：卡提交数＝roadmap 行卡片数，未归卡提交拦下）→ 合并落地 post-merge 钩子自动推送 origin master 触发远端 CI 全量（后台，不阻塞）→ 即向用户呈报本批总结（呈报即本回合止），结果按需现查 tools/ci_check.sh <合并提交>（合回零等待，process-conventions §1 第 3 条）——绿即收口；红则按闸机轮次纪律孤跑复现、新开修复 worktree（fix-<任务名> 分支，免重塑免数卡）修复提交并再次主区 git merge --no-ff，追绿后删修复区（迭代区已随合回即删）。允许的重跑只剩「验证修复」与用户自发全量回归两类，禁「跑都跑了再跑一遍保险」（process-conventions §1 第 2 条、§3 第 9 条）。
3. 账面随批：能力清单核对（2026-10-29 起，核对义务归收尾提交）——核对 game/tests/README.md 能力表与本批落地一致：本批退役能力的行已删、表上代表用例名与实际落地的测试名一致（改名则回表，回表归写卡段）；名实不符＝卡片没定死名字＝停卡退回，本批禁代改 README（test-conventions §8.3）。体验验证清单登记目检项（真人检测只登记不阻塞——登记完批内义务即了结，禁以等目检为由延后合并/收口/下一迭代，2026-10-12 用户立规）、roadmap 行内该卡换代、术语表如涉（以上机械面文档，合并前随批更新完毕）；GDD/art-bible 等设计权威文档一律不动——实现与设计的差异/缺口逐条记入反哺点清单（2026-10-10 用户立规：文档更新必须经用户同意）。
4. 迭代产出物全部落 reports/，禁落 design/——reports/iter<N>-实现报告-<日期>.md（各卡状态＋实际对照表＋独立验收审计结论＋实机目检总清单＋遗留读数义务＋实现决定记录）、reports/iter<N>-反哺点-<日期>.md（要写进 GDD/art-bible 的点逐条写清：哪个文件哪一节、改成什么、依据是什么；不再登记待办清单，用户在会话里裁决后由文档批写入 design/ 并把该条清掉）；stage.txt 视情移动、批末闸序列全绿留痕。待办清单条目状态推进与 roadmap 顶部「当前位」三行换代都归文档批做（本批禁写 design/ 与根规则文件，见批性质禁令）。roadmap 里程碑或行换代已移出本批（属文档动作，归文档批做）；若按第 3 步搬运过定义面（roadmap/待办清单/需求卡片），那笔提交单独成笔，呈报时注明是搬运既有文件、不是本批撰写文档。
5. 红灯纪律：存量红零新增口径可继续；新红必修或停机呈报，禁带红合并。

坑速查（历史实证，开工前扫一眼）

• 报告写「V1 绿」不等于有 V1 的断言：先 grep 断言尾缀和真实入口，再看报告；绕过真实入口的测试（如裸 EffectEngine 替代 BattleOrchestrator）不算该接线的验收。
• worktree 冷检出（整迭代一次；并行例外路径每卡一次）：game/assets/art/** 与一切 *.import 边车都不入 git，检出后必先把主区素材拷过来（cp -r <主区>/game/assets/art/. <本区>/game/assets/art/），再用 --editor --quit 刷导入——--import 不生成新素材的 .import 边车，刷完仍报 main_theme.tres 解析失败、按钮样式盒全空、冒烟 V1 成片假红（2026-10-17 实测）。跑批前的素材齐盘预检会把这件事拦下来并按名列出缺件。同轮跑 tools/setup_worktree_userdir.sh：不建区隔离时所有 worktree 共用引擎 user 目录，测试夹具、试玩日志与截图产物互踩（并行跑闸必假红）；闸壳跑批前会自检/自愈，建不起来即拒跑。
• 合并后主区：无手工动作——类名缓存刷新由 CI 跑批起手接管（--editor --quit）；CI 首跑即合并后验证，红项与绿证用 tools/ci_check.sh <合并提交> 现查（读数须是绿；「未验」＝零触发批跑闸步全跳过，不算验过），修复走 fix-<任务名> worktree 合回自动追绿。
• 长测试前：清残留 Godot 进程（probe_gate 自带清杀，run_all 需手动）。
• 改名件：.gd/.uid/.tscn 三件同步，禁只改 .gd。
• heredoc 内变量会被吞：复杂脚本落文件再执行。
• CRLF：禁往核心层 .gd 带入 CRLF（battle_orchestrator 前科）。
• 守卫/脚本过闸：用 worktree 相对路径形态调用，禁主区绝对路径。
• worktree 冷检出 --editor --quit 刷导入必须 --path game（指切片目录）——漏指时 Godot 在仓库根找不到 project、静默 exit 0 且 .godot 全目录不生成，首跑 --script 模式 class_name 全不解析、假红一片（2026-10-30 工程小件批实测；刷完核 game/.godot/global_script_class_cache.cfg 在位再跑测试）。

模式开关

• 用户说「只要 prompt」「不要直接开跑」→ 完成第 1、2 步后不施工，把第 3-5 步按本迭代实况展开成一段可粘贴的开工 prompt 交付，结束。
• 默认（无修饰语）→ 调用即开工，全程执行到总收口或合法停机点。