daoqi/erqiwang_youle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
56 Commits 1 Branch 0 Tags
b5d9eece5d32c03a1722de6c22016ff4f52628d9
Commit Graph
27 Commits
Author SHA1 Message Date
joywayerandClaude Opus 5 b5d9eece5d 二七王：第七轮核对（反方向 代码→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
joywayerandClaude Opus 5 9d0675fce8 二七王：第六轮核对（多局大局 + 整局带牌型模糊），未发现不一致 
前五轮的端到端都只跑单局、且只出单张。本轮补两个从未被驱动过的维度：

一、多局大局（design §12.1 步骤10 / §12.2 / §4.6）
真实驱动 6 局与 12 局：跨局轮庄与「上局 banker+result」严格对应，另单独造出
result=0 的庄赢局验证连庄端到端（此前只有 do_prepare 的桩单测）；每局零和、
累计分与逐局累加一致；account 只在末局出现，打满后再准备被拒；房卡只扣一次；
战绩载荷完整；中途解散按当前累计分结算、result=3。全部相符。

二、整局带牌型模糊（新增 test/test_fuzz.js）
test_endgame 的驱动器只会出单张，对子/拖拉机/甩牌/甩错在整局链路里从未跑过。
新测试用带牌型的对局补上，并对每一墩用独立参考实现重算「谁最大」与服务端
比对（不是抽查），另独立重算捡分、扣底倍数、算奖与捡分子数分配。探针阶段
跑了 160 局约 3800 墩（4 个种子）0 异常，入库版固定为 20 局约 480 墩、0.3s。

变异检验：牌的归属写给非胜者、单张毙牌不再压过副牌、算奖分配去掉 ×X、
跟牌牌面值改回未排序入参 —— 四条全部转红。

过程中修正了测试自身的三个问题（已写进 test/README 与 compliance）：
- 参考实现的 rank 取了负数，而 0 是「不参与本墩」的哨兵，哨兵反而数值最大；
- 闲家捡分按 playowner 累加再与 aset.grade 比，是拿被测字段自证，playowner
  写错时两边一起错照样通过 —— 改成按独立算出的墩胜者累计；
- 扣底倍数再调 get_bottom_multiple 去比，同样是自证，倍数表改成恒返回 2 也
  通过 —— 改成按 design §6.3 独立重算。
另：该文件的覆盖下限是发牌相关的，随机发牌下扣底可能一次都不出现（实测 60
次里有 1 次），故把发牌也接到固定种子上；随机发牌的整局覆盖由 test_endgame
承担。

全套单测 511 → 519 项全绿，总耗时 < 1.7s。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-23 13:58:02 +08:00
joywayerandClaude Opus 5 a4361a802d 二七王：补 9 处 design 规则的正/反/边界用例（均通过变异检验） 
对 design §1~§12 重做「每条规则是否三类用例齐全」的审计。此前的覆盖矩阵按
「被测函数」组织，容易漏掉跨函数才体现的规则，本轮补齐 9 处：

- G1/G2 §4.2 叫分：下限5与非首家不叫接受，负数/缺call/步进外/同分拒；
  「不叫即退出本局叫分」——反悔再叫被 SEAT 拒、callproc 不变、仍轮到下一家
- G3 §4.5 埋牌：非庄家 SEAT、step2/step5 STEP、7张/9张/空数组 PARAM
- G4 §5.1 每轮由上一轮牌面最大的一方先出（闲1赢/闲2赢两种）
- G5 §6.2 闲家赢计入台面全部分牌（含庄家自己打出的）、庄家赢作废、
  两个闲家谁赢结果一致
- G6 §8 算奖快照：庄家埋后28（已埋不在内）、闲家28、投降36、打出后不缩水
- G7 §3 对子只认同花色同点数两副：跨花色副7/副2、正副7、大小王均不成对
- G8 §6.3 赢末轮的牌不全是主牌就不扣底（副牌拖拉机/混合出牌/顺序颠倒）
- G9 §11 无超时托管守卫：对局阶段 min_ontimeout 调用次数必须为 0，
  将来有人加超时代打就会转红

每条都在副本上注入违反该规则的改动确认转红（7 组变异全部被抓住）。

顺带修一个测试自身的问题：mkBury 桩缺 do_burycard，导致「埋牌张数校验被
改松」这类变异表现为整个文件崩溃而非某条断言转红，后续断言全不执行。桩已
补完整到能走完成功路径。

