简化TDD写作规则并明确策划案验收边界

简化 TDD 总纲、三份写作规则、四份模板与配套样例，取消固定流程和重复登记
保留仅凭本套 TDD 可完成当前范围实现的标准，明确策划案验收与后续生产验证的边界
技术选型限定在 Game Agent 已支持范围内，更新新二维 Web 的 npm、Vite 与 Phaser 约束
统一星露谷首个日常原型范围、跨分册引用与示例参数，如实保留施工和验算缺口
同步策划技术方案与共享决策记录

apps/ai-game-creator-shell/src-tauri/design-agent/resources/exemplars/stardew-tdd-art-bible.md

@@ -1,85 +1,64 @@
-# 美术圣经：《星露谷物语》（TDD 金样 · 美术圣经）
+# 美术圣经：《星露谷物语》首个日常原型（TDD 示例）
 
-> 状态：reviewed　|　设计依据：概念层@v1「身份、基调与世界观」「边界与约束」（温暖乡村、慢节奏、治愈、轻度压力）　|　style_id：`stardew_warm_rural_pixel`
-> 本例仍有换装范围、锚点图和字体等待解决的问题；相关规格为草案，不能将局部资产验收当作整体规格完备。
-> 实证规格来源：星露谷 1.6.15 解包知识库 v3（资产计数时点 2026-09-11，快照 stardew-1.6.15-7f1e5b8e）。写新项目时按本项目定调重译，数字仅作规模参照。
+## 范围与设计依据
 
-## 视觉风格总览
+本例只覆盖首个日常原型：农场、小镇、基础采集区域；耕地、播种、浇水、跨日生长、收获、买种、出售，以及时间、天气、体力、背包、金钱和日终反馈。它承接同目录 `stardew-concept.md` 的“身份、基调与世界观”“边界与约束”，以及 `stardew-architecture.md` 的“首个原型范围”“实现范围与验证”。矿井、战斗、NPC 日程、关系、钓鱼、畜牧、节日、多人和大批换装属于后续范围，本例不为它们预配首期图集。
 
-承接概念层温暖乡村与季节变化的视觉气质：**"被四季照亮的温暖小农场"**——手绘感像素、俯视 45° 视角，春夏绿意、秋日暖橙、冬季留白，颜色随季节整体切换而不是换贴图；物件轮廓圆润、无锐利科技感。玩家一看画面就该感到：这里节奏很慢，干活是安心的。参考图位 4 张（量产流程第 3 步产出锚点图）。
+视觉依据是温暖乡村、复古像素、轻度压力和可反复游玩的日常节奏，来源版本见总册。**目前没有已选定的参考图、画风卡或可验收的源素材**；以下色值和尺寸是示例策划假设，供后续视觉确认。目标运行时是新建 2D Web 原型（npm + Vite + Phaser 4.2.1）。美术源文件和导出资源尚未产出；预定资源入口为项目内 `assets/art/source/`（可编辑源文件）、`game/public/assets/art/`（PNG 和帧表 JSON）与 `game/public/assets/audio/`（音频）。运行素材由 Vite 复制到 `game/dist/assets/`，程序按构建内相对路径加载；这些是预定交付位置，不表示文件已存在。
 
-## 视觉锚
+## 视觉规则
 
-- 关键词：温暖、手绘像素、田园、四季分明、生活感。
-- 禁用关键词：阴暗压抑、血腥恐怖、高饱和霓虹、写实渲染、锐利科技风（依据概念层的温暖治愈基调、乡村像素风和不制造生存焦虑的边界）。
-- 色板：主色 暖土绿系（草地/耕地基底）60% ／ 辅色 暖木棕+瓦顶红 30% ／ 点缀 季节信号色（春樱粉/夏浓绿/秋橙/冬蓝白）10%。昼夜·天气·季节表现：季节=色调与植被整体切换；天气=雨天全屏冷色叠加（原作 OrangeRed×0.45 实证）；昼夜=时刻线性插值环境光。
-- 形状语言：圆润矩形轮廓，物件以 16px 网格对齐；无 1px 高光乱线。
-- 比例与轮廓：物件 16px 一档；NPC 16×32（渲染放大 4 倍）；玩家可完全自定义外观。
-- 光照与材质：不做真实光照——低分辨率 lightmap 乘法混合；优先级链=矿井 tint＞室内 ambient＞室外 outdoor（时刻插值）；十种光源贴图常量够用。
-- 渲染口径：纯像素、无抗锯齿、整数倍缩放（程序侧能力边界同源）。
+- 关键词：温暖、朴素、清爽、生活感。避免血腥、霓虹、高反光写实材质、尖锐科技造型和繁密的随机像素噪点。
+- 色板示例假设：草地基色 `#78A85A`、泥土 `#9D7048`、木材 `#AA724C`、纸面 `#F2E1B9`、操作提示 `#E8BE62`、不可用 `#738291`。这些是设计锚点，实际调色板及色弱可辨性须在首批视觉样张中确认；状态不能只靠颜色区分。
+- 画面采用近正上方的斜俯视像素场景，地面按 16×16 世界像素网格排布。人物脚点落在格中心下沿；可遮挡的建筑/树冠在人物之上，地面和作物基座在人物之下。建筑、箱子和植物用圆润轮廓，亮面集中在左上，阴影不使用柔边渐变。
+- 游戏世界用最近邻采样、整数倍缩放和像素对齐；示例假设移动端世界像素放大 3 倍、桌面端 4 倍，布局可裁剪视野但不拉伸像素。HUD 使用清晰文字与图形，不把 16px 图标放大后作为 44 CSS px 的触控热区；热区由 UI 布局提供。
+- 当前范围只需晴、雨和日间至傍晚的可辨反馈。雨天在地面与图标之外加低强度冷色层和雨线；傍晚用统一环境色层。天气图示另带“晴/雨”文字，避免仅靠色调识别。季节全套换景不是首期要求。
 
-## 角色模板
+## 类别规格
 
-- 基础规则：玩家=换装组合而非整图——19 个独立层（基础体/裤/衣/发型/饰件/配件…），每层独立图集，调色板像素 256-277 区域换色实现同图集多变色；层深=基准+层序×1e-6 保证叠加次序稳定。NPC=16×32 四方向小人+64×64 立绘（对话用）。
-- 方向数：4 方向（左=右镜像：是——行走图按方向分行布局，如 64×448=4 列×14 行）。
-- 动画状态：待机/走 walk=4 帧循环、每帧 200ms（帧表含毫秒级帧时长）；受击/使用工具按动作逐条登记帧表。玩家帧表量大（原作 500+ 动画参数为 switch 硬编码），本项目帧表走数据表不走硬编码。
-- 立绘表情：六表情索引 0-5（$neutral/$happy/$sad/$unique/$love/$angry），对话文本中 `$表情` 标记驱动切换。
+下表参数均为示例假设；后续确定时应在本分册更新，不能把本段视为已经产出的资产事实。帧键按对象标识及适用的状态、方向、帧序组成；同类共性只定义一次。
 
-## 场景模板
+| 类别 | 共性规格 | 命名与交付格式 | 运行时消费 | 后续验收判据 |
+|---|---|---|---|---|
+| 地形图块 | 每格 16×16；地面可无透明，边缘变体不留缝；绘制时留 1px 图集挤出边防采样渗色 | `tile_{terrain}_{variant}`，PNG 图集+JSON 帧表 | 地图按 `region_id` 的格子与图层取帧；湿地块读取地块状态，不复制一张整农场图 | 每帧 16×16、图集无渗色；干湿耕地与普通土路在目标缩放下能区分 |
+| 场景物 | 按占格记录脚点和遮挡高度；静态物 1 帧，交互状态单列 | `prop_{object}_{state}`，PNG 图集+JSON 帧表 | 地图对象标识决定帧；遮挡层按脚点排序，交互热点由地图数据给出 | 图像、脚点、碰撞/热点对齐；可交互物与背景有轮廓差异 |
+| 玩家 | 单个 16×32 角色，不做换装层；待机每方向 1 帧、走路每方向 4 帧，工具动作是否专帧待确定 | `player_{state}_{dir}_{frame}`，PNG 图集+JSON 帧表；方向 `down/up/left/right`，右可镜像左 | 移动状态驱动待机/行走，帧表注明顺序和时长；脚点固定在帧底中心 | 四方向基准点一致，镜像后工具手势不误导；行走不跳格或抖动 |
+| 作物与采集点 | 作物占 1 格，按数据侧生长状态取 16×32 透明帧；采集点包含可采和已采状态 | `{crop_id}_{stage}` / `{forage_node_id}_{state}`，PNG 图集+JSON 帧表 | 数据状态映射到帧键，成熟和可采必须有独立轮廓；状态数以数据分册最终定义为准 | 各状态有唯一帧键，无缺帧；未熟/成熟、可采/已采在移动视口能辨认 |
+| 物品图标 | 16×16，透明背景，单帧；工具和产物同一盒内留 1px 内边距 | `icon_{item_id}`，PNG 图集+JSON 帧表 | 背包、商店、出售清单按 `item_id` 查图标；金额、数量由 UI 文字绘制 | 图标键与物品表逐项匹配，无空白或越界；种子、产物、工具形状可区分 |
+| UI | 面板、槽位、进度条用 CSS 或九宫格按界面实现，文字走字体系统；天气图示与操作提示可为 16×16 图标 | 需要图片时用 `ui_{element}_{state}`；UI 图 PNG，文字不烘入纹理 | HUD、背包、商店、出售和日终视图读取权威状态；禁用态以图形与文字共同提示 | 数字与图标不重叠；移动端本例暂定触控热区至少 44 CSS px，桌面/移动两视口可读 |
+| 音频 | BGM 暂定 OGG 循环、目标 -18 LUFS；SFX 暂定 WAV 单发，均为本例假设；时长、采样与混音参数待补齐 | `bgm_{usage}` / `sfx_{action}`，独立文件；循环点随资源给出 | 首次用户操作后启用音频；按游戏事件触发，具体绑定由技术分册补齐 | 在目标浏览器可解码，循环无接缝，事件不重复触发，反馈清楚且不盖过其他必要提示 |
 
-- tileset 规格：16px tile；TileSheets 级图集约 41 张+地形特征图集 38 张（作物/树）；padding 1px 防渗色。
-- 图层拆分：四层 Back/Buildings/Front/AlwaysFront（深度 -1/0.1/64+/-1）——地面/建筑/前景遮挡/最前；碰撞由 Buildings 层属性驱动；矿井布局池按模板拼装（原作 61 张模板，本项目首期 8~12 张）。
-- 场景对象规则：多帧素材禁当静态贴图（作物生长/角色必须走帧表）；单元素禁整图（区域由 tile 拼装，禁为每区域画整张立绘）；地图数参照：原作 259 tmx+304 预览，本项目首期 3 区域（农场/小镇/矿井）。
+## 当前范围对象清单与例外
 
-## UI 视觉
+清单用对象组列出有限变体，适用上面的类别规格。物品和作物标识以数据分册为准；若数据分册尚未给完整首期清单，下列命名只作示例，**不能据此宣称原型素材范围已全量对账**。
 
-承 UI 系统文档界面清单（HUD/背包/商店/对话/日终结算五界面）。视觉语言：木质面板底+纸张质感对话框；信息分层——价格信息永远暖金、锁定/禁用永远灰蓝、日终收入单列。字体用位图字体（原作 5 fnt 位图字体实证）。触控版式热区 ≥44px 与程序侧输入表同源。特效走程序动画（按帧表播图集区域）+粒子，不逐特效画整图（原作 LooseSprites 156 张 UI/杂项图集规模参照；最大图集实测 1920×1376）。
-
-## 素材规格契约
-
-| 素材 | 规格（尺寸/帧数/方向数） | 命名规则 | atlas 格式 | 验收 | 绑定 |
+| 对象或明确对象组 | 类别 | 标识/数据绑定 | 状态与变体 | 规格例外或无图像资产的处理 | 消费位置 |
 |---|---|---|---|---|---|
-| 物品图标 | 16×16，1 帧 | `icon_{item_id}` | JSON atlas | 技术+视觉 | `item_*` 全量（参照原作 807；本项目首期 ~120 行） |
-| 作物 | 16×32×相位帧（4~5 相位，每相位 1~2 帧） | `crop_{crop_id}` | JSON atlas | 技术+视觉 | `crop_*`（参照原作 50） |
-| 玩家换装层 | 每层独立图集，walk 4 帧×4 方向 | `farmer_{layer}_{state}_{dir}` | JSON atlas | 技术+视觉 | 豁免（角色非物品，登记于本表） |
-| NPC 行走+立绘 | 行走 16×32 四方向行布局；立绘 64×64×6 表情 | `npc_{id}_walk` / `npc_{id}_portrait_{expr}` | JSON atlas | 技术+视觉 | `npc_*`（参照原作 34 社交 NPC/101 立绘；本项目首期 8 位） |
-| tileset | 16px，边缘连接变体 | `tile_{theme}_{variant}` | JSON atlas | 技术+视觉 | 豁免（场景组件） |
-| UI 面板 | 9 宫格切片，3 态 | `ui_{element}_{state}` | JSON atlas | 技术+视觉 | 豁免（UI） |
-| BGM | ogg，-18LUFS，循环点标记 | `bgm_{season}` 4 首+矿井 1 首 | — | 响度+循环 | 豁免（音频契约） |
-| SFX | wav 单发 | `sfx_{event}`（事件↔音效映射表登记） | — | 同帧触发 | 豁免（音频契约） |
+| 农场、小镇、基础采集区域 | 地形图块/地图 | `region_id`：`farm`、`town`、`forage`（示例假设） | 草地、土路、干耕地、湿耕地、边界与出入口；必要的相邻边缘变体 | 每区由 tile 与对象图层拼装；地图格、出口和碰撞数据需随地图一同交付，不能以整图代替 | S04 场景加载、S03 地块展示 |
+| 农舍外观、出货箱、小镇种子商店门牌 | 场景物 | 地图对象 `farmhouse`、`shipping_bin`、`seed_shop` | 默认；出货箱可交互、商店开/关由 UI 文本或标记提示 | 农舍可跨多格，需给实际占格与脚点；不为商店首期制作有日程的店员 | S04 地图与 S09 商店/出售入口 |
+| 野外采集点 | 作物与采集点 | `forage_node_id` 对应地图资源点 | 可采、已采；刷新后回可采，触发时机待 S04/S05 定义 | 采集物外观与其背包图标可以不同 | S04 资源点、S05 采集反馈 |
+| 防风草作物 | 作物与采集点 | `crop_id=crop_parsnip`（数据分册局部示例配置） | 播种后各生长阶段、成熟；浇水通过地块湿态呈现 | 数据样例仅给 `growth_days=4`，四次满足条件的跨日不等于四个视觉阶段；阶段数和映射待定 | S03 地块投影 |
+| 玩家 | 玩家 | `player` | 四方向待机、行走；工具动作待确定 | 不做 19 层换装、立绘或 NPC 表情 | S04 移动、S03 农务、S05 采集 |
+| 防风草种子、防风草 | 物品图标 | `item_id=parsnip_seed`、`parsnip`（数据分册局部示例配置） | 每物品 1 图；数量与价格均由文字显示 | 只覆盖局部示例配置，不代表首期全量物品 | 背包、商店、出售清单 |
+| 采集物、锄头、水壶 | 物品图标 | `wild_berry`、`hoe`、`watering_can` 是待数据确认的示意标识 | 每物品 1 图；数量与价格均由文字显示 | 数据规则与数值未定，不能据此进入全量生产；金币无需物品图标 | 背包、商店、出售清单 |
+| 时间/天气/体力/金钱、背包、商店、出售、日终与存读档 | UI | S01/S02/S07/S09 状态与界面标识 | 晴/雨图示，体力进度与低体力提示，可买/不可买、可卖/不可卖、结算前后 | 数值、名称、日期、价格和说明由 UI 文本绘制；进度条和槽位可程序绘制，按界面无需逐状态出图 | HUD 与各界面 |
+| 日常环境音乐与行动反馈 | 音频 | 暂定 `bgm_daily`，以及耕地、播种、浇水、收获、采集、购买、出售、日终的 `sfx_{action}` | 单一日常循环与各成功事件单发；失败提示是否需要独立音效待定 | 不预填四季或矿井音乐；精确事件、文件名与音量映射待补齐 | 场景音频、S03/S05/S09 与日终反馈 |
 
-- 绘制工艺：按项目实际制作路径逐类记录参数与封装流程；施工环境无产出通道时规格先行锁定、状态如实登记"缺失"。
-- 音频契约说明：原作 XACT cue 名 435 候选/代码引用 230 个——本项目首期 SFX 事件 20 只起步，按事件总线 `sfx_event` 映射表登记，不逐 cue 复刻。
-- 豁免类型仅限：程序化生成（矿井布局由表驱动拼装）/ UI 文本 / 本期不需要——每项豁免在契约行写明。
+## 后续生产与接入验收
 
-## 资产状态表（asset manifest）
+- 交付时保留可编辑源文件，并按类别导出 PNG 与帧表 JSON。帧表至少给帧键、矩形、脚点、状态、方向、帧时长；地图另给格子、图层、对象脚点、出口和碰撞数据。生产前先用少量地形、角色、作物、图标和 UI 样张核对色板与比例，再按已定规格扩充；样张数量由实际疑点决定。
+- 技术验收逐项对照**最终数据清单**核对对象键：图集和帧表能解析；帧矩形不越界；16×16 图标/地形与 16×32 玩家符合约定；透明通道、边缘和脚点正确；作物与采集状态都有帧。接入场景后移动、播种、浇水、跨日成长、采集、买卖和日终均能取到正确帧或程序绘制状态，缺帧或错误状态即不通过。
+- 视觉验收在桌面与移动视口截取农场、小镇、采集、背包、商店、出售和跨日后的画面，对照本分册检查乡村像素风、角色脚点、干湿地块、作物未熟/成熟、可采/已采、天气与禁用态。请观察者不看说明指出可操作对象与关键状态；若只能靠颜色或反复试错识别，就需调整形状/文字提示后复验。
+- 这套检查是**后续生产和接入的判据**，不表示已有素材通过。新增物品、区域或状态时，先更新数据/系统清单，再更新本页对象、帧键和消费映射。
 
-| asset_id | 规格 | 绑定 | 状态 | 验收记录 | contract_version |
-|---|---|---|---|---|---|
-| icon_item_*（首期 ~120 行，逐 item_id 一行） | 16×16 | `item_*` | 缺失 | — | 1 |
-| crop_*（50 行） | 16×32 相位帧 | `crop_*` | 缺失 | — | 1 |
-| farmer_*（19 层图集） | 4 帧×4 方向 | 豁免 | 缺失 | — | 1 |
-| npc_*_walk / _portrait（8 位×7 件） | 16×32 / 64×64×6 | `npc_*` | 缺失 | — | 1 |
-| tile_*（3 主题变体组） | 16px 变体 | 豁免 | 缺失 | — | 1 |
-| ui_*（5 界面套件） | 9 宫格 3 态 | 豁免 | 缺失 | — | 1 |
-| bgm_*（5 首） | ogg -18LUFS | 豁免 | 缺失 | — | 1 |
-| sfx_*（20 只） | wav | 豁免 | 缺失 | — | 1 |
+## 当前未决问题
 
