简化架构层规则与下游文档衔接

按职责与协作重写架构规则、模板和样例，取消固定数量、P0 必需性与无环硬要求明确权威数据归属及系统文档映射，区分策划文档目录与实现代码组织同步系统规则、类型资料与 TDD 引用，保留当前施工范围的自足性要求对齐星露谷首个原型、速览卡与 TDD 样例，列明基础采集、跨日结算和验算缺口更新策划技术方案与共享决策记录
2026-09-27 16:57:48 +00:00
parent 89a901e329
commit 35c0859ae8
17 changed files with 243 additions and 519 deletions
@@ -36,20 +36,23 @@ Web 浏览器运行 · 双视口（桌面/移动）· 键鼠/触屏双输入 ·
 ## 9. MVP 系统（本例首期范围）
 | 系统 | 最小功能 | 为什么必须有 | 验证方法 |
 |---|---|---|---|
-| 时间与日程 | 时钟/日终结算/季节天气 | 全局节拍器 | 一个游戏日全流程可完成并结算 |
-| 体力与状态 | 单池体力/昏倒惩罚 | 一切取舍的成本源 | 玩家主动在体力耗尽前收手 |
-| 农场经营 | 锄种浇收+加工队列 | 核心产出与规划场 | "买种→收获→出售"闭环成立 |
-| 物品与制作 | item_id/背包/配方解锁 | 资源身份与转化 | 拾取/堆叠/制作全链无回翻 GDD |
-| 经济与商店 | 基准价+价差+出货箱 | 投资回报换算 | 第 4 日现金流回正（前五日验算） |
+| 时间与日程 | 时钟、天气、日终协调与跨日推进 | 组织日常活动 | 单日行动与多日状态持续一致 |
+| 体力与状态 | 行动成本、休息恢复 | 支持日常计划与取舍 | 结合行动调整和玩家反馈判断压力 |
+| 农场经营 | 耕种、浇水、生长与收获 | 核心产出与规划场 | 连续数日完成生长、收获与再投资 |
+| 探索与地图 | 农场、小镇与基础采集区域 | 支持外出和活动选择 | 移动、出入口与资源点状态正确 |
+| 采集与钓鱼 | 本期基础采集，钓鱼后续加入 | 提供农场外的资源来源 | 采集结果正确入账且不重复领取 |
+| 物品与制作 | 本期物品身份、背包与工具使用 | 连接活动成果与投资 | 拾取、消耗及存读档结果一致 |
+| 成长与技能 | 基础农务或采集成长 | 为后续活动提供目标 | 多日成果产生可理解的能力变化 |
+| 经济与商店 | 买种、出售与基础投资 | 连接产出与后续投入 | 收益可用于下一轮活动，具体节奏待验算与试玩 |

 ## 10. 制作边界 ←概念层「边界与约束」
 不做：硬核生存（无饥饿/债务/死亡惩罚）；效率至上的工厂经营；以战斗为核心的动作游戏；剧情驱动的任务链主线；多人竞争；无边界开放世界（区域小网络全步行可达）。

 ## 11. 创作者提示（本例原型验证安排）
- 先做：第 1 日循环（买种→播种→浇灌→收获→出售→日终结算）＋一个可进入的矿井遭遇。
+- 先做：单日农务与基础采集，继续数日覆盖作物生长、收获、出售、投资和基础成长，包含必要的 UI 与存读档。
 - 暂不做：装备刷取、随机构筑、复杂剧情、节日全量、联机。
- 这样验证：测试者玩完第 1 日后是否主动说"再玩一天"；能否说出"明天要先做什么"。
- 达标再扩展：玩家能自述明日计划后，才加社交深度与矿井分层。
+- 这样验证：结合试玩观察和玩家对选择理由、后续目标的说明，判断是否形成有意义的计划；同时检查资源与跨日状态的一致性。
+- 后续验证：加入一个矿井遭遇，再逐步覆盖关系与社区目标；依据实际问题调整范围，不把能自述计划作为唯一门槛。

 ## 12. 待原型验证项
 - 矿井中的轻度战斗能否提供节奏变化，同时保持探索流畅；通过原型试玩观察判定是否易懂、战斗是否拖慢探索。
@@ -1,200 +1,94 @@
 # 系统架构：《星露谷物语》

-## 架构定位与目标
-本阶段确定"哪些系统支撑一轮玩法"，不展开单系统内部规则。
-划分原则：将生活模拟 RPG 拆成职责清晰、可独立讨论的规则系统，同时保留少量跨系统入口，避免"每个功能都能互相调用"造成架构失控。系统划分服务于顶层循环：安排一天、执行活动、获得进展、投入成长、解锁新选择。
+## 系统与职责

-一句话架构：
-> 玩家在有限的时间与体力下，通过农场、探索与社交三组活动系统产出资源与关系，经物品与经济系统转化为投资，由时间系统推进日终，把一天的成果变成下一天的选择。
+架构承接顶层的农场生活体验：安排一天、执行活动、获得进展、投入成长，再形成后续计划。战斗服务于探索中的风险与节奏变化，不作为装备成长主轴。以下系统覆盖完整版本，首个原型只实现其中必要的能力。

-变更记录：
- 2026-09-05：战斗与敌人系统定为伴生风险定位，深度刻意受限，不进入最小闭环核心链（依据：分析文档“矿井战斗要不要做成装备驱动的成长主轴”）。
-
-## 系统地图
-
-| 编号 | 系统 | 一句话职责 | 优先级 |
+| 编号 | 系统 | 职责与权威维护的状态 | 首个原型范围 |
 |---|---|---|---|
-| S01 | 时间与日程 | 推进游戏时间、日期、季节、天气、营业时间、NPC 日程和日终结算 | P0 |
-| S02 | 体力与状态 | 管理体力、负面状态、恢复、昏倒和行动成本 | P0 |
-| S03 | 农场经营 | 管理土地、作物、畜牧、农场设施和生产状态 | P0 |
-| S04 | 探索与地图 | 管理区域、出入口、可交互资源点、地图解锁和移动 | P0（基础） |
-| S05 | 采集与钓鱼 | 管理野外采集、钓鱼活动、资源品质和获得物 | P1 |
-| S06 | 战斗与敌人 | 管理矿区或危险区域中的战斗、伤害、敌人行为和战利品 | P1 |
-| S07 | 物品、背包与制作 | 管理物品实例、堆叠、工具、装备、配方和制作队列 | P0 |
-| S08 | 成长与技能 | 管理技能经验、等级、工具升级、职业选择和能力解锁 | P0（基础） |
-| S09 | 经济与商店 | 管理货币、买卖、价格、商店库存、订单和资金流 | P0 |
-| S10 | NPC 与关系 | 管理 NPC 日程、对话、好感度、礼物偏好和关系事件 | P1 |
-| S11 | 任务与社区目标 | 管理任务状态、阶段目标、奖励、社区修复和区域解锁条件 | P1 |
-| S12 | 事件与节日 | 管理季节事件、节日活动、条件触发和特殊奖励 | P1 |
+| S01 | 时间与日程 | 时钟、日期、季节、天气，时间通知与日终流程协调 | 基础时间、天气与跨日推进 |
+| S02 | 体力与状态 | 体力、恢复、昏倒和状态效果，处理活动提交的成本 | 农务与采集的行动成本、休息恢复 |
+| S03 | 农场经营 | 土地、作物、畜牧、设施生产状态与生产规则 | 耕种、浇水、生长与收获 |
+| S04 | 探索与地图 | 区域、出入口、角色位置、资源点位置与可用状态，执行移动和区域开放 | 农场、小镇与基础采集区域 |
+| S05 | 采集与钓鱼 | 活动判定、获得物与品质规则 | 基础采集；钓鱼后续加入 |
+| S06 | 战斗与敌人 | 战斗过程、敌人状态、伤害和战利品请求 | 后续矿井遭遇原型 |
+| S07 | 物品、背包与制作 | 物品身份、实例、容器、配方、工具装备及通用制作队列 | 种子、工具、采集物和农产品的持有与使用 |
+| S08 | 成长与技能 | 经验、等级、能力与配方解锁条件 | 基础农务或采集成长 |
+| S09 | 经济与商店 | 货币、价格、交易、库存及营业条件 | 买种、出售与基础投资 |
+| S10 | NPC 与关系 | NPC 日程内容与执行进度、对话、好感和关系事件 | 后续关系原型 |
+| S11 | 任务与社区目标 | 任务状态、奖励、社区进度和区域解锁条件 | 后续社区目标原型 |
+| S12 | 事件与节日 | 节日内容、触发条件、活动流程与完成状态 | 后续节日内容 |

-支撑层（不拥有核心规则）：
- 存档与进度系统：保存跨日、跨季节和跨阶段的持久状态。
- UI 与文本呈现层：展示状态、提供操作入口、呈现反馈与文本。
+存档保存各系统的持久状态并按归属恢复；UI 与文本呈现展示结果、提供操作入口。它们需要实现规格，但不另行维护玩法规则，规格在 TDD 中展开。

-P0 段：
+容易混淆的边界：

-| 系统 | 目的 | 输入 | 输出 | P0 原因 |
-|---|---|---|---|---|
-| S01 时间与日程 | 全局时钟与日终 | 各系统行动完成信号、日终触发 | 日期/季节/天气变化、日终结算、跨天 tick | 没有"一天"，规划与取舍失去标尺 |
-| S02 体力与状态 | 全局行动成本 | 各系统行动请求、食物与休息 | 体力变化、昏倒、状态效果 | 没有它，"想做的事多于做得到的"不成立 |
-| S03 农场经营 | 核心产出与规划场 | 时间 tick、种子与工具、体力 | 作物畜产品、设施生产状态 | 概念核心承诺的载体 |
-| S04 探索与地图 | 活动场景与空间约束 | 移动指令、区域解锁条件 | 位置、区域状态、资源点入口 | 没有空间结构，农/矿/镇一体失去意义 |
-| S07 物品与制作 | 资源身份与转化 | 各系统获得物、配方请求 | 物品实例、制作结果 | 所有系统产出的公共语言 |
-| S08 成长与技能 | 长期回报层 | 各活动经验提交 | 等级、能力与配方解锁 | 长期动机的最小载体 |
-| S09 经济与商店 | 投资与回报换算 | 物品、金钱 | 价格、交易、库存 | 没有它，"变现 vs 投资"张力无载体 |
+- S01 提供时钟与日期，S10 根据自身日程决定 NPC 的目标和行动，通过 S04 执行移动；S09 判断商店是否营业。时间系统不维护另一套居民日程或商店规则。
+- S04 维护资源点的位置和是否仍可采集，S05 判定本次采集的结果；物品入账由 S07 处理，经验由 S08 处理。
+- S03 管理农场设施的生产状态，S07 管理背包与通用制作。共用配方时引用同一配方定义，不各自复制材料与产出规则。
+- S11 判断社区目标是否满足解锁条件，S04 维护实际开放的区域；S08 管理技能解锁，S07 据此判断配方或工具能否使用。

-## 系统职责
+## 协作与数据归属

