daoqi/erqiwang_youle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
121 Commits 1 Branch 0 Tags
dbdd6607d788ebc622c619ffc56229d21c20dc84
Commit Graph
121 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
joywayerandClaude Opus 5 6ec6bdbbc2 二七王：确立「余主公示」「底牌公示」术语，核查「亮牌」冲突 
术语决策：
- A 庄家手牌达门槛后公开数量/结构 → 仍叫「亮牌」（保持不变）
- B 有人报无主后展示各家剩余主牌数与对数 → 新术语「余主公示」
- C 70 分坐庄摸底牌前向全场亮 8 张底牌 3 秒 → 新术语「底牌公示」
- 「亮主」确认为选主界面的标题文案、不是规则术语，三份文档均注明不得
  用它指代任何规则

「亮牌」冲突核查结论：无同名不同义，但有三处字面相近而语义方向相反的
读错风险——亮牌 vs 明牌（一个给数量、一个给牌面，方向还相反）、亮牌 vs
亮主（只差一字且同在庄家阶段）、亮牌 vs「亮出底牌」。故在 design 术语表、
协议 §0.0b、前端清单 §0.0 各加一张四类「公开信息」对照表，一句话口诀：
「亮牌」「余主公示」只给数字，「明牌」「底牌公示」才给牌面。

design.md：术语表新增 亮牌 / 余主公示 / 明牌 / 底牌公示 四条定义 +
易混对照表；§4、§9、§12.1 正文启用新术语。
packet_protocol.md：新增 §0.0b 术语小节；seatlist 第 5 位、ancard3s、
baozhu 三处字段说明冠以对应术语。
前端清单：§0.0 补对照表，§2.5 改名为「自己的主牌统计 + 余主公示」。

另据新图 等待庄家选主.png 抽出一个通用部件「状态提示条」（§2.8）：
深色半透条 + 居中白字，等待类（等待庄家选主…）与即时反馈类（强甩失败）
共用同一套精灵，只切位置预设与文案。原单列的 BAR_SHUAICUO 并入该部件。

新增 T-32（该图底牌仍摊着与 design §4 的先后顺序对不上，需确认）、
T-33（等待类文案清单待定）。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-25 23:04:03 +08:00
joywayerandClaude Opus 5 be06d3bf58 二七王：D-1..D-9 定稿落地，新增 S-6/S-7 两个服务端缺口 
据新参考图（大局结算.png、强甩失败提示.png）与本轮确认，设计稿只剩 D-8：
- D-1 建房：子游戏只做「类别标签 + 选项」内容区，弹窗背景/标题/关闭/确认
  由平台提供，§5.8 相应不再列弹窗外壳。
- D-2 底牌 3 秒展示：复用庄家翻开底牌那套 UI，不要倒计时；非 70 分只有
  庄家可见、70 分全场可见——同一套界面只差可见范围，故砍掉原先规划的
  独立公示面板（资源 655 与精灵 1757/1758 作废）。
- D-3 甩错：桌面中央深色半透条「强甩失败」，不做收回动画。
- D-4 报无主：不做全场提示（资源 652、精灵 1753 作废），只让他家
  主N/对N 角标出现。
- D-6 明牌 / D-7 出牌历史：版式都照算奖牌型显示.png（遮罩 + 每家一排牌），
  与算奖叠加层共用同一套渲染。出牌历史【不按轮次】，按玩家聚合并用主牌序
  排序——前端摊平 pushlist 即可，无需改服务端。
- D-9 大局结算：玩家栏用精灵复制（新增 §5.7a）。

同时更正了一处我此前的理解错误：左侧那条「主牌对子: 1对」是【自己的主牌
统计、有手牌时常显】，不是 design §8.2 的庄家亮牌 liangpai。§2.5 已重写为
「自己的主牌统计 vs 他家的报无主角标」两套并列，并指出 liangpai 目前没有
界面位置（T-30）。

新增两个服务端缺口：
- S-6（阻塞 D-9）：大局结算要显示「基础分/算奖分/傍王分」，而 account 只有
  累积得分与每局得分。傍王分尤其拆不出来——naward = 常规算奖 + 傍王王数，
  两者求和后才代入 grade_aw 公式，事后无法反推各自占比。建议把 N 拆成两个
  分量分别代入同一公式，相加应等于现 grade_aw（可作回归断言）。
