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
..
2026-08-26 12:42:29 +08:00
2026-08-26 12:42:29 +08:00
2026-08-23 12:18:04 +08:00
2026-07-04 23:51:12 +08:00
2026-08-26 00:34:46 +08:00
2026-08-25 20:25:32 +08:00
2026-07-04 23:51:12 +08:00
2026-07-04 23:51:12 +08:00
2026-08-26 12:42:29 +08:00
2026-08-25 20:25:32 +08:00