daoqi/erqiwang_youle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
173 Commits 1 Branch 0 Tags
08c387e609d6c3b0bbe2ac76e8f91062afeb5279
Commit Graph
173 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
joywayerandClaude Opus 5 08c387e609 二七王：test_leak 门禁强化——统计量重算、豁免按字段路径收窄、覆盖投降/解散 
泄露缺陷功能正常、玩家看不出、只有抓包的人知道，所以门禁的【盲区】比一次具体泄露更值得投入。
本轮补掉四处盲区：

① 统计量层（新增）：原来只扫牌 id，seatlist 的计数、playproc.maxcard 的牌编码、curmultiple
   一个都扫不到。新增「公开账本独立重算」——只喂三家都看得见的信息（已广播的 chupai*.cards、
   chupai1 的 count/flower/cardtype、庄家/叫分/主花色，账本里没有任何人的手牌），
   算出的 maxseat/maxcard/缺门无对表/curmultiple/捡分 必须与包内值逐项相等；
   再钉死 seatlist 恒 5 项、playproc 恒 10 个键，防止有人新加一项统计而门禁照样全绿。
   报副格（design §9 的有意公开）单独做门控断言：没人报无主之前必须还是 [-1,-1]。
   反向验证 5 组（塞第 6 项统计 / 提前填报副格 / 按真实手牌点亮已有缺门格 /
   maxcard 混入余主数 / curmultiple 混入余主数）全部转红。

② 埋牌底牌豁免：从「按 rpc 整包放行」收窄为「按字段路径 bottom.cards + step===6 + result!==3」。
   为此 collectCards 改为同时记录牌 id 的字段路径。对照实证：构造「给解散路径也带上 bottom」，
   新规则转红、旧规则静默放行。

③ 投降 / 解散两条结算路径此前零覆盖（9 局全是正常打完），各补 2 局并加覆盖下限断言。
   审计未发现新泄露；唯一需放行的是「算奖明细 aset.seatlist[].cards」——投降/解散时牌一张没打，
   他家的王/冲关牌会随算奖明细发给三家。这是既有行为（算奖需向三家自证、局已终止），
   写成带理由、带命中计数（awardExempt>=1）的显式豁免，不让它落在扫不到的盲区里。

④ 措辞更正：上一轮把「给重连包补上豁免」记成"收紧"，实际净效果是放宽（旧放行面 ⊂ 新放行面），
   注释已改成准确说法。

覆盖量：3141 个下发面 / 38619 次可见性判定 / 103175 次统计量重算比对。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 22:07:15 +08:00
joywayerandClaude Opus 5 8e0c8fdc90 二七王：接上 SubGameHooks.DeskInfo（中途进桌），复用重连的重画路径 
平台 07_Desk.js 在「牌局已开始 + 走加入房间而非重连」时调 Game_Modify.DeskInfo(_msg.data.deskinfo)，
该 hook 此前只有注释占位，整份 deskinfo 被 02 转发壳静默丢弃、界面全空且不报错。

裁剪核实（读平台源码）：两条路径的 deskinfo 都出自 server_room/class.return.js——
进房走 self_join_room 的 get_deskinfo(o_room, o_player.gameinfo.seat)，
登录走 self_login 的 get_deskinfo(o_player.gameinfo.o_room, o_player.gameinfo.seat)，
同一个函数、同一个「本人座位」入参。底牌/埋牌底牌只给庄家、亮牌只给闲家、mustcard 只给轮到那家
等可见性裁剪对中途进桌一样生效，不存在「拿到别人视角」的问题，接线安全。

test_hooks 新增 4 条断言，含「同一份 deskinfo 分别喂 DeskInfo 与 Reconnect，snapshot 逐字段相同」。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 22:06:53 +08:00
joywayerandClaude Opus 5 f8a154ff7a 二七王：result.chupai 移出 GameState，本墩结果改走 EQW_TRICK_END 事件载荷 
谁最大、这墩闲家得几分是【一次性表现】（收牌动画、得分飘字），任何 deskinfo 都不下发它，
写进 GameState 就多出一处「只活在前端、服务端不知道」的对局态——出牌中途断线重连即归零，
违反红线「丢弃 this.data、仅凭最近一次服务端快照重画，界面必须一致」。

三处一起改，缺一不可：
- PlayHandler chupai3：删 result.chupai 写入，改随 EQW_TRICK_END 下发 {seat,cards,maxseat?,grade?}；
  aset.grade 的累加保留（它有服务端来源 PushCards.grade / chupai3.grade，是镜像量）
- ResultHandler：_apply 的 map 删掉 chupai。收尾墩不发 chupai3、整包换成 jiesuan，
  不改这里则删 EXCLUDE 后必转红。收尾墩改为与 chupai3 走同一对事件、同一份载荷字段
  （补 emit EQW_TRICK_END 并带上 grade），否则最后一墩的得分没有出口
- GameState：删掉 result.chupai 字段本身（声明 + reset），不留永远为 null 的死字段

test_consistency 的 EXCLUDE 随之删到只剩 table.ancard3s 一条，27 checks 仍全绿；
该条改注释标明「当前夹具（65 分坐庄、单局）无法触发，此条未经验证」，不假装它在守什么。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 22:06:41 +08:00
joywayerandClaude Opus 5 b9a423071b 二七王：Balance.readystate 改为深拷贝下发，扩展深拷贝守卫测试 
o_desk.prepare 是 do_prepare 就地置 1、do_new_paiju 就地重建的活数组，
整根挂进 deskinfo.Balance.readystate 会让「已发出的包」随后续准备操作被回改。
与 get_playproc / get_seatlist / get_pushlist / get_bottomcards 同一条标准，改为下发副本。

