daoqi/erqiwang_youle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
175 Commits 1 Branch 0 Tags
master
Commit Graph
31 Commits
Author SHA1 Message Date
joywayerandClaude Opus 5 8dba099717 二七王：HIST_FAN/MING_FAN maxWidth 由 490 改判定为 480，让 spacingMin 真正生效 
上一版把 maxWidth 收窄到 490 只是让 RIGHT 座位恰好贴住画布边界（零余量），且
spacingMin:-96 在 28 张时永远不触底、成了死参数。裁定改为 480：
(480-110)/27-110≈-96.30 超过 spacingMin，spacing 被截断为 -96，总宽变为
28×110+27×(-96)=488，与清单原注释「每张露14px、总宽488」精确对齐——500 是笔误，
488 才是当初想要的值。

求解器验证（count=28）：LEFT 16→504、RIGHT 791→1279、SELF 396→884，三座位均落在
0-1280 内且有余量。同步订正 Layout_Result.js 注释与清单 §6.9c 文字/数值。

client/tests/run.js 与 server/games/erqiwang/test/run.js 均全绿，精灵总数(380)/
布局节点数(83) 未变。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 09:08:48 +08:00
joywayerandClaude Opus 5 2b1dd0d947 二七王：修复出牌操作条/亮牌历史布局越界，补主牌统计条改名遗漏 
- I1：Layers.js 群组 206 改名遗漏一处注释（亮牌信息条 → 主牌统计条），全仓复查确认无第二处
- I2：出牌操作条补「提示」项后 anchor:center 导致已有两项挤偏，改用 anchor:left 并反推
  anchorX=446，令「出牌」按钮回到参考图实测 x≈556（求解器验证：446/556/748）
- I3：HIST_FAN/MING_FAN 的 maxWidth 反推算错（旧注释「488」有误，实际总宽恒等于
  maxWidth=500），导致 RIGHT 座位整排超出画布 5px；收窄为 490 使三座位求解结果落在
  0-1280 内，订正注释与清单 §6.9c 对应文字
- M3：同步修正计划文档里遗留的旧名「亮牌信息条/亮牌条」
- M6：test_constants.js 补 items[].key 的三命名空间解析守卫（此前完全无守卫）
- M5/M7：订正 ACC_ROW_TEXT_GRID 与扣底按钮宽度的估值依据说明
- M1/M2：清单 §6.9 子节重新排序为 6.9a→6.9b→6.9c 并统一标题层级，修正脚注星号误渲染

client/tests/run.js 与 server/games/erqiwang/test/run.js 均全绿，精灵总数(380)/
布局节点数(83) 两个钉死断言未变。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 09:06:01 +08:00
joywayerandClaude Opus 5 8f36b61620 二七王：补齐三处配置缺口（扣底按钮 / 出牌提示按钮槽位 / 三个 View 的布局节点） 
这三处都是「精灵或按钮已在清单里定案，但配置层缺东西」，不补的话 C/D/E 阶段
写渲染代码时会发现没有布局节点，极易就地硬编码坐标（违反零裸值红线）。

1) 底栏「扣底」按钮没有精灵（清单 §2.6 列了 5 个功能按钮，只登记了 4 个）
   - 新增 BTN_BURY_CARDS(1056) / BTN_BURY_CARDS_TEXT(1057)，群组 205 号段内空闲号，
     资源沿用 BTN_BOTTOM_FUNC，与其余四个按钮同构。
   - FOOTER_FUNC_BUTTONS 的 items 由 4 项扩到 5 项，扣底紧邻底牌（照 §2.6 表序）。
     扣底宽 78 是【估值】：清单未给，取同为两字按钮的「底牌」实测值，已在配置与清单里注明。
   - 扣底看【埋牌底牌】(burycards)、底牌看【底牌】(bottomcards)，两批不同的牌，
     JSDoc 里补了防写反的提示（对应验收清单第 13 条）。

2) 出牌阶段「提示」按钮有精灵、无布局槽位
   - PLAY_OPERATION_BAR.items 补上 PLAY_BTN_TIP，顺序照清单 §1.7 行文：倒计时 / 出牌 / 提示。
   - 宽 180 是【估值】：清单 §6.8 自身漏了该项；与埋牌条的提示按钮同资源 BTN_TIP
     （§3.3 实测 180×63），埋牌条 items 首项亦取 180，故沿用。
   - 顺带记下一处待裁定项：本条 itemHeight 为 55（对齐 BTN_PLAY 157×55），
     而 BTN_TIP 原生高 63，高度差待设计稿定。