-- 状态单向流转：缺失 → 草稿 → 已交付 → 已验收 → 已接入；驳回退回草稿并记原因。
-- 验收两维：技术（尺寸/透明/帧数/命名）+ 视觉（对照视觉锚）；两维都过才进"已验收"。
-- **每个 gameplay 可见对象必有一行或显式豁免——没有第三种状态**：物品图标逐 item_id 与数据侧物品表逐行对账（参照规模：原作 Characters 215 png/Portraits 101/TileSheets 41/TerrainFeatures 38/LooseSprites 156）。
-- 程序接入后填消费点（哪个模块加载、事件映射），`contract_version` 变更须重验收。
-
-## 量产流程与验证
-
-1. 概念候选 4 张（农场一角/角色/物品图标/UI 面板各 1 方向稿）→ 2. 人选方向（用户确认）→ 3. 锚点图 4 张 → 4. 锁圣经 → 5. 写契约（本例的相关缺口仍待补齐）→ 6. 小批 8 张（icon_item 子集：防风草种子/防风草/木材/石头/铜矿/锄头/水壶/出货箱）→ 7. 技术检查（尺寸/透明/命名/atlas 解析）→ 8. 接入程序（v0.1 里程碑）→ 9. 运行时截图验收（桌面/移动双视口下 16×16 图标与作物相位可辨、四季色调正确）→ 10. 扩产（8→120→全量）。
-
-## 待解决问题
-
-| 问题 | 影响 | 下一步与需更新的正文 |
+| 问题 | 对当前施工的影响 | 下一步与需更新的位置 |
 |---|---|---|
-| 换装首期是否采用 5 层 | 决定角色图集数量与程序分层接口 | 确认范围后，在角色规格及素材契约写清采用的层次、顺序与命名；当前建议为基础体、裤、衣、发型、饰件 |
-| 锚点图方向待用户确认 | 影响后续素材的视觉验收依据 | 用户确认后将锚点及具体风格要求写入视觉规格，更新受影响的素材契约 |
-| 位图字体还是矢量像素风字体 | 影响文字渲染与 UI 资产格式，正文的位图方案尚为暂定 | 小批 UI 验证后定案，将字体资源、格式与使用方式补入 UI 规格并同步程序分册 |
+| 数据分册目前只有 `parsnip_seed`、`parsnip` 与 `crop_parsnip` 的局部示例配置；完整物品/采集点 ID 与作物视觉阶段未定 | 无法最终对账图标和作物帧键，也不能给出全量资产数；`growth_days=4` 不能代替阶段映射 | 数据分册定稿后填入对象清单及物品、作物、采集点帧键映射 |
+| 技术分册暂定农场 80×65 格、小镇 50×40 格；采集区域尺寸、各区域出口、遮挡物占格与碰撞仍不完整 | 地形和场景物的实例数量、脚点与地图数据无法施工 | 地图规格确定后补地图对象表和场景物例外，并同步 S04 |
+| 视觉锚图、实际调色板与字体尚未选定 | 可按文字规则做方向稿，但最终视觉一致性与 UI 字符可读性仍需评审 | 选择可访问的锚图与字体资源后更新“范围与设计依据”“视觉规则”“类别规格” |
+| 工具动作帧和具体 UI 布局尚未确定 | 农务动作与移动端操作反馈无法完成逐状态切图 | 交互规格确定后补玩家动作帧和 UI 状态映射 |
+| 图集 JSON 格式、帧时长与音频参数/事件映射未全定 | 程序无法直接加载所有动画或绑定声音 | 明确与 Phaser 加载方式一致的格式和映射，同步技术分册 |
 
-问题解决后更新对应正文并移出待办，施工方无需从外部台账查找最终规格。
+本例展示如何写出当前范围的规格与后续验收方法；以上缺口仍影响实际施工，因此不宣称首个原型的美术策划案已经完备。

apps/ai-game-creator-shell/src-tauri/design-agent/resources/exemplars/stardew-tdd-data.md

@@ -1,107 +1,75 @@
-# 数据与配表：《星露谷物语》（TDD 金样 · 数据与配表）
+# 数据与配表：《星露谷物语》题材写法示例
 
-> 状态：待补齐（基础采集配置、当前范围验算、背包容量与公共索引定义仍有缺口）　|　基于：各系统规则与数据汇总 ＋ 归 TDD 素材两份提取件（S06 数值结构／架构字段字典）　|　已有数据验收：check@C-2026-09-11-v1；不代表当前范围规格已完备
-> 实证计数来源：星露谷 1.6.15 解包知识库 v3（13 张数据表，提取脚本断言通过；快照 stardew-1.6.15-7f1e5b8e）。写新项目时按本项目的系统规则与数据需求重建，计数仅作规模参照。
+> 本例只演示首个日常原型的数据侧写法：农场与小镇、基础采集、耕种、商店购买、出售、跨日成长。下列数值是用于演示计算的**项目假设**，不是原作实证或解包数据。本例尚未填满当前范围，未通过策划文档验收，更不代表游戏成品验收。
 
-## 数据表总清单
+## 数据范围与归属
 
-以下包含完整版本的数据类别；v0.1 只取首个日常原型需要的农务、基础采集、物品、交易、成长、时间与地图等内容。战斗、钓鱼、关系、任务和节日数据用于后续范围，不作为 v0.1 已实现能力。
+| 数据或配置 | 维护系统 | 原型用途与消费方式 |
+|---|---|---|
+| 日期、天气、跨日触发 | S01 时间 | S03 读取日期和天气决定成长；S09 接收日终结算时点 |
+| 行动体力成本与恢复 | S02 体力 | 农务和采集动作提交成本；数值尚未确定 |
+| 地块与作物 | S03 农场 | 引用 S07 的种子与产出物品 ID；播种、浇水、跨日成长和收获由 S03 判定 |
+| 农场、小镇、资源点位置及可用状态 | S04 地图 | S05 读取可采集资源点并在成功后请求更新；点位和刷新尚未确定 |
+| 采集获得物与经验规则 | S05 采集 | 成功时向 S07 请求物品入账、向 S08 报告经验；产物与判定尚未确定 |
+| 种子、作物产物、采集物的身份与持有 | S07 物品 | 由 S03/S05 产出、S09 买卖；背包容量尚未确定 |
+| 农务与采集经验、等级 | S08 成长 | 接收活动结果；本例只给出首级阈值的演示值 |
+| 起始货币、商品价格、库存、出售与出货 | S09 经济 | 商店和出货箱使用同一价格定义；营业、库存和结算规则尚未确定 |
 
-| 表格组 | 建议表名 | 主要维护系统 | 实证规模（原作 1.6.15） |
+表或文件的拆分由实现方式决定，上述数据归属不随存储方式改变。当前只需要稳定引用：`parsnip_seed` 是种子物品，`crop_parsnip` 引用该种子与 `parsnip` 产出物品。S09 维护其买价和卖价，不在 S03/S07 复制价格。
+
+## 已知字段契约与示例配置
+
+下表只覆盖已出现的字段。ID 是不随显示名称变化的字符串；引用不存在时不能把动作算作成功。数值单位写在字段定义中，不能把游戏日、体力、金钱和经验混用。无默认值的字段必须显式给值；本例没有授权用 `0`、空值或估值替代缺失配置。
+
+| 字段及维护者 | 类型与单位 | 本例约束/默认值 | 消费方式 |
 |---|---|---|---|
-| 物品与经济 | 物品表、品质表、商店表、商店库存表、价格表 | 物品与制作、经济与商店 | 物品 807×29 类；商店 77 店 897 条库存（含店级 PriceModifiers） |
-| 农场内容 | 作物表、动物表、设施表、加工配方表 | 农场经营 | 作物 50 全字段；机器 39 台全 OutputRules |
-| 活动内容 | 资源点表、采集规则表、钓鱼点表、鱼类表、敌人表、敌人行为表、遭遇表、战利品表 | S04 管资源点位置、可用与刷新状态；S05 管采集/钓鱼判定及获得物；S06 管战斗与战利品规则 | 怪物 51 条配置；怪物 AI 矩阵 30 类移动原型 |
-| 物品制作 | 通用配方表、配方解锁表 | S07 管配方定义；S08 管技能解锁，S11 管任务条件，使用方引用结果 | 配方 231（烹饪 81+工艺 150，全原料/产出/解锁） |
-| 玩家成长 | 技能表、等级经验表、能力节点表、工具升级表、效果表 | 成长与技能 | 职业 30 全效果钩子（51 钩子+6 数据驱动）；附魔 34 逐项数值；经验曲线代码常量 |
-| NPC 与任务 | NPC 表、关系等级表、礼物偏好表、任务表、奖励表、事件条件表 | NPC/任务/事件 | NPC 送礼 34NPC×4 档+全局 5 档；事件 258/条件码 39 |
-| 时间与世界 | 日期季节表、天气表、节日表、营业时段表 | S01 管日期天气，S12 管节日，S09 管营业条件；居民日程归 S10 | —（代码常量+日程数据驱动） |
-| 文本与展示 | 文本表、UI 提示表 | UI 与文本呈现及各内容系统 | 11 语言按后缀拆分（含 zh-CN） |
+| S07 `item_id` | 非空字符串 | 必填、唯一；无默认值 | S03、S05、S09 以 ID 引用物品 |
+| S03 `crop_id`、`seed_item_id`、`harvest_item_id` | 非空字符串 | 必填、唯一作物 ID；两个物品引用无默认值 | 播种消费种子；收获请求产出物品入账 |
+| S03 `growth_days` | 非负整数，游戏日 | 必填；本例 4；无默认值 | 每次满足成长条件的跨日推进一次 |
+| S09 `buy_price`、`sell_price`、`starting_currency` | 非负整数，金 | 必填；无默认值 | 买入扣款、出售入账、开局钱包 |
+| S08 `farming_xp_per_harvest`、`farming_level_1_xp` | 非负整数，经验 | 必填；无默认值 | 成功收获入账并比较等级阈值 |
+| 验算 `seed_count` | 非负整数，包 | 仅场景输入，本例 15；不是商店库存默认值 | 验算一次购买和播种的总量 |
 
-（表格拆分是生产组织方式，不改变主数据归属。原作同套模型同时服务本体与模组生态——静态表为结构化 JSON-in-XNB，由 DataLoader 按需缓存。）
-
-## 字段字典与 ID 命名规范
-
-- ID 命名：小写 snake_case，`对象类型_名称_必要时加阶段`（如 `item_turnip`）；全局唯一、废弃不复用。（原作实证：1.6 起用限定 ID 如 `(O)123` 统一引用 807 物品——原理同源：ID 不含人话、不随语言变。）
-- 通用字段：`*_id` / `display_name_text_id` / `description_text_id` / `condition_id` / `enabled_state`（active·draft·disabled·deprecated）/ `sort_order` / `designer_note` / `unit`（数值字段必填：time_slice·game_day·currency·stamina·exp）。
-- 常用后缀：`_amount`（配单位）/ `_cost` / `_rule_id` / `_condition` / `_time` / `_duration` / `_state` / `_text_id`。
-- 类型与空值：数值栏禁"约/无/待定"；空值=不适用≠0≠无限（无限制库存用 `stock_type=unlimited`，不用 999999）；布尔 true/false；多值一律关系子表（多材料配方禁拼一格）。
-- 引用完整性：`item_id`→物品表；`location_id`→区域表；`npc_id`→NPC表；`quest_id`→任务表；`recipe_id`→配方表；`condition_id`→条件表；`text_id`→文本表。删除先置 `deprecated` 并查引用。
-- 枚举实证注意：品质枚举值为 0/1/2/4（银=1、金=2、铱=4）——所有 `(1+0.25×quality)` 型公式乘数因此是 1.25/1.5/2.0；枚举值是语义约定，禁止想当然重排。
-
-## 公共条件表
-
-| condition_id | condition_type | target_id | operator | required_value | enabled_state | 备注 |
-|---|---|---|---|---|---|---|
-| `condition_day_2` | `date_day` | `season_spring` | `>=` | 2 | `active` | 春季第 2 日后可触发 |
-| `condition_shop_unlocked` | `progress_flag` | `flag_general_store_open` | `==` | 1 | `active` | 杂货店已开放 |
-| `condition_skill_farming_1` | `skill_level` | `skill_farming` | `>=` | 1 | `active` | 农务技能达到 1 级 |
-| `condition_blacksmith_open` | `schedule_open` | `schedule_blacksmith_default` | `==` | 1 | `active` | 铁匠铺当前处于营业时段 |
-| `condition_recipe_repair_path` | `quest_completed` | `quest_repair_path` | `==` | 1 | `active` | 修路任务完成后解锁基础洒水器配方 |
-
-（复杂条件拆条件组+条件行；全项目只此一个条件入口，程序实现一次 `check(condition_id)`。实证参照：原作 258 事件共用 39 个条件码——条件收敛是可达到的规模。）
-
-## 工作簿组织与建表顺序
-
-| 工作簿 | 工作表 |
-|---|---|
-| `世界与地图.xlsx` | 日期季节、天气、日程、区域、区域连接、活动入口 |
-| `农场与制作.xlsx` | 地块、作物、动物、设施、加工配方、通用配方 |
-| `物品与经济.xlsx` | 物品、品质、装备、价格、商店、商店库存、货币 |
-| `活动与战斗.xlsx` | 采集点、掉落、钓鱼点、鱼类、敌人、行为、遭遇 |
-| `成长与任务.xlsx` | 技能、等级经验、能力节点、工具升级、NPC、关系、任务、目标、奖励 |
-| `事件与文本.xlsx` | 节日事件、事件阶段、事件条件、文本、UI 提示、教程 |
-
-建表顺序：①物品表（公共 item_id）→ ②作物表 → ③区域与连接表 → ④NPC 表 → ⑤配方表 → ⑥价格与商店库存表 → ⑦任务/目标/奖励表 → ⑧敌人/掉落/技能/事件表。
-每完成一组查三件事：引用 ID 存在 / 条件有负责系统 / 同一数值只有一个系统维护。
-
-## 表格-程序契约
-
-1. 加载顺序按引用拓扑：主数据 → 关系 → 条件 → 文本（最后）。
-2. 启动期全量校验（外键/枚举/单位）；运行期全部 id→对象字典 O(1) 查找。（实证参照：原作按需缓存加载+`ContentHashes.json` 逐文件 MD5 校验拒损坏。）
-3. 条件求值统一 `check(condition_id)`，全部系统复用。
-4. enabled_state 生命周期：active 加载；draft 调试可见；disabled 不加载；deprecated 不加载但留 ID 占位。
-5. 单位类型化（time_slice/game_day/currency/stamina/exp 进类型系统，同列禁混单位）。实证锚点：`700ms=10 游戏分钟`为运行时常量，配表侧时间单位统一 time_slice，禁现实秒混入。
-6. 多值一律关系子表；运行期无"解析逗号拼接"代码路径。
-7. 改表 → 验收过检（blocker=CI 红灯）→ 进包；`data_version` 为迁移依据（实证参照：原作存档迁移器按版本处理旧字段）。
-8. 随机契约：影响掉落/品质的 roll 绑定「世界日+存档 ID+位置/主体」种子（防读档刷结果；原作行为级种子实证：收获 `CreateRandom(x×7, y×11, DaysPlayed, uniqueID)`）。
-
-## 数值填充与验算
-
-- 当前采用的数值与验证关注点：
-
-| 表 | 字段 | 当前值 | 依据 | 验证关注点（按需） |
-|---|---|---|---|---|
-| 等级经验表 | skill_cumulative_xp | 100/380/770/1300/2150/3300/4800/6900/10000/15000 | 代码常量（Farmer.cs 实证） | 原型期曲线过陡/过缓 |
-| 作物表 | 防风草 price/days/xp | 35 金/4 日/8 xp | 原作作物表实证（crop 472：phases 1-1-1-1，xp_per_harvest 8） | 前 5 日验算不闭合 |
-| 经济表 | 买卖价差 | 商店价=2×基价×品质系数；出售所得=其半 | 原作一对出售方法实证 | 新手期现金流断裂 |
-| 战斗表 | 受击无敌帧 | 450ms（按武器类型 2/3 除） | 原作 takeDamage 实证 | 手感测试受击连按 |
-
-- v0.1 多日验算草案（农务、基础采集、交易与成长）：
-
-| 时段 | 关键行动 | 可据现有数值推算的部分 | 待补齐的验算输入 |
+| 维护系统 | 示例记录或参数 | 已知值与引用 | 仍缺的当前范围配置 |
 |---|---|---|---|
-| 第 1 日 | 买种、播种、浇水与基础采集 | 起始 500 金，15 包种子各 20 金，购种后余 200 金 | 农务和采集成本、采集获得物与经验 |
-| 第 2～4 日 | 维护作物，选择外出采集并出售部分成果 | 连续满足成长条件，等待四次跨日成长完成 | 每日时间体力收支、资源点刷新、采集收益 |
-| 第 5 日 | 收获、出售、投资与基础成长 | 若 15 株均正常成熟且为普通品质，售得 525 金、收获经验 120 xp；种子投入的毛利为 225 金，不含其他收支 | 实际品质、其他活动收支、成长反馈与投资选择 |
+| S07 | `parsnip_seed`、`parsnip` | 分别是防风草种子和产物的示例物品 ID | 完整物品字段、背包容量、堆叠和展示文案 |
+| S03 | `crop_parsnip` | `seed_item_id=parsnip_seed`；`harvest_item_id=parsnip`；`growth_days=4 游戏日` | 地块初态、种植季节、浇水/天气成长细则、阶段视觉映射、品质与收获数量规则 |
+| S09 | 防风草种子买价、产物卖价 | 种子 `20 金/包`；普通品质产物 `35 金/个`；开局 `500 金` | 商店 ID、营业时段、库存及补货、售价适用条件、出货箱结算细则 |
+| S08 | 农务收获经验与首级阈值 | 成功收获 `crop_parsnip` 获 `8 经验/株`；累计 `100 经验` 达 1 级，均为示例假设 | 采集经验与其他当前可达等级、升级反馈 |
+| S04 | 农场、小镇地图尺寸 | 相邻技术样例使用 `16px` 网格、农场 `80×65` 格、小镇 `50×40` 格，均仅作本例地图规模假设 | 地图层数据、连接点、可采集点位、可用状态与刷新配置 |
+| S01 | 日期与成长 | 一次满足成长条件的跨日记为 `1 游戏日`；S03 负责累计 | 游戏日长度、天气概率、跨日通知与结算输入 |
 
-- 待校验的收益关系：`item_seed_parsnip(20金) → crop_parsnip(4 日) → item_parsnip(35 金) → 出货箱日终结算 → 种子复购`。仍需结合实际配置核对引用、成长条件、采集收益及跨日结算，不能以局部算术推算宣称完整验算通过。
-- 当前结论：上述草案未完成 v0.1 的时间、体力和资源收支验算，也未证明玩法节奏成立。补齐输入后验算，并结合原型观察与玩家反馈判断。
+以上是**局部示例配置**，不是可加载的完整数据集。尤其不能凭两个物品 ID、一株作物和地图尺寸推断物品、地块、地图、商店或采集已配齐。所有可见名称、交互提示、商店文案、收获及结算文案也需在本套 TDD 中逐条确定；本例尚未提供这些正式文案。
 
