二七王：第七轮核对（反方向代码→design）+ 新增下发面泄露审计

前六轮都是「design → 代码」方向。本轮反过来：从代码出发，把每个规则决策与常量拉出来追问 design 有无明文依据。没有发现与 design 冲突的行为，但列出 6 项「design 未明文规定、由代码自行决定」的项（倒计时秒数、§5.4.4 降级阶梯是否最长优先、甩牌分解的最大化合并约定、同级副7对不成连对、call 入参宽松而 cards 严格、get_chongguan 的 <28 隐式兜底），已写进 compliance 待规则设计者拍板。同时补上一块此前完全没有测试的红线：**下发面按可见性下发**。design §4 暗牌只有庄家可见、§9 查牌模式、§11 结束亮底牌，以及 server 红线「发全 ≠ 发多」，此前各处门控只有逐条手工核对，从未系统验证「有没有哪个包把不该看的牌送到了某个座位」。新增 test/test_leak.js：跑 6 局（可查牌/不查牌 × 叫 65/70/5），对每一个「服务器 → 某座位」的下发面（各 RPC 逐座位包 + 各阶段重连快照 + 明牌应答）深度扫描出所有牌 id，逐个判定该座位此刻是否有权知道。结果 1814 个下发面 / 18706 次可见性判定，0 泄露。变异检验：非 70 分把暗牌发给闲家（第三轮修过的历史缺陷）、重连把底牌发给闲家、出牌包把剩余手牌发给所有人 —— 三条全部被抓住。全套单测 520 → 523 项全绿。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-23 14:29:12 +08:00
parent 49ee068c5c
commit b5d9eece5d
3 changed files with 164 additions and 0 deletions
@@ -217,6 +217,39 @@ F1~F4 修复后，对 **design.md 维度**又做了一次独立取证复核。

 ---

+## 第七轮核对（反方向：代码 → 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 张暗牌发给闲家（这正是第三轮修过的历史缺陷） | ✅ 抓住 |
+| 重连时把庄家埋的底牌发给闲家 | ✅ 抓住 |
+| 出牌包把出牌者剩余手牌发给所有人 | ✅ 抓住 |
+
+---
+
 ## 结论摘要

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