# Cross-GDD Review Report

**Date:** 2026/04/29
**GDDs Reviewed:** 2
**Systems Covered:** Node System, Tower Assembly

---

## 一致性问题 (Consistency Issues)

### 警告级 (Warnings)

#### ⚠️ `TryDisassembleTower` 未实现但 UI 可调用
- **GDD**: `tower-assembly.md` Open Question #1
- **问题**: `node-system.md` R3 规定"组装后可以免费拆解"，Assembly Phase UI 也提供 Disassemble 选项。但 `tower-assembly.md` 明确标注 `TryDisassembleTower` 方法不存在。玩家看到可点击的 Disassemble 按钮但无法使用，属于误导性 UI。
- **建议**: `tower-assembly.md` 应将 Open Question #1 从 "OPEN" 改为标注为 "Blocking — GDD 自洽性受损"，直至方法实现

---

## 游戏设计问题 (Game Design Issues)

### 阻塞级 (Blocking)

#### 🔴 Boss 难度曲线可能无法追赶 — 威胁两大系统核心幻想

**位置**: `node-system.md` Boss Difficulty Scaling 公式；`tower-assembly.md` Stat Scaling

**问题描述**:
- Boss HP 增长: `BossEffectiveHp = DRLevel.BaseHp × 2^(completedLoopCount)` — 指数增长
- 玩家战力增长: Tower Assembly 提供线性成长（每场战斗最多 8 次升级事件，每次 `baseValue + perLevel * i`）
- 在某个 loop 阈值后，玩家数学上无法击败 Boss

**设计后果**:
- `node-system.md` Player Fantasy: "whether I survive **depends on** how I prepare" — 若准备永远不够，此幻想崩塌
- `tower-assembly.md` Player Fantasy: "arrange pieces to solve it" — 若 puzzle 解不开，此幻想崩塌
- 两大系统的核心幻想共享同一个前提：玩家准备应当是充分的

**未知依赖**: `DRMuzzleComp`、`DRBearingComp`、`DRBaseComp` 数据表值未知，无法验证实际成长率

**设计建议**:
1. 在 Boss 战中引入 catch-up 机制（每 loop 玩家获得临时增益）
2. 让 Tower Assembly 存在超线性成长路径（tag synergy、combo 机制）
3. 降低 Boss 的指数系数（从 ×2 改为 ×1.3~1.5）
4. 在 `node-system.md` 中明确说明"Boss 的设计意图是部分玩家无法一次通关"以调整预期

---

#### 🔴 无 Gold 消耗强制机制 — 经济回路开放无界

**位置**: `node-system.md` 经济表格（1100 gold 上限）；`tower-assembly.md` 无 gold sink 定义

**问题描述**:
- 6 场 Combat 节点共 600 gold，Boss 胜利额外 500 gold，最大总量 1100 gold/run
- Shop Node 4 和 8 奖励 0 gold，不强制消费
- 无任何机制（修理费、强制升级、门票等）要求消耗 gold
- **Shop System GDD（待编写）必须定义强制消耗场景**，否则 Shop 节点沦为 UI 空操作

**风险**: Shop 节点存在但内容空洞，玩家跳过购买不打 Boss —— 浪费了 2 个节点的设计价值

---

### 警告级 (Warnings)

#### ⚠️ 塔组装存在显然的最优策略

**位置**: `tower-assembly.md` R7（无组件兼容性约束）

**问题**: 任意 Muzzle+Bearing+Base 组合均可。Rarity Resolution 取算术均值：
- Red(5)+Red(5)+Red(5) → 均值 5.0 → Red Tower
- Red(5)+Green(2)+White(1) → 均值 2.67 → 向下取整 → Green Tower（比单 Red 差）

**结论**: 贪婪地堆最高稀有度组件永远是最优策略，无任何权衡代价。塔组装的最优解是排序后取 top 3，无需战术思考。

**建议**: 引入稀有度以外的优化维度：
- Tag synergy 机制（Fire+Ice 组合产生额外效果）
- Endurance 配平（3 高稀有度 = 3 高损耗率，混合可延长功能性）
- Roster slot 约束下的边际收益（分散稀有度可在 4 槽位限制下覆盖更多敌人类型）

---

#### ⚠️ 节点选择若两条路径难度不同，最优路径显而易见

**位置**: `node-system.md` 节点选择流程

**问题**: 每 junction 显示 2 个目的节点类型。若两条路径在难度/奖励上存在差异（比如两 Combat 但一个是 L1 一个是 L3），"战术决策"退化为"比较两个数字"。

**建议**: 确保两条分支在难度和奖励上等价，或引入隐藏变量（敌人波次、特殊条件）使玩家无法在选择前判断哪个更有利。

---

#### ⚠️ 玩家注意力预算已达上限，无扩展空间