- S-7（有泄露口子）：明牌按钮条件收紧为「自己是无主玩家」，与 design §9.3
  的「全体三人」及服务端 have_baofu() 校验都不一致。前端先按严格规则显隐，
  但服务端校验未改前，有主牌的玩家伪造请求仍能拿到明牌数据。

另：修复文末附录丢失——三次提交前的一个切片脚本把它挤掉了，现已按当前
状态恢复并补充 SpriteCopyUtils 一行。新增 T-30/T-31、验收清单增至 17 条。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-25 21:32:38 +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 82cfc98502 二七王：design 与协议文档统一「底牌 / 埋牌底牌」术语 
原命名与前端界面倒挂——界面上「底牌」按钮查看的正是发牌留桌那 8 张，
旧术语却把它叫「暗牌」，极易写反。现统一为：

- 底牌     = 发牌时没有发给玩家、扣在桌面的 8 张（原「暗牌」）
- 埋牌底牌 = 庄家埋牌时从手里扣下的 8 张（原「底牌」）

design.md：全文 38 处表述替换（术语表、§4 坐庄流程、§6.3 扣底、§7.1
70 分说明、§8 算奖快照、§12.1 流程、§12.3 阶段速览），并在术语表后补
「术语变更记录」说明改名缘由与协议字段尚未拆分的现状。

packet_protocol.md：新增 §0.0 术语小节置于全文之首，逐条列出
bottomcards 在哪些包里指底牌、哪些包里指埋牌底牌；相关字段说明同步改用
新术语，并在 maipai / PushCards 两处加同名不同义的警示。

字段名本身暂未改动（底牌保持 bottomcards、埋牌底牌拟改 burycards），
拆分计划见前端清单 §7.5 S-4；在拆分落地前收发两侧按包判断语义。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-25 17:58:18 +08:00
joywayerandClaude Opus 5 cfef896fd6 二七王：UI 清单统一底牌术语，细化叫分按钮，确认 S-1 语义 
术语修订（本文先行，design/protocol 待同步）：
- 底牌 = 发牌时没发给玩家、留在桌面的 8 张（原「暗牌」）
- 埋牌底牌 = 庄家埋牌扣下的 8 张（原「底牌」）
改后底栏按钮名实相符（底牌钮看底牌、扣底钮看埋牌底牌），原「术语陷阱」
一节改写为「术语已统一」。新增 §0.0 术语节置于全文之首。
全文 35 处表述与精灵键名同步（DARK_CARD→BOTTOM_CARD、
BOTTOM_CARD→BURY_CARD、ANCARD_3S→BOTTOM_3S）。

S-3 定论：底牌可见性按 design 手册办——庄家全程可看，闲家仅 70 分坐庄局
可看，其余局按钮不显示。服务端无需改动，现有下发面正好支持。

新增两条服务端待补：
- S-4 拆分 bottomcards 字段名：底牌保持 bottomcards，埋牌底牌改 burycards
  （maipai / PushCards / 结算 bottom 分组）。前端未开工，现在改代价最小。
- S-5 同步 design.md 与 packet_protocol.md 的术语，并列出待改位置清单。
  三份文档术语不一致会直接违反 SSOT，属最危险的那类分歧。

S-1 语义确认：当前捡分对应判定倍率的实时预览（大光×3/小光×2/过庄×1/
升N级×N）。要求随 chupai1/2/3、PushCards、shangzhuang 一起下发
curmultiple，不新开推送包；get_upgrade 现成可用。

叫分按钮（据更新后的 叫分按钮面板.png）：
- 配色按档位位置固定，只因不可叫变灰，不随子数变。
- 按钮底与右上角角标底画在同一张图上，4 帧。
- 叫分分数用数字精灵（新增资源 NUM_CALL_SCORE），角标子数用文字精灵。
- 每档由 4 个精灵改为 3 个。
数字口径相应从「一律图片多帧」改为分工：美术字用图片、纯数据小字用文字精灵。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-25 17:48:49 +08:00
joywayerandClaude Opus 5 5dda571250 二七王：UI 清单落实 A/B/C 组决策，新增服务端待补项 
规格确认（T-4/6/7/8/10/11/12/15/16/18/19/22/23/26 全部落地）：
- 叫分按钮配色按【档位位置】固定三档（浅黄/金黄/橙）+ 灰=已叫过，
  按钮底与角标底各 4 帧。特别标注：参考图角标 1子/2子/4子 是 mock，
  颜色不随子数变（反证：常规算子下 50~5 档同为 6 子却是两种颜色）。
