二七王：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>

docs_dev/二七王-UI资源与精灵清单.md

@@ -840,7 +840,7 @@ EQW_RoomOptions = {
 
 **动画播放遵守「数据优先、表现延后」**（client 02 §3）：先 `setXxx` 把结算数据写进 `this.data`，再播动画；动画的开始/结束/出错回调里**只刷界面、不写核心数据**。动画缺失或卡住时，结算面板与数据仍须正确。
 
-> ⚠️ **过程中的判定动画需要「带符号」的判定值，而 `curmultiple` 目前是绝对值**——`Math.abs` 之后，「大光 ×3」与「闲家升 3 级 ×3」都是 `3`，无法区分该播哪个动画。详见 §7.5 **S-8**。
+> `curmultiple` 是**带符号**的（S-8 已改）：`3/2/1` = 庄家大光/小光/过庄，`-N` = 闲家升 N 级，`0` = 叫分未定。判定动画按符号 + 绝对值两维映射即可，与结算包 `aset.upgrade` 同一套逻辑。
 
 **投降结算**：只有 `aset`，无 `chupai`、无 `bottom` → 结算面板必须容忍**底牌区缺失**，不能因为读不到 `bottom.cards` 就崩或显示空框。
 
@@ -922,7 +922,7 @@ EQW_RoomOptions = {
 | --- | --- | --- | --- |
 | 1 | `主` | 花色图标 | `xuanzhu.flower` / `aset.flower`（1方块 2梅花 3红心 4黑桃）；选主前显示占位 |
 | 2 | `叫分`（绿字） | 分数 + 蓝色角标 | `shangzhuang.grade` + `multiple` |
-| 3 | `抓分`（橙字） | 分数 + 橙色角标 | 闲家累计捡分（逐轮 `chupai3.grade` 累加，结算时以 `aset.grade` 为准） |
+| 3 | `抓分`（橙字） | 分数 + 橙色角标 | 分数 = 闲家累计捡分（逐轮 `chupai3.grade` 累加，结算时以 `aset.grade` 为准）；角标 = **`Math.abs(curmultiple)`**（该字段带符号，角标只取大小，见 S-8） |
 
 【待确认 T-16】：`抓分` 列的角标在 `等待叫分.png` 里是 `1子`、在 `小局结算.png` 里是 `1倍`，两图不一致。推定为 `aset.upgrade` 判定倍率（仅结算后有意义），需确认。
 
@@ -1791,7 +1791,7 @@ codes/config/
 ## 7. 待补充清单
 
 > **状态汇总**（2026-08-26）：待确认规格 34 项**只剩 T-20 音效**（已明确后补）；设计稿只剩 **D-8**（判定结果**动画**）。
-> **§7.5 服务端待补项**：S-1…S-7 已处理完毕；**新增 S-8**（`curmultiple` 需带符号，阻塞 D-8 的过程中动画）待处理。
+> **§7.5 服务端待补项 8 条全部处理完毕**。**服务端侧无遗留**——D-8 只差动画设计稿与触发细节。
 
 ### 7.1 待出设计稿的界面
 
@@ -2053,28 +2053,25 @@ data.bottom.cards     // 结算包
 > 之前记录的「有主牌的玩家伪造请求也能拿到明牌数据」这一泄露担忧**不成立**：按手册他本来就有权查看，服务端受理是正确行为，不是校验缺失。
 
 
-#### S-8 · `curmultiple` 需要带符号（新增，⚠️ 阻塞 D-8 的过程中动画）
+#### S-8 · `curmultiple` 改为带符号 —— ✅ 已完成（2026-08-26）
 
-**背景**：D-8 定为「判定结果由动画呈现」，其中**对局过程中**那一路要靠 `curmultiple`（S-1）判断当前是哪一档判定。
+**问题**：S-1 实现时取了绝对值，而判定的**正负号恰恰是「谁赢」的区分**——`3` 大光与 `-3` 升3级、`2` 小光与 `-2` 升2级、`1` 过庄与 `-1` 升1级，取绝对值后三对完全撞在一起，D-8 的过程中动画无从分辨该播哪个。
 
-**问题**：S-1 实现时把 `curmultiple` 取了**绝对值**（`class.paiju.js` `get_curmultiple` 末行 `return (_u < 0) ? (0 - _u) : _u;`）。而判定的**正负号恰恰是「谁赢」的区分**：
+**改法**：`get_curmultiple` 直接返回 `get_upgrade` 的原值，**与结算包 `aset.upgrade` 完全同口径**：
 
-| `get_upgrade` 原值 | 判定 | 取绝对值后 |
-| --- | --- | --- |
-| `3` | 庄家**大光** | `3` |
-| `-3` | 闲家**升 3 级** | `3` ← **撞了** |
-| `2` | 庄家**小光** | `2` |
-| `-2` | 闲家**升 2 级** | `2` ← **撞了** |
-| `1` | 庄家**过庄** | `1` |
-| `-1` | 闲家**升 1 级** | `1` ← **撞了** |
+| 值 | 含义 |
+| --- | --- |
+| `3` / `2` / `1` | 庄家 **大光** / **小光** / **过庄** |
+| `-N` | 闲家**升 N 级** |
+| `0` | 叫分未定 |
 
-三对判定在绝对值下完全无法区分，**过程中动画不知道该播哪个**。
+**前端用法**：
+- 顶部「抓分」角标只关心倍数大小 → `Math.abs(curmultiple)`（§2.1）。
+- **判定动画**靠符号分辨该播哪个（§1.8 D-8），一套映射通吃「过程中」与「结算前」两条路径。
 
-**建议**：`curmultiple` 改为**带符号**，与结算包 `aset.upgrade` 完全同口径（正=庄家赢的三档，负=闲家升级）。这样前端一套映射通吃「过程中」与「结算前」两条路径，不必写两份。
+**测试**（hint 33 → 46 checks）：新增两组——一组直接钉住三对「绝对值相同、判定相反」的组合可区分；另一组**直接调 `get_curmultiple` 本身**覆盖负数分支。
 
-- 顶部「抓分」角标要显示的是倍数大小 → 前端取 `Math.abs(curmultiple)` 即可（§2.1），不受影响。
-- 改动很小：去掉取绝对值那一步 + 协议说明 + 测试断言同步。
-- **为什么当初取了绝对值**：S-1 只服务于顶部角标那一个用途，角标只关心大小。现在多了动画这个消费方，符号成了必需信息。
+> 后一组是补上的**测试盲点**：原有断言里，算法层的 `cm()` 走的是 `A.get_upgrade`、**绕过了 `get_curmultiple`**，而端到端那局恰好是大光（正数），取不取绝对值结果一样。第一次反向验证（把实现退回取绝对值）竟然全绿，正是因为这个盲点。补齐后再验，4 条断言立刻失败。
 
 ---