test_rpc 扩展既有的深拷贝守卫：正面（内容逐格相等）+ 非空转（活数组确实变过）
+ 反面（已发出的包不被回改、改副本不影响本体）。反向验证：去掉 .concat() 后两条断言转红。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 22:06:26 +08:00
joywayerandClaude Opus 5 8b2cfdaf27 二七王：前端删掉 9 处阶段/控制权推导，一律读服务端包字段 
I-3 前端不再持有对局状态机（配合服务端上一提交的下发面补齐）：
- 删掉 5 处按 rpc 名硬编码的 aset.step（Deal=1 / Call=2 / Main=3 / Bury=5 / Result=6），
  一律改 _apply 读包里的 step
- 删掉 4 处 turn.seat = aset.banker（CallHandler / MainHandler / ResyncHandler×2），
  增量路径读 nextseat、重连路径读分组里的 seat；同一条规则不再有 4 个写入处

I-2 ResyncHandler._applyBalance 由只接 aset 扩为接 aset/bottom/account，
结算面板开着时重连/硬刷新不再丢抠底明细与末局大结算。
一致性测试 EXCLUDE 随之从 4 条收缩为 2 条（去掉 result.bottom / result.account，
只留一次性事件 table.ancard3s 与归下一轮的 result.chupai），未新增任何豁免条目。

夹具按新包结构重跑（种子不变，牌局不变）：diff 纯为 67 行新增字段、0 行删除；
test_fixture 补上 step/nextseat/Balance 同源断言（68→82 checks）。
export_packets.js 里关于 playproc/seatlist 活引用的注释已过时，更正为仍存在的
Balance.readystate 与三份结算快照。

各 handler 单测补齐新字段并新增守卫用例：刻意构造 nextseat != banker、
step 为非预期值的包，使「退回硬编码/banker 反推」的写法必然转红（11/11 已验证）。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 21:31:20 +08:00
joywayerandClaude Opus 5 5d981a722e 二七王：I-3/I-2/M-2 服务端补齐阶段·控制权·结算重连下发面 
I-3 阶段与控制权改由服务端唯一维护并逐包下发：
- fapai / jiaofen / shangzhuang / xuanzhu / maipai / jiesuan 各补 step（取自 o_paiju.step）
- shangzhuang / xuanzhu 补 nextseat（控制权 = o_paiju.banker，选主/投降/埋牌均只由庄家做）
- deskinfo 的 ChooseMain / BuryCards 各补 seat（控制权，与增量推送 nextseat 同源同值）
- 各下发点的真实值先用探针跑真实一局逐个核实；顺带发现 shangzhuang.data.seat 是
  最后一个叫分者而非控制权（本局实测 2 vs 庄家 0），故控制权另起名 nextseat
- get_paiju_account 统一把 step 置 6：解散结算此前无人推进 step，包里给不出诚实的阶段值

I-2 结算阶段的重连包补发抠底明细与大局结算：
- get_paiju_account 末尾一并冻结 tmp_jiesuan_bottom / tmp_jiesuan_account
- get_deskinfo case 6 的 Balance 据此补 bottom / account，与 jiesuan 推送同源同值、
  门控一致（投降/解散无 bottom、非末局无 account）；新局开始时三份快照一并清除
- 修复「结算面板开着时断线重连/硬刷新 → 抠底明细与末局大结算空白」

M-2 seatlist 不再以活引用挂进下发包：
- 新增 get_seatlist() 深拷贝快照，maipai / chupai / deskinfo.PushCards 三处改用它

测试：test_rpc 新增 I-3/I-2/M-2 三节（131→166 checks）、test_desk 新增 fapai
阶段与控制权用例（6→10）；全部新增守卫已逐条做「退回修复必转红」反向验证（15/15）。
test_leak 的可见性规则同步收紧到「本局结算(step6)后埋牌底牌才全场公开」，
并修掉一处把阶段写死成 step5 的报错文案；整局泄露审计仍全绿。
协议文档同步补充上述字段说明。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 21:30:56 +08:00
joywayerandClaude Opus 5 cfa0409d94 二七王：CLAUDE.md 补记断言反向验证与 CRLF 脚本改写注意事项 
两条都是本轮开发中真实踩到的：
- 新增守卫断言若不做「故意破坏→看是否变红」，可能加的是空转断言；
- 仓库为 CRLF 行尾，脚本化改写用 `\n` 匹配会一行不改却静默成功，
  曾据此差点得出「测试抓不住原缺陷」的错误结论。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 21:07:15 +08:00
joywayerandClaude Opus 5 af779f473a 二七王：C-1 修复 room.mySeat 永远为 -1 
平台 12_Logic.js 在第 389 行调 Game_Modify.appStart()，而 C_Player = new Player(-1)
要到同函数第 480 行才执行，此刻 typeof C_Player === 'undefined'，appStart 整体空转；
之后玩家登录 SetSeat 拿到真座位，appStart 再也不会被调用。于是 mySeat 永远停在 -1：
发包带 seat:-1 被服务端 check_player 全部拒绝、StartWar 差异化下发认领不到本座位而
整包丢弃、SeatMap.toDisplay(-1) 抛错——且全程无一处报错。

- 新增 SubGameHooks._syncMySeat()：room.mySeat 的唯一写入处（SSOT），幂等、
  座位非法或 C_Player 缺席时保持原值不倒退
- 在 setRoomDes / StartWar / Reconnect / ReconnectNoMakewar / appStart 各调用一次，
  不赌「所有路径都经过某一个入口」
- 新增 SubGameHooks.changeSeat 并同步座位：Desk.change_seat 是唯一「座位中途变化
  且不重走 setRoomDes」的路径，漏掉会让 mySeat 静默过期
- Rpc._seat() 改 fail-fast：座位非 0/1/2 即抛错，不再无声透传 -1
- 新增 client/tests/test_appstart_timing.js：复刻平台真实初始化时序，
  全程不直接赋值 mySeat；已反向验证（退回 6 个调用点后核心断言转红）
- test_rpc_send 补座位非法抛错断言；test_consistency 删除空转的 my.mustCard EXCLUDE

