daoqi/erqiwang_youle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
175 Commits 1 Branch 0 Tags
637fa8fca72e303277f2625527e175cb0e418185
Commit Graph
13 Commits
Author SHA1 Message Date
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 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 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 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 4aab71e6a3 二七王：实现 S-1 curmultiple 与 S-2 mustcard 
S-1 当前抓分倍数（design §7.2.0）：
- class.paiju.js 新增 get_curmultiple()，复用 get_qvalue + get_upgrade，
  与结算 aset.upgrade 同源同算法，差别仅在不含扣底（末轮才产生）。
- 随现有包下发、不另开推送：shangzhuang / chupai1-3 / deskinfo.PushCards。
- 三家同值，整表下发不涉及泄露（捡分本就公开）；叫分未定时为 0。

S-2 跟牌必出牌（design §5.2）：
- class.paiju.js 新增 get_mustcard(seat)，内部复用与出牌校验完全相同的
  get_followcard，故建议与校验天然一致。
- 【只发给 nextseat 一家】：它是该玩家自己手牌的子集，整表下发会泄露
  他家手牌结构（server 红线：发全 ≠ 发多）。
- 四种情形不下发：非出牌阶段、该座位是本轮首家、首家甩牌、必出牌为空。
  甩牌一条尤其重要——甩牌跟牌走 flush_follow_ok 的逐分量匹配，与
  get_followcard 不是同一条路径，给建议会给错。

测试（新增 test/test_hint.js，33 checks）：
- curmultiple：算法层逐档对齐 design §7.2.0 判定表（含爬坡 Q 分段）、
  三家同值、重连与出牌包一致、叫分未定为 0、与 get_upgrade 绝对值一致。
- mustcard：只有 nextseat 收到、另两家没有、内容确属收包者自己的牌、
  首家无、缺门有富余时无、手牌数恰等于首家张数时整手必出、甩牌不发、
  非出牌阶段不发、重连按 currseat 门控。

过程中修正的两个测试自身问题（均为脚本缺陷，非业务缺陷，业务判定经证据核实正确）：
- 「缺门方无必出」原用例给闲2 只发 2 张牌，恰等于首家张数，get_followcard
  正确判定为「整手必出」；改为发 4 张才留出选择余地，并补一条对照用例
  锁住「恰等于张数则整手必出」这个正确行为。
- 「甩牌不发」「非出牌阶段不发」两条原本是假通过——桩的 startcount 仍是 -1，
  前置守卫先返回了 null，根本没测到被测因素。改为先把桩推进到跟牌态、
  每个用例只变动一个因素，并加一条「自证」用例确认推进后确实能算出必出牌。

另：mustcard 补进 test_leak.js 的 CARD_FIELDS 审计白名单（与 burycards 同理，
不加则误发不会被泄露审计发现）。反向验证：改成整表下发后，审计立刻报出
5 张越权牌；把 curmultiple 写死为 1 后，两条断言失败。均已还原、全绿。

协议文档同步 shangzhuang / chupai1-3 / PushCards 的字段说明。
至此 §7.5 服务端待补 5 条全部完成，服务端侧无遗留。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-25 20:25:32 +08:00
joywayerandClaude Opus 5 ecec44e93a 二七王：S-4 拆分 bottomcards 字段名，S-5 术语同步收口 
S-4（服务端改动）：底牌与埋牌底牌不再共用一个字段名。
- bottomcards = 底牌（发牌留桌 8 张）—— shangzhuang / ChooseMain / BuryCards，保持不变
- burycards   = 埋牌底牌（庄家埋下 8 张）—— maipai（mod.js）、PushCards（class.export.js）
- 结算 bottom.cards 未改名（分组名已表明是抠底相关），文档注明其语义

测试：
- test_leak.js 的 CARD_FIELDS 白名单加入 burycards。这一步是必须的——不加的话
  新字段会静默脱离下发面审计，闲家误收也发现不了。
- test_rpc.js 新增 11 条正反用例：庄家有 burycards 且为 8 张、庄家不再有
  bottomcards（抓改名漏改）、闲家两个字段皆无、重连 PushCards 同上。

