  joywayerandClaude Opus 5
|
dac4a94b38
|
二七王：夹具补甩牌样本，重连恢复 baozhu
导出脚本原来全出单张，单张一手无所谓顺序，服务端两个顺序口径的分岔
在夹具里永远测不出来。改出牌策略（种子不变）：首家优先合法甩牌 → 领
最大的一对 → 最小单张；跟家凑合法跟牌；提交时刻意反转成升序，模拟真实
客户端的点击顺序，把「下发顺序是否被请求顺序污染」暴露出来。
中段 step5 快照锚点从 1 个加到 5 个——开局那三张快照的 pushlist 还是空的，
只有打到一半的快照才真的比对到出牌历史。
重导结果：51 手出牌，一手多张 30 手、合法甩牌 4 手，deskinfo 快照 18 张，
仍覆盖 step 1/2/3/5/6；连跑两次逐字节相同。
该样本在修复前使 test_consistency 5 个比对点转红，修复后全绿。
前端 ResyncHandler 补上 PushCards.baozhu 的映射（服务端已补发），
test_resync 加正反两条断言。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-08-27 20:12:24 +08:00 |
|
|
joywayerandClaude Opus 5
|
5689ceab6f
|
二七王：重新生成夹具、BuryHandler 接住 maipai.playproc，修正甩错断言的错误映射
配合上一个 commit 服务端补发的 maipai.playproc，重新生成真包夹具（diff 只新增
三家 maipai 包各一份 round-1 初值 playproc，无其他变化）后跑一致性测试，暴露出
前端还有一处对应缺口：BuryHandler.js 组 table.playproc 时没有接 data.playproc
（PlayHandler.js 早已对 chupai1/2/3 做了同样的原样拷贝），于是「埋牌完成→庄家
首出」窗口增量路径的 table.playproc 停在上一阶段的 null。现补上，并在
test_handlers_bury.js 新增一条用例守住、用「退回修复必转红」反向验证。
test_handlers_play.js:84 的 `S.table.playproc.shuaicuo` 断言的正是此前 Fix Round 2
裁决②（本手信息收进事件载荷、不进 GameState）判定为缺陷的旧映射，playproc 改为
原样拷贝服务端结构后必然读 null 硬崩。按 task-12d-report.md §8 的裁决与建议替换：
断言改为守事件载荷（EQW_CARD_PLAYED 的 shuaicuo/order/seat/cards/count/flower/
cardtype）+ playproc 原样拷贝，强度不降——原断言只守住"甩错标志被处理"这一件事，
新断言额外多守了"本手信息不得混入 playproc"一条。
client/tests/test_consistency.js 全绿（23 checks，此前 20 绿/3 红）；
client/tests/run.js 全绿（20 脚本）；server/games/erqiwang/test/run.js 全绿
（17 脚本/675 checks，见上一个 commit）。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-08-27 19:48:54 +08:00 |
|
|
joywayerandClaude Opus 5
|
f7b87f32e8
|
二七王：重新生成真包夹具、补捕 StartWar、修复一致性测试用例间污染
服务端 8452535 改了下发面（chupai1/2/3 新增 playproc、deskinfo step2/3 新增
curmultiple、maipai 新增 seatlist、bottomcards/burycards 顺序统一），前端真包
夹具 packets.json 已过期，重新导出并逐项核对新字段存在与三处/两处顺序一致。
夹具新增顶层 startwar[]（每座位一份，结构=deskwar=deskinfo，取自 do_new_paiju
之后、jiaofen 之前的同一时刻），独立存放、不混入 seats[]，避免 packetIndex 对
齐锚点错位；test_fixture.js 补相应断言。
修复 test_consistency.js 的用例间污染：EQW_GameState.reset() 按设计不清
room.playerScores（跨局累积量），旧版增量路径从不写它，实际靠"沿用同进程里
上一次全量路径写入的残留"凑出假绿，换座位顺序或调整执行顺序就会转红。改为
每个对齐点独立起步（buildIncremental/buildFull 各自 reset），且增量路径先喂
StartWar 再喂增量包，与真实客户端时序一致，不再依赖任何隐式残留。已验证正
序/倒序跑出的 PASS/FAIL 集合逐条相同。
修完后 23 checks：15 绿、8 红。红项均已归因：3 处为任务已知的前端未接线缺口
（table.playproc 映射、table.pushlist 累积、maipai.seatlist 消费），另发现两
类同类缺口（ResyncHandler 未映射 deskinfo 新增的 curmultiple 字段、BuryHandler
埋牌后未清空 my.bottomCards），均未改动 client/js 正式代码，留给下一个前端任务。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-08-27 19:28:13 +08:00 |
|
|
joywayerandClaude Opus 5
|
e2d470d37f
|
二七王：修复夹具导出的活引用污染并引入固定种子
审查发现 C-1（阻塞）：export_packets.js 的 snap() 直接存了
class.export.js get_deskinfo() 返回的 PushCards.playproc/seatlist——这两个
字段在服务端是无拷贝的活引用赋值，脚本却在整局跑完后才统一 JSON.stringify
写盘，导致中途出牌不断原地改写这两个对象，已存的 step5 快照被事后篡改成终
局状态。修法是在 snap() 里对 get_deskinfo 的返回值套一层已有的 clone()。这
是导出脚本"延后序列化"这个用法本身的缺陷，不动 server/。
同时按裁决引入固定种子：min_random 只在 class.paiju.js 的发牌洗牌里用到，
原始实现走 Math.random()；改为在导出脚本进程内 monkey-patch 一个 xorshift32
确定性 PRNG（写法与服务端既有测试 test_flow.js 等一致），种子值 DEAL_SEED 写
成具名常量。连跑两次导出脚本，packets.json 逐字节无 diff。
test_fixture.js 补强三条断言：底牌"只发给部分座位"改为精确断言恰好1个座位；
新增 packetIndex/roomtype/step 自洽性检查；step5 快照的 playproc 回归锁直接
捕获本次的活引用污染类缺陷；deskinfo 阶段覆盖从"≥3个"改为显式钉死
[1,2,3,5,6]。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-08-27 18:35:02 +08:00 |
|
|
joywayerandClaude Opus 5
|
e61725da40
|
二七王：前端测试的服务端真包夹具
用服务端 test/_rpc.js + class.desk.js 脚手架跑一局（发牌→叫分→上庄→选主→
埋牌→28轮出牌→结算），把真实下发包按座位导出成 JSON 供前端回放。不手写假
包——测的是真实契约，协议文档写错或前端理解偏差都会在这里暴露。
_rpc.js 的 setup() 只接受已构造好的 o_paiju，不走 class.desk.js，产不出
fapai；改用 test_flow.js/test_endgame.js 的 mkRoom() 模式（D.new + 全局
youle_erqiwang.app/import 与 mod.app/mod.import 同指一个 sent 数组），两条
既有用法缺一不可。
夹具自检守住质量：覆盖 fapai/jiaofen/shangzhuang/xuanzhu/maipai/
chupai1/2/3/jiesuan 全部阶段、保留座位差异（底牌只发给部分座位）、每个下发
包都带 success。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-08-27 18:22:51 +08:00 |
|