client 23 脚本全绿，server 17 脚本 / 680 checks 全绿。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 21:05:46 +08:00
joywayerandClaude Opus 5 22e43cf2e6 二七王：平台接线与加载段 
SubGameHooks 只解包转交、不写业务：_ReceiveData 收到的是完整包，
按 rpc 分发；Free 的参数是平台已取出的 deskfree、可能为 null；
appStart 只记座位与房间选项，UI 初始化留给 C 阶段。

index.html 里 handler 排在 Dispatcher 之前——后者注册时要引用全部 handler。

另加 test_index_load_order.js：按 index.html 实际 script 顺序自动加载
codes/ 全部文件 + 3 个框架依赖，验证顺序无遗漏、无环，并断言
EQW_Dispatcher 路由表确已注册，作为长期守卫。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 20:16:45 +08:00
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 4508fe005f 二七王：出牌顺序收敛为唯一口径，重连包补发 baozhu 
同一份数据「这一手打出的牌」此前有两个顺序口径：chupai*/playproc.cards
回显客户端请求原序，重连包 pushlist 则从 playround 反查后自己再排一次序。
一手多张（甩牌/对子/拖拉机）时两者必然分岔；同编码的一对牌更是排序都
区分不了，靠"两处各自排序"永远收敛不了。

改为单一写入处：
- 新增 order_playcards()，do_playcard 入口归一化一次（顺带隔离
  can_playcard 的原地排序，不再就地改写 pack.data.cards）
- 新增 paiju.playhistory，出牌当场归档；新增 get_pushlist() 只做深拷贝
- class.export.js 删掉整段反查+重排，改为直读归档
- do_playcard 三个分支都给 re.cards，mod.js 去掉回落到入参的兜底

顺带修复重连包漏发 baozhu：它是余主公示与明牌按钮的开关，此前只在
chupai 包里给，报无主后重连按钮会凭空消失。现与 chupai 同源同门控下发。

协议文档新增 §0.6「一手出牌」的顺序口径，并补 PushCards.baozhu 字段。
测试：pushlist 一节改为真实链路驱动（一手多张 + 乱序提交），断言升级为
「重连每一手与当时的 chupai.cards 逐元素相等」；三处修复均已退回验证转红。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 20:12:03 +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 cdf2bc730e 二七王：maipai 补发 playproc（增量路径与重连路径对齐） 
前端一致性测试剩余 3 红的根因：do_burycard() 内部已调 new_playround 初始化好
round-1 的进行态，但 mod.js 组 maipai 包时没有放 playproc（协议 §9 字段表也没有），
「埋牌完成 → 庄家首出」这段窗口增量路径 table.playproc 为 null，重连路径却已有初值——
与上一个 commit（8452535）给 maipai 补 seatlist 是同一个窗口、同一条理由，被漏在了同一处。

修法：复用既有的 get_playproc() 快照函数（与 chupai1/2/3、PushCards.playproc 同源，
本身就是逐字段深拷贝，不引入活引用风险）。可见性：此刻一张牌未出，round/start/currseat
等全部由桌面公开信息推出，cards 全空、shuai_demand 为 null，不含私密信息，故与
chupai1/2/3.playproc 一样三家整体下发、不受查牌模式门控。

协议文档 §9 同步补字段说明。test_rpc.js 新增 5 checks：庄闲同值、与重连快照比对、
round-1 初值断言、不查牌模式下仍恒有、深拷贝守卫；已用「退回修复必转红」反向验证
（3/5 转红）。既有 121 checks 未改一条断言，全绿（17 脚本 / 675 checks）。未涉及 shared/。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 19:46:32 +08:00
joywayerandClaude Opus 5 729128aa9d 二七王：前端 handler 六处下发面漏读/错读修复（增量路径对齐重连路径） 
一致性测试（同一局真包：逐包增量回放 vs 一次性 deskinfo 重连）暴露的六处前端缺陷：

① PlayHandler：table.playproc 由「字段映射错误」改为原样拷贝
   原实现把这一手的 seat/cards/count/flower/cardtype 灌进 playproc，而服务端 playproc
   是本轮进行态（round/start/currseat/.../cards），两者几乎无交集、撞名的 cards 语义还相反。
   服务端已在 chupai1/2/3 补发 playproc，前端零推导直接镜像，不自行累积 round/maxseat。

② 本手信息改走 EQW_CARD_PLAYED 事件载荷，不进 GameState
   {order, seat, cards, count?, flower?, cardtype?, shuai?, shuaicuo?}，带 ? 的缺字段不兜底。
   落牌是一次性表现而非对局状态；新立 GameState 字段只会再制造一处增量/全量不一致。

③ PlayHandler：table.pushlist 逐手落盘、按轮归档（GameState.pushPlay）
   chupai1 开新的一轮、2/3 落进当前轮，任意时刻都与 deskinfo 的全量重建相等（服务端
   pushlist 含进行中的当前轮）。不读 chupai3.playproc.cards——那是下一轮的进行态（协议 §13）。
   仅可查牌模式累积，与服务端同一道门控，否则不查牌房会凭空攒出重连没有的历史。

④ ResultHandler：归档收尾轮（最后一手走 jiesuan.chupai，不发 chupai3）
   夹具实证 chupai1×28 / chupai2×28 / chupai3×27。jiesuan.chupai 只有 seat/cards/maxseat。
   归档随即被结算收敛清空（deskinfo step6 不带 PushCards），但 emit 同步，落牌表现在清空前取值。

⑤ BuryHandler：接住 maipai 新增的 seatlist（此刻为全初值，界面无差别但重连侧有）

⑥ ResyncHandler 的 ChooseMain/BuryCards 补映射 curmultiple（原重连重建为 0，抓分角标掉档）；
   BuryHandler 埋牌完成后清空 my.bottomCards——底牌上庄时已并入手牌，埋牌后只剩 burycards
   有意义，deskinfo 的 PushCards 不下发 bottomcards，重连重建恒为 []（语义已逐条核实）。

