简化策划agent工作流 (#522)

Reviewed-on: #522

docs/project-memory/shared-memory/decision-log.md

@@ -1,5 +1,78 @@
 # 决策记录
 
+## 2026-09-28 速览卡只承载概览、范围与设计入口
+
+- 速览卡帮助读者快速理解游戏及本次范围，分类、支柱、循环与目标玩家可融入概述；不复制系统拆分、具体参数、素材数量、完整排除清单或验证计划，不设固定字数或必填章节。
+- 仅在概览内容或入口变化时维护，只链接已有且有用的文档；影响方向或当前范围的重要未决问题简述并引用详细位置。注入说明与样例同步清理，概念阶段必需产物路径、资源登记及审批合同不变，已有用户项目不自动改写。详见[策划 Agent 生产迁移方案第 6 节](../../technical/【技术方案】策划Agent生产迁移与工作区浏览-2026-09-10.md#6-阶段与提示词注入)。
+
+## 2026-09-28 TDD 验证按需去重，范围外内容不自动规划
+
+- 验收判据与必要场景在对应分册完整写一次，其他位置引用并补充独有要求；总册汇总重要结论和缺口，不复制清单。必要数值验算保留，不重复行为状态推演，也不能代替运行验证。
+- 实际构建、交付约束与设计验收条件保留；测试脚本、顺序、截图数量和工具由施工方安排。性能目标与专门验证须有实际依据，未执行不得记录通过。
+- 当前采用值不自动登记调优待办；具体体验疑虑按需验证，不默认制作对照版本。架构和 TDD 对范围外内容只说明必要边界，已确定的后续计划或影响当前设计的要求按需补充，不自动承诺里程碑及扩展实现。TDD 独立施工、四份产物与关键缺口判据不变。详见[策划 Agent 生产迁移方案第 6 节](../../technical/【技术方案】策划Agent生产迁移与工作区浏览-2026-09-10.md#6-阶段与提示词注入)。
+
+## 2026-09-28 TDD 明确设计要求，内部实现由施工方决策
+
+- 保留“只看本套 TDD 就能完成当前范围实现”：写全设计要求、内容与数值、实际工程约束和验收条件，施工方无需回查 GDD 或猜测关键设计。代码组织、算法、内部接口、数据结构、配置载体及资源命名和打包由施工方决定，未预定这些选择不构成策划缺口。
+- 已有工程契约、数据与资源格式、明确交付要求仍须遵循；实现建议不作为唯一方案，不增加逐项登记或用户确认。固定规则不要求配置化，也不禁止施工方使用配置；不承诺尚未定义的模式或开关。文档统一使用“施工方”称谓。
+- TDD 总纲、三分册规则、四模板、四样例及上游交接同步这一边界；样例仍保留真实的玩法、内容、数值与表现缺口，未执行验证不写通过。四文件、资源登记、技术范围、阶段审批与已有项目产物均不变。当前合同见[策划 Agent 生产迁移方案第 6 节](../../technical/【技术方案】策划Agent生产迁移与工作区浏览-2026-09-10.md#6-阶段与提示词注入)。
+
+## 2026-09-28 架构与系统按行为组织协作，减少重复展开
+
+- 系统拆分以有用的独立规则边界为依据，简单职责可合并，不因变量、操作不同或未来替换而增加系统和协作层。架构保留职责、关键协作与共享约束，数据归属和文档位置可合写。
+- 完整流程在主要负责的系统文档展开，参与方写自身接收、处理和返回，按需引用；行为已说明的协作与反馈不再另表复述。规则、相关模板与样例同步，关键顺序、失败处理及 TDD 独立施工要求保留，已有项目产物不自动改写。当前合同见[策划 Agent 生产迁移方案第 6 节](../../technical/【技术方案】策划Agent生产迁移与工作区浏览-2026-09-10.md#6-阶段与提示词注入)。
+
+## 2026-09-28 数据分册按数据形态组织，避免重复列值
+
+- 少量参数合写含义与当前值，同结构多条内容可分列共用属性说明和完整记录；文案集中列一次，其他位置引用唯一权威定义，共用规则集中说明，派生值只保留计算关系。内部字段与配置载体由施工方决定，实际数据契约按需保留。
+- 数据模板、写作规则及样例采用同一口径，当前范围完整内容、数值、文案与验算要求不变。当前合同见[策划 Agent 生产迁移方案第 6 节](../../technical/【技术方案】策划Agent生产迁移与工作区浏览-2026-09-10.md#6-阶段与提示词注入)。
+
+## 2026-09-28 策划文档密度按项目需求与复杂度安排
+
+- 常驻提示词统一要求按项目需求、规模和复杂度组织内容；模板与样例仅供参考，章节和字段按需增减、合并，简单内容简述，复杂或易歧义处充分展开，不为填模板增加设计或重复论证。
+- 精简保留当前阶段判断与后续实现所需信息，TDD 可独立指导当前范围实现的标准不变。当前合同见[策划 Agent 生产迁移方案第 6 节](../../technical/【技术方案】策划Agent生产迁移与工作区浏览-2026-09-10.md#6-阶段与提示词注入)。
+
+## 2026-09-27 TDD 按施工信息简化，验收对象为策划案
+
+- 保留“只看本套 TDD 就能完成当前范围实现”的标准。文档、数据引用与必要验算须完整自洽；保留实际构建与交付约束、验收判据及必要场景，具体测试安排由施工方决定，不要求游戏或素材在策划案验收前已经完成，未执行不得记录通过。
+- 技术选型限定在 Game Agent 已支持的 Web、Unity、Godot、Cocos Creator 范围，不逐框架说明支持程度；新 Web 使用 npm + Vite，二维使用 Phaser 4.2.1，三维按需求选型，预览与导出读取 dist。已有工程不因模板自动迁移。
+- 收编可重组内容，来源版本集中维护；取消固定编写顺序、能力清单、建表步骤、条件架构、检查分级及资产生产台账。数据保留完整内容、数值、文案与验算；美术保留表现要求、对象与状态、用途及实际接入约束；四份必需产物、资源登记与阶段审批不变。
+- 星露谷 TDD 样例统一首个日常原型，具体参数是示例假设，当前施工缺口如实标明，不能将局部算术或未核验的原作资料当作完备证据。当前合同见[策划 Agent 生产迁移方案第 6 节](../../technical/【技术方案】策划Agent生产迁移与工作区浏览-2026-09-10.md#6-阶段与提示词注入)。
+
+## 2026-09-27 系统文档按实际行为展开
+
+- 系统层围绕触发、规则、状态变化、结果与协作组织内容，取消固定十二节、编号追溯、统一取舍表和枚举表达要求；类型规则与模板按需使用，不为填模板添加机制或预设玩法。
+- 十二类资料保留领域问题，职责和数据归属遵循实际架构；UI 维护自身交互与临时状态，正式玩法校验和结算归对应系统。跨系统行动明确成功、失败与中断后的结果。
+- 已定规则、单位和参数留在系统文档，TDD 按相关内容收编并补齐，不依赖固定交接章节；Sxx、产物路径与审批合同保持不变。战斗样例区分暂定原型、撤退与倒下后果及规格缺口，TDD 继续以当前范围可独立施工为完成标准。
+- 当前规则见[策划 Agent 生产迁移方案第 6 节](../../technical/【技术方案】策划Agent生产迁移与工作区浏览-2026-09-10.md#6-阶段与提示词注入)。
+
+## 2026-09-27 系统架构按职责与协作组织
+
+- 架构保留系统编号、职责、权威数据归属、文档位置、实现范围和验证，取消固定系统数量、P0 必需性、统一图表与分类、逐轮变更记录。双向交互按含义与更新顺序判断，不以图上有环自动要求重切。
+- 同一事实由明确的权威方维护；只读副本、派生视图和快照说明来源及更新或恢复方式。必要的规则与参数可在架构明确，由系统文档展开、TDD 收编补齐。
+- `project/03_systems/...` 是策划文档映射，不决定代码目录。系统与 TDD 的直接引用按实际范围衔接，TDD 仍须写全当前施工所需规格；星露谷首个原型包含基础采集，单日选择与多日成长分别验证，样例缺口如实列明。
+- 当前规则见[策划 Agent 生产迁移方案第 6 节](../../technical/【技术方案】策划Agent生产迁移与工作区浏览-2026-09-10.md#6-阶段与提示词注入)。
+
+## 2026-09-27 顶层设计按实际玩法展开
+
+- 顶层说明游玩过程、关键规则与反馈、资源与进展、选择后果和版本范围；取消固定循环层级、回报数量、资源消耗链、日历节奏和失败档位，允许说明玩法所需的具体参数。
+- 原型范围依据验证问题确定，与完整版本范围分开；验证可结合观察、玩家反馈和指标，预期与已验证结论分清。
+- 架构按顶层已有内容检查玩法覆盖，可拆分、合并能力范围并由多个系统协作，不依赖固定循环图、独立定稿章节或逐项映射。TDD 自足性、产物路径和审批合同保持不变。
+- 当前规则见[策划 Agent 生产迁移方案第 6 节](../../technical/【技术方案】策划Agent生产迁移与工作区浏览-2026-09-10.md#6-阶段与提示词注入)。
+
+## 2026-09-27 概念设计按内容组织，取消固定填写程序
+
+- 概念层先利用已有对话与资料，按实际缺口补问；模板和样例按需参考，不强制参照、固定句式、字数、唯一卖点、六项锚点或调性编号。
+- 概念明确核心体验、主要吸引力和重要边界。设计原则帮助判断方向，不代替具体分析；必要的数值、操作或界面信息可以用于说明概念，规模按实际团队与项目条件确定。
+- 规则、模板、样例及下游引用同步调整：重要取舍与视觉设计依据按具体内容或章节引用，不要求张力编号或 T 原则；TDD 继续保留来源版本及完整施工规格。现有产物路径与审批合同不变。
+- 当前规则见[策划 Agent 生产迁移方案第 6 节](../../technical/【技术方案】策划Agent生产迁移与工作区浏览-2026-09-10.md#6-阶段与提示词注入)。
+
+## 2026-09-27 策划共享文档按用途和内容变化维护
+
+- 分析文档按需保留重要取舍依据，决策台账集中待处理事项，对话摘要仅在用户需要时维护，速览卡仅随概览内容变化更新；取消概念至系统分册中的重复状态、连续编号和多处登记流程。TDD 同步取消逐项代决登记，规格直接写入 TDD，未决问题解决后补齐正文并关闭待办。
+- 保留“只看 TDD 就能完成当前范围实现”的标准，以及内容收编、来源版本、变更同步和施工所需清单；影响当前实现的关键问题未解决时不能宣称完备。文件路径与现有审批存在性检查不变，不增加内容校验，不批量改写已有项目文件；旧 `resources/SKILL.md` 合并总稿已删除，现役规则由全局提示词、阶段上下文及资源目录登记的分册承接。
+- 当前维护规则见[策划 Agent 生产迁移方案第 6 节](../../technical/【技术方案】策划Agent生产迁移与工作区浏览-2026-09-10.md#6-阶段与提示词注入)。
+
 ## 2026-09-22 UI 编辑器预览画布补上右键拖拽平移，节点菜单改为右键抬起弹出
 
 - 背景：预览画布此前只有中键与空格+左键平移，右键整段留给节点操作菜单（`UiTreeRenderer.onContextMenu` 直接弹 `UiNodeContextMenu`）。这次要补右键拖拽平移，并要求"拖拽过就不许再触发右键菜单"。实测（Linux Chromium 151 / Firefox 151，真实 X11 输入）确认 `contextmenu` 在**按下**瞬间触发，且原生菜单一旦弹出，页面之后收不到任何 `pointermove` / `pointerup` / `mouseup` / `auxclick`，所以"先让菜单弹、拖拽时再关"在浏览器层面不可行；headless 没有原生菜单，Playwright 复现不出该行为。macOS 的 `contextmenu` 在 mouseup 触发（本容器无法实测），但同一条实现路径对两种时序都成立。同一次实测：键盘菜单键触发的是 `button: -1`，所以"只认按钮 2"的拦截天然把键盘菜单留给原有节点菜单路径。

docs/technical/【技术方案】策划Agent生产迁移与工作区浏览-2026-09-10.md

@@ -233,6 +233,16 @@ get_workflow_status
 
 ## 6. 阶段与提示词注入
 
+常驻提示词统一要求按具体项目的需求、规模和复杂度安排文档结构与内容密度。模板和样例仅供参考，章节与字段可按需增加、合并或删减；简单内容简述，复杂或易歧义处充分展开，不为填模板增加设计、重复论证或无关内容。精简须保留当前阶段判断与后续实现所需信息，TDD 仍须独立指导当前范围的实现。
+
+2026-09-27：常驻提示词删除每次修改文件后汇报修改内容和相对路径、将不确定内容统一分为用户确认／Agent 建议／待原型验证事项的要求。汇报形式按当前协作需要决定；仍按后文规则标注暂定方案并就关键问题询问用户。提示词简化可以调整核心行为，以调整后的行为是否合理作为评估依据。
+
+概念层规则、模板和样例围绕核心体验、主要吸引力与重要边界组织。先利用已有对话和资料，仅按影响当前设计的缺口补问；模板与样例按需读取，参照只说明具体借鉴点，不自动继承参照作品的全部设计。章节按项目需要选取，不要求固定句式、字数、唯一卖点、六项锚点、调性滑杆、T 编号或重复定稿，也不要求先回答固定定调问题或标注“零参照”。
+
+概念层的设计原则帮助后续判断方向，不替代具体问题的分析。说明核心体验所需的数值、操作方式和界面形式可以保留，详细规则、数值平衡和界面规格留待后续展开；规模依据实际团队和项目条件确定。交付检查聚焦概念是否清楚、是否符合已有意图和约束、是否存在影响交付的矛盾或缺口，避免为填模板编造内容。
+
+下游按相关内容或章节承接概念，不强制张力逐条对应或附编号；TDD 美术规则与样例不再依赖概念层固定第 2 节或 T 原则。美术圣经保留设计依据及来源版本，并在 TDD 内写全视觉规格；总册引用对应 TDD 分册，继续满足只看 TDD 即可完成当前范围实现的标准。资源路径、产物路径及阶段审批合同保持不变。
+
 阶段顺序固定为：
 
 ```text
@@ -276,7 +286,7 @@ concept → top_design → architecture → systems → tdd → consultant
 | 技术文档 | `project/04_tdd/01_技术实现.md`、`project/04_tdd/02_美术圣经.md`、`project/04_tdd/03_数据与配表.md`、`project/04_tdd/总册.md` |
 | 顾问态 | 不提交下一阶段审批 |
 
-`systems: []` 是已确定的行为，不是迁移时需要补齐的缺口。`project/analysis.md`、`project/决策台账.md`、`project/dialog.md` 保持原型中的共享过程文件口径，不升级为新的审批必需项。速览卡保留原型结构提示，但 Runtime 与 UI 不解析其章节或内容字段。
+`systems: []` 是已确定的行为，不是迁移时需要补齐的缺口。`project/analysis.md`、`project/决策台账.md`、`project/dialog.md` 保持原型中的共享过程文件口径，不升级为新的审批必需项。速览卡采用下述简短概览结构，Runtime 与 UI 不解析其章节或内容字段。
 
 提示词中的路径是策划 Agent 使用的相对路径约定：
 
@@ -285,7 +295,58 @@ concept → top_design → architecture → systems → tdd → consultant
 
 这些路径直接服务于 Agent 的文件操作和资源查阅，属于提示词应保留的契约；即使阶段上下文也注入了某条产物路径，分册和模板中的路径仍提供目标文件与交叉引用的具体定位。去除客户端与宿主实现细节时，不应把这类相对路径当作意外暴露的内部实现；宿主安装目录、项目绝对路径及会话控制文件位置才不属于 Agent 的操作输入。
 
-过程文档记录关键依据、决定和待办，不要求实时完整，也不应重复正式设计文档；阶段提交前补齐影响验收的关键记录。顶层设计的分册、模板和示例保留核心定位及按需说明的易混淆方向与排除理由，不强制使用固定的“不是 X，而是 Y”句式。
+共享文档按以下职责维护，文件路径和审批必需产物清单保持不变：
+
+| 文档 | 用途与更新时机 |
+| --- | --- |
+| `project/analysis.md` | 按需保留重要取舍的依据与当前结论；存在实际备选时再比较，未决问题说明原因或下一步。结论稳定或依据变化时更新，可合并修订条目，不记录每次讨论。 |
+| `project/决策台账.md` | 按需集中列出待处理事项和下一步，必要时引用分析或正式设计。事项变化时更新，完成后移出待办，不再重复保存全部已采用决定。 |
+| `project/dialog.md` | 仅在用户需要对话摘要或交接记录时维护，不逐轮转录聊天。 |
+| `project/速览卡.md` | 概念阶段形成简短游戏概览、当前范围与已有设计入口；仅在概览内容或入口变化时更新，不复制系统表、参数、素材数量、完整排除清单或验证计划。 |
+
+正式设计承载当前采用的规则，共享文档按各自用途记录，不要求同一决定在多处重复登记。不强制连续编号、状态枚举、候选数、问题数量、推翻条件或完整历史流水；尚未确定的事项用自然语言说明，不冒充用户确认。阶段提交前检查影响交付的信息是否一致，不以补齐过程记录作为新门禁。已有项目文件不批量重写或删除。
+
+速览卡让读者快速了解游戏、当前准备做什么及详细设计的位置。分类、支柱、循环和目标玩家可合入概述，不再分别展开；不设固定字数，也不要求填满参考结构。只提示会改变方向或当前范围的重要未决问题，并引用详细位置；设计入口仅链接已存在且有用的文档，不为填卡新增范围或未来计划。注入说明与星露谷样例同步，样例清除旧 NPC、图标和换装数量，按当前日常原型概括；`project/速览卡.md` 仍为概念阶段必需产物。
+
+TDD 的决策记录采用相同原则：设计要求、当前采用值和实际工程约束直接写入对应分册，重要取舍按需保留分析，未决事项说明影响与下一步，不要求逐项登记到外部台账或附推翻条件。总册保留施工索引、跨分册约定与重要缺口，详细问题指向对应分册。问题解决后更新受影响的 GDD 与 TDD 正文并关闭待办，不能只登记处理去向。
+
+“施工方只看 TDD，应能完成当前范围的实现”仍是完成标准：设计要求、内容与数值、实际工程约束和验收条件写全，施工方无需回查 GDD 或猜测关键设计。保留来源版本与变更同步，外部分析与台账不能代替正文。代码组织、算法、内部接口、字段与数据结构、配置载体、资源命名与打包由施工方自主决定；未预定这些实现选择不构成策划缺口。已有工程契约、实际数据/资源格式和用户明确交付约束必须记录；有依据的实现建议可供参考，不成为唯一方案，也不增加逐项登记或用户确认。
+
+TDD 阶段验收对象是策划文档：当前范围的行为、内容、数值、界面、表现要求与实际接入约束须完整、自洽，完成文档一致性、内容关系和必要数值验算。奖励、失败后果、关键视觉状态等设计缺口须补齐；函数签名、源码目录、内部字段或打包格式未预定不阻塞验收。保留实际构建与交付约束，验收条件明确，必要时给代表性场景；测试脚本、执行顺序、截图数量和测量工具由施工方安排，性能指标与专门验证须有实际目标或风险依据。不要求产品或资产已经完成，只有实际执行过才能记录通过。当前采用的设计值明确，后续调优不能代替当前设计。
+
+同一验证的场景、判据和结果在对应 TDD 分册完整写一次，其他位置引用并只补充独有要求；总册汇总重要结论、缺口与位置，不复制清单。不强制每册单列完整验证章节或新增统一验证表。数据册保留必要数值计算，不重复技术册的行为状态推演；文档验算与实际运行检查不能互相代替。当前采用值不自动成为调优待办，只有具体体验疑虑才记录验证问题，不默认安排替代版本对照。架构与 TDD 对范围外内容简述边界，只有已确定的后续计划或确实约束当前设计的要求才补充，不自动承诺里程碑或扩展实现。规则、模板与样例同步，已有用户项目不批量改写。
+
+TDD 总纲与技术分册把选型限定在 Game Agent 已支持的 Web、Unity、Godot、Cocos Creator 范围，不逐框架分级说明支持程度。新 Web 使用 npm + Vite，二维使用 Phaser 4.2.1，三维按需求选择适用技术栈；依赖由 npm 管理，预览和导出使用包目录下的 `dist/index.html`，运行素材随构建进入 dist。已有工程沿用实际结构，不因模板自动迁移。该约束与 GameAgent 的 `prompts/runtime/texts/direct.json` 工程提示、`src/project/manifest.rs` 脚手架一致；本轮不修改 GameAgent 提示词或运行时。
+
+TDD 按实际内容组织，可重组 GDD 规则而不要求逐段全文复制；来源版本集中在总册记录，设计变化同步受影响正文。取消固定编写顺序、必读样例、统一图表和逐项登记要求。技术分册写行为、工程约束、存档要求及验证，已有接口按契约描述，不为新项目预定代码目录或内部调用。数据分册写全当前内容、数值、关系与文案及可复核验算，不以示例行代替，也不强制写成可加载配置。美术分册写共性表现、对象与状态、用途及验收，已有素材记录真实接入约束，不通用强制帧键、图集、命名或目录。
+
+总册保留当前范围、分册索引、来源版本、实际跨分册约定与重要缺口，不重复生产验收表或以 frozen 标签判定通过。`project/04_tdd/01_技术实现.md`、`02_美术圣经.md`、`03_数据与配表.md`、`总册.md` 四个产物继续保留，不涉及的方向在分册简述原因。十二份 TDD 规则、模板和样例同步这一口径；星露谷样例聚焦首个日常原型，数值与素材规格标明示例假设，未附证据的原作实证、构建通过和资产验收声明清理，规格与验算缺口如实保留。资源 ID、路径、阶段注入及 Runtime 的文件存在性检查不变。
+
+数据模板将含义、关系与完整内容合写：少量参数直接列当前值与单位，同结构多条内容可共用属性说明；文案集中列一次，其他位置引用唯一权威定义。固定行为写在相关规则中，是否配置化由施工方选择，不为未来可能变更承诺尚未定义的模式或开关。派生值保留计算关系，不重复登记；已有数据格式或明确要求交付可加载数据时，才按实际契约补充字段、类型、默认或必填规则。当前范围完整内容、文案和验算要求保留。
+
+写作规则由 `system-prompt.md`、`phase-context/`、资源目录登记的 `skills/` 与各分册承接；重复且过期的 `resources/SKILL.md` 合并总稿已删除，历史由 Git 保留。
+
+顶层设计将概念展开为游玩过程、关键规则与反馈、资源与进展、选择后果、版本范围及验证计划。规则、模板和样例按实际玩法组织，不强制三层循环、三种互相供给的回报、资源“来源—储存—消耗”链、日历节奏、反馈层数、唯一原型片段或失败三选一；最优解是否成立取决于玩法，必要的规则与参数可以在顶层明确。保留核心定位及按需说明的易混淆方向与排除理由，不强制固定句式或结尾重复定稿。
+
+原型范围由要验证的问题决定，与完整版本范围分别说明；验证可以结合试玩观察、完成情况、玩家反馈和指标，明确如何形成判断，不把未验证的预期写成结论。星露谷样例按选择双方的收益与代价比较，按场景说明损失与恢复，并区分单日、多日和后续内容的验证范围。
+
+架构层承接顶层已有的玩法描述、能力范围、版本边界和验证计划，按实际职责、状态与数据边界拆分或合并系统，不要求顶层清单逐项对应系统。规则、模板与样例围绕系统职责、协作和数据归属、系统文档映射、实现范围及验证组织；取消固定系统数量、每个系统必须属于 P0、“不负责”必填列、图表格式、状态分类、数值基准分类和逐轮变更记录。重要取舍按需保留依据。
+
+拆分应带来有用的独立规则边界，不因变量、操作不同或未来可能替换就单独设系统；简单职责可在同一系统内部表达。架构概述关键协作，保留影响结果的顺序与共享约束，职责、数据归属和文档位置可合写，不重复建表。完整行为流程在主要负责的系统文档展开，其他参与方说明自身接收、处理与返回，按需引用完整流程并就近保留理解本系统所需的前提和结果。
+
+系统交互区分调用、通知、读取与玩法反馈；双向关系不自动判为架构错误，按实际问题检查职责纠缠和更新顺序。主数据归属明确，实际需要的副本或快照说明来源与预期结果，不要求额外设计更新机制。系统文档展开行为，TDD 收编并补齐设计要求、内容与数值及实际约束，内部实现由施工方决定。
+
+保留 Sxx 编号与 `project/03_systems/...` 文档位置，可以按内容合并或拆分文档；该映射不决定代码目录，代码模块与文件组织由施工方选择。实现范围区分完整版本、首个原型及后续内容，不固定 P0/P1/P2，也不要求验证失败就退回顶层或禁止调整系统划分。星露谷样例明确 NPC 日程、资源点、物品与经济等归属，首个原型包含基础采集，按单日选择和多日成长分别验证。
+
+系统总纲、相关系统类型资料与 TDD 的直接引用同步承接职责、协作、数据归属和当前实现范围，不再依赖架构 P0 清单、固定依赖图或仅限定性的数值基准。数据侧按实际玩法选择验算场景与跨度；技术侧按当前施工范围收编全部必需行为，不能因某系统标为后续优先级而遗漏当前所需规格。速览卡与 TDD 样例同步首个原型范围，基础采集、跨日结算规格和完整数值验算的缺口如实标明，局部推算不作为验算通过的证据。施工完备要求、产物路径与阶段审批合同保持不变。
+
+系统层按实际行为展开职责、触发条件、状态变化、结果、协作与反馈，类型规则、模板和样例按需使用，不要求先归入十二类之一。取消固定十二节、顶层条目编号、取舍表列、循环层级、“三不”、全部枚举及禁止段落等填写纪律；未决事项按影响处理，不只保留结构问题，也不把全部数值问题自动推给原型。代表性验证场景说明预期结果和判断依据，不冒充已完成验证。
+
+这些维度是信息覆盖要求，不是独立章节要求。参与方、数据来源、处理顺序和反馈可随行为一次说明，已讲清的内容不再另列协作表或反馈章节；简单同步处理不额外设计消息、确认或中间状态。相关类型模板将协作与反馈并入具体行为，架构样例合并职责与文档映射、战斗样例将协作归属就近写入行为。去重不降低关键行为边界、结果一致性和 TDD 独立施工要求，不改写已有项目产物。
+
+十二类系统资料保留类型特有的设计问题，模板不预填未经选择的动作、状态、循环和数据表。日历、生产队列、成长分支、复杂叙事、节日专属玩法和战斗定位均由实际项目决定；系统职责与权威数据归属遵循架构，UI 可以维护交互、导航和临时状态，正式玩法校验与结算仍由对应系统负责。跨系统行动明确整体成功或失败的预期结果，TDD 收编设计约束，具体实现机制由施工方选择。
+
+系统文档保留已定规则、单位和参数，TDD 从相关内容收编并补齐设计与实际接入缺口，不依赖固定交接章节。系统编号、文档位置、资源登记及审批语义不变。战斗样例明确为后续矿井原型的暂定方案：实时基础动作、安全撤退保留成果、倒下可能损失部分钱物，未定设计和待执行验证如实标明；TDD 日常原型样例不提前收编后续战斗。样例中的代码、数据和资源组织不再作为预先设计或验收要求，仍缺少的玩法、内容、数值及表现如实保留。
 
 进入下一阶段必须由用户批准触发。Runtime 推进后向 Agent 追加明确的用户行为语义，例如“用户已批准上一阶段，现在进入顶层设计阶段”，避免 Agent 误认为 Runtime 自行推进。