- 选主大数字=该花色张数、角标=对数；手牌标记 3 帧（拖/正2正7/其他主牌）。
- 底栏功能按钮定为 5 个，新增「扣底」；并显著标注术语陷阱——底栏「底牌」
  按钮看的是【暗牌】、「扣底」按钮看的才是【底牌】，而协议里两批牌共用
  bottomcards 字段名，要求前端用 anCards/diCards 区分。
- 结算底牌文案的 x 后面是扣底倍数；牌型标签只做「毙」；准备标识用平台的；
  数字一律用图片多帧（参考图数字带描边渐变）。
- 发牌动画：从右往左铺开。算奖叠加层点遮罩关闭、并列显示奖数。
- 自己发的提示本地回显，作为悲观 UI 的受控例外并写明成立理由
  （提示不含对局状态、服务端不校验真实性）。
- T-5 手牌排序定为对齐服务端 order_cards 主牌序，选主后整体重排。

新增 §7.5 服务端待补项：
- S-1 抓分倍数字段：协议现无，出牌阶段拿不到任何倍数；服务端 get_upgrade
  现成可用，建议补 curmultiple，语义待最终确认。
- S-2 下发应选中的牌：get_followcard 已返回 mustcard，仅用于内部校验、
  未下发；建议只发给 nextseat 一家（整表下发会泄露他家手牌结构）。
- S-3 ⚠️ 底栏「底牌」按钮要求所有人可看暗牌，与 design §4「非 70 分时
  暗牌只有庄家可见」及协议下发面直接冲突；给出三个方案，确认前前端按
  最保守的 (a) 限定可见范围实现。

新增 D-13（扣底查看面板）、验收清单增至 15 条。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-25 13:25:33 +08:00
joywayerandClaude Opus 5 2c3464b6f0 二七王：UI 清单关闭 7 项待确认，补平台图层清单与验收检查表 
从平台代码/编辑器数据查证后关闭：
- T-2 解散投票：平台全包（Layer 420 CheckFree_Layer + GameUI.openCheck
  + Desk.self_apply_free_room 一族），子游戏只处理解散结算包，D-10 缩到
  只剩结算面板。
- T-3 建房图层：Layer 27 CreateRoom_Layer；Layer 28 SeniorOptions_Layer
  是代开房/抽水，与玩法规则选项无关，不走它。

按参考图算定 / 技术自决：
- T-21 手牌间距：单排 spacingMin=-78（36 张露 32px，与实测 33px 吻合），
  双排 -65。
- T-27 埋牌分行：上排 floor(n/2)、下排 ceil(n/2)；参考图 17/19 按 mock 处理。
- T-25 line 增加可选 items 支持逐项不等宽，底栏功能钮组与埋牌/出牌操作条
  改用它。
- T-17 倒计时归零停在 0 不隐藏（隐藏会被误读为已超时/已跳过）。
- T-28 EQW_Layout 为权威，配置区手工同步并列入验收。

另补：
- §0.2 增列平台已占用的 14 个图层（创建房间/解散/帮助/设置/加载/重连/
  战绩/聊天语音等），凡列出者子游戏不必重建。
- 新增 §7.3 验收检查清单 12 条，逐条对应一处已知易错点。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-25 09:01:52 +08:00
joywayerandClaude Opus 5 b85c286dde 二七王：精灵复制范围收回，仅算奖牌型一处使用 
上一次提交把复制方案扩到了建房选项、并把已出牌区列为候选，超出了
实际要求。现纠正：

- 已出牌区维持预置（28 × 3），不改复制，撤销原 T-29 候选项。
- 建房规则选项改回预置 20 个（3 类别标题 + 8 选项 × 2 + 房卡附注），
  选项集固定、数量小，不需要复制；渲染仍由 §1.1 的配置数据驱动。
- 选用判据表改为明确结论：全项目只有「算奖牌型」用复制，其余一律预置。
  精灵段有近 2000 空位，预置的 ID 开销不构成压力，不必给每处都背上
  显式清理负担。

原 T-30 顺延为 T-29。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-25 08:30:32 +08:00
joywayerandClaude Opus 5 766ef7eae3 二七王：UI 清单补冲关定义，算奖牌型与建房选项改精灵复制 
- 补「冲关」的准确定义（class.arith.js:1277 get_chongguan）：它就是
  design §8.1 常规算奖的服务端命名，不是独立规则。列出 count/wang/cards
  三个返回值的去向与计数规则，并点明两处易错：连对链必须先有 ≥3 王才
  计算；固定主牌 ≥10 张只触发亮牌、不算奖。前端不重算，一律取下发值。