一致性测试 8 红 → 3 红。剩余 3 条同源：服务端 maipai 漏发 playproc（与本次服务端补发
seatlist 是同一个窗口、同一个理由），前端无法自补且不得伪造，详见报告 §7 待裁决。
另有 test_handlers_play.js:84 断言的正是 ① 修掉的错误映射，按纪律未改测试，见报告 §8。

未触碰 server/、client/tests/（含夹具与 EXCLUDE）；服务端 29 checks 全绿。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 19:41:48 +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 84525359fc 二七王：服务端下发面四处缺陷修复（增量路径与重连路径对齐） 
前端一致性测试（同一局真包：逐包增量回放 vs 一次性 deskinfo 重连）暴露的四处
服务端缺陷，均属「同一份数据两条路径给的不一样 / 有一条根本没给」：

① chupai1/2/3 补发 playproc（本轮进行态）
   与 deskinfo.PushCards 共用新增的 get_playproc() 快照函数，结构取值完全一致。
   playproc 是全程复用的活对象（new_playround 就地重置），故快照做逐字段深拷贝，
   避免已发出的包被后续出牌回改。可见性：全部字段由桌面公开信息推出，
   与既有 PushCards.playproc 一样三家无差别下发。

② deskinfo ChooseMain(step2)/BuryCards(step3) 补发 curmultiple
   与 shangzhuang 推送同源同值；此刻一张牌未出、捡分恒 0，必为 +3(大光)。
   原先重连重建为 0，顶部「抓分」角标掉档。

③ maipai 补发 seatlist
   与 chupai/PushCards 同一张表、同一道查牌模式门控；埋牌完成时为初始化空表。

④ bottomcards / burycards 收敛到单一权威源（SSOT）
   - burycards：maipai 原样回显了客户端请求包里 cards 的顺序，改取 get_burycard()
     权威快照，与 PushCards.burycards 同一函数。请求包只承载「意图」，其顺序不可信。
   - bottomcards：get_bottomcards 按「调用时的 flower」排序，导致上庄推送(flower=-1)
     与重连 BuryCards(flower 已定) 两种顺序。底牌是选主【之前】就翻给玩家看的、
     发牌结束即固定的快照，故改为发牌时算一次并冻结，get_bottomcards 返回其副本
     （order_cards 是原地排序，交出本体会被调用方就地重排）。三个调用点无需改动。

协议文档同步 7 处（新增 playproc/seatlist/curmultiple 字段说明与两处排序口径）。
新增 test_rpc.js「下发面一致性」用例组 21 checks，含 28 轮真实牌局逐包逐座位比对
（249 次、0 不一致）与深拷贝守卫；每条均已用「退回修复必转红」反向验证。
既有 649 checks 未改一条断言，全绿（17 脚本 / 670 checks）。未涉及 shared/。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 19:17:09 +08:00
joywayerandClaude Opus 5 c4c061b0e1 二七王：修复三处前端漏读（Task 12 一致性测试 Fix Round 1 · 类别 A） 
一致性测试发现的 8 处不一致中，分诊出 3 处确属"deskinfo 里有、增量 handler
没读"的前端缺陷，本次修复：

- room.playerScores：reset() 不再清空，改为跨局保留字段；ResultHandler 从
  jiesuan 的 aset.seatlist[i].score（协议 §14「累积得分」）回填，避免一局
  中段（fapai 后至 jiesuan 前）总积分持续为空。
- call.currcall/call.calls：CallHandler.handleShangzhuang（step1→2 转场）
  清回默认值——deskinfo 从 ChooseMain 起就不再带 CallRun，这两个叫分过程量
  该阶段起无意义。
- ResultHandler._applyResult（jiesuan/解散共用）补齐结算清场：把 aset.*/
  turn.*/call.*/table.*/my.bottomCards/buryCards/cards 清回 reset() 默认值，
  与 deskinfo step6 只应用 Balance 分组时的重建结果对齐；顺带清掉出完最后一张
  牌的座位因 jiesuan.chupai 不带 cardsinhand 留下的幽灵手牌。

发现 3（curmultiple）、发现 6（seatlist 窗口期）判给服务端，发现 4/5
（table.playproc/pushlist）待裁决，均未改动。test_consistency.js 由 9
PASS/14 FAIL 转为 14 PASS/9 FAIL，EXCLUDE 白名单未改一字。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 18:57:54 +08:00
joywayerandClaude Opus 5 33c18a2c17 二七王：增量 vs 全量一致性测试（B 阶段核心验收） 
把前端红线「视图 = f(服务端快照)」变成可执行断言：按序喂推送包累积出的
GameState，必须与同一时点 deskinfo 全量重建的完全相等。

不一致只有两种可能，都要修：前端私存了服务端不知道的状态，或服务端漏发了字段。
EXCLUDE 白名单只收「一次性事件」与「重连不重放」两类，每条都写明理由。

本测试当前保持失败：比对发现了 7 处前端 handler 缺陷（含 table.playproc 字段
结构与协议不符等高优先级问题）与 1 处疑似服务端下发顺序不一致，均未在本次
改动中修复，详见 task-12-report.md，留待裁决。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 18:48:08 +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
joywayerandClaude Opus 5 a5ca3bc5d9 二七王：重连与开局 handler，路由表注册齐全 
重连即重画：断线重连与硬刷新复用同一条路径（填 GameState → emit RESYNC_ALL），
不为重连单写一套渲染。deskinfo 按 step 分组填充，重连不重放 70 分开底那类
一次性事件。StartWar 支持差异化下发，按本座位取自己那份。

路由表 12 条注册齐全，test_dispatcher 的完整性断言随之转绿——
漏接一个包就会红。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 18:15:04 +08:00
joywayerandClaude Opus 5 e8fc3a9bfa 二七王：结算与解散 handler 
三种结算来源组成不同（正常出牌 / 投降 / 解散），共用一套落地逻辑：
有哪组写哪组，缺的保持 null。