全套单测 462 → 511 项全绿。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-23 13:36:09 +08:00
joywayerandClaude Opus 5 1b76683704 二七王：固化两组 design 差分测试（§7 全量对拍 + §5.2 穷举差分） 
把第五轮复验用的取证探针固化入库。两者都不枚举「我想到的场景」，而是把
design 的规则整条转写成参考实现再与代码大面积对拍，专治手写用例覆盖不到
的欠约束分支：

- test_calc.js：§7 算子全量对拍。参考实现逐字转写自 §7.1/§7.2/§7.3 判定表，
  比对 2 种算子模式 × 14 个叫分档 × grade 0~260 共 7308 格（每格比
  base/Q/判定倍率/最终子数），另按 design 的 17 张表逐格抽查 141 个写死的
  最终子数。断言按档位分组，失败可直接定位。
- test_followdiff.js：§5.2 跟牌强制层级穷举差分。对每手牌枚举全部 C 张出牌
  组合，逐个比对参考裁定与 can_followcard，约 11 万组。

两组均通过变异检验：关掉 follow_tractor_cover_ok → followdiff 三种拖拉机
首出全红；大光倍率 3→4 / 常规55档 base 4→5 / 爬坡40·35档 Q 20→40 → calc
精确指出档位与 grade。

过程中的教训已写进 test/README 与 compliance：差分测试的强度取决于造牌器。
第一版纯随机抽牌跑 7.8 万组全绿，但关掉覆盖度校验依然全绿——「同花色三组
互不相邻的两连对」这种唯一能区分「只出零散对子」与「先凑最长拖拉机」的
12 张结构随机抽不出来；掺牌又一度把它撑过枚举上限被静默跳过。故随机源改用
固定种子 PRNG，关键结构用确定性 structHands() 钉死。

全套单测 401 → 462 项全绿，总耗时 < 1.5s。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-23 12:56:30 +08:00
joywayerandClaude Opus 5 e8a7b245cc 二七王：记录第五轮·复验（design 维度的穷举/差分取证，未发现不一致） 
不再逐条读代码，改为按 design.md 原文另写参考实现再与代码穷举对拍：

- §7 算子：两种算子模式 × 14 个叫分档 × grade 0~260 全量对拍 14672 格
  失配 0，另抽查 design 表格里写死的最终子数 113 格失配 0
- §5.2 跟牌强制层级：按原文写参考裁定，4000 手牌枚举全部出牌组合，
  86474 组失配 0
- §5.4 甩牌最大性：按 §5.4.2 原文写参考判定，6000 例失配 0
- §2/§3/§5.3/§6/§8/§4/§9/§10/§11 逐条取证，全部符合

两次「疑似失配」经查都是探针写错（甩错最小张那一档有两副牌、闲家赢轮的
台面分含庄家自己打出的分牌），代码是对的，已在台账注明避免后续重提。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-23 12:45:33 +08:00
joywayerandClaude Opus 5 2fd5829551 二七王：协议文档修正解散结算的真实投递方式，补 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>
 2026-08-23 12:18:18 +08:00
joywayerandClaude Opus 5 681be60e20 二七王：design 全量复验（无新增不一致）+ 补端到端整局单测 
对 E1~E3 修复后的实现做取证式复核：把 design 的判定语句做成可执行探针直接
打在代码上（§5.1/§5.2 跟牌层级、§8.1 算奖连对链、§7 算子逐档、§5.4 甩牌最大性、
§6.3 扣底、§8.4 三条支付线、§4/§9/§10/§11 流程与门控），未发现新的不一致。

新增 test/test_endgame.js：用真实发牌跑完整一局（叫分→上庄→选主→埋牌→28 轮
出牌→小局结算）并校验与牌面无关的不变量（牌张守恒 84/8/16、捡分=闲家赢得分牌
+扣底分、X 分配庄±2X/闲∓X、算奖 X×(2Ni−Nj−Nk)、零和、result 与判定一致），
另覆盖投降局与中途解散两条支线。连跑 10 次无抖动，全套单测 389 项通过。