- 算奖牌型叠加层改用 SpriteCopyUtils 精灵复制：cards 张数无小上限
  （四王 + 长连对链 + 八个 7 + 八个 2 可达 20+ 张），预置既可能不够又
  常年空占。编辑器只建 5 个精灵（遮罩 + 3 容器 + 1 模板），省约 19 个 ID，
  关闭 T-24。

- 建房界面按「类别标题（牌局/模式/规则）+ 选项组」重构：
  选项组分单选 / 多选 / 单选（可不选）三型，后者复用复选图；
  每个选项 = 选择框图片 + 文字精灵；选择框资源定为 2x2 四帧
  （单选未选/单选选中/复选未选/复选选中），帧号 =
  (useCheckbox?3:1)+(selected?1:0)；类别标题一张图 3 帧。
  整个界面由「类别→选项组→选项」配置数据驱动渲染，渲染代码不认识
  具体玩法名，roomtype 靠每项自带的 bit 拼串。同样改精灵复制，
  编辑器只建 4 个精灵（原预置方案需 21 个）。

- 新增「预置 vs 精灵复制」的选用判据表，并据此标出下一个候选：
  已出牌区 84 个预置精灵（T-29，需先确认复制精灵满足 z 序与出牌动画）。

- 新增 T-29 / T-30。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-25 08:23:25 +08:00
joywayerandClaude Opus 5 ddb4f7d6a2 二七王：UI 清单增补布局配置规范，并据 4 张新/改参考图更新 
新增/更新的参考图带来的确定项：
- 小局结算.png 更新：两个小字标签定为「牌局分」(grade_jf) /「算奖分」(grade_aw)，
  关闭 T-13；新增「算奖牌型」「下一局」两个按钮。
- 算奖牌型显示.png：算奖明细走独立的半透遮罩叠加层（aset.seatlist[i].cards），
  关闭 T-14。
- 自己是闲家时的踩有分没分按钮.png：提示入口 = 底栏三按钮，占用庄标区域、
  与庄标互斥；气泡资源定为 3x2 六帧，按「头像在气泡哪一侧」选箭头朝向，
  关闭 D-5。
- 创建房间选项参考图：属他游戏内容，只取视觉范式；二七王实际为 4 行
  （局数/扣卡/玩法多选/查牌），无人数行，D-1 降级为「缺定稿」。
- 左上家出牌区确认为右上家的左右镜像，关闭 D-12。

§6 由「布局坐标表」重写为「布局配置规范与配置清单」：
- 所有布局参数一律外提为配置，业务代码零裸值（工程总则 §6 / client 02 §2）。
- 定义 5 种布局器 point / line / fan / grid / attach，参数名直接对齐框架
  AlignmentUtils 的入参，配置可原样喂入、零转换。
- fan 给出唯一的自适应间距算法；bySeat 表达三个显示位的差异；
  另有 textStyle 预设与 CARD_SIZE 尺寸档，改一处全局跟随。
- 补充配置文件组织与「与平台 PLAYER_INFO_LAYOUT 坐标一致性」的衔接要求。

待办变化：关闭 T-1/T-13/T-14 与 D-5/D-12，新增 T-22..T-28。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-25 08:14:30 +08:00
joywayerandClaude Opus 5 6fc9f15976 二七王：新增前端 UI 资源与精灵清单（docs_dev）+ 归档 9 张参考图 
对照 design.md 全流程与 packet_protocol.md 下发字段，把二七王前端所需的
图片资源、声音、精灵、图层、群组、坐标整理成可执行规格书，供美术出图与
gameabc 编辑器建资源使用。

要点：
- 核实号段占用：精灵 1001-3000 段内仅 3000 被占（Spirit3000/Layer602），
  实际可用 1001-2999；图层 101-200/301-400、群组 201+、图片 501+ 全空闲。
- 牌面资源定为 10x6=60 帧通用排版（黑桃/红桃/梅花/方块 A-K + 双王 + 6 牌背），
  开大/中/小三套尺寸；给出唯一权威的 cardIdToFrame 转换与 10 条校验样例。
  服务端 flower 编号(1方块..4黑桃)与美术花色顺序相反，转换须按花色段倒序数。
- 标明平台已提供、子游戏不重建的部分（头像/昵称/分数、聊天语音气泡、
  RecordView、帮助、建房界面骨架与 25 号确认按钮）。
