docs(进件): 记录 5 条裁定 —— 全部按现方案走，零代码改动

用户 2026-09-23 裁定「5 条都按现方案走」。只改交付说明：零代码、零配置、零 SQL。

§四 由「需要用户裁定的 4 项」改为「裁定材料（已全部裁定）」。正文原样保留（那 4 段的
「代价若判错」正是裁定的依据材料），每项末尾加一行裁定的终态：

  §0.3d 通道条件必填 —— 维持「本批不收」；字段继续进 DTO、继续上送
  连带：account_type 建号腿派生 / 更新腿直取的不对称 —— 维持现状
  §0.7 /api/info/bank —— 维持「不实现 + 联行号手工录入」
  §0.8 rate_code —— 维持「平台级配置项」。5 条里代价最高，所以另钉住「判错时要改什么」：
       改的是「谁填这个值」（加 UI 或改派生），不是接口形状、不是 DTO、不是 SQL
  Task 9 验证台 —— 按现方案走 ⇒ 不收编（排除 ①）、不丢弃（排除 ③），即 ② 只留文件

三处连带订正，都是同一件事的不同落点：

  §七 那条「更新腿 10 个字段本批不补 UI」的理由 ①（「§0.3d 本身待裁定」）前提已消失。
      结论不变，依据换成另外两条：三个 *_stt 语义在上游文档里自相矛盾 + 增量语义下
      「不补是安全的」这条独立成立。并写明这不等于裁定「将来也不补」。
  §八②「进件是租户自助还是仅管理端」未被这 5 条覆盖，如实标注（不与已裁的 5 条混同）；
      现行为两边都成立（只授 role 1），今天不需要动作。
  §一 那句「只有待裁定与阻塞在凭据两类」同步改为「已裁定完毕」。

读数：476 → 511 行（git --numstat 40 增 5 删，净 +35，两处自洽）；
sha256 4cba370f1c53856a7fd2ee57373a07f17dba70aadf1292181c663bd4777a10d3；CR=0。
CR 量具配了成对正控：LeshouyingClient.java（w/crlf）CR=483 非 0、
LeshouyingOnboardingController.java（w/lf）CR=0。

.claude/plan/2026-09-23-lsy-onboarding-B-交付说明.md

@@ -65,7 +65,8 @@
   新注释里 `PENDING` / `APPROVED` / `REJECTED` **三个词全部命中** →
   **列 DDL 未变**（默认值仍是 `'APPROVED'::character varying` / `NO` / `32`）→ **值分布未变**
   ⇒ 确实**只动了注释**，没碰表结构也没碰数据。
-- ⇒ **三个交付 SQL 至此全部执行完毕。** 剩下的不再有「待执行的 SQL」，只有「待用户裁定」与「阻塞在凭据」两类。
+- ⇒ **三个交付 SQL 至此全部执行完毕。** 剩下的不再有「待执行的 SQL」，只剩两类：
+  **裁定**（§四 那 4 项 + 1 条相关不对称，**2026-09-23 已全部裁定完毕**）与**阻塞在凭据**。
 
 ---
 
@@ -115,7 +116,16 @@
 
 ---
 
-## 四、需要用户裁定的 **4 项**
+## 四、裁定材料（**2026-09-23 已全部裁定 —— 5 条都按现方案走**）
+
+> **用户原话**：「裁定：5 条都按现方案走」（**2026-09-23**）。
+> 所谓「现方案」＝**本件写下这一节时正在运行的那套行为**：下面 4 项各自的现有实现，
+> 加上 §七 里那条 `account_type` 派生/直取的不对称的现状。
+> ⇒ **本批次对此零代码改动、零配置改动、零 SQL 改动。**
+> **落笔时 HEAD = `c8ae69f`**（本次裁定记录另起一次提交）。
+> ★ 本节的正文**原样保留**（那 4 段的「代价若判错」是裁定的**依据材料**），
+> 只在每项末尾加一行「★ 裁定」标出终态 —— 这样读的人既能看到裁了什么，也能看到据什么裁的。
+> ★ **不属于这 5 条的一条**：§八② 「进件是租户自助还是仅管理端」**没有被覆盖**，见 §八。
 
 1. **§0.3d —— 通道条件必填字段本批次一律不收。** 说明栏里按通道标注的条件必填
    （`reg_capital` / `fSettle_account_type` / `actual_addr` / `business_scope` / `check_code` /
