daoqi/erqiwang_youle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
69 Commits 1 Branch 0 Tags
4aab71e6a3ca1386ecacfbf980aaa3a9125f33a7
Commit Graph
12 Commits
Author SHA1 Message Date
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 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 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 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 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