验证（不止「跑过了」）：
- 改动前基线 16 个文件全绿；改动后仍全绿，新增后 rpc 从 89 → 100 checks。
- 反向验证一：把 mod.js 的 burycards 改回 bottomcards → test_rpc 新用例 FAIL，
  且 test_leak 报出真实泄露（赋值改了而 delete 没改时，闲家会收到庄家埋的牌）。
- 反向验证二：删掉闲家侧的 delete msg.data.burycards → test_leak 立刻抓出
  5 张越权牌，确认 burycards 确已纳入审计白名单。
两次验证后均已还原并复跑全绿。

S-5：术语同步收口。design.md / packet_protocol.md / 代码注释均已改用
「底牌 / 埋牌底牌」；compliance 三份历史核对记录有意不改（反映当时的 design
表述，下轮核对按新 design 重做）。

另：T-9 亮牌条文案暂定「x对 x主」（取 liangpai.zhupair 与 zhu，其余档位
先不渲染、协议不变）。至此 29 项待确认规格全部有结论。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-25 18:07:17 +08:00
joywayerandClaude Opus 5 ce4c972b7b 二七王：修复跟牌判定依赖客户端入参顺序（可翻转本轮胜负与结算） 
can_followcard 尾段计算 cardvalue/noflower/nopair 时用的是入参原始数组
followcards（客户端提交顺序），而 get_pairlist/get_tuolaji_list 都按降序
相邻取对。端到端实测：闲家用主拖拉机毙牌且为末轮，降序提交时闲家赢下本轮
（捡分 40、扣底 ×4），把同一手牌打乱成 [51,50,105,104] 后对子漏判、
cardvalue 归 0，变成庄家赢、闲家 0 分大光、不扣底——同一手合法牌仅靠数组
顺序就能翻转胜负、捡分归属与最终结算，同源问题还能抹掉 noflower 缺门标志
污染 §9 下发给全场的牌况表。

改为在 min_ary_deduct 削减 _followcards 之前另存完整排序快照 _sortfollow，
尾段 8 处全部改用它（_followcards 会被削减、不可复用）。

顺带给 get_disbandRoom 加空守卫：平台在 makewar 后立刻置 battlestate=1，
而首局是延迟 1 秒创建的，这段窗口内解散会在 curr_paiju() 的 undefined 上
解引用抛异常、打断平台解散链路；现返回 null 走平台既有的「不带 deskfree」分支。

补 8 条回归（入参顺序无关性 5 条 + 端到端 1 条 + 解散空守卫 2 条），
已用「回退修复 → 用例转红」反验有效性；全套单测 401 项全绿。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-23 12:18:04 +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 84774fa525 二七王：修正重连出牌历史 pushlist 的结构与排序 
get_deskinfo 的 PushCards.pushlist 排序段有两处错：

1. 内层循环上界误用 pushlist.length（轮次数）当座位数。轮次 >3 时
   会给内层数组写入下标 3..轮次-1，把本应恒为 3 个座位的数组撑成
   轮次长度并填满 undefined；轮次 <3 时又漏排后面的座位。实测 5 轮
   时内层长度变成 5 且含 undefined。
2. 排序传的是上一个 for 循环泄漏出来的 pai.flower。循环结束后 pai
   指向牌表最后一张（大王，flower=5），等于按「无主牌花色」排序，
   主牌不会排到副牌前面。

改为内层固定 3 个座位、按 paiju.flower 排序，并对缺失轮次加守卫。

test_rpc 新增 4 项：轮数、内层恒 3、无 undefined，以及排序判别用例
（seat0 同轮出「主5 + 副♥A」，主5 必须在前——旧代码下 副A 会排前）。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-12 04:18:30 +08:00
joywayerandClaude Opus 5 20b5425a65 二七王：下发面 multiple 按房间「爬坡」开关取值 
arith.get_multiple_bycall 写死 get_base_bycall(call, false)，被
mod.jiaofen（jiaofen/shangzhuang 两个包）与 export.get_deskinfo
的叫分/选主/埋牌/出牌四个阶段共 6 处使用，且都不传 roomtype。

