daoqi/erqiwang_youle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
82 Commits 1 Branch 0 Tags
f04bff4e9fc89614bba0393981c086a329942334
Commit Graph
17 Commits
Author SHA1 Message Date
joywayerandClaude Opus 5 796503153d 二七王：S-7 明牌条件按手册定案，服务端无需改动 
结论：按 design §9.3——任一玩家报无主后，三家都显示「明牌」按钮，
且整个出牌阶段随时可查、不限次数。判定依据是「场上有人报无主」而非
「自己报无主」，报无主那位和另外两位一样能看。

此前我把前端条件收紧成「自己是无主玩家」，比手册严格，反而与服务端
have_baofu() 的受理条件对不上。现改回：

- 前端清单 §1.7 D-6、§2.6 底栏按钮、§0.0 对照表、baozhu 字段说明统一为
  「可查牌 + 出牌阶段 + baozhu==1 → 三家都显示」。
- design §9.3 第 3 条补一句消歧：明确「为这三个人都出现」、判定依据是
  场上有人报无主、且不限次数随时可查。原文靠「同时」承接上一条的
  「为全体三人」，容易读漏。
- protocol 的术语表与 mingpai 受理条件说明同步加注。

服务端与协议本来就是手册口径，无代码改动。此前记的「有主牌玩家伪造请求
也能拿到明牌数据」这一泄露担忧不成立——按手册他本就有权查看，服务端受理
是正确行为。

验收清单增至 18 条，新增一条专门钉住「三家都显示，不是只给自己无主那家」。
至此 §7.5 服务端待补项 7 条全部处理完毕，服务端侧无遗留。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-26 08:03:08 +08:00
joywayerandClaude Opus 5 50e6fd3ca4 二七王：庄家算奖统一口径为「冲关」 
design §8.1 的「常规算奖」全面改称「冲关」，与服务端既有字段 chongguan、
界面「冲关分」「冲关牌型」对齐。理清三层关系并写进三份文档的术语表：

  冲关 = §8.1，只计庄家（旧称常规算奖）
  傍王 = §8.3，可选，庄闲都算
  算奖 = 上位概念 = 冲关 + 傍王 → naward（总奖数）、grade_aw（算奖得分）

「算奖」作为上位概念保留——naward / grade_aw / §8.4 的结算模型都建立在
合并概念之上，去掉它这些字段无从命名。故未做无差别替换，而是逐处甄别：
指 §8.1 的改冲关，指合计的留算奖。

design：17 处「常规算奖」→「冲关」，另修正 §7.0 第 4 层一处笔误
（「8.2 傍王」应为「8.3 傍王」，§8.2 是亮牌）；§8.1 开头加改名说明。
protocol：新增 §0.0c 算奖层级表；chongguan / naward / grade_aw 注释同步。
前端清单：界面文案与精灵键名统一（算奖牌型→冲关牌型、BTN_AWARD_CARDS→
BTN_CG_CARDS、AWARD_*→CG_* 等），§0.0 补层级表。

据更新后的 小局结算.png：「算奖分」→「冲关分」、「算奖牌型」→「冲关牌型」。
参考图 算奖牌型显示.png 已随之更名为 冲关牌型显示.png，文档 6 处引用同步；
已逐一核对 16 张图的文件名在文档中都能对上。

顺带记录一处标签不严谨：小局结算的「冲关分」取的是 grade_aw，而后者是按
合计后的 N 算出来的。没开傍王时两者相等；开了傍王时该数含傍王贡献，叫
「冲关分」偏窄。根因与 S-6 同源（两分量算钱前已合并、事后拆不开），待
S-6 落地后此标签才名副其实。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-26 00:25:11 +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 dc9123da92 二七王：确立「摸底 / 开底 / 查底牌」术语，弃用有歧义的「底牌公示」 
弃用原因：中文「底牌」既指发牌留桌那 8 张牌，也指"底细/实力"。我上一轮
造的「底牌公示」会被读成"公示庄家牌力"，而那其实是 design §8.2 的「亮牌」
——两边撞车。改用「底」字族，与已有的「扣底」成套：

| 术语 | 含义 | 谁看得到 |
| 摸底 | 庄家坐定后把 8 张底牌摸起查看并入手牌 | 仅庄家 |
| 开底 | 70 分坐庄，摸底【之前】向全场翻开 3 秒 | 全场 |
| 查底牌 | 对局中随时回看这 8 张（前端底栏按钮） | 庄家全程；闲家仅开底过的局 |
| 扣底 | 末轮闲家用主牌赢下，翻开埋牌底牌计分（原有） | —— |

三份文档同步：design 术语表新增三条并更新易混对照、§4/§12.1/§12.3 正文
改用新词；protocol §0.0b 与 ancard3s 字段说明同步；前端清单 §0.0 补「底」
字族对照表，§1.4、§2.6 相应改写。

口诀相应更新为：「亮牌」「余主公示」是统计类，「明牌」「开底」是牌面类。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-25 23:34:18 +08:00
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 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 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 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 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 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 1edbe9cc24 二七王规则：新增"混合出牌"概念（副牌不够+补主牌，等效垫牌） 
场景：首家出副牌、跟牌方有该花色副牌但张数不够、又无其他副牌可垫，
只能用主牌补差额，打出"副牌+主牌"混合。核对 can_followcard：混合牌
组不成纯主牌牌型，cardvalue=0，压不过首家。此前文档未成文——补入
术语表并在 §5.2 数量不足段落指向，明确它既非垫牌也非毙牌、但与垫牌
等效、不争夺出牌权。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 06:58:25 +08:00
joywayerandClaude Opus 4.8 55db22f4b1 二七王规则：明确 §5.2 同花色牌数量不足时缺口补牌规则 
原第 150 行仅笼统一句"缺口部分可任意补其他牌"，未针对"首家出拖拉机"
点破缺口不必成对/成拖拉机，且易与层级 4(同花色够、对子不够→补同花色
单张)混淆。按 get_followcard 数量不足分支(cantype 落单张型、只校验张数)
改写为：该花色牌全部必出，缺口用任意其他花色牌补、不强制成对/成拖拉机，
并与"完全缺门"情形分段。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 06:48:38 +08:00
joywayerandClaude Opus 4.8 83545e8b80 二七王规则：修正 §5.2 毙牌成立条件为"完全缺门" 
原第 156 行写"没有该副牌花色的同长度拖拉机"即可毙，暗示手里有该
花色的牌但不成拖拉机时也能用主牌毙——与代码不符。核对
class.arith.js can_followcard：毙牌成功(cardvalue>0)仅出现在完全
缺门分支，只要手中还有首家花色的牌，get_followcard 即判为必出，
只能垫不能毙。将三条特殊情况统一收紧为"完全缺门"，并补前提说明。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 06:36:57 +08:00
joywayerandClaude Opus 4.8 93449c8a92 二七王规则：按代码实际行为补全 §5.2 拖拉机跟牌的强制降级层级 
design.md §5.2 原本只描述"两连对"最简情形，缺少 3 连对及以上的
强制层级。按 class.arith.js get_followcard 的实际实现补写为完整
优先级表：同长拖 > 更短拖拆凑 > 对子够 > 对子不够全出+补 > 单张补；
并修正对子行"同花不足两张必出现有同花"的措辞。§5.4.4 甩牌跟牌
加一句交叉引用，点明与正常跟牌共用同一层级原则。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-05 06:16:50 +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