  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
|
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
|
b98f58effc
|
二七王：亮牌改为下发庄家全部固定主牌的具体牌面
规则变更（design §8.2）：原先「只亮数量/结构，不亮具体是哪几张牌」，现改为
向两个闲家亮出【庄家手中全部固定主牌的具体牌面】。
- 固定主牌 = 双王 + 全部花色的 2 + 全部花色的 7，【不含】主花色普通牌
A/K/Q/J/10/9/8/6/5。注意这与旧实现收集的「所有主牌」范围不同。
- 门槛不变（固定主牌总数 ≥10 / 王 ≥3 / 7 ≥6 / 2 ≥6，任一满足）。
- 不限叫分；仅可查牌模式下发；亮出的是固定的一份，不随被哪条门槛触发而增减。
- 协议 liangpai 由 {zhu,zhupair,zhutuo,wang,qi,er} 数量结构改为 {cards:[牌id...]}，
数量交由前端从 cards 自行计算。
服务端 get_liangpai() 重写（class.paiju.js）；design §8.2 整节重写，术语表、
易混对照表、§9 相应更新；协议 §0.0b 与 maipai / PushCards 两处字段说明同步。
测试：
- test_paiju 亮牌用例按新规则重写（54 checks）。新增两条针对性用例：
「只含固定主牌·主花色普通牌未混入」与「同时满足多档仍只亮同一份」——
前者正是这次范围变更最容易写错的地方。
- test_leak 增加亮牌可见性规则。关键点：期望集合【独立于 get_liangpai 重算】，
而不是复用被测实现——否则实现若误塞非固定主牌，审计会跟着放行、抓不住。
反向验证证实了这一点：故意让 get_liangpai 混入主花色普通牌后，审计确实报警。
发现并修复一处假绿：原 6 局随机牌序下庄家一次都没达到亮牌门槛，即
「下发面无越权泄露」对亮牌这条路径根本没走到。现追加换牌序的 4 局（保留
原 6 局覆盖不动），并加两条覆盖断言钉住「可查牌达标 ≥1 局」「不查牌达标
≥1 局」，防止以后再退化成碰巧没触发。反向验证：去掉不查牌门控后审计立即
报出 5 张越权牌。
待定：T-34 亮牌的展示时机（出牌前一次性弹出 / 随时可查）。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-08-25 23:46:06 +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
|
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 |
|