明确策划与施工边界，简化TDD实现约束

明确TDD写全设计要求与工程约束，内部实现由施工方自主决策
同步技术、数据、美术分册规则及模板样例，移除预设内部实现的验收要求
保留独立施工、关键设计完整性和已有契约，统一使用施工方称谓
同步上游交接措辞、技术方案与共享记忆

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

@@ -306,19 +306,19 @@ concept → top_design → architecture → systems → tdd → consultant
 
 正式设计承载当前采用的规则，共享文档按各自用途记录，不要求同一决定在多处重复登记。不强制连续编号、状态枚举、候选数、问题数量、推翻条件或完整历史流水；尚未确定的事项用自然语言说明，不冒充用户确认。阶段提交前检查影响交付的信息是否一致，不以补齐过程记录作为新门禁。已有项目文件不批量重写或删除。
 
-TDD 的决策记录采用相同原则：施工规格、参数、默认值直接写入对应分册，重要取舍按需保留分析，未决事项说明影响与下一步，不要求逐项登记到外部台账或附推翻条件。总册保留施工索引、跨分册契约与重要缺口，详细问题指向对应分册。问题解决后更新受影响的 GDD 与 TDD 正文并关闭待办，不能只登记处理去向。
+TDD 的决策记录采用相同原则：设计要求、当前采用值和实际工程约束直接写入对应分册，重要取舍按需保留分析，未决事项说明影响与下一步，不要求逐项登记到外部台账或附推翻条件。总册保留施工索引、跨分册约定与重要缺口，详细问题指向对应分册。问题解决后更新受影响的 GDD 与 TDD 正文并关闭待办，不能只登记处理去向。
 
-“施工方只看 TDD，应能完成当前范围的实现”仍是完成标准。保留 GDD 内容收编、来源版本与变更同步，以及资产清单、字段字典、接口规格、验证方法与已有检查结果等施工信息；外部分析与台账不能代替 TDD 的实现说明。当前范围仍有影响实现的关键问题时，不得宣称该范围已完备。样例中尚有缺口的 TDD 应如实展示未完成状态，不以已登记或部分检查通过代替规格完整。
+“施工方只看 TDD，应能完成当前范围的实现”仍是完成标准：设计要求、内容与数值、实际工程约束和验收条件写全，施工方无需回查 GDD 或猜测关键设计。保留来源版本与变更同步，外部分析与台账不能代替正文。代码组织、算法、内部接口、字段与数据结构、配置载体、资源命名与打包由施工方自主决定；未预定这些实现选择不构成策划缺口。已有工程契约、实际数据/资源格式和用户明确交付约束必须记录；有依据的实现建议可供参考，不成为唯一方案，也不增加逐项登记或用户确认。
 
-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 规则而不要求逐段全文复制；来源版本集中在总册记录，设计变化同步受影响正文。删除固定数据→程序→美术顺序、必读样例、P0 七件与三态、逐节表格、固定建表步骤、统一条件求值器和七查三级等写作纪律。数据分册仍须给出当前范围全部配置与文案及可复核验算，不以示例行代替；美术采用类别共性规格、明确对象清单及例外，保留命名、绑定、消费方式与验收判据，不再强制全部对象绑定 item_id 或维护生产状态台账。
+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 保留。
 
@@ -330,9 +330,9 @@ TDD 按实际内容组织，可重组 GDD 规则而不要求逐段全文复制
 
 拆分应带来有用的独立规则边界，不因变量、操作不同或未来可能替换就单独设系统；简单职责可在同一系统内部表达。架构概述关键协作，保留影响结果的顺序与共享约束，职责、数据归属和文档位置可合写，不重复建表。完整行为流程在主要负责的系统文档展开，其他参与方说明自身接收、处理与返回，按需引用完整流程并就近保留理解本系统所需的前提和结果。
 
-系统交互区分调用、通知、读取与玩法反馈；双向关系不自动判为架构错误，按实际问题检查循环调用、职责纠缠和更新顺序。主数据有明确的权威维护方，只读副本、派生视图和快照说明来源及更新或恢复方式，不成为第二套独立维护的事实。为判断职责和协作所需的规则、字段与参数可以明确，系统文档继续展开行为，TDD 收编并补齐完整实现规格。
+系统交互区分调用、通知、读取与玩法反馈；双向关系不自动判为架构错误，按实际问题检查职责纠缠和更新顺序。主数据归属明确，实际需要的副本或快照说明来源与预期结果，不要求额外设计更新机制。系统文档展开行为，TDD 收编并补齐设计要求、内容与数值及实际约束，内部实现由施工方决定。
 