3) AccountView / HistoryView / MingPaiView 一个布局节点都没有
   - AccountView（§6.9a 新增）：外壳 6 个节点 + 玩家栏「容器 ACC_ROW_CONTAINER +
     行节点 ACC_ROW（itemHeight 即行高，行数由 ctx.count 给出）+ 行内模板贴附到行矩形」
     + 面板外 4 按钮，共 14 个节点。行内节点求出的是相对容器的坐标，可直接喂
     SpriteCopyUtils.create（与 §5.6a 冲关牌同一用法）。
   - HistoryView / MingPaiView（§6.9c 新增）：遮罩 + 容器 + 每家一排牌(fan) + 座位标签，
     各 4 个节点。照 CHONGGUAN_FAN 同构、锚点沿用 §6.7 冲关牌的三家落点；
     差别只在张数上限——出牌历史摊平后可达 28 张以上，故 maxWidth 放宽到 500、
     spacingMin 收到 -96【估值】。MING_* 只有 LEFT/RIGHT 两个 bySeat 变体（明牌不看自己）。
   - 坐标来源：大局结算.png / 冲关牌型显示.png 目视实测，w/h 取资源尺寸；
     配置与清单里均已注明「目视实测估值，待设计稿复核」。
   - 运行时才确定的字段（动态文字宽高、随行浮动的 anchorY、数字精灵宽）一律
     runtime 显式声明。

钉死断言按实际重新数并更新：精灵总数 378 → 380，布局节点总数 61 → 83。
另把 ACC_TPL_SCORE_NUM 加进 NUM_STYLE 同源校验表（与 RESULT_SCORE_NUM 同一套资源）。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 08:40:48 +08:00
joywayerandClaude Opus 5 f982460c9c 二七王：群组 206 改名为主牌统计条，与 design §8.2 的「亮牌」消歧义 
群组 206 原名「亮牌条 / LIANGPAI_BAR」，但它的实际用途与坐标 (35,400) 对应的是
清单 §2.5「自己的主牌统计条」——手牌上方显示 x对 x主、前端本地统计、有手牌时常显。
而 design §8.2 真正的「亮牌」是庄家埋牌后向两个闲家亮出自己全部固定主牌的具体牌面，
走遮罩面板（群组 242，复用 HIST_* 精灵）。清单 §0.0 专门用一节区分「亮牌 / 余主公示 /
明牌 / 开底」四类公开信息，名字撞车极易把渲染写到错误的界面上。

统一改名（ID 一律不变，只改名字）：
- 群组   EQW_Groups.LIANGPAI_BAR   → ZHU_STAT_BAR (206)
- View   EQW_Sprites.LiangPaiView  → ZhuStatView，容器 LiangPaiBar → ZhuStatBar
- 精灵   LIANGPAI_BG/_TEXT (1030/1031) → ZHU_STAT_BG / ZHU_STAT_TEXT
- 布局   EQW_Layout.LIANGPAI_BG    → ZHU_STAT_BG
- 资源   EQW_Images.BAR_LIANGPAI   → BAR_ZHU_STAT (605)

同步清单 §0.0 / §0.3 群组表与号段表 / §1.6 / §2.5 / §3.5 / §3.6 / §5.1 / §5.7b /
§6.5 / §7.2 T-9 / §7.3 第 5 条，并在 §0.3 群组表下加修订说明（2026-08-27 + 缘由）。

一并订正清单 §1.6 的一处笔误：收到 liangpai 时应弹出亮牌遮罩面板（群组 242），
原文写的是「渲染 §2.5 亮牌信息条」——正是同名异实造成的串位。
EQW_Anim.LIANGPAI_AUTO_CLOSE 属真正的亮牌面板，保持原名，仅补注释说明归属。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 08:40:09 +08:00
joywayerandClaude Opus 5 0c58ae67db 二七王：倒计时与结算得分改用数字图精灵，收尾几处命名与文档订正 
- CD_LEFT/CD_RIGHT/CD_SELF（1150-1152）由文字精灵改为多帧图数字精灵：
  资源 NUM_COUNTDOWN，纯秒数无后缀；对应布局节点 P_COUNTDOWN 的 h 改取
  NUM_STYLE.COUNTDOWN.charHeight，w 留到运行时注入。