- 座位方向据 class.paiju.js:264 get_nextseat 定论：下家 =(seat+1)%3、显示在右上。
- 汇总 12 项待出设计稿（D-1..D-12）与 20 项待确认规格（T-2..T-21）。

ID 均为规划建议值，编辑器建成后须回填校准；坐标为参考图实测估值。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-24 22:40:44 +08:00
joywayerandClaude Opus 5 df4eefc9e2 二七王：design §4.6 修正笔误「最0号座位」→「0 号座位」，补第一局取固定座位的缘由 
规则方确认轮庄规则本身无误（开局先叫分者为暂定庄家；第一局暂定庄家为座位 0；
之后庄赢原庄、庄输下家），与 §4.2/§4.6 及代码一致，无需改动逻辑。

仅修一处笔误并补上缘由：第一局此前没有打过任何牌局、不存在「上一局的庄家」，
所以取固定座位 0。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-23 15:13:39 +08:00
joywayerandClaude Opus 5 b924b6e864 二七王：第八轮核对（流程/牌型/玩法/算分）+ 新增阶段机迁移矩阵用例 
规则方复述「开局庄家先叫分、不允许不叫分；第一局无庄家时默认座位0开始叫分」，
据此按四个维度重新取证，未发现不一致。

新增此前从未做过的取证：**阶段机迁移矩阵**。前几轮每个 handler 只测了 1~2 条
代表性失败路径，从没系统验证过「某个请求在别的阶段会不会被误放行、会不会静默
丢弃」。本轮把 8 个 RPC × 5 个阶段做成 40 格矩阵逐格驱动，全部符合：每个 RPC
只在应允阶段受理，其余一律回 STEP 失败包，无静默丢弃。

叫分起始者规则逐条取证，与规则方复述一致：
- 第一局 firstseat=0、待叫者=0
- 之后每局起始 = 暂定庄家：连打 6 局逐局比对「上局 banker + result」
- 庄赢连庄：随机对局几乎打不出 result=0，用「叫70分 + 首家出最大牌」专门构造
- 庄输/投降顺延下家
- 首家不允许「不叫」：第一局与其后每局（含连庄局）发 call=0 一律回 RULE，
  且叫分过程不变、仍轮到他自己

固化为 test/test_flow.js（7 项聚合断言，0.3s）。断言里带 cells===40，防止驱动
失败导致整行「跳过」而假绿。变异检验：去掉 chupai/maipai 的阶段校验、把 jiaofen
的阶段校验改成静默丢弃 —— 三条全部转红。

全套单测 540 → 547 项全绿。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-23 14:59:46 +08:00
joywayerandClaude Opus 5 31011e2eeb 二七王：改写 design §5.3（拖拉机相邻关系），消除自相矛盾表述 
规则复核时提出「主牌链上位置相邻的对子即成拖拉机、不限花色」，据此发现 §5.3
首句「**同一花色内**点数相邻的两个对子构成拖拉机」与本节紧接着给出的跨花色
主牌链（正7-副7-正2-副2-主A…）自相矛盾。代码实现的一直是那条链（跨花色），
首句表述是错的。

§5.3 拆成两段重写：
- 副牌拖拉机：**必须同一花色**，链 A-K-Q-J-10-9-8-6-5（7、2 是固定主牌不入链，
  故 6 与 8 相连；3、4 不在牌堆，5 是最小档）；跨花色不构成连对。
- 主牌拖拉机：只有一条完整序列，**位置相邻即成拖拉机、不限花色**——正7对+副7对、
  副7对+正2对、副2对+主A对、大王对+小王对都是合法两连对。
- 补充「同一档位的两个对子不相邻」：副7 在序列里只占一个位置，♥7对+♣7对 是两个
  平级对子而非拖拉机，副2 同理。

§1 术语表给「正2/正7」加上口语别名「主2/主7」，避免复核时来回换词。

代码无需改动（实测 14 段链全通、跨花色通、同档位不通，与改写后的表述一致）。

补 17 条用例把改写后的每条钉在**拖拉机层**——此前只测到 is_continuous（两张牌
相不相邻），没测过「这几个对子能不能真的组成拖拉机」。变异检验：主牌链改成必须
同花色 / 同档位副7对算相邻 / 副牌 8-6 去掉同花色约束，分别转红 6、2、4 条。

另：复核给出的副牌链写作「…-6-5-3」，需要牌堆保留 3；但 92 = 28×3 + 8 只有在
3、4 都剔除时才成立（保留 3 则 92÷3 除不尽、三家发不平）。经确认为笔误，维持
design §2 现状，并就地补两条断言钉住「参与发牌的牌里 3 和 4 各 0 张、共 92 张」。

