二七王：把「无超时托管」确认为规则，写入 design §11

服务端四个阶段只下发 countdown、没有任何定时器，此前被本轮核对记
为待办 D3（等规则设计者定义超时默认动作）。规则设计者已确认：
**维持现状，不需要超时动作**。

这属于规则本身如此、而非实现缺口。若不固化下来，下一轮核对会再次
把它当缺陷提出、甚至有人去补一套「超时自动出牌」，反而违背规则。
故写进 design.md 作为权威约定：

- design §11 新增一条：倒计时只作展示、不触发任何自动操作——不自
  动叫分/选主/埋牌/出牌，也不判负、不跳过；轮到谁而谁不操作，牌局
  就停在这一步等待。并加醒目说明：这是确认过的规则、不是待实现的
  缺口，牌局停住由玩家走房间解散流程收场（按当前累计分结算，
  §12.2），后续核对不要为它补超时托管。
  （解散路径已核实：平台 server_room 侧有 freeroom 解散倒计时，并
  回调子游戏 export.get_disbandRoom → get_paiju_account(2) 出解散
  结算包，与 §12.2 一致。）
- 协议文档新增 0.3「countdown 只是展示用的秒数」：说明服务端无定
  时器、归零不做任何事，并要求客户端不得在归零时做乐观界面推进
  （原 0.3 顺延为 0.4）。
- 合规 01：D3 由「🟧 中等/未修」改为「✅ 规则如此」，并说明 server
  dev-guide「服务端自动操作复用真人链路」约束的是「若要做代打就必
  须复用真人链路」，本局不做代打故不适用；「尚未处置」小节改为
  「无」，11 项全部收口。
- 合规 02：撤掉「仍无自动化覆盖」中的超时项，改为说明不需要超时用
  例，并反向标注：若将来有人给服务端加了超时代打，那才是违反
  design §11、应由核对拦下。

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

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

@@ -79,17 +79,19 @@
 | 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`，但服务端**无任何定时器**做超时兜底/托管，玩家掉线不操作则牌局永久卡死（server dev-guide「服务端自动操作复用真人链路」） | **未修**，见下方「待办」 |
+| 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` |
 
-### 尚未处置（需外部输入）
+### 尚未处置
 
-- **D3 超时托管**：服务端对四个阶段只下发 `countdown` 数值，没有对应的定时器与超时后的默认动作（自动叫分/选主/埋牌/出牌）。design.md 未规定托管行为，且默认动作与前端表现强相关，需与前端和规则设计者一起定义后再实现。当前状态下**任一玩家掉线不操作，该局会永久停住**。
+**无。** 本轮发现的 11 项已全部收口：
 
-> D6 原为「规则歧义、待确认」，现已由规则设计者拍板（不可查牌屏蔽出牌历史），已改 design §9 + 代码 + 单测，不再是待办。
+- A1/B1/B2/B3/C1/D1/D2/D4/D5/D7 共 10 项为缺陷，已改代码 + 补单测；
+- D6（不查牌是否屏蔽出牌历史）原为规则歧义，已由规则设计者拍板「屏蔽」，改 design §9 + 代码 + 单测；
+- D3（超时托管）原列为待外部输入，已由规则设计者拍板 **维持现状、不做超时动作**，属**规则如此、并非缺陷**，已写入 design §11 固化，避免后续核对反复把它当缺口重提。
 
 ---
 

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

@@ -182,8 +182,6 @@ design 全部服务端可验证章节均有正/反/边界单测：
 | §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，应由核对拦下。
 
-- **超时托管**（`01` 表 D3）：服务端只下发 `countdown`、无定时器与默认动作，玩家不操作则牌局永久停住。默认动作需与前端/规则设计者共同定义，定义前无法写期望。
+> 原列在此处的两项「待外部输入」均已由规则设计者拍板：「不查牌模式是否屏蔽出牌历史」确认屏蔽，已改 design §9 + 代码 + 用例（见上表）；「超时托管默认动作」确认维持现状、不做超时动作，已写入 design §11。至此测试计划无待外部输入项。
-
-> 原列在此处的「不查牌模式是否屏蔽出牌历史」已由规则设计者确认（屏蔽），design §9 改写为无歧义表述，代码与用例均已落地，见上表「§9 出牌历史按查牌模式门控」。