- 结算得分 RESULT_SCORE_LEFT/RIGHT/SELF（1805-1807）同理由文字精灵改为
  数字图精灵（NUM_RESULT_WIN/NUM_RESULT_LOSE），与大局结算已有的
  ACC_TPL_SCORE_NUM 保持一致；布局节点随之调整，移除不再使用的
  TEXT_STYLE.SCORE_BIG。
- NUM_CALL_SCORE 第16帧由"待美术与规则确认"改为明确的"无后缀"（叫分档位
  面板只显示纯数字，"N子"角标是独立文字精灵）；NUM_MAIN_SUIT_COUNT /
  NUM_RESULT_WIN / NUM_RESULT_LOSE 第16帧仍待确认，不改。
- Layout_Action.js 的 CALL_BTN_SCORE_TEXT、Layout_Result.js 的
  RESULT_SCORE_TEXT 改名为 CALL_BTN_SCORE_NUM / RESULT_SCORE_NUM：
  两者驱动的都是数字图精灵，_TEXT 后缀误导；同步测试引用。
- docs/client/development-guide/02：订正"SpriteManager 第1154行"这一失效
  行号引用（回退后该行号落在 setTextWithWidth 体内），改为不写死行号。
- docs_dev 清单同步：§2.4/§5.4/§5.6/§6.6/§6.9 倒计时与结算得分的精灵类型
  描述、§6.6/§6.9 对应布局参数。
- test_constants.js 的 NUM_STYLE 同源守卫表新增 COUNTDOWN、RESULT_WIN、
  RESULT_LOSE 三对（连同改名后的 CALL_BTN_SCORE_NUM），共 6 条新断言。

精灵总数、布局节点总数均未变（378 / 61），只改类型与命名，不增删。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 00:54:42 +08:00
joywayerandClaude Opus 5 35ee85e1d6 二七王：回退自造的图集叠绘，改用平台既有 SpriteManager.setNumberImage 
方案作废并纠正认知：多帧图片精灵【不是】只能显示一位数——SpriteManager 第 1154 行
早有 setNumberImage(spriteId, text, charWidth)：把整串文本设给一个多帧图片精灵，
引擎按字符逐帧渲染，精灵宽度按「字符数 × charWidth」自动调整。bc75e40 造的
drawImageRegion + NumberRenderer 是重复轮子，本次整体回退（revert bc75e40）。

- 回退：删除 gameabc-framework/ui/NumberRenderer.js 与其单测，SpriteManager 与
  index.html 恢复到改动前（与 bc75e40^ 逐字节一致）。
- ImageResources.js：数字类资源改为 16 帧、固定帧序 0123456789.+-x/p，逐条写明
  各帧含义、第16帧后缀（选主张数=「张」；结算/叫分的后缀标注待美术与规则确认，未瞎填）、
  单字符宽高与整图尺寸（16 × 单字宽），并说明帧序不可重排、不可省略占位。
- LayoutConstants.js：NUM_STYLE 改为 setNumberImage 所需的 res/charWidth/charHeight/suffix。
- Layout_Action.js：两个数字节点 h 取 charHeight（SSOT），w 留运行时注入
  （宽度由 setNumberImage 按字符数自动改，随位数变）。
- Sprites_Action.js / Sprites_Result.js：注释改为 setNumberImage 用法；
  结算玩家栏 ACC_TPL_SCORE_NUM 是复制精灵也能用（该接口不依赖绘制回调）。
- test_constants.js：NUM_STYLE 守卫改为校验 charWidth/charHeight/suffix 与
  「h 同源、w 运行时注入」；suffix 限定为 setNumberImage 支持的 分/倍/张。
- 文档：清单 §1.3/§1.5/§3.6/§5.4/§6.8 与前端 02 的那一节全部按 setNumberImage 重写，
  三种机制改为「文字精灵 / setFrame 切帧 / setNumberImage」，并记下这次误判作为反例。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-27 00:07:35 +08:00