-## 验收
+## 用已知数值做局部验算
 
-- 验收记录：check_id / workbook / sheet / data_version / check_type（primary_key·reference·enum·unit·range·business_rule·duplicate_ownership）/ severity（blocker·warning·note）/ result / issue / owner / resolution。
-- 五查必过：主键唯一不空；外键存在且目标非弃用；枚举有清单（品质枚举 0/1/2/4 单独登记）；单位可判且同列不混；无违规负数、`duration=0` 仅即时。
-- 两查复核：业务规则（季节窗口相容、目标有验证系统、奖励一次、配方输入可达）；重复归属（价格由 S09 维护，品质枚举由 S07 维护，农作物品质由 S03 的收获规则判定，采集品质由 S05 判定，不另行定义品质枚举）。
-- 三级处置：blocker 禁止扩内容；warning 记负责人与计划；note 不阻断。
-- 工具化实证口径（参照知识库做法）：提取脚本逐表断言（行数/字段/枚举）；对账器做表间交叉对账（代表资产级 50 键全对账）；反例套件 5/5 拒绝。
-- 最近验收结论：check@C-2026-09-11-v1——已有数据的五查与两查复核通过；基础采集配置、当前范围验算、背包容量与公共索引定义仍需补齐，不能据此认定当前范围的数据规格完整。结构、规则或字段语义一变，受影响链路全部重验。
+场景假设：开局持有 `500 金`，商店可一次卖出 `15 包`示例种子，玩家有 `15 块`可用地且逐块播种；其后每块都满足四次跨日成长条件，均产出一个普通品质防风草，全部成功入账并按示例价格出售。这些条件是验算输入，不是已经确定的系统配置。
+
+| 行动与状态 | 计算 | 可确认的结果 |
+|---|---|---|
+| 买 15 包种子 | `15 × 20 = 300 金`；`500 − 300 = 200 金` | 购种后余 `200 金`，前提是库存、营业与背包允许交易 |
+| 播种并成长 | 消费 `15 包`；每株满足 `4` 次跨日成长 | 可推得最早在满足第四次成长条件后收获；浇水、天气和日终精确规则仍未配置 |
+| 收获 15 株 | `15 × 1 = 15 个`；`15 × 8 = 120 经验` | 假设均为普通品质、每株一产物且物品入账成功，农务经验达到示例首级阈值 `100` |
+| 全部出售 | `15 × 35 = 525 金`；`200 + 525 = 725 金` | 假设交易或日终出货成功，最终金钱 `725`；相对购种投入毛利 `525 − 300 = 225 金` |
+
+这只验证了给定假设下的数量和金钱/经验算术。没有行动体力、实际耗时、采集产出与成本、商店库存、背包容量、天气概率及跨日结算顺序，无法证明玩家能走完整个流程，也无法判断收益、节奏和平衡。补齐这些数据后，需以真实配置重算农务与采集的同日取舍、跨日成长和出售投资闭环。
+
+## 数据检查与结论
+
+| 检查对象 | 已做的文档检查 | 结论与缺口 |
+|---|---|---|
+| 已列示例 ID | `crop_parsnip` 的两个物品引用均出现在本例中；价格只在 S09 定义 | 局部引用及归属一致；商店、地图、采集点等真实引用尚未定义 |
+| 数值与单位 | `15×20=300`、`500−300=200`、`15×35=525`、`200+525=725`、`15×8=120`，单位对应金/经验 | 上述假设下算术成立；行动、产量、品质、库存等约束未验 |
+| 当前范围完整性 | 对照 S01/S02/S03/S04/S05/S07/S08/S09 的当前原型职责 | 采集配置、地图点位、行动成本、容量、商店与全部可见文案缺失 |
+| 关键循环 | 已计算买种到卖出的局部链条 | 农务与采集并行选择、跨日结算及存读档后的结果未能验算 |
+
+本册**未完成**，不构成策划文档验收通过的记录。没有运行游戏、构建或试玩；表中结果仅是可复核的局部文档检查。
 
 ## 待解决问题
 
-- 基础采集：补齐资源点位置与刷新、采集判定、获得物、品质和经验配置，与技术分册 S04/S05/S07/S08 的职责和接口一致。
-- 当前范围验算：补齐日常行动成本和收益，明确跨日结算顺序，完成 v0.1 农务、基础采集、交易与成长的多日收支验算。
-- 背包容量：与技术分册确认格子或重量规则后，补齐容器字段、容量约束及存档数据定义。
-- 公共索引：补齐 condition/text/station/behavior 的索引定义与引用说明，再检查加载和引用完整性。
-
-完成后将采用的规则写入本文对应数据规格并更新验收结论，移出待办。
+| 问题 | 对当前施工或验算的影响 | 下一步 |
+|---|---|---|
+| 基础采集与地图点位 | 无法实现资源点发现、判定、刷新和产物入账 | 补 S04 点位/状态及 S05 获得物、品质、经验规则，连同物品引用验算 |
+| 行动成本与日期天气 | 无法验证农务和采集能否在同一天完成，也不能确定四次跨日的实际路径 | 补 S01/S02/S03 的时间、体力、浇水和跨日数据后重算 |
+| 背包、商店与出货 | 数量和金额虽可计算，仍无法验证交易与结算是否可执行 | 补 S07 容量及 S09 营业、库存、售价、结算配置和失败处理 |
+| 当前范围其余数据与文案 | 几条示例记录不足以施工，玩家反馈也无权威文本 | 按确定的内容范围填满物品、作物、地图、采集、商店、成长及文案，再检查完整性 |

apps/ai-game-creator-shell/src-tauri/design-agent/resources/exemplars/stardew-tdd-master.md

@@ -1,59 +1,48 @@
-# TDD 总册：《星露谷物语》
+# TDD 总册：《星露谷物语》日常原型示例
 
-> 状态：待补齐（v0.1 仍有关键规格缺口）　|　基于 GDD：架构层@v3 + 各系统规则与数据
+## 当前范围
 
-## 自足性检查（未完备示例）
+首个日常原型包括农场、小镇与基础采集区域，覆盖 S01 时间、S02 体力、S03 耕种、S04 地图、S05 基础采集、S07 物品、S08 基础成长和 S09 商店，以及 UI 和存读档。单日观察计划与取舍，多日覆盖作物成长、出售和再投资。
 
-| # | 施工方的问题 | 答案在哪 | 状态 |
-|---|---|---|---|
-| 1 | 首个日常原型所需的八个系统如何协作？ | 01 收编章及待解决问题 | **缺口**：基础采集、跨日结算顺序、背包容量与体力规则仍需补齐 |
-| 2 | 表里有多少行内容、文本全填了吗？ | 03 数值填充、验收及待解决问题 | **缺口**：基础采集配置、当前范围验算、容量与公共索引定义仍需补齐 |
-| 3 | 每个界面长什么样、怎么走？ | 01 UI 交互规格 | **缺口**：背包方案确定后需更新对应交互 |
-| 4 | 每份素材什么规格、谁验收过？ | 02 素材规格、资产状态表及待解决问题 | **缺口**：换装范围、锚点图和字体仍有待确认内容 |
-| 5 | 代码怎么组织、跑在哪？ | 01 代码组织+能力边界（三态全落位） | **过** |
-| 6 | 怎么算做完？ | 01 里程碑三判据+三件验收 | **过** |
+矿井战斗、钓鱼、畜牧、制作、NPC 关系与日程、社区目标和节日留待后续，不以完整版本的内容量作为本次施工范围。
 
-**结论：当前范围的 TDD 尚未完备。** 只有相关规则、数据与素材规格补齐到 TDD 正文后，才能认定施工方可只凭 TDD 完成该范围的实现；登记待办或已有检查通过均不能替代这一步。
-后续版本新增系统时仍需补齐相应规则并收编。已明确规格的资产可按计划制作，其生产进度与上述规格缺口分别记录。
+**本套是未完备的写法示例，尚不能仅凭 TDD 实现整个原型。** 玩法数值与素材规格为示例假设；本例选用新二维 Web，npm + Vite + Phaser 4.2.1 则按总纲约束执行。没有可核验的构建、试玩或资产验收证据。
 
-## 三件状态
+## 分册索引
 
-| 件 | 状态 | 版本 | 读者 | 一句话结论 |
-|---|---|---|---|---|
-| 01 技术实现 | 待补齐 | v0.2 | 程序 | 补齐基础采集、跨日结算、背包与体力规格；v0.1 覆盖单日选择及多日成长 |
-| 02 美术圣经 | 待补齐 | v1 | 美术 | 确认换装范围、锚点图与字体；已有资产的验收记录保留 |
-| 03 数据与配表 | 待补齐 | ck-001 | 数值+程序 | 补齐基础采集配置、当前范围验算、容量与公共索引定义后重验 |
-
-## 跨件契约速查
-
-| 缝 | 契约 | 权威在 |
+| 项目产物 | 包内样例 | 内容 |
 |---|---|---|
-| 素材绑定 | 作物绑 `crop_{id}`、工具绑 `item_`、敌人绑 `enemy_{id}`、NPC 绑 `npc_{id}`（ID 全部查 03 字段字典指向的表） | 03 字段字典 |
-| 视觉设计依据 | `stardew_warm_rural_pixel` 承接概念层的温暖治愈、乡村生活与季节变化；四季色板和完整视觉规格见美术圣经 | 02 视觉风格与视觉锚 |
-| 加载顺序 | 主数据（物品/敌人）→ 关系（掉落/配方）→ 条件（condition 表）→ 文本（text 表最后） | 03 契约七条① |
-| 帧表格式 | `farmer_{anim}_{dir}_{frame}` JSON 帧表：圣经契约列的格式=程序侧帧动画节直接解析的格式 | 01 §能力边界 |
-| 交互热区 | 触控热区 ≥44px；圣经 UI 节与 01 输入表同源（热区按钮规格一字不差） | 01 输入表 |
-| 音频规格 | BGM ogg 循环+循环点标记 -18LUFS、SFX wav 单发——圣经契约与 01 音频表触发实现一致 | 02 音频契约 |
-| 昼夜色调 | `tint_{phase}` 四档程序色值表，豁免绑定、拥有者=美术圣经资产表 | 02 资产状态表 |
-| 拥有者总则 | 数值事实归 03（价格只在经济表）；生产状态归 02（素材验收记录）；技术事实归 01（缩放档位） | 架构层@v3 |
+| `01_技术实现.md` | `exemplars/stardew-tdd-tech.md` | 行为与协作、Phaser 工程、UI、构建与验证计划 |
+| `02_美术圣经.md` | `exemplars/stardew-tdd-art-bible.md` | 首期视觉依据、类别规格、素材清单与接入标准 |
+| `03_数据与配表.md` | `exemplars/stardew-tdd-data.md` | 数据定义、示例配置、局部计算与待补验算 |
 
-## 重要缺口汇总
+## 来源与版本
 
-| 相关分册 | 影响当前施工的缺口 | 详细位置 |
+采用同包内 `stardew-concept.md`、`stardew-top-design.md`、`stardew-architecture.md` 的 2026-09-27 修订内容，以其“首个日常原型”范围为本例设计基线。技术、数据、美术三分册按这一范围共同维护，具体示例参数由对应分册明确，不把原作解包快照或未附带的外部资料当作施工依据。
+
+系统文档编号沿用架构。当前未随包提供全部系统的完整正文，也未形成可施工快照；补齐时记录实际采用的来源及版本，同步受影响分册，不能将旧的通用版本占位当作已完成收编。
+
+## 跨分册约定
+
+| 约定 | 当前结论 | 维护位置 |
 |---|---|---|
-| 01、03 | 基础采集及区域数据、跨日结算顺序不完整 | 01“S05”“S01”及“待解决问题”；补齐后同步数据分册 |
-| 01、03 | 背包容量与体力规则影响行为、存档及界面 | 01“待解决问题”；确定后同步两份分册正文 |
-| 02 | 换装范围、锚点图与字体影响素材和渲染规格 | 02“待解决问题” |
-| 03 | 当前范围验算与公共索引定义未完成 | 03“数值填充与验算”及“待解决问题” |
+| 工程与产物 | 新二维 Web 使用 npm + Vite + Phaser 4.2.1；`game/dist/index.html` 为预览与导出入口 | 01 当前范围与工程约束 |
+| 状态与数据 | 各系统维护所拥有的状态；UI 展示，存档保存和恢复；配置标识与引用定义集中维护 | 01 行为与接口、03 数据定义 |
+| 视觉与绑定 | 暂定 16px 网格、16×32 角色、16×16 物品图标；素材按其消费对象绑定，不全部强绑 item_id | 02 类别规格与素材清单 |
+| 配置与资源加载 | 数据与素材随构建进入 dist，具体路径与消费接口需共同补齐 | 01 代码、接口与数据；02、03 对应定义 |
+| 输入与 UI | 桌面键鼠、移动触控；本例按钮热区暂定至少 44 CSS px，容量未定前不能宣称背包布局完整 | 01 界面与操作、02 UI 规格 |
 
-详细分析与下一步在对应分册维护；问题解决后更新分册正文，再移出本汇总，无需向全局台账重复登记。
+## 文档检查与重要缺口
 
-## 验收总状态
+当前分册对首期范围与工程方向的描述已对齐，但行为、数据、素材与接口仍存在施工缺口。局部算术推算不能代替完整数值验算，也不代表策划案已通过验收。
 
-| 件 | 最近验收 | blocker | 结论 |
-|---|---|---|---|
-| 01 | 已有构建和静态检查通过；当前范围验证待补齐规格后进行 | 基础采集、跨日结算、背包与体力等规格缺口 | 补齐正文后复核当前范围的完整性 |
-| 02 | ck-a01~a03 保留已有资产的接入与验收记录 | 换装、锚点图与字体规格未定 | 相关规格确认后再制作和验收受影响素材 |
-| 03 | ck-001 已有数据检查通过 | 基础采集配置、当前范围验算、容量与公共索引定义缺口 | 补齐后重验受影响的数据与接口 |
+| 相关分册 | 重要缺口 | 详细位置 |
+|---|---|---|
+| 01、03 | 时间、体力、天气、跨日结算与存档恢复未完整定义 | 01 待解决问题、03 用已知数值做局部验算及待解决问题 |
+| 01、02、03 | 基础采集、地图配置及其素材绑定不完整 | 各分册的采集、地图与待解决问题 |
+| 01、03 | 背包容量、交易边界、成长曲线及当前范围全量数据不足 | 01 S07/S08/S09、03 配置与缺口 |
+| 01、02 | 素材清单、帧与地块映射、字体和双视口布局尚待补齐 | 02 待解决问题、01 场景与交互 |
 
-以上缺口解决且施工所需信息完整后，才能将当前范围标为“只凭 TDD 可实施”。
+策划案验收要求补齐这些正文、检查跨分册一致性和必要验算，使施工方仅凭本套 TDD 能完成当前范围。素材可以在文档完成后按规格制作，游戏构建、接入和试玩按分册计划执行；没有执行的检查不写成已通过。
+
+详细问题只在对应分册维护，解决后更新正文并移出本汇总。

apps/ai-game-creator-shell/src-tauri/design-agent/resources/exemplars/stardew-tdd-tech.md

@@ -1,187 +1,109 @@
-# 技术实现：《星露谷物语》（TDD 金样 · 技术实现）
+# 技术实现：《星露谷物语》日常原型示例
 
-> 状态：待补齐　|　基于 GDD：架构层@v3 + 当前范围系统文档@v1（收编）　|　数据侧契约：data/contracts@v2
-> 本例 v0.1 对应架构层的首个日常原型，仍缺基础采集的完整规格，背包容量和体力规则也未确定；尚不能作为完整施工依据。后续能力另行标明，纳入实现范围前须补齐。
-> **目标运行时：HTML**（由 GDD 平台事实锁定；本项目按浏览器平台事实执行）
-> 平台事实：双视口（桌面/移动）· 键鼠/触屏双输入 · 本地 HTTP 预览
-> 实证数字来源：星露谷 1.6.15 反编译知识库 v3（快照 stardew-1.6.15-7f1e5b8e，2026-09-11）；写新项目时替换为本项目数值。
+本例展示从设计到实现规格的写法，范围与来源见总册。文中的玩法数值是示例假设，不是对原作数据或已完成实现的核验；本例选用新二维 Web，具体工程约束遵循总纲。基础采集、跨日结算、容量等规格尚未齐全，当前不能仅凭本例完成整个原型。
 
-## 系统行为规格（收编章——施工只读这里，不回 GDD）
+## 当前范围与工程约束
 
-### S01 时间与日程（基于系统文档@v1 收编）
-- 玩家行动：查看时间天气（HUD 常驻）；使用床提前结束一天；等待营业时段。
-- 状态与规则：时间以时间片计、现实驱动、暂停时停表；时间片耗尽或就寝→协调日终结算→日期与天气更新→各系统准备次日状态→存档与汇总反馈。作物成长由 S03、设施或制作由对应生产系统、出货由 S09、成长由 S08 处理；28 日/季、四季/年；天气每日按季节权重抽取（晴/雨/风暴），雨天免浇水。居民内容加入后，S10 接收时间通知并推进自身日程；精确结算顺序仍需补齐。
-- 反馈需求：HUD 时钟日期常驻；天气图标；日终面板逐项列当日变化。
-- 实证参照（原作 1.6.15）：`700ms = 10 游戏分钟`（累加器超 `7000 + 地点Extra×10`ms 触发十分钟拍，`timeOfDay += 10`，上限 2600）；日结算顺序不可乱——出货先于邮件/任务（订单计数依赖）、地点 dayUpdate 先于玩家 dayupdate（作物推进后才有当日收获判定）。
+首个原型包含农场、小镇、基础采集区域，以及时间、体力、耕种、采集、物品、基础成长、商店、UI 和存读档。矿井战斗、钓鱼、畜牧、制作、NPC 关系与日程、社区目标和节日属于后续范围。
 
-### S02 体力与状态（基于系统文档@v1 收编）
-- 玩家行动：进食恢复体力；食物附带状态效果；观察体力条决定收手。
-- 状态与规则：单池体力（战斗共享风险资源——B 级待拍，暂按共享实现）；成本分档：移动/普通农务≈0~低、耕作浇水低、砍伐采矿战斗钓鱼中高；恢复：食物立即+效果、就寝次日满、温泉持续；体力归零→昏倒：当日终止、次日上限下降、轻度金钱/物品损失（不清背包）；状态效果有限枚举，由食物/装备写入、各系统结算。
-- 反馈需求：体力条常驻+临界变色；昏倒过场说明原因与损失、给出可恢复路径。
-- 实证参照：原作基础 MaxStamina=270、MaxHealth=100；午夜后体力惩罚为线性公式（Farmer.dayupdate）；昏睡账单上限默认 1000g、姜岛 2500g（LocationContexts 数据驱动，非硬编码）。
+本例选择新建二维 Web 工程：npm + Vite + Phaser 4.2.1，使用 `import Phaser from 'phaser'`，由 Phaser Scene、GameObject 和 update 承载游戏。沿用客户端脚手架的 Vite 依赖约束，安装解析结果由 `package-lock.json` 固定；不另写一套 Canvas 渲染循环。
 