@@ -125,10 +135,20 @@
    类型、必填标记与取值线索，以及**上游文档自身的三处缺陷**，都在 **§七**里（2026-09-23 取自上游
    page 196236557）。同时那里记着一条相关的语义不对称待你一并裁：`account_type` 建号腿**由类别派生**、
    更新腿**可单独改**。
+   ★ **裁定（2026-09-23）：维持「本批不收」** —— 必填矩阵**不加**这 6 + 4 个字段；字段继续进 DTO、
+   继续上送（**不收 ≠ 放行**，这句不变）。**终态。**
+   ★ **连带裁定：`account_type` 的派生/直取不对称 —— 维持现状**（更新腿仍可单独改）。
+   **代价如实留着**：更新腿能造出**与商户类别不符**的结算类型，而建号腿不能（详见 §七）。
 2. **§0.7 —— `/api/info/bank` 选择器要不要补。** `account_bank_code` 已从「平台级凭据」改正为
    **商户自己的结算账户开户支行**（逐商户填）。本批次**不实现**该接口，联行号**手工录入**。
+   ★ **裁定（2026-09-23）：维持「不实现 + 手工录入」。终态。**
 3. **§0.8 —— `rate_code` 的归属未定：平台级还是逐商户。** 现按**平台级配置项**实现（DTO 里留了可覆盖字段）。
    **代价若判错**：若其实逐商户，操作者会用同一个值给所有商户进件 ⇒ **费率错**。
+   ★ **裁定（2026-09-23）：维持「平台级配置项」。终态。**
+   ★ **这是 5 条里代价最高的一条**，所以把「判错时要改什么」也一并钉住：
+   上游 `rate_code` 是**请求级**参数，我们两种实现都走同一条线上送（`LsyOnboardingService:500` 更新腿
+   `putIfNotBlank` / `:1225` 建号腿「空白则回落平台配置」）⇒ 万一其实该逐商户，要改的是**「谁填这个值」**
+   （加 UI 入口 / 改派生规则），**不是接口形状、不是 DTO、不是 SQL** —— DTO 里那个可覆盖字段一直在。
 4. **Task 9 的验证台是否收编进 `frontend/`。**
    修复轮造出一台可执行验证台（真 `@vue/compiler-sfc` + 真 `vue`，驱动页面真 `setup()`，只桩 `@/api` 与上传子组件）：
    `.superpowers/sdd/2026-09-23-lsy-onboarding-B/task-9-fix1-harness.mjs`（**10796 B / sha16 `7f07de4099c96a23`**）。
@@ -138,6 +158,13 @@
    **局限（务必一并考虑）**：**模板不渲染** ⇒ 只证明函数判定逻辑、不证明浏览器表现；
    **exit code 恒 0** ⇒ 判成败**只能读 `SUMMARY` 行**。
    ★ **注**：该台子在**工作区内**，若采纳 ② 需先把它挪到工作区之外。
+   ★ **裁定（2026-09-23）：按现方案走 ⇒ 不收编（排除 ①）、不丢弃（排除 ③），即 ② 只留文件。**
+   **终态。** 台子留在批次工作区原路径，`frontend/` 不引入测试入口。
+   ★ **② 那句「工作区可能被清」的残留**：工作区**已决定不删**（2026-09-23，理由：用户保留最终验收权 +
+   该操作不可逆 + 代价≈0），所以「只留文件」今天成立；但 `git clean -fdx` 仍会连它一起清掉
+   —— **挪出工作区是一条命令的事，要挪说一声**。
+   ★ **若你要的其实是 ①「收编」**（那是新工作：得先给 `frontend/` 引入测试入口），也说一声即可 ——
+   本行按「现方案走」读作 ②，是因为 ① 会**改变仓库内容**，与「按现方案走」相反。
 
 ---
 