server/games/erqiwang/docs/design/design.md

@@ -664,6 +664,9 @@
   1. **踩**：提示对家"我能大过庄家"。
   2. **没分**：提示对家"我手上没分了"。
   3. **有分**：提示对家"我手上有分"。
+- **倒计时只作展示，不触发任何自动操作**：叫分 / 选主 / 埋牌 / 出牌四个阶段都会给出一个倒计时秒数，用于界面提醒当前该谁操作。**倒计时归零后不做任何代打**——不自动叫分、不自动选主、不自动埋牌、不自动出牌，也不判负、不跳过该玩家；轮到谁而谁不操作，牌局就停在这一步一直等。
+
+> **"无超时托管"是确认过的规则，不是待实现的缺口**：本局不设服务端代打/AI 托管，也不因超时改变任何对局状态。若玩家长时间不操作导致牌局停住，由玩家走房间的**解散**流程收场，按当前累计分结算（见 12.2）。**后续核对不要把"没有超时动作"当成缺陷去补"超时托管/自动出牌"。**
 
 ---
 

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

@@ -43,7 +43,17 @@
 
 > **例外：`tishi` 成功时不回执**。该包是闲家给对家的主观提示、不含任何对局状态，服务端只转发给对家（design §11），发送者收不到成功包；只有失败才回给发送者。
 
-### 0.3 断线重连包不在此约定内
+### 0.3 `countdown` 只是展示用的秒数
+
+多个包带 `countdown`（叫分 / 选主 / 埋牌 / 出牌倒计时，取自 `class.desk.js` 的四个常量）。它**只供客户端显示提醒，服务端不据此做任何事**：
+
+- 服务端**没有**对应的定时器，倒计时归零后**不会**自动叫分 / 选主 / 埋牌 / 出牌，也不判负、不跳过该玩家；
+- 轮到谁而谁不操作，牌局就停在该阶段一直等，`step` 与 `playproc` 都不变；
+- 这是 design §11 确认过的规则（无超时托管），不是未实现的功能。牌局因此停住时，由玩家走平台的**房间解散**流程收场（平台回调子游戏 `get_disbandRoom` → 解散结算，见 §14）。
+
+因此**客户端不要在倒计时归零时做任何乐观的界面推进**（不要自行跳阶段、不要清控制权），一切仍以收到服务端推送为准。
+
+### 0.4 断线重连包不在此约定内
 
 `deskinfo` 由平台组装在 `pack.data.deskinfo` 下（见文末「断线重连」），`data.success` 由**平台**填写，子游戏不注入。
 
@@ -408,7 +418,7 @@
 
 ## 断线重连（deskinfo）
 
-> 由平台在玩家进入房间/断线重连时回调 `youle_erqiwang.export.get_deskinfo(o_room, seat)` 生成并下发（服务器→客户端）；下发的 app/route/rpc 由平台的进房/重连流程决定，不在本子游戏代码内固定。平台把它挂在 `pack.data.deskinfo` 下，**`data.success` 由平台填写、子游戏不注入**（见 0.3）。下列字段即该函数返回的 `deskinfo` 对象结构，按当前 `paiju.step` 只带对应阶段的分组。
+> 由平台在玩家进入房间/断线重连时回调 `youle_erqiwang.export.get_deskinfo(o_room, seat)` 生成并下发（服务器→客户端）；下发的 app/route/rpc 由平台的进房/重连流程决定，不在本子游戏代码内固定。平台把它挂在 `pack.data.deskinfo` 下，**`data.success` 由平台填写、子游戏不注入**（见 0.4）。下列字段即该函数返回的 `deskinfo` 对象结构，按当前 `paiju.step` 只带对应阶段的分组。
 
 | 参数名 | 类型 | 说明 |
 | --- | --- | --- |