解散走平台的 Game_Modify.Free 入口而非收包分发表——它的 route 是 room，
被平台分流走了。取值路径因此比协议文档少一层，且参数可能为 null
（首局发牌前解散），已覆盖。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 18:09:06 +08:00
joywayerandClaude Opus 5 070ff37db1 二七王：明牌、提示、准备 handler 
明牌数据进 GameState（面板可反复开关查看）；提示不进——它是一次性通知、
不是对局状态，重连也不重放，存下来只会变成幽灵数据，故只随事件带出。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 18:04:33 +08:00
joywayerandClaude Opus 5 47c8a27d0d 二七王：补全出牌 handler 测试里 chupai3 各用例的 turn.seat 断言 
三条 chupai3 用例（不带 grade 那条、跨包累加的两条）之前都带了 nextseat
字段却没验证它，读起来像遗漏，也让"chupai3 同样会推进控制权"这件事只被
验证了一次。补齐后四条 chupai3 用例均验证 turn.seat；跨包累加的两条从
turn.seat 由 0 变 1，顺带证明了第二个包确实被处理，不只是看 grade 一个数字。

只改测试文件，PlayHandler.js 未改动。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 18:01:56 +08:00
joywayerandClaude Opus 5 5a77e4b132 二七王：修正出牌 handler 注释并补强 grade 累加与 nextseat 测试 
审查发现简报本身两处缺陷：
1. grade 累加测试断言力不足，无法区分"累加"与"仅在字段存在时赋值"两种
   实现——补一条跨包连续收两个 grade 的用例（10 再 15，断言最终 25）钉住
   累加语义。
2. chupai3 实际也带 nextseat（服务端在 switch 前统一设置三个包），简报
   注释误写成"chupai1/2 独有"；修正文件头注释，并给 chupai3 测试用例补
   上 nextseat 与对应的 turn.seat 断言，使包结构与真实下发一致。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 17:58:42 +08:00
joywayerandClaude Opus 5 5637d63c3b 二七王：出牌 handler 
三个包字段不同：chupai1 带牌型信息、chupai1/2 带 nextseat 与 mustcard，
chupai3 带 maxseat 与本轮得分。

两个易错点已覆盖：cardsinhand 只有出牌者自己有，别人出牌时缺该字段不能抹掉
自己的手牌；mustcard 只对当前轮有效，没给就要清空，否则上一轮的建议会残留。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 17:51:36 +08:00
joywayerandClaude Opus 5 daf2708af9 二七王：选主与埋牌 handler 
选主后主牌集合变化、手牌需重排，但重排是渲染时由 core/CardOrder 现算，
不在状态里落地——GameState 只镜像不派生。

埋牌区分 burycards（埋牌底牌）与 bottomcards（底牌），两批不同的牌；
闲家无 cards/burycards 但可能有 liangpai，缺字段一律不抹已有值。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 17:46:01 +08:00
joywayerandClaude Opus 5 081130b020 二七王：发牌与叫分 handler 
fapai 是一局起点，先 reset 清上局残留（保留 mySeat 与 options）。
叫分里 0（不叫）与 null（还没叫）严格区分。上庄的 bottomcards/cards 只有庄家有，
缺字段时保持原值、不抹掉闲家已有手牌——GameState 的「缺字段不兜底」在此体现。

新增 GameState._apply 助手：按 {目标键:源键} 映射写入，源键不存在就不写。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 17:41:09 +08:00
joywayerandClaude Opus 5 01eb6c60b5 二七王：收包分发器与失败回包处理 
分发器只分发不写业务。判定顺序上先看 data.success，失败包一律先分流给
FailHandler——协议规定失败回包的 rpc 与请求同名（chupai 失败回 chupai，
成功走 chupai1/2/3），不先分流则每个业务 handler 都要自己判一遍。

未知 rpc 只警告不抛错，畸形入参不崩。路由表完整性断言留待全部 handler 就位。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 17:36:15 +08:00
joywayerandClaude Opus 5 65674542b3 二七王：补全 FORBIDDEN 列表覆盖完整协议字段 
FORBIDDEN 列表扩充到覆盖协议中服务端→客户端的全部字段名，
作为回归网防止未来在发包方法中意外泄漏服务端计算结果。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 17:32:44 +08:00
joywayerandClaude Opus 5 ff46d874c0 二七王：前端语义化发包 
route 显式写 erqiwang——RpcHelper.sendGameRpc 预设 route="room"，
用它包会被路由到平台房间模块、到不了子游戏 mod.js 且不报错。

只做形状校验（牌 id 范围/去重/张数），规则合法性由服务端裁定；
不合形状即抛错、不发残缺包。测试断言发包字段集合不含任何结论字段。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 17:28:11 +08:00
joywayerandClaude Opus 5 a82969a23b 二七王：前端 roomtype 位串解析 
与服务端 class.config.js 的 parse() 同规则；缺失/非字符串/过短一律按 '0'，
这是协议 §0.5 明文规定的行为。已逐位对照服务端确认。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 17:21:39 +08:00
joywayerandClaude Opus 5 4e79f135ce 二七王：前端事件常量与 GameState 骨架 
GameState 是服务端快照的镜像、前端 SSOT：只镜像不派生、字段名对齐协议、
缺字段不兜底。reset 清对局态但保留 mySeat 与 options（跨局不变）。
事件只带「发生了什么」，数据由订阅者从 GameState 读，避免同一份数据两处存。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 17:19:43 +08:00
joywayerandClaude Opus 5 2df7179266 二七王：前端子项目 B 实施计划 
13 个任务，每个自带 TDD 循环与提交：GameState 骨架与事件契约、roomtype 解析、
语义化发包、分发器与失败回包、五组 handler、重连与开局、服务端真包夹具、
增量 vs 全量一致性、平台接线。

