gplan-2/design/gdd/analysis/c2-adventure-structure.md

C2 冒险结构 设计推演

状态：concluded · 本文只装"为什么"——design/gdd/c2-adventure-structure.md 只收本文的结论。 修订时新增问题节，不删旧节（历史即依据）。 本文由 v1（lean 全文，2026-09-14）两件套迁移而来：原文的公式推导过程、数值锚定论证、候选取舍、体验锚点论证与已裁决争议按问题归位；文末附开放问题、历史审计与去向映射（零丢失审计表）。

问题一：冒险骨架为什么是"N=2 线性序列 + 死亡即终"，序列为什么必须被内容覆盖锁死？

广度分析

• 候选 A：维持切片现状（单关 N=1）——收益是零新增内容即可运行；代价是承载不了 P4"不断下探更险的层"的序列感，也没有 P1 要的冒险级对照物（"这局我到第几层"没有坐标）。
• 候选 B：线性序列 MVP N=2（L1 地牢基线 → L2 雾解锁 + 数值台阶）——收益是用最小内容批同时给出可感知难度台阶（通关率带下移 + 雾解锁 + 数值跳升）与冒险级坐标；代价是 N=2 生效前提 = C3 L2 深度轴行值（enemy/board_gen 的 (2, D1–D4)）填充批，未落地期只能以 N=1 合法态运行。
• 候选 C：更长或带分支/跳关的序列——收益是逼近愿景单局 20–40 分钟（OQ1）；代价是扩关 = 内容批（链行 + 敌我数值 + 变异解锁同批落），MVP 期内容缺口风险最大，且跳关/回头路与 MVP 线性语义冲突。序列扩展走修订批，不许静默加回。

深度分析

序列覆盖义务把"冒险长度"从运行时问题变成内容生产问题：冒险关数 ⊆ 表内容覆盖，运行时战斗表 floor 兜底属 D2 既有语义，C2 不产生越界请求、玩家不可达越界关——越界关卡 = 内容生产缺口，必须在冒烟期被断言拦下（行集内每个 battle/boss 节点 (L,D) 在 enemy/board_gen 两表有精确行 + 序列关数断言，D2 跨表校验复用），而不是运行期被兜底吞掉。关卡行缺失同理是序列配置事故、fail-fast 处置，与战斗表 floor 兜底分属两层。

难度总闸在 N：P_run = Π P(L_i) 是乘法合成——N=2 合成带 [6%, 20%]（L1 [30,50]% × L2 [20,40]%，L3+ [10,25]% 预留）对应 Roguelike"多数局止步中途"的体感；每加一关带再乘一次，所以扩关节奏必须用真人单关时长数据裁决（OQ1），不能拍脑袋加关。链模板（battle D0/D1 → reward → battle D2/D3 → rest → boss D4，7 节点 5 战斗深度）与深度标号规则（前序战斗节点计数、Boss = Dmax、reward/rest 不占深度不查战斗表）让 L1/L2 同构复用、加关只动内容批不动结构。

综合判断

定案：MVP N=2 线性序列（无跳关、无回头路），死亡即冒险终；通关 = Boss 战胜利（C3 Boss 通关编排归属 C1/C2 域——game-concept 冒险语义承接）；序列覆盖由冒烟断言 + D2 跨表校验承接；A4 雾 unlock_level=2 是 L2 台阶的内容面（序列难度排布消费）；扩关节奏归 OQ1（playtest 批次 2 后，C2 + C3）。

问题二：HP 为什么一条血走完整个冒险、恢复为什么只留恢复点与大奖励两个显式口？

广度分析

• 候选 A：每关开始回满（切片现状）——收益是关卡间难度解耦、无需账本；代价是"Boss 前把血囤满"的囤积决策消失，P3 塌掉，冒险没有资源压力曲线。
• 候选 B：跨战斗 HP 账本 + 两个显式回血口——收益是血成为冒险内唯一带得走的资源、恢复点位置 = 决策压力点；关卡切换零结算、账本收支四口（置满/交出/收回/入账）结构简单可测；代价是要给 C1 增 report_battle_end / heal_clamped 两个上报口，并经 begin_battle 覆盖值通道供值。
• 候选 C：大奖励改部分恢复——收益是削弱对满血口径的强依赖；代价是 C3 逐关通关率带按每关满血开局校准，大奖励血回满正是该口径跨关成立的闭合件——改部分恢复则 F1 合成式整体失效、须改口径；否决，仅在 OQ2 大奖励形态扩展时重审。

深度分析

跨战斗 HP 持久性归 C1/C2 是已锁事实——B2 单位接口以初始 hp 入参、零变更，C2 以账本兑现自己那半边；B4 关内库存跨战斗延续与账本同构。三套跨战斗生命周期口径对齐：buff 战斗域清（B1）、RAP 战斗域清（A3）、库存关卡域清（C1 收束点）、血冒险域延续——冒险内无跨关遗留物，冒险层账本与摘要是唯一跨关状态。

