统一简化策划文档维护与技术决策登记

简化分析文档、决策台账、对话记录与速览卡的维护要求清理阶段分册、模板和样例中的重复登记协议简化技术决策记录，保留只凭TDD完成当前范围实现的要求修正未决问题与施工完备性矛盾的样例并同步项目文档
2026-09-27 13:14:01 +00:00
parent c6a0844b50
commit 8484a30d49
26 changed files with 185 additions and 310 deletions
@@ -1,6 +1,6 @@
 共享过程文件（如需维护，请使用这些相对路径）：
- project/analysis.md
- project/决策台账.md
- project/dialog.md
+- project/analysis.md：重要取舍的依据与当前结论。
+- project/决策台账.md：待处理事项与下一步，必要时引用相关文档。
+- project/dialog.md：仅在用户需要时记录对话摘要或交接信息。
 正式产物使用当前阶段指定的相对路径。
 五个策划阶段的审批：当你判断当前策划阶段必需产物已完成时，必须提交阶段审批。用户批准后进入下一阶段。
@@ -1,4 +1,4 @@
-概念阶段定稿时，创建或更新 `project/速览卡.md`。下面是速览卡的参考结构；根据游戏类型、项目规模和用户要求选择适用字段，同类内容可以合并，复杂项目可以增加必要字段。表格和列表中的示例行按实际对象逐行扩展：
+概念阶段定稿时，创建或更新 `project/速览卡.md`，简要介绍当前游戏。后续仅在核心体验、范围、平台等概览内容变化时更新，不复制完整决策清单。下面是速览卡的参考结构；根据游戏类型、项目规模和用户要求选择适用字段，同类内容可以合并，复杂项目可以增加必要字段。表格和列表中的示例行按实际对象逐行扩展：

 # 速览卡：《游戏名》

@@ -1,66 +1,8 @@
-# 决策台账：《星露谷物语》金样项目
+# 决策台账：《星露谷物语》示例项目

-版本：v3　|　规则：台账放活队列——design 只放结论、分析只放论证、决定与开放问题住这里。编号连续不复用；被推翻的行标 overturned 挂新行，不删行。
-状态六态：`confirmed`（用户亲口/亲选）/ `auto_decided`（技术类代决，必带理由＋推翻条件，用户一键可翻）/ `default_pending`（默认建议兜底，用户未点头）/ `prototype_pending`（待原型验证）/ `pending_user`（等用户拍板）/ `overturned`（被推翻，挂旧行编号）。
+仅列仍需跟进的事项和下一步。详细依据与采用的规则见相关分析和设计文档；事项完成后移出待办。

-> 编号口径：D-01~D-13 与 templates/stardew-analysis.md 台账节选一致（D-04~D-06、D-08~D-10、D-12 原为"就地小权衡，直接登记未开条目"，此处按登记口径展开）；D-14 起为技术文档期新增，与 stardew-tdd-tech.md 开放问题回执互引。
-
-## 当前待办（活队列）
-
-### 等用户拍板（pending_user）
-
-| 编号 | 决定 | 层 | 谁 | 依据 | 推翻条件 | 状态 |
-|---|---|---|---|---|---|---|
-| D-14 | 体力与战斗共享单池 | TDD | user | 风险资源统一制造取舍（概念张力一）；**暂按共享实现，改单拆只需改 S02 成本入口** | 战斗参与率实测过低（玩家回避矿井） | pending_user（暂按共享实现） |
-| D-15 | 背包格子制 vs 重量制 | TDD | user | 格子制直觉、重量制焦虑感与 T5"休闲不打卡"冲突；暂按格子制实现、存档预留 capacity_type 字段 | 格子管理成为主要负面反馈 | pending_user（B 级阻断存档结构，暂按格子制） |
-
-### 待原型验证（prototype_pending）
-
-| 编号 | 决定 | 层 | 谁 | 依据 | 推翻条件 | 状态 |
-|---|---|---|---|---|---|---|
-| D-13b | 战斗判定窗口手感（前摇帧数/无敌帧 450ms 基准） | 系统 | user | 数值可定、手感不可纸面验证 | 原型显示节奏拖慢/玩家困惑 | prototype_pending（规则本体见 D-13 confirmed） |
-
-### 默认建议兜底（default_pending）
-
-| 编号 | 决定 | 层 | 谁 | 依据 | 推翻条件 | 状态 |
-|---|---|---|---|---|---|---|
-| D-19 | 天气权重表具体数值（晴/雨/风暴按季节） | TDD | agent | 概念层只定"雨免浇水"定性；数值推内容期填 | 前 5 日出现连续 3 日雨/全无雨 | default_pending（默认值已进数据表，带 designer_note） |
-
-## 已采用决定
-
-### 用户确认（confirmed）
-
-| 编号 | 决定 | 层 | 谁 | 依据 | 推翻条件 | 状态 |
-|---|---|---|---|---|---|---|
-| D-01 | 定调：牧场物语系参照、治愈慢节奏 | 概念 | user | 用户原始需求 | — | confirmed |
-| D-02 | 单人体验，无多人 | 概念 | user | 概念层非目标 | — | confirmed |
-| D-03 | 战斗保持伴生风险，不做装备驱动主轴 | 概念 | user | 概念期问题一 | 矿井流失率过半且归因战斗 | confirmed |
-| D-07 | 日目标自设，季节与社区提供低频牵引 | 顶层 | user | 顶层期问题一 | 新手周流失归因无方向 | confirmed |
-| D-11 | 采集/钓鱼/战斗统一"活动结果"接口 | 架构 | user | 架构期问题一 | 第三活动类型出现结构性差异 | confirmed |
-| D-13 | 战斗采用节奏/指令判定 | 系统 | user | S06 问题一 | 原型显示节奏拖慢/玩家困惑 | confirmed（手感部分拆 D-13b prototype_pending） |
-
-### 技术代决（auto_decided——带理由与推翻条件，用户一键可翻）
-
-| 编号 | 决定 | 层 | 谁 | 依据（理由） | 推翻条件 | 状态 |
-|---|---|---|---|---|---|---|
-| D-04 | 时间片制：700ms=10 游戏分钟 | 概念 | agent | 原作实证节拍；一天≈14 分钟真实时间贴合 T5"休闲" | 内测一天体感过短/过长 | auto_decided |
-| D-05 | 分区域切换（区域独立场景，非连续地图） | 概念 | agent | 概念层"不是什么：无边界开放世界"；区域小网络全部步行可达 | 场景切换成为移动负担反馈 | auto_decided |
-| D-06 | 28 日/季、四季/年 | 顶层 | agent | 季节窗口制造"本季计划"节奏（支柱二） | 换季频率在测试中被无视 | auto_decided |
-| D-09 | 商店营业时段走条件表 | 架构 | agent | 与配方/区域解锁共用 check(condition_id) 单一入口 | 条件表规模膨胀难维护 | auto_decided |
-| D-10 | 出货箱日终统一结算 | 架构 | agent | 收入集中进日终面板，强化"一天一结算"叙事；商店现卖保留即时通道 | 玩家普遍绕开出货箱 | auto_decided |
-| D-12 | 工具升级期间该工具不可用 | 系统 | agent | 升级=时间成本换效率（顶层张力二）；备用旧工具暂不做（开放问题） | 升级期挫败感集中爆发 | auto_decided |
-| D-16 | 矿井逐层生成本期不做（P2） | TDD | agent | GDD 已标"不做无限地牢"；首期按布局池 8~12 模板拼装 | 内测要求深度爬塔玩法 | auto_decided |
-| D-17 | 换装首期 5 层（基础体/裤/衣/发型/饰件），非 19 层 | TDD | agent | 外观自定义非首期卖点；层结构预留到 19 层 | 外观系统成核心诉求 | auto_decided |
-| D-18 | 作物品质三档：普通/银/金 | TDD | agent | 经济分层需要（即时变现 vs 等待升值的取舍） | 银金档无人区分、一律普通出售 | auto_decided |
-
-### 已推翻（overturned——旧行保留，挂新行）
-
-| 编号 | 决定 | 层 | 谁 | 依据 | 推翻条件 | 状态 |
-|---|---|---|---|---|---|---|
-| D-08 | 作物品质两档：普通/银 | TDD | agent | 早期小权衡：两档最简 | — | **overturned → D-18**（经济分层不足，改三档；铱档留 P1） |
-
-## 队列纪律（使用说明）
-
- 新决定入队：拿下一号（当前最大 D-19，下一号 D-20）；就现代决可登记不开条目，但状态必须写 auto_decided 并带理由＋推翻条件。
- 用户翻案：旧行标 overturned 挂新行，受影响文档节重写（本台账只记录，不代改）。
- 概念层变更定稿后：速览卡"决定状态与原型验证项"字段随本文件最新版同步。
+- 体力与战斗是否共享资源：涉及探索压力和恢复规则，结合用户对战斗体验的要求确认，再更新相关系统设计。
+- 背包使用格子还是重量限制：在确定存档和界面结构前确认，选择依据记录在分析文档。
+- 战斗判定窗口的手感：通过矿井原型试玩观察是否易懂、是否拖慢探索，依据见分析文档“战斗判定窗口是否需要调整”。
+- 天气权重是否合适：用前几天的游玩样本检查连续雨天或长期无雨的影响，再调整配置。
@@ -1,6 +1,6 @@
 # 速览卡：《星露谷物语》金样项目