-| 系统 | 主要职责 | 不负责 → 移交谁 |
-|---|---|---|
-| S01 时间与日程 | 时间推进、日期、季节、天气、营业与日终 | 直接决定某项活动的奖励 → 各活动系统 |
-| S02 体力与状态 | 行动消耗、恢复、昏倒、状态效果 | 农作物或敌人的具体配置 → S03/S06 |
-| S03 农场经营 | 土地、作物、畜牧、设施生产 | 商店买卖规则和角色技能 → S09/S08 |
-| S04 探索与地图 | 区域连接、进入条件、资源点位置、移动 | 具体掉落概率和战斗公式 → S05/S06 |
-| S05 采集与钓鱼 | 采集和钓鱼行为、成功条件、获得物 | 物品价格和任务奖励 → S09/S11 |
-| S06 战斗与敌人 | 战斗流程、敌人状态、伤害与战利品请求 | 角色长期成长和商店价格 → S08/S09 |
-| S07 物品与制作 | 背包、物品、配方、制作与工具装备 | 物品最终经济价值的平衡目标 → S09 |
-| S08 成长与技能 | 经验、等级、技能分支、能力解锁 | 单次行动的基础奖励 → 各活动系统 |
-| S09 经济与商店 | 货币、交易、库存、订单、价格 | 任务剧情与 NPC 情感变化 → S10/S11 |
-| S10 NPC 与关系 | 日程、互动、好感、关系事件 | 全局季节推进和商店库存 → S01/S09 |
-| S11 任务与社区 | 目标、前置、奖励、社区进度和解锁 | NPC 的日常行为表现 → S10 |
-| S12 事件与节日 | 周期事件、特殊流程和限定内容 | 常规日常行动的基础规则 → 各活动系统 |
+以下表格描述行动处理和通知，不把所有关系混成同一种依赖箭头。

-职责说明：
-
-### S01 时间与日程系统
-负责一天制的节奏规则：什么时候推进日期、哪些系统收到跨天 tick、日终结算何时发生。它不负责奖励结算，也不负责作物成长规则——只负责"什么时候"和"谁被通知"。
-
-### S06 战斗与敌人系统
-负责战斗内状态、敌人行为与战利品请求。它不直接修改商店价格或 NPC 好感，不负责角色长期成长；战利品只提交请求，由 S07 物品系统入账。定位是矿井探索的风险与节奏变化，不是成长主轴，依据见分析文档中的矿井战斗取舍。
-
-### S07 物品、背包与制作系统
-负责物品身份、容器、堆叠与配方队列。它是全项目的公共语言层——任何系统的产出都以 `item_id` 入账；它不负责物品的经济价值平衡，价格只由 S09 维护。
-
-## 依赖与数据流
-
-```mermaid
-flowchart TD
-  S1[S01 时间与日程] --> S2[S02 体力与状态]
-  S1 --> S3[S03 农场经营]
-  S1 --> S4[S04 探索与地图]
-  S1 --> S10[S10 NPC 与关系]
-  S1 --> S12[S12 事件与节日]
-  S3 --> S7[S07 物品与制作]
-  S4 --> S5[S05 采集与钓鱼]
-  S4 --> S6[S06 战斗与敌人]
-  S5 --> S7
-  S6 --> S7
-  S7 --> S9[S09 经济与商店]
-  S7 --> S8[S08 成长与技能]
-  S8 --> S7
-  S10 --> S11[S11 任务与社区]
-  S12 -.读取日期季节.-> S1
-  UI[UI 与文本呈现] -.读取状态.-> S1
-  UI -.读取状态.-> S3
-  UI -.读取状态.-> S7
-  SAVE[存档与进度] -.订阅持久状态.-> S1
-```
-
-```mermaid
-flowchart LR
-  T[时间/体力] --> ACT[玩家行动]
-  ACT --> GAIN[物品·金钱·经验·关系·任务进度]
-  GAIN --> INV[制作·交易·升级·解锁]
-  INV --> NEW[新的行动选择]
-  NEW --> ACT
-```
-
-主要状态：
- 全局状态：日期、季节、天气、当前时间、已解锁区域、社区进度。
- 玩家状态：位置、体力、生命、技能等级、工具、装备、背包和金钱。
- 场景状态：土地、作物成长、设施生产、资源点、敌人和宝箱。
- 社会状态：NPC 位置、关系值、已触发事件、任务阶段和节日参与状态。
-
-主数据归属规则：
- 规则文档描述"如何计算"和"何时发生"；数据表描述"有哪些对象"和"每个对象的配置"。
- 系统之间通过稳定 ID 关联（物品 ID、NPC ID、区域 ID、任务 ID、配方 ID）。
- 任何系统都不复制另一系统的主数据；任务只引用物品 ID，不重新定义物品价格。
-
-## 玩法覆盖检查
-
-| 顶层玩法环节或关键规则 | 负责或协作系统 |
+| 行动或时机 | 协作与结果归属 |
 |---|---|
-| 查看天气、日程与目标 | S01、S11、S12、UI |
-| 选择活动并移动 | S04、S02 |
-| 农务与生产 | S03、S07、S02 |
-| 采集、钓鱼与战斗 | S04、S05、S06、S07 |
-| 出售、购买与投资 | S09、S07、S03 |
-| 社交与委托 | S10、S11、S07 |
-| 日终结算与保存 | S01、S12、存档、UI |
+| 播种与农务 | S03 检查地块及行动条件，S07 检查种子或工具，S02 检查行动成本；确认可执行后更新各自状态。失败时不留下仅扣种子或体力的部分结果 |
+| 采集 | S04 确认资源点可用，S05 判定获得物，S07 入账，S08 接收活动经验；成功后由 S04 更新资源点状态 |
+| 出售与购买 | S09 校验营业、库存与价格，S07 校验物品和容器；交易成功时双方分别更新所拥有的状态，失败时保持原状态 |
+| 成长与解锁 | 活动系统报告成果，S08 更新经验与能力；S07 等使用方读取解锁结果，不自行维护另一套技能进度 |
+| 日终 | S01 停止当日行动并协调结算；S03 推进作物与生产、S09 结算出货、S08 结算成长，之后汇总反馈并保存。跨日通知让各系统准备次日状态 |
+| 居民行动与节日 | S10、S12 读取 S01 的日期与时间，按各自规则决定活动；需要移动时交给 S04，不反过来推进全局时钟 |

-## 目录映射
+跨系统行动的提交方式、失败处理和精确结算顺序在系统文档与 TDD 中展开，须满足上述结果一致性。日终保存应包含已经完成的结算，不能读档后重复发放同一次收益。

-| 目录 | 本阶段定位 |
+系统通过 `item_id`、`npc_id`、`region_id`、`recipe_id` 等稳定标识关联。物品身份与实例归 S07，价格归 S09，关系值归 S10；任务、界面和存档可以引用或展示这些结果，不独立修改对应事实。UI 从权威状态刷新，只读展示副本不承担结算；存档快照在结算完成后生成，读档时恢复到对应系统。
+
+跨系统共享的约束：
+
+- 时间与生产使用一致的游戏时间单位，行动成本、制作时长与跨日成长须说明对应关系。顶层暂定常规游戏日约 10～20 分钟，实际换算与暂停规则在后续规格中明确并试玩验证。
+- 金钱由 S09 统一结算，各活动提供产物或交易请求；经验是持续积累的进展，不作为货币消费。
+- 失败后果按顶层场景分别处理：矿井倒下可能损失部分钱物，换季可能使作物枯萎，同时保留大部分长期进展。涉及体力、物品、金钱或位置的变化由各自负责系统执行。
+- 存档、UI 和活动系统使用相同的状态含义，避免显示已获得但实际未入账、或已结算却未保存的结果。
+
+## 系统文档映射
+
+本例分别展开各系统，以下是策划工作区的文档目录；实现代码如何拆模块由 TDD 决定。
+
+| 系统 | 文档目录 |
 |---|---|
-| 03_systems/S01_time_schedule/ | 时间推进、日期季节天气、营业时段、日终结算 |
-| 03_systems/S02_stamina_status/ | 体力、状态效果、昏倒与恢复 |
-| 03_systems/S03_farm_management/ | 土地、作物、畜牧、设施生产 |
-| 03_systems/S04_exploration_map/ | 区域、连接、资源点、解锁与移动 |
-| 03_systems/S05_foraging_fishing/ | 采集、钓鱼、品质与获得物 |
-| 03_systems/S06_combat_enemies/ | 战斗、敌人行为、伤害与战利品请求 |
-| 03_systems/S07_items_inventory_crafting/ | 物品、背包、配方与制作队列 |
-| 03_systems/S08_progression_skills/ | 技能经验、等级、工具升级、能力解锁 |
-| 03_systems/S09_economy_shop/ | 货币、买卖、价格、库存与订单 |
-| 03_systems/S10_npc_relationship/ | NPC 日程、对话、好感与关系事件 |
-| 03_systems/S11_quests_community/ | 任务、社区目标、奖励与解锁条件 |
-| 03_systems/S12_events_festivals/ | 季节事件、节日、条件触发 |
-| 支撑层不单开系统文档 | 存档与 UI 随实现层组织，规则不独立成文 |
+| S01 时间与日程 | `project/03_systems/S01_time_schedule/` |
+| S02 体力与状态 | `project/03_systems/S02_stamina_status/` |
+| S03 农场经营 | `project/03_systems/S03_farm_management/` |
+| S04 探索与地图 | `project/03_systems/S04_exploration_map/` |
+| S05 采集与钓鱼 | `project/03_systems/S05_foraging_fishing/` |
+| S06 战斗与敌人 | `project/03_systems/S06_combat_enemies/` |
+| S07 物品、背包与制作 | `project/03_systems/S07_items_inventory_crafting/` |
+| S08 成长与技能 | `project/03_systems/S08_progression_skills/` |
+| S09 经济与商店 | `project/03_systems/S09_economy_shop/` |
+| S10 NPC 与关系 | `project/03_systems/S10_npc_relationship/` |
+| S11 任务与社区目标 | `project/03_systems/S11_quests_community/` |
+| S12 事件与节日 | `project/03_systems/S12_events_festivals/` |

-## MVP 最小闭环
-1. 玩家在一个游戏日内完成开垦、播种、浇灌，并看到成长状态反馈。
-2. 在时间与体力约束下选择当日主目标（农场劳动或外出）。
-3. 外出采集（或矿井轻度战斗）带回资源。
-4. 通过出售或加工获得金钱，投资种子或工具。
-5. 日终结算展示当日变化并保存。
-6. 次日作物状态变化，玩家据此形成新计划。
-7. 数个游戏日内出现第一次技能提升与配方解锁。
+## 实现范围与验证

-如果这条闭环不成立，不应继续增加钓鱼深度、节日、社区目标或更多区域。
+首个原型包含 S01、S02、S03、S04、S05、S07、S08、S09 的上述基础能力，加上必要的 UI 与存读档。完整版本还需展开钓鱼、制作、畜牧、战斗、居民关系、社区目标与节日等能力；完整清单不等于首个原型的施工范围。

-## 统一数值基准
-本案例采用"宽松治愈型"数值风格。全局单位：时间片、游戏日、货币、体力、经验；所有数值字段必须注明单位。
- 时间节奏基准：单次常规行动控制在短时间片内；玩家一天应能完成农务、一个主要外出目标和少量顺路活动；早期玩家不应因一次路线失误失去整天进度。
- 货币量级基准：主要货币只有一种；初期基础种子可用少量日常产出购买；一次普通收获不应立刻买下最高阶升级；任务奖励以补足短期资金为主，不替代生产交易。
- 成长回报基准：前几级在正常尝试一种活动的数个游戏日内出现；升级奖励优先采用节省时间体力、扩大选择和解锁配方，而非单纯提高伤害售价；专长分支宽松可恢复。
- 体力与风险基准：体力是规划提示不是严苛倒计时；普通农务与移动成本低，战斗、钓鱼和重型工具才产生明显取舍；失败成本采用时间、少量金钱或位置变化，不损毁进度。
+首个流程从查看天气和选择目标开始，经农务或外出采集获得进展，再通过出售、购买和日终进入下一天。单日用于观察计划与取舍；连续数日用于覆盖作物生长、收获、投资和基础成长，不要求作物一天内完成播种到收获。