全套单测 523 → 540 项全绿。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-23 14:41:41 +08:00
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 49ee068c5c 二七王：解散/重连空守卫用例改为 try/catch，避免回归时整个文件崩溃 
复检本会话修复项时发现：`解散·牌桌尚未创建 → 返回 null` 这两条用例是直接调
get_disbandRoom 的。守卫一旦被去掉，被测函数当场抛异常，未捕获时 test_endgame
在此中断，后面的「出牌入参顺序无关性」等断言全不执行——看到的是崩溃而不是
某条断言转红，定位与信号都差。改用 noThrow 包一层，异常转成可读的断言失败。

顺带补 get_deskinfo 的同名守卫用例（平台在开战前也可能回调重连）。两个守卫
都做了变异检验：分别去掉后对应断言干净转红，且文件后续断言照常执行。

全套单测 519 → 520 项全绿。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-23 14:13:20 +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 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
joywayer 685b629854 claude doctor以及规则修改，修复 2026-08-19 08:01:47 +08:00
joywayerandClaude Opus 5 b255730c1b 文档：新增「前端数据驱动架构」规范（前端无对局状态机 + 防作弊四条） 
前端的阶段/状态/显示一律以服务器为准，前端不得自建状态机、不得本地推导或推进流程；
由此推出请求包只带意图、服务端按可见性下发两条防作弊约束。

- client 05 §6 改为「数据驱动架构：服务端状态的投影」，新增 6.1 前端无对局状态机、
  6.2 视图=f(服务端快照)（丢弃 this.data 仅凭最近快照重画须一致）、6.3 本地 UI 态白名单
  （并澄清与 04 §5.6 乐观清除例外的关系）；原条目归入 6.4
- client 04 §1 新增「请求包只带意图，不带结论」；§5.3 补「不得据本地推断补齐未下发状态」
- server 03 新增 §1.3 按可见性下发（下发即泄露）、§1.4 状态机唯一在服务端并随包下发
- server 04 §4 补「前端不是数据源」；§8 新增「只接受意图入参，客户端回传结论一律忽略」
- 两份 README 红线速查与审查速查表同步补条目

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-16 20:02:55 +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
joywayer 26a52e1a11 平台框架代码更新 2026-08-16 18:46:21 +08:00
joywayer ca7352b76c 移除games2/jinxianmahjong/mod.js的加载 2026-08-12 06:08:37 +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 5 8948a2950f 二七王：chupai1 下发甩牌分量构成 shuai 
cardtype 只能表达单一牌型（1xx 单张 / 2xx 对子 / 3xx 拖拉机），而
甩牌是单张、对子、拖拉机自由混搭（design §5.4.3），会被 can_playcard
的牌型推导压平——例如「主K对 + 主5」得到 103、「两连对 + 散对」得到
203，客户端拿到 cardtype 无从还原分组，甚至看不出这是一次甩牌。

服务端本就已经算出了分量需求 shuai_demand（供跟牌逐分量强制匹配，
design §5.4.4），按「每个下发包必须携带前端界面所需的全部核心数据」
一并下发：chupai1 在合法甩牌时带 shuai = {tractors,pairs,singles}，
非甩牌与甩错退化为单张时不带此属性。

test_rpc 新增 8 项：合法甩牌带 shuai、非甩牌不带、甩错只打最小一张
且不带 shuai。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-12 04:21:11 +08:00
joywayerandClaude Opus 5 4276d38267 二七王：报无主后立即为全体三人刷新主牌统计 
design §9：「一旦有玩家的主牌全部打空，系统就为全体三人显示另外
两家各自的主牌数量、以及这些主牌里有多少对子」。

原实现只在出牌者自己出牌时更新自己那一格 seatlist[seat][4]，所以
A 打空主牌报无主的那一刻，B、C 的主牌数/对子数仍是初始 [-1,-1]，
要等各自轮到出牌才补上，界面最多滞后两次出牌才完整。

改为：出牌后先判定出牌者主牌是否出空，一旦 have_baofu() 成立，就
按各家实际手牌为三个座位统一重算 [剩余主牌数, 剩余主对数] 及主花
色标志。重算幂等——主牌一旦出空不会再有，[4][0] 恒为 0。