**当前 Assembly Phase + Node Choice 时活跃系统**: 4 个
1. Tower Assembly 决策（选 3 组件组合）
2. Roster 管理（4 槽位分配）
3. 下个节点威胁评估（已知类型 + 难度）
4. 节点二选一（强制决策）

**设计阈值**: 技能定义 >4 时触发警告，当前 = 4（刚好达标）

**风险**: Event System（待设计）若在 Assembly Phase 窗口引入额外主动决策（如事件影响当前备战），预算立即超标。

---

#### ⚠️ Pillar 轻微漂移

| GDD | Pillar 声明 | 实际行为 | 漂移程度 |
|-----|------------|---------|---------|
| `node-system.md` | "players drive their own path" | 节点类型序列固定（Plain 主题下所有玩家路径相同）；Junction 处只选顺序不选类型 | 轻微 — "path" 实为"choice order" |
| `tower-assembly.md` | "adaptation to known threats" | Shop/Event 节点无需塔组装决策；"adaptation" 对 30% 节点不适用 | 轻微 — pillar 覆盖部分场景 |

---

## 跨系统场景问题 (Cross-System Scenario Issues)

**场景走过**: 3 个

---

### 🔴 场景1: 战斗结束 → 组件掉落 → 塔组装（数据流歧义）

**涉及系统**: Combat → Inventory → Tower Assembly

**问题描述**:
Combat 节点完成后，组件掉落通过 `InventoryComponent.AddItem` 进入 inventory。**接口未定义**：
- 掉落的是全新组件实例（InstanceId 新生成）？
- 还是对现有组件的修改（如 `IsAssembledIntoTower` 标记改变）？

**隐患**: 若为后者，而玩家在 Assembly Phase 前一步已组装了某些塔，战损标记可能与已组装组件的状态产生歧义。

**需确认**: `InventoryComponent.AddItem` 的精确语义，建议在 `node-system.md` Dependencies 或接口协议中明确定义。

---

### ⚠️ 场景2: Boss 前夕的 Assembly Phase（难度曲线验证）

**涉及系统**: Node System + Tower Assembly + Combat

**问题描述**:
玩家在 Node 9 完成后进入 Assembly Phase，此时 `BossEffectiveHp` 是可计算的（因 `completedLoopCount` 已知）。玩家可以提前计算胜率。

**风险**:
- 若计算结果为正 → Boss 战是仪式感结局，fantasy 得到验证
- 若计算结果为负 → 玩家感受到"数值碾压"而非"战术压力"，两大系统的核心幻想同时受损

**需验证**:
- `BossEffectiveHp` 是否对玩家 UI 可见（建议：仅在 Boss 血条上显示，不显示计算公式）
- 实际 tower DPT（每秒伤害）是否能与指数增长的 Boss HP 达到动态平衡

---

### ℹ️ 场景3: Degraded 塔在战斗开始时的处理

**涉及系统**: Tower Assembly + Combat

**问题描述**:
`tower-assembly.md` 明确："mid-combat 降级不会自动从 roster 移除"。但 `CombatNodeComponent` 的 roster 验证逻辑未定义。

**两种处理方式的后果**:
- 若验证在战斗**开始**时：degraded 塔被筛除，玩家以 <4 塔对抗预期敌人规模
- 若验证在战斗**进行中**：塔在战斗中失效，战斗难度非线性上升

**建议**: 在 `tower-assembly.md` Acceptance Criteria 中补充：`CombatNodeComponent` 必须在战斗开始前调用 `CombatParticipantTowerValidationService.ValidateParticipantTowers`，拒绝 degraded 塔入战。

---

## GDD 标记需修订

| GDD | 原因 | 类型 | 优先级 |
|-----|------|------|--------|
| `tower-assembly.md` | `TryDisassembleTower` 未实现但 UI 可调用；Open Question #1 应更新状态为 Blocking | 设计完整性 | Warning |
| `node-system.md` | Boss catchability 需在 GDD 中明确设计意图；建议补充"战斗开始前 roster 验证逻辑"的跨系统约定 | 难度曲线 | Warning |
| `systems-index.md` | Combat System 标注"Designed"但 GDD 在 `docs/CombatNodeArchitecture.md` 而非 `design/gdd/`，文档位置不统一 | 文档管理 | Warning |

---

## Verdict: **CONCERNS**

存在 2 个阻塞级问题（Boss catchability + 无 gold sink）和多个警告级问题。阻塞问题不会阻止架构设计，但应在 `/create-architecture` 前明确设计意图。

---

## Next Steps

- `/design-system shop` — 编写 Shop System GDD（阻塞项：gold sink 定义）
- `/design-system event` — 编写 Event System GDD（阻塞项：EventContext 合约）
- `/design-system progression` — 编写 Progression GDD（阻塞项：RunEnd 数据持久化）
- `/design-review tower-assembly` — 修订 Open Question #1 并更新 TryDisassembleTower 状态
- `/create-architecture` — 在所有 MVP GDD 完成后开始架构设计（Verdict 为 CONCERNS 但非 FAIL）