-（具体换算数值与前五日验算由技术文档层·数值策划承接。）
-
-## 系统边界
- 农场经营只管理农场内的生产状态，不负责所有资源的通用背包逻辑。
- 探索与地图只管理"在哪里"和"能否进入"，不管理每种活动的具体奖励。
- 战斗只管理战斗内状态和战利品请求，不直接修改商店价格或 NPC 好感。
- NPC 与关系负责互动和关系变化；任务与社区负责可验证目标，二者通过事件和条件连接。
- UI、文本和表现不反向承载核心规则；所有关键变化必须由规则系统确认。
- 本案例不拆出独立多人、拍卖、复杂天气模拟、动态市场或高复杂度叙事工具系统。
-
-## 优先级与范围
- P0（最小可玩闭环）：时间与日程、体力、农场、物品背包、经济、基础地图、基础成长和日终结算。
- P1（形成完整案例）：采集、钓鱼、轻度战斗、NPC 关系、任务、社区目标、制作、商店、季节和节日。
- P2（扩展内容）：更多区域、敌人、作物、配方、关系事件、节日小游戏和终局后的自由活动。
-
-拆分系统不等于所有系统都要在最小版本同时实现；系统独立性是为了便于协作和后续裁剪。
-
-## 风险与校验
-
-| 风险 | 校验方式 |
+| 验证问题 | 内容与判断依据 |
 |---|---|
-| 农场变成例行公事，失去规划感 | 玩家是否在目标选择阶段出现真实取舍与计划调整 |
-| 矿井战斗反客为主 | 战斗收益是否仍以"农场难以产出的材料"为主，而非直接金钱 |
-| 时间压力变成打卡义务 | 休闲型玩家能否自由调低日程重量而不被惩罚 |
-| 经济成长过快，后期失去决策 | 升级价格是否持续制造"效率 vs 规模"的选择 |
-| UI 泄题，探索失去意义 | 关键信息是否保留为探索发现而非全量直读 |
-| 系统间主数据重复维护 | 交叉检查：同一事实是否只有一个系统拥有写权 |
+| 基础系统是否共同支持日常计划 | 试玩农务与采集，观察时间、体力、物品和金钱变化是否一致，结合玩家说明判断选择是否有意义 |
+| 跨日成果能否支持后续计划 | 连续游玩并存读档，检查作物、交易与成长是否持续且无重复结算，结合玩家反馈判断是否形成新的目标 |
+| 战斗是否改善探索节奏 | 后续加入 S06 与矿井所需的地图、状态和物品能力，观察战斗理解、损失恢复及其对日常活动的影响 |
+| 关系与社区是否形成长期目标 | 后续加入 S10、S11 及对应内容，观察多日投入与目标选择；单日原型不据此判断长期体验 |

-## 开放的结构问题
- 体力与生命是否保持为两个状态，还是在轻度战斗中共享一套风险资源？
- NPC 日程、任务条件和节日事件之间采用统一条件格式还是各自维护？
- 农场设施生产是否由农场系统统一管理，还是交给通用制作队列？
- 采集、钓鱼和战斗是否共享统一的"活动结果"接口？
- 哪些系统需要独立数据表，哪些小型配置应合并为一张内容表？
+以上是验证计划，尚未形成试玩结论。出现问题时先判断是玩法目标不成立、协作职责遗漏还是实现错误，再调整相应设计与范围。
+
+## 风险与未决问题
+
+- 时间、体力和收益可能共同把休闲生活变成赶任务：沿用顶层验证计划，比较不同玩家的计划调整与压力反馈。
+- 农场生产、制作和交易可能重复消费或入账：在系统规格中明确提交与失败处理，在实现阶段验证中断和日终存读档后的结果。
+- 社区目标采用章节、可选收集还是组合仍需展开：在该内容进入实现范围前确定，并补齐 S11 与 S04 的解锁协作。
+- 体力与战斗生命是否共享、战斗最低深度如何确定：不阻塞基础日常原型，在战斗原型前解决，再补齐 S02、S06 及相关 TDD 规格。
@@ -1,19 +1,21 @@
 # 数据与配表：《星露谷物语》（TDD 金样 · 数据与配表）

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

 ## 数据表总清单

+以下包含完整版本的数据类别；v0.1 只取首个日常原型需要的农务、基础采集、物品、交易、成长、时间与地图等内容。战斗、钓鱼、关系、任务和节日数据用于后续范围，不作为 v0.1 已实现能力。
+
 | 表格组 | 建议表名 | 主要维护系统 | 实证规模（原作 1.6.15） |
 |---|---|---|---|
 | 物品与经济 | 物品表、品质表、商店表、商店库存表、价格表 | 物品与制作、经济与商店 | 物品 807×29 类；商店 77 店 897 条库存（含店级 PriceModifiers） |
 | 农场内容 | 作物表、动物表、设施表、加工配方表 | 农场经营 | 作物 50 全字段；机器 39 台全 OutputRules |
-| 活动内容 | 采集点表、钓鱼点表、鱼类表、敌人表、敌人行为表、遭遇表、战利品表 | 采集/钓鱼/战斗 | 怪物 51 条配置；怪物 AI 矩阵 30 类移动原型 |
-| 物品制作 | 通用配方表、配方解锁表 | 物品与制作 | 配方 231（烹饪 81+工艺 150，全原料/产出/解锁） |
+| 活动内容 | 资源点表、采集规则表、钓鱼点表、鱼类表、敌人表、敌人行为表、遭遇表、战利品表 | 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） |

 （表格拆分是生产组织方式，不改变主数据归属。原作同套模型同时服务本体与模组生态——静态表为结构化 JSON-in-XNB，由 DataLoader 按需缓存。）
@@ -75,30 +77,30 @@
 | 经济表 | 买卖价差 | 商店价=2×基价×品质系数；出售所得=其半 | 原作一对出售方法实证 | 新手期现金流断裂 |
 | 战斗表 | 受击无敌帧 | 450ms（按武器类型 2/3 除） | 原作 takeDamage 实证 | 手感测试受击连按 |

- 前五日闭环验算（防风草路线，起始 500 金实证口径）：
+- v0.1 多日验算草案（农务、基础采集、交易与成长）：

-| 日期 | 主目标 | 关键行动 | 主要成本 | 主要获得 | 结果 |
-|---|---|---|---|---|---|
-| 第 1 日 | 建立基础生产 | 购防风草种子×15（20 金/包）、开垦播种浇灌、采集少量木材 | 300 金；约 30 体力；约 8 时间片 | 15 块已播种地；少量木材；农务经验 | 进入等待成长阶段 |
-| 第 2 日 | 接社区引导 | 浇灌、采集木材、与工匠对话推进修路任务 | 约 25 体力；约 8 时间片 | 任务材料进度；少量经验 | 任务明确指向自然区域 |
-| 第 3 日 | 补足任务材料 | 浇灌、采集木材与铜矿、返回小镇 | 约 35 体力；约 12 时间片 | 木材 20、铜矿 5（或进度）；采集/战斗经验 | 可提交修路任务 |
-| 第 4 日 | 收获+解锁 | 收 15 防风草（35 金×15=525 金、8 xp×15=120 xp→农务 1 级）、提交任务领奖 | 任务材料；约 10 时间片 | 525 金；基础洒水器配方；林间区域开放 | 现金流回正＋新活动选择 |
-| 第 5 日 | 验证扩展循环 | 浇灌、赴林间采集或钓鱼、出售部分产物 | 约 30~45 体力；约 14 时间片 | 新资源、活动经验、可售物品 | 循环从单一农务扩展为农场+探索 |
+| 时段 | 关键行动 | 可据现有数值推算的部分 | 待补齐的验算输入 |
+|---|---|---|---|
+| 第 1 日 | 买种、播种、浇水与基础采集 | 起始 500 金，15 包种子各 20 金，购种后余 200 金 | 农务和采集成本、采集获得物与经验 |
+| 第 2～4 日 | 维护作物，选择外出采集并出售部分成果 | 连续满足成长条件，等待四次跨日成长完成 | 每日时间体力收支、资源点刷新、采集收益 |
+| 第 5 日 | 收获、出售、投资与基础成长 | 若 15 株均正常成熟且为普通品质，售得 525 金、收获经验 120 xp；种子投入的毛利为 225 金，不含其他收支 | 实际品质、其他活动收支、成长反馈与投资选择 |

- 收益链校验：`item_seed_parsnip(20金) → crop_parsnip(4 日) → item_parsnip(35 金) → 出货箱日终结算 → 种子复购（单包毛利 15 金）`（逐环引 ID，全链存在）。
- 验算结论：第 1 日不要求做完，播种即进展；第 4 日奖励同时给资金/配方/区域三样；第 5 日出现农场与探索取舍但两条路线都可行。
+- 待校验的收益关系：`item_seed_parsnip(20金) → crop_parsnip(4 日) → item_parsnip(35 金) → 出货箱日终结算 → 种子复购`。仍需结合实际配置核对引用、成长条件、采集收益及跨日结算，不能以局部算术推算宣称完整验算通过。
+- 当前结论：上述草案未完成 v0.1 的时间、体力和资源收支验算，也未证明玩法节奏成立。补齐输入后验算，并结合原型观察与玩家反馈判断。

 ## 验收

 - 验收记录：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——已有数据的五查与两查复核通过；背包容量与公共索引定义仍需补齐，不能据此认定当前范围的数据规格完整。结构、规则或字段语义一变，受影响链路全部重验。
+- 最近验收结论：check@C-2026-09-11-v1——已有数据的五查与两查复核通过；基础采集配置、当前范围验算、背包容量与公共索引定义仍需补齐，不能据此认定当前范围的数据规格完整。结构、规则或字段语义一变，受影响链路全部重验。

 ## 待解决问题

+- 基础采集：补齐资源点位置与刷新、采集判定、获得物、品质和经验配置，与技术分册 S04/S05/S07/S08 的职责和接口一致。
+- 当前范围验算：补齐日常行动成本和收益，明确跨日结算顺序，完成 v0.1 农务、基础采集、交易与成长的多日收支验算。
 - 背包容量：与技术分册确认格子或重量规则后，补齐容器字段、容量约束及存档数据定义。
 - 公共索引：补齐 condition/text/station/behavior 的索引定义与引用说明，再检查加载和引用完整性。

@@ -6,8 +6,8 @@

 | # | 施工方的问题 | 答案在哪 | 状态 |
 |---|---|---|---|
-| 1 | 七个 P0 系统怎么行为？ | 01 收编章及待解决问题 | **缺口**：背包容量与体力规则仍需确定 |
-| 2 | 表里有多少行内容、文本全填了吗？ | 03 数值填充、验收及待解决问题 | **缺口**：已有数据检查不能代替容量与公共索引定义 |
+| 1 | 首个日常原型所需的八个系统如何协作？ | 01 收编章及待解决问题 | **缺口**：基础采集、跨日结算顺序、背包容量与体力规则仍需补齐 |
+| 2 | 表里有多少行内容、文本全填了吗？ | 03 数值填充、验收及待解决问题 | **缺口**：基础采集配置、当前范围验算、容量与公共索引定义仍需补齐 |
 | 3 | 每个界面长什么样、怎么走？ | 01 UI 交互规格 | **缺口**：背包方案确定后需更新对应交互 |
 | 4 | 每份素材什么规格、谁验收过？ | 02 素材规格、资产状态表及待解决问题 | **缺口**：换装范围、锚点图和字体仍有待确认内容 |
 | 5 | 代码怎么组织、跑在哪？ | 01 代码组织+能力边界（三态全落位） | **过** |
