- CLAUDE.md 新增「三段开发流程」节:设计(用户点头心智模型一致才落文档+裁点清零才算完成)→写需求卡片(grilling 多轮复核零待裁+入库必登记 06)→实现(迭代号 U0+设计正主文档批内一律不更新);批次工作流清单引言同步改指 - CLAUDE.md 批次工作流第 12 条改 v2:机械面文档(roadmap 行/registry/active.md/README/工具注)合并前随批同步不变;GDD/art-bible 等设计正主改走迭代实现报告反哺制——收口出迭代级实现报告(design/qa/iter<N>-实现报告-<日期>.md,含各卡状态+代拍板追认单+GDD 反哺点节),反哺点收口时登记 06,用户逐点裁决后另批落文 - doc-conventions §11 新增「迭代实现报告」行+「证据只留最新」措辞换代+版本历史 v15:实现报告属中间文档,替代原每卡出口报告 背景:武器锻造取证确认「迭代」曾被当作一切批次容器(迭代18卡③设计提案混进迭代通道)致「迭代完成了但游戏里没有」口径错位;用户立规依据=文档与用户想法等同对等,文档修改必须经用户同意,只出报告、同意后再更新。纯文档批零代码零测试(两入口铁规)
135 lines
21 KiB
Markdown
135 lines
21 KiB
Markdown
# Dungeon Sweeper(扫雷 × 自动战斗 闯关 Roguelike)
|
||
|
||
扫雷推理层 + 自动战斗结算的两段式回合 Roguelike。个人开发,MVP 优先管线。
|
||
设计入口:`design/gdd/02-系统清单.md`(根索引)· 概念:`design/gdd/00-游戏概念.md`
|
||
|
||
> 本文件只保留全局元信息与硬性红线;一切领域细则在子文档,动手前先查「规范导航」。
|
||
|
||
## Technology Stack
|
||
|
||
- **Engine**: Godot 4.7.2 · **Language**: GDScript · **Build**: SCons(engine)+ Godot Export Templates · **资源管线**: Godot Import System + 自定义 resource pipeline
|
||
- **Godot 可执行文件(本机固定路径)**:`D:\code\godot\Godot_v4.7.2-stable_win64_console.exe`——headless / 命令行一律用 console 版;编辑器版为同目录 `Godot_v4.7.2-stable_win64.exe`
|
||
|
||
## Engine Version Reference
|
||
|
||
@design/dev/engine-reference/godot/VERSION.md
|
||
|
||
## 运行与验证(垂直切片)
|
||
|
||
工作目录 = 切片目录本身(含 `project.godot` 的那一层):
|
||
|
||
- 冒烟(全量 headless 断言):`python tools/run_smoke.py`(包装器三闸:退出码+摘要失败数+SCRIPT ERROR 扫描——脚本错误不计冒烟失败数且静默中断所在函数剩余断言,2026-09-19 工作日志 84 立闸)。底层命令 = `…console.exe --headless --path . --script res://smoke/smoke_all.gd`
|
||
- 场景级探针(呈现层回归):`…console.exe --headless --path . res://smoke/ui_probe.tscn`;另有 `ui_tune_probe.tscn`(调试浮窗——2026-10-04 迭代 14.5 起原数值调整板收进 debug_overlay)、`ui_click_probe.tscn`(合成鼠标事件行为探针)
|
||
- 调参期批量工具:`--script res://smoke/adventure_monte_carlo.gd`(全冒险期望扫描)· `--script res://smoke/reward_expectation.gd`(奖励获取期望)——单关直入口口径已退役(2026-09-23 用户拍板),通关率/难度类测量一律走全冒险(原 level_monte_carlo/level_debug 已删)
|
||
- 数值验证工具:`python tools/balance_verifier.py`(零强化冒险逐关条件通关率+止步节点归因+营地循环爬升战役——采集端 `--script res://smoke/verifier_batch.gd`,报告落 `design/qa/`;元进度换算率标定与曲线调参的自动化评判面,2026-09-22 数值验证工具批;直入口带判定随口径退役暂停,带重锚归曲线调参批)
|
||
- 交付前验收 = smoke + 全部场景探针全绿(测试细则见 `design/dev/code-conventions.md`)
|
||
- 结构审计闸(熵增闸):`python tools/repo_structure_audit.py`——顶层目录/根文件/图像白名单/退役路径四查,违例 FAIL;新类别 = 同批修订 CLAUDE.md Project Layout + 脚本白名单,commit 留痕(2026-09-27 立闸)
|
||
|
||
## Project Layout
|
||
|
||
- `design/gdd/` — 现行设计文档树(根索引 `02-系统清单.md`;文档增删必须同步它;`gdd/ux/` 战斗画面与交互规格)
|
||
- `design/registry/` — 跨系统事实登记(entities.yaml 术语与已锁数值、architecture.yaml 架构登记)
|
||
- `design/art/` — 美术**纯文档**:定稿规范 md(圣经/清单/提示词卡)+ `references/` 参考池;评估/调研 md 一律 `design/research/`;**不放任何图片**
|
||
- `design/dev/` — 工程规范:code-conventions / doc-conventions / architecture(ADR) / engine-reference
|
||
- `design/qa/` — 验证报告 md(balance-verifier/playtest/等价证明;raw 数据归 `sim-data/`)+QA 呈现产物图(目检预览拼图等——2026-09-29 迭代 5 返工批收编图像白名单)
|
||
- `design/research/` — 调研/提案/评估记录/历史验收/执行工单
|
||
- `artwork/` — **在途图像素材唯一工作区**(2026-09-27 用户三层裁定:文档归文档/在途图归一处/终稿归游戏):生图候选批次(每批一目录+每资产一目录+vN 命名)、像素稿、样张渲染、实机截图全在这里;**整目录不入 git——2026-10-02 用户裁:内容永久保留本地、永不提交(md 例外一并取消,.gitignore `artwork/` 强制)**;收口归档 `archive/`
|
||
- `game/assets/art/` — 已验收终稿(入包被游戏加载)
|
||
- `game/` — 游戏工程本体:代码三件套+`smoke/` 冒烟套件+`tests/` 单元/集成测试(2026-09-27 根 tests/ 并入)
|
||
- `sim-data/` — 机器读数据产物:模拟试玩 CSV/JSON、verifier raw 基线、日志样例输出。**数据件不入 git(2026-10-03 用户立规:.gitignore 强制)——语义=MC 缓存层:最新一份 MC 锚+读数常驻留盘供分析直读,无数值调整禁重跑(细则见「测试执行两入口铁规」MC 触发细则);`iteration_log.md` 模拟批日志同目录留盘不入库。入库例外三件(2026-10-03 二裁)=`README.md`+`analyze.py`+`growth_model.py`(分析工具本体随 git)**
|
||
- `tools/` — python 工具脚本本体(验证/审计/像素化/仪表盘/日志分析)
|
||
- 根目录运行文件:`active.md`(会话状态唯一状态源——快照+未决面+当前迭代工作记录;状态文件非历史档案,历史归 git,退役规则见 `design/dev/doc-conventions.md` §10)、`roadmap.md`(里程碑)、`stage.txt`/`review-mode.txt`(运行开关)
|
||
- `archive/` — 收口归档 zip(gitignored)
|
||
|
||
## 规范导航(动手前先查表)
|
||
|
||
| 时机 | 权威文档 |
|
||
|---|---|
|
||
| **写代码 / 改代码前** | `design/dev/code-conventions.md`——结构 / 契约 / 测试 / 语言 / 数值 / 流程六类硬纪律 + 反面案例对照表 |
|
||
| **写文档 / 改文档前** | `design/dev/doc-conventions.md`——可读性第一、白话写作、概念封装、引用纪律、文档骨架、文档生命周期(吸收即死) |
|
||
| 查系统设计 / 增删文档 | `design/gdd/02-系统清单.md`——根索引 + 中文规范名↔英文代号对照表 |
|
||
| 架构与决策记录 | `design/dev/architecture/architecture.md` + 同目录 `adr-*.md` |
|
||
| 引擎版本与参考 | `design/dev/engine-reference/godot/`(版本表已在上方 @ 引入) |
|
||
| 术语、已锁数值 | `design/registry/entities.yaml`——仅 owner 文档可修订,冲突须显式提出 |
|
||
| 会话进度记录 | 根目录 `active.md`(状态文件,2026-10-09 立宪:只记现在,每行当下为真)——快照节(≤10 条)+未决面+当前迭代工作日志;收口先改快照再记账,并删除已完结旧条目;历史归 git、待裁归 06、教训归记忆库;条目用完整白话句子写清结论,能看懂比短重要(2026-10-04 用户立规),详情归正主文档 |
|
||
| 工程路线图 | 根目录 `roadmap.md`——里程碑时间线与下一步顺序(批级视图;实时状态看快照节) |
|
||
|
||
## 分支纪律(worktree 铁律,2026-09-19 用户立规)
|
||
|
||
主工作区(本目录,`master` 检出)只作**合并落点与共享状态载体**,一切开发/设计改动不得直接发生在主工作区:
|
||
|
||
1. **开工**:每个任务批次先建独立 worktree 分支再动手:`git worktree add ../g-plan2-<任务名> -b <任务分支>`。所有代码/文档/数值改动与验证跑测都在 worktree 内进行(注意:未跟踪文件不会出现在新 worktree,需手工搬运)
|
||
2. **收尾**:迭代 loop 批次在验证全绿(冒烟 + 场景探针;冒烟挂迭代开发完成后的出口/落籍闸)后,在主工作区 `git merge --no-ff <任务分支>` 落回 master,然后 `git worktree remove` + 删分支;合并前先看 active.md 尾部工作日志,避免与并行会话撞号/漏捎带;收口时按 doc-conventions §10 退役规则删除已完结旧条目(判据=已落籍+结论进快照+无未决项指向)。非 loop 批次收口跑闸与否按「测试执行两入口铁规」(见硬性红线):默认不跑,用户点名或当场问
|
||
3. **豁免面(仅这两处允许主工作区直改)**:根目录 `active.md`(会话收口)与 `.zcode/`(钩子配置)——其余一律走 worktree;主工作区 `git commit` 会被钩子直接拦截
|
||
4. 本铁律由 PreToolUse 钩子 `.zcode/hooks/worktree-guard.sh` 强制兜底;钩子只约束 agent 侧,用户本人手工改动不受限
|
||
|
||
## 三段开发流程(2026-10-10 用户立规)
|
||
|
||
一切要做的东西按三段走:**设计 → 写需求卡片 → 实现**。段与段之间不自动流转,每段转进由用户发令;本节只立出入口与铁律,段内细则见规范导航各文档。背景:2026-10-10 武器锻造取证确认「迭代」曾被当作一切批次的容器(设计提案混进迭代通道),导致「迭代完成了但游戏里没有」的口径错位——本节为此立规。
|
||
|
||
**第一段·设计**——产出 GDD 文档或 art-bible。
|
||
- 触发:用户提起,或从 `design/gdd/06-待办清单.md` 取出讨论。
|
||
- 会话内进行、用户主导,不可无监管自跑;经用户点头确认心智模型一致后,才允许落文档。
|
||
- 设计完成的唯一判据 = 文档待裁点逐条清零;带未裁点的文档是讨论稿,不得转进下一段。
|
||
- 设计完成不自动进入写卡段;写需求卡片须用户另行发令。
|
||
|
||
**第二段·写需求卡片**——产出需求卡片(实施指导文档,写作规范见用户级技能 req-card)。
|
||
- 触发:设计定稿后由用户发令。**无设计前置的例外**:缺陷修复/工程债/测试基建/重构类工程需求,凭 bug 证据或 06 在册条目直接进入本段;新玩法/新系统/新内容类必须有设计定稿前置。
|
||
- 质量门:卡片必经 grilling 多轮复核,裁决全落、零待裁点才算成立。
|
||
- 登记:卡片入库后必在 `design/gdd/06-待办清单.md` 登记一条(卡片名/文件指针/状态:待编入/已编入/已开工/已落籍)——防用户遗忘已写过的卡;卡片落籍后按 06 退役规则销号。
|
||
- 编入:卡片加入后续未完成的迭代(roadmap 迭代行);没有可用迭代时与用户确认开新一轮。
|
||
|
||
**第三段·实现**——产出代码与配置文件,可运行的游戏。
|
||
- 触发:需求卡片永不单独施工,统一由用户指定迭代号触发(=U0 开工令);执行按 /iter 技能与下方批次工作流标准清单。
|
||
- **设计正主文档(GDD/art-bible 等承载设计决定的文档)在实现批内一律不更新**——文档与用户想法等同对等,任何更新必须经用户同意;实现批只出迭代实现报告(见下方第 12 条文档同步闸)。
|
||
- 收口人闸:实机目检清单+代拍板追认单交用户;后置不阻塞收口,用户验完才算真完。
|
||
|
||
## 批次工作流标准清单(2026-10-06 用户确认固化)
|
||
|
||
每个批次按以下链路执行——本清单主要承载第三段(实现段)与一切被批准批次的执行纪律,三段的出入口与转进规则见上节。本清单是总索引,各步细则散见上文各节与 `design/dev/` 子文档;与任一细则冲突时以细则为准,发现清单本身过时须同批修订。
|
||
|
||
**开工前**
|
||
1. **先检索后提问**——动手前先查在册记忆与正主文档,防止把已裁决事项当新问题重问,或重踩已记录的坑
|
||
2. **需求卡片全列备选案**——批需求卡片里每个待拍板点列出全部备选方案与各自代价,交用户裁决,不在需求卡片内自行定夺
|
||
3. **用户发开工令才动手**——需求卡片经用户批准(U0)后方开工
|
||
|
||
**环境与基线**
|
||
4. **独立 worktree + 拷导入缓存**——按分支纪律建 worktree;新 worktree 先拷主区 `.godot/` 目录与字体 `.import` 边车文件再跑测试,否则每套测试全量重新导入资源、近似卡死
|
||
5. **改码前定基线三查**——记录改动前的冒烟全绿数目、单元测试套数、现行模拟基线读数是哪份;改完用同一口径对拍,红绿才能归因到本批改动
|
||
6. **涉数值改动先采改前读数**——批次要改游戏数值的,改码前先采「改前」模拟读数(与改后同随机种子配对比较),并写明对拍口径;无数值改动禁跑模拟(触发细则见硬性红线)
|
||
|
||
**实施**
|
||
7. **新功能必配新测试**——按需求卡片卡片写码,新增玩法/机制必须配套新增测试套件进 `tests/run_all`;没有对应测试的变更不许合并
|
||
8. **验收改动先行声明**——逻辑变更对应的验收变化(模拟基线换代、探针用例增改、旧断言改判)在需求卡片里预先写明,不事后补
|
||
|
||
**收口**
|
||
9. **批末四闸全绿才合并**——冒烟 + 单元测试 + 场景探针 + 改前改后读数对拍,四项全绿方可在主工作区合并
|
||
10. **合并后主区全量复跑**——合并本身可能引入冲突或环境差异,落回 master 后再跑一遍全套验证
|
||
11. **会话收口落记**——`active.md` 快照与工作日志更新(含删除已完结旧条目,退役规则见 `design/dev/doc-conventions.md` §10);跨会话有效的教训写入记忆库
|
||
12. **文档同步闸 v2(2026-10-10 用户改立,替代 2026-10-09 版)**——文档更新时间点分两层:**机械面文档**(roadmap 行换代、registry、active.md 记账、README/工具注)合并/落籍前随批更新完毕方算收口(原口径不变);**设计正主文档**(GDD/art-bible 等承载用户设计决定的文档)实现批内一律不更新——文档与用户想法等同,更新必须经用户同意:实现批收口产出**迭代实现报告**(`design/qa/iter<N>-实现报告-<日期>.md`,一个迭代一份,含各卡状态+代拍板追认单+**GDD 反哺点节**——实现与设计的差异/缺口逐条列明),反哺点收口时同步登记 `design/gdd/06-待办清单.md`,用户逐点裁决后另批落文(可随批捎带,窗口长短由用户控制)。反哺点未落文期间,相关 GDD 节按 06 登记视为待反哺状态——读该节做新设计/写新卡前先查 06,勿把旧文当现行事实。需求卡片仍必列「关联文档同步面」,同步义务按两层标注(机械面=随批更新;设计面=报告反哺)
|
||
13. **实机目检归用户**——真机人闸由用户执行,用户亲口确认才算验收通过
|
||
14. **中间产物吸收即死**——结论先迁入正主文档(GDD/待办清单/路线图),中间文件即删且永不提交(细则见硬性红线)
|
||
|
||
## 硬性红线(勿违反)
|
||
|
||
- **worktree 铁律**:主工作区禁止直接改动与提交(细则见上节;并行会话各占 worktree 互不踩踏)
|
||
- **测试执行两入口铁规(2026-10-02 用户立规)**:测试类执行——冒烟测试、单元测试(tests/run_all)、模拟验证(MC/verifier/调参批量工具)、场景探针等一切跑游戏的验证调用——只有两个触发入口:①**迭代 loop 开发**(冒烟挂迭代开发完成后的出口/落籍闸,loop 内过程性验证属开发工作本身);②**用户主动点名**。除此之外(问答/调研/文档/审查/零散小改等短小会话)一律零测试,不得擅自调用任何测试;确需测试支撑结论时先请示,以静态阅读/推理作答并注明未跑测。**MC/模拟验证触发细则(2026-10-02 用户确认,2026-10-03 补落文——出处:迭代 9 出口批 81000 锚误跑质询)**:MC/verifier 仅在**数值验证场景**触发(改数值前后取证);normal 档为主、perfect 按需;**无数值改动的会话禁跑 MC**——结构位移类「存档锚」须先向用户请示定性再跑;需求卡片预设步骤的前提消失时(如「带值裁定后重锚」实际未投值)停问勿照字面执行。**分级周期口径(2026-09-26 用户裁定,2026-10-03 自 06-待办清单收编;重闸定义随迭代 19 卡①需求卡片 Q1 裁决扩容 2026-10-08)**:轻闸(run_smoke 全量+ui_input_probe;触碰 presentation 加跑 ui_click_probe+ui_layout_probe)可随变更执行;**重闸自此批末=轻闸+probe_gate --click+probe_gate --full(ui_probe/ui_tune_probe/t17_defer_probe/fx_probe 四探针)+render_gate(窗口化渲染闸:shot_probe 七屏样张 A-D 断言+fx_shot/board_shot 取证+棋盘 golden 逐像素)+run_all 单元全套+doc 三闸(gdd_lint/doc_link_audit/doc_term_audit)+熵增闸(repo_structure_audit)**,属**周期执行**——统一在批次收口或固定周检跑,不进每次变更;真人实机目检仍归用户不进自动闸(07⑮ 目检半不销号);MC 大扫描仍按上方 MC 触发细则(无数值改动零跑)
|
||
- **MC 采集档位细则(2026-10-03 用户四档立规,承接 MC 触发细则)**:MC 局数按用途四档硬闸(表见 `sim-data/README.md`「MC 采集档位表」):**一档·调研**=总量 >40(100+ 为常用锚量级;60/档=结构回归、100=95% CI ±9.8pp、170=±7.5pp=15pp 带半宽、400 满档=±4.9pp 贴边裁决;normal 独立满档 ~8 分钟同属一档)**只能由用户发起**——需求卡片/计划书/agent 均无权发起,非用户发起一律不构成一档授权;**二档·数值修改验证**=总量 ≤40、每档 ≤20(仅 ≥~40pp 结构位移可判,同种子配对下 ~30pp);**三档·小调**=总量 ≤20、每档 ≤10(只测不判);**四档·微量**=总量 ≤5(sanity 门,零统计判读)。四档仅承接 MC 触发细则的数值验证场景,两入口铁规不变;超档=停机呈报,禁在二/三/四档下带值结论(窗口不足如实挂起)。改前/改后锚同 seed0 配对、改前锚留盘禁补跑;对拍断言零新跑(复验用锚内子集 ≤20);读数缺陷(零 gameplay/RNG 触碰)禁整套重跑、走事件流重构补算;≥60 局采集先 N=5 pilot 校验字段;二/三/四档会话累计 ≤20 分钟;零数值改动=零 MC
|
||
- **中间产物吸收即死(2026-10-01 立规)**:中间文档(批需求卡片/机检报告/调研审计报告/模拟读数/迭代计划书/目检清单)寿命=迭代寿命——结论先吸收进正主文档、未决项先迁 `design/gdd/06-待办清单.md` 或 roadmap,然后文件即删,且永不提交 git;活文档=唯一事实源,git=变更记录。细则见 `design/dev/doc-conventions.md` 第 11 节
|
||
- **用语红线(2026-10-04 用户立规,黑话审计后落文)**:面向用户的一切输出——文档、工作日志(active.md)、报告、清单、对话——禁止自造黑话与代号式命名;判据 = 业内读者没读过项目历史也能一遍看懂,需要作者解释才能懂的词必须展开成完整白话句(三种固定形态、本仓反例全表与正确写法见 `design/dev/doc-conventions.md` 第 4 节)
|
||
- **呈报六问铁规(2026-10-07 用户立规)**:向用户呈报一切事物——bug、需求、概念设计、提案——一律按六问结构顺序展开,确认后才动手实现:①**What 现状与差异**——现在是什么样(引用文件、行为等事实)+ 要做什么/改什么;②**Why 期望与动机**——目标态是什么样、为什么值得改,含「不做的代价」;③**How 怎么改**——修改路径,有备选案全部列出不私藏;④**Where 影响面**——改动波及哪些系统、文件、流程、既有裁决;⑤**怎么算改对了**——可判定的验收标准,不写模糊话;⑥**不确定的地方**——没把握、需要用户裁决的点,单列收尾不埋正文。**Who/When 不进呈报正文**——谁来执行、什么时候做由用户决定,由 roadmap 与需求卡片承接,呈报里最多一句话带过。**适用范围(2026-10-08 用户补立)**——六问结构只用于**首次描述需求、bug 缺陷或相关方案**的呈报;同一方案的后续对答(追问、讨论、细化、执行汇报)不再套用六问结构,除非用户显式要求
|
||
|
||
- **数值单一事实源**:玩法数值只存 `data/tables/`(.tres),经 `ConfigDB` autoload 类型化单点读取;禁止数值字面量与自建 `load()` 表路径
|
||
- **RNG 单点**:禁止 `randomize()` / 自建 RandomNumberGenerator——随机只经 `RngService` 统一流(单盐单计数器+用途标签+全事件日志,ADR-0007 裁丙 2026-09-27)
|
||
- **Core 层零 UI 依赖**:完整战斗必须可 `--headless --script` 跑通
|
||
- **fail-fast**:数据校验错误一律致命中止,无软回退
|
||
- **spec-AC 一致性**:规约与验收标准不得在同一输入上给出不同答案(所有 GDD 同尺度)
|
||
- **评审隔离**:`/design-review` 必须在独立会话跑(与 `/design-system` 隔离)
|
||
|
||
## 像素结构件工作纪律(2026-09-26,高墙批转角三返工复盘用户令落档)
|
||
|
||
1. **先抄后造**:画任何像素结构件前,先从参考素材裁同类结构放大逐像素描述,再实现同款;禁止凭印象/第一性原理发明像素结构(圣经 §8.5 参考核验的执行口径)。
|
||
2. **验收口径写成像素级视觉判据**:开工前把合格标准写成"X 与 Y 同列收尾/无悬空/无突出"式句子;自检放大最差交界处逐行核像素,不只看整板观感。
|
||
3. **±1px 一律坐标推导**:单像素级结构先写坐标推导(哪条线在哪列、谁与谁齐平)留档再写码;禁蒙数试错。
|
||
4. **修复默认附前后对比图+像素审计**,不等用户索要。
|