-### S03 农场经营（基于系统文档@v1 收编）
-当前实现耕种、浇水、生长与收获；下述畜牧、设施和加工内容属于后续范围。
-- 玩家行动：锄地/播种/浇水/收获/铲除；喂动物收集畜产；放置使用设施；整理布局。
-- 状态与规则：地块状态机 荒地→耕地→（播种+浇水）→生长 N 日→可收获→收获后回耕地；未浇水当日不生长；生长按日终 tick；雨天视为已浇水；作物有适宜季节、换季枯萎；动物每日喂食→周期产出、未喂不产出不死亡；洒水器每晨自动浇固定格；加工设备按配方+时间片队列产出；品质分普通/银/金（技能等级+概率）。
-- 反馈需求：生长阶段视觉可辨；成熟提示标记；设施完成音效图标；日终列农场产出。
-- 实证参照：耕地是网格状态拥有者，作物挂在耕地下（HoeDirt 拥有湿度/肥料/作物引用）；收获单一入口；**品质 roll 先于数量 roll 且共用同一随机流**（顺序影响结果）；保水判定在作物推进之后（当天浇的水当天有效）。
+工程位于 `game/`，`npm run build` 在该目录执行，产物入口为 `game/dist/index.html`。预览和导出均使用 dist，运行资源随构建进入其中。目标为桌面键鼠与移动触控、本地 HTTP 预览。
 
-### S04 探索与地图（基于系统文档@v1 收编）
-当前实现农场、小镇与基础采集区域；矿井、钓鱼入口和任务解锁属于后续范围。
-- 玩家行动：移动（8 向网格）；穿出入口切换区域；查看地图；交互资源点入口（采集/钓鱼/战斗分别交 S05/S06）。
-- 状态与规则：区域=独立场景、连接点切换淡入淡出≤1s；初始开放农场+小镇+海滩，林间/矿井由社区任务解锁（条件表）；资源点固定刷新点按规则周期重生；隐藏信息保留为探索发现；矿井按层进入、固定池随机拼装+亮度递减。
-- 反馈需求：地图标注已解锁区域与当前位置；解锁新区域明确提示与入口指引；资源点可交互高亮。
-- 实证参照：原作矿井同日同层布局确定（每日世界种子 `DaysPlayed + 存档ID/2`）；矿井布局池 61 张模板按层拼装；骷髅洞时间减速 28.6%（+200ms/分）仅单机生效。
+## 系统行为与协作
 
-### S05 采集与钓鱼（当前范围为基础采集，规格待补齐）
+### S01 时间与日终
 
-基础采集属于 v0.1，钓鱼属于后续范围。当前尚缺采集触发、获得物判定、资源点状态更新、物品入账失败处理及经验反馈的完整规格；须补齐本节及数据分册中的配置后，才能满足当前范围只看 TDD 即可实现的要求。
+世界运行时推进游戏时钟；背包、商店、日终面板及页面失焦时暂停，不在返回前台时补算离线时间。HUD 展示日期、时间与天气；使用床或到达日终时限后停止接收当日行动，进入日终流程。
 
-### S07 物品、背包与制作（基于系统文档@v1 收编）
-当前实现基础物品、背包与工具使用；装备、制作队列和图鉴等能力后续展开。
-- 玩家行动：整理背包；使用/装备/丢弃；设施处提交配方；查看图鉴。
-- 状态与规则：一切以 item_id 为准，类别枚举（工具/种子/素材/食物/装备/家具/礼物）；同类同品质堆叠（容量结构待 B 级决策，暂按格子制实现、预留字段）；工具等级制（基础→铜→铁…，升级交材料+金+天数）；装备槽武器/防具各一；配方=材料子表→输出→设施→condition_id 解锁；制作队列按时间片推进、日终照常完成。
-- 反馈需求：拾取飘字音效同帧；背包变更即时刷新；制作完成提示；图鉴进度。
-- 实证参照：原作 807 物品统一限定 ID 引用（如 `(O)123`）；品质枚举值为 0/1/2/4（银=1、金=2、铱=4），所有 `(1 + 0.25×quality)` 型公式的乘数因此是 1.25/1.5/2.0；出售语义一对方法承载：`salePrice()`（=2×基价×品质系数，商店价）与 `sellToStorePrice()`（=salePrice/2，玩家所得）。
+S01 协调 S03 作物成长、S09 出货、S08 成长和各系统次日准备，反馈结算结果并保存完成后的状态。具体时间换算、日终时限、天气配置、结算顺序与中断恢复仍待补齐；读档不得再次发放已结算收益。
 
-### S08 成长与技能（基于系统文档@v1 收编）
-当前实现基础农务或采集成长；其他活动技能、分支与工具升级委托属于后续范围。
-- 玩家行动：查看技能面板；升级时选加成方向；提交工具升级委托。
-- 状态与规则：技能五项（农务/采集/采矿/钓鱼/战斗）独立经验池；执行对应活动得经验、只增不减；等级效果三类——效率（省时省体力）/解锁（配方/区域/工具位）/选择（每若干级一次分支，宽松可回转）；工具升级期间该工具不可用（备用旧工具=开放问题暂不备）；升级奖励优先省时省力扩选择，不加数值伤害。
-- 反馈需求：经验条与升级音效；升级面板三选一；工具完成由铁匠通知。
-- 实证参照：原作技能累计经验曲线为代码常量 `100/380/770/1300/2150/3300/4800/6900/10000/15000`（10 级）；经验取整用银行家舍入（边界值注意）；满级后经验转全局精通点（第二成长曲线）。
+### S02 体力与状态
 
-### S09 经济与商店（基于系统文档@v1 收编）
-- 玩家行动：出售（出货箱日终/商店现卖）；购买；查看价格库存；装箱订单属于后续范围。
-- 状态与规则：货币唯一；基准价+买卖价差，价格只由本系统维护（其他系统只提交产物或消费请求）；商店各有营业时段（条件表）、库存按周期补货、部分商品有购买条件；出货箱投入→日终统一结算计入当日收入；后续订单的基础形式为每周装箱单换奖金。
-- 反馈需求：交易金额飘字音效；日终面板单列收入明细；商店营业状态门口可见。
-- 实证参照：原作 77 店 897 条库存，店级 PriceModifiers 数据驱动；基础材料（木/石/煤/铜/铁/金）售价走年度特例（第 2 年起涨价）而非通用公式。
+农务和采集提交行动成本，S02 判断是否足够并维护体力，UI 读取结果。休息恢复体力；体力不足时的行为、各行动成本、恢复值及日终处理尚未确定，当前不能用“低消耗”等描述替代数值。体力与战斗生命的关系在战斗原型前确定，不扩大本期规格。
 
-### S06 战斗与敌人（后续范围，基于系统文档@v2 收编要点）
-矿井原型暂按实时操作验证移动避让、普通攻击、补给与撤退，不预设重攻、独立闪避或格挡技能。普通敌人发现玩家后接近，攻击前给出可识别的准备动作；有效命中才结算伤害，同一次击败只发放一次战利品与经验。S06 管敌人行为和判定，S04 管位置，S02 管玩家生存状态，S07 管物品，S08 管经验。安全撤退保留已入账成果；倒下执行部分钱物损失，由 S02 协调 S09、S07、S04 更新结果。
-生命与体力关系、敌人行为与刷新、伤害和动作参数、奖励入账受阻处理、失败损失及日终中断顺序尚未明确。纳入实现范围前须补齐这些设计，并将系统文档@v2 的完整规则及实现规格收编进本册；当前要点不构成战斗施工规格。
-实证参照：怪物 51 条配置拆 15 字段（HP/伤害/掉落对/防御/闪避/速度/经验…）；受击 `max(1, 伤害−防御)`、450ms 基准无敌帧；伤害链顺序固定：roll→暴击→+攻击→职业→附魔→怪物防御（改序即改平衡）；暴击乘区在 +Attack×3 之前（攻击力不吃暴击）。
+### S03 耕种与收获
 
-## UI 交互规格
+当前流程为锄地、播种、浇水、跨日成长、成熟收获；雨天按已浇水处理，未满足水分条件的当天不增长。S03 维护地块、作物和成长状态，S07 管种子与收获物，S02 管行动成本。播种失败不扣种子或体力；收获入账失败不消耗作物或发放经验。
 
-| 界面 | 元素与布局 | 流转 | 触控版式 |
-|---|---|---|---|
-| HUD | 体力条（左上）+时钟日期天气（右上）+金钱 | 常驻；点开时钟看季节日历 | 等比缩放，热区≥44px 的仅按钮 |
-| 背包/工具栏 | 底部工具槽×8+Tab 全屏网格背包 | Tab/I 开→再关；槽位与物品表工具位同步 | 底栏加宽，点选代替快捷键 |
-| 商店 | 商品列表（价格/库存/条件）+背包对照双栏 | 营业时段与店主对话进入→交易→Esc/返回退出 | 双栏改上下布局（移动） |
-| 对话 | 底部文本框+头像位+选项列表 | 靠近 NPC 按 E→逐句→选项分支→结束 | 全屏按钮式选项（热区 44px） |
-| 日终结算 | 全屏面板：收入明细/关系与技能变化/明日提示 | 就寝或时间耗尽自动→任意键进入次日 | 同桌面，纵向排布 |
+数据分册采用示例作物的 4 次跨日成长、普通品质售价 35 金和每株收获 8 xp，具体配置以数据分册为准。阶段与贴图映射、成熟后的地块处理、收获入账的完整边界仍需补齐；本期不加入畜牧、加工或品质随机机制。
 
-（实证参照：原作对话文本中 `$表情` 标记驱动立绘切换，六表情索引 0-5；钓鱼小游戏是唯一不暂停时间的菜单。）
+### S04 地图与 S05 基础采集
 
-## 来自 GDD 的功能（首个日常原型）
+S04 管位置、碰撞、区域连接和资源点可用状态。S05 在玩家交互时判断资源点与行动条件，计算获得物，交 S07 入账、S08 发经验，成功后由 S04 更新资源点；失败不产生部分消耗或奖励。
 
-| 系统 | 一句话职责 | 拥有的主数据 |
+区域为农场、小镇和基础采集区域，暂按独立场景、连接点切换。采集物、资源点坐标与刷新、获得物数量、成本、入账失败反馈等仍不完整；不能用矿井或钓鱼规则代替基础采集规格。
+
+### S07 物品与容器
+
+物品通过稳定的 `item_id` 引用，S07 负责持有、使用和容器变更；价格归 S09。背包暂按格子制讨论，但容量、堆叠、工具占位、满包处理和对应存档字段仍未定，须明确后才能实现相关界面和交易。
+
+### S08 成长
+
+农务或采集成果由活动系统报告，S08 维护经验与等级，其他系统读取成长结果，不重复发放。示例收获 15 株各 8 xp，合计 120 xp，达到数据分册的首级阈值 100 xp；其他当前可达等级、成长收益、采集经验与日终反馈仍需补齐。首期不预填五项技能、三选一分支或工具升级委托。
+
+### S09 商店与出售
+
+S09 校验营业、价格、库存和金钱，S07 校验物品及容量；买卖全部条件满足才同时更新，失败保持原状态并反馈原因。出货箱在日终结算，须明确投入、取回和重复结算的处理。
+
+数据分册的局部示例为初始 500 金，15 包种子各 20 金，购种后余 200 金；15 株按 35 金出售收入 525 金，扣种子投入毛利 225 金。它没有计入采集、体力、营业与容量限制，不能当作原型经济验算已通过。
+
+## 代码、接口与数据
+
+本例拟采用以下结构；模块按实现职责拆分，系统编号用于对照设计，不决定目录：
+
+- `game/game.js`：创建 Phaser Game、注册场景。
+- `game/src/scenes/`：加载、世界与界面场景，负责对象展示和输入转发。
+- `game/src/systems/`：时间、体力、农务、地图、采集、容器、成长与经济的行为及状态。
+- `game/src/save.js`：收集和恢复各系统的持久状态。
+- `game/public/data/`、`game/public/assets/`：随 Vite 构建进入 dist 的配置和运行素材。
+
+UI 只维护交互与临时状态，不直接改写金钱、背包或作物。跨系统行动先验证全部前置条件，再提交对应状态变化；具体函数签名、失败结果与日终协调方式待补齐。
+
+存档暂采用 localStorage 中的 JSON 快照，保存日期、角色位置、地块、资源点、容器、金钱、成长及已完成的日终结果。序列化、字段版本、写入失败提示和读档恢复顺序需要完整定义，不能假设浏览器存储就是文件系统的临时文件替换。
+
+## 界面与操作
+
+| 界面 | 元素、流转与反馈 | 适配 |
 |---|---|---|
-| S01 时间与日程 | 全局时钟与日终协调 | 日期、季节、天气；居民日程归 S10 |
-| S02 体力与状态 | 全局行动成本与恢复 | 体力、状态效果 |
-| S03 农场经营 | 核心产出与规划场 | 地块、作物、设施 |
-| S04 探索与地图 | 场景与空间约束 | 区域、连接、资源点 |
-| S05 采集与钓鱼 | 本期基础采集，钓鱼后续加入 | 采集判定与获得物规则；资源点状态归 S04，物品入账归 S07 |
-| S07 物品与制作 | 资源身份与转化 | 物品、配方、背包 |
-| S08 成长与技能 | 长期回报层 | 经验、等级、解锁 |
-| S09 经济与商店 | 投资与回报换算 | 价格、交易、库存 |
+| HUD | 体力、日期、时间、天气和金钱常驻；随权威状态刷新 | 桌面与移动均不遮挡主要操作区域 |
+| 工具栏与背包 | 数字键或点选切工具；Tab/I 或背包按钮打开，再按或返回关闭；打开时暂停 | 槽位数与布局待容量方案确定 |
+| 商店 | 交互营业入口打开，显示价格、库存与购买结果；Esc/返回关闭 | 桌面可双栏，移动纵向布局；触控热区暂定至少 44 CSS px |
+| 日终 | 展示出货收入与成长变化，确认后进入次日 | 暂停世界操作，不允许重复确认触发重复结算 |
 
-## 技术目标与平台事实
+移动采用 WASD/方向键或虚拟摇杆，交互采用 E/空格或触控按钮。移动速度、交互距离、对象冲突时的选择、摇杆尺寸及死区尚待定义；本期不增加 NPC 对话界面。
 
-- 首屏可玩 ≤ 5 秒（本地 HTTP，无网络依赖）。
-- 移动视口稳定 60fps（作物满屏实例 ≤ 200 时）。
-- 场景切换 ≤ 1 秒，无白屏。
+## 场景、镜头与素材
 
-## 技术风险
+示例使用 16px 网格，角色基准帧 16×32；素材规格、命名、帧序和绑定由美术分册维护。农场暂定 80×65 格，小镇 50×40 格；基础采集区域尺寸、地图层、碰撞与出入口坐标待补齐。
 
-| 风险 | 影响 | 缓解 | 校验方式 |
-|---|---|---|---|
-| 非整数缩放导致像素模糊 | 全部视觉资产 | 整数倍缩放+letterbox | 双视口各跑 5 种常见分辨率截图比对 |
-| 触屏点击判定过小 | 移动端交互不可用 | 交互热区 ≥ 44px；摇杆替代方向键 | 移动视口手测清单§3 |
-| 存档结构变更丢档 | 用户进度 | schema_version 字段+迁移函数；写档先落临时名、成功后替换（旧档三级回退：正常→_old→_TMP） | 每版跑旧档加载测试 |
-| 满屏作物逐帧重绘掉帧 | 移动端性能 | 脏矩形渲染；非动画作物静态层 | 性能面板：作物 200 实例压测 |
-| 读档刷随机结果（SL 刷品质/掉落） | 经济与平衡崩坏 | 分层种子确定性随机：影响掉落/品质的 roll 一律绑定「世界日+存档 ID+位置/主体」 | 同日同格收获结果可复现测试 |
+镜头跟随玩家并限制在地图边界，场景切换目标为 1 秒内且无白屏。像素画面采用整数倍显示，小屏时调整可见世界范围；画布由 CSS 单独居中，Phaser 设置 `NO_CENTER`，不重复定位。实际画布逻辑尺寸、HUD 安全区域和缩放档位须结合双视口布局补齐。
 
-## 运行时能力边界（P0 七件，本例 HTML；引擎运行时对照见括号速记）
+音频包含本期环境 BGM 以及农务、采集、交易和日终反馈，格式、素材标识见美术分册；各音效与成功或失败事件的精确映射仍需补齐。浏览器音频在首次用户操作后启用，本期不预填四季或矿井音乐。
 
-| 能力 | 落位 | 状态 | 说明 |
-|---|---|---|---|
-| 瓦片地图渲染 | Canvas 2D 分层渲染 + JSON 地图数据 | 自封装 | 四层：Back/Buildings/Front/AlwaysFront，深度 -1/0.1/64+/-1（原作 xTile 同构；Unity=Tilemap 原生／Godot=TileMap 节点原生／Cocos=TiledMap 组件） |
-| 寻路 | A* 网格 | 自封装 | 仅 NPC 日程移动用（Unity=NavMesh／Godot=NavigationServer 原生） |
-| 2D 帧动画 | spritesheet atlas+帧表驱动（Canvas 逐帧绘制） | 自封装 | 帧表含毫秒级帧时长（原作 walk=4 帧循环、每帧 200ms） |
-| 分辨率适配 | CSS 整数倍缩放 + Canvas letterbox | 自封装 | 基准 16px 网格，NPC 16×32 放大 4 倍渲染（引擎侧用各自 Canvas/Viewport 适配方案） |
-| 音频 | WebAudio 双通道（BGM/SFX） | 原生 | 循环无缝预解码；多场景换曲走六槽上下文仲裁后淡出（防场景竞争）（Unity=Mixer／Godot=AudioServer 总线／Cocos=AudioSource） |
-| 移动与碰撞 | 自研网格移动+碰撞检测 | 自封装 | 8 方向；碰撞体小于格子 2px 防卡边（Unity/Godot 物理系统原生） |
-| 存档 | localStorage + JSON 文件导出 | 原生 | 版本迁移+临时名保护（引擎侧=文件系统/PlayerPrefs） |
+## 风险与待验证目标
 
-## 代码组织概览
+- 触屏同时操作摇杆、工具与交互可能遮挡场景，需要在 390×844 视口检查可达性和误触。
+- 跨日与读档可能重复结算，需要先明确结算顺序和持久状态，再验证中断恢复。
+- 示例性能目标为本地 HTTP 首屏可玩不超过 5 秒、200 株作物场景目标 60 fps；基准设备与测量窗口尚未确定，暂不能据此判定通过。
+- 固定像素规格是否支持小屏清晰阅读仍需布局与素材验证，不能以尚无测试结果为由删除该风险。
 
