二七王：协议文档修正解散结算的真实投递方式，补 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 项全绿）为准。

server/games/erqiwang/docs/protocol/packet_protocol.md

@@ -57,6 +57,29 @@
 
 `deskinfo` 由平台组装在 `pack.data.deskinfo` 下（见文末「断线重连」），`data.success` 由**平台**填写，子游戏不注入。
 
+### 0.5 `roomtype` 房间选项位串（建房参数，下文多处引用「位2 / 位3」）
+
+`roomtype` 是**建房时**由客户端拼好、经平台建房流程存在 `o_room.roomtype` 上的**定长数字位串（字符串）**，每一位（`charAt`）一个开关 `'0'/'1'`，便于前端逐项勾选。它不是某个 erqiwang 收发包的字段，但下文多个包的 `multiple` / `bangwang` / `climb` / `baozhu` / `seatlist` / `liangpai` / `pushlist` 都按它取值或门控，故在此给出唯一定义。服务端解析入口是 `class.config.js` 的 `parse()`（SSOT，不得在别处按下标硬解析）。
+
+| 位 | 含义 | `'0'` | `'1'` | design |
+| --- | --- | --- | --- | --- |
+| 0 | 局数 | 6 局（缺省）| 12 局 | §10.1 |
+| 1 | 扣卡方式 | 房主扣卡（缺省）| AA 每人扣卡 | §10.1 |
+| 2 | 傍王 | 关（缺省）| 开 | §8.3 / §10.3 |
+| 3 | 爬坡 | 常规算子（缺省）| 爬坡 | §7.3 / §10.3 |
+| 4 | 查牌模式 | 可查牌（缺省）| 不查牌 | §9 / §10.2 |
+
+缺省 `"00000"` = 6局 / 房主扣卡 / 无傍王 / 常规算子 / 可查牌。示例 `"10100"` = 12局 / 房主扣卡 / 傍王开 / 常规算子 / 可查牌。解析对**缺失、非字符串、过短**的 `roomtype` 一律按 `'0'` 处理。
+
+对应的房卡与局数（`export.get_asetcount` / `get_needroomcard` / `get_needroomcard_joinroom`，design §10.1）：
+
+| 扣卡方式（位1） | 局数（位0） | 房主开房扣 | 加入者扣 |
+| --- | --- | --- | --- |
+| 房主扣卡 `'0'` | 6 局 | 2 张 | 0 |
+| 房主扣卡 `'0'` | 12 局 | 4 张 | 0 |
+| AA 每人 `'1'` | 6 局 | 1 张 | 1 张 |
+| AA 每人 `'1'` | 12 局 | 2 张 | 2 张 |
+
 ---
 
 ## 1. 发牌（fapai）
@@ -322,7 +345,34 @@
 
 - **正常出牌结算**（`mod.chupai` 中最后一张牌出完，`get_paiju_account(0, ...)`）：含 `chupai` + `bottom` + `aset`（末局再加 `account`）。
 - **投降结算**（`mod.touxiang`，`get_paiju_account(1, ...)`）：只含 `aset`（末局再加 `account`），无 `chupai`、无 `bottom`。
-- **解散结算**（`export.get_disbandRoom`，`get_paiju_account(2, ...)`）：只含 `aset` + `account`，无 `chupai`、无 `bottom`。
+- **解散结算**（`export.get_disbandRoom`，`get_paiju_account(2, ...)`）：只含 `aset` + `account`，无 `chupai`、无 `bottom`。**投递方式与上面两种不同，见 §14.1。**
+
+上面这张表头（`route: erqiwang / rpc: jiesuan`）**只适用于前两种**——正常出牌结算与投降结算，由子游戏自己 `sendpack_toother` 广播，客户端在 `rpc == "jiesuan"` 的分支里按 `data.aset` 取值。
+
+### 14.1 解散结算的投递方式（与前两种不同，客户端需单独处理）
+
+解散**不是**由子游戏发包，而是平台在解散流程里回调 `youle_erqiwang.export.get_disbandRoom(o_room)`，把**返回值整个对象**塞进**房间路由**的解散包里下发（平台 `server_room/rpc.js`、`server_room/class.room.js`）。因此客户端收到的是：
+
+```json
+{
+  "app": "youle", "route": "room", "rpc": "free_room",
+  "data": {
+    "seats": [],
+    "deskfree": {
+      "rpc": "jiesuan",
+      "data": { "success": true, "aset": {}, "account": [] }
+    }
+  }
+}
+```
+
+要点（照 §14 的表去 `data.aset` 取值会取空）：
+
+- **rpc 是平台的 `free_room`（route 也是 `room`），不是 `erqiwang/jiesuan`**；子游戏返回的 `rpc: "jiesuan"` 只是嵌在 `deskfree` 里的一个普通字段。
+- **多一层 `data` 包装**：真实取值路径是 `data.deskfree.data.aset` 与 `data.deskfree.data.account`。
+- 本包的成败标志有两层：外层 `data.success` 由**平台**填写（解散流程本身成功与否），子游戏结算自带的 `success` 在 `data.deskfree.data.success`。§0.1「每个包 `data` 必带 `success`」说的是子游戏自己发的包；本包外层归平台。
+- `aset` / `account` 的字段结构与下面 §14 的表完全一致（`aset.multiple = 0`、`upgrade = 0`、各家 `grade = 0`，即解散局不结算子数与算奖；`account` 恒有，见 design §12.2「按当前累计分结算」）。
+- 若解散发生在**开战后、首局牌发出前**的窗口内（本游戏首局由 `makewar` 延迟 1 秒创建），`get_disbandRoom` 返回 `null`，平台走「不带 `deskfree`」分支——客户端需容忍 `data.deskfree` 缺失。
 
 **chupai（出牌包，仅正常出牌结算存在）**