自检修掉两处：Task 8 一条拿自己跟自己比的恒真断言；Task 12 引用的
fx.roomtype / snapPoint.packetIndex 在 Task 11 的夹具结构里没定义
——packetIndex 是两条路径的对齐锚点，缺了一致性测试无从比对。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 17:16:11 +08:00
joywayerandClaude Opus 5 d4de34c951 二七王：B 设计修正发包路由与解散入口 
两处对着平台代码核实后修正：

发包必须用 RpcHelper.sendRpc('youle','erqiwang',...)，不能用 sendGameRpc
——后者预设 route="room"，包会被路由到平台房间模块、永远到不了子游戏 mod.js，且不报错。

解散结算根本进不了 _ReceiveData：平台按 route 分流，room 路由交给 Net[rpc]，
只有子游戏路由才转 _ReceiveData。平台另有专门入口 Game_Modify.Free(Desk.deskfree)，
取值路径因此比协议文档少一层（deskfree.data.aset），且参数可能为 null 需容忍。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 17:05:11 +08:00
joywayerandClaude Opus 5 f63de40229 二七王：前端子项目 B（网络与数据镜像）设计定案 
架构：点击 → 语义化发包 → RpcHelper；推送 → 唯一分发入口 → 一 rpc 一 handler
→ 写 GameState → emit 语义事件。handler 不引用任何 UI 组件，故 B 可脱离 C 独立完成与测试。

GameState 只镜像不派生、字段名对齐协议、缺字段不兜底。事件只带「发生了什么」，
数据由订阅者从 GameState 读，避免同一份数据两处存。

两条核心验收把红线变成断言：增量累积与 deskinfo 全量重建必须完全相等
（即「视图 = f(服务端快照)」）；发包字段集合不含任何结论字段。
测试数据用服务端 _rpc.js 脚手架捕获的真实下发包，不手写假包。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 17:02:40 +08:00
joywayerandClaude Opus 5 8dba099717 二七王：HIST_FAN/MING_FAN maxWidth 由 490 改判定为 480，让 spacingMin 真正生效 
上一版把 maxWidth 收窄到 490 只是让 RIGHT 座位恰好贴住画布边界（零余量），且
spacingMin:-96 在 28 张时永远不触底、成了死参数。裁定改为 480：
(480-110)/27-110≈-96.30 超过 spacingMin，spacing 被截断为 -96，总宽变为
28×110+27×(-96)=488，与清单原注释「每张露14px、总宽488」精确对齐——500 是笔误，
488 才是当初想要的值。

求解器验证（count=28）：LEFT 16→504、RIGHT 791→1279、SELF 396→884，三座位均落在
0-1280 内且有余量。同步订正 Layout_Result.js 注释与清单 §6.9c 文字/数值。

client/tests/run.js 与 server/games/erqiwang/test/run.js 均全绿，精灵总数(380)/
布局节点数(83) 未变。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 09:08:48 +08:00
joywayerandClaude Opus 5 2b1dd0d947 二七王：修复出牌操作条/亮牌历史布局越界，补主牌统计条改名遗漏 
- I1：Layers.js 群组 206 改名遗漏一处注释（亮牌信息条 → 主牌统计条），全仓复查确认无第二处
- I2：出牌操作条补「提示」项后 anchor:center 导致已有两项挤偏，改用 anchor:left 并反推
  anchorX=446，令「出牌」按钮回到参考图实测 x≈556（求解器验证：446/556/748）
- I3：HIST_FAN/MING_FAN 的 maxWidth 反推算错（旧注释「488」有误，实际总宽恒等于
  maxWidth=500），导致 RIGHT 座位整排超出画布 5px；收窄为 490 使三座位求解结果落在
  0-1280 内，订正注释与清单 §6.9c 对应文字
- M3：同步修正计划文档里遗留的旧名「亮牌信息条/亮牌条」
- M6：test_constants.js 补 items[].key 的三命名空间解析守卫（此前完全无守卫）
- M5/M7：订正 ACC_ROW_TEXT_GRID 与扣底按钮宽度的估值依据说明
- M1/M2：清单 §6.9 子节重新排序为 6.9a→6.9b→6.9c 并统一标题层级，修正脚注星号误渲染

client/tests/run.js 与 server/games/erqiwang/test/run.js 均全绿，精灵总数(380)/
布局节点数(83) 两个钉死断言未变。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 09:06:01 +08:00
joywayerandClaude Opus 5 8f36b61620 二七王：补齐三处配置缺口（扣底按钮 / 出牌提示按钮槽位 / 三个 View 的布局节点） 
这三处都是「精灵或按钮已在清单里定案，但配置层缺东西」，不补的话 C/D/E 阶段
写渲染代码时会发现没有布局节点，极易就地硬编码坐标（违反零裸值红线）。

1) 底栏「扣底」按钮没有精灵（清单 §2.6 列了 5 个功能按钮，只登记了 4 个）
   - 新增 BTN_BURY_CARDS(1056) / BTN_BURY_CARDS_TEXT(1057)，群组 205 号段内空闲号，
     资源沿用 BTN_BOTTOM_FUNC，与其余四个按钮同构。
   - FOOTER_FUNC_BUTTONS 的 items 由 4 项扩到 5 项，扣底紧邻底牌（照 §2.6 表序）。
     扣底宽 78 是【估值】：清单未给，取同为两字按钮的「底牌」实测值，已在配置与清单里注明。
   - 扣底看【埋牌底牌】(burycards)、底牌看【底牌】(bottomcards)，两批不同的牌，
     JSDoc 里补了防写反的提示（对应验收清单第 13 条）。

2) 出牌阶段「提示」按钮有精灵、无布局槽位
   - PLAY_OPERATION_BAR.items 补上 PLAY_BTN_TIP，顺序照清单 §1.7 行文：倒计时 / 出牌 / 提示。
   - 宽 180 是【估值】：清单 §6.8 自身漏了该项；与埋牌条的提示按钮同资源 BTN_TIP
     （§3.3 实测 180×63），埋牌条 items 首项亦取 180，故沿用。
   - 顺带记下一处待裁定项：本条 itemHeight 为 55（对齐 BTN_PLAY 157×55），
     而 BTN_TIP 原生高 63，高度差待设计稿定。