-> 字段来源见每节尾注（概念层/定调记录/决策台账）。概念层变更定稿后本卡必须同步更新。
+> 本卡概括当前游戏；仅在核心体验、范围、平台等概览内容变化时更新。具体规则和取舍依据见对应设计与分析文档。

 ## 1. 游戏名称
 《星露谷物语》（金样项目沿用案例名；新项目由概念层第 1 节定名）←概念层§1
@@ -51,9 +51,5 @@ Web 浏览器运行 · 双视口（桌面/移动）· 键鼠/触屏双输入 ·
 - 这样验证：测试者玩完第 1 日后是否主动说"再玩一天"；能否说出"明天要先做什么"。
 - 达标再扩展：玩家能自述明日计划后，才加社交深度与矿井分层。

-## 12. 决定状态与原型验证项（依据决策台账）
- 已确认（confirmed）：定调 D-01 / 单人 D-02 / 战斗伴生 D-03 / 日目标自设 D-07 / 活动统一接口 D-11 / 战斗节奏判定 D-13。
- 技术代决（auto_decided，可一键翻案）：D-04 时间片 / D-05 分区域切换 / D-06 28 日季 / D-09 营业条件 / D-10 出货箱日终 / D-12 工具占用 / D-16 矿井生成 P2 / D-17 换装 5 层 / D-18 品质三档（推翻 D-08 两档）。
- 等拍板（pending_user）：D-14 体力战斗是否共享单池（暂按共享实现）；D-15 背包格子/重量（暂按格子制，B 级阻断存档结构）。
- 待原型（prototype_pending）：D-13b 战斗判定窗口手感（前摇帧数/450ms 无敌帧基准）。
- 默认兜底（default_pending）：D-19 天气权重数值（默认已入表，带 designer_note）。
+## 12. 待原型验证项
+- 矿井中的轻度战斗能否提供节奏变化，同时保持探索流畅；通过原型试玩观察判定是否易懂、战斗是否拖慢探索。
@@ -8,7 +8,7 @@
 > 玩家在有限的时间与体力下，通过农场、探索与社交三组活动系统产出资源与关系，经物品与经济系统转化为投资，由时间系统推进日终，把一天的成果变成下一天的选择。

 变更记录：
- 2026-09-05：战斗与敌人系统定为伴生风险定位，深度刻意受限，不进入最小闭环核心链（依据：概念分析 D-03）。
+- 2026-09-05：战斗与敌人系统定为伴生风险定位，深度刻意受限，不进入最小闭环核心链（依据：分析文档“矿井战斗要不要做成装备驱动的成长主轴”）。

 ## 系统地图

@@ -66,7 +66,7 @@ P0 段：
 负责一天制的节奏规则：什么时候推进日期、哪些系统收到跨天 tick、日终结算何时发生。它不负责奖励结算，也不负责作物成长规则——只负责"什么时候"和"谁被通知"。

 ### S06 战斗与敌人系统
-负责战斗内状态、敌人行为与战利品请求。它不直接修改商店价格或 NPC 好感，不负责角色长期成长；战利品只提交请求，由 S07 物品系统入账。定位是矿井探索的风险与节奏变化，不是成长主轴（D-03）。
+负责战斗内状态、敌人行为与战利品请求。它不直接修改商店价格或 NPC 好感，不负责角色长期成长；战利品只提交请求，由 S07 物品系统入账。定位是矿井探索的风险与节奏变化，不是成长主轴，依据见分析文档中的矿井战斗取舍。

 ### S07 物品、背包与制作系统
 负责物品身份、容器、堆叠与配方队列。它是全项目的公共语言层——任何系统的产出都以 `item_id` 入账；它不负责物品的经济价值平衡，价格只由 S09 维护。
@@ -1,6 +1,7 @@
 # 美术圣经：《星露谷物语》（TDD 金样 · 美术圣经）

 > 状态：reviewed　|　定调锚：概念层@v1 第 2 节（定调记录：牧场物语系参照、压力低/节奏慢/治愈）　|　style_id：`stardew_warm_rural_pixel`
+> 本例仍有换装范围、锚点图和字体等待解决的问题；相关规格为草案，不能将局部资产验收当作整体规格完备。
 > 实证规格来源：星露谷 1.6.15 解包知识库 v3（资产计数时点 2026-09-11，快照 stardew-1.6.15-7f1e5b8e）。写新项目时按本项目定调重译，数字仅作规模参照。

 ## 视觉风格总览
@@ -71,12 +72,14 @@

 ## 量产流程与验证

-1. 概念候选 4 张（农场一角/角色/物品图标/UI 面板各 1 方向稿）→ 2. 人选方向（用户确认）→ 3. 锚点图 4 张 → 4. 锁圣经 → 5. 写契约（本文件已锁）→ 6. 小批 8 张（icon_item 子集：防风草种子/防风草/木材/石头/铜矿/锄头/水壶/出货箱）→ 7. 技术检查（尺寸/透明/命名/atlas 解析）→ 8. 接入程序（v0.1 里程碑）→ 9. 运行时截图验收（桌面/移动双视口下 16×16 图标与作物相位可辨、四季色调正确）→ 10. 扩产（8→120→全量）。
+1. 概念候选 4 张（农场一角/角色/物品图标/UI 面板各 1 方向稿）→ 2. 人选方向（用户确认）→ 3. 锚点图 4 张 → 4. 锁圣经 → 5. 写契约（本例的相关缺口仍待补齐）→ 6. 小批 8 张（icon_item 子集：防风草种子/防风草/木材/石头/铜矿/锄头/水壶/出货箱）→ 7. 技术检查（尺寸/透明/命名/atlas 解析）→ 8. 接入程序（v0.1 里程碑）→ 9. 运行时截图验收（桌面/移动双视口下 16×16 图标与作物相位可辨、四季色调正确）→ 10. 扩产（8→120→全量）。

-## 开放问题回执
+## 待解决问题

-| # | 问题 | 去向 |
+| 问题 | 影响 | 下一步与需更新的正文 |
 |---|---|---|
-| 1 | 换装系统首期是否做全 19 层（或缩到 5 层） | → 台账代决（建议首期 5 层：基础体/裤/衣/发型/饰件；台账 D-17） |
-| 2 | 锚点图方向需用户确认 | → 施工期提案卡 |
-| 3 | 位图字体 vs 矢量像素风字体 | → 小批阶段随 UI 套件定 |
+| 换装首期是否采用 5 层 | 决定角色图集数量与程序分层接口 | 确认范围后，在角色规格及素材契约写清采用的层次、顺序与命名；当前建议为基础体、裤、衣、发型、饰件 |
+| 锚点图方向待用户确认 | 影响后续素材的视觉验收依据 | 用户确认后将锚点及具体风格要求写入视觉规格，更新受影响的素材契约 |
+| 位图字体还是矢量像素风字体 | 影响文字渲染与 UI 资产格式，正文的位图方案尚为暂定 | 小批 UI 验证后定案，将字体资源、格式与使用方式补入 UI 规格并同步程序分册 |
+
+问题解决后更新对应正文并移出待办，施工方无需从外部台账查找最终规格。
@@ -1,6 +1,6 @@
 # 数据与配表：《星露谷物语》（TDD 金样 · 数据与配表）