@@ -20,9 +20,9 @@

 | 件 | 状态 | 版本 | 读者 | 一句话结论 |
 |---|---|---|---|---|
-| 01 技术实现 | 待补齐 | v0.2 | 程序 | 补齐背包与体力规则；v0.1 判据仍为一个游戏日全流程 |
+| 01 技术实现 | 待补齐 | v0.2 | 程序 | 补齐基础采集、跨日结算、背包与体力规格；v0.1 覆盖单日选择及多日成长 |
 | 02 美术圣经 | 待补齐 | v1 | 美术 | 确认换装范围、锚点图与字体；已有资产的验收记录保留 |
-| 03 数据与配表 | 待补齐 | ck-001 | 数值+程序 | 已有数据检查通过，容量与公共索引定义仍需补齐后重验 |
+| 03 数据与配表 | 待补齐 | ck-001 | 数值+程序 | 补齐基础采集配置、当前范围验算、容量与公共索引定义后重验 |

 ## 跨件契约速查

@@ -41,10 +41,10 @@

 | 相关分册 | 影响当前施工的缺口 | 详细位置 |
 |---|---|---|
+| 01、03 | 基础采集及区域数据、跨日结算顺序不完整 | 01“S05”“S01”及“待解决问题”；补齐后同步数据分册 |
 | 01、03 | 背包容量与体力规则影响行为、存档及界面 | 01“待解决问题”；确定后同步两份分册正文 |
-| 01 | 矿井生成是否纳入本期影响地图实现 | 01“待解决问题”及“场景与镜头” |
 | 02 | 换装范围、锚点图与字体影响素材和渲染规格 | 02“待解决问题” |
-| 03 | 公共索引定义影响数据加载与引用 | 03“待解决问题” |
+| 03 | 当前范围验算与公共索引定义未完成 | 03“数值填充与验算”及“待解决问题” |

 详细分析与下一步在对应分册维护；问题解决后更新分册正文，再移出本汇总，无需向全局台账重复登记。

@@ -52,8 +52,8 @@

 | 件 | 最近验收 | blocker | 结论 |
 |---|---|---|---|
-| 01 | 已有构建和静态检查通过；双视口验证待联调 | 背包与体力等规格缺口 | 补齐正文后复核当前范围的完整性 |
+| 01 | 已有构建和静态检查通过；当前范围验证待补齐规格后进行 | 基础采集、跨日结算、背包与体力等规格缺口 | 补齐正文后复核当前范围的完整性 |
 | 02 | ck-a01~a03 保留已有资产的接入与验收记录 | 换装、锚点图与字体规格未定 | 相关规格确认后再制作和验收受影响素材 |
-| 03 | ck-001 已有数据检查通过 | 容量与公共索引定义缺口 | 补齐后重验受影响的数据与接口 |
+| 03 | ck-001 已有数据检查通过 | 基础采集配置、当前范围验算、容量与公共索引定义缺口 | 补齐后重验受影响的数据与接口 |

 以上缺口解决且施工所需信息完整后，才能将当前范围标为“只凭 TDD 可实施”。
@@ -1,7 +1,7 @@
 # 技术实现：《星露谷物语》（TDD 金样 · 技术实现）

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

 ### S01 时间与日程（基于系统文档@v1 收编）
 - 玩家行动：查看时间天气（HUD 常驻）；使用床提前结束一天；等待营业时段。
- 状态与规则：时间以时间片计、现实驱动、暂停时停表；时间片耗尽或就寝→日终结算（顺序固定：作物生长 tick→设施产出→出货箱结算→NPC 日程推进→存档→日记界面）→日期+1；28 日/季、四季/年；天气每日按季节权重抽取（晴/雨/风暴），雨天免浇水；结算后向 S03/S07/S10 发跨天 tick。
+- 状态与规则：时间以时间片计、现实驱动、暂停时停表；时间片耗尽或就寝→协调日终结算→日期与天气更新→各系统准备次日状态→存档与汇总反馈。作物成长由 S03、设施或制作由对应生产系统、出货由 S09、成长由 S08 处理；28 日/季、四季/年；天气每日按季节权重抽取（晴/雨/风暴），雨天免浇水。居民内容加入后，S10 接收时间通知并推进自身日程；精确结算顺序仍需补齐。
 - 反馈需求：HUD 时钟日期常驻；天气图标；日终面板逐项列当日变化。
 - 实证参照（原作 1.6.15）：`700ms = 10 游戏分钟`（累加器超 `7000 + 地点Extra×10`ms 触发十分钟拍，`timeOfDay += 10`，上限 2600）；日结算顺序不可乱——出货先于邮件/任务（订单计数依赖）、地点 dayUpdate 先于玩家 dayupdate（作物推进后才有当日收获判定）。

@@ -21,37 +21,45 @@
 - 实证参照：原作基础 MaxStamina=270、MaxHealth=100；午夜后体力惩罚为线性公式（Farmer.dayupdate）；昏睡账单上限默认 1000g、姜岛 2500g（LocationContexts 数据驱动，非硬编码）。

 ### S03 农场经营（基于系统文档@v1 收编）
+当前实现耕种、浇水、生长与收获；下述畜牧、设施和加工内容属于后续范围。
 - 玩家行动：锄地/播种/浇水/收获/铲除；喂动物收集畜产；放置使用设施；整理布局。
 - 状态与规则：地块状态机 荒地→耕地→（播种+浇水）→生长 N 日→可收获→收获后回耕地；未浇水当日不生长；生长按日终 tick；雨天视为已浇水；作物有适宜季节、换季枯萎；动物每日喂食→周期产出、未喂不产出不死亡；洒水器每晨自动浇固定格；加工设备按配方+时间片队列产出；品质分普通/银/金（技能等级+概率）。
 - 反馈需求：生长阶段视觉可辨；成熟提示标记；设施完成音效图标；日终列农场产出。
 - 实证参照：耕地是网格状态拥有者，作物挂在耕地下（HoeDirt 拥有湿度/肥料/作物引用）；收获单一入口；**品质 roll 先于数量 roll 且共用同一随机流**（顺序影响结果）；保水判定在作物推进之后（当天浇的水当天有效）。

 ### S04 探索与地图（基于系统文档@v1 收编）
+当前实现农场、小镇与基础采集区域；矿井、钓鱼入口和任务解锁属于后续范围。
 - 玩家行动：移动（8 向网格）；穿出入口切换区域；查看地图；交互资源点入口（采集/钓鱼/战斗分别交 S05/S06）。
 - 状态与规则：区域=独立场景、连接点切换淡入淡出≤1s；初始开放农场+小镇+海滩，林间/矿井由社区任务解锁（条件表）；资源点固定刷新点按规则周期重生；隐藏信息保留为探索发现；矿井按层进入、固定池随机拼装+亮度递减。
 - 反馈需求：地图标注已解锁区域与当前位置；解锁新区域明确提示与入口指引；资源点可交互高亮。
 - 实证参照：原作矿井同日同层布局确定（每日世界种子 `DaysPlayed + 存档ID/2`）；矿井布局池 61 张模板按层拼装；骷髅洞时间减速 28.6%（+200ms/分）仅单机生效。

+### S05 采集与钓鱼（当前范围为基础采集，规格待补齐）
+
+基础采集属于 v0.1，钓鱼属于后续范围。当前尚缺采集触发、获得物判定、资源点状态更新、物品入账失败处理及经验反馈的完整规格；须补齐本节及数据分册中的配置后，才能满足当前范围只看 TDD 即可实现的要求。
+
 ### 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，玩家所得）。

 ### S08 成长与技能（基于系统文档@v1 收编）
+当前实现基础农务或采集成长；其他活动技能、分支与工具升级委托属于后续范围。
 - 玩家行动：查看技能面板；升级时选加成方向；提交工具升级委托。
 - 状态与规则：技能五项（农务/采集/采矿/钓鱼/战斗）独立经验池；执行对应活动得经验、只增不减；等级效果三类——效率（省时省体力）/解锁（配方/区域/工具位）/选择（每若干级一次分支，宽松可回转）；工具升级期间该工具不可用（备用旧工具=开放问题暂不备）；升级奖励优先省时省力扩选择，不加数值伤害。
 - 反馈需求：经验条与升级音效；升级面板三选一；工具完成由铁匠通知。
 - 实证参照：原作技能累计经验曲线为代码常量 `100/380/770/1300/2150/3300/4800/6900/10000/15000`（10 级）；经验取整用银行家舍入（边界值注意）；满级后经验转全局精通点（第二成长曲线）。

 ### S09 经济与商店（基于系统文档@v1 收编）
- 玩家行动：出售（出货箱日终/商店现卖）；购买；查看价格库存；接装箱订单（P1）。
- 状态与规则：货币唯一；基准价+买卖价差，价格只由本系统维护（其他系统只提交产物或消费请求）；商店各有营业时段（条件表）、库存按周期补货、部分商品有购买条件；出货箱投入→日终统一结算计入当日收入；订单 P1 最低配=每周装箱单换奖金。
+- 玩家行动：出售（出货箱日终/商店现卖）；购买；查看价格库存；装箱订单属于后续范围。
+- 状态与规则：货币唯一；基准价+买卖价差，价格只由本系统维护（其他系统只提交产物或消费请求）；商店各有营业时段（条件表）、库存按周期补货、部分商品有购买条件；出货箱投入→日终统一结算计入当日收入；后续订单的基础形式为每周装箱单换奖金。
 - 反馈需求：交易金额飘字音效；日终面板单列收入明细；商店营业状态门口可见。
 - 实证参照：原作 77 店 897 条库存，店级 PriceModifiers 数据驱动；基础材料（木/石/煤/铜/铁/金）售价走年度特例（第 2 年起涨价）而非通用公式。

-### S06 战斗与敌人（P1，基于系统文档@v1 收编要点）
-进入危险区域遭遇→敌人状态机（待机/警觉/前摇/攻击/受击/眩晕/死亡）→攻击需满足距离方向冷却装备条件→伤害=来源属性+目标防御+倍率+状态→敌前摇必须可识别→死亡只结算一次经验战利品→战利品按 item_id 提交 S07 入账→撤退保留已结算奖励。全规则见系统文档@v1（P1 施工时全文收编）。
+### S06 战斗与敌人（后续范围，基于系统文档@v1 收编要点）
+进入危险区域遭遇→敌人状态机（待机/警觉/前摇/攻击/受击/眩晕/死亡）→攻击需满足距离方向冷却装备条件→伤害=来源属性+目标防御+倍率+状态→敌前摇必须可识别→死亡只结算一次经验战利品→战利品按 item_id 提交 S07 入账→撤退保留已结算奖励。纳入实现范围前须将系统文档@v1 的完整规则收编进本册，当前要点不构成战斗施工规格。
 实证参照：怪物 51 条配置拆 15 字段（HP/伤害/掉落对/防御/闪避/速度/经验…）；受击 `max(1, 伤害−防御)`、450ms 基准无敌帧；伤害链顺序固定：roll→暴击→+攻击→职业→附魔→怪物防御（改序即改平衡）；暴击乘区在 +Attack×3 之前（攻击力不吃暴击）。

 ## UI 交互规格
@@ -66,14 +74,15 @@

 （实证参照：原作对话文本中 `$表情` 标记驱动立绘切换，六表情索引 0-5；钓鱼小游戏是唯一不暂停时间的菜单。）

-## 来自 GDD 的功能（P0 七系统）
+## 来自 GDD 的功能（首个日常原型）

 | 系统 | 一句话职责 | 拥有的主数据 |
 |---|---|---|