-- 本例代码采用 `src/systems/s01_time/` 等系统模块目录，仅为当前实现范围建立所需模块；`src/scenes/` 负责场景注册，`src/core/` 负责循环、渲染、输入、存档。这是 TDD 的实现选择，不由 `project/03_systems/...` 的文档目录决定。
-- 入口 `main.ts` → 场景管理器（注册表制，场景切换走统一接口）。
-- 边界约定：系统间只经公开 api 与事件总线通信，禁跨目录直改他人 state。
-- 实证参照（原作，仅作组织参考）：玩法逻辑全在一个 6.27MB 程序集，入口链 原生启动器→主 dll→GameRunner 帧循环（Update/Draw 非固定步长，真实毫秒累加器驱动逻辑）；静态表/本地化文本/地图/运行状态/存档五类数据分置 Content、内存、Saves 目录，按需缓存加载。
+## 构建与验证计划
 
-## 外部依赖与可复用能力
+以下均是实现后的验证计划，本资源包没有对应的构建或试玩通过证据：
 
-| 需求 | 用什么 | 来源与版本 | 实例化参数 |
-|---|---|---|---|
-| Web 游戏开发规范 | agc-web-game-development | `skill@当前版` | 双视口/双输入/本地预览/纯 HTML 交付 |
-| 地图渲染 | Canvas 2D 自研渲染器 | 手写（JSON 地图数据） | 四层结构（对齐原作 xTile 层语义） |
-| 音频 | 原生 WebAudio | 浏览器内置 API | BGM/SFX 双通道 |
-
-## 场景与镜头
-
-| 项 | 规定 | 依据 |
-|---|---|---|
-| 瓦片地图结构 | 16px 网格；农场 80×65、小镇 50×40；基础采集区域的数据待补齐，矿井属于后续范围 | 各区域独立场景，通过连接点切换，不构建连续地图 |
-| 镜头 | 跟随玩家+边界钳制；无缩放（固定整数倍） | GDD 顶层（无镜头玩法） |
-| 场景切换 | 农场、小镇与基础采集区域通过连接点淡入淡出 ≤1s；矿井后续加入 | 分区域加载，限制单次加载范围 |
-| 关卡数据 | `data/maps/*.json`（自定义 JSON：层/网格/对象点） | 契约 v2 |
-
-## 输入与操作
-
-| 动作 | 键盘 | 触控 | 备注 |
-|---|---|---|---|
-| 移动 | WASD/方向键 | 虚拟摇杆 | 8 方向 |
-| 交互（对话/拾取/使用） | E / 空格 | 热区按钮（≥44px） | 场景对象注册热区 |
-| 工具切换 | 1~8 / 滚轮 | 底栏工具槽 | 槽位与物品表工具位同步 |
-| 背包/菜单 | Tab / I | 右上按钮 | 暂停世界时钟（对话与过场同样停表） |
-
-## 音频
-
-| 用途 | 格式/规格 | 触发点 | 依据 |
-|---|---|---|---|
-| 四季 BGM | ogg 循环，循环点标记，-18LUFS | 季节变更淡入淡出 2s | 美术圣经音频契约 |
-| 矿井环境 | ogg 循环 | 进入矿井场景 | 同上 |
-| SFX（收获/砍伐/受击/购买…） | wav 单发，同帧触发 | 事件总线 `sfx_event` | 事件↔音效映射表（资产表） |
-
-（实证参照：原作音频 XACT 三件套，cue 名 435 候选、代码实际引用 230 个；音效带距离衰减、音乐六槽仲裁后淡出换曲。本项目音频契约见美术圣经。）
-
-## 构建与验证
-
-- 构建：项目标准构建命令（产物可离线运行，本地 HTTP 起服）。（引擎项目按所选引擎的预览与导出流程完成验证与交付。）
-- 自动：无头构建通过+静态检查（资源引用存在、表引用完整——CI 跑验收七查）。
-- 半自动：双视口浏览器验证——桌面 1920×1080 与移动 390×844 各完成"新档→第 1 日流程→存读档"，截图比对缩放整數性（引擎项目＝弹窗预览内同流程）。
-- 手测清单：①移动视口摇杆+热区全操作可完成第 1 日；②场景切换三次无白屏；③后台 5 分钟返回，时钟与存档一致。
-
-## 版本里程碑
-
-| 版本 | 内容 | 判据 |
-|---|---|---|
-| v0.1 | S01/S02/S03/S04/S05/S07/S08/S09 基础，加 UI 与存读档 | 单日农务与采集均可执行；连续数日完成作物生长、收获、出售与投资，出现基础成长；存读档后状态一致且无重复结算 |
-| v0.2 | 矿井与战斗（S06）及配套地图、状态和成长能力 | 矿井进出一次、遭遇一场、掉落与经验正确入账，撤退或倒下的后果符合补齐后的规格 |
-| v0.3 | NPC 与社区目标（S10/S11）及配套交易内容 | 代表性关系事件和社区目标可完成，奖励与解锁正确触发 |
+- 在 `game/` 执行项目 `npm run build`，检查 `dist/index.html` 及必需数据、素材均进入构建，无加载错误。
+- 桌面 1920×1080 与移动 390×844 各检查新档、农务、采集、交易和存读档，操作完整可达，窗口变化后无溢出、错位或模糊缩放。
+- 单日观察时间、体力与行动选择；连续数日覆盖成长、收获、出售和再投资，结果与数据分册的完整验算一致。玩家反馈用于判断是否形成新的目标。
+- 验证满包、资金或体力不足、日终重复确认、页面切后台和存档失败，确认没有部分扣款、重复奖励或错误恢复。
 
 ## 待解决问题
 
-| 问题 | 影响 | 下一步与需更新的正文 |
-|---|---|---|
-| 基础采集与采集区域规格尚未收编完整 | v0.1 缺少必需能力，无法只凭 TDD 实现 | 补齐 S05 行为规格、S04 资源点交互、场景数据及数据分册中的获得物配置 |
-| 跨日精确结算顺序尚未确定 | 影响成长、生产、出货及存档的一致性 | 补齐 S01 协调顺序及各系统输入输出，验证存读档后不重复结算 |
-| 背包采用格子还是重量容量 | 决定物品容器、存档和 UI 结构 | 与用户确认后补齐 S07 行为规格、UI 交互规格及数据分册中的容量字段；目前的格子制是暂定方案 |
-| 后续矿井采用何种地图组织与生成方式 | 影响 v0.2 的地图结构与关卡数据，不阻塞 v0.1 | 在矿井进入实现范围前明确，再更新场景与镜头、关卡数据及版本里程碑 |
-| 体力是否与战斗共享单池 | 影响 S02、战斗成本及恢复规则 | 与用户确认后补齐相关系统行为规格和数据定义；目前共享单池是暂定方案 |
+| 缺口 | 影响与下一步 |
+|---|---|
+| 时间、天气、体力与跨日顺序 | 影响日常循环和存档；补齐当前采用值、结算与恢复规格，再做跨日验算 |
+| 采集、区域与地图配置 | 影响首期必需流程；补齐获得物、坐标、刷新、成本及失败反馈，联动数据与美术清单 |
+| 容量、堆叠、商店、成长 | 影响物品、交易、UI 和存档；明确规则及参数后同步各分册 |
+| 接口、存档结构、素材映射与适配 | 工程说明仍不足以直接实现；补齐签名、状态字段、绑定、画布与输入参数 |
 
-问题解决后将实际采用的规则写入对应正文，检查关联分册并移出待办；这些记录不能代替施工规格。
+已明确的局部规格可以用于讨论与局部实现；以上当前范围的缺口未解决前，本套 TDD 尚未通过策划案验收。

apps/ai-game-creator-shell/src-tauri/design-agent/resources/exemplars/tdd-art-bible-SKILL.md

@@ -1,95 +1,21 @@
----
-name: game-tdd-02-art-bible
-description: 写"美术圣经"（美术侧）分册时使用。与总纲（技术文档层总纲分册）配套。
-  配套模板：templates/tdd-art-bible.md。配套金样：exemplars/stardew-tdd-art-bible.md。读者：美术 / 素材生产。
----
+# 美术圣经写法（TDD 美术分册）
 
-# 美术圣经 · 美术侧写法（策划 · TDD 分册之二）
+写入 `project/04_tdd/02_美术圣经.md`。参考结构见 `templates/tdd-art-bible.md`，示例见 `exemplars/stardew-tdd-art-bible.md`，按需读取；来源版本在总册集中记录。
 
-> 本文件承载美术侧的写作流程；模板在 templates/tdd-art-bible.md（保持纯净），金样在 exemplars/stardew-tdd-art-bible.md。
+## 目标与输入
 
-## 一、这一件的判断立场
+美术圣经把概念设计的体验、基调和当前实现范围，转成能生产、接入和验收的视觉规格。施工方只看本套 TDD，应能找到当前范围每种可见对象的规格、命名、消费方式与验收判据；不需要回到 GDD 猜测。引用概念、系统和数据文档时指出依据，并在本分册写全实际执行所需的规则。
 
-你是技术美术思维的策划。这一件是**GDD 之后、资产生产之前的桥梁**：
-把概念层的调性翻译成可执行的视觉语言，把视觉语言压成逐素材的规格契约。
-你相信：
+动笔前核对概念与架构的当前里程碑、玩法对象、界面与状态、数据侧稳定标识、目标运行时和现有视觉资料。物品用 `item_id` 对接数据表，角色、区域、UI 状态等使用各自适当的标识，不给每种对象强加 `item_id`。范围外内容标明后续里程碑，不展开成当前资产清单。
 
-- **风格统一是资产效率的前提**：没有圣经，每张图都在重新发明风格；
-  有了圣经，一百张素材共享同一套锚点。
-- **视觉设计承接概念**：依据概念层的核心体验、情绪基调、风格及相关约束，
-  形成关键词、色板和形状语言。需要追溯时引用具体内容或章节，
-  完整视觉规格写入本圣经。
-- **每个可见对象必须绑定资产或显式豁免**：GDD 里出现的每个 gameplay 可见
-  对象，要么在资产总清单有一行，要么显式标"程序化生成/UI 文本/本期不需要"
-  ——没有第三种状态。漏绑定的对象会在开发中期以"缺素材"形式爆炸。
-- **先锚点后量产**：概念候选→人选方向→锚点确认→小批验证→接入→才扩产。
-  绝不做"做完一大批才发现风格不对"的事。
-- **禁用词与正向词同等重要**：每条视觉锚配"禁什么"（不要暗黑、不要描边
-  溢出），生成侧的负面清单比正向描述更防跑偏。
+## 写作要点
 
-## 二、动笔前
+1. **视觉依据与资源入口**：写明概念来源、风格意图、色彩、轮廓、材质、视角、像素或缩放规则，以及应避免的效果。已有参考图、画风卡或源素材时给可访问的位置与具体借鉴点；尚未形成的资源明确写“待产出”和预定交付位置，不把描述或路径当成已验收素材。
+2. **类别规格与明确清单**：先定义角色、地形、场景物、作物、图标、UI 等适用类别的共性规格，再列出当前范围的具体对象或有限变体。一个类别规则可覆盖多对象；个别尺寸、帧、层级或色彩不同的对象只写例外。清单与系统可见状态对账，程序化图形、文字等无图像资产的对象说明生成或消费方式。需要音频时同样列明用途、格式、循环、音量及触发绑定。
+3. **命名与消费**：说明文件或帧键命名、输出格式、预定交付目录、图集或独立文件选择，以及运行时如何按对象标识、状态、方向和事件取用。多帧资源必须给状态到帧的映射；区域图块不能当整图直接贴。目标运行时的导入方式按实际工程确定，不列不相关引擎的流程。
+4. **验收判据**：技术检查覆盖尺寸、透明、帧序、命名、打包和映射；视觉检查覆盖风格锚、辨识度、关键状态与目标视口。写成后续生产、接入时可执行的动作和通过条件。影响交付的工艺约束可以写，但无需固定候选图数量、十步流程或每对象工艺卡。
+5. **未决问题**：只记录会影响当前规格或交付的真实缺口，标明影响、决策者或下一步，以及确定后要更新的位置。关键规格未定时如实标注当前范围尚不能据此施工；样例中的假设也须标为假设。
 
-1. 输入齐了吗：概念层与视觉有关的体验、基调和约束（设计依据）、系统文档全部可见
-   对象（资产总清单的范围）、物品表（item_id 绑定依据，数据侧已定）、
-   可复用画风规范。
-2. 本件在数据侧表结构定稿后开写（素材清单引用 item_id）。
-3. 读取金样 exemplars/stardew-tdd-art-bible.md 了解契约表与资产状态表包含的信息类型（同层只读一次）。
+## 完成判断
 
-## 三、怎么写（模板即流程，按节）
-
-### 1. 视觉风格总览
-一段话 + 参考图位。结合概念层的体验、基调与约束，说明视觉气质、信息密度
-和需要避免的表现；有视觉参照时说明具体借鉴点。**style_id 在此定名**——
-本项目全部素材提示词共用此锚。
-
-### 2. 视觉锚（七件套）
-关键词（3~5 个）/ 禁用关键词 / 色板（主色辅色点缀+配比）/ 形状语言 /
-比例与轮廓 / 光照与材质 / 渲染口径。每件可引画风库现成卡（`卡名@版本`）。
-
-### 3. 角色与场景模板
-角色：共用基础规则（头身比、结构、方向数约定——左=右镜像之类的硬规定）、
-动画状态清单（待机/走/跑/受击…各几帧）。场景：tileset 规格、图层拆分、
-昼夜天气季节的表现预算。逐类写死，不留"到时候再说"。
-
-### 4. 素材规格契约（逐素材一行，美术按此交付、程序按此消费）
-| 素材 | 尺寸/帧数/方向数 | 命名规则 | atlas 格式 | 验收 | 绑定 item_id / 豁免 |
-每个 gameplay 可见对象一行；多帧图禁当静态图、单元素区域图禁整图使用
-（运行时绑定规则）。**怎么绘制→封装→交付，逐类写明工艺**
-（与三段复用能力的工艺卡衔接）。**资产管线按目标运行时适配**：HTML=源文件
-+atlas/帧表 JSON 直接入包；Unity=Sprite 导入设置与图集；Godot=资源导入
-（.import）；Cocos=Creator 资源与自动图集——规格（尺寸/帧数/命名）四运行时
-一致，封装形式随程序侧契约。
-
-### 5. 资产状态表（asset manifest，美术的"配表"）
-与数据侧的数值表平行的一张生产事实表：asset_id / 规格 / 绑定 / **状态** /
-验收记录 / contract_version。状态单向流转（缺失→草稿→已交付→已验收→已接入）；
-验收两维（技术：尺寸透明帧数命名；视觉：对照视觉锚），两维都过才进"已验收"。
-**每个 gameplay 可见对象必有一行或显式豁免，没有第三种状态**——缺什么、
-做到哪、谁验收过，一张表看全；程序接入填消费点，契约版本变更重验收。
-**自足性判定**：资产表"全行非缺失且两维验收过"＝美术侧构建完成——
-施工方 只看本圣经+资产表即可产出全部素材，不回 GDD。
-
-### 6. 量产流程与验证
-十步流水：概念候选（3~10 张）→人选方向→编辑出锚点图（3~5 张）→锁圣经
-→写契约→小批生成（3~8 张）→技术检查（尺寸/透明/视角/风格）→接入程序
-→运行时截图验收→**通过后才批量扩产**。验收判据写行为：桌面与移动视口
-下阵营/状态/反馈是否一眼可辨。
-
-### 6. 未决问题与待办
-视觉与玩法冲突、素材成本超预算（面数/张数/工时）、锚点两难等未决问题，
-记明影响和下一步；涉及产品取舍时请用户确认并同步 GDD。解决后把完整规格
-补入本圣经与资产清单，关闭待办。影响当前素材施工的关键问题未解决时，
-不宣称该范围已完备。
-
-## 四、写完自查（参考，不是闸门）
-
-- style_id 有了吗？禁用词列了吗？
-- GDD 每个可见对象都在资产总清单里吗（或显式豁免）？
-- 每类素材的验收是否技术可查（尺寸/透明通道/帧数）+ 视觉可查（风格一致）？
-- 量产流程里"扩产"前面有"运行时截图验收"这道闸吗？
-
-## 五、红线（承总纲四条，本件特化）
-
-1. 视觉规格应与概念层的体验、基调和约束一致，并在本圣经中写全。
-2. 素材契约每行必绑 item_id 或写豁免类型。
-3. 画风卡引用必带版本；工艺沿用既有复用能力的工艺卡，不即兴写流程。
+验收对象是**策划文档**：当前范围、视觉依据、对象清单、规格、绑定、消费方式及未来生产验收方法自洽，且没有阻断施工的未决歧义，即可评审文档。实际资产是否已经生成、接入或通过视觉验收，应由后续生产任务记录，不作为本分册完备的前提，也不在样例中虚构完成记录。

apps/ai-game-creator-shell/src-tauri/design-agent/resources/exemplars/tdd-data-SKILL.md

@@ -1,108 +1,29 @@
----
-name: game-tdd-03-data-config
-description: 写"数据与配表"（数据侧）分册时使用。与总纲（技术文档层总纲分册）配套。
-  配套模板：templates/tdd-data.md。配套金样：exemplars/stardew-tdd-data.md。
-  底料：归 TDD 素材两份提取件（S06 数值结构＋架构字段字典，随包附件）。
-  读者：数值策划 + 程序。
----
+# 数据与配表 · 数据侧写法（TDD 分册之三）
 
-# 数据与配表 · 数据侧写法（策划 · TDD 分册之三）
+写入 `project/04_tdd/03_数据与配表.md`，来源版本在总册集中记录。
 
-> 本文件承载数据侧的写作流程；模板在 templates/tdd-data.md（保持纯净），金样在 exemplars/stardew-tdd-data.md。
-> 两份提取件是本件的现成实料：引用规则、示例表、验收七查直接改造成文。
+本册把当前实现范围内会被程序读取的内容写成可施工的数据规格。策划文档是本阶段验收对象；文档验收通过后，程序应能只凭本套 TDD 实现当前范围，无须回查 GDD 或请作者补口头规则。游戏成品的运行、手感和平衡另在实现与试玩阶段验证。
 
-## 一、这一件的判断立场
+## 先确定范围和归属
 
-你是数值策划与程序之间的契约作者。表格是两者的共同语言。你相信：
+- 从技术分册的当前系统行为和本期流程找出实际需要的配置、枚举、地图点位、数值及文案；后续系统不提前铺表。
+- 每项事实指定唯一维护者：例如物品身份归物品系统，作物成长归农场系统，资源点位置与可用状态归地图系统，采集获得物归采集系统，价格和货币归经济系统。其他系统以稳定 ID 引用，说明读取或提交结果的方式。
+- 按项目内容组织数据。简单配置可直接列清，确实需要独立维护或一对多关系时再拆表；不预设工作簿数量、建表顺序、通用字段、关系子表或公共条件求值器。
 
-- **ID 是资产的身份证**：全局唯一、小写 snake_case、不因语言名称变化、
-  废弃不复用。显示名称永远走 `*_text_id` 引用，ID 单元格不出现人话。
-- **一个事实只有一个写权**：物品身份只在物品表、价格只由经济表、任务奖励
-  只由奖励表——其他表只引用。重复归属是配表第一大乱源，验收单独一查。
-- **数据拆分按"独立可调"**：敌人拆成"是什么/怎么行动/掉什么"三张表——
-  难度和经济才能独立调（S06 实证结构）。
-- **验收是硬闸**：七类检查 + blocker/warning/note 三级；**有 blocker 禁止
-  进入下一轮内容扩充**（竞品四十轮实测的同款铁律）。验收通过不代表平衡，
-  只代表结构、引用、单位、边界合格。
-- **单位必须类型化**：time_slice/game_day/currency/stamina/exp 各自为栏，
-  同一列混用单位是 blocker 级错误。
+## 写出可直接消费的配置
 