-> 状态：accepted（结构定稿＋首期全量填充验算通过）　|　基于：各系统文档交接节汇总 ＋ 归 TDD 素材两份提取件（S06 数值结构／架构字段字典）　|　验收：check@C-2026-09-11-v1 结论 无 blocker
+> 状态：待补齐（背包容量与公共索引定义仍有缺口）　|　基于：各系统文档交接节汇总 ＋ 归 TDD 素材两份提取件（S06 数值结构／架构字段字典）　|　已有数据验收：check@C-2026-09-11-v1；不代表当前范围规格已完备
 > 实证计数来源：星露谷 1.6.15 解包知识库 v3（13 张数据表，提取脚本断言通过；快照 stardew-1.6.15-7f1e5b8e）。写新项目时按本项目系统交接节重建，计数仅作规模参照。

 ## 数据表总清单
@@ -66,9 +66,9 @@

 ## 数值填充与验算

- 填充代决台账：
+- 当前采用的数值与验证关注点：

-| 表 | 字段 | 默认值 | 依据 | 推翻条件 |
+| 表 | 字段 | 当前值 | 依据 | 验证关注点（按需） |
 |---|---|---|---|---|
 | 等级经验表 | 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 日验算不闭合 |
@@ -95,4 +95,11 @@
 - 两查复核：业务规则（季节窗口相容、目标有验证系统、奖励一次、配方输入可达——防风草种子→收获→出售链全通）；重复归属（价格只由经济表维护、品质只由收获规则维护）。
 - 三级处置：blocker 禁止扩内容；warning 记负责人与计划；note 不阻断。
 - 工具化实证口径（参照知识库做法）：提取脚本逐表断言（行数/字段/枚举）；对账器做表间交叉对账（代表资产级 50 键全对账）；反例套件 5/5 拒绝。
- 最近验收结论：check@C-2026-09-11-v1——五查全过、两查复核通过、blocker 清零（结构、规则或字段语义一变，受影响链路全部重验）。
+- 最近验收结论：check@C-2026-09-11-v1——已有数据的五查与两查复核通过；背包容量与公共索引定义仍需补齐，不能据此认定当前范围的数据规格完整。结构、规则或字段语义一变，受影响链路全部重验。
+
+## 待解决问题
+
+- 背包容量：与技术分册确认格子或重量规则后，补齐容器字段、容量约束及存档数据定义。
+- 公共索引：补齐 condition/text/station/behavior 的索引定义与引用说明，再检查加载和引用完整性。
+
+完成后将采用的规则写入本文对应数据规格并更新验收结论，移出待办。
@@ -1,28 +1,28 @@
 # TDD 总册：《星露谷物语》

-> 状态：active（v0.1 里程碑期）　|　基于 GDD：架构层@v3 + 各系统交接节
+> 状态：待补齐（v0.1 仍有关键规格缺口）　|　基于 GDD：架构层@v3 + 各系统交接节

-## 自足性检查（2026-09-06 生产态复评）
+## 自足性检查（未完备示例）

 | # | 施工方的问题 | 答案在哪 | 状态 |
 |---|---|---|---|
-| 1 | 七个 P0 系统怎么行为？ | 01 收编章（P0 七系统规则全文已收编@v1；S06 P1 要点已收） | **过** |
-| 2 | 表里有多少行内容、文本全填了吗？ | 03 全量填充（作物8/敌人3/NPC12/文本40/物品46/配方14 全填，第八查全绿） | **过** |
-| 3 | 每个界面长什么样、怎么走？ | 01 UI 交互规格（HUD/背包/商店/对话/结算五界面全） | **过** |
-| 4 | 每份素材什么规格、谁验收过？ | 02 资产状态表 42 行全登记（完成度 12/42，缺口=量产排期非规格缺口） | **过（规格）**／量产进行中 |
+| 1 | 七个 P0 系统怎么行为？ | 01 收编章及待解决问题 | **缺口**：背包容量与体力规则仍需确定 |
+| 2 | 表里有多少行内容、文本全填了吗？ | 03 数值填充、验收及待解决问题 | **缺口**：已有数据检查不能代替容量与公共索引定义 |
+| 3 | 每个界面长什么样、怎么走？ | 01 UI 交互规格 | **缺口**：背包方案确定后需更新对应交互 |
+| 4 | 每份素材什么规格、谁验收过？ | 02 素材规格、资产状态表及待解决问题 | **缺口**：换装范围、锚点图和字体仍有待确认内容 |
 | 5 | 代码怎么组织、跑在哪？ | 01 代码组织+能力边界（三态全落位） | **过** |
 | 6 | 怎么算做完？ | 01 里程碑三判据+三件验收 | **过** |

-**结论：六问全过——TDD 规格已自足，施工方 可只凭本 TDD 开工。**
-剩余非规格缺口（不阻塞开工，按里程碑推进）：①P1 四系统（S05/S10/S11/S12）施工前补文档并收编；②资产表 30 行量产（按十步流程排期）；③B 级两项（背包容量、生命体力共享）在 v0.1 存档实现前收口。
+**结论：当前范围的 TDD 尚未完备。** 只有相关规则、数据与素材规格补齐到 TDD 正文后，才能认定施工方可只凭 TDD 完成该范围的实现；登记待办或已有检查通过均不能替代这一步。
+后续版本新增系统时仍需补齐相应规则并收编。已明确规格的资产可按计划制作，其生产进度与上述规格缺口分别记录。

 ## 三件状态

 | 件 | 状态 | 版本 | 读者 | 一句话结论 |
 |---|---|---|---|---|
-| 01 技术实现 | reviewed | v0.2 | 程序 | P0 铁底七件全部落位（native 4/emulated 3），无 gated；v0.1 判据=一个游戏日全流程 |
-| 02 美术圣经 | locked（锚点已锁） | v1 | 美术 | 视觉锚七件套从 T1~T7 翻译完毕；资产表 ~40 行全登记，农夫已接入、芜菁已验收 |
-| 03 数据与配表 | accepted | ck-001 | 数值+程序 | 七查过、无 blocker、2 warning（公共索引表未建、背包容量未定案）；前五日验算通过 |
+| 01 技术实现 | 待补齐 | v0.2 | 程序 | 补齐背包与体力规则；v0.1 判据仍为一个游戏日全流程 |
+| 02 美术圣经 | 待补齐 | v1 | 美术 | 确认换装范围、锚点图与字体；已有资产的验收记录保留 |
+| 03 数据与配表 | 待补齐 | ck-001 | 数值+程序 | 已有数据检查通过，容量与公共索引定义仍需补齐后重验 |

 ## 跨件契约速查

@@ -37,23 +37,23 @@
 | 昼夜色调 | `tint_{phase}` 四档程序色值表，豁免绑定、拥有者=美术圣经资产表 | 02 资产状态表 |
 | 拥有者总则 | 数值事实归 03（价格只在经济表）；生产状态归 02（素材验收记录）；技术事实归 01（缩放档位） | 架构层@v3 |

-## 开放问题回执汇总
+## 重要缺口汇总

-| # | 来源件 | 问题 | 去向 | 状态 |
-|---|---|---|---|---|
-| 1 | **01** | 背包格子还是重量容量（阻断：影响存档与 UI） | 概念层决策卡 | **待用户（B 级置顶）** |
-| 2 | 02 | NPC 对话立绘 +12 张（影响 UI 结构与工时） | 决策卡 | 待用户（B 级） |
-| 3 | 01 | 矿井逐层生成是否本期 | 台账代决（建议 P2） | 待登记 |
-| 4 | 02 | 节日专属装饰 P1/P2 | 台账代决（建议 P2） | 待登记 |
-| 5 | 02 | 矿井色板 1 套 vs 3 套 | 台账代决（建议 1 套+亮度递减） | 待登记 |
-| 6 | 03 | condition/text/station/behavior 公共索引表 | 03 warning（记负责人） | 进行中 |
+| 相关分册 | 影响当前施工的缺口 | 详细位置 |
+|---|---|---|
+| 01、03 | 背包容量与体力规则影响行为、存档及界面 | 01“待解决问题”；确定后同步两份分册正文 |
+| 01 | 矿井生成是否纳入本期影响地图实现 | 01“待解决问题”及“场景与镜头” |
+| 02 | 换装范围、锚点图与字体影响素材和渲染规格 | 02“待解决问题” |
+| 03 | 公共索引定义影响数据加载与引用 | 03“待解决问题” |
+
+详细分析与下一步在对应分册维护；问题解决后更新分册正文，再移出本汇总，无需向全局台账重复登记。

 ## 验收总状态

 | 件 | 最近验收 | blocker | 结论 |
 |---|---|---|---|