-| S01 时间与日程 | 全局时钟与日终结算 | 日期、季节、天气、日程 |
+| S01 时间与日程 | 全局时钟与日终协调 | 日期、季节、天气；居民日程归 S10 |
 | S02 体力与状态 | 全局行动成本与恢复 | 体力、状态效果 |
 | S03 农场经营 | 核心产出与规划场 | 地块、作物、设施 |
 | S04 探索与地图 | 场景与空间约束 | 区域、连接、资源点 |
+| S05 采集与钓鱼 | 本期基础采集，钓鱼后续加入 | 采集判定与获得物规则；资源点状态归 S04，物品入账归 S07 |
 | S07 物品与制作 | 资源身份与转化 | 物品、配方、背包 |
 | S08 成长与技能 | 长期回报层 | 经验、等级、解锁 |
 | S09 经济与商店 | 投资与回报换算 | 价格、交易、库存 |
@@ -108,7 +117,7 @@

 ## 代码组织概览

- 承架构目录映射：`src/systems/s01_time/ … s12_events/`（每系统一目录：state/rules/api 三件）；`src/scenes/` 场景注册；`src/core/` 循环、渲染、输入、存档。
+- 本例代码采用 `src/systems/s01_time/` 等系统模块目录，仅为当前实现范围建立所需模块；`src/scenes/` 负责场景注册，`src/core/` 负责循环、渲染、输入、存档。这是 TDD 的实现选择，不由 `project/03_systems/...` 的文档目录决定。
 - 入口 `main.ts` → 场景管理器（注册表制，场景切换走统一接口）。
 - 边界约定：系统间只经公开 api 与事件总线通信，禁跨目录直改他人 state。
 - 实证参照（原作，仅作组织参考）：玩法逻辑全在一个 6.27MB 程序集，入口链 原生启动器→主 dll→GameRunner 帧循环（Update/Draw 非固定步长，真实毫秒累加器驱动逻辑）；静态表/本地化文本/地图/运行状态/存档五类数据分置 Content、内存、Saves 目录，按需缓存加载。
@@ -125,9 +134,9 @@

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

 ## 输入与操作
@@ -160,16 +169,18 @@

 | 版本 | 内容 | 判据 |
 |---|---|---|
-| v0.1 | S01/S02/S03/S07+S04 基础 | 一个游戏日"买种→播种→浇灌→收获→出售"全流程可完成并触发日终结算 |
-| v0.2 | 矿井+战斗（S06）+成长（S08） | 矿井进出一次、遭遇一场、掉落入账、经验到 1 级（累计 100xp） |
-| v0.3 | NPC+任务+商店（S09/S10/S11） | 修路任务全链可交付并解锁洒水器配方 |
+| v0.1 | S01/S02/S03/S04/S05/S07/S08/S09 基础，加 UI 与存读档 | 单日农务与采集均可执行；连续数日完成作物生长、收获、出售与投资，出现基础成长；存读档后状态一致且无重复结算 |
+| v0.2 | 矿井与战斗（S06）及配套地图、状态和成长能力 | 矿井进出一次、遭遇一场、掉落与经验正确入账，撤退或倒下的后果符合补齐后的规格 |
+| v0.3 | NPC 与社区目标（S10/S11）及配套交易内容 | 代表性关系事件和社区目标可完成，奖励与解锁正确触发 |

 ## 待解决问题

 | 问题 | 影响 | 下一步与需更新的正文 |
 |---|---|---|
+| 基础采集与采集区域规格尚未收编完整 | v0.1 缺少必需能力，无法只凭 TDD 实现 | 补齐 S05 行为规格、S04 资源点交互、场景数据及数据分册中的获得物配置 |
+| 跨日精确结算顺序尚未确定 | 影响成长、生产、出货及存档的一致性 | 补齐 S01 协调顺序及各系统输入输出，验证存读档后不重复结算 |
 | 背包采用格子还是重量容量 | 决定物品容器、存档和 UI 结构 | 与用户确认后补齐 S07 行为规格、UI 交互规格及数据分册中的容量字段；目前的格子制是暂定方案 |
-| 矿井逐层生成是否纳入本期 | 影响地图结构与关卡数据，当前方案倾向延期 | 确认本期范围与地图实现方式，再更新场景与镜头、关卡数据及版本里程碑 |
+| 后续矿井采用何种地图组织与生成方式 | 影响 v0.2 的地图结构与关卡数据，不阻塞 v0.1 | 在矿井进入实现范围前明确，再更新场景与镜头、关卡数据及版本里程碑 |
 | 体力是否与战斗共享单池 | 影响 S02、战斗成本及恢复规则 | 与用户确认后补齐相关系统行为规格和数据定义；目前共享单池是暂定方案 |

 问题解决后将实际采用的规则写入对应正文，检查关联分册并移出待办；这些记录不能代替施工规格。
@@ -29,9 +29,8 @@ description: 写"数据与配表"（数据侧）分册时使用。与总纲（

 ## 二、动笔前

-1. 输入齐了吗：各系统文档「数值与数据交接」节（订单——每系统交来哪些
-   数据类别与定性约束）、架构层主数据归属规则（写权分配）、统一数值基准
-   （架构层的定性基准，在本件落成前 N 日验算）。
+1. 输入齐了吗：各系统的数据类别、已确定的规则参数与待补规格，以及架构中
+   的数据归属和共享约束。将这些信息落实为完整字段、配置和可执行的验算。
 2. 先读两份提取件：字段字典全套规则与验收模板已在那里成文，本件是
   项目实例化，不是重新发明。
 3. 读取金样 exemplars/stardew-tdd-data.md 了解数据清单、验算表与验收结论包含的信息类型（同层只读一次）。
@@ -75,11 +74,10 @@ draft 调试可见/两 disabled 不加载、deprecated 留 ID 占位防复用）

 ### 6. 数值填充与验算
 结构定稿后才填数。实际数值、单位、适用范围和默认值写在本册配表与字段
-契约中；重要取舍按需记分析。**前五日
-闭环验算必做**：按架构统一数值基准排五日表（主目标/关键行动/成本/获得/
-结果），加收益链校验（`区域→敌人→材料→配方→产出`逐环引 ID）——验算
-结论写回：第 1 日不要求做完、奖励多元不单一、第 5 日出现取舍但仍留两条
-可行路线。
+契约中；重要取舍按需记分析。依据当前玩法、共享约束和验证问题选择验算
+场景与跨度，记录关键行动、成本、获得和结果；检查实际存在的收益与消耗
+关系及引用 ID。验算结果应支持对节奏、可达性和资源收支的判断，不预设
+必须采用五日表或得出固定结论。

 ### 6.5 全量填充与内容完成度（自足性的数据侧保障）
 结构定稿后的填充不是示例——是**全量**：数值表每表填满计划行数、文本表
@@ -100,7 +98,7 @@ note 不阻断。验收记录表留 check_id 与 data_version。**结构、规
 - 每张表答得出"谁是拥有者系统"吗？
 - 任意单元格有没有"约/待定/多值拼一格"？
 - 条件表是否全项目一个入口？程序求值器只需实现一次吗？
- 前五日验算跑过吗？收益链每一环的 ID 都存在吗？
+- 当前范围的关键场景验算跑过吗？涉及的资源与配置 ID 都存在吗？
 - 最近一次验收：blocker 清零了吗？

 ## 五、红线（承总纲四条，本件特化）
@@ -25,7 +25,7 @@ description: 写"技术实现"（程序侧）分册时使用。与总纲（技

 ## 二、动笔前

-1. 输入齐了吗：架构层系统范围表+P0 清单（拆模块依据）、数据侧表结构契约
+1. 输入齐了吗：架构层当前实现范围、职责与协作（拆模块依据）、数据侧表结构契约
   （加载与校验要引用）、可复用能力选型（实现类需求先查现成能力，不自造轮子）。
 2. 读总纲判断立场；本件在数据侧表结构定稿后开写。
 3. 读取金样 exemplars/stardew-tdd-tech.md 了解技术实现文档包含的信息类型（同层只读一次）。
@@ -33,10 +33,10 @@ description: 写"技术实现"（程序侧）分册时使用。与总纲（技
 ## 三、怎么写（模板即流程，按节）

 ### 0. 系统行为规格（收编章——本件的灵魂）
-每个 P0 系统一节，**收编**该系统文档的「玩家行动／状态与规则／反馈需求」
-三节全文（标注"基于系统文档@v{N}"）。施工方 只读这里就该知道这个系统
-怎么行为——不需要回 GDD。P1 系统收编一句话职责+开放状态，施工到该系统时
-补收编。收编节只同步不改写：GDD 变了重同步，TDD 不在这里加观点。
+按当前实现范围**收编**各系统的玩家行动、状态与规则、反馈需求等行为规格，
+标注来源版本（如"基于系统文档@v{N}"）。施工方只读这里就应知道当前范围
+怎么实现，不需要回 GDD。后续范围可以保留职责与未决事项，纳入施工范围前
+必须补齐规格。GDD 变更时同步受影响的收编内容，不能只更新范围清单。

 ### 0b. UI 交互规格（收编+落地章）
 界面清单（每个界面一行：HUD/背包/商店/对话/结算面板…）+ 每界面的元素、
@@ -44,7 +44,7 @@ description: 写"技术实现"（程序侧）分册时使用。与总纲（技
 规则在此落位（与圣经 UI 节同源）。

 ### 1. 来自 GDD 的功能
-摘录系统范围表与 P0 清单，一行一系统。只摘，不评——评价回 GDD。
+列出当前实现范围的系统与能力，承接架构中的职责、协作和数据归属。

 ### 2. 技术目标与平台事实
 平台事实原样置顶（禁改）；技术目标写可测量的两三条（如"首屏可玩≤N 秒"）。
@@ -62,7 +62,8 @@ HTML 的 Canvas/WebAudio/localStorage）、**自封装**（基础 API 上自己
 引擎项目按所选引擎的预览与导出流程验证。

 ### 5. 代码组织概览
-承架构层目录映射：入口、场景、系统模块的文件组织，一图或一段写死。
+根据职责与实现需求确定入口、场景、系统模块的代码组织；架构中的系统文档
+目录不等于代码目录。用图或文字写清实际文件位置与模块关系。
 命名与模块边界约定写清（面向生成代码的可读性：谁在哪个目录、什么前缀）。

 ### 6. 外部依赖与可复用能力
@@ -8,15 +8,15 @@ description: 写"时间与日程"类系统文档时使用。与 skills/systems.m

 # 时间与日程 · 系统写法

-**定位**：世界时钟 + 开放窗口的唯一真源。
+**定位**：世界时间推进；开放窗口的规则归属按架构职责确定。

 ## 本类型要点
- 状态与规则：配置基准定性写清（时间片/日结构/季长/年结构各自的
-  设计意图）；具体数值进 TDD 的配置基准表，本层只定结构与意图。
+- 状态与规则：说明实际时间结构、推进与暂停方式，保留已经确定的单位和
+  参数；完整配置及换算由 TDD 收编并补齐。
 - 反馈三件套：HUD 持续显示 + 阈值预告（商店将关/日终将至）+
  **不可用必给具体原因**（"尚未开放/已关闭/今天不营业"，不许只灰按钮）。
- 与架构层"统一数值基准"逐条对齐：1 日=多少时间片、一天应完成几件事的
-  量级感在本层说清，数值给 TDD。
+- 与顶层节奏和架构共享约束一致，说明活动时长、开放窗口与时间推进怎样配合。
+  居民日程、营业或节日规则由其他系统维护时，明确提供的时间信息与协作方式。
 - 边界：不负责活动本身的时间成本（只接收并推进已验证请求）；
  不模拟真实天文（潮汐/星象之类不做）。

