DKChan
7aee5eb71a
两文件是流水线流程件而非游戏描述件，此前住在 design/gdd/ 造成三处不适配： gdd_lint 必须为它们逐条关掉体裁规则、格式权威却写在 doc-conventions §12、 与同族的 roadmap（在仓库根）分居两处。迁到根后按 roadmap.md 的无编号风格改名。 - 迁出：design/gdd/06-待办清单.md → 待办清单.md；07-体验验证清单.md → 体验验证清单.md - 指向改写 53 个文件：GDD 各系统文档指路存根、四份规约、02 根索引、README/roadmap/AGENTS - 两份清单自身 74 处出站链接按新基址重指（../art → design/art、systems → design/gdd/systems） - gdd_lint：待办/体验验证两文件的 R1/R3/R5/R7 豁免行随迁删除（已脱离扫描面），后门表清零 - pipeline_gate 默认路径、log_analysis/render_gate 称谓、repo_structure_audit 根文件白名单同步 - 保护面补写：两份清单列入实现批禁写清单（AGENTS 两类批条 / process-conventions §12 / 架构文档域表）， 条目状态只由流水线各段推进 - 范围外未动（用户令「全不碰」）：reports/ 与 design/research/ 的 22 处历史指向、game/ 两处注释
25 KiB
增益状态
一句话：增益/减益状态的容器、叠层与衰减 状态：已定稿（自旧体系迁移）
设计目的
战斗里有一类效果不在当场一次性用掉，而要管上几次结算：挖开安全格拿到的主角增益、封印标中带来的怪物削弱、踩雷喂给怪物的增强（警觉——blast 型负向）、标错封印招来的负向兑付，都是这类。本文把它们统称"状态"：发给主角的有益效果叫增益（失衡与乏力是例外——它们是发给主角的减益），发给敌人的负面效果叫减益；敌方侧的增强同样是状态——几个方向共用一本账。
增益状态就是这本账：一个容器收下全部状态，用同一套规矩管理——发入、合并（同一种效果重复拿到时按表行策略处理：叠层加一，或只刷新剩余次数——读 status_effects.tres 逐行 stack_policy）、衰减（每次结算后剩余次数减一，减到零效果消失）、清空（战斗结束全部清除）。没有它，几类效果得各写一套计时逻辑，结算明细也无法逐行指回"这效果是我哪步棋带来的"。容器管机制、不管数值从哪来：某个效果该多大，由各收益系统的表去定，容器只照章入账、按次衰减。
系统范围
边界这样划：容器只管"效果存进来之后"的一生——受理、存续、倒数、清空。效果"该不该发、发几次"由战斗结算在轮末兑现时裁决，容器只记账；"发进来之后在伤害公式里怎么用"是战斗结算的消费侧规则；"画成什么样"归呈现层。
负责：
| 负责 | 说明 |
|---|---|
| 状态实例生命周期 | 授予受理、存续、到期移除、战斗结束清空；寿命以一场战斗为界 |
| 时限、叠层、衰减语义 | 按"结算次数"倒数、同名效果按表行策略合并、先兑付后衰减（见核心规则） |
| 归因记录 | 每笔状态随身携带来源类别、来源格、第几轮，供结算明细逐行指认 |
| 状态表的回填责任 | 状态定义表的字段与 MVP 内容行在本系统定稿；表本体经数据配置承载 |
不负责：
| 不负责 | 归谁 |
|---|---|
| 事实产生与授予裁决（去重、恰好一次） | 战斗结算 |
| 效果在结算公式里的用法（乘除侧读法、地板、作用顺序） | 战斗结算 |
| 增益与削弱档位的当量对照验收 | 地图战斗资源与战斗结算 |
| 状态栏、图标、明细行的呈现 | HUD 框架 |
在核心循环中的位置
扫雷阶段：挖格 / 封印 / 踩雷 ──(事实流)──▶ 战斗结算（轮末逐行兑现）──(授予 / 查询兑付 / 衰减)──▶ 增益状态 ──▶ 效果落进结算公式
增益状态站在轮末结算这一段，是战斗结算身后的状态仓库：扫雷攒下的因里，凡是"要管上几次结算"的那部分都存在它这里。扫雷事实不直接进容器——战斗结算每轮把事实兑换成状态发入，兑付时再来读生效清单。
核心规则
一个容器管全部方向：增益减益同账本
主角的增益与减益、敌方的削弱与增强——各个方向的效果在容器里是同一种东西，都叫状态实例（容器里的一份效果，带层数与剩余次数），走同一套受理、合并、倒数、清除的语义。踩雷的惩罚与封印标中的收益共用同一本账，玩家能在同一种读法下看到雷的两面：一边喂强敌人，一边拆它的皮。
容器四条硬规矩：
| 规矩 | 含义 |
|---|---|
| 寿命 = 一场战斗 | 战斗开始时容器为空，结束全部清空，不跨到下一场战斗 |
| 跨轮跨图延续 | 同一场战斗里换新雷图、弃图刷新都不清空——状态跟着战斗走，不跟图走 |
| 全程零随机 | 授予、合并、衰减、列举顺序全部确定，可回放 |
| 敌方侧共享 | 对敌效果一律对全体存活敌人生效，层数全体共享一份（单体寻址是后置扩展位） |
举证：本节为容器结构规则，无计算。
授予只在结算时发生：事实换状态的唯一入口
状态只在轮末结算时发入容器。挖掘期的挖格、封印、踩雷都不直接改容器——棋盘只上报"发生了什么"的事实，战斗结算在每轮结算时把事实统一兑换成状态发进来。这个授予入口是唯一的：棋盘和奖励背包都没有直通通道。
每笔状态随身携带归因记录：来源类别五选一、来自哪个格子、发生在第几轮。结算明细因此能逐行回答"这效果是我哪步棋带来的"。
| 来源类别 | 什么时候发生 | 发给谁 |
|---|---|---|
| 安全格 | 挖开安全格拿到增益 | 主角 |
| 封印标中 | 轮末封印判定标中（危险格被控制） | 敌方，削弱 |
| 踩雷 | 挖开危险格并惊动 | 敌方，增强 |
| 清图奖励 | 清图奖励槽含增益时 | 随行定，路径归地图战斗资源定稿 |
| 标空封印 | 轮末封印判定标空（标了但格不是雷） | 该安全格格面资源的负向兑付（极性矩阵"标错"分支——2026-09-15 起不再三选一）；载体裁决归战斗结算 |
容器是只记账、不裁决的仓库：上游叫它施加几次，它就入账几次。同一笔事实被重复转化两次，就入两层——它不去重、不合并事实，"事实到授予恰好一次"由战斗结算保证。同轮多笔授予按调用方给定的次序先后入列，容器保证入账顺序稳定可读。
状态一经发入立即生效，没有"待生效"中间态——授予它的那轮结算就是它的第一次兑付。
举证：本节为授予路径与记账规则，无计算。
同名状态再拿到：叠层、刷新、并存
同一种状态还没消失又拿到一份，怎么合并由状态表每行的合并策略字段说了算，共三种。合并在授予那一刻由容器完成；多个状态在结算里按什么先后起作用，是战斗结算的编排——两件事互不干扰。
| 合并策略 | 重复授予时发生什么 | 说明 |
|---|---|---|
| 叠加 | 层数加一；剩余结算次数不动——只有首次授予定钟 | 现行内容行多数用叠加（逐行合并策略读 status_effects.tres） |
| 刷新 | 剩余结算次数重置为该实例首次授予时的初始值，层数不变 | 刷新类内容行已就位——削弱行 weaken（2026-09-18 续时定案）、增益技行 empower / fortify、主角增益行 attack_up / ac_up（2026-09-20 用户拍板「只续时不叠层」，全状态表增益/减益两侧合并语义就此统一为：主角可重复获取的增益与减益一律续时、不叠层）；逐行读 status_effects.tres |
| 并存 | 新建一份独立实例，两份各算各的 | 同上 |
并存分支没有满层上限，但容器规模天然有界：实例数的上界就是受理过的授予数——多受理一份就多一份实例，多少份在授予那一刻就完全确定，不会无限膨胀。
叠加是纯加法：几层就是几倍的行值。叠到行上限后再授予同款会被拒绝，容器一个字不变；但这份奖励不会被无声吞掉——结算明细多一行"奖励未生效"（满层后白拿的那份，如实留痕），连来源一起写明，玩家看得到"这层白拿了"。浪费诚实、可规划。
无论重复来自玩家直接踩出的格子，还是连锁展开自动开出的奖励格，都走同一个授予入口、同样产生溢出行、同样留痕。
举证：本节为合并分支规则，无计算——满层判定就是一次"层数等于上限"的比较。
剩余次数怎么倒数：按结算次数衰减
每个状态实例自带一个倒数计数——剩余结算次数（本文说的"衰减"就是它逐次递减、归零消失）。它不承诺"活几轮"，而是数"经历过几次轮末结算"：每轮结算先让状态起作用，随后计数减一，减到零状态即被移除。持续 1 的状态就是"一次性"：在授予它的那轮结算里生效一次，轮末消失。MVP 时期六行内容均为一次性（削弱后改续时——见 git 提交史；2026-09-20 起主角增益两行也走续时、duration 表值仍为 1——重复拿等于重新获得一次当轮增益）；跨轮持续的状态，寿命由表行初始值表达，给几就活几次结算。
一轮结算：查询生效清单 → 逐行兑付（层数 × 行值）→ 轮末衰减（全部实例剩余次数 −1）→ 归零实例移除
| 要点 | 内容 |
|---|---|
| 计数单位 | 结算次数——全部状态唯一的时限单位，玩家读到的"还剩几次"就是规划素材本身 |
| 每轮时序 | 先兑付、后衰减：战斗结算兑付完才做减一，每轮结算恰减一次 |
| 归零即移除 | 减到零的实例当轮销毁，不留零值实例 |
| 停手照减 | 停手不挖的轮、弃图刷新的轮也照常算一次结算——没有"不结算就不掉次数"的免费延时 |
| 全清兜底 | 战斗结束通知到达即全实例清空；战斗最后一轮是否还做衰减判定归战斗结算的编排次序，两种次序终态相同 |
举证：本节为衰减时序规则，无计算。
幅度与量纲：容器只做加法，换算归结算
容器对每个状态只记两件数值的事：幅度（一个整数）和量纲（百分比还是固定值）。百分比量纲的叠层是纯加法——两层合计 = 2 × 单行幅度（叠层策略行，读 status_effects.tres 暴走 enrage 行），不是 1.5 的平方；固定值量纲几层就乘几。
结论：容器输出的有效值 = 层数 × 行值，原样给出、不封顶不保底；把百分比合计换算成乘数、并在 −100 个百分点处设地板，是战斗结算的消费侧规则——地板保证减益不会把属性打到绝对负值，最低压到"归零"为止。
有效值 = 层数 × 行值（量纲标签随值原样输出，不进乘法）
两个现行例子读起来是这样：
| 例子 | 容器输出 | 消费侧读法 |
|---|---|---|
| 暴走叠两层 | +(2 × enrage 行幅度)（读表；越出单行取值域，原样输出） | 压在天花板 +100% 上：敌方输出乘区封顶 ×2（削弱已改续时——"叠两层压地板 −100% 归零"的读法随 2026-09-18 结构修复批退役） |
| 主角盾牌加护再拿一份 | 层数恒 1、剩余结算次数重置（refresh——2026-09-20 主角增益续时批） | 不经任何池：掷点判定阈值 = 主角基准（读 hero 表）+ 层数（现行 +1——上限 2 层叠读取法退役，局内可达 AC 上限 11） |
容器还有一条快照纪律：实例的幅度、初始次数、量纲在授予那一刻从表行拷贝。战斗中配置表即使被重载，已授予实例不受任何影响，只影响后续授予。
现在有哪些状态：现行九行内容
现行状态表恰有九行：主角侧四行（增伤/盾牌加护两增益 + 失衡/乏力两减益）、敌方侧五行（削弱/暴走/警觉/蓄力/硬化——警觉为 blast 型负向踩雷载体，2026-09-20 伏击退役后进表）。全部用同构实例承载；数值全部 provisional（临时值，过锚验收后才定稿）。
| 字段 | 取值 | 说明 |
|---|---|---|
| effect_id | 文本，全表唯一 | 状态标识 |
| display_name | 文本 | 界面与结算明细用名 |
| target_side | hero / enemy | 作用侧 |
| magnitude | 整数 | 幅度：百分比行 ∈ [−100,100] 且非 0；固定值行 ≥ 1；护甲等级行 ∈ [−20,20] 且非 0 |
| unit | percent / flat / ac | 百分比修正 / 固定值 / 护甲等级（掷点折扣判定阈值轴——2026-09-16 护甲等级掷点批新增） |
| duration_settlements | 整数 [1,99] | 授予时初始剩余结算次数（1 = 一次性） |
| stack_policy | stack / refresh / independent | 同名再授予的合并策略 |
| max_stack | 整数 [1,16] | 叠层上限，仅叠加策略消费 |
| 状态 | 效果一句话 | 发给谁 | 幅度（现行值） | 时限 / 合并 | 来源类别 |
|---|---|---|---|---|---|
| attack_up 增伤 | 主角攻击提升 | 主角 | 见 data/tables/status_effects.tres attack_up 行 |
时限/上限读表 / 刷新（2026-09-20 续时批 stack→refresh，层数恒 1） | 安全格 |
| ac_up 盾牌加护 | 主角护甲等级提升（掷点折扣判定阈值——AC 轴，不入池） | 主角 | 见 status_effects.tres ac_up 行（2026-09-16 换装，原 defense_up 行已退役） |
时限/上限读表 / 刷新（2026-09-20 续时批 stack→refresh，层数恒 1） | 安全格 |
| alert 警觉 | 敌方护甲等级 +1/层 | 敌方 | 见 status_effects.tres alert 行 |
1 结算 / 叠加读表 | 踩雷 / 标空封印（blast 型负向） |
| weaken 削弱 | 敌方攻击被削弱（同名重复标中只刷新剩余次数、层数恒 1） | 敌方 | 见 status_effects.tres weaken 行（取值域 [60,85]，取负生效） |
时限读表 / 刷新（2026-09-18 续时定案） | 封印标中 |
| enrage 暴走 | 敌方攻击提升 | 敌方 | 见 status_effects.tres enrage 行 |
时限/上限读表 / 叠加 | 标空封印反噬 / 踩雷（attack 型负向） |
| off_guard 失衡 | 主角护甲等级降低（AC 轴——掷点判定阈值下调、更易被命中；2026-09-18 换装，原百分比承伤池已退） | 主角 | 见 status_effects.tres off_guard 行 |
时限/上限读表 / 叠加 | 标空封印反噬 / 踩雷（defense 型负向）/ 敌方妨害技（2026-09-19 新效应词汇批——蛛网束缚载体，duration 由技能行覆盖） |
| sapped 乏力 | 主角输出降低（weaken 型负向，hero_offense 池） | 主角 | 见 status_effects.tres sapped 行 |
时限/上限读表 / 叠加 | 危险格负向 / 标空封印（2026-09-15 格面资源批）/ 敌方妨害技（大地脉动——L3 Boss 石君王独占，2026-09-20 第三关内容批） |
| empower 蓄力 | 敌方输出倍率增益（enemy_output 池——蓄力技载体；幅度读表） | 敌方 | 见 status_effects.tres empower 行 |
duration 读表 = 1 个有效增益拍 / 刷新 | 敌方技能施放（2026-09-16 敌人技能池批） |
| fortify 硬化 | 敌方防御提升（敌方防御池 enemy_defense——硬化技载体；负值入池 = 主角攻击折半，2026-09-18 符号纠正——旧正值实际翻倍） | 敌方 | 见 status_effects.tres fortify 行 |
duration 读表 = 1 个有效增益拍 / 刷新 | 敌方技能施放（2026-09-16 敌人技能池批） |
empower 与 fortify 是敌方技能池增益技在容器侧的数据落点（技能行 buff_ref 引用，施放时长由技能行覆盖——技能冷却与增益持续是两个计时器）：两行 duration 表值（读表）的口径是"先兑付后衰减含施放当轮"——施放发生在第 N 结算战斗段，存活到第 N+1 结算战斗段才兑付"下一拍"，即"持续 1 个有效结算"（proposal 语义的容器落地）。敌方防御池（enemy_defense）是第四个乘区池：敌方作为防守方的百分比修正池，消费面 = 战斗结算主角攻击的池乘区——四池对称（敌打主角 = hero_defense × enemy_output，主角打敌 = hero_offense × enemy_defense），容器语义零延伸：仍是同构实例、side-wide 加算、不封顶不保底。
削弱行是当量锚在容器侧的数据落点：封印标中的收益折算成统一价值后，必须严格高于最低档主角增益——"封印标中必须比随便挖一格更值"，否则没人愿意封印。这条锚的契约归行动经济，对照验收归战斗结算；暴走与失衡两行分别是 attack/defense 型负向（极性矩阵"标错/踩雷"分支兑付）在容器侧的数据落点：行内容与载体裁决归它，本表只承载行值（失衡已换装 AC 轴不入池——2026-09-18 结构修复批）。失衡另有第二来源：敌方妨害技（2026-09-19 新效应词汇批——蛛化卓尔精灵"蛛网束缚"，敌方技能施放来源、duration 由技能行 buff_duration 覆盖）——容器零新语义，同构实例照常受理；乏力 sapped = 妨害第二词汇，载体已落地（L3 Boss 灰矮人石君王独占妨害技「大地脉动」，2026-09-20 第三关内容批）。
依赖与输出
本系统接面很窄：一个调用方（战斗结算），外加数据与呈现侧的软依赖。下表就是删除任何一方时的影响面清单。
| 方向 | 系统 | 接口要点 |
|---|---|---|
| 调用方 | 战斗结算 | 五个入口的唯一调用方：战斗开始（开账）、授予（唯一进货口）、查询生效清单（兑付消费）、轮末衰减、战斗结束（清空）；事实转授予、兑付作用顺序、换算与地板都在它一侧 |
| 上游 | 数据配置 | 状态表的字段定义承载与统一读取；本系统是该表的回填责任方 |
| 相邻 | 排雷玩法 | 棋盘事实的事件源头；与本容器零直接接口——事实一律经战斗结算转化 |
| 相邻 | 行动经济 | 契约相邻、无运行时接口：五条经济契约在本侧的数据落点就是状态表行值 |
| 下游 | 地图战斗资源 | 清图奖励含增益时经授予入口进入；增益与削弱档位的锚验收方之一 |
| 下游 | HUD 框架 | 状态栏数据源；有利/有害极性呈现、无状态时空槽隐藏、状态到图标的映射，三义务归口 |
容器对外是一组封闭的被动入口，全部布尔或计数返回：战斗开始（开账）、授予（唯一进货口）、查询生效清单（只读，按授予先后排列）、轮末衰减（返回本轮移除数）、战斗结束（全清回空）。它不发任何事件、不做任何界面动作——呈现刷新点在战斗结算编排完成之后。
P0 最小闭环
- 战斗结算通知战斗开始：容器开账，空容器进入可用状态。
- 轮末结算时，战斗结算把这一轮的扫雷事实兑换成授予：挖开安全格给主角上增益、封印标中削弱敌人、踩雷给敌方上增强、标空封印触发反噬——授予入口是唯一进货口。
- 容器按表行合并策略受理（新建 / 叠一层 / 刷新），实例立即生效并携带归因记录。
- 战斗结算查询生效清单，逐行兑付进结算公式（有效值 = 层数 × 行值）。
- 兑付完做轮末衰减：全部实例剩余次数减一，归零移除——先兑付、后衰减。
- 战斗外授予、未知状态、满层授予一律被拒且容器不变；满层的"奖励未生效"行归战斗结算的结算明细。
- 战斗结束通知到达：全实例清空、容器回空，不跨到下一场战斗。
P1 / P2 后置
后置不等于删除：以下条目保留在案，复活任何一条都走本文修订流程。
| 优先级 | 内容 | 后置原因 |
|---|---|---|
| P1 | 刷新、并存两类合并策略的后续内容行 | 语义已定义、容器已承载；刷新类已有内容（empower/fortify 2026-09-16 敌人技能池批、weaken 2026-09-18 续时定案），并存仍空，首个并存内容行上线时顺带补验收 |
| P1 | 清图奖励含增益的授予路径 | 来源类别已预留；内容与档位归地图战斗资源定稿 |
| P1 | 单体寻址扩展位 | 现行对敌效果一律全体共享；首个"只作用于其中一个敌人"的效果上线时给实例加目标字段 |
| P2 | 驱散 / 延时 / 转移接口 | 状态一旦生效，玩家没有任何手段摘掉、延后或挪给别人——省掉一整类界面复杂度是明确的设计决定；要加属于新增接口的修订，不是调参 |
| P2 | 并存行高频授予（持续伤害类）的容量语义 | 并存实例数上界 = 受理授予数，有界确定、无满层语义；MVP 无并存内容行，首个并存内容行上线时顺带复核容量读法 |
| P2 | 敌人词条引用状态（免疫 / 抗性） | 预留位；随敌人系统的内容批裁决 |
| P2 | 随关卡成长的效果行 | 状态表是定义表、不是进度成长表；需要时走加表列的修订 |
调参表
状态表为定义表，键 = 状态标识；已锁数值以 data/tables/status_effects.tres 为准，九行数值全部 provisional；现行值不列于本文——读 .tres。
| 参数 | 取值域 | 字段语义 | 说明 |
|---|---|---|---|
| attack_up 幅度 | 百分比 [−100,100] 且非 0 | percent 行 magnitude | 增伤；当量锚的参照对象（最低档主角增益） |
| ac_up 幅度 | 护甲等级 [−20,20] 且非 0 | ac 行 magnitude | 盾牌加护；掷点折扣判定阈值 = 基准 AC（读 hero 表）逐层 +1，不入任何池、消费归战斗结算掷点判定 |
| alert 幅度 | [0, 4] | ac 行 magnitude | 警觉（敌方护甲等级 +1/层 provisional）；消费 = 战斗结算护甲等级掷点判定 |
| weaken 幅度 | 百分比取值域 [60,85]，取负生效 | percent 行 magnitude | 削弱；须过"封印标中锚"对照 |
| enrage 幅度 | 百分比 [−100,100] 且非 0 | percent 行 magnitude | 暴走；attack 型负向行，进敌方输出修正池 |
| off_guard 幅度 | 护甲等级 [−20,20] 且非 0 | ac 行 magnitude | 失衡；标空封印反噬载体，掷点判定阈值逐层下调（2026-09-18 换装 AC 轴，不入池、退出 hero_defense 池） |
| sapped 幅度 | 百分比 [−100,100] 且非 0 | percent 行 magnitude | 乏力；危险格负向 weaken 型，进主角输出修正池（2026-09-15 格面资源批补登记） |
| empower 幅度 | 百分比 [−100,100] 且非 0 | percent 行 magnitude | 蓄力；敌方技能池增益技载体，进敌方输出修正池 |
| fortify 幅度 | 百分比 [−100,100] 且非 0 | percent 行 magnitude | 硬化；敌方技能池增益技载体，进敌方防御池 enemy_defense（负值 = 减伤方向——2026-09-18 符号纠正） |
| 初始剩余次数 | 整数 [1,99] | duration_settlements | 一次性语义行逐行读表；续时行 = weaken（2026-09-18 定案，duration 2）+ empower/fortify（1 个有效增益拍——先兑付后衰减含施放当轮）+ attack_up / ac_up（2026-09-20 主角增益续时批，duration 表值 1 维持——续时语义在 dur=1 下表现为重复拿重置当轮倒数；跨轮延续随将来 duration 拉长自然显形，数值归状态层重设计批）；拉长 = 恢复跨轮延续、规划变简单 |
| 叠层上限 | 整数 [1,16] | max_stack | 仅叠加策略消费；刷新行层数恒 1——weaken / attack_up / ac_up 表值上限在续时语义下不消费（2026-09-18 / 2026-09-20），empower/fortify ×1（冷却闸下不可能自叠加） |
非调参的冻结项：三类合并策略语义、两种量纲语义、来源类别枚举、"先兑付后衰减"时序、拒绝原子性、零随机——改动走本文修订流程，不走调参。
联动纪律：增伤与削弱是当量锚的两端；盾牌加护与难度曲线与Boss的承伤预期联动（掷点折扣轴——AC 行值变更须复算生存链区间；2026-09-20 主角增益续时批后 ac_up 层数恒 1、局内可达 AC 上限 11，复算随调参批）；削弱改续时后"单轮层数上限受行动经济行动点约束"的联动随之失效（2026-09-18 续时定案——同名重复标中只刷新剩余次数、层数恒 1；2026-09-20 起主角侧 attack_up / ac_up 同口径）。这些联动值禁止独立调参，修订须重跑锚对照并同步 registry。
验收标准
- 容器寿命可答：战斗开始时为空；除战斗结束清空外没有任何入口能清空容器；战斗未开始或已结束时的授予一律被拒且容器不变。
- 多向同构：主角侧增益与减益、敌方侧增强与削弱共用同一套受理、合并、倒数、清除语义，不存在第二套计时逻辑。
- 授予即生效：状态发入当轮结算即兑付第一次，无"待生效"中间态。
- 只记账不去重：同一事实被转化两次授予，入账两层——去重责任在战斗结算。
- 叠层不减钟：叠加策略行叠加只加层数，剩余次数保持首次授予定下的轨迹不变（刷新策略行则相反——层数不变、只重置剩余次数；两策略逐行读表）。
- 满层拒绝原子且留痕：叠满后再授予返回失败、容器逐字不变；结算明细多一行"奖励未生效"（含来源）。
- 先兑付后衰减：每轮结算恰做一次衰减，归零实例当轮移除；停手轮、弃图刷新轮照常衰减。
- 合成不设上下限：容器输出的有效值恒等于层数 × 行值，越出百分比域不封顶不保底；地板在战斗结算侧。
- 快照抗重载：已授予实例的数值在战斗中不受配置表重载影响，只影响后续授予。
- 确定性回放：同一授予序列驱动两个独立容器实例，生效清单（含排列顺序）与衰减轨迹逐项相同。
- 表实一致：配置表字段与
data/schemas/status_effect_table.gd逐字段一致。
待办
本系统待办条目已统一收编至 待办清单，本节不再逐条登记。