-| 01 | 构建通过+静态检查全绿；双视口验证待 v0.1 联调 | 0 | 结构合格 |
-| 02 | ck-a01~a03：农夫接入✓、芜菁两维过（1 warning）、春瓦技术过视觉待锚点 | 0 | 小批已过闸，允许扩产 |
-| 03 | ck-001 七查全跑 | 0（2 warning） | 允许内容扩充 |
+| 01 | 已有构建和静态检查通过；双视口验证待联调 | 背包与体力等规格缺口 | 补齐正文后复核当前范围的完整性 |
+| 02 | ck-a01~a03 保留已有资产的接入与验收记录 | 换装、锚点图与字体规格未定 | 相关规格确认后再制作和验收受影响素材 |
+| 03 | ck-001 已有数据检查通过 | 容量与公共索引定义缺口 | 补齐后重验受影响的数据与接口 |

-当前无任何 blocker：填数（03）、扩产（02）、v0.1 联调（01）三线并行合法。B 级第 1 条（背包容量）在 v0.1 存档实现前必须收口，否则冻结存档模块。
+以上缺口解决且施工所需信息完整后，才能将当前范围标为“只凭 TDD 可实施”。
@@ -1,6 +1,7 @@
 # 技术实现：《星露谷物语》（TDD 金样 · 技术实现）

 > 状态：reviewed　|　基于 GDD：架构层@v3 + P0 系统文档@v1（收编）　|　数据侧契约：data/contracts@v2
+> 本例仍有背包容量和体力规则等关键缺口，尚不能作为当前范围的完整施工依据；相关暂定内容需解决后更新正文。
 > **目标运行时：HTML**（由 GDD 平台事实锁定；本项目按浏览器平台事实执行）
 > 平台事实：双视口（桌面/移动）· 键鼠/触屏双输入 · 本地 HTTP 预览
 > 实证数字来源：星露谷 1.6.15 反编译知识库 v3（快照 stardew-1.6.15-7f1e5b8e，2026-09-11）；写新项目时替换为本项目数值。
@@ -124,9 +125,9 @@

 | 项 | 规定 | 依据 |
 |---|---|---|
-| 瓦片地图结构 | 16px 网格；农场 80×65、小镇 50×40、矿井按层生成 | 台账 D-05（区域分场景，非连续地图） |
+| 瓦片地图结构 | 16px 网格；农场 80×65、小镇 50×40、矿井按层生成（是否纳入本期尚待确认） | 各区域独立场景，通过连接点切换，不构建连续地图 |
 | 镜头 | 跟随玩家+边界钳制；无缩放（固定整数倍） | GDD 顶层（无镜头玩法） |
-| 场景切换 | 农场↔小镇↔矿井走连接点淡入淡出 ≤1s | 概念 D-05 定案"分区域切换" |
+| 场景切换 | 农场↔小镇↔矿井走连接点淡入淡出 ≤1s | 分区域加载，限制单次加载范围 |
 | 关卡数据 | `data/maps/*.json`（自定义 JSON：层/网格/对象点） | 契约 v2 |

 ## 输入与操作
@@ -163,10 +164,12 @@
 | v0.2 | 矿井+战斗（S06）+成长（S08） | 矿井进出一次、遭遇一场、掉落入账、经验到 1 级（累计 100xp） |
 | v0.3 | NPC+任务+商店（S09/S10/S11） | 修路任务全链可交付并解锁洒水器配方 |

-## 开放问题回执
+## 待解决问题

-| # | 问题 | 去向 |
+| 问题 | 影响 | 下一步与需更新的正文 |
 |---|---|---|
-| 1 | 背包格子还是重量容量（影响存档与 UI 结构） | → 概念层决策卡（B 级阻断，台账 D-15） |
-| 2 | 矿井逐层生成是否本期做 | → 台账代决（建议 P2，GDD 已标"不做无限地牢"；台账 D-16） |
-| 3 | 体力是否与战斗共享单池 | → 台账 D-14（B 级待拍，暂按共享实现） |
+| 背包采用格子还是重量容量 | 决定物品容器、存档和 UI 结构 | 与用户确认后补齐 S07 行为规格、UI 交互规格及数据分册中的容量字段；目前的格子制是暂定方案 |
+| 矿井逐层生成是否纳入本期 | 影响地图结构与关卡数据，当前方案倾向延期 | 确认本期范围与地图实现方式，再更新场景与镜头、关卡数据及版本里程碑 |
+| 体力是否与战斗共享单池 | 影响 S02、战斗成本及恢复规则 | 与用户确认后补齐相关系统行为规格和数据定义；目前共享单池是暂定方案 |
+
+问题解决后将实际采用的规则写入对应正文，检查关联分册并移出待办；这些记录不能代替施工规格。
@@ -75,9 +75,11 @@ description: 写"美术圣经"（美术侧）分册时使用。与总纲（技
 →运行时截图验收→**通过后才批量扩产**。验收判据写行为：桌面与移动视口
 下阵营/状态/反馈是否一眼可辨。

-### 6. 开放问题回执
-视觉与玩法冲突、素材成本超预算（面数/张数/工时）、锚点两难——全部走
-回执：问用户的升级决策卡，代决的记台账。
+### 6. 未决问题与待办
+视觉与玩法冲突、素材成本超预算（面数/张数/工时）、锚点两难等未决问题，
+记明影响和下一步；涉及产品取舍时请用户确认并同步 GDD。解决后把完整规格
+补入本圣经与资产清单，关闭待办。影响当前素材施工的关键问题未解决时，
+不宣称该范围已完备。

 ## 四、写完自查（参考，不是闸门）

@@ -74,7 +74,8 @@ draft 调试可见/两 disabled 不加载、deprecated 留 ID 占位防复用）
 种子，防读档刷结果。

 ### 6. 数值填充与验算
-结构定稿后才填数。每项代决记台账（默认值+依据+推翻条件）。**前五日
+结构定稿后才填数。实际数值、单位、适用范围和默认值写在本册配表与字段
+契约中；重要取舍按需记分析。**前五日
 闭环验算必做**：按架构统一数值基准排五日表（主目标/关键行动/成本/获得/
 结果），加收益链校验（`区域→敌人→材料→配方→产出`逐环引 ID）——验算
 结论写回：第 1 日不要求做完、奖励多元不单一、第 5 日出现取舍但仍留两条
@@ -85,7 +86,8 @@ draft 调试可见/两 disabled 不加载、deprecated 留 ID 占位防复用）
 （对话/提示/图鉴文案）逐行填满。这是"纯看 TDD 做完游戏"的数据前提：
 程序加载表即得完整内容，不再回 GDD 找"这里应该有 8 种作物"。验收在七查
 之外加第八查——**内容完成度**：每表计划行数 vs 实填行数，缺口列清单回填；
-填数每项代决记台账。文本表由文本系统文档的文案收编（带版本锁）。
+未决的填充缺口记明影响和下一步，解决后补齐配表并关闭待办。文本表由文本
+系统文档的文案收编（带版本锁）。

 ### 7. 验收（七查+三级）
 主键/引用/枚举/单位/范围五查必须过；业务规则/重复归属两查需设计师复核。
@@ -104,5 +106,5 @@ note 不阻断。验收记录表留 check_id 与 data_version。**结构、规
 ## 五、红线（承总纲四条，本件特化）

 1. 表里不写散文；规则进契约文档。
-2. 数值填充的每个代决都进台账，无痕改数=违规。
+2. 数值变更同步更新本册配表、字段契约和受影响的验算；重要取舍按需记分析，不以外部台账替代施工数据。
 3. 有 blocker 不许扩内容——没有例外。
@@ -15,7 +15,7 @@ description: 写"技术实现"（程序侧）分册时使用。与总纲（技

 - **自包含**：TDD 开头"来自 GDD 的功能"节必带——读者不回翻 GDD 就能开工。
 - **平台事实置顶且禁改**：自包含 Web、双视口、键鼠+触控、本地 HTTP 预览。