后果：爬坡房里对局全程界面显示的是常规算子子数，与结算包
aset.multiple 不符。例如叫 45 分，界面显示 6 个子、结算按
design §7.3.1 实际是 7 个子。违反 server dev-guide「服务器权威 +
每个下发包必须携带前端界面所需的全部核心数据」与 engineering
SSOT（同一业务数据只有一个计算处）。

移除 get_multiple_bycall 这层写死 climb=false 的兼容包装，全部
改为直接调 get_base_bycall(call, cfg.climb)，cfg 由
class.config.parse(o_room.roomtype) 得到——与结算处
get_paiju_account 用的是同一个取值入口。get_deskinfo 内顺带复用
同一份 cfg，去掉 PushCards 分支里重复解析 roomtype 的调用。

test_rpc 新增 7 项：叫 45 分在常规房/爬坡房分别驱动到上庄，断言
上庄包与重连 ChooseMain 的 multiple 为 6/7，并与结算包
aset.multiple 逐一对齐。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-12 04:16:42 +08:00
joywayerandClaude Opus 4.8 60271175d6 二七王：逻辑文件补双运行时守卫，解锁 Node 单测 
按 dev-guide 01 §1「一套代码，两个运行时」补齐 erqiwang 缺失的守卫（此前只支持友乐全局加载模型）：
- 顶部：跨模块依赖走 `if (typeof require!=='undefined') var X=require('./class.X.js')`
  （config/pai/arith 无跨模块依赖；paiju 依赖 arith/config/pai；desk 依赖 paiju；export 依赖 arith/config/desk）
- 底部：`if (typeof module!=='undefined') module.exports = cls_X`
- export/import 的平台接线 `youle_erqiwang.X=...` 加 `typeof youle_erqiwang` 守卫，Node 无此全局时跳过

纯增量：友乐无 require（浏览器模型），守卫全部跳过、全局名仍无条件暴露，线上行为不变；
仅在 Node 下额外启用 require/module.exports，从而可用 node 直接单测。min_*/youle_erqiwang 等平台全局仍按全局名引用（Node 侧由测试 shim 提供）。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-04 23:51:12 +08:00
joywayerandClaude Opus 4.8 6120580505 二七王服务端：按 design.md 整改结算/算奖/甩牌，roomtype 改位串 
结算与算奖（§6.3/§7/§8）
- 扣底倍数改线性：单张×1、主对×2、N连对×2N
- 算子实现常规算子 + 爬坡两套（大光×3、Q=40 / 爬坡分段），X=基础子数×判定倍率
- 常规算奖只计庄家；连对链修复（传实际主花色）；移除 ≥10 老主误加奖与设计外的
  「冲关必叫/四王必踢」作废；算奖快照取庄家埋牌后28张（新增 get_seat_cards_award）
- 算奖并入结算改为 X×(2Ni−Nj−Nk)；傍王按房间开关、庄闲每王1奖

出牌与甩牌（§5.4）
- 副牌绝对禁甩；甩牌最大性按对手全部手牌逐分量判定（新增 trump_rank/
  decompose_trump/opp_can_beat_flush）；甩错惩罚（收回、只打最小一张、下发 shuaicuo）
- 修复 can_followcard 引用未定义 tuolaji_list 的崩溃、can_playcard 14张上限失效

开局/投降/暗牌（§4）
- 投降改为选主阶段(step2)与选主互斥、不埋牌、算奖用庄家36张；埋牌后直进出牌(删废弃step4)
- 70分暗牌摸牌前向所有玩家亮3秒(+ancard3s)，非70分不再泄露暗牌给闲家；叫分上限≤70

查牌/亮牌（§8.2/§9）
- 新增亮牌 get_liangpai（庄家埋牌后28张按阈值统计）；报无主统计与亮牌按查牌位门控
- 新增 mingpai 明牌 RPC（可查牌+已报无主时查看他家全部主牌）

房间与配置（§10）
- 局数6/12、房主扣卡2/4；新增 class.config.js 以位串解析 roomtype（唯一入口 SSOT）
- 清理 do_choiceflower 死代码

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