joywayerandClaude Opus 5 dbdd6607d7 二七王：文档同步图集叠绘数字（清单 §1.3/§1.5/§3.6/§5.4/§6.8 + 前端 02 新增一节） 
- docs_dev 清单：§3.6 数字资源改为「等宽连续排列的一张图」并给出字符顺序/单字宽高/整图尺寸，
  §1.3 说明叫分档位分数为何必须改叠绘（14 档里 13 档两位数、每档一个精灵），
  §1.5/§5.4 选主张数由 8 个精灵改回 4 个（1678–1681 记跳号不复用），
  §6.8 布局节点合并 + 新增 NUM_STYLE 数字样式表；各处均带 2026-08-26 修订说明与缘由。
- 前端 02：新增「三种显示机制：文字精灵 / 多帧图片精灵 / 图集叠绘」一节，
  给出三问选用判据、多位数误用 setFrame 的坑与真实事故、叠绘的三条前提与出图规格；
  §5 补一条「转发必须接上且参数对齐，否则事件静默失效」的警示；DO/DON'T 各补一行。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-26 23:56:32 +08:00
joywayerandClaude Opus 5 b81e800f22 二七王：选主面板按美术实际出图方式（一张图5帧）重做资源与精灵定义 
BTN_SUIT_CHOOSE 改为 5 帧（4 花色按钮各含底+图标+角标底、帧5=投降按钮含底+文字），
删除独立的 SUIT_ICON_L(512)/BTN_SURRENDER(534)/花色图标精灵/角标底精灵/投降文字精灵；
花色张数从单个文字精灵改为图片数字精灵(十位+个位)，新增资源 NUM_MAIN_SUIT_COUNT(636)。
同步规格清单文档与两个测试文件里被钉死的精灵总数(387→382)。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-26 23:30:12 +08:00
joywayerandClaude Opus 5 be3e8d0837 二七王：清单 §5.2 手牌标记改为每张牌一个 
原表「牌型分组标记 ×8」与 §1.6「三种标记互斥、每张牌至多一个」矛盾。
裁决按每张牌——§1.6 是行为规格更权威，且三种标记本就是逐张判定的属性；
实测一手 28 张常带 13 个以上标记，8 个远远不够。

号段 1236–1243 太窄且其后 1250 起已被底牌区占用，改为 2100–2135。
前端 Sprites_Cards.js 与 core/CardMark.js 已按此落地。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-26 22:32:10 +08:00
joywayerandClaude Opus 5 f04bff4e9f 二七王：S-8 curmultiple 改为带符号 
问题：S-1 实现时取了绝对值，而判定的正负号恰恰是「谁赢」的区分——
3 大光 vs -3 升3级、2 小光 vs -2 升2级、1 过庄 vs -1 升1级，取绝对值后
三对完全撞在一起，D-8 的过程中判定动画无从分辨该播哪个。

改法：get_curmultiple 直接返回 get_upgrade 原值，与结算包 aset.upgrade
完全同口径（3/2/1 庄家大光/小光/过庄，-N 闲家升N级，0 叫分未定）。
顶部「抓分」角标只关心大小，取 Math.abs 即可；判定动画靠符号分辨，
前端一套映射通吃「过程中」与「结算前」两条路径。

协议 4 处 curmultiple 说明同步（shangzhuang / chupai1 / chupai2·3 /
PushCards）。

测试（hint 33 → 46 checks）：
- 钉住三对「绝对值相同、判定相反」的组合可区分，以及符号语义
  （>0 庄赢 / <0 闲赢 / ==0 叫分未定）。
- 新增一组【直接调 get_curmultiple 本身】覆盖负数分支，含爬坡 Q 分段。

补上一个测试盲点：第一次反向验证（把实现退回取绝对值）竟然全绿——因为
原有断言里算法层的 cm() 走的是 A.get_upgrade、绕过了 get_curmultiple，
而端到端那局恰好是大光(正数)，取不取绝对值都一样。补齐直接调用的用例后
再验，4 条断言立刻失败。

至此 §7.5 服务端待补 8 条全部完成，服务端侧无遗留；D-8 只差动画设计稿
与触发细节。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-26 12:42:29 +08:00
joywayerandClaude Opus 5 fd31272bd1 二七王：D-8 判定结果改为动画呈现，并记录 S-8 
小局结算面板【不做】大光/小光/过庄/升N级 的静态文字，改由动画在两个时机
呈现：对局过程中（判定档位跳变时）与结算前（最终判定）。精灵 1814
RESULT_JUDGE_TEXT 与资源 634 的静态文字方案作废，634 改为帧动画资源
ANI_JUDGE，播放参数进 AnimationConfigs。