-## 二、动笔前
+对当前范围每个数据集，写明维护系统、记录身份、字段类型、单位、允许值、默认值或必填要求、引用目标和消费方。默认值只给确实允许省略的字段；未确定的关键值列入待解决问题，不能把“待定”当成运行值。多值采用能明确表达数量和顺序的结构，按实际消费需要选择数组、对象或独立表。
 
-1. 输入齐了吗：各系统的数据类别、已确定的规则参数与待补规格，以及架构中
-   的数据归属和共享约束。将这些信息落实为完整字段、配置和可执行的验算。
-2. 先读两份提取件：字段字典全套规则与验收模板已在那里成文，本件是
-   项目实例化，不是重新发明。
-3. 读取金样 exemplars/stardew-tdd-data.md 了解数据清单、验算表与验收结论包含的信息类型（同层只读一次）。
+把当前范围所需的**全部**记录和玩家可见文案放入本套 TDD，或明确指向本套 TDD 内唯一的权威定义。示例行不能代替完整配表；不能用“照此补齐”掩盖作物、商品、资源点或提示文案的缺口。对每条跨系统引用，说明来源、目标以及使用方如何处理缺失、不可用或入账失败。改变数据时同步更新受影响的规则、配置和验算。
 
-## 三、怎么写（模板即流程，按节）
+若游戏使用条件、随机或版本迁移，按实际机制描述触发输入、结果和数据消费方式；只有当前范围确实需要时才定义相应结构。不要为所有系统强制使用同一种条件表、固定加载顺序或随机种子。
 
-### 1. 数据表总清单
-表格组 → 建议表名 → 主要维护系统。从各系统的实际规则、数据与已定参数汇总，不要求固定交接章节；声明"表格拆分
-是生产组织方式，不改变主数据归属"。
+## 用真实配置验算
 
-### 2. 字段字典与 ID 命名规范
-ID 命名（`对象类型_名称_阶段`）/ 通用字段八件（`*_id`、`display_name_text_id`、
-`condition_id`、`enabled_state`、`sort_order`、`designer_note`、`unit`）/
-常用后缀（`_amount`、`_cost`、`_rule_id`、`_condition`、`_time`、`_duration`、
-`_state`、`_text_id`）/ 类型与空值铁律（数值栏禁写"约/无/待定"；空值≠0≠
-无限；多值一律关系子表）/ 引用完整性（`item_id`→物品表等全套指向；删除
-先 `deprecated` 查引用）。
+选择覆盖本期关键循环的场景和跨度，列出起点、行动、成本、获得、跨日变化与终点，展示计算过程和实际结果。至少核对相关 ID 可达、单位一致、资源不凭空产生或重复扣减、收益与消耗能支持目标行为。验算发现缺输入时写清已算出的部分和不能下结论的部分，补齐配置后重算；不要用预设的前五日表或只给公式不代入数值。
 
-### 3. 公共条件表
-任务、配方、商店、区域、事件、UI 教程共用同一条件入口：condition_id /
-condition_type（date_day、progress_flag、skill_level、schedule_open、
-quest_completed…）/ target_id / operator / required_value。复杂条件拆
-条件组+条件行，单元格禁自由文本。**程序只实现一遍求值器，全部系统复用
-`check(condition_id)`**——这是条件表存在的全部意义。
+## 验收本册
 
-### 4. 工作簿组织与建表顺序
-工作簿拆分（世界与地图/农场与制作/物品与经济/活动与战斗/成长与任务/
-事件与文本）+ ID 全局唯一声明。**建表顺序八步从物品表起步**（公共
-item_id 先立），每完成一组表查三件事：引用 ID 存在、条件有负责系统、
-同一数值只有一个系统维护。
+检查当前范围的数据和文案是否齐全，字段类型/单位/默认值是否明确，ID 与枚举是否有效，跨系统归属和引用是否一致，数值是否在规则允许范围内，以及关键场景的验算是否有可复核结果。记录检查对象、实际结果和未解决项；影响当前施工的缺口存在时明确写“未完成”，不可标成已验收。修改结构、数值或规则后复核受影响的配置和验算。
 
-### 5. 表格-程序契约（七条，程序照此消费）
-①加载顺序按引用拓扑（主数据→关系→条件→文本，文本最后）；②启动期
-全量校验（外键/枚举/单位一次性查，运行期 O(1) 字典查找）；③条件求值
-引擎统一 `check(condition_id)`；④enabled_state 生命周期（active 加载/
-draft 调试可见/两 disabled 不加载、deprecated 留 ID 占位防复用）；⑤单位
-类型化进类型系统；⑥多值一律关系子表，运行期不存在解析逗号拼接的代码
-路径；⑦改表→验收过检（blocker=CI 红灯）→进包，data_version 做迁移依据。
-随机类数值另加一条：影响掉落/品质的 roll 绑定「世界日+存档 ID+位置/主体」
-种子，防读档刷结果。
-
-### 6. 数值填充与验算
-结构定稿后才填数。实际数值、单位、适用范围和默认值写在本册配表与字段
-契约中；重要取舍按需记分析。依据当前玩法、共享约束和验证问题选择验算
-场景与跨度，记录关键行动、成本、获得和结果；检查实际存在的收益与消耗
-关系及引用 ID。验算结果应支持对节奏、可达性和资源收支的判断，不预设
-必须采用五日表或得出固定结论。
-
-### 6.5 全量填充与内容完成度（自足性的数据侧保障）
-结构定稿后的填充不是示例——是**全量**：数值表每表填满计划行数、文本表
-（对话/提示/图鉴文案）逐行填满。这是"纯看 TDD 做完游戏"的数据前提：
-程序加载表即得完整内容，不再回 GDD 找"这里应该有 8 种作物"。验收在七查
-之外加第八查——**内容完成度**：每表计划行数 vs 实填行数，缺口列清单回填；
-未决的填充缺口记明影响和下一步，解决后补齐配表并关闭待办。文本表由文本
-系统文档的文案收编（带版本锁）。
-
-### 7. 验收（七查+三级）
-主键/引用/枚举/单位/范围五查必须过；业务规则/重复归属两查需设计师复核。
-三级处置：blocker 禁止扩内容修完重验；warning 可继续但记负责人与计划；
-note 不阻断。验收记录表留 check_id 与 data_version。**结构、规则或字段
-语义一变，受影响链路全部重验。**
-
-## 四、写完自查（参考，不是闸门）
-
-- 每张表答得出"谁是拥有者系统"吗？
-- 任意单元格有没有"约/待定/多值拼一格"？
-- 条件表是否全项目一个入口？程序求值器只需实现一次吗？
-- 当前范围的关键场景验算跑过吗？涉及的资源与配置 ID 都存在吗？
-- 最近一次验收：blocker 清零了吗？
-
-## 五、红线（承总纲四条，本件特化）
-
-1. 表里不写散文；规则进契约文档。
-2. 数值变更同步更新本册配表、字段契约和受影响的验算；重要取舍按需记分析，不以外部台账替代施工数据。
-3. 有 blocker 不许扩内容——没有例外。
+模板 `templates/tdd-data.md` 提供可删减的组织方式；`exemplars/stardew-tdd-data.md` 展示尚有缺口时如何诚实记录。样例不是必须读取的前置材料，也不提供原作解包证据。

apps/ai-game-creator-shell/src-tauri/design-agent/resources/exemplars/tdd-tech-SKILL.md

@@ -1,95 +1,22 @@
----
-name: game-tdd-01-tech
-description: 写"技术实现"（程序侧）分册时使用。与总纲（技术文档层总纲分册）配套。
-  配套模板：templates/tdd-tech.md。配套金样：exemplars/stardew-tdd-tech.md。读者：工程师。
----
+# 技术实现写作规则
 
-# 技术实现 · 程序侧写法（策划 · TDD 分册之一）
+本册写入 `project/04_tdd/01_技术实现.md`，让程序仅凭本套 TDD 实现当前范围。参考结构见 `templates/tdd-tech.md`，示例见 `exemplars/stardew-tdd-tech.md`，按需读取。
 
-> 本文件承载程序侧的写作流程；模板在 templates/tdd-tech.md（保持纯净），金样在 exemplars/stardew-tdd-tech.md。
+## 平台与输入
 
-## 一、这一件的判断立场
+按 TDD 总纲限定的技术选型范围，记录本项目的平台、框架版本、工程入口和交付产物，构建与验证按实际工程说明。
 
-你是实现者视角的架构作者。这一件回答三个问题：**代码怎么组织、
-跑在哪、怎么证明能跑**。你相信：
+从架构和系统文档取得当前范围、职责、行为、数据归属及已定参数，与数据、美术分册协同补齐接口。当前缺少的产品取舍需要确认；实现选择直接写完整，并说明重要取舍。来源版本由总册集中记录，变更时同步受影响正文。
 
-- **自包含**：TDD 开头"来自 GDD 的功能"节必带——读者不回翻 GDD 就能开工。
-- **平台事实置顶且禁改**：自包含 Web、双视口、键鼠+触控、本地 HTTP 预览。
-  一切技术选择先过这道闸；GDD 里出现平台做不到的需求，记明问题、影响与下一步，涉及产品取舍时请用户确认，不硬做。
-- **能力边界说三态**：native（原生支持）/ emulated（需模拟封装）/ gated
-  （本期不做，写明替代方案）——程序侧不许答应 GDD 做不到的事。
-- **性能预算是基准不是完美**：每项指标写上限、写测量方式，当取舍依据用，
-  不追求极致。
-- **验证不靠人肉感觉**：每条验证写"跑什么、看什么输出、过了什么算过"——
-  接双视口浏览器验证与 browser-playtest 现有资产。
+## 写清实现所需信息
 
-## 二、动笔前
+- **系统行为与协作**：玩家或外部输入、前置条件、状态变化、结果反馈，成功、失败与中断后的结果。收编全部当前必需行为，可以按流程或模块重组，不能只列功能名或让施工方回翻 GDD。
+- **代码与数据**：工程入口、实际模块位置、调用关系、状态归属、配置读取与更新、素材加载与绑定；有存档时写清保存内容、时机、恢复与失败处理。代码目录按工程组织，不照搬系统文档目录。
+- **界面与操作**：界面元素、布局、进入退出、操作反馈，以及适用的输入设备、焦点、暂停和适配规则；参数与美术分册一致，不强制每个项目使用同一热区或版式。
+- **场景、镜头与音频**：按项目需要写尺寸、坐标、碰撞、镜头、动画、声音触发和参数；不要求项目具备固定的能力清单。
+- **依赖与能力限制**：优先复用已知可用能力，写清来源、版本和必要配置。对会影响实现的限制、风险及尚待核实能力如实说明，不能因暂时没有验证方法而删去风险。
+- **构建与验证**：写明命令或编辑器流程、产物位置、适用的验证场景和通过判据。性能目标注明测量条件；玩法与视觉可结合具体观察和玩家反馈判断，不必全部改成自动指标。
 
-1. 输入齐了吗：架构层当前实现范围、职责与协作（拆模块依据）、数据侧表结构契约
-   （加载与校验要引用）、可复用能力选型（实现类需求先查现成能力，不自造轮子）。
-2. 读总纲判断立场；本件在数据侧表结构定稿后开写。
-3. 读取金样 exemplars/stardew-tdd-tech.md 了解技术实现文档包含的信息类型（同层只读一次）。
+## 完成检查
 
-## 三、怎么写（模板即流程，按节）
-
-### 0. 系统行为规格（收编章——本件的灵魂）
-按当前实现范围**收编**各系统的玩家行动、状态与规则、反馈需求等行为规格，
-标注来源版本（如"基于系统文档@v{N}"）。施工方只读这里就应知道当前范围
-怎么实现，不需要回 GDD。后续范围可以保留职责与未决事项，纳入施工范围前
-必须补齐规格。GDD 变更时同步受影响的收编内容，不能只更新范围清单。
-
-### 0b. UI 交互规格（收编+落地章）
-界面清单（每个界面一行：HUD/背包/商店/对话/结算面板…）+ 每界面的元素、
-布局要点与流转（从哪进、怎么出、焦点默认在哪）。触控版式与 44px 热区
-规则在此落位（与圣经 UI 节同源）。
-
-### 1. 来自 GDD 的功能
-列出当前实现范围的系统与能力，承接架构中的职责、协作和数据归属。
-
-### 2. 技术目标与平台事实
-平台事实原样置顶（禁改）；技术目标写可测量的两三条（如"首屏可玩≤N 秒"）。
-
-### 3. 技术风险表
-每行：风险 / 影响 / 缓解 / **校验方式**。写不出校验方式的风险是空焦虑，删。
-
-### 4. 运行时能力边界
-P0 七件逐项过（瓦片地图渲染、寻路、帧动画、分辨率适配、音频、移动与碰撞、
-存档），**按所选运行时判定**，每项标三态：**原生**（运行时自带该能力：
-Unity Tilemap/NavMesh、Godot TileMap 节点/AudioServer、Cocos 组件、
-HTML 的 Canvas/WebAudio/localStorage）、**自封装**（基础 API 上自己写逻辑）、
-**受限**（该运行时不适合，写明替代方案或降级）。不许答应 GDD 做所选运行时
-做不到的事。运行时四选一（HTML/Unity/Godot/Cocos），TDD 不擅自换；
-引擎项目按所选引擎的预览与导出流程验证。
-
-### 5. 代码组织概览
-根据职责与实现需求确定入口、场景、系统模块的代码组织；架构中的系统文档
-目录不等于代码目录。用图或文字写清实际文件位置与模块关系。
-命名与模块边界约定写清（面向生成代码的可读性：谁在哪个目录、什么前缀）。
-
-### 6. 外部依赖与可复用能力
-实现类需求先查可复用能力；记录来源、适用版本与实例化参数；没有现成能力时写明来源与理由。
-
-### 7. 场景与镜头 / 输入与操作 / 音频
-三节各一张表：场景（tilemap 结构/镜头行为，规格和参数写全）；输入（动作×
-键盘×触控对照）；音频（用途×格式规格×触发点×依据）。各项实现默认值
-也写在对应正文，重要取舍按需记分析，不让施工方依赖外部台账。
-
-### 8. 构建与验证
-构建流程 + 验证分级：自动（什么命令、什么输出为过）、半自动（双视口
-浏览器验证走哪步）、手测清单（谁试玩、看什么）。
-
-### 9. 版本里程碑
-版本 / 内容 / 判据三列。判据必须可程序化或可观察，不写"基本完成"。
-
-## 四、写完自查（参考，不是闸门）
-
-- 每条风险都有"缓解+校验方式"吗？
-- 能力边界表覆盖 P0 铁底七件了吗？gated 项都有替代方案吗？
-- 验证流程里有没有一步是"人肉感觉"？有就改写成行为判据。
-- 程序拿到这份文档，能否不问任何人开工？
-
-## 五、红线（承总纲四条，本件特化）
-
-1. 平台事实禁改；与 GDD 冲突时说明影响和下一步，涉及产品取舍时请用户确认并同步 GDD。
-2. 可复用能力引用必带版本与参数。
-3. 里程碑判据不许写"基本""大致""感觉"。
+当前范围的行为、接口、数据消费、交互与工程约束能直接指导实现，跨分册约定一致。文档和必要验算应完成；后续构建、试玩与接入写成可执行计划，有已执行结果才记录结果。尚缺当前实现所需规格时，明确缺口及影响，不宣称本册完备。

apps/ai-game-creator-shell/src-tauri/design-agent/resources/skills/tdd.md

@@ -1,117 +1,33 @@
-## A5 技术文档分册（game-tdd）
+# 技术文档写作规则
 
----
-name: game-tdd
-description: 写游戏技术文档（TDD）时使用的总纲。GDD 四层定稿后的第五步：把
-  "怎么做"写实——程序怎么写、美术怎么做、字段怎么定义、怎么配表。
-  三大件各有专属分册：技术实现（程序侧）/ 美术圣经（美术侧）/ 数据与配表（数据侧）。
----
+TDD 是当前实现范围的施工依据：**施工方只看本套 TDD，就能完成该范围的实现。** 把设计落实为完整的行为、接口、数据、界面、素材规格和验证方法，章节按实际需要组织。
 
-# 技术文档写法（策划 · TDD 分册 · 总纲）
+## 技术选型范围
 
-> 本文件是 TDD 层唯一承载写作流程的教学件；各分册写法与模板配套使用。
-> 模板与例子文件保持纯净：不含任何步骤、检验提示与标记。
+选型限定在 Game Agent 已支持的 Web、Unity、Godot、Cocos Creator 范围内，并遵循已定平台与实际工程。新建 Web 使用 npm + Vite；二维使用 Phaser 4.2.1，三维按需求选择 Three.js、Babylon.js 等适用技术栈；依赖通过 npm 管理，预览与导出使用包目录下的 `dist/index.html`，运行资源随构建进入 dist。已有工程沿用实际结构，不因模板擅自更换引擎或迁移框架。
 
-## 〇、结构适配原则
+## 内容与维护
 
-根据当前版本的实现目标、游戏规模、运行时和用户要求选取本分册的适用内容，同类项可合并；复杂项目可以拆分补充，简单项目可以合并为最小施工合同。
+- 利用已有 GDD 和资料，收编当前范围所需规则、参数与反馈，并补全实现规格；可以重组表达，不要求逐段复制。来源及版本集中记录在总册，特殊来源在相应内容旁注明。
+- GDD 的产品取舍有缺口或需要变更时，与用户确认并同步受影响设计；技术实现规格、参数和默认值直接完善在 TDD。设计变化后同步受影响分册，不能只更新版本或范围清单。
+- 一个事实有明确的权威维护方。跨系统调用、表引用、素材绑定、只读副本与存档说明数据来源、更新方式和失败后的结果。
+- 技术、美术、数据可按依赖交叉完善，不固定编写顺序。重要取舍按需记分析；未决事项写清问题、影响和下一步，解决后补齐正文并移出待办，外部台账不能代替施工规格。
 
-## 〇、TDD 的完成判据（总纲）
+## 产物与参考
 
-**TDD 是当前版本的施工合同：施工方只看 TDD，应能完成本项目实际范围内的实现。**
-GDD 是设计真源（给人看、给迭代看）；TDD 是构建真源（给施工看）。
-检验方式＝按项目范围检查施工所需信息是否齐全：实际存在的系统怎么行为、
-实际使用的表和配置怎么读取、实际存在的界面怎么走、实际需要的素材什么规格。答不出的项就是缺口，
-缺口回 GDD 同步后**收编**进 TDD（带版本锁）。收编是构建期快照：GDD 定稿
-变更 → 触发对应收编节重同步。
+在 `project/04_tdd/` 保留以下四文件；某方向不涉及时在对应分册简述原因，按需增加补充文件。
 