合规文档补记「第四轮·复验」取证表。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-16 19:47:01 +08:00
joywayerandClaude Opus 5 916066ba96 二七王：修正 design 全量重核发现的 3 项不一致（亮牌快照/报无主下发面/甩牌张数上限） 
- §8.2 亮牌改用埋牌后 28 张静态快照 get_seat_cards_award，不再用
  get_seat_cards（只含未出的牌）——否则闲家重连时 get_deskinfo 按庄家
  当前剩余手牌重算，亮牌统计缩水甚至变 null。
- §9 出牌包由只带出牌者一家的 info 改为整表下发三家 seatlist，与重连包
  PushCards.seatlist 同名同构；报无主后另两家的主牌数/对子数不再滞后两次出牌。
- §5.4.3 甩牌"无组合数量限制"：can_playcard 去掉规则外的 14 张硬上限，
  改为结构性上界 28（单人手牌上限，牌型编码在此范围内不溢出）。

协议文档同步改写 chupai 三处 info 条目与 liangpai 口径；合规文档补记第四轮
核对（流程层无缺环，规则层 3 项已收口）。全套单测 368 项通过。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-16 19:33:06 +08:00
joywayerandClaude Opus 5 b6aeba412f 二七王：把「无超时托管」确认为规则，写入 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>
 2026-08-16 19:05:24 +08:00
joywayerandClaude Opus 5 35affa7c20 二七王：不可查牌模式屏蔽出牌历史（design §9 消歧义 + 代码门控） 
design §9 原文把可查牌模式的四项功能列成无序列表，不可查牌只写
「不提供以上任何查看 / 明牌功能」，随后展开的例子却只提了主牌数量、
对子结构、明牌按钮、亮牌统计，没提第一条「已经打出的牌可以查看」，
导致"以上"的范围有歧义。代码据此照发出牌历史，前一轮核对把它记为
待确认项（01 表 D6）。

规则设计者已确认：**不可查牌模式必须屏蔽出牌历史，只有可查牌模式
才能查看**。据此：

- design §9 改写为无歧义表述：先给出「查牌 = 回看不该随时可见的信
  息」的定义，把可查牌的四项功能编号列出（① 出牌历史 ② 报无主后的
  他家主牌数/对子数 ③ 明牌 ④ 庄家亮牌），不可查牌逐条对应说明一项
  都不提供；并补一段边界说明——**当前这一轮桌面上的牌两种模式下都
  必须可见**，否则后出的人无从跟牌、无从判断本轮谁最大，断线重连同
  理（当前轮照常恢复，往轮历史按模式开关给不给）。
- class.export.js：get_deskinfo 的 PushCards.pushlist 构建与排序整
  体移入 `if (!cfg.nocheck)`，不查牌时不带该属性；当前轮桌面牌由
  PushCards.playproc.cards 恢复，两种模式都有。
- 协议文档：pushlist 补「仅可查牌模式下有此属性」，playproc 补「两
  种模式恒有」及其原因。
- 合规文档：01 表 D6 由「待确认/未修」改为已确认并修复，从「尚未处
  置」移出；02 测试计划断言总数 357→361 并新增该维度覆盖行。

test_rpc 新增 4 项：不查牌房无 pushlist、可查牌房有 pushlist，且两
种模式下当前轮桌面牌 playproc.cards 都能恢复。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-16 18:55:33 +08:00
joywayerandClaude Opus 5 c4256c51db 二七王合规文档：修正"全部符合"结论并补第三轮核对 
01 的「二次全量复核结论」写的是「服务端全部符合 design.md」，但该
轮核对完全按 design 章节组织，平台接入、客户端入参校验、下发面一
致性、协议红线这几类问题整类不在范围内——所以 270 项断言全绿的同
时，漏掉了 1 项阻断级（子游戏从未在 app.js 注册，运行时不可达）、
3 项严重（重复牌id 可伪造牌型、入参无类型校验、下发面 multiple 忽
略爬坡）与 data.success 红线缺失。

本次：
- 01 把结论限定为「就 design.md 的玩法规则维度而言符合」，并加警示
  「符合 design.md ≠ 实现完整正确」。
- 01 新增「第三轮核对」章节：A1/B1/B2/B3/C1/D1~D7 共 11 项的严重
  度、位置、实测现象与处置，并单列两项需外部输入的待办（D3 超时托
  管无定时器、D6 不查牌模式是否屏蔽出牌历史的规则歧义）。
- 02 测试计划更新断言总数 270→357，新增「第三轮补充：design 之外
  的可验证维度」覆盖表（入参校验/重复id/报无主刷新/success 成功包
  与失败回包/multiple 同源/甩牌下发面/pushlist 结构/相邻链花色），
  并写明两项仍无自动化覆盖的原因。