clamp 边界：账本三写口全部 clamp [0, max_hp_eff]；恢复点满血触发回 0 合法（账本静默——无明细行协议，与战斗域"奖励未生效"族不同层）；defeat 腿 = 0 与"死亡即冒险终"闭合，不存在"带着 0 血进下一战"的中间态。max_hp_eff = HeroTable.max_hp + Σ大奖励提升——恢复比例 rest_heal_pct 随上限加成同步放大，防止高上限档恢复失效（切片 30 转正 provisional，数值复验归 C3）。

综合判断

定案：F2 账本结算式——战后回写 / 恢复点比例回血（floor(max_hp_eff × rest_heal_pct ÷ 100)）/ 大奖励回满三写口全 clamp；血条跨关只降不自动回。切片"每关开始 HP 回满"转正改写为跨关延续，恢复只来自恢复点节点与大奖励两个显式口。依据链：B2 hp_persistence 归 C1/C2、B1 begin_battle 覆盖值入参、B4 关内延续同构。

问题三：关卡大奖励为什么是三件固定构成、为什么末关不兑付、为什么不进库存？

广度分析

• 候选 A：发进背包的物品——与库存裁决冲突：库存生命周期 = 关卡域，收束点已清空，跨关携带违背"关卡末清库"既定语义；且奖励内容/库存语义归 B4/C3，C2 不碰库存域。否决。
• 候选 B：三件固定（上限 +10 / 血回满 / 代币 +10/关）——上限提升经 begin_battle 覆盖值通道传入后续每战（hero 表运行期不可变，覆盖值是唯一合法提升通道）；回满与 C3 满血开局校准口径闭合（问题二）；代币给 C4 一个干净入账位（levels_cleared 乘子）。
• 候选 C：三选一 / 攻击型 / 通关加成等扩展形态——MVP 无元进度消费面；AdventureTable 扩列结构位已留，随 C4 元进度设计（OQ2），通关加成位预留不启用（裁决归 C4）。

深度分析

末关不兑付的机理：上限提升只对"下一战"有收益，末关通关后没有下一战可受益——此时兑付是死数值，还虚增摘要口径；代币照记（乘子是 levels_cleared，不受影响）。

时点约束"收束清库之后、下一关开始之前"不可换：清库（B1 level_clear）在收束点已由 C1 触发，大奖励若插在清库前会被关卡域清空吞掉。上限 +10 的值锚是 C3 区间平移换算率（+10hp ≈ +1 轮）——回满 + 上限共同抬开局强度，上调须 C3 重扫 L2 通关率带；累加语义（每关一份，N=2 冒险至多一次）让多次兑付不产生重复歧义。

综合判断

定案：三件固定构成；F3 记账式 tokens = levels_cleared × token_per_level，通关与中途死亡同式、差异只在 run_completed 标记；末关不兑付；不进背包不占库存域。依据链：B4 库存关卡域裁决、C3 区间平移换算率锚、C4 记账位。

问题四：失败重开为什么是全新冒险、放弃为什么同失败型、种子域单位为什么是冒险？

广度分析

• 候选 A：关卡重试 / 检查点——直接违背 game-concept"死亡则冒险结束"已锁语义。否决。
• 候选 B：重开 = 全新一轮（新种子 / 第 1 关 / 满血 / 空手）——每局是新局面而非同一关复读（P1 锚点）；保留面只有冒险摘要（坐标对照），清零面 = 账本 / 库存 / 种子域，Roguelike 重开纯度最高。
• 候选 C：切片逐关播种 + 逐关重置——切片无冒险层的历史简化：逐关播种使冒险不可复现（快照契约域单位 = master_seed + 三流计数器对不上），转正改写为冒险域单种子、关卡间 RNG 连续。

深度分析

放弃同失败型：差异只在 run_completed 标记与"玩家主动"；已到手的保留（已获大奖励不追回）——追回需要回滚大奖励三件，复杂度全在边界上且无体验收益。战斗中拒绝受理（战斗域单事务在飞），入口呈现仅非战斗期可达；MVP 无 UI 入口，语义预留归 OQ4 / D1。

种子接线：注入时点 = 冒险开始恰一次，冒险内雷图生成 / 奖励抽取 / 遭遇掷骰全部派生自该种子、冒险内不重置；重开种子与上局相同是合法态（熵源小域）——约束在通道而非值：种子生成禁走玩法随机通道、冒险内计数器随 reseed 归零，生成器归属归实现期 ADR（OQ3）。零流消费（RngService open_stream 零命中）让"冒险可复现域"有静态可验的判据（AC-8 静态扫描）。