-  一切技术选择先过这道闸；GDD 里出现平台做不到的需求，回执上报，不硬做。
+  一切技术选择先过这道闸；GDD 里出现平台做不到的需求，记明问题、影响与下一步，涉及产品取舍时请用户确认，不硬做。
 - **能力边界说三态**：native（原生支持）/ emulated（需模拟封装）/ gated
  （本期不做，写明替代方案）——程序侧不许答应 GDD 做不到的事。
 - **性能预算是基准不是完美**：每项指标写上限、写测量方式，当取舍依据用，
@@ -69,8 +69,9 @@ HTML 的 Canvas/WebAudio/localStorage）、**自封装**（基础 API 上自己
 实现类需求先查可复用能力；记录来源、适用版本与实例化参数；没有现成能力时写明来源与理由。

 ### 7. 场景与镜头 / 输入与操作 / 音频
-三节各一张表：场景（tilemap 结构/镜头行为，代决记台账）；输入（动作×
-键盘×触控对照）；音频（用途×格式规格×触发点×依据）。
+三节各一张表：场景（tilemap 结构/镜头行为，规格和参数写全）；输入（动作×
+键盘×触控对照）；音频（用途×格式规格×触发点×依据）。各项实现默认值
+也写在对应正文，重要取舍按需记分析，不让施工方依赖外部台账。

 ### 8. 构建与验证
 构建流程 + 验证分级：自动（什么命令、什么输出为过）、半自动（双视口
@@ -88,6 +89,6 @@ HTML 的 Canvas/WebAudio/localStorage）、**自封装**（基础 API 上自己

 ## 五、红线（承总纲四条，本件特化）

-1. 平台事实禁改；与 GDD 冲突走回执，不就地硬做。
+1. 平台事实禁改；与 GDD 冲突时说明影响和下一步，涉及产品取舍时请用户确认并同步 GDD。
 2. 可复用能力引用必带版本与参数。
 3. 里程碑判据不许写"基本""大致""感觉"。
@@ -45,7 +45,7 @@ description: 写游戏策划案（GDD）系统架构时使用。在顶层设计

 | # | 节 | 是什么 | 为什么写 | 和谁咬合 |
 |---|---|---|---|---|
-| 1 | 架构定位与目标 | 阶段边界（定哪些系统、不展开内部）+ 划分原则 + 一句话架构 + **变更记录** | 防止架构漂离顶层；改刀可追溯 | 承顶层定稿；变更记录引登记编号 |
+| 1 | 架构定位与目标 | 阶段边界（定哪些系统、不展开内部）+ 划分原则 + 一句话架构 + **变更记录** | 防止架构漂离顶层；改刀可追溯 | 承顶层定稿；必要时引用相关分析 |
 | 2 | 系统地图 | Sxx 编号清单（=系统文档范围真源）+ 支撑层 + P0 段五列表（目的/输入/输出/P0原因） | 编号让系统可引用；P0 原因逼答"删了塌什么" | **对下真源**：Sxx ↔ 04 系统文档一一对应 |
 | 3 | 系统职责 | 职责表（负责/不负责→移交谁）+ 逐系统说明段 | 边界写死，防两个系统管同一件事 | 系统文档的"边界与非目标"必须与此对齐 |
 | 4 | 依赖与数据流 | 依赖图（无环）+ 数据流图 + 主要状态 + 主数据归属规则 | 谁读谁、数据从哪到哪——接口的真源 | 顶层的资源流图在此展开成系统级 |
@@ -84,7 +84,7 @@ description: 写游戏策划案（GDD）系统架构时使用。在顶层设计
 本阶段确定"哪些系统支撑一轮玩法"，不展开单系统内部规则。
 划分原则：__。一句话架构：
 > （玩家通过哪些系统、以什么因果，把一轮玩法的输入变成下一轮的选择）
-变更记录：日期 + 改了什么 + 为什么（引登记编号）。
+变更记录：日期 + 改了什么 + 为什么，必要时引用相关分析。
 → 没有变更记录的架构文档，第二轮迭代就会变成黑箱。

 ### 2. 系统地图
@@ -137,24 +137,10 @@ P1/P2 可用能力表（能力/说明）控制颗粒度。
 ### 12. 开放的结构问题
 → 结构级（接口归属/统一格式/合并拆分）才留这里；数值细节不留。

-## 五、分析文档（全局一份，按层分节）
+## 五、分析参考

-**全局共用 `project/analysis.md`**：论证按发生层归节，决定登记表全项目共用，
-跨层引用查这里。模板与例子：资源 `templates/analysis.md`、
-`templates/stardew-analysis.md`。已决论证与登记写入分析文档，
-灵感池、代决、待原型等活队列写入决策台账。
-
- 条目格式：`## 问题：<一句话>` ＋ 状态（agent_proposal / user_confirmed /
-  superseded，登记 D-__）＋ 广度分析（牵动面＋候选 ≥2）＋ 深度分析
-  （逐候选利弊依据，必须引 T 原则/锚点/张力编号，写不出依据的偏好不进分析）
-  ＋ 综合判断（建议取 __ 因为 __；推翻条件：__）。
- 分诊三条件全满足才进：① 影响项目方向或边界；② ≥2 合理候选；③ 一时定不了。
-  不满足的：就地小权衡直接进登记表一行，不写条目。
- 本层标准问题：结构级争议——接口统一、系统归并、主数据归属划分。
- 数量纪律：按需；架构期问题多为接口与归属二义。
- user_confirmed 后三件事：结论一句话迁入 design.md 对应节（留修订痕迹）；
-  登记表加行（编号全项目连续，跨层引用写 D-__）；本条目改状态记 D 号保留不删。
-  推翻时新增行挂旧行编号，旧行不删。
+可关注系统拆分、接口和数据归属中的重要争议。
+按需参考 `templates/analysis.md` 和 `templates/stardew-analysis.md`。


 ## 六、自查参考
@@ -115,24 +115,10 @@

 若某节对本项目没意义，直接省略。

-## 五、分析文档（全局一份，按层分节）
+## 五、分析参考

-**全局共用 `project/analysis.md`**：论证按发生层归节，决定登记表全项目共用，
-跨层引用查这里。模板与例子：资源 `templates/analysis.md`、
-`templates/stardew-analysis.md`。已决论证与登记写入分析文档，
-灵感池、代决、待原型等活队列写入决策台账。
-
- 条目格式：`## 问题：<一句话>` ＋ 状态（agent_proposal / user_confirmed /
-  superseded，登记 D-__）＋ 广度分析（牵动面＋候选 ≥2）＋ 深度分析
-  （逐候选利弊依据，必须引 T 原则/锚点/张力编号，写不出依据的偏好不进分析）
-  ＋ 综合判断（建议取 __ 因为 __；推翻条件：__）。
- 分诊三条件全满足才进：① 影响项目方向或边界；② ≥2 合理候选；③ 一时定不了。
-  不满足的：就地小权衡直接进登记表一行，不写条目。
- 本层标准两问：① 什么是本项目不可替代的核心承诺；② 什么内容扩张会稀释它。
- 数量纪律：概念期问题通常 ≤3；开始堆第 4 问时先怀疑概念层没想清楚，重读定调记录而不是继续开新争议。
- user_confirmed 后三件事：结论一句话迁入 design.md 对应节（留修订痕迹）；
-  登记表加行（编号全项目连续，跨层引用写 D-__）；本条目改状态记 D 号保留不删。
-  推翻时新增行挂旧行编号，旧行不删。
+可关注核心体验的取舍，以及哪些范围扩张会稀释它。
+按需参考 `templates/analysis.md` 和 `templates/stardew-analysis.md`。


 ## 六、自查参考
@@ -3,7 +3,7 @@
 ---
 name: game-gdd-system-doc
 description: 写单个系统的设计文档（Sxx）时的总纲——通用纪律、十二类常见内容、
-  红线与分析文档格式。每类系统的专属写法与模板在 modules/system-types/ 下对应目录的 SKILL.md
+  红线与分析参考。每类系统的专属写法与模板在 modules/system-types/ 下对应目录的 SKILL.md
  与对应模块的模板.md 里，按需取用。
 ---

@@ -19,7 +19,7 @@ description: 写单个系统的设计文档（Sxx）时的总纲——通用纪
 ## 一、这一层的判断立场
 你是写单个系统的策划。在这个层里你相信：
 - 系统文档是**执行层**：刀已经在架构层切好——服从系统地图编号、职责表