test_rpc 的 mkChupai 原先只把 seatlist[1][4][0] 置 0 伪造报无主，
而不真的清空 seat1 的主牌；新逻辑按实际手牌重算会把这个假状态纠
正回去，导致 baozhu 断言失败。这是新实现更严格的正确表现，故改测
试造真状态（把 seat1 的主牌标为已出），不是放宽断言。

test_input 新增 6 项：报无主前三家均为 [-1,-1]；打空瞬间三家统计
与主花色标志同时刷新到实际值。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-12 04:20:03 +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 5832b781c8 二七王：is_continuous 的 8→6 相邻补花色校验 
design §5.3 的「6 与 8 可组成拖拉机」是同花色内的相邻关系，但
is_8/is_6 只判 code % 100，不校验花色，导致
is_continuous(♥8=308, ♣6=206) 与 is_continuous(主8=1408, ♣6=206)
都返回 true。

影响面：get_chongguan 是唯一会拿整手牌（含各花色副牌）去扫描连对
链的调用点，连对链走到主 8 之后，手里任意花色的一对 6 都会被误判
为连续、多算 1 奖，并把链锚点带进副牌继续错误延伸（design §8.1
明确 A 到 5 这一段必须是选定花色的主牌）。其余调用点入参都是同花
色牌表或纯主牌表，不受影响。

改为要求牌编码相差 2（同花色的 8 与 6 恒差 2，跨花色差 100 的倍
数），并保留 is_8/is_6 守卫以免把「主A-主Q」这类差 2 组合放行。

test_arith 新增 5 项：同花色 8-6 连、三组跨花色 8-6 不连、差 2 但
非 8/6 的组合不连。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-12 04:17:32 +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 5 c2a375eef5 二七王：补齐 data.success 成败标志与失败回包 
此前全仓（除协议文档开头一句说明外）没有任何下发包携带
data.success，且所有失败路径一律裸 return、不回任何包：前端点了
没反应，只能干等倒计时，同时违反 server dev-guide「成败标志唯一
是 data.success，主动推送的 data 必须自带 success」与 client
dev-guide「发包只请求、收包才表现」两条硬红线。

本次：
- 成功包一律补 data.success=true：fapai、zhunbei（class.desk.js）、
  jiaofen、shangzhuang、xuanzhu、maipai、chupai1/2/3、mingpai、
  tishi（mod.js），jiesuan 在 get_paiju_account 统一注入（覆盖
  正常/投降/解散三种结算来源）。
- 新增 youle_erqiwang.ERR 失败码表与 do_sendfail 统一回包封装：
  PLAYER/NODESK/STEP/SEAT/PARAM/RULE，失败只回发给请求者
  （conmode/fromid 取自请求包），data.success=false + errcode。
- 每个 handler 的每条失败分支都改为「回失败包 + return」，含
  check_player 不通过（平台侧只返回 null、不回包，前端会干等）。

tishi 成功时仍按 design §11 只转发给对家、不给发送者回执（该包不
含对局状态，属 fire-and-forget 提示），失败才回给发送者。

test_rpc 中原先以「不发包」表示被拒的断言，同步改为断言「恰好回
1 个 success=false 且 errcode 正确的包」——是随行为修正而加强，
不是软化。新增 test_success.js 29 项覆盖成功包 success 字段与各
handler 失败回包。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-12 04:15:31 +08:00
joywayerandClaude Opus 5 a4a8eb8408 二七王：补齐客户端牌id入参校验（重复/越界/非数组） 
check_cards_inhand 此前只逐个校验牌id是否在手上，不查重复、不查
类型与范围，且在牌已出/已埋时 return 空值而非 false，造成两个可
被利用的缺陷：

1. 重复牌id 可伪造牌型：do_playcard([方块K,方块K]) 实测返回
   result=true、cardtype=201（同一张牌被判成一对），可进而伪造
   拖拉机与甩牌分量，本轮结算时该分牌的 score 还会被重复累加。
2. 埋牌传 8 个相同 id 实测只埋下 1 张，庄家带 35 张进入出牌阶段，
   整局牌数错乱。
3. 越界 id 或非数组入参会在解引用处抛异常，中断 DoPack。

新增 check_cards_valid 作为唯一入参校验入口（非空数组、元素为本
局牌表内的整数牌id、互不重复），由 check_cards_inhand 先行调用；
mod.maipai/mod.chupai 在读取 cards.length 之前先过该校验。按
engineering §03「显式失败优于隐式兜底」直接拒绝，不做类型兜底。