综合判断

定案：死亡即冒险终（无关卡重试、无检查点）；重开 = 全新一轮，保留面 = 摘要、清零面 = 账本/库存/种子域；放弃同失败型、非战斗期受理；一次冒险一粒种子、冒险 = 快照契约域单位（D3 复盘消费 master_seed）。依据链：game-concept 死亡即终、A3 RAP 战斗域生命周期、registry rng_service 快照契约 + D3 消费方。

问题五：C1/C2 编排边界为什么收束点在 C1、C2 为什么零直调？

广度分析

• 候选 A：C2 直调 B1 战斗/清库——冒险层同时侵入战斗域与库存域，收束点语义分裂：库存清空触发源不唯一，时序归属扯皮。否决。
• 候选 B：收束点在 C1（先调 B1 level_clear、再向 C2 宣布 level_end）——库存关卡域清空触发源唯一（C1 收束点），C2 零战斗域直调、零库存域直调，只守账本写口与收束监听。
• 候选 C：收束点在 C2——C2 需要监听战斗内部状态才能判收束，跨层反向依赖，违背"C1 拥有关内行进"的切分。

深度分析

先例转正：切片 level_runner 的关卡域生命周期切两半——冒险域（序列推进 / HP 账本 / 大奖励 / 重开 / 种子）归 C2 侧新 owner，关内行进与节点兑付触发归 C1。B1 出口分发既定语义"关卡结束 = 上层显式调用"由 C1 收束点承接。

接口契约四件套（start_level / report_battle_end / heal_clamped / level_end）+ 战斗发起组装权是 C1 GDD 强制输入——C2 在 C1 之前设计，边界措辞即 C1 接口基线，C1 定稿须全款承接核对（门禁评审项）。战斗发起组装：深度取链位、关卡序号与血条取 C2 下放、hero_atk 走表值通道（MVP 冒险内不提升攻击）。防御双层：英雄死亡但战斗判定胜利为结构不可达（B1 判定 hero 先判），cleared 收束另有账本 hp > 0 防御断言——不依赖运行时序的单点正确。

综合判断

定案：C1 拥有关内一切行进与收束点，C2 只接结果；四件套 + 组装权成文为契约表（design 领域六）；对侧义务全款列入 design 依赖与输出的活契约台账（C3 L2 行值批 / D2 种子注入入口 + AdventureTable 建表 / B1 begin_battle 入参供给方转正 / C1 全款承接核对 / C4 远期消费 / registry 三条目登记）。

开放问题（原文 OQ 全量，编号不动）

#	悬案	owner	时机
OQ1	冒险长度扩展节奏——MVP N=2（约 15–25 分钟）vs 愿景单局 20–40 分钟；扩关 = 内容批，节奏按真人单关时长数据定	C2 + C3	playtest 批次 2 后
OQ2	大奖励形态扩展（三选一 / 攻击型 / 通关加成）——AdventureTable 扩列结构位已留，设计随 C4 元进度	C2 + C4	C4 GDD
OQ3	master_seed 生成源（熵源通道禁走玩法随机——种子值生成器归属）	D2 / 实现期 ADR	实现期
OQ4	放弃入口呈现与受理细节（仅语义已定：非战斗期受理、同失败型结算）	D1	D1 / UX 批
OQ5	L2 display_name 表现层命名（provisional 名"第二层 · 雾漫巢径"——风格对齐 L1"苔藓回廊"）	C2 表现层	L2 内容批

迁移校验说明：未发现原文内部或原文与 registry 之间的数值/规则冲突；无新增待拍板项。唯一迁移副作用：registry hero_override_parameter_passing.adr_status 引用"C2 GDD 规则 3/4"作为 HP 账本供值的定义源——v2 迁移后 C2 规则改为领域内编号（对应现 design 领域三规则 1 与领域四规则 1–2），该跨文档编号引用失真，registry 修订归 owner 批处理（本迁移批禁碰 registry）。

附录 A：历史审计（自 v1 正文迁入，非现行规则）

• 复核注记（v1 定稿时）：v1 solo 出稿 → 经 /design-review（--solo 快速审批）APPROVED（0 blocking / 3 recommended——recommended 随下次修订批执行）；专员/总监代理未咨询——生产前人工复核保留。评审日志：design/gdd/reviews/c2-adventure-structure-review-log.md。
• 状态沿革：v1 出稿时状态头 In Design → v1.1 评审通过同步为 Approved（零规则变更），详见 design 件版本历史。
• C2 是结构系统——运行时零新增公式；F1 为设计期工具式、F2/F3 为账本结算式，全部数值 provisional，调参所有权见 design 调参表（v1 数值节导语，随迁）。

附录 B：去向映射（零丢失审计表）