-  边界、依赖图方向，无权改刀；发现切错了，提分析、记登记，不私自扩边界。
+  边界、依赖图方向，无权改刀；发现切错了，说明问题并提出调整建议，不私自扩边界。
 - 一个系统文档的成败在**边界节**："不负责什么、移交给谁"那几行是
  防返工价值最高的几行。
 - 接口纪律：引用具名系统与具名数据，禁泛称；别家主数据只引 ID 不复制。
@@ -72,24 +72,10 @@ description: 写单个系统的设计文档（Sxx）时的总纲——通用纪
 11 边界与非目标：参考该类型系统写法的“三不”说明边界；建议说明字段与数值的交接边界。
 12 开放问题：结构级才留；手感数值类标"待原型验证"。

-## 五、分析文档（全局一份，按层分节）
+## 五、分析参考

-**全局共用 `project/analysis.md`**：论证按发生层归节，决定登记表全项目共用，
-跨层引用查这里。模板与例子：资源 `templates/analysis.md`、
-`templates/stardew-analysis.md`。已决论证与登记写入分析文档，
-灵感池、代决、待原型等活队列写入决策台账。
-
- 条目格式：`## 问题：<一句话>` ＋ 状态（agent_proposal / user_confirmed /
-  superseded，登记 D-__）＋ 广度分析（牵动面＋候选 ≥2）＋ 深度分析
-  （逐候选利弊依据，必须引 T 原则/锚点/张力编号，写不出依据的偏好不进分析）
-  ＋ 综合判断（建议取 __ 因为 __；推翻条件：__）。
- 分诊三条件全满足才进：① 影响项目方向或边界；② ≥2 合理候选；③ 一时定不了。
-  不满足的：就地小权衡直接进登记表一行，不写条目。
- 本层标准问题：① 本系统与相邻系统的边界在哪；② 本系统内部哪个规则影响顶层取舍。条目标系统号（如 S06）。
- 数量纪律：按需；每系统通常 0~1 条，超了先回读架构职责表。
- user_confirmed 后三件事：结论一句话迁入 design.md 对应节（留修订痕迹）；
-  登记表加行（编号全项目连续，跨层引用写 D-__）；本条目改状态记 D 号保留不删。
-  推翻时新增行挂旧行编号，旧行不删。
+可关注本系统与相邻系统的边界，以及影响玩家选择的关键规则。
+按需参考 `templates/analysis.md` 和 `templates/stardew-analysis.md`。


 ## 六、自查参考
@@ -101,6 +87,6 @@ description: 写单个系统的设计文档（Sxx）时的总纲——通用纪

 ## 七、红线（只有三条）
 1. 不冒充用户决定：用户没说的方向标"待确认"，正文不写死。
-2. 不越层：不翻架构的案（要改走分析文档+登记表），不写字段数值（归 TDD），
+2. 不越层：架构需要调整时先说明影响，不写字段数值（归 TDD），
  不替别的系统定规则。
 3. 不凑数：写不出"删了塌什么"的系统直接删除；章节对项目有意义但信息不足时，记录已确定内容与待补问题。
@@ -52,10 +52,12 @@ GDD 是设计真源（给人看、给迭代看）；TDD 是构建真源（给施
 | 定调记录（参照/滑杆/T 原则）+ 身份基调 | 概念层 | 美术圣经（视觉翻译源头） |
 | 可复用能力 | 能力库 | 程序侧+美术圣经（带版本与实例化参数） |

-TDD 不回头改 GDD：发现 GDD 没写清楚的点，走「开放问题回执」——该问用户
-的升级决策卡，该代决的记台账（带理由和推翻条件），结论回写对应层，TDD 只
-登记去向。顾问期（开发阶段）同一出口：程序美术卡点、成品与文档偏差，都从
-回执进、修订出（v{N+1}）。
+TDD 不擅自改 GDD：发现 GDD 没写清楚的产品取舍，向用户确认并同步 GDD；
+技术实现中的规格、参数和默认值直接写完整在对应 TDD 正文。重要取舍可按需
+记录分析，但外部决策台账不是施工信息来源。尚未解决的问题记入对应分册的
+待办，写明问题、影响和下一步；解决后补齐正文并关闭待办。顾问期（开发阶段）
+遇到程序美术卡点或成品与文档偏差，也按此更新对应文档版本（v{N+1}）。
+影响当前实现的关键问题未解决时，不宣称该范围的 TDD 已完备。

 ## 三、三大件与开工顺序

@@ -73,7 +75,7 @@ GDD 喂的（系统文档交接节就是订单）；程序侧的加载与验证
 ## 四、怎么写（总纲级；细节在各分册）

 1. 数据侧：总清单拆表 → ID 与字段字典 → 公共条件表 → 建表顺序（物品表
-   起步）→ 表结构契约（程序签名）→ 数值填充（代决+台账）→ 验收七查。
+   起步）→ 表结构契约（程序签名）→ 数值填充（完整值与默认值）→ 验收七查。
 2. 程序侧：系统实现总览（每系统一段话写死怎么做）→ 技术选型与可复用能力引用
   → 场景与镜头 → 输入与操作 → 音频 → 验证方式与性能预算。
 3. 美术圣经：视觉锚（从概念层定调翻译）→ 素材规格契约逐素材一行 →
@@ -90,9 +92,9 @@ GDD 喂的（系统文档交接节就是订单）；程序侧的加载与验证
 ## 六、红线（只有四条）

 1. **收编必带版本锁**：从 GDD 收编的任何内容标注"基于系统文档@v{N}"；
-   无锁收编=违规（双源漂移之源）。TDD 不产生设计观点，只汇集与落实施工。
+   无锁收编=违规（双源漂移之源）。TDD 不擅自新增产品设计，只汇集与落实施工。
 2. 引用必带版本：可复用能力引用必须记录版本与实例化参数，选型时与执行时用的一致性靠此保证。
-3. 不越权拍板：产品级取舍回 GDD 层走决策流程；TDD 只做技术代决且记台账。
+3. 不越权拍板：产品级取舍由用户确认并同步 GDD；技术实现的完整结论写在 TDD，重要取舍按需记分析。
 4. 表里不写散文：单元格只有数据和枚举；规则写在契约文档，不写在表里。


@@ -160,24 +160,10 @@ __（多短一段玩法体现独有乐趣——原型只做这一个单位）。

 若某节对本项目没意义，直接省略。

-## 五、分析文档（全局一份，按层分节）
+## 五、分析参考

-**全局共用 `project/analysis.md`**：论证按发生层归节，决定登记表全项目共用，
-跨层引用查这里。模板与例子：资源 `templates/analysis.md`、
-`templates/stardew-analysis.md`。已决论证与登记写入分析文档，
-灵感池、代决、待原型等活队列写入决策台账。
-
- 条目格式：`## 问题：<一句话>` ＋ 状态（agent_proposal / user_confirmed /
-  superseded，登记 D-__）＋ 广度分析（牵动面＋候选 ≥2）＋ 深度分析
-  （逐候选利弊依据，必须引 T 原则/锚点/张力编号，写不出依据的偏好不进分析）
-  ＋ 综合判断（建议取 __ 因为 __；推翻条件：__）。
- 分诊三条件全满足才进：① 影响项目方向或边界；② ≥2 合理候选；③ 一时定不了。
-  不满足的：就地小权衡直接进登记表一行，不写条目。
- 本层标准两问：① 一天/一局怎样形成清楚但不拖沓的循环；② 风险、收益与长期成长怎样互相支撑。
- 数量纪律：顶层期问题通常 ≤5（结构性争议天然更多）；堆问题时先回读第 1 节定位句。
- user_confirmed 后三件事：结论一句话迁入 design.md 对应节（留修订痕迹）；
-  登记表加行（编号全项目连续，跨层引用写 D-__）；本条目改状态记 D 号保留不删。
-  推翻时新增行挂旧行编号，旧行不删。
+可关注一局玩法的节奏，以及风险、收益与长期成长如何相互支撑。
+按需参考 `templates/analysis.md` 和 `templates/stardew-analysis.md`。


 ## 六、自查参考
@@ -1,41 +1,11 @@
-### C1 模板_分析.md（全局一份；→ templates/analysis.md）
-
 # 分析：《游戏名》

-> **全局唯一一份分析文档**：论证按发生层归节；决定登记表全项目共用，跨层引用只查这里。
-> 论证按发生层归节；决定登记表全项目只此一张，跨层引用只查这里。
-> 状态池（灵感池/代决/待原型等"活的"队列）在决策台账，不放本文件——本文件管已决的档案。
-> 仅记录值得跨轮保留的重要问题；普通讨论、临时灵感和完整对话不写入。策划提案不等于用户确认。
+按需记录影响后续设计的重要取舍。可按问题或主题组织，简单问题几句话即可，复杂问题再展开比较；不必预建各阶段的空章节。

