二七王：协议文档修正解散结算的真实投递方式，补 roomtype 位串表

以 packet_protocol.md 本身为核对对象（前四轮只在改代码时顺手同步、从未反向
验证「文档写的 = 客户端实际会收到的」），查出两处：

- §14 把解散结算写成 route=erqiwang / rpc=jiesuan 的独立包，实际平台是把
  get_disbandRoom 的返回值整个塞进房间路由的 route=room / rpc=free_room 包，
  即 data.deskfree = { rpc:"jiesuan", data:{...} }，比文档多一层 data 包装，
  真实取值路径是 data.deskfree.data.aset；前端照原文档写会取空。新增 §14.1
  给出真实包结构、取值要点、两层 success 的归属与 deskfree 可能缺失的情形。
- 文档多处引用「roomtype 位2/位3」，却从未给出位串定义（只存在于 compliance
  文档里），前端无法据协议拼建房串。新增 §0.5 位表 + 缺省示例 + 兜底规则 +
  局数/扣卡 4 组合对照，并指明 class.config.js parse() 为唯一解析入口。

compliance 记第五轮核对：design 维度逐条复核未发现新的不一致；新发现 4 项
（F1 跟牌入参顺序、F2/F3 协议文档、F4 解散空守卫）已全部处置，并留痕本轮
确认无误、勿再重提的三点观察。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

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

@@ -133,6 +133,33 @@
 
 ---
 
+## 第五轮核对（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 项**全绿。
+
+---
+
 ## 结论摘要
 
 > **注**：下表是**首轮核对**的初始发现快照（保留以记录起点）。其中 §4.4、§5.4、§6.3、§7、§8.1-8.4、§9、§10、§11 等标 🟥/🟧/🟨 的项**后续均已修复并验证**——当前逐节状态以本文档后面的分节详情及全套单测（270 项全绿）为准。