3) AccountView / HistoryView / MingPaiView 一个布局节点都没有
   - AccountView（§6.9a 新增）：外壳 6 个节点 + 玩家栏「容器 ACC_ROW_CONTAINER +
     行节点 ACC_ROW（itemHeight 即行高，行数由 ctx.count 给出）+ 行内模板贴附到行矩形」
     + 面板外 4 按钮，共 14 个节点。行内节点求出的是相对容器的坐标，可直接喂
     SpriteCopyUtils.create（与 §5.6a 冲关牌同一用法）。
   - HistoryView / MingPaiView（§6.9c 新增）：遮罩 + 容器 + 每家一排牌(fan) + 座位标签，
     各 4 个节点。照 CHONGGUAN_FAN 同构、锚点沿用 §6.7 冲关牌的三家落点；
     差别只在张数上限——出牌历史摊平后可达 28 张以上，故 maxWidth 放宽到 500、
     spacingMin 收到 -96【估值】。MING_* 只有 LEFT/RIGHT 两个 bySeat 变体（明牌不看自己）。
   - 坐标来源：大局结算.png / 冲关牌型显示.png 目视实测，w/h 取资源尺寸；
     配置与清单里均已注明「目视实测估值，待设计稿复核」。
   - 运行时才确定的字段（动态文字宽高、随行浮动的 anchorY、数字精灵宽）一律
     runtime 显式声明。

钉死断言按实际重新数并更新：精灵总数 378 → 380，布局节点总数 61 → 83。
另把 ACC_TPL_SCORE_NUM 加进 NUM_STYLE 同源校验表（与 RESULT_SCORE_NUM 同一套资源）。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 08:40:48 +08:00
joywayerandClaude Opus 5 f982460c9c 二七王：群组 206 改名为主牌统计条，与 design §8.2 的「亮牌」消歧义 
群组 206 原名「亮牌条 / LIANGPAI_BAR」，但它的实际用途与坐标 (35,400) 对应的是
清单 §2.5「自己的主牌统计条」——手牌上方显示 x对 x主、前端本地统计、有手牌时常显。
而 design §8.2 真正的「亮牌」是庄家埋牌后向两个闲家亮出自己全部固定主牌的具体牌面，
走遮罩面板（群组 242，复用 HIST_* 精灵）。清单 §0.0 专门用一节区分「亮牌 / 余主公示 /
明牌 / 开底」四类公开信息，名字撞车极易把渲染写到错误的界面上。

统一改名（ID 一律不变，只改名字）：
- 群组   EQW_Groups.LIANGPAI_BAR   → ZHU_STAT_BAR (206)
- View   EQW_Sprites.LiangPaiView  → ZhuStatView，容器 LiangPaiBar → ZhuStatBar
- 精灵   LIANGPAI_BG/_TEXT (1030/1031) → ZHU_STAT_BG / ZHU_STAT_TEXT
- 布局   EQW_Layout.LIANGPAI_BG    → ZHU_STAT_BG
- 资源   EQW_Images.BAR_LIANGPAI   → BAR_ZHU_STAT (605)

同步清单 §0.0 / §0.3 群组表与号段表 / §1.6 / §2.5 / §3.5 / §3.6 / §5.1 / §5.7b /
§6.5 / §7.2 T-9 / §7.3 第 5 条，并在 §0.3 群组表下加修订说明（2026-08-27 + 缘由）。

一并订正清单 §1.6 的一处笔误：收到 liangpai 时应弹出亮牌遮罩面板（群组 242），
原文写的是「渲染 §2.5 亮牌信息条」——正是同名异实造成的串位。
EQW_Anim.LIANGPAI_AUTO_CLOSE 属真正的亮牌面板，保持原名，仅补注释说明归属。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 08:40:09 +08:00
joywayerandClaude Opus 5 dc08513886 gitignore 忽略 .superpowers 工作区 
多智能体执行过程的临时产物（任务简报、审查包、报告），不应入库。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 08:23:56 +08:00
joywayerandClaude Opus 5 92a8caa53f 恢复 githooks 机械红线校验 
2026-08-11「先关闭 githooks」注释掉了唯一的 exec 行，提交闸此后一直空转。
恢复前已空跑验证：暂存一个含现代语法的测试文件与一个 config 文件，
退出码 0——测试豁免生效、存量代码不被误拦。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 08:23:44 +08:00
joywayerandClaude Opus 5 b11a3f17a9 二七王：Sprites_CreateRoom.js 补 CreateRoomView 的布局说明注释 
分区标题标出 Layer（平台 27）与 Group 250，正文含 ASCII 版式图：类别竖排 ×
选项槽横排的两层嵌套，标出三个类别标题、8 组「选择框 + 文字」与房卡附注各自
对应的精灵常量与 attach 目标；另附帧号公式、roomtype 五位映射、房卡联动表、
资源说明与 @see 出处，并注明参考图是别的游戏、只借版式不借内容。

纯注释改动，数据部分一字未动（精灵总数仍 378、布局节点仍 61）。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 01:52:54 +08:00
joywayerandClaude Opus 5 6c339060bf 二七王：Sprites_Result.js 补 5 个 View 的布局说明注释 
为 AsetResultView / ChongGuanOverlayView / AccountView / HistoryView /
MingPaiView 各补一块 JSDoc：分区标题标出 Layer 与 Group，正文含 ASCII 版式图
（小局结算三家光晕与底牌算式区、冲关叠加层三家牌位与遮罩、大局结算面板的
标题栏/玩家栏/规则栏/面板外按钮条、出牌历史与明牌的三排/两排版式），
另附元素说明、关闭方式对照、资源说明、精灵 ID 分配与 @see 出处。

