feat: integrate platform room entry, UI migration and erqiwang documentation

server/games/erqiwang/docs/compliance/00-已知不一致-初步清单.md

@@ -0,0 +1,53 @@
+# 二七王 服务端实现 vs 设计文档：初步不一致清单
+
+> 本文是首轮通读 `server/games/erqiwang/*.js` 与 `docs/design/design.md` 后记录的**初步**疑点清单，作为逐条深入核对的线索。完整、逐节的核对结论见同目录 [`01-design合规逐节核对.md`](./01-design合规逐节核对.md)。
+>
+> 方向约定（与根 `CLAUDE.md` 一致）：`design.md` 是玩法规则的唯一权威，代码与其冲突时**应改代码去符合规则**（除非规则标「待确认」）；本清单只做记录，不代表已修复。
+
+---
+
+## 1. 算子（基础子数）与设计表格完全对不上
+
+- 设计 §7.1 常规算子基础子数：65→2、60→3、55→4、50 及以下→6；70 投降→1、70 打牌→2。
+- 代码 `arith.get_multiple_bycall` 只返回 1/2/4/0（`call>60→1`、`call>40→2`、`call>0→4`），与设计四档数值、结构均不符。
+
+## 2. 爬坡 / 傍王 房间选项未做成开关
+
+- `arith.get_upgrade` 用 `halfcall = ceil(call/2)` 作小光/过庄分界与升级级距；设计常规算子该分界**固定 40**、级距**固定 40**。
+- 代码里**没有任何读取房间「爬坡 / 傍王」勾选的分支**：`grade_w`（傍王）无条件计算、`halfcall` 恒用。设计 §7.3 / §8.3 / §10.3 中这两项都是可选规则，需要开关。
+
+## 3. 扣底倍数不符
+
+- 设计 §6.3：单张主 ×1、主对子 ×2、两连对 ×4、三连对 ×6、N 连对 ×2N（线性）。
+- 代码 `arith.get_bottom_multiple`：单张 →2、对子 →4、两连对 →8、三连对 →16、四连对 →32、五连对 →64（近似指数），且单张即翻倍；六连对落空返回 `undefined`。
+
+## 4. 「固定主牌 ≥10 张」给了算奖
+
+- 代码 `arith.get_chongguan` 对 `王+2+7≥10` 追加 `total−9` 奖（「10 个老主判断」）。
+- 设计 §8.2 明确举例：固定主牌 ≥10 张只触发**亮牌**、**不触发任何算奖**。
+
+## 5. 算奖归属模型与结算方式不同
+
+- 设计 §8.1：常规算奖**只计庄家**；§8.3 傍王才庄闲都算（且需勾选）；§8.4：算奖额外支付额 = `X × N`（`X` 为第 7 节算出的基础输赢子数）。
+- 代码：对**三家**都算「冲关」并两两结算，且叠加「冲关必叫 / 四王必踢」的**作废**规则（设计中无此机制）；`grade_cg`、`grade_w` 是**扁平奖数差**（每奖记 1 子），**未乘 `X`**。
+
+## 6. 叫分缺上限校验
+
+- 设计 §4：叫分范围 5 ~ 70。
+- 代码 `mod.jiaofen` 只校验 `call%5==0` 与「后叫必须更低」，**缺 `call<=70` 上限**，首家可叫出 75、100 等非法分值。
+
+## 7. 投降资格范围过宽
+
+- 设计 §4.4 / §7.1：投降是 **70 分坐庄专属**分支。
+- 代码 `mod.touxiang` 用 `call < 65 → 拒绝`，即 **65 分也能投降**。
+
+## 8. 70 分暗牌亮 3 秒等交互细节未实现
+
+- 设计 §4.4 / §7.1：70 分坐庄，8 张暗牌需向两个闲家亮 3 秒（投降 / 打牌都要）。
+- 代码未见相关下发逻辑。
+
+---
+
+以上为初步清单。经逐节精查后，另发现若干**运行期代码缺陷**（如 `can_followcard` 引用未定义变量 `tuolaji_list` 会抛异常、`can_playcard` 的 14 张上限 `do_returnfalse` 漏写括号导致失效等）、以及**甩牌合法性 / 强制跟牌 / 局数扣卡 / 查牌模式**等更多不一致，详见 [`01-design合规逐节核对.md`](./01-design合规逐节核对.md)。
+
+> **本文与 01 的前两轮都只沿 design.md 逐节核对玩法规则**，因此平台接入、客户端入参校验、下发面一致性、协议红线这几类问题整类不在核对范围内。第三轮补上这些维度后又查出 1 项阻断级（子游戏从未在 `server/youle/app.js` 注册，运行时完全不可达）、3 项严重（重复牌id 可伪造牌型、入参无类型校验、下发面 `multiple` 忽略爬坡开关）与协议红线缺失（全仓无 `data.success`），见 [`01`「第三轮核对」](./01-design合规逐节核对.md#第三轮核对平台接入--入参--下发面--协议红线)。

server/games/erqiwang/docs/compliance/01-design合规逐节核对.md

@@ -0,0 +1,531 @@
+# 二七王 服务端实现 vs `design.md` 逐节合规核对
+
+> 权威方向（同根 `CLAUDE.md`）：`design.md` 是玩法规则的**唯一权威**。凡代码与规则冲突，除非规则项标注「待确认」，一律视为**代码缺陷**，应改代码去符合规则，**不得改规则迁就代码**。
+>
+> 核对对象：`server/games/erqiwang/` 下 `mod.js`、`class.pai.js`、`class.paiju.js`、`class.arith.js`、`class.desk.js`、`class.export.js`、`class.import.js`。
+>
+> 严重度标记：
+> - 🟥 **严重**：影响发牌 / 计分 / 输赢 / 核心玩法正确性。
+> - 🟧 **中等**：可选规则缺失、边界校验缺失、局部规则偏差。
+> - 🟨 **轻微**：交互提示 / 展示细节 / 死代码。
+> - 🐞 **代码缺陷**：运行期异常或明显写错（无论是否直接违背规则）。
+> - ✅ **符合**。
+
+---
+
+## 整改进度
+
+> 本轮已按 design.md 修正的项（均已用 Node 脚本对 design 判定表逐格验证，见"验证"列）。下方"结论摘要"与各节详评仍保留**原始不一致**描述以留痕；本节记录当前状态。
+
+> **二次全量复核结论（限定范围）**：对整改后代码做了一次独立对抗性复核（§7/§8 算子算奖、§5 出牌甩牌、§4 开局投降暗牌阶段机、§2/§3/§9/§10 编码查牌房间，逐条比对 + Node 实测）。结果：**就 design.md 的玩法规则维度而言，服务端符合**，且未发现整改引入的符号/下标/边界错、无 step4 死代码残留、投降 36 张快照与 X×N 算奖均正确。
+> - 复核时发现的唯一未落地项 **§5.4.4 强制跟牌分量拆解已于本轮修复**：合法甩牌在 `can_playcard` 记录分量需求 `shuai_demand`（拖拉机长度/对子/单张），存入 `playproc`；跟牌时 `do_playcard` 调 `arith.flush_follow_ok` 在"同花色凑张数、主牌最大化"之上追加"拖拉机→对子→单张"的强制分量匹配（能凑同长主拖必凑、能凑主对必凑，不得拆散去垫）。已用 Node 正反面/边界用例验证。
+>
+> ⚠️ **该结论只覆盖"玩法规则是否符合 design.md"这一个维度**。第三轮核对（见下方「第三轮核对」）在**平台接入、客户端入参校验、下发面一致性、协议红线**四个维度上又发现 1 项阻断级、3 项严重、若干中等缺陷——它们不属于 design.md 的玩法条款，所以逐节核对没有覆盖到，但同样会让服务端跑不起来或被利用。**"符合 design.md" ≠ "实现完整正确"**，后续复核不要再把前者当成后者。
+
+| 项 | 位置 | 整改内容 | 验证 |
+| --- | --- | --- | --- |
+| D1 崩溃 | `class.arith.js` `can_followcard` | 用 `get_pairlist`+`get_tuolaji_list(_followcards)` 校验拖拉机牌型，消除未定义 `tuolaji_list` | 语法通过 |
+| D3 | `can_playcard` | `do_returnfalse;` → `do_returnfalse()`，恢复 14 张上限 | 语法通过 |
+| D4 | `do_choiceflower` | 删除空循环死代码 | 语法通过 |
+| §6.3 | `get_bottom_multiple` | 改为线性：单张 1、主对 2、N 连对 2N | ✅ 10 用例 |
+| §7 算子 | `get_base_bycall`/`get_qvalue`/`get_upgrade`（新）+ `get_paiju_account` | 实现常规算子(大光×3、Q=40) 与爬坡(§7.3 分段) 两套，按爬坡位(roomtype 位3)切换；`X=multiple×|upgrade|` | ✅ 74 格逐档 |
+| §8.1 | `get_chongguan` + `get_paiju_account` | 常规算奖只计庄家；连对链修复（传实际主花色）；移除 ≥10 老主奖；去掉设计外的"冲关必叫/四王必踢"作废 | ✅ get_chongguan 用例 |
+| §8 快照 | `get_seat_cards_award`（新） | 庄家用埋牌后 28 张（排除已埋）、闲家用发牌后 28 张 | 语法通过 |
+| §8.3 傍王 | `get_paiju_account` | 改为按傍王位(roomtype 位2)开关，庄闲每王 1 奖，去作废 | ✅ 公式用例 |
+| §8.4 | `get_paiju_account` | 算奖并入结算改为 `X×(2Ni−Nj−Nk)`（乘 X） | ✅ §8.4 举例 |
+| §4.2 | `mod.jiaofen` | 增加叫分上限 `call<=70` | — |
+| §4.4 投降 | `mod.touxiang` + `do_burycard` + `get_deskinfo` | 投降仅 70 分、在**选主阶段 step2** 与选主互斥、不选主不埋牌；结算基础 1、庄输 1 子/闲；算奖用庄家 **36 张**（发牌+暗牌，无主花色→无连对链）；埋牌后 step 直接进 5、删除已废弃的投降 step4 与重连 Surrender 视图 | — |
+| §10.1 | `get_asetcount`/`get_needroomcard` | 局数 6/12；房主扣卡 2/4 | — |
+| §5.4 甩牌 | `arith`(新增 `trump_rank`/`decompose_trump`/`opp_can_beat_flush`/`flush_follow_ok`/`remove_pairs`)+ `can_playcard` + `do_playcard` + `mod.chupai` | 副牌绝对禁甩；最大性改为**按对手全部主牌**逐分量判定；甩错惩罚（收回、只打最小一张、下发 `shuaicuo`）；**§5.4.4 强制跟牌分量拆解**（拖拉机→对子→单张优先级，`shuai_demand`+`flush_follow_ok`） | ✅ 分解/最大性/各路径/跟牌分量用例 |
+| roomtype | `class.config.js`（新）+ `export`/`paiju` | 数组下标改为**位串**（`"01011"`），`class.config.js` 唯一解析（SSOT） | ✅ parse/扣卡/局数用例 |
+| §4 暗牌亮牌 | `shangzhuang` + `get_deskinfo` | 70 分坐庄把 8 张暗牌下发给所有玩家 + `ancard3s=1`（供摸牌前亮 3 秒）；修正**非 70 分暗牌泄露给闲家**（现暗牌只发庄家，符合 §4"只有庄家可见"）；重连的暗牌一律仅庄家可见 | — |
+| §8.2 亮牌 | `get_liangpai`（新）+ `mod.maipai` + `get_deskinfo` | 庄家埋牌后 28 张按阈值（固定主≥10/王≥3/7≥6/2≥6）统计，出牌开始向闲家亮（只亮数量/结构）；可查牌模式才下发 | ✅ 阈值/统计用例 |
+| §9 查牌 | `class.config.js`(nocheck) + `mod.chupai` + `get_deskinfo` + `mod.mingpai`(新) | 报无主的座位统计 `info`/`baozhu`/`PushCards.seatlist` 与亮牌均按 `cfg.nocheck` 门控；新增 `mingpai` RPC（可查牌+已报无主时查看他家全部主牌） | — |
+
+**尚未整改（多需与客户端/协议协同，或为较大的独立子系统）**：
+
+- ✅ **§5.4 甩牌（已全部完成）**：副牌绝对禁甩、最大性按对手全部主牌逐分量判定、甩错惩罚、以及 §5.4.4 强制跟牌分量拆解（`flush_follow_ok`：拖拉机→对子→单张优先级）均已实现并用 Node 验证。
+- 🟩 **§9 查牌 / §8.2 亮牌（服务端已完成）**：亮牌 `get_liangpai`（庄家埋牌后 28 张按阈值统计）在 `maipai`/重连下发给闲家；报无主的座位统计（`info`/`baozhu`/`PushCards.seatlist`）与亮牌均按查牌位 `cfg.nocheck` 门控（不查牌一律不下发）；新增 `mingpai` RPC（可查牌 + 已报无主时查看他家全部主牌）。剩客户端展示（面板/明牌按钮）。
+- 🟩 **§4.4 70 分暗牌亮 3 秒（服务端已就绪）**：`shangzhuang` 对 70 分坐庄把 8 张暗牌下发给所有玩家并带 `ancard3s=1`，供客户端在庄家摸暗牌前亮 3 秒；顺带修正了**非 70 分把暗牌泄露给闲家**的问题（现非 70 分暗牌只发庄家，符合 §4"只有庄家可见"）。剩下的 3 秒动画由客户端完成。
+- ✅ **§11 闲家 3 提示（踩/没分/有分）**：`mod.tishi` 服务端转发给对家已实现；剩客户端展示。
+- 🟧 **客户端建房配置**：`roomtype` 已改为位串（见下表：位0局数/位1扣卡/位2傍王/位3爬坡/位4查牌），需在 erqiwang 客户端建房界面按位勾选拼串；服务端已按该格式读取（`class.config.js`）。
+
+### roomtype 位串约定（服务端已按此读取；解析入口 `class.config.js`）
+
+`roomtype` 为**定长数字位串（字符串）**，每一位（`charAt`）一个开关 `'0'/'1'`，便于前端逐项勾选。缺省 `"00000"` = 6局/房主扣卡/无傍王/常规算子/可查牌。解析对缺失/过短字符串按 `'0'` 兜底。
+
+| 位 | 含义 | `'0'` | `'1'` |
+| --- | --- | --- | --- |
+| 0 | 局数 | 6局（缺省）| 12局 |
+| 1 | 扣卡方式 | 房主扣卡（缺省）| AA每人扣卡 |
+| 2 | 傍王 | 关（缺省）| 开 |
+| 3 | 爬坡 | 常规算子（缺省）| 爬坡 |
+| 4 | 查牌模式 | 可查牌（缺省）| 不查牌 |
+
+示例 `"10100"` = 12局 / 房主扣卡 / 傍王开 / 常规算子 / 可查牌。
+
+---
+
+## 第三轮核对（平台接入 / 入参 / 下发面 / 协议红线）
+
+> 前两轮只沿 design.md 逐节核对玩法规则，因此**整类问题在核对范围之外**。本轮补上这些维度，结论如下（均已修复并有单测回归）。
+
+| # | 严重度 | 位置 | 问题 | 处置 |
+| --- | --- | --- | --- | --- |
+| A1 | 🟥 阻断 | `server/youle/app.js` | 只加载 `games2/jinxianmahjong/mod.js`，**从未加载 `games/erqiwang/mod.js`**，全仓平台侧对 erqiwang 零引用 → `youle_erqiwang` 模块从不创建、`pack.route="erqiwang"` 无法命中三层路由，**整个子游戏运行时不可达** | 已在 app.js 补注册（server dev-guide README 允许触碰的唯一平台文件） |
+| B1 | 🟥 严重 | `class.paiju.js` `check_cards_inhand` | 不查重复牌id：`do_playcard([方块K,方块K])` 实测 `result=true, cardtype=201`——同一张牌被判成一对，可伪造拖拉机/甩牌分量，且该分牌 score 被重复累加；`maipai` 传 8 个相同 id 实测**只埋下 1 张**，庄家带 35 张进入出牌阶段 | 新增 `check_cards_valid`（非空数组 / 0~107 整数 / 无重复）作为唯一入参校验入口 |
+| B2 | 🟥 严重 | `mod.js` `maipai`/`chupai` | 越界 id 或非数组入参在解引用处抛异常，中断 `DoPack`；且 `cards.length` 读在校验之前 | 校验前置于 length 判断之前 |
+| B3 | 🟥 严重 | `arith.get_multiple_bycall` + 6 个调用点 | 写死 `climb=false`：**爬坡房对局全程界面显示常规算子子数，与结算 `aset.multiple` 不符**（叫 45 分：界面 6、结算 7） | 删除该兼容包装，全部改调 `get_base_bycall(call, cfg.climb)`，与结算同源 |
+| C1 | 🟥 红线 | 全部下发包 + 所有失败分支 | **全仓无 `data.success`**；失败一律裸 `return`、不回任何包，前端只能干等倒计时。违反 server dev-guide「成败唯一是 data.success、主动推送必须自带」与 client dev-guide「发包只请求、收包才表现」 | 成功包统一补 `success:true`；新增 `ERR` 码表 + `do_sendfail`，每条失败分支回 `success:false + errcode` 给请求者 |
+| D1 | 🟧 中等 | `arith.is_continuous` | `is_8`/`is_6` 只判 `code % 100`、不校验花色：`is_continuous(♥8=308, ♣6=206)` 实测为 `true`。`get_chongguan` 是唯一扫描整手牌（含各花色副牌）的调用点，连对链走到主 8 后会被任意花色的一对 6 错误接续、多算奖（design §8.1 要求 A~5 段必须是主花色） | 追加「编码相差 2」约束（同花色 8/6 恒差 2） |
+| D2 | 🟧 中等 | `export.get_deskinfo` pushlist | ① 内层循环上界误用轮次数当座位数，实测 5 轮时内层被撑成长度 5 且含 `undefined`；② 排序传的是上个循环泄漏的 `pai.flower`（=最后一张牌大王的花色 5），等于按「无主牌」排序 | 内层固定 3、改用 `paiju.flower`，并对缺失轮次加守卫 |
+| D3 | ✅ 规则如此 | `class.desk.js` | 下发了 `countdown`，但服务端无任何定时器做超时托管，玩家不操作则牌局停住等待 | **规则设计者确认：维持现状、不做超时动作**。已写入 design §11「倒计时只作展示，不触发任何自动操作」并注明不是缺口；牌局停住由玩家走房间解散流程收场（按当前累计分结算，design §12.2）。server dev-guide「服务端自动操作复用真人链路」约束的是「若要做代打就必须复用真人链路」，本局不做代打，故不适用 |
+| D4 | 🟨 轻微 | `paiju.do_playcard` | 报无主后只更新出牌者自己那一格，B/C 要等各自轮到出牌才补上，界面最多滞后两次出牌（design §9 要求「为全体三人显示另外两家」） | 改为一旦 `have_baofu()` 成立即按实际手牌刷新三个座位 |
+| D5 | 🟨 轻微 | `can_playcard` / `chupai1` | `cardtype` 只能表达单一牌型，甩牌被压平成 1xx/2xx（「主K对+主5」→103），客户端连"这是一次甩牌"都看不出来 | `chupai1` 增发 `shuai` 分量构成（与 `shuai_demand` 同源） |
+| D6 | 🟧 中等 | `export.get_deskinfo` | 不查牌模式下 `pushlist`（已打出牌历史）仍照发。规则设计者已确认：**不可查牌模式必须屏蔽出牌历史，只有可查牌模式才能查看** | 已按确认修复：`pushlist` 按 `cfg.nocheck` 门控；design §9 同步改写为无歧义表述（四项功能整体开关 + 「当前轮桌面牌不属于查牌、两种模式都可见」的边界） |
+| D7 | 🟨 轻微 | `check_cards_inhand` | 牌已出/已埋时 `return;`（undefined）而非 `false` | 已改为 `return false` |
+
+### 尚未处置
+
+**无。** 本轮发现的 11 项已全部收口：
+
+- A1/B1/B2/B3/C1/D1/D2/D4/D5/D7 共 10 项为缺陷，已改代码 + 补单测；
+- D6（不查牌是否屏蔽出牌历史）原为规则歧义，已由规则设计者拍板「屏蔽」，改 design §9 + 代码 + 单测；
+- D3（超时托管）原列为待外部输入，已由规则设计者拍板 **维持现状、不做超时动作**，属**规则如此、并非缺陷**，已写入 design §11 固化，避免后续核对反复把它当缺口重提。
+
+---
+
+## 第四轮核对（全量重核 design.md：先流程、后规则细节）
+
+> 从 design.md §1~§12 重新逐条对照当前代码（含流程阶段机与全部规则细则），**流程层无缺环**（发牌→叫分→摸暗牌/70分亮3秒→选主/投降互斥→先选主后埋牌→出牌→末轮扣底→算子+算奖→轮庄→大局/解散结算，`step` 迁移 1→2→3→5→6 闭合）。规则层新发现 3 项不一致，已全部修复并补回归单测。
+
+| # | 严重度 | 位置 | 问题 | 处置 |
+| --- | --- | --- | --- | --- |
+| E1 | 🟧 中等 | `class.paiju.js` `get_liangpai` | 亮牌统计取 `get_seat_cards`（只含未出的牌），而 §8.2 的依据是**庄家埋牌后的手牌**。埋牌那一刻算对，但 `get_deskinfo` 在 step5 重连时会按庄家**当前剩余手牌**重算：实测「4王+6个7」的庄家打掉 2 大王 + 1 对♦7 后，重连再取从 `{zhu:10,zhupair:5,zhutuo:1,wang:4,qi:6}` 变成 `null`，闲家重连即丢失亮牌 | 改用已有的静态快照 `get_seat_cards_award(o_paiju, banker)`（埋牌后 28 张、含之后已打出的），并在函数注释里固化"不得用 get_seat_cards"的原因；补 3 条回归用例（快照 / 打出后重连不缩水 / 已埋牌不计入） |
+| E2 | 🟨 轻微 | `mod.js` `chupai` | 第三轮 D4 只修了服务端状态（`do_playcard` 里已按 `have_baofu()` 同时刷新三个座位），**下发面没跟上**：出牌包仍只带 `info = seatlist[seat]` 一家，另两家的主牌数/对子数要等它们各自出牌才送达，仍最多滞后两次出牌，与 §9「一旦有人报无主，立即为全体三人显示另外两家」不符 | 出牌包改发整表 `seatlist`（三家），字段名/结构与重连包 `PushCards.seatlist` 统一；协议文档三处 `info` 条目同步改写；补「整表带三家 + 含非出牌者统计」用例 |
+| E3 | 🟨 轻微 | `class.arith.js` `can_playcard` | 开头 `if (cards.length > 14)` 是"规则外的约定"硬上限，与 §5.4.3「甩牌无组合数量限制」冲突：手持 15 张以上顶级主牌时的合法甩牌会被整个拒掉（如 4王+8个7+正2对+副2对 共 16 张） | 上限改为结构性上界 28（出牌阶段单人最多持 28 张，且 28 张内牌型编码不溢出 1xx/2xx/3xx 区间），不再设规则性限制；补 16 张合法甩牌用例 |
+
+**非缺陷的观察（本轮确认，勿再重提）**：
+
+- 70 分「暗牌亮 3 秒」：服务端在上庄包里一次性下发 8 张暗牌 + `ancard3s=1`，"摸入前亮 3 秒"的先后由前端表现；重连不重放该一次性事件。design 未要求服务端表达先后，**按现状即合规**。
+- §4/§11「选主按钮显示各花色对子数」：design 标注为**前端表现**，服务端已把庄家全部手牌下发，前端可自算，**不是下发面缺口**。
+
+### 尚未处置
+
+**无。** E1/E2/E3 已全部改代码 + 补单测，协议文档同步。
+
+### 第四轮·复验（E1~E3 修复后的独立取证复核）
+
+对修复后的实现又做了一次**取证式**复核：不再靠通读，而是把 design 的判定语句直接做成可执行探针打在代码上。**未发现新的不一致**，全部符合。取证覆盖：
+
+| 维度 | 取证方式 | 结果 |
+| --- | --- | --- |
+| §5.1/§5.2 跟牌 | 层级 2/3/4（放着更长拖拉机不出→拒、拆对出散张→拒、留着对子只出散张→拒）、同花色不足全出+缺口任意、混合出牌牌面判 0、毙牌须完全缺门且牌型对应、首家出主必须跟主 | 15/15 符合 |
+| §8.1 算奖 | 三/四王、链从正 7 起、无正 7 链断、正 7-副 7-正 2-副 2-主 A-主 K 链 5、副 K 对(非主花色)不入链、六/七/八个 7 与 2、固定主 ≥10 不给奖 | 13/13 符合 |
+| §7 算子 | 常规与爬坡逐档抽查 18 格（含大光/小光/过庄/升 N 级、爬坡 45 独有档、10 分与 5 分无小光档） | 18/18 符合 |
+| §5.4 甩牌 | 单一牌型不算甩牌、分量被更大同长拖拉机压→甩错、对手仅持更大散张压不了对子、甩错只打最小一张、"持有即算被压" | 6/6 符合 |
+| §6.3 扣底 | 混合甩牌取最高规格倍数、末轮用副牌赢不扣底 | 符合 |
+| §8.4 结算 | **闲家也持奖时的三条独立支付线**（此前未覆盖）：`N=[4,1,0]`→`aw=[28,-8,-20]`，与捡分子数叠加后零和 | 符合 |
+| §12 全流程 | 端到端跑通整局 + 18 局随机模糊（含甩牌轮），校验牌张守恒/捡分一致/结算零和/分配公式/扣底触发条件 | 无异常 |
+| §4/§9/§10/§11 | 叫分 6 种序列（含跳过已"不叫"者）、70 分暗牌下发与投降资格、重连各阶段门控（暗牌仅庄家、pushlist/seatlist/亮牌按 `nocheck`、当前轮桌面牌两种模式都有）、爬坡房 `multiple` 三处同源、提示只发对家、明牌返回另两家全部主牌、扣卡 4 组合 | 全部符合 |
+
+固化产物：新增 `test/test_endgame.js`（L4 端到端，21 项，断言均与具体牌面无关、连跑 10 次无抖动），全套单测 **389 项**全绿。
+
+---
+
+## 第五轮核对（design 复验 + 首次以 packet_protocol.md 为核对对象）
+
+> 本轮做两件事：① 再次独立复核 design.md ↔ 代码；② **首次把 `docs/protocol/packet_protocol.md` 本身当作核对对象**（前四轮只在改代码时顺手同步文档，从未反向验证「文档写的 = 客户端实际会收到的」）。
+>
+> **design 维度**：§1~§12 逐条重核，含自行重算 §7 边界档（爬坡 10 分/5 分无小光、70 分打牌、常规 40 分无过庄）与 §8.1 连对链（正 7 起链、副 7 跨花色不成对、非主花色断链）——**规则层未发现新的不一致**，前四轮整改均真实落地。
+>
+> **新发现 4 项**（1 项严重缺陷 + 2 项协议文档不准确/不完整 + 1 项健壮性），已全部处置。
+
+| # | 严重度 | 位置 | 问题 | 处置 |
+| --- | --- | --- | --- | --- |
+| F1 | 🟥 严重 | `class.arith.js` `can_followcard` 尾段 | 计算 `cardvalue` / `noflower` / `nopair` 时用的是**入参原始数组 `followcards`**（客户端提交顺序），而不是上面已排好序的副本；`get_pairlist` / `get_tuolaji_list` 都按**降序相邻**取对。端到端实测：庄家出红心 KKQQ、闲家用黑桃 KKQQ 主拖拉机毙牌且为末轮——降序提交 `[51,105,50,104]` → `maxseat=1`、闲家捡分 40、扣底 ×4；打乱成 `[51,50,105,104]` → 对子漏判、`cardvalue=0`、`maxseat=0`（庄家赢）、捡分 0（大光）、不扣底。**同一手合法牌，客户端只靠数组顺序就能翻转本轮胜负、捡分归属、扣底与最终结算**；同源问题还能抹掉 `noflower` 缺门标志、污染 §9 下发给全场的牌况表。踩 server 红线「前端不是数据源」「服务器权威」 | 在 `min_ary_deduct` 削减 `_followcards` **之前**另存完整排序快照 `_sortfollow`，尾段 8 处全部改用它（`_followcards` 会被削减、不能复用）；函数内注释固化"绝不能用入参 followcards"的原因。补 6 条回归（`test_follow.js` 入参顺序无关性 5 条 + `test_endgame.js` 端到端 1 条），已验证**回退修复后这 6 条全红** |
+| F2 | 🟧 中等 | `packet_protocol.md` §14 | 「解散结算」被写成 `route=erqiwang / rpc=jiesuan` 的独立包。实际平台（`server_room/rpc.js`、`server_room/class.room.js`）是把 `get_disbandRoom` 的**返回值整个对象**塞进**房间路由**的解散包：`route=room / rpc=free_room`，`data.deskfree = { rpc:"jiesuan", data:{ success, aset, account } }`——**多一层 `data` 包装**，真实路径是 `data.deskfree.data.aset`。前端照原文档写会取空。另外该包外层 `data.success` 由平台填写，子游戏的 `success` 在 `deskfree.data.success`，与 §0.1 的读法不同 | 新增 §14.1「解散结算的投递方式」：给出真实包结构 JSON、三条取值要点、两层 `success` 的归属，并说明 `deskfree` 可能缺失（见 F4）；§14 开头标注原表头只适用于正常出牌结算与投降结算 |
+| F3 | 🟨 轻微 | `packet_protocol.md` 全篇 | 文档在 `multiple` / `bangwang` / `climb` / `baozhu` / `seatlist` / `liangpai` / `pushlist` 等多处引用「roomtype 位2 / 位3」，但**全文从未给出 roomtype 位串定义**——它只存在于本 compliance 文档里。前端据协议文档无法拼出建房串 | 新增 §0.5「`roomtype` 房间选项位串」：位表（位0局数/位1扣卡/位2傍王/位3爬坡/位4查牌）+ 缺省与示例 + 缺失兜底规则 + 局数/扣卡 4 组合对照，并指明 `class.config.js` `parse()` 是唯一解析入口（SSOT） |
+| F4 | 🟨 轻微 | `class.export.js` `get_disbandRoom` | 未像 `get_deskinfo` 那样判 `o_room.o_desk` / `curr_paiju()` 为空。平台在 `rpc.js` 开战处 `makewar` 后**立刻**置 `battlestate=1`，而本游戏首局是 `makewar` 里 `min_ontimeout(...,1000)` 延迟创建的——这段窗口内解散会在 `curr_paiju()` 的 `undefined` 上解引用抛异常，打断平台整条解散链路 | 两级空守卫，返回 `null`（平台对 `null` 的 `_deskfree` 已有「照常发解散包、不带 deskfree」分支）；补 2 条回归用例 |
+
+**本轮同时复核并确认无误（勿再重提）**：
+
+- **协议文档字段面**：跑完整局（含 `mingpai`/`tishi`/失败包/投降局）与重连五个阶段，把**实际下发的 `data` 键集**与文档逐包对齐——`fapai / jiaofen / shangzhuang / xuanzhu / maipai / chupai1,2,3 / jiesuan / mingpai / tishi / zhunbei` 及 `deskinfo` 的 `CallRun / ChooseMain / BuryCards / PushCards / Balance`，**字段名、出现条件、按座位裁剪（暗牌仅庄家、`gradecards` 仅闲家、`liangpai` 仅闲家+可查牌、`cardsinhand` 仅出牌者）全部一致**；`errcode` 码表、§0.1 `success` 约定、§0.3「`countdown` 无定时器」说明亦准确。
+- **`can_followcard` 首家/跟家牌面值的比较基准不一致（首家取拖拉机最小对、跟家取最大牌）**：因同花色同长拖拉机不可能共用点数（两副牌已被首家占满），两段区间必然不重叠，比较结果恒正确，**属既有写法差异、非缺陷**。
+- **`get_chongguan` 的 `cards.length < 28` 早退**：属隐式兜底写法，但三个调用点的快照恒为 28（闲家）或 36（70 分投降的庄家），**当前不可触发**。
+
+### 尚未处置
+
+**无。** F1/F4 已改代码 + 补回归单测（并已用「回退修复→用例转红」反验有效性），F2/F3 已改协议文档。全套单测 **401 项**全绿。
+
+### 第五轮·复验（design 维度的穷举/差分取证）
+
+F1~F4 修复后，对 **design.md 维度**又做了一次独立取证复核。方法上比前几轮更进一步：不再逐条读代码，而是**按 design 原文另写一份参考实现**，再和代码**穷举对拍**——参考实现只依据 design 的文字与表格，不看 `class.arith.js`。**未发现任何不一致。**
+
+| design 章节 | 取证方式 | 规模 / 结果 |
+| --- | --- | --- |
+| §2 牌局构成 · §6.1 分牌 | 直接清点 `init_cards` 产物 | 108 张牌表 / 去 3-4 共 16 张 / 发 92 张 = 三家 84 + 暗牌 8 / 11 种点数各 8 张 + 大小王各 2 张 / 分值 5-10-K / 全场总分 200 ✅ |
+| §3 主牌顺序 · 对子判定 | 取全部主牌排序后归并成「等级序列」，与 §3 表逐级比对 | 大王-小王-正7-副7-正2-副2-主A…主5 共 15 级完全一致；副牌 A…5 顺序一致；♥7+♣7 / ♥2+♣2 / 大王+小王 均不成对，同花色两副成对 ✅ |
+| §5.3 拖拉机相邻 | 15 级相邻链逐段验证 + 反例 | 链全通；7 不与 6/8 相连、6 与 8 同花色相连、♥8+♣6 跨花色不相连、副2 只接主A ✅ |
+| §5.1 / §5.2 跟牌强制层级 | **穷举差分**：按 §5.2 原文写参考裁定（缺门/不足/够牌 × 单张/对子/N 连对 + 最长拖拉机优先的档案比较），随机手牌枚举**全部** C 张出牌组合逐个对拍 | 4000 手牌 / **86474 个出牌组合，失配 0** ✅ |
+| §5.4.1-3、§5.4.5 甩牌 | **随机差分**：按 §5.4.2 原文写「对手是否持有能压过任一分量的主牌/主对/同长主拖」的参考判定 | **6000 例，失配 0**；副牌禁甩 4 种组合全拒、副牌单一牌型全放行 ✅<br>（首轮出现的 170 例「最小张不符」经查是**同一等级的两副牌选了不同那张**，非分歧——改按牌面等级比对即归零） |
+| §5.4.4 强制跟牌分量拆解 | 按 §5.4.4 五条逐条造正反用例 | 同长主拖必出 / 无同长退化为主对 / 主对不够全出+主单补 / 主牌不够全出+垫副 / 无主牌随意垫 / 多组不同长拖拉机逐组匹配，12 条全符合 ✅ |
+| §5.4.5 甩错惩罚落地 | 走 `do_playcard` 真实链路 | 甩错后 `shuaicuo=true`、实际只打出最小一张、其余收回手牌、本轮牌型退化为 101、不再带 `shuai_demand` ✅ |
+| §6.2 捡分归属 | 造庄赢/闲赢两轮 | 庄家赢 → 台面分牌作废（闲家捡分 0）；闲家赢 → **台面全部分牌（含庄家自己打出的）** 计入闲家 ✅ |
+| §6.3 扣底倍数 | §6.3 表逐格 | 单张 1 / 主对 2 / 2-6 连对 4·6·8·10·12；混合甩牌取最高规格；末轮用副牌或混合牌赢 → 0 不扣底 ✅ |
+| §7 算子（全部） | **全量对拍**：把 §7.2.1 / §7.3.3 的判定表转写成参考实现，两种算子模式 × 14 个叫分档 × grade 0~260 逐格比 base / Q / 判定 / 最终子数 | **14672 格失配 0**，另抽查 design 表格里写死的最终子数 **113 格失配 0** ✅ |
+| §8.1 常规算奖 | 逐组合造手牌 | 三王 1 / 四王 3 / 六·七·八个 7 → 1·2·3 / 六·八个 2 → 1·3；连对链 正7→副7→正2→副2→主A→主K 逐级 2·3·4·5·6·7 奖；链必起于正7（无正7 断链）、缺副7 断于正7、副A 对（非主花色）不入链、无三王则无链奖、固定主 ≥10 不给奖 ✅ |
+| §8.2 亮牌 | 四档阈值边界（含刚好差 1） | 王≥3 / 7≥6 / 2≥6 / 固定主≥10 分别触发，各自差 1 即不触发；输出只含数量与结构、无具体牌面 ✅ |
+| §8 快照时间点 | 走真实埋牌/出牌/投降链路 | 庄家=埋牌后 28 张（已埋 8 张不在内、出牌后不缩水）、闲家=发牌后 28 张、投降局庄家 36 张且 `flower=-1` ✅ |
+| §8.4 算奖并入结算 | §8.4 举例数值 | `X=6, N=[1,2,0]` → `aw=[0,18,-18]`，三条支付线零和；只庄家持奖 → 另两家各付 X ✅ |
+| §4.2 叫分 | **穷举全部叫分序列**（DFS，叫分集 {70,50,25,10,5}+不叫） | **80 条终局路径**：受理判定、待叫者永不落在已「不叫」者身上、上庄者恒为最低叫分者、上庄条件恒为「叫 5」或「另两家都不叫」，**异常 0**；首家不能不叫、75/71/67/3/-5 全按 PARAM 拒 ✅ |
+| §4.3 暗牌可见性 · §4.4 投降 | 非 70 分 / 70 分两条链路 + 重连 | 非 70 分暗牌只给庄家（闲家无 `bottomcards`、无 `ancard3s`、无 `cards`）；70 分三家都收到 8 张 + `ancard3s=1`；重连一律只给庄家（3 秒亮牌不重放）；`touxiang` 仅 70 分为 1；投降 base=1、庄 -2 闲各 +1 ✅ |
+| §4.6 轮庄 | 三种 result | 庄赢连庄 / 闲赢顺延下家 / 投降顺延下家；首局暂定庄家为 0 号座位 ✅ |
+| §9 查牌模式 · §10 房间设置 · §11 提示 | 可查牌与不查牌两套房间跑同一段对局 | 可查牌下 `chupai.seatlist` 整表三家、`baozhu` 有值、重连带 `pushlist`/`seatlist`；不查牌下三者全无、`baozhu` 恒 0、明牌回 RULE；**当前轮桌面牌（`playproc`）两种模式都下发**；局数 6/12、房主 2/4、AA 1/2 与加入者扣卡 4 组合正确；提示只转发给对家、庄家发 → RULE、非法 tip → PARAM；不操作则 `step`/`playproc` 不变（无超时托管）✅ |
+
+> 一句话结论：**就 design.md 而言，服务端实现完整且准确**。本轮两次「疑似失配」（甩错最小张 170 例、闲家赢轮捡分 15 vs 10）经查**都是探针写错**，代码是对的；已在上表注明，后续核对不要再把它们当缺陷重提。
+>
+> **已固化两组差分测试入库**（其余取证为一次性探针）：`test/test_calc.js`（§7 全量对拍，7308 格 + design 表 141 格）与 `test/test_followdiff.js`（§5.2 穷举差分，约 11 万组），全套单测由 401 项增至 **462 项**，总耗时仍 < 1.5s。
+>
+> 两组都做过**变异检验**：关掉 `follow_tractor_cover_ok` → `test_followdiff` 三种拖拉机首出全红；大光倍率 3→4 / 常规 55 档 base 4→5 / 爬坡 40·35 档 Q 20→40 → `test_calc` 精确指出档位与 grade。
+>
+> ⚠️ 固化过程中的一个教训（改这两个文件时别踩回去）：**差分测试的强度取决于造牌器，不取决于对拍逻辑**。第一版用纯随机抽牌，跑 7.8 万组全绿，但关掉 `follow_tractor_cover_ok` **依然全绿**——因为「同花色三组互不相邻的两连对」（12 张）这种唯一能区分"只出零散对子"与"先凑最长拖拉机"的结构，随机抽根本抽不出来（少于 3 组时任取 3 对必含相邻对，测不出差别）。补上确定性的 `structHands()` 后才转红。同理，掺入的其他花色一度把这手撑到 15 张、超过枚举上限被**静默跳过**，表面照常全绿。**"跑了很多组且全绿"不等于"测到了"，新增差分测试必须做变异检验。**
+
+---
+
+## 第六轮核对（多局大局 + 整局带牌型模糊）
+
+> 前五轮的端到端**都只跑单局、且只出单张**。本轮补两个从未被驱动过的维度：① `design §12.1 步骤10 → §12.2` 的**多局大局**（跨局轮庄、累计分、大局结算、战绩）；② **带牌型的整局链路**（对子/拖拉机/甩牌/甩错/毙牌/扣底与 `do_playcard`→`mod.chupai`→结算的集成）。**未发现任何不一致。**
+
+| 维度 | 取证方式 | 结果 |
+| --- | --- | --- |
+| §12.1 步骤10 · §4.6 跨局轮庄 | 真实驱动 6 局（RPC 全链路，含每局 `zhunbei` 开新局） | 每局 `firstseat` 与「上局 banker + result」严格对应；另单独构造出 `result=0` 的**庄赢局**验证**连庄**（此前只有 `do_prepare` 的桩单测，端到端从未走过）✅ |
+| §7 累计分 | 6 局 | 每局零和；`desk.seatlist[i][0]` == 逐局累加；`aset.seatlist[i].score` == 累计分 ✅ |
+| §12.2 大局结算 | 6 局房与 12 局房各跑满 | `account` **只在末局**出现（6 局房第 6 局、12 局房第 12 局）；打满后再 `zhunbei` 回 RULE 拒 ✅ |
+| §10.1 扣房卡 | 6 局 | 全程只扣一次（第一局结算），`save_grade` 一次 ✅ |
+| 战绩 | `save_grade` 载荷 | `gameinfo1.asetcount`/`players.score` 与累计分一致；`gameinfo2` 每局 `seatlist`/`banker`/`call`/`flower`/`result` 齐全 ✅ |
+| §12.2 中途解散 | 打完 2 局后在第 3 局解散 | 解散局 `multiple/upgrade` 均 0、三家得分 `[0,0,0]`、`result=3`；`account` 累计分 == 解散前累计分（"按当前累计分结算"）✅ |
+| 牌局隔离 | 每局开新 paiju | 新局重新发满 92 张；上一局的 `tmp_jiesuan_aset` 已清理 ✅ |
+| §5/§6/§7/§8 整局带牌型 | 160 局 / 约 3800 墩（4 个种子 × 40 局），**每一墩**用独立参考实现重算胜者与服务端比对 | 多张首出、合法甩牌、甩错、毙牌墩、扣底均大量出现；牌张守恒 84/8/16、捡分守恒、结算零和、扣底触发条件、算奖分配公式**全部相符，0 异常** ✅ |
+
+**本轮两次"疑似缺陷"经查都不是**（勿再重提）：
+
+- 某局结算 `[0,0,0]`：是 `jf=[4,-8,4]` 与 `aw=[-4,8,-4]` 恰好抵消，不是漏算。
+- 首轮 40 次尝试跑不出庄赢局：是**用例设计反了**——叫 5 分是闲家最容易达标的档（`grade ≥ 5` 即赢），应叫 70 分才易守。改后立刻出现。
+
+**固化产物**：新增 `test/test_fuzz.js`（整局模糊 + 每墩胜者差分，20 局约 480 墩，8 项聚合断言，0.3s）。多局大局部分为一次性探针未入库（跑满 12 局较慢，且其不变量已由 `test_desk`/`test_endgame`/本轮探针共同覆盖）。全套单测 **511 → 519 项**全绿。
+
+---
+
+## 第七轮核对（反方向：代码 → design）
+
+> 前六轮都是「design → 代码」方向：拿规则去找代码有没有实现。本轮换**反方向**——从代码出发，把服务端每一个规则决策与常量拉出来，逐个追问「design 里有没有明文依据」。找的是两类此前查不到的东西：**代码做了 design 没授权的事**，以及 **design 有歧义时代码替规则做的选择**。
+>
+> **结论：没有发现与 design 冲突的行为。** 但列出 6 项「design 未明文规定、由代码自行决定」的项——它们不是缺陷，但也从未被规则设计者确认过，建议逐条拍板后写回 design。
+
+| # | 代码的决定 | design 依据 | 性质 |
+| --- | --- | --- | --- |
+| R1 | 四个阶段的倒计时秒数 **15 / 20 / 25 / 30**（`class.desk.js`） | §11 只说「四个阶段都会给出一个倒计时秒数」，**未规定具体值** | 实现选择，需确认 |
+| R2 | **§5.4.4 拖拉机分量的降级阶梯不要求「最长优先」**：甩牌里有 3 连对分量而闲家只有 2 连对时，代码允许出任意 3 对，不强制先凑出那个 2 连对 | §5.4.4 第 1 条明文写「没有同等连对数的拖拉机，退而求其次用**同等张数的主对子**顶替」——支持代码；但该节开头又说「沿用 §5.2 强制层级同一原则」，而 §5.2 层级 2 要求「能凑多长就必须先凑多长」。**两处措辞可作两种解读** | 歧义，代码按显式的第 1 条实现 |
+| R3 | 服务端把提交的一组主牌按「**连续对子最大化合并成拖拉机**」分解（`decompose_trump`） | §5.4.3 只说甩牌可自由混搭，**未规定服务端如何分解**。该选择同时影响最大性判定、跟牌分量需求、扣底倍数（合并对甩牌方更有利：`AAKKQQ` 记 3 连对 ×6 而非 2 连对 ×4） | 实现选择，需确认 |
+| R4 | 两个**同级**的副 7 对（♥7对 + ♣7对）**不构成连对** | §5.3 的链只列一次「副7」，同级即非相邻——代码按此。但 design 未直说 | 解读，合理 |
+| R5 | `call` 用 `parseInt` 宽松解析：`"65"`（字符串）与 `65.5`（小数截断为 65）都会被接受；而 `cards` 是严格校验（字符串数字/小数一律拒） | design 不管入参类型；协议 §0.2 只对 `cards` 定了严格约束。**两者标准不一致**，但截断后语义正确、不改变规则结果 | 一致性瑕疵，非规则违反 |
+| R6 | `get_chongguan` 对 `cards.length < 28` 静默返回 0 奖 | 隐式兜底（违反工程总则「显式失败优于隐式兜底」）。三个调用点的快照恒为 28 或 36，**当前不可触发** | 代码风格，非缺陷 |
+
+### 本轮新增取证：下发面泄露审计
+
+design §4（暗牌只有庄家可见 / 70 分亮 3 秒）、§9（查牌模式）、§11（结束亮底牌）与 server 红线「**发全 ≠ 发多，按可见性下发**」此前**没有任何测试**——各处门控是逐条手工核对的，从未系统验证过「有没有哪个包把不该看的牌送到了某个座位」。
+
+本轮把它做成可执行审计（`test/test_leak.js`）：跑完整局（可查牌 / 不查牌 × 叫 65 / 70 / 5 共 6 局），对每一个「服务器 → 某座位」的下发面（含 6 个 RPC 的逐座位包 + 各阶段重连快照 + 明牌应答）做深度扫描，取出其中出现的**所有牌 id**，逐个判定该座位此刻是否有权知道这张牌。
+
+**结果：1814 个下发面 / 18706 次「座位×牌」可见性判定，0 泄露。**
+
+变异检验（注入真实泄露确认审计有效）：
+
+| 注入的泄露 | 结果 |
+| --- | --- |
+| 非 70 分也把 8 张暗牌发给闲家（这正是第三轮修过的历史缺陷） | ✅ 抓住 |
+| 重连时把庄家埋的底牌发给闲家 | ✅ 抓住 |
+| 出牌包把出牌者剩余手牌发给所有人 | ✅ 抓住 |
+
+---
+
+## 第八轮核对（按 流程 / 牌型 / 玩法 / 算分 四个维度复核）
+
+> 规则方复述了一条叫分规则：「开局庄家先叫分，不允许不叫分；第一局在没有庄家的情况下，默认座位号 0 玩家开始叫分」。据此按四个维度重新取证，**未发现不一致**。
+
+**新增取证（此前从未做过）：阶段机迁移矩阵。** 前几轮每个 handler 只测了 1~2 条代表性失败路径，从没系统验证过「某个请求在**别的**阶段会不会被误放行、会不会静默丢弃」。本轮把 8 个 RPC × 5 个阶段做成 **40 格矩阵**逐格驱动：
+
+| | step1 叫分 | step2 选主/投降 | step3 埋牌 | step5 出牌 | step6 结算 |
+| --- | --- | --- | --- | --- | --- |
+| jiaofen | ✓ 受理 | × STEP | × STEP | × STEP | × STEP |
+| xuanzhu | × STEP | ✓ 受理 | × STEP | × STEP | × STEP |
+| touxiang | × STEP | ✓ 受理 | × STEP | × STEP | × STEP |
+| maipai | × STEP | × STEP | ✓ 受理 | × STEP | × STEP |
+| chupai | × STEP | × STEP | × STEP | ✓ 受理 | × STEP |
+| mingpai | × STEP | × STEP | × STEP | ✓ 受理 | × STEP |
+| tishi | × STEP | × STEP | × STEP | ✓ 受理 | × STEP |
+| zhunbei | × STEP | × STEP | × STEP | × STEP | ✓ 受理 |
+
+**40 格全部符合**，无误放行、无静默丢弃。（`mingpai` 在 step5 还需「已有人报无主」这一前置，首轮矩阵曾把它标红——是期望表漏了前置条件，不是缺陷。）
+
+**叫分起始者规则逐条取证**（`design §4.2 + §4.6`，与规则方复述一致）：
+
+| 规则 | 取证 | 结果 |
+| --- | --- | --- |
+| 第一局默认座位 0 开始叫分 | `makewar → do_new_paiju(0)` → `firstseat=0`、待叫者=0 | ✅ |
+| 之后每局由**暂定庄家**先叫 | 连打 6 局，每局 `firstseat` 与「上局 banker + result」逐局比对 | ✅ |
+| 庄赢 → **连庄**（起始仍是该庄家） | 随机对局几乎打不出庄赢，用「叫 70 分 + 首家出最大牌」专门构造出 `result=0` 局 | ✅ |
+| 庄输 / 投降 → 起始顺延到下家 | 6 局中逐局验证 | ✅ |
+| **首家不允许"不叫"** | 第一局与其后每一局（含连庄局）的首家发 `call=0`，一律回 `RULE` 且叫分过程不变 | ✅ |
+
+四个维度的现有取证汇总：
+
+| 维度 | 取证手段 | 规模 |
+| --- | --- | --- |
+| **流程** | 阶段机 40 格矩阵、叫分序列 DFS 80 条终局、多局大局（6 局/12 局）、轮庄含连庄、中途解散、端到端整局 | 本轮新增矩阵 |
+| **牌型** | §3 等级序列逐级、§5.3 相邻链（副牌同花色 / 主牌不限花色 / 同档位不相邻）、§5.2 跟牌穷举差分 11 万组 | `test_arith`/`test_followdiff` |
+| **玩法** | §5.4 甩牌最大性 6000 例差分、甩错惩罚、§5.4.4 分量拆解、整局带牌型模糊每墩胜者差分、§9 查牌门控、下发面泄露审计 1.8 万次判定 | `test_fuzz`/`test_leak` |
+| **算分** | §7 算子全量对拍 7308 格 + design 表 141 格、§6.3 扣底、§8.1 算奖、§8.4 分配公式、结算零和 | `test_calc`/`test_paiju` |
+
+**固化产物**：新增 `test/test_flow.js`（7 项聚合断言，0.3s）。变异检验：去掉 `chupai`/`maipai` 的阶段校验、把 `jiaofen` 的阶段校验改成静默丢弃——三条全部转红。全套单测 **540 → 547 项**全绿。
+
+---
+
+## 结论摘要
+
+> **注**：下表是**首轮核对**的初始发现快照（保留以记录起点）。其中 §4.4、§5.4、§6.3、§7、§8.1-8.4、§9、§10、§11 等标 🟥/🟧/🟨 的项**后续均已修复并验证**——当前逐节状态以本文档后面的分节详情及全套单测（270 项全绿）为准。
+
+| 设计章节 | 主题 | 结论（首轮快照，非当前状态） |
+| --- | --- | --- |
+| §2 | 牌局构成（92 张、去 3/4） | ✅ 符合 |
+| §3 | 主牌顺序（牌编码） | ✅ 符合（副 7/副 2 跨花色成对存疑，见下） |
+| §4.1-3 | 发牌 / 叫分 / 埋牌流程 | 🟧 缺叫分上限、投降资格过宽 |
+| §4.4 | 70 分投降 / 打牌分支 | 🟥 投降资格 65 分即可、暗牌亮 3 秒未实现、投降结算数值错 |
+| §4.6 | 坐庄轮换 | ✅ 符合 |
+| §5.1-5.3 | 跟牌 / 毙牌 / 垫牌 / 拖拉机 | ✅ 基本符合（1 处运行期崩溃缺陷） |
+| §5.4 | 甩牌 | 🟥 合法性判定模型、副牌禁甩、强制跟牌拆解、甩错惩罚均不符 |
+| §6.1-6.2 | 分牌 / 捡分 | ✅ 符合 |
+| §6.3 | 扣底倍数 | 🟥 倍数表完全不同 |
+| §7 | 算子（基础子数 / 大光小光过庄 / 升级 / 爬坡） | 🟥 系统性不符，且无爬坡开关 |
+| §8.1 | 常规算奖（只庄家 + 连对链） | 🟥 三家都算、含额外作废规则、连对链因传参失效、≥10 老主误给奖、庄家快照含底/埋牌牌 |
+| §8.2 | 亮牌 | 🟧 未实现 |
+| §8.3 | 傍王 | 🟥 无开关（恒开）、含设计外作废、且未乘 X |
+| §8.4 | 算奖并入结算 | 🟥 扁平奖数（每奖 1 子），未按 `X × N` |
+| §9 | 查牌 / 不查牌模式 | 🟧 无模式开关、明牌功能无服务端支持 |
+| §10.1 | 扣卡 / 局数 | 🟥 局数 2/4（应 6/12）、房主扣卡数不符 |
+| §10.2-10.3 | 查牌 / 傍王 / 爬坡选项 | 🟥 均无开关 |
+| §11 | 交互提示 | 🟨 亮底牌 ✅；甩牌见 §5.4；闲家 3 提示无服务端支持 |
+
+---
+
+## §2 牌局构成 — ✅ 符合
+
+`class.paiju.js` `init_cards`：两副牌，点数 3、4 置 `dealowner=-1` 且不发（`if (k != 3 && k != 4) do_dealpai`）；`tmpdeal` 共 `28×3 + 8 = 92` 个槽位。发出 92 张（11 种点数 ×4 ×2 + 4 王），去掉 16 张 3/4，与设计一致。分值 `5→5、10→10、K(13)→10` 亦一致（§6.1）。
+
+---
+
+## §3 主牌顺序 — ✅ 符合（1 处存疑）
+
+`arith.id_to_code` 以 `flower*100+number` 为底，`A(+13)`、`2(+2000)`、`7(+7000)`、主花色 `(+1000)`、王固定 `9553/9554`，得到 code 降序即设计主牌顺序：
+
+大王 9554 > 小王 9553 > 正 7（8xxx）> 副 7（7xxx）> 正 2（3xxx）> 副 2（2xxx）> 主花色普通牌 A…5（1xxx）> 副牌 A…5（<1000）。
+
+`is_continuous` 正确实现全部相邻段（含 `小王↔正7`、`副2↔主A`、`8↔6`，以及「7 不与 6/8 连」——7 恒为主、不在普通链内）。
+
+**存疑（待规则确认）**：不同花色的副 7（code 7107/7207/7307）、副 2（2107/2207/2307）编码互不相等。因此：
+
+- 排序上三家副 7 被强行分出大小；比大小时 `can_followcard` 又把落在 7xxx/2xxx 段的牌**归一为 7000/2000**（视作同级），二者存在不对称，但因跟牌只能跟同花色、毙牌只能用更大主牌，实测不产生错误赢家。
+- 成对判定 `get_pairlist` 要求 `code 相等`，故「副 7 对 / 副 2 对」只认**同花色两张**，跨花色的两张副 7 不算一对。设计 §3 把副 7 列为同一等级，但未明确「两张不同花色副 7 是否成对」——**需与规则设计者确认**。若规则要求跨花色副牌可成对，则此处需改。
+
+---
+
+## §4 开局与坐庄
+
+### §4.1 发牌（每人 28 + 8 暗牌）— ✅ 符合
+
+### §4.2 叫分 — 🟧 缺上限校验
+
+- ✅ 步进 5：`mod.jiaofen` 校验 `call % 5 != 0` 拒绝。
+- ✅ 暂定庄家必须叫：首家 `currcall==0 && call==0` 被拒。
+- ✅ 后叫更低：`curr_call != 0 && call >= curr_call` 被拒。
+- ✅ 叫 5 立即上庄、两家不叫则上庄：`paiju.do_callgrade` 实现。
+- 🟧 **缺 `call <= 70` 上限**：`mod.jiaofen` 未限制上界，首家可叫 75、100 等（设计 §4 范围 5~70）。
+
+### §4.3 埋牌 — ✅ 符合（选主/埋牌顺序已确认解决）
+
+庄家得暗牌（`get_seat_cards` 对庄家含 `dealowner==0`），`mod.maipai` 校验埋 8 张且都在庄家手上，`do_burycard` 置 `playround=0` 后由庄家开首轮。
+
+✅ **顺序问题已解决**：复查时曾发现 design §4 列举顺序是「埋牌→选主」、而代码是「选主(step2)→埋牌(step3)」，二者相反。经与规则设计者确认，正确顺序为**先选主、后埋牌**（庄家知道主副后才好决定埋哪 8 张）——即**代码本就正确**，是 design §4 的列举笔误。已修正 design §4 的步骤顺序，并新增 design §12「完整牌局游玩流程」明确整局先后。代码无需改动。
+
+### §4.4 70 分投降 / 打牌 — 🟥 多处不符
+
+- 🟥 **投降资格过宽**：设计仅 **70 分**可投降；代码 `mod.touxiang` 判 `o_paiju.call < 65` 才拒绝，即 **65 分也能投降**。应改为「仅 `call == 70` 允许」。同样地 `shangzhuang.touxiang`、`get_deskinfo` 各阶段的 `touxiang` 字段都用 `call < 65` 判定，需一并改。
+- 🟥 **投降结算数值错**：设计投降为「基础子数 1、庄家每闲家输 1 子」。代码 `get_paiju_account(type=1)`：`upgrade=-99→-2`、`multiple=get_multiple_bycall(70)=1`，庄家 `grade_jf = -2 × 1 × 2 = -4`（每闲家 2 子）。金额翻倍且模型不对。
+- 🟨 **暗牌亮 3 秒未实现**：设计要求 70 分坐庄把 8 张暗牌向两闲家亮 3 秒（投降 / 打牌都要），代码无此下发。
+
+### §4.6 坐庄轮换 — ✅ 符合
+
+`class.export.js` `makewar` → `do_new_paiju(0)`：首局暂定庄家为 0 号座位（设计 §4.6）。`class.desk.js` `do_prepare`：`result==1(闲赢)||result==2(投降)` 时下一局 `firstseat=(banker+1)%3`（下家），否则连庄。两点均与设计一致。
+
+---
+
+## §5 出牌规则
+
+### §5.1 / §5.2 跟牌 / 毙牌 / 垫牌 — ✅ 基本符合（含 1 处崩溃缺陷）
+
+- 每轮由上轮最大者先出、每局首轮庄家先出：`new_playround(maxseat)` / `do_burycard→new_playround(1, banker)`。✅
+- 跟同花色、缺门可毙（主牌压过）或垫（任意副牌不争）：`arith.get_followcard`/`can_followcard` 按「同花色是否够 / 有无对子 / 有无拖拉机」给必出牌与可出牌，毙牌能否赢由 `cardvalue`（副 7/副 2 归一、跨花色垫牌记 0、主牌对/拖拉机才 >0）裁定。✅ 与 §5.2「毙牌必须用对应牌型」一致。
+- 🐞 **`can_followcard` 引用未定义变量 `tuolaji_list` 会抛异常**（`class.arith.js` 约 801 行，`get.cantype` 为拖拉机型 3xx 分支内 `if (tuolaji_list.length == 0)`，该变量在此作用域未赋值）。当跟牌方手中存在**多个**符合长度的候选拖拉机（`get_followcard` 返回 `cantype=startcardtype`）时命中此分支，`DoPack` 抛错、该次出牌链中断。需修复。
+
+### §5.3 拖拉机定义 — ✅ 符合（见 §3 的 `is_continuous`）
+
+### §5.4 甩牌 — 🟥 原合法性 / 禁令 / 跟牌 / 惩罚多处不符（🟩 第 1/2/4 点已整改，见「整改进度」）
+
+> **整改状态**：下述第 1（副牌禁甩）、第 2（最大性按全手牌判定）、第 3（强制跟牌分量优先级，`flush_follow_ok`）、第 4（甩错惩罚）**均已实现并验证**。以下保留原始不一致描述留痕。
+
+1. 🟥 **副牌禁甩未落实**：设计 §5.4.1「所有副牌完全禁止甩牌，无论外面是否剩余该花色副牌」。代码 `can_playcard` 对副牌甩牌只要求「其他两家没有主牌 **且** 没有该副花色（`other_noflower`）」即**放行**（约 415-419、427-438 行），等于「对手缺门时允许甩副牌」，与绝对禁令冲突。
+2. 🟥 **甩牌合法性判定模型不符**：设计 §5.4.2 要求服务端**按全部手牌**判断「对手是否持有能压过甩牌任一分量的更大主牌 / 主对 / 更长主拖拉机」。代码改用出牌过程累积的 `seatlist[i][flower-1][0/1]`、`[4]` 等**报副标志**（`other_noflower`/`other_noflowerpair`），语义是「对手是否已被记录为该花色 / 主牌 / 对子出空」，既非「按全部手牌」也非「更大」而是「有没有」，与设计判定完全不同。
+3. 🟥 **强制跟牌拆解未按分量**：设计 §5.4.4 要求闲家把甩牌拆成各分量（拖拉机优先跟拖拉机、对子优先跟对子…）逐个匹配。代码把甩牌压成单一 `cardtype`（如 `102 两张单张甩`、`203 三对甩`），`get_followcard` 对甩牌型只要求「同花色、张数相等」，不校验对子 / 拖拉机结构（如多对甩分支 `cantype=100+startcount` 只按单张计数）。
+4. 🟥 **甩错惩罚未实现**：设计 §5.4.5 规定甩错要「收回甩牌、本轮只强制打出最小一张、失去甩牌资格」。代码把非法甩牌当作无效输入（`can_playcard` 返回 `result=false`→`mod.chupai` 直接 `return`），无任何惩罚流程。
+5. ✅ **报无主**：`do_playcard` 出牌后自动检测主牌出空并置 `seatlist[..][4][0]=0`，属自动判定（设计允许由服务端精确计算）。
+
+---
+
+## §6 捡分与扣底
+
+### §6.1 分牌 / §6.2 捡分 — ✅ 符合
+
+`do_playcard` 仅在 `maxseat != banker` 时累计本轮分；`get_jian_grade` 汇总 `playowner != banker` 的分牌。庄家赢的轮分牌作废、不计入。与设计一致。
+
+### §6.3 扣底 — 🟥 倍数表完全不同
+
+- ✅ 触发条件「闲家用主牌赢下最后一轮」：`get_bottom_account` 仅在 `maxseat != banker` 时调 `get_bottom_multiple`，后者首末张非主（code<1000）即返回 0（不扣底），与「非主牌赢末轮不算扣底」一致。
+- 🟥 **倍数不符**：
+
+  | 闲家扣底牌型 | 设计倍数 | 代码 `get_bottom_multiple` |
+  | --- | --- | --- |
+  | 单张主 | 1 | 2 |
+  | 主对子 | 2 | 4 |
+  | 两连对 | 4 | 8 |
+  | 三连对 | 6 | 16 |
+  | 四连对 | 8 | 32 |
+  | 五连对 | 10 | 64 |
+  | 六连对 | 12 | `undefined`（🐞 落空返回未定义） |
+
+  代码为近似 `2^k`、且单张即翻倍；设计为线性 `2N`（单张不翻倍）。
+
+---
+
+## §7 结算：子数与升级 — 🟥 系统性不符
+
+设计的四层模型（§7.0）：`基础子数(由叫分定) × 判定倍率(大光×3/小光×2/过庄×1/升N级×N) = X`（每「庄–闲」对子的基础金额）。常规算子分界 `Q` 固定 40、升级级距固定 40；勾选爬坡才改用 §7.3 的梯度子数与分段 `Q`。
+
+代码实际实现（`get_paiju_account` + `get_multiple_bycall` + `get_upgrade`）：
+
+- `multiple = get_multiple_bycall(call)`：`call>60→1`、`>40→2`、`>0→4`、`≤0→0`。
+- `upgrade = get_upgrade(call, grade)`：大光→4、小光→2、过庄→1、升级→`-(floor((grade-call)/halfcall)+1)`；分界与级距用 `halfcall = ceil(call/2)`。
+- 每对子金额 = `multiple × upgrade`，庄家收两家（×2）、闲家各付（×-1）。
+
+**问题**：
+
+1. 🟥 **基础子数不符**：代码 `multiple∈{1,2,4}` 与设计常规算子 `{65:2, 60:3, 55:4, 50↓:6}` 数值、档位都不同。
+2. 🟥 **大光倍率错**：代码大光 `=4`，设计大光 `×3`。（小光 ×2、过庄 ×1 与设计一致。）
+3. 🟥 **小光 / 过庄分界与升级级距错**：代码用 `halfcall=ceil(call/2)`；设计常规算子固定 40。例如叫 65：代码分界 35（35~64 记过庄），设计分界 40（40~64 才过庄，35~39 仍是小光）。
+4. 🟥 **无爬坡开关**：设计 §7.3 是「勾选爬坡才生效」的可选梯度；代码无任何房间选项分支，只有一套公式。巧合的是 `halfcall` 对低档（40/35→20、30/25→15、20/15→10、10/5→5）恰等于爬坡的 `Q`，但对高档（65→35≠40、60→30≠40、50→25≠40）不等，且基础子数 `{1,2,4}` 与常规 `{2,3,4,6}`、爬坡 `{2,3,4,6,7,8,…}` 都不符——即代码既不是常规算子、也不是爬坡，而是第三套数值。
+
+**常规算子每对子最终子数对照（代码 vs 设计）**：
+
+| 叫分 | 判定 | 设计 | 代码 |
+| --- | --- | --- | --- |
+| 65 | 大光 / 小光 / 过庄 / 升1 / 升2 | 6 / 4 / 2 / 2 / 4 | 4 / 2 / 1 / 1 / 2 |
+| 60 | 同上 | 9 / 6 / 3 / 3 / 6 | 8 / 4 / 2 / 2 / 4 |
+| 55 | 同上 | 12 / 8 / 4 / 4 / 8 | 8 / 4 / 2 / 2 / 4 |
+| 50 | 同上 | 18 / 12 / 6 / 6 / 12 | 8 / 4 / 2 / 2 / 4 |
+| 40 | 大光 / 小光 /（无过庄）/ 升1 / 升2 | 18 / 12 / — / 6 / 12 | 16 / 8 /（误记过庄 4）/ 4 / 8 |
+
+（叫 40 一行还暴露分界问题：设计 `call≤40` 无过庄档，代码却在 grade 20~39 记出「过庄」。代码升级子数 = `multiple(=4) × 级数`，故升 1 级 4 子、升 2 级 8 子。）
+
+> **70 分打牌**同样落在本套公式里且同样不符：代码 `multiple = get_multiple_bycall(70) = 1`（设计打牌基础子数应为 2），`halfcall = 35`（设计 `Q = 40`）；大光 4×1=4、小光 2、过庄 1，而设计应为大光 6、小光 4、过庄 2。
+
+---
+
+## §8 算奖规则 — 🟥 归属、开关、数值均不符
+
+### §8.1 常规算奖（只庄家） — 🟥
+
+- ✅ 基础组合计数正确：`get_chongguan` 中 `3 王→1、4 王→3`、`6/7/8 个 7→1/2/3`、`6/7/8 个 2→1/2/3`。
+- 🟥 **只应计庄家，代码却算三家**：`get_paiju_account` 对 0/1/2 号位都调 `get_chongguan` 并两两结算（`grade_cg = cg×2 − 另两家`）。设计 §8.1「常规算奖只认庄家身份，不看闲家手牌」。
+- 🟥 **设计外的作废规则**：`do_obsolete_with_call` 引入「冲关必叫」「四王必踢（`call>60`）」，设计中不存在。
+- 🟥 **连对链算奖失效（传参 bug）**：设计 §8.1「三 / 四王在有正 7 及以后连续对子时每对 +1 奖」。但 `get_chongguan` 在正常 / 投降结算被以 `mainflower = -1` 调用（`get_paiju_account` 中 `if (type != 2) _flower = -1;`）。此时 `id_to_code` 不加 `+1000`，正 7 与副 7 都落到 7xxx、主花色普通对子不被识别为主，`is_continuous(小王, 正7)` 因 `is_zheng7` 只认 8xxx 而返回假——连对链一对也加不上。即该奖项**实质未生效**。
+- 🟥 **≥10 老主误给奖**：`if (_total >= 10) re.count += _total - 9`（「10 个老主判断」）。设计 §8.2 明示固定主牌 ≥10 只亮牌、**不算奖**。
+- 🟥 **庄家算奖手牌快照错（含底牌与已埋牌）**：设计 §8「算奖依据静态初始手牌——庄家是**埋牌完成后的那 28 张**，闲家是发牌后的 28 张」。代码 `get_paiju_account` 用 `get_seat_cards_owner(seat)` 取牌喂给 `get_chongguan`，而该函数按 `dealowner ∈ {seat+1, 0}` 取牌、**不排除 `playround==0`（已埋）**：庄家因此拿到「28 张发牌 + 8 张底牌 = 36 张」，把**已埋进底牌的 8 张也计入算奖**，闲家则是正确的 28 张。庄家的常规算奖与傍王都因此可能虚高（例如把埋掉的王/7/2 仍算进去）。应改为庄家取「埋牌后保留的 28 张」（排除 `playround==0`）。
+
+### §8.2 亮牌 — 🟧 未实现
+
+设计 §8.2 的四档亮牌门槛（固定主 ≥10 / 王 ≥3 / 7 ≥6 / 2 ≥6，向闲家亮统计信息，受「不查牌」模式抑制）在服务端无对应计算与下发。
+
+### §8.3 傍王（可选） — 🟥
+
+- 🟥 **无开关（恒开）**：`grade_w`（傍王得分）在 `get_paiju_account` 中无条件计算。设计 §8.3 / §10.3 傍王需勾选才生效。
+- 🟥 **含设计外作废**：`grade_w` 复用 `obsolete` 置 0 逻辑；设计傍王「每张王算一奖、庄闲都算」，无作废概念。
+
+### §8.4 算奖并入结算 — 🟥 未乘 X
+
+- 设计 §8.4：某玩家 `N` 奖，则另外两人各额外付 `X × N`（`X` 为 §7 第三层的每对子子数）。
+- 代码：`grade_cg`、`grade_w` 是**扁平奖数两两差**（`cg×2 − 另两家`），每奖等价 1 子，**未乘 `X`**。举例设计（X=6、庄家 1 奖）应从每闲家收 6 子；代码只收 1 子/家。
+- ✅ 结构上「所有两两之间（含闲–闲）都结算」这一点与设计一致，仅倍率错。
+
+---
+
+## §9 牌局查看模式 — 🟧
+
+- 报无主后，服务端确有记录他家剩余主牌数 / 对子数（`seatlist[..][4]` 与花色标志），并通过 `chupai*`/`PushCards` 的 `info`、`seatlist`、`baozhu` 下发，供客户端展示——方向正确。
+- 🟧 **无「可查牌 / 不查牌」模式开关**：`baozhu` 恒发、`seatlist` 恒带，未按房间设置抑制（设计 §9 / §10.2 的不查牌模式应屏蔽这些信息）。
+- 🟧 **「明牌」（查看他家具体主牌）无服务端支持**：服务端不会向闲家下发他家的具体主牌牌面。
+
+---
+
+## §10 房间设置选项 — 🟥
+
+### §10.1 扣卡方式 / 局数 — ✅ 已整改（下述为原始不一致留痕）
+
+> **现状（已改）**：`get_asetcount` 按位串返回 6/12；`get_needroomcard` 房主 6局2张/12局4张、AA 6局1张/12局2张，均符合 §10.1。以下为原始（数组下标版）不一致记录。
+
+- 🟥（原始）**局数不符**：旧 `export.get_asetcount` 返回 `roomtype[0]==1→2`、`==2→4`。设计 §10.1 为 **6 局 / 12 局**。
+- 🟥（原始）**房主扣卡数不符**：旧 `get_needroomcard` 房主档返回 1/2；设计房主扣卡为 6 局 2 张 / 12 局 4 张。
+
+### §10.2 查牌模式 — 🟥 无开关（见 §9）
+
+### §10.3 附加规则（傍王 / 爬坡，可同时勾选）— 🟥 均无开关（见 §7.4、§8.3）
+
+---
+
+## §11 牌局交互提示 — 🟩
+
+- ✅ 牌局结束亮底牌：`get_bottom_account` 结算恒带 `bottom.cards`。
+- ✅ 选主对子数 / 70 分投降按钮门控：随 `shangzhuang`/`xuanzhu` 阶段包下发（见 §4）。
+- ✅ 甩牌相关提示：见 §5.4（甩牌实现已核对一致）。
+- ✅ **闲家 3 提示（踩 / 没分 / 有分）**：`mod.tishi`（design §11）——闲家在出牌阶段(step5)发 踩/没分/有分，服务端不校验真实性、只 `SendPack` 转发给对家（另一闲家 `3-banker-seat`）；庄家不参与。协议见 packet_protocol §13.7/13.8，测试见 `test_rpc`。
+
+---
+
+## 附录：运行期代码缺陷汇总（与规则合规相对独立，但都需修）
+
+| # | 位置 | 现象 | 影响 |
+| --- | --- | --- | --- |
+| D1 | `class.arith.js` `can_followcard`（约 801 行） | 引用未赋值的 `tuolaji_list.length` | 跟牌方有多个候选拖拉机时抛异常、出牌中断 🐞 |
+| D2 | `class.arith.js` `get_bottom_multiple`（六连对分支） | 六连对时无返回值 | 返回 `undefined`，扣底倍数计算异常 🐞 |
+| D3 | `class.arith.js` `can_playcard`（约 276 行） | `do_returnfalse;` 漏写 `()`，语句空转 | 「一次最多 14 张」上限失效，超量出牌被当作合法 🐞 |
+| D4 | `class.paiju.js` `do_choiceflower`（约 417-421 行） | `for` 循环体为空、取出 `o_card` 后无操作 | 死代码（主牌重编码实际在 `id_to_code` 动态完成），无害但应清理 🟨 |
+
+> D1~D3 均为真实缺陷；虽多数属「代码写错」而非「规则理解错」，但会导致对应规则（跟拖拉机校验、扣底、出牌张数上限）无法正确执行，需按缺陷修复处理。
+
+---
+
+## 总体判断
+
+- **流程骨架**（发牌、叫分推进、选主埋牌、逐轮出牌收束、断线重连快照、战绩存储）实现完整且大体正确。
+- **牌型与大小体系**（编码、排序、相邻、跟牌 / 毙牌 / 垫牌的必出可出计算）设计良好、基本符合规则，主要缺陷是 D1 崩溃与甩牌子系统。
+- **不符合集中在「算分 / 算奖 / 房间选项」三块**：§6.3 扣底倍数、§7 算子全套、§8 算奖归属与并入方式、§10 局数 / 扣卡 / 各类开关——这几处需按 `design.md` 重做，是后续整改的重点。
+- 结合数值特征（`multiple` 只有 1/2/4、局数 2/4、扣底 2^k、含「冲关必叫 / 四王必踢」等设计外机制），**服务端很可能是在早期或另一套规则版本上实现的，与当前 `design.md` 已系统性脱节**，而非个别笔误。

server/games/erqiwang/docs/compliance/02-测试计划.md

@@ -0,0 +1,236 @@
+# 二七王服务端 · 合规测试计划
+
+> 目标：用 Node 单测/集成测**系统覆盖 `design.md` 的全部服务端可验证规则**，做到"规则 → 用例"可追溯，作为"代码是否符合手册"的**自动化证据**（与 `01-design合规逐节核对.md` 的人工审计互补）。
+>
+> 运行：`node server/games/erqiwang/test/run.js`。测试原理与双运行时见 `test/README.md`。测试纪律（正/反/边界、不软化断言、失败先裁根因）见 `docs/server/development-guide/04` §10。
+
+---
+
+## 0. 分层与测试类型
+
+| 层 | 含义 | 依赖 | 现状 |
+| --- | --- | --- | --- |
+| **L1 单元** | 纯函数直接调用（arith/config/paiju 静态计算） | 仅 `_shim` 的平台工具 | 已有 `test_arith`/`test_config`/`test_paiju`（部分） |
+| **L2 局内集成** | `cls_youle_erqiwang_paiju.new(o_desk,firstseat)` 造牌局，驱动 `do_callgrade→do_choiceflower→do_burycard→do_playcard…→get_paiju_account` 验证状态/结算 | mock `o_desk`/`o_room` + shim；**不经 mod.js** | 仅 `get_paiju_account` 造了极简对象，**无完整一局驱动** |
+| **L3 RPC/广播** | `mod.js` 收包入口 → 校验 → 广播 | mock `check_player`/`SendPack`/`sendpack_toother`，捕获下发包 | **完全未覆盖** |
+
+**发牌随机性处理**：`do_dealpai` 用 `min_random`。L2 需要**可控发牌**——测试 `_shim` 提供可注入的 `min_random`（预置序列或指定发牌结果），使一局可复现。这是 L2 的前置基建。
+
+---
+
+## 1. 覆盖矩阵（按 design 章节）
+
+状态：✅ 已覆盖 · 🟡 部分 · ❌ 待补。用例列标注 正/反/边界 三类（`docs/server/development-guide/04` §10 要求三类齐全）。
+
+### §2 牌局构成
+| 规则 | 被测 | 用例（正/反/边界） | 层 | 状态 |
+| --- | --- | --- | --- | --- |
+| 92 张、去两副 3/4 | `init_cards`/`do_dealpai` | 正：发完 3 家各 28 + 底 8 = 92；反：牌堆不含 number 3/4；边界：两副各花色计数 | L2 | ❌ |
+| 分值 5→5、10→10、K→10、余 0 | `init_cards` | 正：各面值 score；边界：非分牌 score=0 | L1/L2 | 🟡（扣底/结算间接） |
+
+### §3 主牌顺序 / 编码
+| 规则 | 被测 | 用例 | 层 | 状态 |
+| --- | --- | --- | --- | --- |
+| 主牌 code 降序=设计顺序（大王>小王>正7>副7>正2>副2>主A…主5>副牌） | `id_to_code`/`order_cards` | 正：排序结果逐位；边界：正/副 7、正/副 2 的相对大小；主A vs 副2 | L1 | ❌（间接用到，无专测） |
+| 相邻链 + 6/8 可连、7 不与 6/8 连 | `is_continuous` | 正：全相邻段逐对；反：7-6/8-7/9-7 不连；边界：8-6 连、大王-小王连 | L1 | 🟡（甩牌/算奖间接） |
+| 副7/副2 跨花色比大小归一 | `trump_rank`/`can_followcard` | 正：副7 vs 副7 不可压；反：正7 压副7 | L1 | 🟡（甩牌间接） |
+
+### §4 开局与坐庄
+| 规则 | 被测 | 用例 | 层 | 状态 |
+| --- | --- | --- | --- | --- |
+| 叫分 5~70、步进5、暂定庄必叫、后叫更低/不叫 | `mod.jiaofen` 校验 + `do_callgrade` | 正：合法叫分推进；反：>70/非5倍/首家0/叫≥当前；边界：叫70、叫5 | L3(校验)+L1(do_callgrade) | ❌ |
+| 叫5立即上庄、两家不叫上庄 | `do_callgrade` | 正：叫5→banker；正：一家叫另两家不叫→banker；边界：三家叫分序列 | L1 | ❌ |
+| 坐庄轮换：庄赢连庄、庄输/投降下家、首局庄=0号 | `desk.do_prepare`/`makewar` | 正：result=0 连庄；正：result=1/2 顺延；边界：首局 firstseat=0 | L2/L3 | ❌ |
+| 阶段机 1→2→3→5→6，无 step4 | `do_up_banker`/`do_choiceflower`/`do_burycard` | 正：各 handler 后 step 值；反：错误 step 调用被拒 | L2/L3 | ❌ |
+| 投降仅70分/step2/庄家/不埋牌 | `mod.touxiang` | 正：70分 step2 投降→结算；反：≠70/step≠2/非庄；边界：投降后 step=6 | L3 | ❌ |
+| 70分暗牌向所有玩家亮3秒(+ancard3s)、非70只发庄 | `mod.jiaofen`(shangzhuang) | 正：70→闲家有 bottomcards+ancard3s；反：非70 闲家无 bottomcards | L3 | ❌ |
+| 选主后先选主后埋牌 | `do_choiceflower`/`do_burycard` | 正：flower 记录、step 推进；边界：埋牌须8张且在手 | L2 | 🟡（check_cards_inhand 未测） |
+
+### §5 出牌规则
+| 规则 | 被测 | 用例 | 层 | 状态 |
+| --- | --- | --- | --- | --- |
+| **§5.1/5.2 跟牌/毙牌/垫牌/混合出牌/拖拉机覆盖度** | `get_followcard`/`can_followcard` | 正：同花色跟、有对必出对、有拖必出拖、两对不连必出、尽量长拖优先；反：缺牌型被拒、放长拖只出散对被拒；毙牌(须完全缺门)：副单→主单、副对→主对、副N连→主N连；垫牌/混合出牌：cardvalue=0 不争权 | L1 | ✅（`test_follow` 50 例，含 else 欠约束修复回归） |
+| §5.3 拖拉机相邻 | `is_continuous`/`get_tuolaji_list` | 见 §3 | L1 | 🟡 |
+| §5.4 甩牌：副禁甩/最大性/甩错 | `can_playcard`/`opp_can_beat_flush`/`decompose_trump` | 已覆盖（合法/甩错含smallest/副禁甩/单张/对子/拖拉机） | L1 | ✅ |
+| §5.4.4 跟甩牌强制分量拆解 | `flush_follow_ok` | 已覆盖（有对必打对/有拖必打拖/退化/主牌最大化/无主全垫） | L1 | ✅ |
+
+### §6 捡分与扣底
+| 规则 | 被测 | 用例 | 层 | 状态 |
+| --- | --- | --- | --- | --- |
+| §6.1 分值 | `init_cards` | 见 §2 | L1 | 🟡 |
+| §6.2 闲家赢归闲、庄赢作废、两闲谁赢都算闲 | `do_playcard`/`get_jian_grade` | 正：闲赢累计分；反：庄赢不计；边界：两闲各赢 | L2 | 🟡（1 集成例） |
+| §6.3 扣底倍数 单1/对2/N连2N、全主牌守卫、取最高规格 | `get_bottom_multiple` | 已覆盖 | L1 | ✅ |
+| §6.3 触发：闲家用主牌赢末轮才扣底 | `get_bottom_account` | 正：闲家主牌赢末轮翻倍；反：非主牌赢不扣、庄家赢不扣 | L2 | ❌ |
+
+### §7 结算：子数与升级
+| 规则 | 被测 | 用例 | 层 | 状态 |
+| --- | --- | --- | --- | --- |
+| 常规算子 基础子数 + 大光×3/小光×2/过庄×1/升N级、Q=40 | `get_base_bycall`/`get_qvalue`/`get_upgrade` | 已覆盖各档代表值 | L1 | ✅（可补每档过庄/小光分界与升3级） |
+| 爬坡 基础子数梯度 + 分段Q | 同上(climb=true) | 已覆盖各档 | L1 | ✅ |
+| X=基础×倍率、庄赢/闲赢符号、按房间爬坡切换 | `get_paiju_account` | 正：大光/过庄/升级/爬坡局 seatlist；边界：banker=-1 | L2 | 🟡（仅65小光+投降） |
+
+### §8 算奖
+| 规则 | 被测 | 用例 | 层 | 状态 |
+| --- | --- | --- | --- | --- |
+| §8.1 常规算奖只庄家、三/四王+连对链、6-8个7/2、无≥10老主/无作废 | `get_chongguan` | 已覆盖 | L1 | ✅ |
+| §8.2 亮牌阈值/统计、只亮结构 | `get_liangpai` | 已覆盖 4 例 | L1 | 🟡（补 王≥3/7≥6 组合、边界9/10） |
+| §8.3 傍王按位开关、庄闲每王1奖 | `get_paiju_account`(bangwang) | 正：傍王局 grade_aw 含王奖；反：未勾选不计 | L2 | ❌ |
+| §8.4 算奖并入 X×(2Ni−Nj−Nk)、含闲-闲、投降X=1 | `get_paiju_account` | 正：庄1奖/闲傍王2奖的三家净额；边界：三家同时有奖 | L2 | ❌（公式单测有，集成未测） |
+| §8 快照：庄埋后28/闲发后28；投降庄36无主 | `get_seat_cards_award` | 正：庄排除已埋；正：投降含底36；边界：无主花色无连对链 | L2 | 🟡（投降 count 间接） |
+
+### §9 查牌 / 明牌
+| 规则 | 被测 | 用例 | 层 | 状态 |
+| --- | --- | --- | --- | --- |
+| 报无主统计 info/baozhu 门控 | `mod.chupai` | 正：可查牌下发 info/baozhu；反：不查牌 info 缺失、baozhu=0 | L3 | ❌ |
+| 亮牌/PushCards.seatlist 门控 | `mod.maipai`/`get_deskinfo` | 正：可查牌闲家有 liangpai；反：不查牌无 | L3 | ❌ |
+| 明牌 mingpai：可查牌+已报无主+出牌阶段 | `mod.mingpai` | 正：条件满足返回他家主牌；反：不查牌/未报无主/非出牌阶段被拒 | L3 | ❌ |
+
+### §10 房间设置
+| 规则 | 被测 | 用例 | 层 | 状态 |
+| --- | --- | --- | --- | --- |
+| 位串解析、局数6/12、扣卡房主2·4/AA1·2 | `config.parse`/`export.get_asetcount`/`get_needroomcard` | 已覆盖（config 复刻映射） | L1 | ✅（可改为直接调 export 函数） |
+| 傍王/爬坡/查牌三开关生效 | `get_paiju_account`/`mod.*` | 傍王/爬坡见 §7/§8；查牌见 §9 | L2/L3 | 🟡 |
+
+### §12 完整流程
+| 规则 | 被测 | 用例 | 层 | 状态 |
+| --- | --- | --- | --- | --- |
+| 一局端到端：发牌→叫分坐庄→选主→埋牌→逐轮出牌→末轮扣底→结算→轮庄 | 全链路 | 正：一局可控发牌打到结算，各家总分正确；含连庄/下家轮转 | L2 | ❌ |
+
+> §11 牌局交互提示中，选主对子数/亮底牌等随对应阶段包下发；闲家三提示（踩/没分/有分）为服务端转发项（`mod.tishi`，见 P1）。
+
+---
+
+## 2. 待补用例清单（按优先级）
+
+### P0 · 规则/金额关键 —— ✅ 已完成
+1. ✅ **§5.1/5.2 正常跟牌/毙牌/垫牌/混合出牌/拖拉机覆盖度**（`can_followcard`，`test_follow.js` 50 例）——单张/对子/拖拉机的必出、毙牌数量对应（副单→主单/副对→主对/副N连→主N连、且毙牌须完全缺门）、垫牌与"混合出牌"(有该花色不够+补主牌→`cardvalue=0` 不争权)、缺门/同花色不足/对子不够各分支、多候选拖拉机(D1 崩溃回归)、**降级递归 else 欠约束回归**（三组等长 2 连对时出孤立对→拒），正反边界齐全。
+2. ✅ **§7/§8 结算集成扩充**（`get_paiju_account`，`test_paiju.js`）——大光/过庄/升2级、爬坡局、傍王局（庄3王，N=4）、不傍王对照、投降，逐档验证 seatlist 各家 grade。
+3. ✅ **§4.2 叫分坐庄**（`do_callgrade`，`test_callgrade.js` 6 例）——叫5立即上庄、两家不叫上庄、后叫更低→最低者上庄、不同首家。
+4. ✅ **§6.3 扣底触发**（`get_bottom_account`，`test_paiju.js`）——闲家主对/两连对赢末轮才扣底(×2/×4)；副牌赢、庄家赢均不扣。
+
+> 注：§4.2 中 `mod.jiaofen` 的**入参校验**（>70/非5倍/首家必叫/后叫更低）属 L3，随投降/暗牌/查牌门控一起在 P1 补。
+
+### P1 · 规则关键、需 RPC 脚手架 —— ✅ 已完成（`_rpc.js` + `test_rpc.js` / `test_desk.js`）
+5. ✅ **§9 查牌门控 + mingpai**——chupai 的 info/baozhu 按 `nocheck` 门控（可查有/不查无）；mingpai 合法下发他家主牌，不查牌/未报无主/非出牌阶段均拒。
+6. ✅ **§4 投降 + 暗牌亮牌**——touxiang 仅 70分/step2/庄家；真实 jiaofen 驱动到 70分上庄，验证 shangzhuang 闲家有 bottomcards+ancard3s、叫5上庄闲家无。
+7. ✅ **§4.2 `mod.jiaofen` 入参校验**——>70/非5倍/首家必叫/后叫更低 全部拒，合法接受。
+8. ✅ **§4.6 坐庄轮换 `do_prepare`**——庄赢连庄、闲赢/投降下家。
+
+### P2 · 补强既有 —— ✅ 已完成
+9. ✅ §2 牌局构成专测（`test_deal`）、§3 编码/排序专测（`test_arith`：order_cards + is_continuous 链）。
+10. ✅ §9 `mod.maipai` 亮牌门控 / `get_deskinfo` PushCards 门控（`test_rpc` 端到端驱动后验证）。
+11. ✅ §8.2 亮牌更多阈值（6个7/固定主9-10边界）、§7 算子每档分界+升3级（`test_arith`）。
+12. ✅ §12 端到端（`test_rpc` 真实驱动到出牌就绪）。
+13. ✅ §10 直接调 `export.get_asetcount`/`get_needroomcard`/`get_needroomcard_joinroom`（`test_config`）。
+14. ✅ **§11 闲家三提示 `mod.tishi`**——正：闲家 step5 发 踩/没分/有分，只转发给对家（`3-banker-seat`，验证 fromid/seat/tip）；反：庄家发/非出牌阶段/非法 tip/缺 tip 均拒（`test_rpc` 11 例）。
+
+---
+
+## 3. 集成脚手架需求（实现 L2/L3 的前置）
+
+- **L2 局内驱动器 `test/_harness.js`**：
+  - 可注入发牌的 `min_random`（或直接构造 `o_paiju.cards` 指定各家手牌），使牌局可复现。
+  - mock `o_desk`（seatlist 累积、`get_desk_account`、`o_room.roomtype/asetcount`）与 `o_room`。
+  - 提供"驱动一局到某阶段"的辅助：叫分序列 → 选主 → 埋牌 → 出牌序列。
+- **L3 RPC 捕获器**：mock `youle_erqiwang.import.check_player`（返回构造的 `o_room`）、`o_room.method.sendpack_toother`/`youle_erqiwang.app.SendPack`（把下发包收集进数组），断言包字段（含 §9 门控、暗牌、投降、chupai1/2/3、jiesuan）。
+
+---
+
+## 4. 完成定义（DoD）—— ✅ 已达成
+
+- ✅ 覆盖矩阵中所有 ❌/🟡 项补到 ✅（详见 §5 现状），每条规则至少含正/反/边界；
+- `node test/run.js` 全绿、退出码 0；
+- 新增用例遵守测试纪律：不改正式代码去迁就测试、不软化断言、失败先用证据裁根因；
+- 本计划与 `01-design合规逐节核对.md` 的结论一致（自动化测试成为人工审计的可回归证据）。
+
+---
+
+## 5. 当前状态小结 —— ✅ DoD 达成，P0/P1/P2 全部完成
+
+**共 511 项断言全绿**（`test_arith` 122 / `test_calc` 49 / `test_callgrade` 6 / `test_config` 19 / `test_deal` 12 / `test_desk` 6 / `test_endgame` 25 / `test_follow` 58 / `test_followdiff` 12 / `test_input` 34 / `test_paiju` 50 / `test_rpc` 89 / `test_success` 29）。其中 `test_calc`/`test_followdiff` 见 §7、G1~G9 见 §8。
+
+design 全部服务端可验证章节均有正/反/边界单测：
+- **§2 构成**：`test_deal` 92张/去3-4/三家28+底8/分值。
+- **§3 编码/排序**：`test_arith` order_cards 降序=设计顺序、is_continuous 相邻链逐段+反例。
+- **§4**：叫分坐庄 do_callgrade、`mod.jiaofen` 入参校验、投降 touxiang 条件、70分上庄暗牌亮牌下发、坐庄轮换 do_prepare。
+- **§5**：**正常跟牌全面覆盖(§5.1/5.2)**——按跟牌方手牌各分支穷举：主牌首出与副牌首出、单张/对子/拖拉机各牌型、有同花必出对应牌型、同花不足则出仅有的+补、缺门毙牌(数量对应)与垫牌(不压)、拖拉机的对子不够/同花无对/**多候选拖拉机(D1崩溃回归)**/3连对/富余对子必出拖、手牌数==首出张数全部必出；**甩牌全面覆盖(§5.4)**——合法(纯单/纯对/单+拖/单+对+拖三混)、甩错(单张/主对/拖拉机分量各自被压、双对之一被压)、副牌禁甩(对手缺门与非缺门)、甩错惩罚**实际执行**(do_playcard 只打最小一张、其余留手)；**跟甩牌全面覆盖(§5.4.4)**——对子必出、拖拉机必出/退化对子/退化到单张、多组拖拉机、混合demand逐分量对位、主牌最大化、无主全垫，以及"首出甩牌→跟牌违规→do_playcard 拒"的集成。
+- **§6**：捡分（结算集成间接）、扣底倍数+触发。
+- **§7**：算子常规+爬坡逐档、每档分界+升3级、结算集成（大光/过庄/升级/爬坡/傍王/投降）。
+- **§8**：算奖 get_chongguan、亮牌 get_liangpai（含 6个7/固定主9-10边界）、算奖并入 X×N（傍王对照）。
+- **§9**：查牌门控（chupai info/baozhu、maipai liangpai、deskinfo PushCards seatlist）、明牌 mingpai。
+- **§10**：位串解析、局数/扣卡（直接调 export 接口）。
+- **§12**：端到端（叫分→上庄→选主→埋牌→出牌ready，真实 RPC 驱动）。
+
+> 说明：§12 覆盖到"出牌准备就绪"（各阶段串接正确）；完整 28 墩逐墩对打需一个合法出牌选择器，属后续增强，非规则合规缺口（逐墩规则已由 §5/§6 单测覆盖）。
+
+---
+
+## 6. 第三轮补充：design 之外的可验证维度
+
+> 前两轮的覆盖矩阵完全按 design 章节组织，因此**平台接入、客户端入参、下发面一致性、协议红线**这几类根本不在矩阵里——270 项全绿却漏掉了 1 项阻断级与 3 项严重缺陷（见 `01-design合规逐节核对.md`「第三轮核对」）。本节把这些维度补进测试计划，后续复核必须一并跑。
+
+| 维度 | 被测 | 用例（正/反/边界） | 文件 | 状态 |
+| --- | --- | --- | --- | --- |
+| 客户端入参合法性 | `check_cards_valid` / `check_cards_inhand` | 正：单张/多张/边界 id 0 与 107；反：非数组(undefined/null/字符串/伪数组)、空数组、重复 id、越界、负数、小数、数字字符串；反：不在手上/已出/已埋 | `test_input` | ✅ 21 |
+| 重复 id 不得伪造牌型 | `mod.maipai` / `mod.chupai` | 反：8 个重复 id 埋牌被拒且一张未埋；反：重复 id 出牌被拒；正：8 张不同牌埋牌成功且实埋 8 张；反：越界/非数组入参不抛异常且不产生出牌 | `test_input` | ✅ 7 |
+| §9 报无主即时刷新 | `do_playcard` | 正：打空瞬间三家统计与主花色标志同时刷新；边界：报无主前三家均为 `[-1,-1]` | `test_input` | ✅ 6 |
+| 红线 `data.success`（成功包） | `class.desk`/`mod.js`/`get_paiju_account` | 正：fapai/zhunbei/jiaofen/shangzhuang/xuanzhu/maipai/chupai1/mingpai/tishi 均带 `success:true`；正：jiesuan 的正常/投降/解散三种 type 都带 | `test_success` | ✅ 12 |
+| 红线 `data.success`（失败回包） | 各 handler 失败分支 | 反：每个 handler 取代表性失败路径，断言"恰好回 1 包 + `success:false` + errcode 正确 + 回到请求者 fromid"，覆盖 STEP/SEAT/PARAM/RULE/PLAYER 五类 | `test_success` | ✅ 17 |
+| §7.3 下发面 multiple 与结算同源 | `mod.jiaofen` / `get_deskinfo` / `get_paiju_account` | 正：叫 45 分在常规房/爬坡房分别得 6/7；正：上庄包与重连 ChooseMain 一致；边界：与结算包 `aset.multiple` 逐一对齐 | `test_rpc` | ✅ 7 |
+| §5.4 甩牌下发面 | `chupai1` | 正：合法甩牌带 `shuai` 分量；反：非甩牌不带；反：甩错只打最小一张且不带 `shuai` | `test_rpc` | ✅ 8 |
+| 重连 pushlist 结构 | `get_deskinfo` | 正：轮数正确、内层恒 3 个座位、无 undefined；正：按本局主牌花色排序（主5 排在副A 前） | `test_rpc` | ✅ 4 |
+| §9 出牌历史按查牌模式门控 | `get_deskinfo` | 反：不查牌房无 `pushlist`；正：可查牌房有 `pushlist`；边界：两种模式下当前轮桌面牌 `playproc.cards` 都必须恢复 | `test_rpc` | ✅ 4 |
+| §3 相邻链花色 | `is_continuous` | 正：同花色 8-6 连；反：三组跨花色 8-6 不连；反：差 2 但非 8/6 不连 | `test_arith` | ✅ 5 |
+
+**关于超时**：`countdown` 只作展示、服务端不做任何超时动作，这是 design §11 确认的规则（并非缺口），因此**没有也不需要「超时自动操作」的用例**；反过来，若将来有人给服务端加了超时代打，那才是违反 design §11——现已由 `test_rpc` 的**守卫用例**拦下（见 §8 G9）。
+
+---
+
+## 7. 第五轮：按 design 原文另写参考实现的差分测试
+
+> 前六节的用例都是**手写的场景枚举**——覆盖的是"我想到的情况"。第五轮补两组**差分测试**：把 design 的规则整条转写成参考实现，与代码大面积对拍，覆盖手写用例想不到的组合。
+
+| 文件 | 覆盖 | 规模 |
+| --- | --- | --- |
+| `test_calc.js` | §7 算子全量对拍：参考实现逐字转写自 §7.1/§7.2/§7.3 判定表，比 base / Q / 判定倍率 / 最终子数 | 2 模式 × 14 档 × grade 0~260 = **7308 格**，另按 design 的 17 张表逐格抽查 **141 个写死的最终子数** |
+| `test_followdiff.js` | §5.2 跟牌强制层级穷举差分：参考裁定按原文写，对每手牌**枚举全部 C 张出牌组合**逐个对拍 | 约 **11 万组** |
+
+**差分测试的强度取决于造牌器，不取决于对拍逻辑。** 第一版 `test_followdiff` 用纯随机抽牌跑 7.8 万组全绿，但把 `follow_tractor_cover_ok` 整个关掉**依然全绿**——因为唯一能区分"只出零散对子"与"先凑最长拖拉机"的形状是「同花色三组互不相邻的两连对」（12 张），随机抽根本抽不出来。故：
+
+- 随机源必须是**固定种子 PRNG**（不用 `Math.random`），保证用例集可复现；
+- 关键结构必须用**确定性手牌**钉死（`structHands()`），不能指望随机覆盖到；
+- 注意别让掺入的其他花色把手牌撑过枚举上限而被**静默跳过**（踩过一次）。
+
+---
+
+## 8. 第五轮：逐规则的正/反/边界补全
+
+> 对 design §1~§12 重新做了一次"每条规则是否三类用例齐全"的审计。覆盖面本来就广，但仍有 9 处 design 明文规则缺用例（多是**规则本身**而非入参校验，前几轮的矩阵按"被测函数"组织，容易漏掉这类"跨函数才体现"的规则）。
+
+| # | design | 规则 | 补的用例（正/反/边界） | 文件 |
+| --- | --- | --- | --- | --- |
+| G1 | §4.2 | 暂定庄家必须叫、其后才可"更低或不叫" | 边界：下限 5 接受；正：非首家 `call=0` 接受；反：负数 / 缺 `call`(NaN) / 步进外小值 1 / 与当前叫分相同 均拒 | `test_rpc` |
+| G2 | §4.2 | **"不叫"即退出本局叫分，轮次跳过他** | 正：首家叫 65 后轮到 seat1；正：seat1 不叫后跳到 seat2；反：seat1 反悔再叫 → SEAT 拒、`callproc` 不变、仍轮到 seat2、未产生庄家 | `test_rpc` |
+| G3 | §4.5 | 埋牌仅庄家、仅埋牌阶段、恰 8 张 | 反：非庄家 → SEAT；反：step2/step5 埋 → STEP；边界：7 张 / 9 张 / 空数组 → PARAM | `test_rpc` |
+| G4 | §5.1 | **每轮由上一轮牌面最大的一方先出** | 正：闲 1 赢 → 下一轮 `start/currseat` 都是 1；边界：闲 2 赢 → 改由闲 2 先出 | `test_paiju` |
+| G5 | §6.2 | 闲家赢 → 台面**全部**分牌计入；庄家赢 → 分牌作废 | 反：庄赢 → 下发面无 `grade`、闲家捡分 0；正：闲 1 赢 → 15 分（**含庄家自己打出的 ♥5**）；边界：闲 2 赢结果与闲 1 赢一致（"两个闲家谁大不影响"） | `test_paiju` |
+| G6 | §8 | 算奖快照的时间点与静态性 | 正：庄家 = 埋牌后 28 张、已埋 8 张不在内；正：闲家 = 发牌后 28 张；边界：投降局庄家 = 发牌+暗牌 36 张；边界：之后打出 10 张，快照仍是同样的 28 张 | `test_paiju` |
+| G7 | §3 | **对子只认同花色同点数的两副** | 正：同花色两副 ♥7/♥2/大王成对；反：♥7+♣7、♥2+♣2、正7+副7、正2+副2、大王+小王 均不成对；边界：四张跨花色 7/2 组不出拖拉机，而正7对+副7对可以 | `test_arith` |
+| G8 | §6.3 | 赢末轮的牌不全是主牌就不扣底 | 反：副牌两连对赢 → 0；反：混合出牌（主K+副K）→ 0；边界：主副提交顺序颠倒仍判 0 | `test_arith` |
+| G9 | §11 | **无超时托管**（守卫） | 守卫：叫分→选主→埋牌→出牌全程 `min_ontimeout` 调用次数为 0。将来若有人加"超时自动出牌/代打"，必然要注册定时器，这条即转红 | `test_rpc` |
+
+**每条都做了变异检验**（在副本上注入违反该规则的改动，确认对应断言转红）：
+
+| 注入的缺陷 | 转红的断言 |
+| --- | --- |
+| 去掉 `mod.jiaofen` 的"非当前叫分位"校验 | G2 三条 |
+| 埋牌张数 `!= 8` 放宽为 `< 1` | G3 两条边界 |
+| §6.2 改成庄家赢也累计闲家捡分 | G5 一条 |
+| 下一轮改为固定庄家先出 | G4 两条 |
+| 算奖快照不排除已埋的牌 | G6 两条 + 亮牌快照一条 |
+| `get_pairlist` 放宽为"只看点数" | G7 五条 |
+| 在 `mod.chupai` 里注册一个定时器 | G9 一条 |
+
+> 过程中的一个教训：M2（埋牌张数）第一次跑出来是**整个文件崩溃**而不是干净的 FAIL——因为 `mkBury` 桩缺 `do_burycard`，校验一被改松就走到成功路径抛异常，后面的断言全不执行。**桩要完整到能走完成功路径**，否则"校验被改松"这类变异只会表现为崩溃，定位与信号都变差。已修。
+
+> 原列在此处的两项「待外部输入」均已由规则设计者拍板：「不查牌模式是否屏蔽出牌历史」确认屏蔽，已改 design §9 + 代码 + 用例（见上表）；「超时托管默认动作」确认维持现状、不做超时动作，已写入 design §11。至此测试计划无待外部输入项。