@@ -18,7 +18,7 @@ description: 写"物品、背包与制作"类系统文档时使用。与 skills/
 - 反馈：获得/消耗/堆叠/装备各给提示；**背包满要说明缺什么、怎么办**；
  配方界面显示持有/缺口/耗时/产物。
 - 边界：不管最终售价（经济系统唯一维护）、任务文本、NPC 喜好——
-  他家只引用本系统 ID；不复制主数据到别家；**不把整理背包做成玩法**。
+  其他系统通过 ID 引用物品，只读副本与快照按架构归属说明来源及更新方式；**不把整理背包做成玩法**。
 - 典型开放问题：格子容量还是重量？耐久制还是升级替换制？

 ## 本类型自查
@@ -16,7 +16,7 @@ description: 写"成长与技能"类系统文档时使用。与 skills/systems.m
 - 反馈：活动得经验即时显示；**升级展示能力变化，不只是数字跳**；
  工具升级界面显示前后对比/费用/耗时/不可用期。
 - 设计侧定性约束：升级奖励优先"省时间省体力/扩大选择/解锁配方"，
-  而非单纯加数值——与架构数值基准的风格对齐。
+  而非单纯加数值——与已确定的成长目标和跨系统约束一致。
 - 边界：不管单次活动的基础奖励与各公式（只接收经验提交）；
  不做复杂天赋树/随机词缀/无限膨胀。
 - 典型开放问题：技能独立还是合并？升级等待期还是即时？重置成本？
@@ -1,158 +1,43 @@
-## A3 系统架构分册（game-gdd-architecture）
-
---
-name: game-gdd-architecture
-description: 写游戏策划案（GDD）系统架构时使用。在顶层设计定稿之后，
-  把顶层的能力范围正式切成 Sxx 系统：编号、职责、依赖、数据流、优先级，
-  并向系统文档交付目录映射与 MVP 闭环。配套：templates/architecture.md、
-  templates/analysis.md（全局一份）、exemplars/stardew-architecture.md、templates/stardew-analysis.md（全局一份）。
---
-
 # 系统架构写法（策划 · 系统架构分册）

-> 本文件是系统架构层唯一承载写作流程的教学件。
-> 模板与例子文件保持纯净：不含任何步骤、检验提示与标记。
+产物：`project/02_architecture/design.md`。
+参考资源：`templates/architecture.md`、`exemplars/stardew-architecture.md`；全局分析文档的模板与样例：`templates/analysis.md`、`templates/stardew-analysis.md`。

-## 〇、结构适配原则
+## 判断立场

-根据游戏类型、项目规模、用户要求和顶层设计选取本分册的适用内容，同类项可合并；复杂项目可以拆分补充，简单项目可以压缩为最小可用架构。
+将已确定的玩法与版本范围划分为职责清晰的系统，说明系统如何协作、谁维护关键数据，以及后续系统文档从哪里展开。

-## 一、这一层的判断立场
-你是架构师，切系统的刀在你手里。在这个层里你相信：
- 为需要独立职责、状态或数据边界的部分拆分系统，使其**职责清晰、可独立讨论**；每个实际拆出的系统应能说明删除后的影响。
- **数据所有权唯一**：同一事实只由一个系统维护，其他系统只引用稳定 ID，
-  不复制主数据。两个系统管同一件事 = 架构事故。
- **依赖无环**是硬要求；信息呈现层只读状态、只经行动入口写入。
- 架构是全项目返工最多的一份（实测 11 版 vs 概念层 2 版）——所以每次改刀
-  都要写变更记录，让"为什么这么切"可追溯。
- 你不越层：上不重定义玩法过程（那是顶层的），下不写单系统内部规则
-  （那是系统文档的），字段定义与数值配置归技术文档层（数值策划）。
+按职责、状态和数据边界决定拆分或合并，不预设系统数量，也不要求每个系统都属于首个可玩版本。同一事实应有明确的权威维护方，避免多处独立定义或修改。不把自己的建议写成用户已经作出的决定。

-## 二、动笔前
-1. 顶层设计已定稿可用——以其中的玩法过程、能力范围、版本边界和验证计划为输入；
-   按职责拆分、合并系统，不要求与顶层清单逐项对应。需要改变已定范围时先讨论相关决定。
-2. 读取 exemplars/stardew-architecture.md 了解内容组织方式，
-   然后往 templates/architecture.md 里填。
-3. 根据顶层已有的文字、表格或图检查玩法覆盖，不要求额外补画固定循环图。
+## 动笔前

-## 三、架构设计的组织维度：写什么、为什么、怎么咬合
+结合已获批的 `project/01_top_design/design.md`、概念设计、已有对话和项目资料开展设计，模板与样例按需参考。承接实际玩法、能力范围、版本边界与验证计划，不要求顶层清单逐项对应独立系统。

-架构文档回答四个问题：
-**这个架构为什么这样切（1~3）→ 系统是什么、怎么连接（4~6）→
-怎么落地、怎么验证（7~11）→ 还有什么没想清（12）。**
+发现已确定的玩法或范围与新的约束冲突时，说明影响并讨论相关决定；发现划分问题时，调整受影响的职责与协作关系。

-第 1 节承顶层已确定的范围与约束开篇，MVP 闭环在中间当守门员，开放问题收尾。
+## 内容组织

-| # | 节 | 是什么 | 为什么写 | 和谁咬合 |
-|---|---|---|---|---|
-| 1 | 架构定位与目标 | 阶段边界（定哪些系统、不展开内部）+ 划分原则 + 一句话架构 + **变更记录** | 防止架构漂离顶层；改刀可追溯 | 承顶层已确定的范围与约束；必要时引用相关分析 |
-| 2 | 系统地图 | Sxx 编号清单（=系统文档范围真源）+ 支撑层 + P0 段五列表（目的/输入/输出/P0原因） | 编号让系统可引用；P0 原因逼答"删了塌什么" | **对下真源**：Sxx ↔ 04 系统文档一一对应 |
-| 3 | 系统职责 | 职责表（负责/不负责→移交谁）+ 逐系统说明段 | 边界写死，防两个系统管同一件事 | 系统文档的"边界与非目标"必须与此对齐 |
-| 4 | 依赖与数据流 | 依赖图（无环）+ 数据流图 + 主要状态 + 主数据归属规则 | 谁读谁、数据从哪到哪——接口的真源 | 顶层的资源与进展关系在此展开成系统级 |
-| 5 | 玩法覆盖检查 | 顶层玩法环节与关键规则 → 负责或协作系统 | 防止系统切分遗漏玩法能力 | 对照顶层已有的玩法描述，检查职责覆盖与分工 |
-| 6 | 目录映射 | 职责 → 物理文档目录的归并表 | 职责数≠文档数；归并规则显式化 | **对下接口**：系统文档照此开工 |
-| 7 | MVP 最小闭环 | 编号验证链 + 守门句（"闭环不成立不许加东西"） | 立项后第一条要跑通的链 | 对应顶层验证标准；失败回顶层而非加系统 |
-| 8 | 统一数值基准 | 单位清单 + 四类定性基准（时间/货币/成长/体力风险的风格约束） | 各系统单独配数值会互相失衡；先定全局尺度 | **数值换算与验算归技术文档层**，此处只到定性 |
-| 9 | 系统边界 | 哪些功能明确不属于任何系统/归引擎层/归呈现层 | 显式排除，防范围蔓延 | 承概念层"不是什么" |
-| 10 | 优先级与范围 | P0/P1/P2 三档（P1/P2 可用能力表） | 拆分≠全做；裁剪顺序显式化 | P0 = MVP 闭环的系统集 |
-| 11 | 风险与校验 | 风险/校验方式表 | 架构级风险提前挂出，每条带检验法 | 对应顶层验证标准与概念层跑偏风险 |
-| 12 | 开放的结构问题 | 结构级未定案 | 显式债务 | 进分析文档或系统文档开题 |
+根据项目实际复杂度选择组织方式，同类内容可以合并，复杂部分可以拆分。不适用的内容省略，有意义但信息不足的内容保留已知信息与待补问题。

-咬合一图：
+- **系统与职责**：为系统保留 Sxx 编号，说明支撑的玩法能力、负责的状态或规则，以及当前版本包含的部分。容易混淆的职责再说明由谁负责，不要求每个系统填写相同的排除项。
+- **协作与数据归属**：说明关键行动经过哪些系统、传递什么信息、由谁确认和更新结果。区分调用依赖、事件通知、数据读取与玩法反馈；使用图时说明箭头含义。双向交互或资源循环不等于错误，重点检查循环调用、职责纠缠和更新顺序不清等实际问题。
+- **共享状态与约束**：明确关键状态、主数据的权威维护方，以及实际需要跨系统统一的单位、规则和参数。系统间通过稳定标识引用对象；只读副本、派生视图和存档快照应说明来源及更新或恢复方式，不成为独立维护的另一套事实。呈现层展示状态并通过行动入口发起修改。
+- **系统文档映射**：说明各系统的文档位置，使用 `project/03_systems/...` 路径。多个职责可以合并成文档，复杂系统也可以拆分说明，只要编号、职责和位置对应清楚。策划文档的组织不决定实现代码的目录，代码组织由 TDD 明确。
+- **实现范围与验证**：承接顶层版本与原型范围，说明先实现哪些能力、依赖哪些协作，以及用什么可玩流程验证。完整版本与各次原型分别写清，可以只实现某系统的一部分，不固定优先级档位或流程跨度。验证出现问题时，依据原因调整玩法、系统划分或实现，不预设必须退回某一层。
+- **风险与未决问题**：保留影响系统边界、协作或范围的实际问题，说明影响及解决或验证方式。影响当前架构成立的问题应先解决，其他问题按需要留给后续展开。

-```
-顶层玩法过程、能力范围与版本边界
-        ↓ 正式切分（拆/并/裁）
-1 定位与目标 ──► 2 系统地图（Sxx 真源）──► 3 职责表
-        ↓                ↓                      ↓
-5 玩法覆盖检查 ◄── 4 依赖与数据流（接口真源）
-        ↓
-6 目录映射 ──► 7 MVP 最小闭环（守门员）
-        ↓
-8 数值基准（定性）· 9 边界 · 10 优先级 · 11 风险校验
-        ↓
-12 开放问题 →（进分析文档 / 系统文档开题）
-```
+## 展开深度

-三个接口：**对上**承顶层能力范围并跑玩法覆盖检查；**对内**地图↔职责↔依赖
-三方一致、主数据归属唯一；**对下**目录映射 + MVP 闭环喂系统文档。
+写清判断系统划分与协作所需的信息，必要的内部规则、字段或参数可以保留。详细系统行为留给系统文档，完整实现规格、表结构和配置由 TDD 收编并补齐；不因分层而删去已经明确且影响架构的信息。

-## 四、怎么写（模板参考结构，建议按此组织）
-（本节是带写法要领的教学版；实际填写的纯净模板在 templates/architecture.md）
+## 分析参考

-### 1. 架构定位与目标
-本阶段确定哪些系统支撑已确定的玩法与版本范围，不展开单系统内部规则。
-划分原则：__。一句话架构：
-> （玩家通过哪些系统完成主要行动，结果如何推动过程继续或结束）
-变更记录：日期 + 改了什么 + 为什么，必要时引用相关分析。
-→ 没有变更记录的架构文档，第二轮迭代就会变成黑箱。
+可关注系统拆分、接口和数据归属中的重要取舍，按需保留依据与当前结论，不逐次记录修改流水。按需参考 `templates/analysis.md` 和 `templates/stardew-analysis.md`。