- 00 加一段说明前两轮的核对范围局限，指向 01 第三轮。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-12 04:25:15 +08:00
joywayerandClaude Opus 5 a049498f2c 二七王协议文档：补齐 success/errcode 约定并同步本轮字段变更 
协议文档开头一直写着「成败判定只看推送包里的 data.success」，但下
面没有任何一个包定义过该字段，代码里也没有——文档自相矛盾且与实
现不符。本轮代码补齐后同步文档：

- 新增「0. 通用约定」：0.1 所有服务器→客户端包必带 data.success；
  0.2 失败回包（rpc 与请求同名、只回请求者、success=false+errcode）
  与 errcode 取值表，另附 cards 牌id 入参约束（非空数组、0~107 整
  数、不重复，不做类型兜底）与 tishi 成功不回执的例外；0.3 说明
  deskinfo 的 success 归平台填写。
- 6 处 multiple 描述改为 get_base_bycall(call, climb)，列出爬坡与
  常规两套取值，并注明与结算包 aset.multiple 同源。
- chupai1 补 shuai 字段；cardtype 补完整取值说明与「甩牌会被压平、
  真实结构读 shuai」的告警。
- 3 处 info 描述补「有人报无主后三个座位同时刷新」。
- PushCards.pushlist 描述补「内层恒 3 个座位、按本局主牌花色排序」。
- mingpai / tishi 的「否则忽略」改为按 0.2 回对应 errcode 的失败包。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-12 04:22:53 +08:00
joywayerandClaude Opus 4.8 9456ab9319 二七王：实现 §11 闲家三提示(踩/没分/有分) + 明确副7/副2 成对语义 
全面符合性再审查(4 维度独立对抗核对)结论：与计分/发牌/出牌/跟牌/甩牌
相关规则均一致，无缺陷；仅 §11 闲家三提示服务端缺失、副7/副2 异花色
成对语义存疑两项待办。本次按用户裁定落地：

1. §11 三提示（新增 mod.tishi）：闲家在出牌阶段(step5)发 踩/没分/有分，
   服务端不校验真实性、只 SendPack 转发给对家(另一闲家 3-banker-seat)；
   庄家无对家不参与；非法 tip/非出牌阶段/庄家发均拒。
   协议补 packet_protocol §13.7/13.8；test_rpc +11 例(正反+边界)。
2. 副7/副2 成对语义：裁定"只同花色同点数两副成对"(代码本已如此，无需改)，
   在 design §3 补说明闭合该反复出现的存疑（异花色副7 不成对）。