纯注释改动，数据部分一字未动（精灵总数仍 378、布局节点仍 61）。
如实记下三处待补：判定结果动画 D-8 无设计稿；AccountView / HistoryView /
MingPaiView 尚无 EQW_Layout 布局节点，图中坐标为参考图目视实测。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 01:51:39 +08:00
joywayerandClaude Opus 5 1644b3ebb2 二七王：Sprites_Action.js 补 5 个 View 的布局说明注释 
为 CallPanelView / ChooseMainView / OperationBarView / CountdownView /
OverlayView 各补一块 JSDoc：分区标题标出 Layer 与 Group，正文含 ASCII 版式图
（叫分面板 7×2 档位阵与单档按钮三精灵拆解、选主面板 4 花色＋投降一排、
埋牌与出牌两条操作条及其中的 CD_SELF 槽位、倒计时三处落点、浮层四类元素的
屏幕位置），另附元素说明、时序说明、资源说明、精灵 ID 分配与 @see 出处。

纯注释改动，数据部分一字未动（精灵总数仍 378、布局节点仍 61）。
如实记下一处缺口：出牌阶段「提示」按钮已有精灵但无布局槽位，待设计稿。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 01:48:23 +08:00
joywayerandClaude Opus 5 ccc41ce092 二七王：修正 Sprites_Table/Cards 注释里 ASCII 版式图的对齐 
上两个提交的三处版式图在等宽字体下右边框错位（手牌区示意框、结算底牌区
文案行、已出牌区的牌角标小图）。按「CJK 双宽、其余单宽」重排到等宽，
不改任何数据。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 01:48:14 +08:00
joywayerandClaude Opus 5 a4b12a1ebb 二七王：Sprites_Cards.js 补 4 个 View 的布局说明注释 
为 HandView / BottomCardsView / BuryCardsView / PlayAreaView 各补一块 JSDoc：
分区标题标出 Layer 与 Group，正文含 ASCII 版式图（手牌单排/双排两种形态、
底牌背面与翻正面、埋牌底牌在结算面板内的位置、三家已出牌区的镜像关系与
牌型标签/牌角标贴附方式）、元素说明、资源说明、精灵 ID 分配与 @see 出处。

纯注释改动，数据部分一字未动（精灵总数仍 378、布局节点仍 61）。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 01:39:49 +08:00
joywayerandClaude Opus 5 19f93bb96f 二七王：Sprites_Table.js 补 4 个 View 的布局说明注释 
按参考图与 UI 清单，为 TopInfoView / PlayerMarkView / LiangPaiView / FooterView
各补一块 JSDoc：分区标题标出 Layer 与 Group，正文含 ASCII 版式图（标注各区域
对应的精灵常量与实测坐标）、元素说明、资源说明、精灵 ID 分配与 @see 出处。

纯注释改动，数据部分一字未动（精灵总数仍 378、布局节点仍 61）。
顺带如实记下两处文档缺口：群组 206 的命名（亮牌条 vs 主牌统计条）与
底栏「扣底」按钮尚无精灵。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 01:37:44 +08:00
joywayerandClaude Opus 5 0c58ae67db 二七王：倒计时与结算得分改用数字图精灵，收尾几处命名与文档订正 
- CD_LEFT/CD_RIGHT/CD_SELF（1150-1152）由文字精灵改为多帧图数字精灵：
  资源 NUM_COUNTDOWN，纯秒数无后缀；对应布局节点 P_COUNTDOWN 的 h 改取
  NUM_STYLE.COUNTDOWN.charHeight，w 留到运行时注入。
- 结算得分 RESULT_SCORE_LEFT/RIGHT/SELF（1805-1807）同理由文字精灵改为
  数字图精灵（NUM_RESULT_WIN/NUM_RESULT_LOSE），与大局结算已有的
  ACC_TPL_SCORE_NUM 保持一致；布局节点随之调整，移除不再使用的
  TEXT_STYLE.SCORE_BIG。
- NUM_CALL_SCORE 第16帧由"待美术与规则确认"改为明确的"无后缀"（叫分档位
  面板只显示纯数字，"N子"角标是独立文字精灵）；NUM_MAIN_SUIT_COUNT /
  NUM_RESULT_WIN / NUM_RESULT_LOSE 第16帧仍待确认，不改。
- Layout_Action.js 的 CALL_BTN_SCORE_TEXT、Layout_Result.js 的
  RESULT_SCORE_TEXT 改名为 CALL_BTN_SCORE_NUM / RESULT_SCORE_NUM：
  两者驱动的都是数字图精灵，_TEXT 后缀误导；同步测试引用。
- docs/client/development-guide/02：订正"SpriteManager 第1154行"这一失效
  行号引用（回退后该行号落在 setTextWithWidth 体内），改为不写死行号。
- docs_dev 清单同步：§2.4/§5.4/§5.6/§6.6/§6.9 倒计时与结算得分的精灵类型
  描述、§6.6/§6.9 对应布局参数。
- test_constants.js 的 NUM_STYLE 同源守卫表新增 COUNTDOWN、RESULT_WIN、
  RESULT_LOSE 三对（连同改名后的 CALL_BTN_SCORE_NUM），共 6 条新断言。

精灵总数、布局节点总数均未变（378 / 61），只改类型与命名，不增删。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 00:54:42 +08:00
joywayerandClaude Opus 5 857bc955bb 框架：订正 setNumberImage 帧序注释的自相矛盾（1-based） 
方法头「帧序号：0-9对应数字，10='.'...」与方法体内「字母'b'-'g'→帧10-16」
互相矛盾，且均与代码实际不符：'0' 的 charCode 48 减 47 得帧1，'.'→'b' 的
charCode 98 减 87 得帧11，故正确读法是 1-based：帧1-10=数字0-9、
帧11='.'、帧12='+'、帧13='-'、帧14='x'、帧15='/'、帧16=可变后缀。
补充说明编码表故意跳过 'a'（97-87=10 会与 '9'→帧10 撞帧）的原因。
只改注释，不动一行代码。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 00:47:00 +08:00