-### 2. 系统地图
-Sxx 编号清单（核心系统通常 1-5 个，有明确要求可超出 5 个）+ 支撑层（存档/UI，不拥有核心规则）。
-P0 段五列表：
-| 系统 | 目的 | 输入 | 输出 | P0 原因 |
-→ 对实际拆出的系统说明删除后的影响；无法形成独立职责的部分合并，不为满足数量新增系统。
+## 交付检查

-### 3. 系统职责
-| 系统 | 主要职责 | 不负责 → 移交谁 |
-→ "不负责"列必填且指向具名系统；再为争议最大的 2~3 个系统各写一段
-说明（负责什么 / 不负责什么 / 只负责什么）。
-
-### 4. 依赖与数据流
-依赖图（mermaid，呈现层用虚线"读取状态"）+ 数据流图（资源从产到耗）。
-主要状态：全局/玩家/场景/社会 四类。
-主数据归属规则：规则与数据表分工 / 稳定 ID 关联 / 任何系统不复制他系统主数据。
-→ 依赖图出现环 = 回去重切。
-
-### 5. 玩法覆盖检查
-| 顶层玩法环节或关键规则 | 负责或协作系统 |
-→ 对照顶层已有的玩法描述，检查当前范围内的能力是否遗漏；多个系统共同支持一个环节时，明确分工，避免同一职责由多个系统重复维护。
-
-### 6. 目录映射
-| 目录 | 本阶段定位 |
-→ 职责可以归并进同一文档目录（官方版 8 职责→3 文档）；归并规则写明。
-系统文档以此开工：地图上没有的系统不许有文档。
-
-### 7. MVP 最小闭环
-依据顶层的版本范围与验证计划，确定最先实现的完整可玩流程；可以是线性推进或循环，不固定为单个体验片段。
-1. __ 2. __ …（编号验证链，一条玩家可走的完整因果）
-守门句：如果这条闭环不成立，不应继续增加 __。
-→ 闭环失败回顶层改设计，不是加系统打补丁。
-
-### 8. 统一数值基准（定性）
-全局单位清单（如时间片/游戏日/货币/体力/经验）+ 四类风格约束
-（时间节奏/货币量级感/成长回报取向/体力风险档位）。
-→ 只写到定性；具体换算、验算数值由技术文档层（数值策划）承接。
-
-### 9. 系统边界
-明确排除项（不拆出独立 __ 系统 / __ 归引擎层 / __ 归呈现层）。
-
-### 10. 优先级与范围
-P0（最小闭环必需）：__；P1（完整体验）：__；P2（扩展内容）：__。
-P1/P2 可用能力表（能力/说明）控制颗粒度。
-
-### 11. 风险与校验
-| 风险 | 校验方式 |
-→ 结合概念层跑偏风险、顶层关键规则与验证问题识别结构风险，说明相应校验方式。
-
-### 12. 开放的结构问题
-→ 结构级（接口归属/统一格式/合并拆分）才留这里；数值细节不留。
-
-## 五、分析参考
-
-可关注系统拆分、接口和数据归属中的重要争议。
-按需参考 `templates/analysis.md` 和 `templates/stardew-analysis.md`。
-
-
-## 六、自查参考
- 每个 Sxx 都能一句话答"删了它什么塌"吗？
- 顶层当前范围的玩法环节和关键规则是否覆盖完整，协作分工是否清楚？
- 依赖图无环？主数据无一物两管？
- 系统文档拿到目录映射能直接开工吗？
- 有没有字段定义或数值配置偷偷写进来？（该在技术文档层）
- 变更记录补了吗——这次切分和上次的差异说得清吗？
-
-## 七、红线（只有三条）
-1. 不冒充用户决定：用户没说的方向标"待确认"，正文不写死。
-2. 不越层：向上不翻顶层的案，向下不写系统内部规则，数值字段归技术文档层。
-3. 不凑数：系统数量不是成绩，写不出 P0 原因的系统就是该删的系统。
+- 当前范围的玩法能力是否覆盖完整，系统职责与协作是否清楚，有无遗漏或重复维护。
+- 关键状态和主数据是否有明确的权威维护方，交互中的信息与更新顺序能否理解。
+- 版本与原型范围是否一致，各验证流程所需的系统能力是否都已纳入对应范围。
+- 系统编号与文档位置是否清楚，是否足以继续展开系统设计。
+- 是否为了填模板编造系统、图表或约束，或把尚未确定、尚未验证的内容写成定论。
@@ -18,16 +18,18 @@ description: 写单个系统的设计文档（Sxx）时的总纲——通用纪

 ## 一、这一层的判断立场
 你是写单个系统的策划。在这个层里你相信：
- 系统文档是**执行层**：刀已经在架构层切好——服从系统地图编号、职责表
-  边界、依赖图方向，无权改刀；发现切错了，说明问题并提出调整建议，不私自扩边界。
+- 系统文档展开架构确定的系统编号、职责、协作与数据归属；按架构中的文档
+  映射组织内容。发现划分问题时说明影响并提出调整建议，同步受影响的设计。
 - 一个系统文档的成败在**边界节**："不负责什么、移交给谁"那几行是
  防返工价值最高的几行。
- 接口纪律：引用具名系统与具名数据，禁泛称；别家主数据只引 ID 不复制。
- 字段定义、数值配置、表结构不归你——写交接声明，交技术文档层（数值策划）。
+- 接口纪律：引用具名系统与具名数据，禁泛称；通过稳定标识关联权威数据。
+  只读副本或快照说明来源及更新或恢复方式，不独立维护同一事实。
+- 展开行为所需的规则、字段或参数可以保留；完整字段定义、配置与表结构由
+  TDD 收编并补齐，不因分层删去已确定的信息。
 - 系统文档保持基本可读的一致性，但不要求所有系统使用相同章节；结构应服从系统类型和实际行为。

 ## 二、动笔前
-1. 架构已定稿：找到本系统的 Sxx 编号、职责表行、依赖方向——这是合同。
+1. 从已定稿架构中找到本系统的 Sxx 编号、职责、协作与数据归属，以及对应文档位置。
 2. 在 01~12 文件夹里选最接近的系统类型（可组合，如"钓鱼"=05 采集+06 战斗
   的判定部分），读取对应的 `SKILL.md` 与 `模板.md`。
 3. 该文件夹标注"参考例子"的，可先读例子了解写法。
@@ -40,32 +42,32 @@ description: 写单个系统的设计文档（Sxx）时的总纲——通用纪

 | # | 节 | 是什么 | 为什么写 | 和谁咬合 |
 |---|---|---|---|---|
-| 1 | 系统目的 | 一句话：删了它什么塌 | 存在性检验 | 架构 P0 原因的展开 |
+| 1 | 系统目的 | 支撑什么玩法能力 | 说明划分价值 | 架构职责与版本范围的展开 |
 | 2 | 支撑的玩家体验 | 对应顶层目标第几条 | 防系统自嗨 | 顶层设计目标 ↔ 本系统 |
 | 3 | 进入与退出 | 何时进入、何时/如何退出 | 循环的接口时刻 | 顶层的循环环节 |
 | 4 | 玩家行动 | 具名动词组 | 玩家用手玩 | 系统类型卡给动词组 |
 | 5 | 取舍表 | 玩家在本系统内的决策 | 张力在系统内的落地 | 概念张力→顶层取舍表→本表 |
 | 6 | 状态与规则 | 对象/状态/转换/异常，枚举表达 | 定性规则真源 | 架构职责表对齐 |
-| 7 | 数值与数据交接 | 本系统交 TDD 的数据类别+定性约束 | 分层边界 | 技术文档层承接 |
+| 7 | 数值与数据交接 | 数据类别、已确定的规则参数与待补规格 | 实现所需输入 | 技术文档层承接 |
 | 8 | 反馈 | 关键结果何时、以何种方式反馈 | 让实际结果可理解 | 与本系统实际结果对应 |
 | 9 | 内部循环 | 本系统内的小循环 | 系统自己的心跳 | 顶层小循环的组成 |
-| 10 | 输入、输出与依赖 | 消费/交付/依赖谁 | 接口真源 | 架构依赖图逐边对齐 |
-| 11 | 边界与非目标 | 不负责什么→移交谁 | **防返工价值最高** | 架构职责表"不负责"列 |
+| 10 | 输入、输出与依赖 | 消费/交付/依赖谁 | 接口真源 | 与架构记录的协作和数据归属一致 |
+| 11 | 边界与非目标 | 易混淆的职责由谁负责 | 防止职责重叠或遗漏 | 架构中的相关职责边界 |
 | 12 | 开放问题 | 本系统未定案 | 显式债务 | 进分析文档 |

-咬合：**对上**服从架构三条合同（编号/职责/依赖）；**对内**状态与接口不越
+咬合：**对上**承接架构的编号、职责、协作与数据归属；**对内**状态与接口不越
 职责边界；**对下**第 7 节交接喂 TDD。

 ## 四、常见内容的参考写法
 （各系统类型的特殊写法见对应文件夹 SKILL.md；纯净模板在其 模板.md）

-1 系统目的：若删除它，__ 会塌——一句话说不出 = 该系统不该存在。
+1 系统目的：说明它支撑的玩法能力及独立划分的理由，不要求所有系统都是首个原型必需项。
 2 支撑体验：对应顶层目标第__条、调性原则第__条。
 3 进入与退出：按本系统实际存在的入口、退出和恢复路径记录。
 4 玩家行动：记录本系统实际存在的具名动词组；编排类写"安排"动词，活动类写"操作"动词。
 5 取舍表：决策/立即收益/延迟收益/主要代价；需要追溯时引用顶层相关取舍的内容或章节。
 6 状态与规则：对象-状态-转换-异常，全部枚举表达，不许整段散文。
-7 数值与数据交接：列数据类别名 + 设计侧定性约束；字段定义归 TDD。
+7 数值与数据交接：列数据类别、已确定的规则与参数、待补规格；TDD 收编并写全实现所需定义。
 8 反馈：记录本系统关键结果的可理解反馈；存在失败时说明原因和恢复路径。
 9 内部循环：动词链；可拆单次/区域/长期三层。
 10 输入输出与依赖：引用具名系统与具名数据，禁泛称"资源"。
@@ -79,14 +81,13 @@ description: 写单个系统的设计文档（Sxx）时的总纲——通用纪


 ## 六、自查参考
- 目的一句话成立吗？边界节和架构职责表逐行对齐吗？
- 输入输出和依赖图逐边对上吗？有没有泛称漏网？
+- 系统目的与版本范围清楚吗？职责边界与架构一致吗？
+- 输入输出与架构中的协作、数据归属一致吗？交互含义是否清楚？
 - 状态是枚举还是散文？失败路径给了原因和恢复吗？
- 有没有字段或数值偷偷写进来？（该在 TDD）
+- 已确定的规则参数是否保留，交给 TDD 补齐的规格是否清楚？
 - 同构检查：另一份系统文档的读者能按同样方式读这份吗？

 ## 七、红线（只有三条）
 1. 不冒充用户决定：用户没说的方向标"待确认"，正文不写死。
-2. 不越层：架构需要调整时先说明影响，不写字段数值（归 TDD），
-  不替别的系统定规则。
-3. 不凑数：写不出"删了塌什么"的系统直接删除；章节对项目有意义但信息不足时，记录已确定内容与待补问题。
+2. 架构需要调整时说明影响并同步相关设计，不另行定义其他系统负责的数据或规则。
+3. 不凑数：无法形成独立职责的内容可以合并；章节对项目有意义但信息不足时，记录已确定内容与待补问题。
@@ -38,8 +38,8 @@ GDD 是设计真源（给人看、给迭代看）；TDD 是构建真源（给施
  语言协作改素材与代码；预览与导出按所选引擎的平台流程执行。
  一切技术选择先过所选运行时这道闸，不推荐该运行时做不出来的东西；
  TDD 不擅自换运行时。