@@ -273,8 +300,9 @@
   它的键集被一条 `assertEquals` 钉死，这 10 个键一个都不在里面。要补得先从更新页参数表逐个转录。
   ★ **2026-09-23 裁定：本批不补这 10 个入口**，两条理由：
   ① 其中 **6 个正是 §0.3d 那一族通道条件字段**（`reg_capital` / `fSettle_account_type` /
-     `actual_addr` / `business_scope` / `check_code` / `p_cashier`），而 §0.3d **本身就是 §四 待用户裁定
-     的第 1 项** ⇒ 先替用户把 UI 做出来，等于替他做了那个裁定；
+     `actual_addr` / `business_scope` / `check_code` / `p_cashier`），而 §0.3d **当时**本身就是 §四
+     待裁定的第 1 项 ⇒ 先替用户把 UI 做出来，等于替他做了那个裁定；
+     **（★ 该前提已于 2026-09-23 消失 —— §0.3d 已裁定，见本节末尾 ★ ；结论不变，依据已换）**
   ② 剩下 4 个各有一个**必须先答的问题**：三个 `*_stt`（`license_stt` / `legal_cert_stt` /
      `account_idcard_stt`）的语义在上游文档里**自相矛盾**（见下）；`account_type` 在**建号腿是从
      `category` 派生**的（实测 `LsyOnboardingService:1190`
@@ -283,6 +311,11 @@
      的结算类型，而建号腿不能。这是**要不要允许**的选择，不是一个默认值。
   ★ **不补是安全的**：上游更新是增量语义「有值则更新，无值则保持原数据」⇒ 没有入口 = **不改这一项**，
      不会把已有值抹掉。所以这是**能力缺口**，不是正确性缺口。
+  ★ **2026-09-23 后补（理由 ① 的前提消失，结论不变）**：§0.3d 已裁定为「维持本批不收」、
+     `account_type` 的不对称已裁定为「维持现状」（见 §四）⇒ 上面理由 ①「先替用户做裁定」**不再成立**。
+     **结论（本批不补这 10 个入口）照旧**，但依据要换成另外两条：② 仍成立（三个 `*_stt` 的语义在上游
+     文档里自相矛盾），加上「**不补是安全的**」这条**独立**成立。
+     ★ **这不等于裁定「将来也不补」** —— 补的时候权威数据就在下一段，是**转录**不是重新调研。
   ★ **转录用的权威数据已取回**（上游 page 196236557，2026-09-23 用 showdoc JSON 接口取全文）。
      将来裁定「补」时不必再查文档，逐字如下：
 
@@ -342,7 +375,9 @@
    **故意不授 `role_id = 2`** —— 因为 `/commit` 的租户归属闸依赖一张**调用方自己可写**的映射表，
    而 role 2（活库实测 17 个用户）本就持有那条写入口所需的读权限（`merchant:list`）。
    ⇒ **这是有意的收紧，不是漏授**；租户用户看不到页面属**预期行为**。已在 §二 复核：授权行 **3 行、role_id 全是 1**。
-② **「进件是租户自助还是仅管理端」待用户裁定** —— 这个答案决定 ① 是**临时收紧**还是**终态**。
+② **「进件是租户自助还是仅管理端」——★ 2026-09-23 那次「5 条都按现方案走」没有覆盖它**
+   （那 5 条里不含本条）。**现行为两边都成立**（只授 role 1：不管将来判「仅管理端」还是「将来开放」，
+   今天这一步都不需要改）⇒ **它现在不需要任何动作**，只在你**决定对租户开放进件页**时才变成决策。
 ③ `save` / `delete` 由读权限 `merchant:list` 守着，而那张映射表**调用方可写** —— **既存面，不在本批修**，如实登记。
 
 ---