动画遵守「数据优先、表现延后」：先写数据再播动画，动画回调只刷界面不写
核心数据；动画缺失或卡住时结算面板与数据仍正确。

新增 S-8（阻塞 D-8 的过程中动画）：S-1 实现 curmultiple 时取了绝对值，
而判定的正负号恰恰是「谁赢」的区分——取绝对值后
  3 大光 vs -3 升3级、2 小光 vs -2 升2级、1 过庄 vs -1 升1级
三对完全撞在一起，过程中动画无从判断该播哪个。建议改为带符号、与结算包
aset.upgrade 同口径，前端一套映射通吃两条路径；顶部抓分角标取 Math.abs
即可，不受影响。

当初取绝对值是因为 S-1 只服务顶部角标一个用途、只关心大小；现在多了动画
这个消费方，符号成了必需信息。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-26 12:12:58 +08:00
joywayerandClaude Opus 5 e51cde02b8 二七王：去掉开底提示文案，状态提示条收敛为 3 条 
闲家看到底牌由背面翻成正面本身就是开底最直白的表达，再加一行「底牌公示中」
是多余的。移除后提示条只剩 3 条：等待庄家选主 / 等待庄家埋牌 / 强甩失败。

「不做」清单相应增至五处：叫分等待、出牌等待、准备等待、掉线重连、开底提示，
各自记明理由（倒计时已指明、平台标识已有、画面本身已表达）。

同时移除随该文案而设的「底牌公示是文案不是术语」那段注记——文案没了，
注记也不再需要；术语侧「开底」的定义在 §0.0 未变。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-26 08:20:48 +08:00
joywayerandClaude Opus 5 32cbe2fe91 二七王：T-33 提示条文案定案，亮牌改为纯自动关闭 
T-33 定案，状态提示条全部 4 条：
  底牌公示中   全场   70 分开底那 3 秒
  等待庄家选主 闲家   shangzhuang → xuanzhu
  等待庄家埋牌 闲家   xuanzhu → maipai
  强甩失败     全场   收到 shuaicuo==1，自动淡出

明确不做四处并记下理由：叫分等待与出牌等待（倒计时就显示在当前操作者
位置旁，已指明在等谁；出牌一局约 84 次切换，弹条只会吵）、准备等待
（平台自带已准备/未准备标识）、掉线重连提示（平台 Layer 615 已覆盖）。

特别标注一处易绕回去的地方：「底牌公示中」是【界面文案】可以用，但
「底牌公示」作为【术语】已弃用（会与「亮牌＝公示牌力」混淆），规则术语
一律说「开底」。文案配合 8 张牌摊开的画面不会误读，故沿用。

T-34 补充：亮牌面板改为【仅自动时长关闭】，遮罩不注册点击。并列出三个
遮罩面板关闭方式的对照表——亮牌仅自动、冲关牌型点遮罩、明牌/出牌历史
点遮罩+按钮切换，三者不同，实现时最容易写混。

至此待确认 34 项只剩 T-20 音效（已明确后补）。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-26 08:14:51 +08:00
joywayerandClaude Opus 5 6c78b37e89 二七王：T-34 亮牌展示时机定案，整理 T-33 等待提示条文案候选 
T-34 已定：亮牌在【埋牌后、出牌前】一次性弹出——收 maipai 包（其中带
liangpai）时展示，出牌开始前收起，与 design §8.2 的规则时点一致。
点遮罩关闭 + 自动关闭时长兜底（liangpaiAutoClose 进配置）；只有闲家会
收到并弹出；面板开着不阻塞出牌推送，收到出牌包直接收起即可。

T-33：按流程梳理出等待类文案候选 W1–W6 写进 §2.8，连同即时反馈类
（目前只有「强甩失败」）。同时标出三处需要拍板的：
- W4 出牌等待要不要做——一局约 84 次切换，每次弹条会很吵，且已有倒计时
  与已出牌区两重指示，倾向不做。
- W6 开底 3 秒显示什么——参考图上写的是「等待庄家选主」，但那张图叠画了
  开底与选主两个状态（§0.5），不能直接采信。