原文（v1）节/表	落点
头部（状态/版本/作者/承载支柱/一句话/复核注记）	design 头部（状态/版本/一句话/推演件）+ 设计目的定位段（支柱）；复核注记 → 本文附录 A
速览·定位 / 拥有（7 项） / 不拥有（6 项）	design 设计目的定位段 + 系统范围（负责/不负责两清单，归属括注保留）
速览·上游输入 / 下游输出	design 依赖与输出主表对应行接口要点
速览·硬约束（零随机/序列覆盖/死亡即终/不碰库存域）	领域一不变式 3（零流消费）+ 领域五规则 4（单一种子注入点）+ 领域二规则 2（序列覆盖）+ 领域五规则 1（死亡即终）+ 领域六规则 3（不碰库存域）
体验锚点表（4 行：P4/P3/P1/锚点时刻）	design 设计目的编号承诺 1–4（关键词与机制承诺逐条保留）
全局流程·冒险生命周期字符画	design 核心循环与冒险生命周期（等义压缩重排，全部分支与标签保留）
全局流程·出口分发表（4 行）	design 核心循环出口分发表（原文保留）
核心规则 1（冒险骨架）+ 依据	design 领域二规则 1；依据链 → 本文问题一综合判断
核心规则 2（序列覆盖）+ 依据	design 领域二规则 2 + 细则表；依据链（D2 跨表校验 / C3 期望表与 OQ1 / A4 unlock_level=2）→ 本文问题一
核心规则 3（HP 账本）+ 依据	design 领域三规则 1–2；依据链（B2 hp_persistence / B1 begin_battle 入参 / B4 关内延续同构）→ 本文问题二
核心规则 4（大奖励）+ 依据	design 领域四规则 1–3 + 构成表；依据链（B4 库存关卡域 / C3 平移换算率 / C4 记账位）→ 本文问题三
核心规则 5（失败重开）+ 依据	design 领域五规则 1–3；依据链（game-concept 死亡即终 / A3 RAP 生命周期）→ 本文问题四
核心规则 6（种子接线）+ 依据	design 领域五规则 4–5；依据链（registry rng_service 快照契约 / D3 消费方）→ 本文问题四
核心规则 7（C1-C2 编排边界）+ 依据	design 领域六规则 1–3 + 契约表；依据链（B1 出口分发 / level_runner 先例转正）→ 本文问题五
规则 2 细则表（5 行）	design 领域二首表（原文保留）
规则 4 细则表（3 行）	design 领域四构成表（原文保留）
规则 7 细则表（接口契约 6 行）	design 领域六契约表（原文保留）
枚举·冒险结果（3 值）/ 关卡收束结果（2 值）	design 领域一"结果与收束枚举"合并表
枚举·冒险摘要（5 字段）	design 领域一冒险摘要表（原文保留）
F1（结论/推导/变量/验算）	design 领域二 F1（结论 + 表达式 + 变量表 + 验算表原文保留）；推导论证 → 本文问题一深度分析
F2（结论/推导/变量/验算）	design 领域三 F2（原文保留）；口径与边界论证 → 本文问题二
F3（结论/推导/变量/验算）	design 领域四 F3（原文保留）；末关不兑付机理与扩展取舍 → 本文问题三
状态表（3 态）+ 不变式（5 条）	design 领域一状态表 + 不变式规则 1–3（hp ∈ [0, max_hp_eff] 并入不变式 1）
边界情况表（11 行）	逐行内联：末关 Boss 胜利 → 领域四规则 3 + 领域一；start_level 越界 → 领域二规则 4；内容缺口 → 领域二规则 3；level_end 重复宣布 → 领域一不变式 2；恢复点满血 → 领域三规则 4；上限已有加成 → 领域四规则 2；战斗中放弃 → 领域五规则 3；死亡但判胜 → 领域一不变式 4；重开种子相同 → 领域五规则 5；跨关遗留物 → 领域三规则 2；关卡行缺失 → 领域二规则 4（"对齐 C3 边界情况表 / B1 判定段"两处依据 → 本文问题一/问题五）
依赖表（上游 6 行 / 下游 5 行）	design 依赖与输出主表（原文保留，B1 上下游两行分开保留）
跨 GDD 义务清单（7 行）	design 依赖与输出·跨 GDD 义务台账表（活契约，原文保留）
Tuning Knobs（5 行 + 非 knob 冻结清单 + knob 交互）	design 调参表（knob 列改 owner 列，域/默认/说明保留，provisional 标注）+ 表下两行注记；交互机理 → 本文问题二/三
验收标准 AC-1–13	design 验收标准 GWT 表（编号与内容不动）
开放问题 OQ1–5	本文开放问题区（编号不动）
版本历史 v1 / v1.1	design 版本历史（原行保留）+ 追加 v2 迁移行