-## 一、这一层的判断立场
-
-你是工程师思维的策划。GDD 是"用户视角的功能描述"，TDD 是"实现者视角的
-架构性描述"——你不重复设计的论证（为什么这样设计，去 GDD 和分析文档查），
-只写怎么落地。你相信：
-
-- **交接契约是 TDD 最大的价值**：美术交给程序的素材、程序读的表、加载的
-  顺序——每一条缝都写死。缝上不写死，返工就在缝里发生。
-- **平台事实优先**：目标运行时由 GDD 平台事实锁定——**HTML / Unity / Godot /
-  Cocos 四选一**。HTML 项纯 HTML/CSS/JS 交付；引擎项支持打开引擎工程、自然
-  语言协作改素材与代码；预览与导出按所选引擎的平台流程执行。
-  一切技术选择先过所选运行时这道闸，不推荐该运行时做不出来的东西；
-  TDD 不擅自换运行时。
-- **一个事实有明确的权威维护方**：主数据归属在 TDD 中落实为表结构与更新接口。
-  其他系统通过稳定标识引用；只读副本、派生视图和快照须写清来源及更新或恢复规则，不能成为第二套独立维护的事实。
-- **验收通过后扩充内容**：有 blocker 时先修复并重验。
-- **先少量验证再量产**（美术）/ **先建索引再转表**（数据）。
-
-## 二、TDD 与 GDD 的接口（输入从哪来）
-
-| 输入 | 来自 | 喂给哪件 |
+| 文件 | 内容 | 写法参考 |
 |---|---|---|
-| 当前实现范围、系统职责与协作、数据归属及共享约束 | 架构层 | 三件共用（拆表与拆模块依据） |
-| 各系统的数据类别、已确定的规则参数与待补规格 | 系统文档 | 数据侧（实现所需输入） |
-| 核心体验、情绪基调、风格及相关约束 | 概念层相关内容或章节 | 美术圣经（视觉设计依据） |
-| 可复用能力 | 能力库 | 程序侧+美术圣经（带版本与实例化参数） |
+| `01_技术实现.md` | 系统行为、代码组织、接口、交互、运行与验证 | `exemplars/tdd-tech-SKILL.md` |
+| `02_美术圣经.md` | 视觉依据、素材清单、制作规格、接入与验收标准 | `exemplars/tdd-art-bible-SKILL.md` |
+| `03_数据与配表.md` | 字段、完整配置与文案、引用与消费方式、验算 | `exemplars/tdd-data-SKILL.md` |
+| `总册.md` | 当前范围、分册索引、来源版本、跨分册约定与重要缺口 | `templates/tdd-master.md` |
 
-TDD 不擅自改 GDD：发现 GDD 没写清楚的产品取舍，向用户确认并同步 GDD；
-技术实现中的规格、参数和默认值直接写完整在对应 TDD 正文。重要取舍可按需
-记录分析，但外部决策台账不是施工信息来源。尚未解决的问题记入对应分册的
-待办，写明问题、影响和下一步；解决后补齐正文并关闭待办。顾问期（开发阶段）
-遇到程序美术卡点或成品与文档偏差，也按此更新对应文档版本（v{N+1}）。
-影响当前实现的关键问题未解决时，不宣称该范围的 TDD 已完备。
+模板与样例通过资源目录按需读取，不预设样例的玩法、数据规模或技术选择。
 
-## 三、三大件与开工顺序
+## 策划案验收
 
-| 件 | 管什么 | 读者 | 分册 |
-|---|---|---|---|
-| 数据与配表 | 字段定义、表结构、数值、验收 | 数值策划 + 程序 | 03 |
-| 技术实现 | 代码组织、场景镜头、输入、音频、性能预算、验证 | 程序 | 01 |
-| 美术圣经 | 视觉锚、素材规格契约、量产流程 | 美术 | 02 |
-
-**顺序：数据侧 → 程序侧 → 美术圣经**。数据侧根据各系统的实际规则、数据与
-已定参数明确配置；程序侧收编行为，加载与验证要引用表结构；美术
-圣经的素材总清单要引用物品表（每个可见对象绑定 item_id 或显式豁免）。小型
-项目三件可交叉，但**表结构永远先于数值填充**。
-
-## 四、怎么写（总纲级；细节在各分册）
-
-1. 数据侧：总清单拆表 → ID 与字段字典 → 公共条件表 → 建表顺序（物品表
-   起步）→ 表结构契约（程序签名）→ 数值填充（完整值与默认值）→ 验收七查。
-2. 程序侧：系统实现总览（每系统一段话写死怎么做）→ 技术选型与可复用能力引用
-   → 场景与镜头 → 输入与操作 → 音频 → 验证方式与性能预算。
-3. 美术圣经：视觉锚（从概念层定调翻译）→ 素材规格契约逐素材一行 →
-   量产流程（概念候选→锚点确认→小批→验收→扩产）→ 资产总清单。
-
-## 五、自查参考
-
-- 任意一条缝（美术→程序、表→代码、表→表引用）是否都写死了规格？
-- 每张表是否答得出"谁是拥有者系统"？每个 ID 是否全局唯一？
-- 程序侧验证方式是否可执行（跑什么命令、看什么输出）？
-- 素材契约是否覆盖了 GDD 里全部可见对象（或显式豁免）？
-- 验收是否跑过且无 blocker？
-
-## 六、红线（只有四条）
-
-1. **收编必带版本锁**：从 GDD 收编的任何内容标注"基于系统文档@v{N}"；
-   无锁收编=违规（双源漂移之源）。TDD 不擅自新增产品设计，只汇集与落实施工。
-2. 引用必带版本：可复用能力引用必须记录版本与实例化参数，选型时与执行时用的一致性靠此保证。
-3. 不越权拍板：产品级取舍由用户确认并同步 GDD；技术实现的完整结论写在 TDD，重要取舍按需记分析。
-4. 表里不写散文：单元格只有数据和枚举；规则写在契约文档，不写在表里。
-
-
-
-
-## A1 概念层分册（简介）
-
-本分册说明概念设计的目标、边界、核心张力、分析记录和交接要求。完整内容请阅读 `resources/skills/concept.md`；概念设计模板请阅读 `resources/templates/concept-design.md`。
-
-## A2 顶层设计分册（简介）
-
-本分册说明游玩过程、关键规则与反馈、资源与进展、选择后果、版本范围和验证计划。完整内容请阅读 `resources/skills/top_design.md`；顶层设计模板请阅读 `resources/templates/top-design.md`。
-
-## A3 系统架构分册（简介）
-
-本分册说明系统职责与协作、数据归属、系统文档映射、实现范围与验证。文档映射指 `project/03_systems/...`，实现代码的目录与模块组织由 TDD 明确。完整内容请阅读 `resources/skills/architecture.md`；架构模板请阅读 `resources/templates/architecture.md`。
-
-## A4 系统文档分册（简介）
-
-本分册说明单个系统的职责、规则、输入输出、反馈、边界、验证和分析记录。完整内容请阅读 `resources/skills/systems.md`；系统类型的专属写法和模板请按需阅读 `modules/system-types/` 下对应分册。
+- 当前范围的行为、数据、界面、素材规格和接口完整、自洽，施工方无需回 GDD 或外部台账寻找实现规则；当前采用值明确，后续调优不能代替当前规格。
+- 文档一致性、数据引用和必要的数值验算已检查，影响当前施工的关键缺口已解决。
+- 构建、试玩、素材生产与接入的执行方法和判据明确。文档验收不要求游戏或素材已制作完成；已有验证结果据实记录，未执行的写为计划，不能宣称通过。

apps/ai-game-creator-shell/src-tauri/design-agent/resources/templates/tdd-art-bible.md

@@ -1,75 +1,50 @@
-### C3 02_美术圣经/模板.md（→ templates/tdd-art-bible.md）
-
-本模板是美术实施的参考结构。按项目实际需要选择角色、场景、UI、动画和素材契约；没有对应资产类型时删除相应章节，复杂项目可增加必要的视觉规则。表格和资产条目可按实际内容扩展，不代表数量上限。
-
 # 美术圣经：《游戏名》
 
-> 状态：{drafting / reviewed / frozen}　|　设计依据：概念层@v{N}（相关内容或章节：__）　|　style_id：`__`
+按实际范围组织内容，来源与版本见总册。
 
-## 视觉风格总览
+## 范围与设计依据
 
-__（一段话：与概念层体验、基调及约束一致的视觉气质；参考图位 __ 张）
+- 当前实现范围：__（区域、玩法、界面和状态；后续内容另列）。
+- 概念与系统依据：__（文档、章节及转译到本分册的视觉要求）。
+- 目标运行时与显示条件：__（实际工程、目标视口和缩放方式）。
+- 已有视觉参考入口：__（真实位置与借鉴点；没有则写“暂无”，并在下文写明文字规格）。
+- 源文件与交付资源入口：__（真实现有位置；尚未产出时注明预定位置和格式）。
 
-## 视觉锚
+## 视觉规则
 
-- 关键词：__（按项目需要）。
-- 禁用关键词：__。
-- 色板：主色 __ / 辅色 __ / 点缀 __（配比 __）；昼夜·天气·季节表现 __。
-- 形状语言：__。
-- 比例与轮廓：__。
-- 光照与材质：__。
-- 渲染口径：__（可引画风卡 `卡名@版本`）。
+- 气质与关键词：__。
+- 避免的表现：__。
+- 色板与状态变化：__（主辅色、提示色、昼夜/天气/季节等当前范围需要的变化）。
+- 形状、比例、视角与层级：__。
+- 光照、材质、渲染与缩放：__。
 
-## 角色模板
+## 类别规格
 
-- 基础规则：__（头身比/结构/共用约束，保同一世界观）。
-- 方向数：__（__ 方向，左=右镜像：是/否）。
-- 动画状态：__（待机 __ 帧 / 走 __ 帧 / 跑 __ 帧 / 受击 __ 帧…）。
-- 与人物复用能力三段格式的衔接：选型卡 __ / 工艺卡 __ / 接口卡 __。
+按当前范围保留需要的类别。图像类写共性尺寸、帧与方向、透明和边缘规则；音频类写格式、循环与音量等规格。各类注明命名、格式/封装、运行时取用方式和验收判据。共享规则只写一次，个别对象的差异在清单中列为例外。
 
-## 场景模板
+| 类别 | 共性规格 | 命名与交付格式 | 运行时消费 | 验收判据 |
+|---|---|---|---|---|
+| __ | __ | __ | __ | __ |
 
-- tileset 规格：__（tile 尺寸/边缘连接/padding）。
-- 图层拆分：__（地面/装饰/遮挡/碰撞语义）。
-- 场景对象规则：__（多帧禁当静态贴图、单元素禁整图等运行时绑定规则）。
+## 当前范围对象清单与例外
 
-## UI 视觉
+列全当前可见对象、必要状态和有限变体。物品引用数据侧 `item_id`；角色、区域、UI 等用适当标识。若对象由程序绘制或由文字呈现，写明来源和消费方式。范围外对象不占当前清单行。
 
-__（承 UI 系统文档的界面清单；视觉语言与信息分层对齐）
-
-## 素材规格契约
-
-| 素材 | 规格（尺寸/帧数/方向数） | 命名规则 | atlas 格式 | 验收 | 绑定 |
+| 对象或明确对象组 | 类别 | 标识/数据绑定 | 状态与变体 | 规格例外或无图像资产的处理 | 消费位置 |
 |---|---|---|---|---|---|
-| __ | __ | __ | __ | __ | `item_ __` / 豁免：__ |
-（以上为示例，可按实际素材删减或扩充。）
+| __ | __ | __ | __ | __ | __ |
 
-- 绘制工艺：__（按项目实际制作路径记录工具、参数与封装流程）。
-- 豁免类型仅限：程序化生成 / UI 文本 / 本期不需要。
+## 后续生产与接入验收
 
-## 资产状态表（asset manifest）
+- 生产交付：__（源文件、导出文件、目录和必要的生成/切图约束）。
+- 技术验收：__（如何检查尺寸、帧序、透明、命名、加载、状态映射；通过条件）。
+- 视觉与可用性验收：__（对照视觉规则，在目标视口检查哪些状态与反馈；通过条件）。
+- 变更同步：__（对象或状态增减时，更新清单、命名、消费映射及相关数据/程序规格）。
 
-| asset_id | 规格 | 绑定 | 状态 | 验收记录 | contract_version |
-|---|---|---|---|---|---|
-| __ | __ | `item_ __` / 豁免 | 缺失/草稿/已交付/已验收/已接入 | 技术过/视觉过 @__ | __ |
-（以上为示例，可按实际资产删减或扩充。）
+## 当前未决问题
 
-- 状态单向流转：缺失 → 草稿 → 已交付 → 已验收 → 已接入；驳回退回草稿并记原因。
-- 验收两维：技术（尺寸/透明/帧数/命名）+ 视觉（对照视觉锚）；两维都过才进"已验收"。
-- 需要登记的 gameplay 可见对象有一行；不需要资产登记的对象不建立空记录。
-- 程序接入后填消费点（哪个模块加载、事件映射），`contract_version` 变更须重验收。
-
-## 量产流程与验证
-
-1. 概念候选 __ 张 → 2. 人选方向 → 3. 锚点图 __ 张 → 4. 锁圣经 →
-5. 写契约 → 6. 小批 __ 张 → 7. 技术检查（__）→ 8. 接入程序 →
-9. 运行时验收（按项目支持的平台）→ 10. 扩产。
-（以上为示例，可按实际流程删减或扩充。）
-
-## 待解决问题
-
-| 问题 | 对当前素材施工的影响 | 下一步与需更新的正文 |
+| 问题 | 对当前施工的影响 | 下一步与需更新的位置 |
 |---|---|---|
 | __ | __ | __ |
 
-按需列出；问题解决后补齐正文与素材规格并移出待办。影响当前素材施工的关键问题未解决时，不宣称该范围已完备。
+仅保留真实缺口。若当前施工所需规格仍有歧义，如实说明，不宣称本分册已经覆盖该范围。

apps/ai-game-creator-shell/src-tauri/design-agent/resources/templates/tdd-data.md

@@ -1,86 +1,62 @@
-### C3 03_数据与配表/模板.md（→ templates/tdd-data.md）
-
-本模板是数据与配表的参考结构。只有项目实际存在配置、枚举、关系或条件数据时才建立对应表和校验；简单项目可以直接写配置约定，复杂项目再拆分表结构与验算流程。表格中的示例行可按实际数据、字段和验算项扩展，不代表数量上限。
-
 # 数据与配表：《游戏名》
 
-> 状态：{structuring / filling / accepted}　|　基于：各系统规则与数据汇总　|　验收：check@{id} 最新结论 __
+> 当前实现范围：__。本册与技术实现、美术圣经及总册共同构成施工依据，来源版本见总册；验收对象是策划文档。填完当前范围的实际配置、文案与验算后才能标记本册完成。
 
-## 数据表总清单
+## 数据范围与归属
 
-| 表格组 | 建议表名 | 主要维护系统 |
-|---|---|---|
-| __ | __ | __ |
-（以上为示例，可按实际数据表删减或扩充。）
+| 数据或配置 | 维护系统 | 当前范围用途 | 消费方与引用方式 |
+|---|---|---|---|
+| __ | __ | __ | __ |
 
-（表格拆分是生产组织方式，不改变主数据归属。）
+只列本期实际使用的内容。每项事实只在一个位置定义；其他系统引用其 ID 或读取其结果。复杂项目可按需要拆为多张表、JSON 或工作簿，简单项目可在本册直接列清。
 
-## 字段字典与 ID 命名规范
+## 字段与消费契约
 
-- ID 命名：小写 snake_case，`对象类型_名称_必要时加阶段`（如 `item_turnip`）；全局唯一、废弃不复用。
-- 通用字段：`*_id` / `display_name_text_id` / `description_text_id` / `condition_id` / `enabled_state`（active·draft·disabled·deprecated）/ `sort_order` / `designer_note` / `unit`（数值字段必填：time_slice·game_day·currency·stamina·exp）。
-- 常用后缀：`_amount`（配单位）/ `_cost` / `_rule_id` / `_condition` / `_time` / `_duration` / `_state` / `_text_id`。
-- 类型与空值：数值栏禁"约/无/待定"；空值=不适用≠0≠无限；布尔 true/false；多值一律关系子表。
-- 引用完整性：`item_id`→物品表；`location_id`→区域表；`npc_id`→NPC表；`quest_id`→任务表；`recipe_id`→配方表；`condition_id`→条件表；`text_id`→文本表。删除先置 `deprecated` 并查引用。
+对每个实际数据集列出记录身份、全部字段、类型、单位、允许值、默认值或必填要求、引用目标。下表按需复制；不要求所有数据集拥有相同字段。
 
-## 公共条件表
+### __（维护系统：__）
 
-| condition_id | condition_type | target_id | operator | required_value | enabled_state | 备注 |
-|---|---|---|---|---|---|---|
-| __ | date_day / progress_flag / skill_level / schedule_open / quest_completed / __ | __ | __ | __ | active | __ |
-
-（存在复杂条件时再拆条件组与条件行；没有条件系统时删除本节。）
-
-## 工作簿组织与建表顺序
-
-| 工作簿 | 工作表 |
-|---|---|
-| `__ .xlsx` | __ |
-
-建表顺序：①物品表（公共 item_id）→ ②__ → ③__ → ④__ → ⑤__ → ⑥__ → ⑦__ → ⑧__。
-每完成一组查三件事：引用 ID 存在 / 条件有负责系统 / 同一数值只有一个系统维护。
-（以上为示例，可按实际表结构删减或扩充。）
-
-## 表格-程序契约
-
-1. 加载顺序按引用拓扑：主数据 → 关系 → 条件 → 文本（最后）。
-2. 启动期全量校验（外键/枚举/单位）；运行期全部 id→对象字典 O(1) 查找。
-3. 条件求值统一 `check(condition_id)`，全部系统复用。
-4. enabled_state 生命周期：active 加载；draft 调试可见；disabled 不加载；deprecated 不加载但留 ID 占位。
-5. 单位类型化（time_slice/game_day/currency/stamina/exp 进类型系统，同列禁混单位）。
-6. 多值一律关系子表；运行期无"解析逗号拼接"代码路径。
-7. 改表 → 验收过检（blocker=CI 红灯）→ 进包；`data_version` 为迁移依据。
-
-## 数值填充与验算
-
-- 实际范围内的全部数据行、字段值、单位和默认值写入本册配表；重要取舍可按需记分析，外部台账不能代替配表。以下用于列出需要明确的字段默认值：
-
-| 表 | 字段 | 默认值 | 单位与适用范围 | 说明 |
+| 字段 | 类型及单位 | 必填或默认值 | 允许值/约束 | 引用目标与消费方式 |
 |---|---|---|---|---|
 | __ | __ | __ | __ | __ |
-（以上为示例，可按实际验算字段删减或扩充。）
 
-- 前五日闭环验算：
+说明：__（如实例状态与静态配置的区别、数据何时读取、缺失或失败如何处理）。若存在一对多内容，选用能清楚表示数量与顺序的结构；条件、随机或迁移数据只在实际需要时定义。
 
-| 日期 | 主目标 | 关键行动 | 主要成本 | 主要获得 | 结果 |
-|---|---|---|---|---|---|
-| 第 1 日 | __ | __ | __ | __ | __ |
-（以上为示例，可按实际循环或阶段删减或扩充。）
+## 当前范围完整配置与文案
 