- 文案是否带昵称——带则提示条需随文案变宽。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-26 08:07:35 +08:00
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 9ea6bfa14d 二七王：立「怎么读参考图」原则，清掉由 mock 数值引出的伪待确认项 
参考图是界面设计示意，只看版式/位置/样式，不看数值与状态组合。§0.5 新增
一张对照表写清哪些可信、哪些不可信：

  可信：位置、尺寸、层级、配色、字体、元素形态、牌面排布方式
  不可信：具体数值（一律填充假数据）；同时出现的互斥元素（如多个玩家位
          同时挂庄标——那是在标「庄标在每个位置分别摆哪儿」）；跨阶段并置
          的状态；底栏功能按钮的显隐

据此关闭两个本来就不成立的待确认项：
- T-31 大局结算「基础分」与「总得分」：图上两者数值相同且与右侧大字对不上，
  是填充数据所致。取 grade_jf_total 与 score，S-6 已实现。
- T-32 等待庄家选主.png 里底牌仍摊着：属叠画示意。实际先后仍按 design §4：
  开底 3 秒 → 摸底入手 → 选主。

其余三处已按同一原则处理过的表述（叫分角标 1子/2子/4子、埋牌双排 17/19）
统一改为指向 §0.5，口径一致。

顺带整理 §7.2：T-9 已定却仍留在「仍未决」表里，T-30~T-34 又不在表内。
现重整为「仍未决 3 项（T-20 音效 / T-33 等待文案 / T-34 亮牌展示时机）」+
「已定论 31 项」，并核对 T-1~T-34 连续无缺号。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-26 07:46:13 +08:00
joywayerandClaude Opus 5 76e82405e1 二七王：S-6 大局结算按 基础分/冲关分/傍王分 三项分解 
问题：大局结算面板要分项显示，而 account 只有「累积得分 + 每局得分数组」。
傍王分尤其拆不出来——N = 冲关奖数 + 傍王王数，两个来源【求和之后】才代入
grade_aw = X×(2Ni−Nj−Nk)，事后无法反推各自占比。

解法：在算钱时就拆。把 N 分成 N_冲关（只计庄家）与 N_傍王（勾选后庄闲都算），
分别代入同一公式各算一次。公式对 N 线性，故恒有
  grade_cg + grade_bw == grade_aw
这条恒等式正好当回归断言用。

服务端：
- class.paiju.js 抽出 award_pay(n) 复用同一公式，新增 grade_cg / grade_bw；
  desk.seatlist 追加三个累计位（基础/冲关/傍王）。
- class.desk.js seatlist 初始化为 5 元素；account 下发改为【对象数组】
  { score, grades, grade_jf_total, grade_cg_total, grade_bw_total }。
  原二元数组下标语义不清，且前端未开工，此时改代价最小（同 S-4 的判断）。

协议：aset.seatlist 增补 grade_cg / grade_bw；account 结构与恒等式
  grade_jf_total + grade_cg_total + grade_bw_total == score 写明；
  并记录这次结构变更的时间与理由。

测试（endgame 26 → 39 checks）：
- 核心不变量：两分量之和 == grade_aw；两分量各自零和。
- 未勾傍王局：grade_bw 恒 0、grade_cg == grade_aw。
- 【新增一整局开傍王的端到端】：不开傍王时 grade_bw 恒 0，只验到平凡情形，
  必须有傍王局才算真验证了拆分。该局逐项复核两个分量的公式、naward 口径，
  并钉住「王数不全相等时 grade_bw 必有非零」防止又退化成平凡。
- 大局累计恒等式：基础+冲关+傍王 == 累积总分。

反向验证：把 _awbw 置零 → 4 条断言失败；把冲关分量误算到闲家头上 →
2 条断言失败。均已还原、全量 17 文件全绿。

另修四处测试桩：_rpc.js / test_paiju / test_rpc / test_success 里手工构造的
o_desk.seatlist 仍是 2 元素，未跟上 class.desk.js 的结构变更（脚本缺陷，
非业务缺陷）。

顺带解决小局结算「冲关分」标签的不严谨：改取 grade_cg 而非 grade_aw，
开傍王时不再把傍王贡献算进来。

遗留 T-31：参考图「基础分」与「总得分」两行数值相同且与右侧大字对不上
（30/30 vs +135），mock 不自洽。当前按 基础分=grade_jf_total、总分=score
提供。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-26 00:34:46 +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 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 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