2 Commits

Include renames

Author	SHA1	Message	Date
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