compliance 文档同步：§11 状态转✅、首轮结论摘要加"非当前状态"说明、
计数 259→270。全套 270 项断言全绿(rpc 34→45)。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 16:39:04 +08:00
joywayerandClaude Opus 4.8 5c9a78029a 二七王测试计划：同步跟牌覆盖度修复后的计数与状态 
test_follow 由 35→50 例、全套 244→259 项；§5.1/5.2 覆盖状态由"❌重大
缺口"更新为✅（含混合出牌、毙牌完全缺门、降级递归 else 欠约束修复回归）。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 07:19:23 +08:00
joywayerandClaude Opus 4.8 1edbe9cc24 二七王规则：新增"混合出牌"概念（副牌不够+补主牌，等效垫牌） 
场景：首家出副牌、跟牌方有该花色副牌但张数不够、又无其他副牌可垫，
只能用主牌补差额，打出"副牌+主牌"混合。核对 can_followcard：混合牌
组不成纯主牌牌型，cardvalue=0，压不过首家。此前文档未成文——补入
术语表并在 §5.2 数量不足段落指向，明确它既非垫牌也非毙牌、但与垫牌
等效、不争夺出牌权。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 06:58:25 +08:00
joywayerandClaude Opus 4.8 55db22f4b1 二七王规则：明确 §5.2 同花色牌数量不足时缺口补牌规则 
原第 150 行仅笼统一句"缺口部分可任意补其他牌"，未针对"首家出拖拉机"
点破缺口不必成对/成拖拉机，且易与层级 4(同花色够、对子不够→补同花色
单张)混淆。按 get_followcard 数量不足分支(cantype 落单张型、只校验张数)
改写为：该花色牌全部必出，缺口用任意其他花色牌补、不强制成对/成拖拉机，
并与"完全缺门"情形分段。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 06:48:38 +08:00
joywayerandClaude Opus 4.8 83545e8b80 二七王规则：修正 §5.2 毙牌成立条件为"完全缺门" 
原第 156 行写"没有该副牌花色的同长度拖拉机"即可毙，暗示手里有该
花色的牌但不成拖拉机时也能用主牌毙——与代码不符。核对
class.arith.js can_followcard：毙牌成功(cardvalue>0)仅出现在完全
缺门分支，只要手中还有首家花色的牌，get_followcard 即判为必出，
只能垫不能毙。将三条特殊情况统一收紧为"完全缺门"，并补前提说明。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 06:36:57 +08:00
joywayerandClaude Opus 4.8 93449c8a92 二七王规则：按代码实际行为补全 §5.2 拖拉机跟牌的强制降级层级 
design.md §5.2 原本只描述"两连对"最简情形，缺少 3 连对及以上的
强制层级。按 class.arith.js get_followcard 的实际实现补写为完整
优先级表：同长拖 > 更短拖拆凑 > 对子够 > 对子不够全出+补 > 单张补；
并修正对子行"同花不足两张必出现有同花"的措辞。§5.4.4 甩牌跟牌
加一句交叉引用，点明与正常跟牌共用同一层级原则。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 06:16:50 +08:00
joywayerandClaude Opus 4.8 0d9ea36c10 二七王测试：穷举跟牌方手牌分支，补主牌首出与拖拉机各分支 
回应"是否模拟了跟牌方所有手牌与边界"的核对，补齐：
- 主牌首出的跟牌（单/对）——原仅测副牌首出
- 对子首出·同花色仅1张（必出它+补1张）
- 拖拉机首出的跟牌方分支：对子不够(出仅有的对+补)、同花无对(补同花)、
  多候选拖拉机(cantype=3xx，回归 can_followcard 曾崩溃的 D1 分支)、
  3连对首出、富余对子中必出3连拖/拆散拒
- 手牌数==首出张数（全部必出）

全部单测 244 项断言全绿（test_follow 35）

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 01:51:58 +08:00
joywayerandClaude Opus 4.8 c29aec140c 二七王测试：补全甩牌/跟甩牌全部情形 
回应"甩牌与跟甩牌测试是否完整"的核对，补齐缺口：
- 甩牌首出(§5.4)：甩错由主对分量/拖拉机分量/双对之一被压引发(原仅测单张分量)；
  纯双单张、纯双对(不连)、单张+拖拉机、单+对+拖三分量混合的合法；副牌禁甩·对手非缺门
- 甩错惩罚实际执行(§5.4.5)：do_playcard 收回甩牌、只强制打出最小一张、其余留手；合法甩牌整套打出
- 跟甩牌(§5.4.4)：拖拉机分量退化到单张(对子也不够)、多组拖拉机分量、混合demand逐分量对位
- 集成：首出合法甩牌→跟牌方拆散主对(违反§5.4.4)→ do_playcard 拒；正确对位→接受

全部单测 226 项断言全绿（arith 101 / paiju 31 等）

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 01:34:02 +08:00
joywayerandClaude Opus 4.8 339e6e99e1 二七王测试：完成 P2 用例，达成测试计划 DoD 
- test_deal.js(新)：§2 发牌构成——92张/去3-4共16/三家各28+底8/分值(§6.1)
- test_arith.js：§3 编码排序（order_cards 降序=设计顺序、is_continuous 相邻链逐段+反例）、
  §7 每档小光/过庄分界+升3级补齐
- test_paiju.js：§8.2 亮牌更多边界（6个7仅qi、固定主9→null、固定主10仅zhu）
- test_config.js：§10 直接调 export.get_asetcount/get_needroomcard(_joinroom)
- test_rpc.js/_rpc.js：§12 端到端（真实驱动 叫分→上庄→选主→埋牌→出牌ready）、
  §9 maipai 亮牌门控 + get_deskinfo PushCards 门控
- 02-测试计划.md/README：P2 与 DoD 标记达成

