★ 本版修订说明（2026-09-14 · 团队加速 v2 口径同步）
本次补入 / 修正 5 处：
- §5.2 团队加速整体改写为 v2 三段式：分享奖
share+ 向上奖up+ 向下奖down，向上 / 向下各序列内逐级折半 0.5，中心 R = 买家的推荐人（2026-09-13 拍板「逐级递减 = 各方向序列内递减」，同日开关team_reward_v2_enable双线翻转）； - §2 总览「阶段 C」行同步 v2；
- §7.1⑤ 加速奖基数改为「按区分叉」：礼包区订单 = 订单实付、其他区订单 = 让利额（非礼包入口
accel_nongift_enable=1已放开，实时钩子在确认收货）； - §11#4 状态更新：「向下」分支已实现投产，不再是留白；线②商户线不随 v2 变化（仍固定 10% pass-up）；
- 2026-09-14 正式线 v2 全量重置落账：14 单 48 行 v1 作废（全量备份
*_bak），按 v2 重计提并发放 60 行 ¥26,094.82（burned=0）。
文中 ★ 标记处为已拍板最终口径（含依据与判定日期），未标记者为原《模式总结》口径。
1. 积分体系（共六类，分属 6 个独立账户池）
| 积分种类 | 来源 | 入账时间点 | 其他说明 |
|---|---|---|---|
消费积分 consume_point | ① 礼包区：零售价 × 让利比 × 5；② 非礼包区：零售价 × 让利比 × 5 × 0.5；③ 锁仓积分解锁 | 订单完成 | 转为专属红包时先扣 6%（不论动 / 静） |
兑换积分 exchange_point | 非礼包区订单：零售价 × 让利比 × 5 × 0.5 | 订单完成 | 仅非礼包区产生，礼包区不产生 |
锁仓积分 lock_point | 后台拨放（非订单自动产生） | 后台操作 | 按每天 0.2% 解锁为消费积分 |
专属红包 red_packet | 消费积分（动 / 静）释放 + 分红 | 释放 / 发放时 | 链内上下互转 0.1% 手续费 |
兑换权益 exchange_equity ★ | 兑换积分释放 | 释放时 | 转出需预留审核表单，后台处理；流水写 exchange_equity_record |
积分余额 balance_point ★ | ① 第三方入账（外部系统推送，type=7）；② 专属红包 ↔ 积分余额互转（type=5） | 后台操作 / 互转时 | 与专属红包互转 0 手续费；point_record.point_type=4；独立于兑换积分（股票兑换 D3 仍走 exchange_point） |
关键结论：旧的「四池」表述（消费 / 兑换 / 锁仓 / 锁仓已解冻）错误。正确为六类账户；其中「锁仓已解冻 lock_released」只是 member 上的一个累计计数列（对账校验 + 计算「可解冻剩余 = lock_point − lock_released」用），不是一个池 —— 锁仓解锁后直接进入消费积分。
2. 总览：一笔订单触发的积分 / 资金流向
订单完成（礼包区 或 非礼包区）
│
▼
积 分 入 账（阶段 A，实时）
├─ 礼包区订单 ：消费积分 += 零售价 × 让利比 × 5
└─ 非礼包区订单：消费积分 += 零售价 × 让利比 × 5 × 0.5
兑换积分 += 零售价 × 让利比 × 5 × 0.5
（锁仓积分只由后台拨放，不从订单产生）
═══════════════ 以下为周期性 / 后台动作 ═══════════════
阶 段 B — 积分释放（活跃值 = 1 才发生）
├─ 锁仓积分：每天 0.2% 解锁 → 消费积分
├─ 消费积分：静态释放 + 动态加速释放 → 专属红包（扣 6%）
└─ 兑换积分：静态释放 → 兑换权益（转出需审核）
阶 段 C — 动态加速（作用于消费积分、锁仓积分；兑换积分无加速）
├─ 分享加速：礼包区订单金额 10%；线下消费者让利额 10%；线下商家让利额 10%
└─ 团队加速（线① v2 三段式）：分享奖 R 本人 10%；向上奖 R 上级链 10%×0.5^(k-1)；
向下奖 R 下级树 10%×0.5^(d-1)（线②商户线仍为固定 10% pass-up，见 §5.2）
阶 段 D — 分红（消耗消费积分，不足原点烧伤）
├─ V1~V6 会员参与 V1..自身级全部分红池（6/5/4/3/2/1 %）
└─ 每池 5:5 拆分：50% 人头均分 + 50% 消费积分占比 → 专属红包
阶 段 E — 互转与转出（red_packet / 权益流出）
├─ 专属红包链内上下互转：手续费 0.1%
├─ 积分余额 ↔ 专属红包：0 手续费
└─ 兑换权益转出：审核表单，后台处理一句话：订单完成只入账「消费积分 / 兑换积分」；锁仓积分靠后台拨放再每天 0.2% 解锁；消费 / 兑换积分靠「活跃值 = 1 的静态释放 + 消费 / 锁仓的动态加速」进入专属红包与兑换权益；分红消耗消费积分、按 5:5 拆到专属红包。
3. 阶段 A — 积分入账（订单完成）
触发：订单完成（礼包区与非礼包区口径不同）。幂等按订单，同一订单不重复入账。
公式（精度 bcmath，中间 6 位、落库 2 位截断）：
| 订单区 | 发放项 | 公式 | 落点 |
|---|---|---|---|
礼包区（type=1） | 消费积分 | 零售价 × 让利比 × 5 | consume_point |
| 非礼包区 | 消费积分 | 零售价 × 让利比 × 5 × 0.5 | consume_point |
| 非礼包区 | 兑换积分 | 零售价 × 让利比 × 5 × 0.5 | exchange_point |
- 让利额 =
零售价 × 让利比（让利比来自商品配置，具体基准待确认）。 - 锁仓积分不由订单产生，仅 后台拨放入口写入
lock_point。 - 记账：
point_record按point_type（1 消费 / 2 兑换 / 3 锁仓 / 4 积分余额）各记一行，balance_after为该池入账后余额。 - 并发 / 一致性：事务 +
member行锁FOR UPDATE。
P0 批次已上线（2026-09-11）：入账基数改为 SettleBase::itemPayAmount() = amount − coupon_amount（含红包抵扣）；新增列 order_item.coupon_amount / pay_amount / rebate_amount、sales_order.rebate_amount、member.effective_member、point_record.grant_key（+ UNIQUE，重复发放报 1062）。
4. 阶段 B — 积分释放（静态 + 动态加速）
释放统一前置：活跃值 = 1（构成 —— 需「看广告签到」广告完整即签到成功）。实现上取前一日签到 + 广告完播。
4.1 锁仓积分解锁（每日 0.2%）
lock_point按每天 0.2% 解锁 → 消费积分（不是兑换积分！）。- 记账：锁仓池出（
type=4,point_type=3）/ 消费池入（type=4,point_type=1）两行。 - 两线实测
lock_point > 0当前 0 人，故该路径当前实际零影响。
4.2 消费积分释放 → 专属红包
- 静态释放：活跃值 = 1 且
consume_point > 0。 - 动态加速释放（见阶段 C）：分享加速 + 团队加速。
- 释放入
red_packet时先扣 6%（不论动 / 静释放）。★ 该 6% 的去向见 §4.4。
4.3 兑换积分释放 → 兑换权益
- 静态释放：活跃值 = 1 且
exchange_point > 0。 - 无动态加速。
- 释放入「兑换权益」；转出需审核表单（后台处理）。
4.4 ★ 6% 释放税的去向（2026-09-11 拍板 · 最终口径）
结论：记入「平台税沉淀科目」。
| 项 | 内容 |
|---|---|
| 现行实现 | red_packet_tax_rate='0.06'、red_packet_tax_record='0' ⇒ 6% 直接蒸发：不写 ledger、不写 point_record、不入任何账户、不累加 burn_amount（仅 error_log 留文本） |
| 拍板口径 | ★ 不再蒸发，改为入账留痕 —— 冲正时按全额回补会员（会员不亏），同时把 6% 税额记入平台税沉淀科目 |
| 落地前置（★2026-09-12 已落地） | 表 platform_tax_reserve 已建、config_param.tax_reserve_enable='0' 已写入（默认 0 = 现状，部署即零回归）；双线已投产 |
| 承接范围 | 建议一张表统一承接三类同性质的「平台留存」，而非给税单独建表：accel_tax（本 6% 税，沉淀）／ burn_gap（差额烧伤，沉淀）／ revoke_tax（冲正释放，支出） |
| 不可复用 | red_packet_ledger（会员红包账本，混入会污染会员对账）；point_record.type 的 1~8 已占满，无「税」语义位 |
覆盖两条路径（易漏）：除了加速奖发放 rewardAccelTransfer()，静态释放 releaseDaily() 同样有 6% 税（消费积分 → 专属红包，积分池按 $rel 全额扣、红包按 netRel = $rel × 94% 入账）。而「兑换积分 → 兑换权益」是另一条独立路径，可另行独立配置。
★ 数据来源：2026-09-11 正式线只读实测 —— settlement.red_packet_tax_record='0'、red_packet_tax_rate=0.06；并已用 #4（u1）逐位验证：actual 999.90 → 扣 consume_point 999.90 → 入红包 939.91（999.90 × 0.06 = 59.994 → 939.906 → 入账 939.91 ✓），单笔税 59.994 蒸发、两笔合计 119.98。
5. 阶段 C — 动态加速释放
作用对象：消费积分、锁仓积分（两者规则一致）；兑换积分无加速。
5.1 分享加速
受益人 = 直接推荐人。金额按三类来源：
- 礼包区订单金额 10%
- 线下消费者让利额 10%
- 线下商家让利额 10%
★ v2 起，分享加速并入团队加速三段式统一计算（direction=share，中心 R = 买家的推荐人），基数按区分叉（礼包区 = 实付 / 其他区 = 让利额），见 §5.2。
5.2 ★ 团队加速（v2 三段式 · 2026-09-13 拍板「逐级递减=各序列内递减」 · 2026-09-14 文档同步）
总开关 team_reward_v2_enable=1（双线已开，2026-09-13 翻转）。v2 以中心 R = 买家的推荐人（非买家本人）为圆心，一次计提产生三段奖励：
| 段 | 受益人 | 公式（B = 计提基数） | 落库指纹（reward_record） |
|---|---|---|---|
① 分享奖 share | R 本人 | B × team_share_rate(0.10) | direction=share, direction_level=0 |
② 向上奖 up | R 的上级链第 k 级 | B × team_up_rate(0.10) × 0.5^(k−1)，k ≤ team_up_max_level(5) | direction=up, direction_level=k |
③ 向下奖 down | R 的下级树第 d 层（含买家本人，team_down_include_buyer=1） | B × team_down_rate(0.10) × 0.5^(d−1)，d ≤ team_down_max_level(5) | direction=down, direction_level=d |
- 逐级递减（已拍板语义）：
team_decay_ratio=0.5—— 向上、向下是两条各自独立的递减序列，各自第 1 级都从 10% 起算、逐级折半；不跨序列连减（故向上#1与向下#1金额可以相等，属正确表现，勿报 bug）。 - 向下段细节：层内按各参与人消费积分占比分摊（
team_down_alloc=ratio）；某层参与人余额不足时该层额度整体蒸发（team_down_zero_pool=vanish），且只影响该层、下一层额度照常（B × rate × 0.5^(d−1)）；team_down_min_amount=0.01以下不落行；team_down_max_nodes=5000熔断防大树扫描。 - 计提基数 B 按区分叉：礼包区订单 = 订单实付（
SettleBase::itemPayAmount()）；其他区订单 = 让利额（itemRebate()）。非礼包入口已放开（accel_nongift_enable=1，2026-09-13 B 方案双线投产）：实时钩子在确认收货（member/Order::confirm），兜底走reward:settle非礼包段（按status∈(4,5)扫描、不看日期）。 - 两阶段入账：计提写
reward_record(status=1)只记账；真正入账（扣消费积分 → 入专属红包，扣 6% 税、差额烧伤）由 T6fund:payout执行 —— 见 §11「计提 ≠ 到账」与 §4.4。 - 级数提示：v2 中心是 R 而非买家本人 ⇒ 同一订单的向上链可能比旧口径少一级（旧口径沿买家链上行）。
⚠️ 旧表述作废三处（保留作历史对照，勿再据其对账）：
- 「每一级固定 10%、非几何衰减、单向 pass-up、封顶 5 级」= v1 口径（沿买家
recommend_path上行），已被 v2 取代（2026-09-13 开关翻转）。历史 v1 行的指纹：direction=''且direction_level=0。 - 「每一级拿下一级 50%」=
0.5^d几何衰减 —— 曾于 2026-09-06 弃用，现以「各序列内逐级折半」的形式成为 v2 现行口径（team_decay_ratio=0.5）。 - 「向下 10% 当前无此机制」—— 已实现（v2 向下奖），不再是待确认项。
商户线（2026-09-10 增补，团队加速升级为「双线」）：
- 线①（购买者线，
line=1） = 上文 v2 三段式； - 线②（商户线，
line=2） = 以「商户绑定的 C 端会员（merchant.member_id）」为源，沿该会员的recommend_path上行，由线下核销让利额（merchant_verify.rebate_amount）触发，仍为每级固定 10%（merchant_line_rate）、单向 pass-up、封顶 5 级（独立计算computeMerchantLine()，不随 v2 三段式变化），受merchant_line_enable控制。 - 商户未绑定会员 ⇒ 线②无源、不计提。回退：
merchant_line_enable=0即一键退回单线（线①不受影响）。
旧版「反加速 recommend（平台拨付招募人 × 0.20）」为错误机制，已删除。正确体系里不存在平台 user_id=0 出资的反加速奖。（配置键 recommend_funded_by_platform 已全项目无读取方，仅历史 reward_record 留有 recommend 记录供后台只读展示。）
每条加速记账：写 point_record（/ reward_record）记录 should_amount、actual_amount、batch_no（幂等），不直接触碰余额 cap。
6. 阶段 D — 分红
触发：按日计提（T+1），消耗消费积分。
6.1 分红前提与消耗
- 分红消耗消费积分余额（扣减顺序：先释放、后分红）。
- 消费积分不足时烧伤，原点烧伤（该会员该期分红归零）。
6.2 分红池与等级
- 分红池来源 = 全网礼包专区流水，按各级分红率计提：V1=6% / V2=5% / V3=4% / V4=3% / V5=2% / V6=1%。
- 叠加规则：V2 参与 V1+V2，V3 参与 V1–V3，…，V6 参与 V1–V6 全部池。叠加为每个等级都参与其自身及以下全部池（不是仅 V5+）。
- 各等级累计分红率：V1=6%、V2=11%、V3=15%、V4=18%、V5=20%、V6=21%。
6.3 池内 5:5 拆分
每个分红池总金额：
- 50% 按参与用户人头均分（身份均分）。
- 50% 按用户剩余「消费积分」占比加权分配（旧版误写为「兑换积分」，实为消费积分 —— 代码
DividendEngine::allocate取consume_point）。 - 守恒：身份半 + 积分半 = 池总额；逐人末位吸收舍入 residual。
6.4 入账
分红入 red_packet（专属红包）。记账与幂等沿用 batch_no = dividend:{source}:{date}。
7. 会员级别（V1–V6）
| 级别 | 晋升条件（自动） | 参与分红池 | 累计分红率 |
|---|---|---|---|
| 普通会员 | 注册即是 | — | — |
| 有效会员 | 有效消费 > 0 | — | — |
| V1 品牌推广员 | 有效会员 + 亚网体团队总业绩 ≥ 10 万 | V1 | 6% |
| V2 品牌业务合伙人 | 有效会员 + 亚网体团队总业绩 ≥ 30 万 | V1–V2 | 11% |
| V3 品牌拓展合伙人 | ≥ 100 万 | V1–V3 | 15% |
| V4 品牌共建合伙人 | ≥ 500 万 | V1–V4 | 18% |
| V5 品牌合伙人 | ≥ 1000 万 | V1–V5 | 20% |
| V6 项目合伙人（隐藏） | 无自动晋升，仅管理员后台手动指定 | V1–V6 | 21% |
- V6 隐藏：前台显示 V5；账户信息 / 操作记录仅管理员可见。
- 旧版「V6 未启用、回退 V5、忘原级别」等错误描述已删除：V6 为正式存在的隐藏级别，参与全池 = 21%。
7.1 ★ 业绩口径与阈值（2026-09-11 P0 批次已上线 · 最终口径）
① 「亚网体团队总业绩」= 非礼包让利额，沿推荐链含自身累加。
| 来源 | 字段 |
|---|---|
| 线上 | sales_order.rebate_amount |
| 线下 | merchant_verify.rebate_amount |
⚠️ 旧口径是「礼包订单实付」，两者量级差约 5 倍 ⇒ 同为 10 万门槛，新口径的达成难度约为旧的 5 倍。这是业务有意的口径收紧，不是 bug。
② 阈值经 config_param 提供；键名语义 = 「晋升到 V(N+1) 的门槛」，本次只上移取值、不改键名。
| 键名 | 取值 | 语义 |
|---|---|---|
level_v0_threshold | 100,000（10 万） | ≥10 万 → V1 |
level_v1_threshold | 300,000（30 万） | ≥30 万 → V2 |
level_v2_threshold | 1,000,000（100 万） | ≥100 万 → V3 |
level_v3_threshold | 5,000,000（500 万） | ≥500 万 → V4 |
level_v4_threshold | 10,000,000（1000 万） | ≥1000 万 → V5 |
level_v5_threshold | 10,000,000 | 保留但不再参与自动晋升（V6 改为后台手动指定） |
③ 前置条件：V1 及以上须为有效会员（累计有效消费 > 0，口径 = Σ 扣券后实付）。
④ 引擎行为：仅升不降；仅 status=1 会员自动晋升；存量 V6 会员不受影响。
⑤ 分工提醒：「晋升业绩」用非礼包让利额；「加速奖（v2 三段式，见 §5.2）」的基数按区分叉：礼包区订单 = 订单实付、其他区订单 = 让利额（accel_nongift_enable=1 后非礼包单也计提）—— 礼包区订单的加速奖基数与晋升业绩口径量级差约 5 倍，勿混用。
8. 代理制度（线下结算，红利入专属红包 / 账户）
| 代理级别 | 考核条件 | 权益 1（区域收益） | 权益 2（单件补贴，入专属红包） |
|---|---|---|---|
| 工作室 | 团队总业绩 ≥ 50 万 且 线下消费让利总额 ≥ 50 万，可叠加多组 | 每组 1 万元扶持经费，多组达标可叠加（后台拨放，不扣消费积分） | — |
| 区县代理 | 月度自动统计辖区业绩与让利 | 辖区内线下消费让利总额 6% | 单件利润达标 6 元及以上 → 单件计提 3 元 |
| 市级代理 | 同上 | 辖区让利总额 2% | 单件计提 2 元 |
| 省级代理 | 同上 | 辖区让利总额 1% | 单件计提 1 元 |
★ 工作室（level1）已纳入自动计提（agent_studio_auto=true，由 AgentSettleCommand 月度执行）。旧表述「工作室不自动计提、仅 agent_funds 手动经费」已作废。
权益 2 需扣消费积分、补贴到专属红包（工作室为后台拨放、不扣消费积分）。无对应级 agent 时差额进平台沉淀（agent_equity_ledger.agent_id=0）。
9. 互转与转出（red_packet / 权益流向）
- 专属红包链内上下互转：手续费 0.1%；同一链内（上下级关系）可转；事务 + 双方
FOR UPDATE行锁；写red_packet_ledger。 - 积分余额 ↔ 专属红包：0 手续费（积分余额来自第三方后台入账）。
- 兑换权益转出：预留审核表单，后台处理（非实时直接提现）。
- 旧版单一的「提现
WithdrawEngine」可作为专属红包提现的具体实现保留，但它并非唯一流出通道。
10. 数据 / 对账保障
- 六类账户池（
consume_point/exchange_point/lock_point/red_packet/ 兑换权益 / 积分余额）独立落member。 - 所有变动写
point_record/red_packet_ledger，balance_after为对应池余额 → 对账中心逐账户校验「末笔流水余额 = 当前余额」。
★ 平台侧留存（非会员账户）：6% 释放税、差额烧伤、冲正释放税额 → 见 §4.4，已统一落 platform_tax_reserve 台账（★2026-09-12 已建表并双线投产，开关 tax_reserve_enable 默认 0）。它与「会员账户池」性质不同：不属于任何会员，故不可混入 red_packet_ledger（会污染会员对账）。
⚠️ 精度陷阱（2026-09-11 实测，复刻金额逻辑前必读）：Amount::round() 是截断（bcadd($a,'0',$s)，bcmath 向零舍入）而非四舍五入；且 allocate() 采用末位吸收（uid 升序，最后一个吃残差）⇒ 末位 uid 系统性多拿（同权同级七日差 2.88 元，上界 ≈ 人数 × 0.01 / 池 / 半）。复刻须用 Decimal + ROUND_DOWN 并逐人校准。
精度统一 bcmath（SCALE=6 中间算、落库 2 位截断）；并发用行锁 + 余额 cap 防超发；无 Redis 环境用 job_queue + schedule_lock 表实现自研队列 / 分布式锁。
11. 待确认清单（逐项标注：已确认 / 已实现 / 仍留白）
| # | 模块 | 待确认项 | 当前口径 | 状态（2026-09-11） |
|---|---|---|---|---|
| 1 | 入账 | 「让利比」的商品配置基准 | 让利额 = 零售价 × 让利比；礼包区 ×5，非礼包区 ×5×0.5 双池 | 仍留白 |
| 2 | 释放 | 「活跃值 = 1」的构成（看广告完成） | 仅约定活跃值 = 1；实现取前一日签到 + 广告完播 | 仍留白 |
| 3 | 释放 | 消费积分转专属红包扣 6% 的征收方 | 按 6% 扣 | 已确认：记入平台税沉淀科目（§4.4） |
| 4 | 团队加速 | 团队加速的比例与方向 | v2 三段式：分享奖 10% + 向上奖 10%×0.5^(k−1) + 向下奖 10%×0.5^(d−1)（各序列内逐级折半，中心 R = 买家推荐人）；线②商户线仍固定 10% pass-up | 已确认且已投产（§5.2；2026-09-13 拍板「各序列内递减」并翻转开关，2026-09-14 正式线 v2 全量重置落账） |
| 5 | 分红 | 分红消耗消费积分的额度 | 按分红额消耗，不足原点烧伤 | 已实现；「身份半是否受余额约束」仍留白 |
| 6 | 等级 | 「亚网体团队总业绩」的统计口径 | 非礼包让利额，沿推荐链含自身（线上 sales_order.rebate_amount + 线下 merchant_verify.rebate_amount） | 已确认（§7.1） |
| 7 | 字段 | 「兑换权益」「积分余额」两个新池的落库字段名 | exchange_equity / balance_point（2026-09-12 确认） | 已确认（积分余额池已双线投产；见 §1） |
| 8 | 代理 | 工作室「多组可叠加」的组上限、区县辖区归属 | 按需求原文 | 仍留白 |
| 9 | 冲正 | 订单退款 / 取消后的资金冲正 | — | 已拍板且已投产（见 §12；2026-09-12 P0–P4 双线完工） |
★ 2026-09-11 新增留白（本轮挖掘出的新问题）
- 分红「身份半」是否受消费积分余额约束 —— 实测烧伤率 43.69%，且逐分等于 29 名零余额会员的「身份半」。若定为「余额校验只作用于积分半」⇒ 烧伤归零、平台零成本（已离线推演）。待拍板。
- 差额烧伤是否并入「平台税沉淀」 —— 现行是直接蒸发（不归平台沉淀账户、不入任何池、不写流水，仅累加
reward_record.burn_amount）。§4.4 建议与 6% 税并入同一台账，Q20-3 已就 6% 税拍板，烧伤是否沉淀待定。 point:thaw（锁仓解冻）数值变化是否接受 —— 修ancestorIds()后上线链会多算正确的一层，解冻数值变准（两线lock_point > 0当前 0 人，故当前实际零影响）。
★ 2026-09-12 新增留白（正式线实测）
- 加速奖「零行计提不留痕」 ——
RewardEngine::compute()在买家无上级链（recommend_path为空）时返回空数组，persistRows([])直接返回 0、不写任何batch_no幂等痕迹 ⇒ 若下单 / 支付时买家尚未接入推荐链，该单永久无加速奖且无自动补算（实测正式线order#2 / #3 / #8三单零reward_record）。叠加reward:settle因reward_settle_offset_days=0只扫当天 00:00–00:30（兜底实际不生效）。「是否补计提 / 是否置offset=1/ 是否改为下单即时发放」待拍板。 - 加速奖「计提 ≠ 到账」是两阶段 —— 下单即时写
reward_record(status=1)（不碰余额），真正入账（consume_point → red_packet，扣 6% 税）由 T6fund:payout每日 04:00 执行 ⇒ 当日计提的奖励次日才在会员专属红包可见（见 §12.2）。若业务要求「下单即时到账」需另行改造。
已确认的固定决策：旧版大量假设（lock_ratio=0.4 订单锁仓、反加速平台出资 0.20、分红按兑换积分加权、V6 未启用等）已全部纠正为《模式总结》口径；锁仓积分仅后台拨放、订单不锁仓。
12. ★ 订单冲正（退款 / 取消后的资金收回）· 2026-09-11 拍板
依据：outputs/q20-revoke-skeleton/Q20订单冲正骨架设计方案.html（13 表 / 9 章）。全部数字取自正式线只读实测（2026-09-11），未写入任何数据。
12.1 为什么需要（现状缺口）
| 入口 | 当前行为 | 资金冲正 |
|---|---|---|
admin/Order::close | status=5 + settle_invalid=1（reason=admin_close） | 无 |
merchant/Order::refund | 源码注释原文「仅状态标记，资金侧由平台结算链路处理」—— 而平台侧并不存在该逻辑 | 无 |
api/Order::cancel | status=6（刻意不打 settle_invalid，防「已付款却被剔除」） | 无 |
admin/Order::payConfirm | 清 settle_invalid=0，走 OrderPostPayService::onPaid | —（反向：重新激活） |
⇒ settle_invalid 只解决「未结算订单的排除」；已发放到会员账上的积分与红包，当前无任何机制可以收回。
12.2 ★ 颠覆性前提：加速奖不是「平台发钱」，是「会员积分变现 + 6% 税」
T3 计提（RewardEngine::settleItem）→ 写 reward_record(status=1)，★ 完全不碰任何余额
T6 发放（fund:payout，每日 04:00）→ PointEngine::rewardAccelTransfer()
实发 = min(应发, 会员 consume_point 余额)
扣 member.consume_point -= 实发
税 = 实发 × 6% ← 直接蒸发（去向见 §4.4，已拍板改为入账）
收 member.red_packet += 实发 × 94%
写 point_record type=6（负数）+ red_packet_ledger(change_type='reward')
差额（积分不足）→ 蒸发，累加 reward_record.burn_amount
→ reward_record.status = 2⇒ 业务定性：退款冲正 = 「撤销一次积分变现」，不是「追回平台给出去的钱」。这决定了下文全部口径。
★ 冲正必须「成对回滚」的 6 个落点（少一个账就不平）：member.consume_point ・ member.red_packet ・ point_record(type=6) ・ red_packet_ledger ・ reward_record.status ・ sales_order.settle_invalid（+ 反向流水）。
12.3 ★ 五项拍板口径
| 编号 | 问题 | 拍板结论 |
|---|---|---|
| Q20-1 | 冲正方案 | C 分级：未发放（status=1）立即撤回；已发放（status=2）挂人工审批后执行 |
| Q20-2 | 余额不足时 | 全额不扣，粒度 = 整笔跳过（含积分侧也不动） |
| Q20-3 | 6% 税归属 | 记入平台税沉淀科目（全额回补会员 + 税额入账留痕），见 §4.4 |
| Q20-4 | 业绩与晋升 | 不回退 |
| Q20-5 | 分红追溯 | 只对未发放批次日（fund:payout 04:00 一过即不可逆） |
12.4 ★★ Q20-2 必须「整笔原子」（反直觉点，写代码前必读）
「全额不扣」不等于「只跳过扣红包那一步」。若只跳红包、却把积分回补给会员，会留下 「积分已还、红包未收」的不守恒中间态 ⇒ 会员净多占 actual 积分 + 94%×actual 红包，平台白亏 94%。
⇒ 正确做法：任一落点不满足 ⇒ 该笔冲正整体不执行（等价于「冲正未发生」，账自洽）。
★ 作用域推论（好消息）：C 分级下自动路径只处理 status=1（翻状态、零资金动作）⇒ 永远遇不到余额不足；Q20-2 实际只在「人工审批执行 status=2 批次」时充当安全阀（余额不足 ⇒ 拒绝执行并提示，不打负数、不留欠账）⇒ 整条自动路径可做到「零余额风险」。
12.5 存量面（2026-09-11 只读实测）
| 核查项 | 实测 |
|---|---|
settle_invalid=1 的订单 | 0 单（13 单全 0，reason 全空） |
order_refund 表 | 空表（0 行） |
sales_order.status 分布 | 仅 1(待付,2) / 2(已付,9) / 4(完成,2)；不存在 5 / 6 / 9 |
| 唯一「不可逆面」 | reward_record id 21 / 22（#4 → u1 共 1,999.80，已入红包 1,879.82，税 119.98 已蒸发） |
status=1 待撤回 | 12 行 / 958.80（翻状态即可，零资金动作） |
★ 2026-09-12 更新：上表 status=1 的 12 行已于 09-12 04:00 由 fund:payout 正常发放（status→2、已入会员红包），故其不再属于「待撤回」面；「唯一不可逆面」reward_record id 21 / 22 结论仍成立。
★ 2026-09-14 更新：正式线 14 单 48 行 v1 奖励已按 v2 全量重置（余额回滚 → 删历史行 → v2 重计提 → fund:payout 放款 60 行 ¥26,094.82、burned=0）。上表为 09-11 时点快照；「不可逆面 reward_record id 21/22」行已随重置删除（全量备份于 xydshop.reward_record_bak / red_packet_ledger_bak / point_record_bak）。
⇒ 零历史包袱，不需要任何历史补扣。
12.6 落地路径（★2026-09-12 P0–P4 全部完工 · 双线投产）
| 阶段 | 交付 | 关键点 |
|---|---|---|
| P0 | 平台税沉淀科目 platform_tax_reserve | 新前置件（因 Q20-3）；开关 tax_reserve_enable 默认 0 |
| P1 | RewardEngine::revokeByOrder() 撤回未发放 | 只处理 status=1：翻 status=3(已冲正) + 写 revoked_at/reason；不碰任何余额 |
| P2 | PointEngine::rewardAccelRevoke() 六落点回滚 | + 反向流水；受 order_revoke_enable 控（默认 0） |
| P3 | OrderRevokeCommand + 接入点 | 接入 admin/Order::close、merchant/Order::refund；带 --dry-run |
| P4 | 只读探针 + 双线部署 | 必测反向对照 + 守恒断言（consume_point 回补额 + red_packet 扣回额 + 税 = 原 actual） |
★ 上述 P0–P4 已于 2026-09-12 全部完工并双线投产：platform_tax_reserve 建表、order:revoke 命令（含 --dry-run）、六落点成对回滚（consume_point / red_packet / point_record(type=6) / red_packet_ledger / reward_record.status / 反向流水）、接入 admin/Order::close + merchant/Order::refund；两个开关 tax_reserve_enable / order_revoke_enable 均默认 0（零行为变更）。P1「撤回未发放（status=1）」为零资金动作，不受开关约束，已在线生效。
★ 事务边界约束：冲正不能放在 merchant/Order::refund 的同一事务里做「跨商户」操作 —— 奖励收款人是买家的上线，可能属于完全无关的商户。必须按订单维度执行、各自成事务、可单独重试。
★ 遗留技术点（已完成）：tax_reserve_enable / order_revoke_enable 已加入 admin/Config::IMMEDIATE_KEYS（2026-09-12），后台改开关即时生效。