-## 概念期问题（通常 ≤3 条）
+下面仅是条目的参考写法，可合并或省略不需要的部分：

-## 问题：__（一句话）
-状态：agent_proposal / user_confirmed / superseded（登记 D-__）
- 广度分析：牵动面（波及哪些锚点/张力/节）＋ 候选方向（≥2）
- 深度分析：逐候选 利/弊/依据（必须引定调记录 T 原则、锚点、张力编号或参照资料，写不出依据的偏好不进分析）
- 综合判断：建议取 __，因为 __。推翻条件：__。
+## 问题：__

-## 顶层期问题（通常 ≤5 条）
+背景与主要依据：__。

-（同上格式）
-
-## 架构期问题
-
-（同上格式；本层不写独立分析文档，结构争议全归此处）
-
-## 系统期问题（按系统号分条，如 S06）
-
-（同上格式）
-
-## 技术文档期问题
-
-（同上格式；复用能力选型分歧、表结构二义等）
-
-## 全局决定登记表
-
-| D# | 决定 | 层 | 权威 | 依据 | 推翻条件 | 状态 |
-|---|---|---|---|---|---|---|
-| D-01 | __ | 概念 | user / agent（代决带理由） | 本文件问题__ / T__ | __ | 已确认/已推翻/待原型 |
-
- 编号全项目连续；跨层引用直接写"D-__"；推翻时新增行挂旧行编号，旧行不删。
- 就地小权衡（不满足分诊三条件的）直接登记一行，不写问题条目。
+当前结论或建议：__。尚未确定的事项及下一步：__。
@@ -1,63 +1,25 @@
-### C1 例子_星露谷_分析.md（分析金样；→ templates/stardew-analysis.md）
+# 分析：《星露谷物语》示例项目

-# 分析：《星露谷物语》
+以下为策划分析的写法示例，不代表原作的真实决策记录。

-> 全局唯一一份分析文档。定调记录（参照/滑杆/T1~T7）在概念层设计文档第 2 节，此处不重复。
-> 状态池在决策台账；本文件只放已决论证与登记。策划提案不等于用户确认。
+## 矿井战斗要不要做成装备驱动的成长主轴？

-## 概念期问题
+本项目以轻松的农场生活和自由安排为主要体验。装备驱动的战斗能增加长期目标，但需要更多装备、敌人和难度设计，也会与农场主轴争夺玩家时间。

-## 问题：矿井战斗要不要做成装备驱动的成长主轴？
-状态：user_confirmed（登记 D-03）
+当前采用战斗作为矿井探索的伴生风险和节奏变化，不做装备驱动主轴。相关定位写入概念设计和架构文档；后续根据试玩反馈评估是否需要调整战斗深度。

- 广度分析：牵动锚点"目标体验"（掌控感与紧张的比例）、"不是什么"表第 3 行、核心张力第 3 条（稳定经营 vs 未知探索）。候选：A 战斗做成装备驱动主轴之一；B 战斗保持伴生风险，深度刻意受限。
- 深度分析：A 利：矿井更耐玩，长期目标多一条。弊：需要装备与难度曲线支撑，时间重量与农场主轴抢位，动摇"治愈"基调（违反 T1）。B 利：保住生活模拟纯度，战斗作为探索的节奏变化存在。弊：战斗型玩家留存偏弱——但受众映射显示目标玩家（牧场物语系）本不以战斗为主诉求。
- 综合判断：建议 B：战斗深度刻意受限，作为矿井探索的风险与节奏变化存在，不做装备驱动主轴。
-  推翻条件：试玩数据中过半玩家在矿井流失且归因于战斗乏味。
+## 每日目标要不要强制？

-## 顶层期问题
+每日固定目标有助于提供方向，但容易形成打卡负担；完全移除时间与体力约束，又会减弱每天安排活动的意义。

-## 问题：一个游戏日怎样保持"想做的事多于做得到的"而不变成打卡负担？
-状态：user_confirmed（登记 D-07）
+当前保留温和的时间与体力约束，日目标由玩家自设，以季节事件和社区修复目标提供较长期的方向。后续通过新手试玩观察玩家是否知道接下来能做什么，再调整引导。

- 广度分析：牵动锚点"目标体验"（掌控感与治愈的配比）、张力第 1 条（时间与体力有限）、节奏结构日内层、失败与回收档位。候选：A 收紧——每日固定目标与奖励；B 放宽——去掉每日压力；C 保留时间/体力约束，目标完全由玩家自设。
- 深度分析：A 利：方向感强。弊：把休闲变成每日打卡义务，直接命中跑偏风险第 2 条（违反 T5）。B 利：最松弛。弊：没有取舍就没有"今天的选择"，张力第 1 条落空。C 利：约束存在但重量自选；节日与季节提供低频外部节拍。弊：部分玩家需要更明确指引——可由社区修复目标与任务系统补位。
- 综合判断：建议 C：时间与体力作为温和硬约束保留，日目标不强制；以季节事件和社区修复目标提供低频牵引。
-  推翻条件：新手引导期数据显示玩家第一周内流失且归因于"不知道该做什么"。
+## 采集、钓鱼与战斗是否共用活动结果接口？

-## 架构期问题
+三类活动都需要把产出交给物品系统。分别定义入账协议会增加公共系统的适配工作，但过度统一也可能掩盖各活动的差异。

-## 问题：采集、钓鱼与战斗要不要共享统一的"活动结果"接口？
-状态：user_confirmed（登记 D-11）
+当前采用统一的活动结果接口，表达结果的身份与去向；掉落、品质和判定规则仍由各活动系统维护。接口与职责已写入对应设计文档。

- 广度分析：牵动 S05/S06 的输出边界、S07 物品系统入账方式、依赖与数据流图活动侧。候选：A 三系统各自定义产出结构；B 统一"活动结果"接口（活动类型+结果列表+条件），三系统只填参数。
- 深度分析：A 利：各系统自由。弊：S07 要维护三种入账协议；任务系统验证"完成了一次采集/战斗"需分别适配——职责表里 S05/S06 的"不负责"列都指向 S07，接口不统一把适配成本堆给公共层。B 利：产出、经验、任务进度走同一条管线，S07 与 S11 只适配一次；新增活动类型不动公共层。弊：接口要预留类型差异（战利品请求/钓鱼品质），设计不当会把差异塞进自由字段。
- 综合判断：建议 B：统一"活动结果"接口，类型差异用明确枚举表达；掉落条件与品质规则仍归各自系统文档定义，接口只承载"结果的身份与去向"。
-  推翻条件：第三种活动类型加入后出现接口无法表达的结构性差异（如双通道产出）。
+## 战斗判定窗口是否需要调整？