-保留 Sxx 编号与 `project/03_systems/...` 文档位置，可以按内容合并或拆分文档；该映射不决定代码目录，代码模块与文件组织由 TDD 明确。实现范围区分完整版本、首个原型及后续内容，不固定 P0/P1/P2，也不要求验证失败就退回顶层或禁止调整系统划分。星露谷样例明确 NPC 日程、资源点、物品与经济等归属，首个原型包含基础采集，按单日选择和多日成长分别验证。
+保留 Sxx 编号与 `project/03_systems/...` 文档位置，可以按内容合并或拆分文档；该映射不决定代码目录，代码模块与文件组织由施工方选择。实现范围区分完整版本、首个原型及后续内容，不固定 P0/P1/P2，也不要求验证失败就退回顶层或禁止调整系统划分。星露谷样例明确 NPC 日程、资源点、物品与经济等归属，首个原型包含基础采集，按单日选择和多日成长分别验证。
 
 系统总纲、相关系统类型资料与 TDD 的直接引用同步承接职责、协作、数据归属和当前实现范围，不再依赖架构 P0 清单、固定依赖图或仅限定性的数值基准。数据侧按实际玩法选择验算场景与跨度；技术侧按当前施工范围收编全部必需行为，不能因某系统标为后续优先级而遗漏当前所需规格。速览卡与 TDD 样例同步首个原型范围，基础采集、跨日结算规格和完整数值验算的缺口如实标明，局部推算不作为验算通过的证据。施工完备要求、产物路径与阶段审批合同保持不变。
 
@@ -340,9 +340,9 @@ TDD 按实际内容组织，可重组 GDD 规则而不要求逐段全文复制
 
 这些维度是信息覆盖要求，不是独立章节要求。参与方、数据来源、处理顺序和反馈可随行为一次说明，已讲清的内容不再另列协作表或反馈章节；简单同步处理不额外设计消息、确认或中间状态。相关类型模板将协作与反馈并入具体行为，架构样例合并职责与文档映射、战斗样例将协作归属就近写入行为。去重不降低关键行为边界、结果一致性和 TDD 独立施工要求，不改写已有项目产物。
 
-十二类系统资料保留类型特有的设计问题，模板不预填未经选择的动作、状态、循环和数据表。日历、生产队列、成长分支、复杂叙事、节日专属玩法和战斗定位均由实际项目决定；系统职责与权威数据归属遵循架构，UI 可以维护交互、导航和临时状态，正式玩法校验与结算仍由对应系统负责。跨系统行动明确整体成功或失败的预期结果，具体实现协议由 TDD 落实。
+十二类系统资料保留类型特有的设计问题，模板不预填未经选择的动作、状态、循环和数据表。日历、生产队列、成长分支、复杂叙事、节日专属玩法和战斗定位均由实际项目决定；系统职责与权威数据归属遵循架构，UI 可以维护交互、导航和临时状态，正式玩法校验与结算仍由对应系统负责。跨系统行动明确整体成功或失败的预期结果，TDD 收编设计约束，具体实现机制由施工方选择。
 
-系统文档保留已定规则、单位和参数，TDD 从相关内容收编并补齐完整实现规格，不依赖固定交接章节。系统编号、文档位置、资源登记及审批语义不变。战斗样例明确为后续矿井原型的暂定方案：实时基础动作、安全撤退保留成果、倒下可能损失部分钱物，未定规格和待执行验证如实标明；TDD 日常原型样例不提前收编后续战斗，纳入施工范围时再补全规则与规格。
+系统文档保留已定规则、单位和参数，TDD 从相关内容收编并补齐设计与实际接入缺口，不依赖固定交接章节。系统编号、文档位置、资源登记及审批语义不变。战斗样例明确为后续矿井原型的暂定方案：实时基础动作、安全撤退保留成果、倒下可能损失部分钱物，未定设计和待执行验证如实标明；TDD 日常原型样例不提前收编后续战斗。样例中的代码、数据和资源组织不再作为预先设计或验收要求，仍缺少的玩法、内容、数值及表现如实保留。
 
 进入下一阶段必须由用户批准触发。Runtime 推进后向 Agent 追加明确的用户行为语义，例如“用户已批准上一阶段，现在进入顶层设计阶段”，避免 Agent 误认为 Runtime 自行推进。