- **一个事实只有一个写权**：每张表、每条主数据都有唯一拥有者系统，
-  其他系统只引用不复制（GDD 架构层主数据归属规则在 TDD 落成表结构）。
+- **一个事实有明确的权威维护方**：主数据归属在 TDD 中落实为表结构与更新接口。
+  其他系统通过稳定标识引用；只读副本、派生视图和快照须写清来源及更新或恢复规则，不能成为第二套独立维护的事实。
 - **验收通过后扩充内容**：有 blocker 时先修复并重验。
 - **先少量验证再量产**（美术）/ **先建索引再转表**（数据）。

@@ -47,8 +47,8 @@ GDD 是设计真源（给人看、给迭代看）；TDD 是构建真源（给施

 | 输入 | 来自 | 喂给哪件 |
 |---|---|---|
-| 系统范围表 + P0 清单 + 主数据归属规则 | 架构层 | 三件共用（拆表与拆模块依据） |
-| 各系统「数值与数据交接」节 + 定性约束 | 系统文档 | 数据侧（直接订单） |
+| 当前实现范围、系统职责与协作、数据归属及共享约束 | 架构层 | 三件共用（拆表与拆模块依据） |
+| 各系统的数据类别、已确定的规则参数与待补规格 | 系统文档 | 数据侧（实现所需输入） |
 | 核心体验、情绪基调、风格及相关约束 | 概念层相关内容或章节 | 美术圣经（视觉设计依据） |
 | 可复用能力 | 能力库 | 程序侧+美术圣经（带版本与实例化参数） |

@@ -110,7 +110,7 @@ GDD 喂的（系统文档交接节就是订单）；程序侧的加载与验证

 ## A3 系统架构分册（简介）

-本分册说明系统职责、依赖、数据归属、MVP 闭环、目录映射和架构校验。完整内容请阅读 `resources/skills/architecture.md`；架构模板请阅读 `resources/templates/architecture.md`。
+本分册说明系统职责与协作、数据归属、系统文档映射、实现范围与验证。文档映射指 `project/03_systems/...`，实现代码的目录与模块组织由 TDD 明确。完整内容请阅读 `resources/skills/architecture.md`；架构模板请阅读 `resources/templates/architecture.md`。

 ## A4 系统文档分册（简介）

@@ -1,117 +1,33 @@
-### C1 模板_系统架构.md（→ templates/architecture.md）
-
-本模板是参考结构，不是固定清单。只有需要独立职责、状态或数据边界的部分才拆成系统；简单项目可以合并系统和章节，复杂项目可以增加必要的系统与校验。表格中的示例行可按实际系统、风险和问题扩展，不代表数量上限。
-
 # 系统架构：《游戏名》

-## 架构定位与目标
-本阶段确定哪些系统支撑已确定的玩法与版本范围，不展开单系统内部规则。
-划分原则：__。
+产物：`project/02_architecture/design.md`。以下内容按项目需要选用，可以合并或拆分。

-一句话架构：
-> __
+## 系统与职责

-变更记录：
- __（日期 + 改动 + 原因/登记编号）
-
-## 系统地图
-
-| 编号 | 系统 | 一句话职责 | 优先级 |
+| 编号 | 系统 | 职责与负责的状态 | 当前版本范围 |
 |---|---|---|---|
-| S01 | __ | __ | P0 |
-| S02 | __ | __ | |
-（以上为示例，可按实际系统删减或扩充。）
+| S01 | __ | __ | __ |

-支撑层（不拥有核心规则）：__。
+需要说明的职责边界与划分依据：__。

-P0 段：
+## 协作与数据归属

-| 系统 | 目的 | 输入 | 输出 | P0 原因 |
-|---|---|---|---|---|
-| __ | __ | __ | __ | 没有它，__ |
+关键行动涉及的系统、信息传递和结果更新：__。
+关键状态与主数据的权威维护方：__。
+需要统一的单位、规则或参数：__。

-## 系统职责
+## 系统文档映射

-| 系统 | 主要职责 | 不负责 → 移交谁 |
-|---|---|---|
-| __ | __ | __ → __ |
-
-职责说明（争议最大的系统各一段）：
-
-### __系统
-负责 __。不负责 __，也不直接决定 __；只负责 __。
-
-## 依赖与数据流
-
-```mermaid
-flowchart TD
-  A[__系统] --> B[__系统]
-  U[呈现层] -.读取状态.-> A
-```
-
-```mermaid
-flowchart LR
-  A[__来源] --> B[__转化]
-  B --> C[__消耗/投资]
-```
-
-主要状态：
- 全局状态：__。
- 玩家状态：__。
- 场景状态：__。
- 社会状态：__。
-
-主数据归属规则：
- 规则文档描述"如何计算"与"何时发生"；数据表描述"有哪些对象与配置"。
- 系统之间通过稳定 ID 关联。
- 任何系统不复制另一系统的主数据。
-
-## 玩法覆盖检查
-
-| 顶层玩法环节或关键规则 | 负责或协作系统 |
+| 系统或职责 | 文档位置 |
 |---|---|
-| __ | __ |
+| S01 __ | project/03_systems/S01__/ |

-## 目录映射
+## 实现范围与验证

-| 目录 | 本阶段定位 |
-|---|---|
-| 03_systems/S01__/ | __ |
-| 03_systems/S02__/ | __ |
+最先实现的能力与可玩流程：__。
+后续版本或原型的范围：__。
+需要验证的问题、方式与判断依据：__。

-## MVP 最小闭环
-依据顶层版本范围与验证计划，记录最先实现的完整可玩流程，可为线性推进或循环。
+## 风险与未决问题

-1. __
-2. __
-3. __
-
-如果这条闭环不成立，不应继续增加 __。
-
-## 统一数值基准
-全局单位：__。
- 时间节奏基准：__。
- 货币量级基准：__。
- 成长回报基准：__。
- 体力与风险基准：__。
-
-（具体换算与验算数值由技术文档层·数值策划承接。）
-
-## 系统边界
- __（不拆出独立 __ 系统 / __ 归引擎层 / __ 归呈现层）
-
-## 优先级与范围
- P0（最小闭环必需）：__。
- P1（完整体验）：__。
- P2（扩展内容）：__。
-
-## 风险与校验
-
-| 风险 | 校验方式 |
-|---|---|
-| __ | __ |
-（按实际风险逐行补充。）
-
-## 开放的结构问题
- __
-（按实际问题逐条补充。）
+问题、影响及下一步：__。
@@ -24,7 +24,7 @@

 ## 来自 GDD 的功能

-| 系统（P0） | 一句话职责 | 拥有的主数据 |
+| 当前实现范围的系统 | 一句话职责 | 拥有的主数据 |
 |---|---|---|
 | __ | __ | __ |

@@ -55,7 +55,7 @@

 ## 代码组织概览

- 目录结构：__（承架构层目录映射：入口/场景/系统模块各在哪）。
+- 目录结构：__（依据职责与实现需求明确入口、场景和模块位置，不照搬系统文档目录）。
 - 命名与边界：__（文件前缀、模块间允许的调用方向）。

 ## 外部库与 skill 引用
@@ -1,5 +1,12 @@
 # 决策记录

+## 2026-09-27 系统架构按职责与协作组织
+
+- 架构保留系统编号、职责、权威数据归属、文档位置、实现范围和验证，取消固定系统数量、P0 必需性、统一图表与分类、逐轮变更记录。双向交互按含义与更新顺序判断，不以图上有环自动要求重切。
+- 同一事实由明确的权威方维护；只读副本、派生视图和快照说明来源及更新或恢复方式。必要的规则与参数可在架构明确，由系统文档展开、TDD 收编补齐。
+- `project/03_systems/...` 是策划文档映射，不决定代码目录。系统与 TDD 的直接引用按实际范围衔接，TDD 仍须写全当前施工所需规格；星露谷首个原型包含基础采集，单日选择与多日成长分别验证，样例缺口如实列明。
+- 当前规则见[策划 Agent 生产迁移方案第 6 节](../../technical/【技术方案】策划Agent生产迁移与工作区浏览-2026-09-10.md#6-阶段与提示词注入)。
+
 ## 2026-09-27 顶层设计按实际玩法展开

 - 顶层说明游玩过程、关键规则与反馈、资源与进展、选择后果和版本范围；取消固定循环层级、回报数量、资源消耗链、日历节奏和失败档位，允许说明玩法所需的具体参数。
@@ -314,7 +314,13 @@ TDD 的决策记录采用相同原则：施工规格、参数、默认值直接

 原型范围由要验证的问题决定，与完整版本范围分别说明；验证可以结合试玩观察、完成情况、玩家反馈和指标，明确如何形成判断，不把未验证的预期写成结论。星露谷样例按选择双方的收益与代价比较，按场景说明损失与恢复，并区分单日、多日和后续内容的验证范围。

-架构层承接顶层已有的玩法描述、能力范围、版本边界和验证计划，不要求固定循环图、独立“顶层定稿”章节或清单逐项对应系统。玩法覆盖检查允许多个系统协作支撑同一环节，须明确分工，避免同一职责重复维护；仍保留系统编号、职责、数据归属与目录映射等架构职责。顶层短阶段提示和 TDD 中的顶层简介同步使用该口径，TDD 的施工完备要求不变。
+架构层承接顶层已有的玩法描述、能力范围、版本边界和验证计划，按实际职责、状态与数据边界拆分或合并系统，不要求顶层清单逐项对应系统。规则、模板与样例围绕系统职责、协作和数据归属、系统文档映射、实现范围及验证组织；取消固定系统数量、每个系统必须属于 P0、“不负责”必填列、图表格式、状态分类、数值基准分类和逐轮变更记录。重要取舍按需保留依据。
+
+系统交互区分调用、通知、读取与玩法反馈；双向关系不自动判为架构错误，按实际问题检查循环调用、职责纠缠和更新顺序。主数据有明确的权威维护方，只读副本、派生视图和快照说明来源及更新或恢复方式，不成为第二套独立维护的事实。为判断职责和协作所需的规则、字段与参数可以明确，系统文档继续展开行为，TDD 收编并补齐完整实现规格。
+
+保留 Sxx 编号与 `project/03_systems/...` 文档位置，可以按内容合并或拆分文档；该映射不决定代码目录，代码模块与文件组织由 TDD 明确。实现范围区分完整版本、首个原型及后续内容，不固定 P0/P1/P2，也不要求验证失败就退回顶层或禁止调整系统划分。星露谷样例明确 NPC 日程、资源点、物品与经济等归属，首个原型包含基础采集，按单日选择和多日成长分别验证。
+
+系统总纲、相关系统类型资料与 TDD 的直接引用同步承接职责、协作、数据归属和当前实现范围，不再依赖架构 P0 清单、固定依赖图或仅限定性的数值基准。数据侧按实际玩法选择验算场景与跨度；技术侧按当前施工范围收编全部必需行为，不能因某系统标为后续优先级而遗漏当前所需规格。速览卡与 TDD 样例同步首个原型范围，基础采集、跨日结算规格和完整数值验算的缺口如实标明，局部推算不作为验算通过的证据。施工完备要求、产物路径与阶段审批合同保持不变。

 进入下一阶段必须由用户批准触发。Runtime 推进后向 Agent 追加明确的用户行为语义，例如“用户已批准上一阶段，现在进入顶层设计阶段”，避免 Agent 误认为 Runtime 自行推进。