全部单测 204 项断言全绿（node server/games/erqiwang/test/run.js）

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 01:24:34 +08:00
joywayerandClaude Opus 4.8 6939e70ed7 二七王测试：完成 P1 用例（L3 RPC 层 + 坐庄轮换） 
- mod.js：加 module.exports 守卫，使其可被 Node require（友乐无 module 跳过）
- test/_rpc.js(新)：L3 脚手架——挂类全局、mock cls_mod/min_loadJsFile 装配 mod.js、
  捕获 SendPack/sendpack_toother 下发包
- test/test_rpc.js(新)：§9 明牌 mingpai(合法/不查牌·未报无主·非出牌阶段拒 + others结构)、
  §9 出牌 chupai 的 info/baozhu 查牌门控(可查有/不查无)、§4 投降 touxiang 条件(70·step2·庄家)、
  §4.2 mod.jiaofen 入参校验(>70/非5倍/首家必叫/后叫更低)、
  §4 70分上庄暗牌亮牌(真实 jiaofen 驱动到上庄，验证 bottomcards/ancard3s 门控)
- test/test_desk.js(新)：§4.6 坐庄轮换 do_prepare(庄赢连庄/闲赢·投降下家)
- 02-测试计划.md/README：P1 标记完成，剩余归入 P2

全部单测 156 项断言全绿（node server/games/erqiwang/test/run.js）

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 01:14:33 +08:00
joywayerandClaude Opus 4.8 0049754988 二七王测试：完成 P0 用例（正常跟牌/结算集成/叫分坐庄/扣底触发） 
- test_follow.js(新)：§5.1/5.2 正常跟牌/毙牌/垫牌 17 例——单张/对子/拖拉机的
  必出、缺门毙牌数量对应(副单→主单/副对→主对/副N连→主N连)、垫牌、有对/拖却出散张被拒
- test_callgrade.js(新)：§4.2 叫分坐庄 do_callgrade 6 例（叫5立即/两家不叫/后叫更低）
- test_paiju.js：§7/§8 结算集成扩充(大光/过庄/升级/爬坡/傍王+算奖参与/对照)、
  §6.3 扣底触发 get_bottom_account(主对×2/两连对×4/副牌不扣/庄赢不扣)
- 02-测试计划.md/README：P0 全部标记完成

全部单测 123 项断言全绿（node server/games/erqiwang/test/run.js）

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 01:03:01 +08:00
joywayerandClaude Opus 4.8 5a5165a319 二七王：制定服务端合规测试计划 
- docs/compliance/02-测试计划.md：按 design 章节的"规则→用例"覆盖矩阵
  （标注被测函数/测试层L1-L3/正反边界/覆盖状态），缺口清单按优先级排序，
  以及 L2 局内集成 / L3 RPC 层所需脚手架
- test/README.md：链接测试计划

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 00:02:52 +08:00
joywayerandClaude Opus 4.8 e31bdd854d 二七王文档：记录二次全量复核结论 + §5.4.4 修复同步 
- compliance/01：新增二次对抗性复核结论（服务端全部符合 design.md）；
  §5.4 标记全部完成、§5.4.4 已修；修正过时的 §10.1 数组下标描述
- packet_protocol.md：playproc 补 shuai_demand 字段说明

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-04 23:20:09 +08:00
joywayerandClaude Opus 4.8 dcf8e09f7d 二七王文档：同步 design 流程/协议，新增合规核对 
design.md
- 修正选主/埋牌顺序笔误（确认「先选主后埋牌」）
- 投降改为选主阶段与选主互斥的选择（不选主/不埋牌直接结算），算奖用庄家36张、无连对链
- 70分暗牌改为「庄家摸牌之前、向所有玩家亮3秒」
- 选主阶段前端显示每花色对数、70分并列投降按钮
- 新增 §12「完整牌局游玩流程」（含大局与阶段速览）

packet_protocol.md（随代码如实同步）
- 结算 aset/seatlist 新结构（multiple=基础子数、upgrade 判定倍率、bangwang/climb、
  chongguan/wang/naward/grade_aw）；shangzhuang bottomcards 按70分门控 + ancard3s
- maipai/PushCards 亮牌 liangpai；chupai info/baozhu 按查牌门控；新增 mingpai 收发包
- step 枚举去掉废弃的投降4；删除 Surrender 重连视图

docs/compliance/（新增）
- 00 初步不一致清单、01 design 合规逐节核对（含整改进度与 roomtype 位串约定）

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-04 22:34:06 +08:00
joywayer 96372d713c 规则文档理清楚，开始代码层面对比和校对 2026-07-04 09:52:49 +08:00