新增 test_input.js 28 项正/反/边界用例回归上述三点。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-12 04:10:15 +08:00
joywayerandClaude Opus 5 391dffc04a 二七王接入平台：在 youle/app.js 注册 games/erqiwang/mod.js 
此前 app.js 只加载了 games2/jinxianmahjong/mod.js，全仓平台侧对
erqiwang 零引用，导致 youle_erqiwang 模块从不创建、pack.route
="erqiwang" 无法命中三层路由，整个子游戏服务端运行时不可达。

按 server dev-guide README「接入新游戏还需在 server/youle/app.js
里加一行 min_loadJsFile 加载其 mod.js」补上注册（该文件是唯一允许
触碰的平台文件，属游戏注册接入点）。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-12 04:08:20 +08:00
joywayer 5c51f647d0 先关闭githooks 2026-08-11 22:18:22 +08:00
joywayer 3b7c103387 模板工程升级修改 2026-08-11 22:17:54 +08:00
joywayer 047561675b 新规hook 2026-07-06 17:16:05 +08:00
joywayerandClaude Opus 4.8 363f97cdbe 文档修复：移除指向不存在文件的失效链接引用 
client/02、client/03 中指向 docs/important/client/友乐游戏引擎精灵与资源管理接口规范.md
（该文件不在仓库）的 markdown 链接改为纯文字规范名，保留文意、去除失效链接。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 22:51:28 +08:00
joywayerandClaude Opus 4.8 f776e4c817 文档修复：校正开发指南编号与失效交叉引用 
- CLAUDE.md：前端指南编号由「01→05」订正为「01→06」（06 子游戏接入模式实存且已被本文件他处引用）；删除已过期的 server/docs 旧副本警告（该旧副本已从工作树删除）。
- 两份 development-guide README + 各章节正文：将旧路径 server/docs/development-guide、client/docs/development-guide 统一订正为 docs/server、docs/client；docs/engineering 订正为 docs/games/engineering。
- 客户端 README 阅读顺序补齐缺失的 06 篇。
- 服务端 README 移除指向不存在的 docs/important/server 的条目。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 22:39:37 +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 21e76b976a 二七王修复：拖拉机跟牌降级递归 else 分支欠约束（放行非法跟牌） 
get_followcard 降规格递归中，当某级"等长短拖拉机候选总对数 > 剩余需求"
时（class.arith.js else 分支），因 cantype 单一结构模型无法表达"任选其一
成拖拉机、其余自由"，直接返回宽松的"任意 N 对"，导致跟牌方明明有 2 连对
却被允许只出三个孤立对子（如首家 3 连对、跟牌方 AA KK JJ TT 88 66 时打
AA JJ 88），违反 design §5.2"能凑多长拖拉机就必须先凑多长"。

方案 2（根治，不引入过约束）：在 can_followcard 结构校验后新增"最大拖拉机
覆盖度"闸门 follow_tractor_cover_ok——
- tractor_run_lengths：把同花色对子按相邻拆成连对 run 长度表；
- max_tractor_profile：贪心最长优先取 K 对，得字典序最大规格档案 best；
- profile_less：跟牌自身档案 got 不得字典序劣于 best，否则拒。
仅在"跟牌整手=首家花色对子且该花色牌≥首家张数"时生效，垫/混合/对子不够
等一律放行。can_followcard 是唯一出牌闸门(paiju.js:605)，覆盖人工+托管。
get_followcard else 分支加注释指明由该闸门兜底。

回归测试：test_follow.js +5 条（303/304 三组 2 连对场景，含 else 欠约束
回归：出孤立对→拒、出尽量长拖→合法）。全套 259 项断言通过。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 07:18:42 +08:00
joywayerandClaude Opus 4.8 cab66bea01 二七王测试：固化 垫牌/混合出牌 回归用例（代码本已正确） 
对应 design.md 新成文的 垫牌(对子/拖拉机首家)与混合出牌概念。经探针
核对，can_followcard 早已让混合牌/垫牌 cardvalue=0、不争夺出牌权，
正式代码无需改。此前仅单张垫牌有覆盖、混合出牌零覆盖，现补 10 条：
- 垫：对子/拖拉机缺门出副牌散张，合法且 beat=false
- 混：有该副花色但不够、只能补主牌 → 合法、beat=false（等效垫牌），
  丢下必出的副牌只出主牌→拒；含"有对也压不过"边界
期望值取自 design 规则（不争权/须先出该花色），全套 254 项通过。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 07:02:43 +08:00