-## 系统期问题
-
-## S06：战斗操作深度选哪一档？
-状态：user_confirmed（登记 D-13；手感部分 prototype_pending）
-
- 广度分析：牵动玩家行动动词组、状态与规则的判定方式、顶层规模锚点（操作复杂度=低）、"不是什么"表第 3 行。候选：A 实时轻操作（移动+攻击+闪避）；B 节奏/指令判定（时机窗口确认）。
- 深度分析：A 利：紧张感即时、反馈直接。弊：与顶层"操作复杂度低"直接冲突，敌人一多把轻度风险推成动作压力，动摇治愈基调（T1）。B 利：判定即反馈，压力可通过窗口宽度调节；与"伴生风险"定位相容（D-03）。弊：判定窗口的手感无法纸面验证——需原型。
- 综合判断：建议 B 为设计方向：节奏/指令判定承载轻度战斗；判定窗口手感在登记表标"待原型验证"。
-  推翻条件：原型显示节奏判定拖慢探索节奏，或玩家反馈"按键时机莫名其妙"。
-
-## 技术文档期问题
-
-（TDD 期开放问题走分册"开放问题回执"，B 级两条——背包容量、生命体力共享——收口后论证与登记归此处。）
-
-## 全局决定登记表
-
-| D# | 决定 | 层 | 权威 | 依据 | 推翻条件 | 状态 |
-|---|---|---|---|---|---|---|
-| D-01 | 定调：牧场物语系参照、治愈慢节奏 | 概念 | user | 用户原始需求 | — | 已确认 |
-| D-02 | 单人体验，无多人 | 概念 | user | 概念层非目标 | — | 已确认 |
-| D-03 | 战斗保持伴生风险，不做装备驱动主轴 | 概念 | user | 概念期问题一 | 矿井流失率过半且归因战斗 | 已确认 |
-| D-07 | 日目标自设，季节与社区提供低频牵引 | 顶层 | user | 顶层期问题一 | 新手周流失归因无方向 | 已确认 |
-| D-11 | 采集/钓鱼/战斗统一"活动结果"接口 | 架构 | user | 架构期问题一 | 第三活动类型出现结构性差异 | 已确认 |
-| D-13 | 战斗采用节奏/指令判定；窗口手感待原型 | 系统 | user | S06 问题一 | 原型显示节奏拖慢/玩家困惑 | 已确认（手感 prototype_pending） |
-
-（D-04~D-06、D-08~D-10、D-12 为就地小权衡，直接登记未开条目；编号连续不复用。）
+目前无法仅凭文档判断窗口手感。下一步在矿井原型中观察判定是否易懂、是否拖慢探索；试玩结果出来后再修订规则。
@@ -66,8 +66,10 @@ __（承 UI 系统文档的界面清单；视觉语言与信息分层对齐）
 9. 运行时验收（按项目支持的平台）→ 10. 扩产。
 （以上为示例，可按实际流程删减或扩充。）

-## 开放问题回执
+## 待解决问题

-| # | 问题 | 去向 |
+| 问题 | 对当前素材施工的影响 | 下一步与需更新的正文 |
 |---|---|---|
-| 1 | __ | → 决策卡 / 台账 {id} / 本文档 §__ 修订 |
+| __ | __ | __ |
+
+按需列出；问题解决后补齐正文与素材规格并移出待办。影响当前素材施工的关键问题未解决时，不宣称该范围已完备。
@@ -53,11 +53,11 @@

 ## 数值填充与验算

- 填充代决台账：
+- 实际范围内的全部数据行、字段值、单位和默认值写入本册配表；重要取舍可按需记分析，外部台账不能代替配表。以下用于列出需要明确的字段默认值：

-| 表 | 字段 | 默认值 | 依据 | 推翻条件 |
+| 表 | 字段 | 默认值 | 单位与适用范围 | 说明 |
 |---|---|---|---|---|
-| __ | __ | __ | T__ / 台账 id | __ |
+| __ | __ | __ | __ | __ |
 （以上为示例，可按实际验算字段删减或扩充。）

 - 前五日闭环验算：
@@ -76,3 +76,11 @@
 - 两查复核：业务规则（季节窗口相容、目标有验证系统、奖励一次、配方输入可达）；重复归属（身份/价格/成本/奖励/位置各只有一个写权）。
 - 三级处置：blocker 禁止扩内容；warning 记负责人与计划；note 不阻断。
 - 最近验收结论：__（结构、规则或字段语义一变，受影响链路全部重验。）
+
+## 待解决问题
+
+| 问题 | 对当前配表施工的影响 | 下一步与需更新的正文 |
+|---|---|---|
+| __ | __ | __ |
+
+按需列出；问题解决后补齐正文与配表并移出待办。影响当前实现的关键问题未解决时，本册不能标为 accepted。
@@ -21,7 +21,7 @@
 | 5 | 代码怎么组织、跑在哪？ | 01 代码组织+能力边界 | __ |
 | 6 | 怎么算做完了（判据）？ | 01 里程碑+各件验收 | __ |

-当前项目所需检查全部为"过"时，TDD 进入 frozen——构建可以在本版本范围内脱离 GDD 进行。
+当前项目所需检查全部为"过"，且影响当前实现的关键问题已解决时，TDD 进入 frozen——构建可以在本版本范围内脱离 GDD 进行。

 ## 三件状态

@@ -44,13 +44,13 @@
 | 昼夜/色调 | tint 色值表豁免绑定但拥有者写明 | 02 资产状态表 |
 | 拥有者总则 | 一个事实一个写权：数值事实归 03 各表、生产状态归 02 资产表、技术事实归 01 | 架构层归属规则 |

-## 开放问题回执汇总（三件集中视图）
+## 重要缺口汇总

-| # | 来源件 | 问题 | 去向 | 状态 |
-|---|---|---|---|---|
-| __ | 01/02/03 | __ | 决策卡 / 台账 id / 分册修订 | __ |
+| 相关分册 | 影响当前施工的缺口 | 详细位置 |
+|---|---|---|
+| 01/02/03 | __ | 分册 §__ |

-（B 级阻断项单独置顶；本视图为临时审阅清单，结论回写各分册与台账。）
+只汇总跨分册或影响当前施工的重要缺口，详细问题与下一步在对应分册维护。解决后补齐分册正文并移出本汇总，不向全局台账重复登记。

 ## 验收总状态

@@ -66,7 +66,7 @@

 ## 场景与镜头

-| 项 | 规定 | 依据（台账/代决） |
+| 项 | 规定（含完整规格与参数） | 依据或说明 |
 |---|---|---|
 | tilemap 结构 | __（尺寸/tile 大小/层数及用途） | __ |
 | 镜头行为 | __（跟随/边界/变化） | __ |
@@ -94,3 +94,11 @@
 | 版本 | 内容 | 判据 |
 |---|---|---|
 | __ | __ | __ |
+
+## 待解决问题
+
+| 问题 | 对当前实现的影响 | 下一步与需更新的正文 |
+|---|---|---|
+| __ | __ | __ |
+
+按需列出；问题解决后补齐正文并移出待办。影响当前实现的关键问题未解决时，本册不能标为 frozen。
@@ -3,13 +3,13 @@

 优先完成能够依据已有信息推进的工作。局部、可逆的问题可以先提出合理方案并标为暂定。会影响当前阶段范围、关键规则、下游实现或其他重要方向，且必须由用户决定的问题，应先通过纯文本或问询工具询问，等待用户回答。决定稳定后，再更新受影响的正式产物和必要的过程记录，并完成阶段审批前的检查。

-分析阶段优先记录当前目标、上层约束、候选方案、取舍、用户已确认或 Agent 暂定的边界，以及必须检查的验收项。形成结论后直接写入正式产物，再进行一次必要的一致性检查；按用户要求展开讨论。文件操作前只需说明简短计划、目标文件和主要变化。
+分析围绕当前目标和约束展开，存在值得比较的方案时再展开比较。形成结论后更新受影响的正式产物，再进行一次必要的一致性检查；按用户要求展开讨论。文件操作前只需说明简短计划、目标文件和主要变化。

 正式策划文档在文档头部写明版本标记，例如“版本：v1”。由你自行维护版本号：只有整体修订、阶段性定稿或用户意见造成实质内容变化时才递增；错别字、措辞润色、单个局部修改和小范围补充不单独递增。

 阶段审批是五个策划阶段各自的最终检查，将已完成的本阶段产物交给用户检阅。需要用户选择的关键问题先通过问询解决，阶段审批不承担问询功能。提交前，解决所有影响本阶段完成的关键问题，或明确说明它们不阻塞本阶段交付，并更新相关产物。可以保留不阻塞当前阶段的后续事项和待原型验证项。

-过程文档用于记录关键依据、决定和待办，不要求实时完整，也不应重复正式设计文档。阶段内优先完成主要设计内容；只有稳定且影响后续工作的决定才需要同步到多个过程文档。阶段提交前，补齐影响验收的关键记录。
+共享文档按用途和内容变化维护，不逐轮更新或重复登记同一决定。分析文档按需保留重要取舍的依据与当前结论；待办变化时更新决策台账，完成后移出待办；对话摘要或交接记录仅在用户需要时维护；速览卡只在概览内容变化时更新。可以合并、修订条目，只保留理解当前决定所需的历史依据。未决事项说明原因或下一步，不要求固定状态、连续编号、候选数量或每项推翻条件。阶段提交前检查影响交付的信息是否一致。

 阶段获批后，产物中已经采用的方案作为后续工作的依据，并保留原有决策来源。用户主动质疑或出现新的约束冲突时，再重新讨论相关决定。

@@ -1,5 +1,11 @@
 # 决策记录

+## 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"的拦截天然把键盘菜单留给原有节点菜单路径。
--- a/Show More
+++ b/Show More