-- 收益链校验：`__ → __ → __ → __ → __`（逐环引 ID）。
+在此列出当前实现范围**每一条**实际记录和值，包括所需的系统参数、配置和玩家可见文案；也可明确指向本套 TDD 中唯一的权威定义。下面的单行仅示范格式，不表示填充完成。
 
-## 验收
+| 数据集 | ID 或适用对象 | 字段和值（含单位） | 来源/引用 |
+|---|---|---|---|
+| __ | __ | __ | __ |
 
-- 验收记录：check_id / workbook / sheet / data_version / check_type（primary_key·reference·enum·unit·range·business_rule·duplicate_ownership）/ severity（blocker·warning·note）/ result / issue / owner / resolution。
-- 五查必过：主键唯一不空；外键存在且目标非弃用；枚举有清单；单位可判且同列不混；无违规负数、`duration=0` 仅即时。
-- 两查复核：业务规则（季节窗口相容、目标有验证系统、奖励一次、配方输入可达）；重复归属（身份/价格/成本/奖励/位置各只有一个写权）。
-- 三级处置：blocker 禁止扩内容；warning 记负责人与计划；note 不阻断。
-- 最近验收结论：__（结构、规则或字段语义一变，受影响链路全部重验。）
+内容数量由已定范围决定。允许明确当前采用的初值并在原型中调优；未定关键值进入“待解决问题”，不可用空白、未经说明的估值或几行示例冒充完整配置。
+
+## 关键循环验算
+
+按玩法选择足以覆盖本期行为的跨度，不固定为五日。使用上节真实配置，逐步写出输入、计算和结果，并核对消费链上的 ID 与单位。
+
+| 起点与行动 | 成本及计算 | 获得及计算 | 跨日/状态变化 | 结果与结论 |
+|---|---|---|---|---|
+| __ | __ | __ | __ | __ |
+
+说明尚不能验算的输入、受影响的结论和补齐后需重算的内容：__。
+
+## 数据检查与结论
+
+| 检查对象 | 实际检查及结果 | 未解决项/影响 |
+|---|---|---|
+| 当前范围配置和文案完整性 | __ | __ |
+| 字段类型、单位、默认值、枚举及数值范围 | __ | __ |
+| ID 引用、归属及消费方式 | __ | __ |
+| 关键循环验算 | __ | __ |
+
+本册结论：__。影响当前施工的缺口存在时写“未完成”；补齐后更新正文并重新检查受影响项。此处记录策划文档检查，不冒充游戏构建或试玩结果。
 
 ## 待解决问题
 
-| 问题 | 对当前配表施工的影响 | 下一步与需更新的正文 |
+| 问题 | 对当前施工或验算的影响 | 下一步与需更新的正文 |
 |---|---|---|
 | __ | __ | __ |
 
-按需列出；问题解决后补齐正文与配表并移出待办。影响当前实现的关键问题未解决时，本册不能标为 accepted。
+没有未决问题时删除本节。

apps/ai-game-creator-shell/src-tauri/design-agent/resources/templates/tdd-master.md

@@ -1,63 +1,37 @@
-### C3 模板_TDD总册.md（→ templates/tdd-master.md）
-
-本模板是 TDD 总册的参考结构。只建立当前项目实际需要的技术、美术、数据和索引内容；没有对应方向时不创建空分册，复杂项目可以增加施工所需的分册。表格中的示例行可按实际分册、问题和验收项扩展，不代表数量上限。
-
 # TDD 总册：《游戏名》
 
-> 本册是 TDD 层的封面与索引：正文在三件分册（01 技术实现 / 02 美术圣经 / 03 数据与配表），
-> 跨件的缝在本页看全。状态：__　|　基于 GDD：__@v{N}
+## 当前范围
 
-## 自足性检查（TDD 的完成判据）
+本次实现目标与边界：__。
 
-> 标准：施工方只看当前 TDD，能完成项目实际范围内的实现。逐项检查当前项目真正需要的问题，
-> 答得出=过；答不出=缺口（列 GDD 来源与同步动作）。
+完成标准：施工方只看本套 TDD 就能完成当前范围的实现。验收检查文档的完整、自洽及必要验算，不以游戏或素材已经生产完成为前提；影响当前施工的关键规格缺口必须解决。
 
-| # | 施工方的问题 | 答案在哪 | 状态 |
-|---|---|---|---|
-| 1 | 实际存在的系统怎么行为？ | 01 收编章（@v{N}） | __ |
-| 2 | 实际使用的表和配置是否可施工？ | 03 数据与配表 | __ |
-| 3 | 实际存在的界面怎么走？ | 01 UI 交互规格 | __ |
-| 4 | 实际需要的素材什么规格？ | 02 资产状态表 | __ |
-| 5 | 代码怎么组织、跑在哪？ | 01 代码组织+能力边界 | __ |
-| 6 | 怎么算做完了（判据）？ | 01 里程碑+各件验收 | __ |
+## 分册索引
 
-当前项目所需检查全部为"过"，且影响当前实现的关键问题已解决时，TDD 进入 frozen——构建可以在本版本范围内脱离 GDD 进行。
+| 文件 | 内容位置 |
+|---|---|
+| `01_技术实现.md` | __ |
+| `02_美术圣经.md` | __ |
+| `03_数据与配表.md` | __ |
 
-## 三件状态
+四文件均保留；不涉及的方向在对应分册简述原因。补充文件在此列明。
 
-| 件 | 状态 | 版本 | 读者 | 一句话结论 |
-|---|---|---|---|---|
-| 01 技术实现 | __ | __ | 程序 | __ |
-| 02 美术圣经 | __ | __ | 美术 | __ |
-| 03 数据与配表 | __ | __ | 数值+程序 | __ |
+## 来源与版本
 
-## 跨件契约速查（缝都在这）
+记录采用的 GDD、系统文档及其他资料的版本或可识别快照：__。设计变更后同步受影响分册，特殊来源在正文旁注明。
 
-| 缝 | 契约 | 权威在 |
+## 跨分册约定
+
+| 共同使用的约定 | 当前结论 | 维护位置 |
 |---|---|---|
-| 素材绑定 | 资产状态表每行绑 `item_id`/`enemy_id`/`npc_id`…，ID 查数据侧对应表 | 03 字段字典 |
-| 视觉设计依据 | style_id 及视觉规格与概念层体验、基调和约束一致，依据与完整规格写入美术圣经 | 02 视觉风格与视觉锚 |
-| 加载顺序 | 程序启动按"主数据→关系→条件→文本"拓扑加载（契约七条①） | 03 契约 |
-| 帧表格式 | atlas+帧表双边共用（圣经素材契约列的格式 = 程序侧帧动画节读的格式） | 01 §能力边界 |
-| 交互热区 | 触控热区 ≥ __px，圣经 UI 节与程序侧输入表同源 | 01 输入表 |
-| 音频规格 | 圣经音频契约（格式/响度/循环点）= 程序侧音频表触发实现 | 02 音频契约 |
-| 昼夜/色调 | tint 色值表豁免绑定但拥有者写明 | 02 资产状态表 |
-| 拥有者总则 | 一个事实一个写权：数值事实归 03 各表、生产状态归 02 资产表、技术事实归 01 | 架构层归属规则 |
+| __ | __ | __ |
 
-## 重要缺口汇总
+只列实际需要共同遵守的标识、数据、素材和接口约定，详细规格在对应分册维护。
 
-| 相关分册 | 影响当前施工的缺口 | 详细位置 |
-|---|---|---|
-| 01/02/03 | __ | 分册 §__ |
+## 文档检查与重要缺口
 
-只汇总跨分册或影响当前施工的重要缺口，详细问题与下一步在对应分册维护。解决后补齐分册正文并移出本汇总，不向全局台账重复登记。
+- 当前范围的完整性、一致性和必要验算结论：__。
+- 影响施工或涉及多分册的重要缺口及详细位置：__。
+- 尚未执行的游戏或素材验证见各分册的执行方法与判据。
 
-## 验收总状态
-
-| 件 | 最近验收 | blocker | 结论 |
-|---|---|---|---|
-| 01 | __（按项目平台验证 @__） | __ | __ |
-| 02 | __（技术+视觉两维 @__） | __ | __ |
-| 03 | __（七查 @check_id） | __ | __ |
-
-任一件有 blocker：禁止对应方向的内容扩充（数值 blocker 冻结填数与接入；资产 blocker 冻结扩产；程序 blocker 冻结下个里程碑）。
+详细问题在对应分册维护，解决后补齐正文并移出缺口汇总；不依赖固定状态标签判定是否完备。

apps/ai-game-creator-shell/src-tauri/design-agent/resources/templates/tdd-tech.md

@@ -1,104 +1,55 @@
-### C3 01_技术实现/模板.md（→ templates/tdd-tech.md）
-
-本模板是技术实现的参考结构。按当前运行时、系统复杂度和用户要求选择章节；没有对应系统、界面、输入、音频或存档需求时，删除相应内容，复杂项目可增加施工所需章节。表格和系统条目可按实际实现范围扩展，不代表数量上限。
-
 # 技术实现：《游戏名》
 
-> 状态：{drafting / reviewed / frozen}　|　基于 GDD：架构层@v{N}　|　数据侧契约：data/contracts@v{M}
-> **目标运行时：{HTML / Unity / Godot / Cocos}（由 GDD 平台事实锁定）**　|　预览：{按项目平台验证 / 引擎=编辑器内预览}　|　导出：{HTML=自包含 / 引擎=引擎命令行导出}
+按实际范围选择和合并章节，补齐实现所需内容；来源及版本见总册。
 
-## 系统行为规格（收编章）
+## 当前范围与工程约束
 
-### S01 __（基于系统文档@v{N} 收编）
-- 玩家行动：__（收编全文）
-- 状态与规则：__（收编全文）
-- 反馈需求：__（收编全文）
+- 本次实现的功能与边界：__。
+- 目标平台、框架及版本、工程入口：__。
+- 构建产物与资源路径：__。
 
-### S__ …
+选型限于 TDD 总纲规定的 Web、Unity、Godot、Cocos Creator；新二维 Web 使用 npm + Vite + Phaser 4.2.1，已有工程沿用实际结构。
 
-## UI 交互规格
+## 系统行为与协作
 
-| 界面 | 元素与布局 | 流转（入口→出口） | 触控版式 |
-|---|---|---|---|
-| __ | __ | __ | __（热区≥44px 落位） |
+| 系统或流程 | 输入与条件 | 状态变化与结果 | 失败或中断 | 反馈与协作 |
+|---|---|---|---|---|
+| __ | __ | __ | __ | __ |
 
-## 来自 GDD 的功能
+复杂行为可展开为段落、步骤或图，规则和当前采用参数写全。
 
-| 当前实现范围的系统 | 一句话职责 | 拥有的主数据 |
+## 代码、接口与数据
+
+- 入口与模块位置、职责及调用关系：__。
+- 状态归属、接口输入输出、更新及失败处理：__。
+- 配置和素材的路径、读取方式与绑定关系：__。
+- 适用的存档内容、时机、恢复与失败处理：__。
+
+## 界面与操作
+
+| 界面或操作 | 元素与布局 | 进入、退出与状态流转 | 输入与反馈 | 适配要求 |
+|---|---|---|---|---|
+| __ | __ | __ | __ | __ |
+
+## 场景、镜头与音频
+
+写明当前需要的坐标、尺寸、碰撞、镜头行为、动画与音频触发及参数：__。
+
+## 依赖、限制与风险
+
+| 依赖或能力 | 来源、版本及配置 | 用途与限制 |
 |---|---|---|
 | __ | __ | __ |
 
-## 技术目标与平台事实
-
-- 平台事实（由 GDD 平台事实锁定）：__。
-- 技术目标：__（可测量，如"首屏可玩 ≤ __ 秒"）。
-
-## 技术风险
-
-| 风险 | 影响 | 缓解 | 校验方式 |
-|---|---|---|---|
-| __ | __ | __ | __ |
-
-## 运行时能力边界
-
-| 能力（按项目实际使用的能力填写） | 落位（按所选运行时） | 状态（原生/自封装/受限） | 说明 |
-|---|---|---|---|
-| 瓦片地图渲染 | __ | __ | __ |
-| 寻路 | __ | __ | __ |
-| 2D 帧动画 | __ | __ | __ |
-| 分辨率适配 | __ | __ | __ |
-| 音频 | __ | __ | __ |
-| 移动与碰撞 | __ | __ | __ |
-| 存档 | __ | __ | __ |
-
-（运行时对照速记：瓦片地图——Unity Tilemap／Godot TileMap 节点／Cocos TiledMap 组件／HTML Canvas 自绘；寻路——Unity NavMesh／Godot NavigationServer／Cocos 寻路组件或自写 A*；音频——Unity AudioSource+Mixer／Godot AudioServer 总线／Cocos AudioSource／HTML WebAudio；存档——引擎侧 PlayerPrefs/文件系统，HTML 侧 localStorage+导出。）
-
-## 代码组织概览
-
-- 目录结构：__（依据职责与实现需求明确入口、场景和模块位置，不照搬系统文档目录）。
-- 命名与边界：__（文件前缀、模块间允许的调用方向）。
-
-## 外部库与 skill 引用
-
-| 需求 | 用什么 | 来源与版本 | 实例化参数 |
-|---|---|---|---|
-| __ | __ | `skill@版本` / CDN / 手写 | __ |
-
-## 场景与镜头
-
-| 项 | 规定（含完整规格与参数） | 依据或说明 |
-|---|---|---|
-| tilemap 结构 | __（尺寸/tile 大小/层数及用途） | __ |
-| 镜头行为 | __（跟随/边界/变化） | __ |
-| 关卡数据 | __（文件格式与位置） | __ |
-
-## 输入与操作
-
-| 动作 | 键盘 | 触控 | 备注 |
-|---|---|---|---|
-| __ | __ | __ | __ |
-
-## 音频
-
-| 用途 | 格式/规格 | 触发点 | 依据 |
-|---|---|---|---|
-| __ | __ | __ | __ |
+重要风险、影响、处理办法及待核实内容：__。
 
 ## 构建与验证
 
-- 构建：__（命令/流程）。
-- 验证分级：自动__（跑什么、看什么输出为过）；半自动__（按项目平台验证步骤）；手测__（谁试玩、观察什么）。
-
-## 版本里程碑
-
-| 版本 | 内容 | 判据 |
-|---|---|---|
-| __ | __ | __ |
+- 构建流程、命令及产物：__。
+- 行为、数据、界面与素材接入的验证场景及通过判据：__。
+- 适用的性能目标、测量条件与方法：__。
+- 已完成的文档检查或验证结果：__；未执行的验证计划：__。
 
 ## 待解决问题
 
-| 问题 | 对当前实现的影响 | 下一步与需更新的正文 |
-|---|---|---|
-| __ | __ | __ |
-
-按需列出；问题解决后补齐正文并移出待办。影响当前实现的关键问题未解决时，本册不能标为 frozen。
+按需写明问题、对当前实现的影响和下一步；解决后补齐正文并移出待办。影响当前施工的关键问题未解决时，本册尚未完备。

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

@@ -1,5 +1,12 @@
 # 决策记录
 
+## 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 系统文档按实际行为展开
 
 - 系统层围绕触发、规则、状态变化、结果与协作组织内容，取消固定十二节、编号追溯、统一取舍表和枚举表达要求；类型规则与模板按需使用，不为填模板添加机制或预设玩法。

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

@@ -306,7 +306,15 @@ concept → top_design → architecture → systems → tdd → consultant
 
 TDD 的决策记录采用相同原则：施工规格、参数、默认值直接写入对应分册，重要取舍按需保留分析，未决事项说明影响与下一步，不要求逐项登记到外部台账或附推翻条件。总册保留施工索引、跨分册契约与重要缺口，详细问题指向对应分册。问题解决后更新受影响的 GDD 与 TDD 正文并关闭待办，不能只登记处理去向。
 
-“施工方只看 TDD，应能完成当前范围的实现”仍是完成标准。保留 GDD 内容收编、来源版本与变更同步，以及资产清单、字段字典、接口规格、验收记录等施工信息；外部分析与台账不能代替 TDD 的实现说明。当前范围仍有影响实现的关键问题时，不得宣称该范围已完备。样例中尚有缺口的 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 规则而不要求逐段全文复制；来源版本集中在总册记录，设计变化同步受影响正文。删除固定数据→程序→美术顺序、必读样例、P0 七件与三态、逐节表格、固定建表步骤、统一条件求值器和七查三级等写作纪律。数据分册仍须给出当前范围全部配置与文案及可复核验算，不以示例行代替；美术采用类别共性规格、明确对象清单及例外，保留命名、绑定、消费方式与验收判据，不再强制全部对象绑定 item_id 或维护生产状态台账。
+
+总册保留当前范围、分册索引、来源版本、实际跨分册约定与重要缺口，不重复生产验收表或以 frozen 标签判定通过。`project/04_tdd/01_技术实现.md`、`02_美术圣经.md`、`03_数据与配表.md`、`总册.md` 四个产物继续保留，不涉及的方向在分册简述原因。十二份 TDD 规则、模板和样例同步这一口径；星露谷样例聚焦首个日常原型，数值与素材规格标明示例假设，未附证据的原作实证、构建通过和资产验收声明清理，规格与验算缺口如实保留。资源 ID、路径、阶段注入及 Runtime 的文件存在性检查不变。
 
 `resources/SKILL.md` 未登记到资源目录，不属于现役注入来源。
 
@@ -326,7 +334,7 @@ TDD 的决策记录采用相同原则：施工规格、参数、默认值直接
 
 十二类系统资料保留类型特有的设计问题，模板不预填未经选择的动作、状态、循环和数据表。日历、生产队列、成长分支、复杂叙事、节日专属玩法和战斗定位均由实际项目决定；系统职责与权威数据归属遵循架构，UI 可以维护交互、导航和临时状态，正式玩法校验与结算仍由对应系统负责。跨系统行动明确整体成功或失败的预期结果，具体实现协议由 TDD 落实。
 
-系统文档保留已定规则、单位和参数，TDD 从相关内容收编并补齐完整实现规格，不依赖固定交接章节。系统编号、文档位置、资源登记及审批语义不变。战斗样例明确为后续矿井原型的暂定方案：实时基础动作、安全撤退保留成果、倒下可能损失部分钱物，未定规格和待执行验证如实标明；技术样例同步来源版本和规则，继续保留当前范围只看 TDD 即可开工的完成标准。
+系统文档保留已定规则、单位和参数，TDD 从相关内容收编并补齐完整实现规格，不依赖固定交接章节。系统编号、文档位置、资源登记及审批语义不变。战斗样例明确为后续矿井原型的暂定方案：实时基础动作、安全撤退保留成果、倒下可能损失部分钱物，未定规格和待执行验证如实标明；TDD 日常原型样例不提前收编后续战斗，纳入施工范围时再补全规则与规格。
 
 进入下一阶段必须由用户批准触发。Runtime 推进后向 Agent 追加明确的用户行为语义，例如“用户已批准上一阶段，现在进入顶层设计阶段”，避免 Agent 误认为 Runtime 自行推进。