# 2026-09-15

## 通读 fms-vue 的 views/module 与 views/base

纯代码阅读，无改动。结论要点：

- `views/base` 是业务侧页面，几乎全部靠 `FmsModuleListPage` 按 `data-code` 自渲染，页面本身只留业务规则。
  - `othercompany/index.vue`（768 行）：唯一有左侧业务分类树的页面，分类树自己维护（增改删 + 拖拽），
    选中分类 → 拼 `[b_cate_id] IN (...)` 作为 `fixedSearchCondition`（含全部下级分类）。
  - `otherdata/index.vue`（479 行）：左树是 `s_module` 子树（根 `base_otherdata`），**分类结构不在本页维护**，
    去「模块管理」改。右侧按选中的 `data` 模块切换数据源，可编辑 + 行拖拽排序（`b_xh`）。
  - `contact/index.vue`（130 行）：最简形态，无左树，只有列表 + 权限按钮 + 行删除。
  - `contacts/detail.vue`、`othercompany/detail.vue`：**两个都是空壳**（各 22 行，只有一个空 div + 注释），
    注释明确写了「保存 / 重置 / 删除与表单均尚未实现」。新增/编辑跳转过去是死的。

- `views/module` 是配置中心（`meta.adminOnly`），三个页面：
  - `module-management/index.vue`（1316 行）编排层，严格按 `开发规范.md` 的「面板式配置页」模式：
    8 对 `xxx` / `xxx_org` ref，面板用 `defineModel` 直读写，跨面板副作用走编排层 watch
    （自动编码字段在 edit schema 中自动只读）。拖拽排序即时落库并同步基线。
  - `menu-management/index.vue`（1155 行）同类页面，已重构出 `MenuTreePanel / MenuBasicPanel / ModulePickerModal`，
    但注释与 `ai-plans/TASK1.md` 显示还有 `MenuPowersPanel` 未落地（权限点已移到模块管理维护）。
  - `i18n-type/index.vue`（214 行）最小样板：`FmsModuleListPage` + `FmsModuleEditModal` + 少量业务规则
    （默认语言保护、行内切换自动保存）。**做新的简单字典页应以此页为模板。**

- 设计器 `module-management/components/design-editor/` 是最大的一块（FormDesignEditor 2786 行、
  useStructureEditing 1012 行）。`TableDesignEditor` 用 `mode` 参数化 `subtable` / `list` 两个场景；
  `schemaModel.js` 负责 schema JSON ↔ 编辑器行/分组 的双向转换。

## 发现的问题（未修，仅记录）

- `FormDesignEditor.vue` / `TableDesignEditor.vue` 的文件头注释仍写 `s_field_edit` / `s_field_view` /
  `s_field_group`（V1 已废弃的表，V2 统一为 `s_module_schema.b_schema_json`），与实际实现不符，属陈旧注释。
- `ModuleListConfigPanel` / `ModuleEditPanel` 只是 30~43 行的薄壳，真正的编辑器在 `components/design-editor/`。

## 本轮改动

### 1. 清理设计器子系统里 V1 表结构的陈旧注释（已改）

改了 7 个文件的注释：`TableDesignEditor.vue`、`FormDesignEditor.vue`、`useStructureEditing.js`、
`FormPreview.vue`、`fieldDefaults.js`、`dataChanges.js`、`schemaRender.js`。
统一改为「对外只读写 `s_module_schema.b_schema_json`，行与分组是编辑器内部草稿」。

顺带查实两条**代码事实**（不是注释问题，未改，需用户决定）：
- `TableDesignEditor` 的 `mode="subtable"` **已无宿主**（全项目只有 `ModuleListConfigPanel` 用 `mode="list"`）；
  与之绑定的 `editMode` ref / `onEditModeChange` / `EDIT_MODE_OPTIONS` / 头部 Segmented 全是死代码
  （`editMode` 只在 `v-if="isSubtable"` 分支渲染，而 isSubtable 恒为 false）。
- `fieldDefaults.js` 的 `createListConfigRow` **无调用点**（只有 `listRowDefaults` / `queryRowDefaults` /
  `createQueryConfigRow` 在用）。按 `开发规范.md`「没有调用点的代码必须删除」应删。

### 2. 删除 `ai-plans/TASK1.md`（已删，目录随之为空已移除）

无其他文件引用它。

### 3. 树逻辑抽取调研（只出结论，未改代码）

全项目宿主树拖拽恰好 3 处，约 55 行核心算法**逐行一致**：
`module-management/index.vue:651`（100 行）、`menu-management/index.vue:212`（107 行）、
`base/othercompany/index.vue:445`（63 行）。差异只有：树 ref 名、提示文案、类型守卫字段
（`b_module_type` / `b_menu_type`）、未保存集合、表名、基线同步、失败重载。

结论：
- **该抽**，抽成 `@/utils/tree.js` 的纯函数（如 `computeTreeMove`），页面只留落库 + 基线同步 + 重载。
- **不放 FmsTree**：它 148 行纯展示（字段名映射 + i18n 标题 + 虚拟根），零 API 依赖；
  且 6 个消费方里 3 个只读（`otherdata` / `ModulePickerModal` / `FileCategoryPanel`）。
- **不放 FmsModuleListPage**：`components/fms-module-list/` 下 grep `tree|b_parent_id|b_depth|b_path|dropPosition`
  零命中，树与列表是并列关系（左树右表），塞进去是倒挂依赖。
- **不合并 ModuleTreePanel / MenuTreePanel**：两文件 477 行零相同行，且 `开发规范.md` 第 8 条
  原文点名「模块树与菜单树先各自平铺，等共性真正清晰后再合并」。

抽取时要保留的行为差异：`othercompany` 失败也重载（"以库里为准"），module/menu 只在失败时重载。

### 4. 树拖拽抽取落地（已改，本轮核心）

在 `fms-vue/src/utils/tree.js` 末尾新增纯函数 **`computeTreeMove(nodes, options)`**（约 95 行含 JSDoc）。
一次调用完成：成环拦截 → 摘除 → 挂载 → 兄弟重排（`renumberSiblings`）→ 整树重建 `b_depth`/`b_path`
（`rebuildTreePositions`）→ 变化时补写 `b_parent_id`。返回
`{ ok:true, updatedRows, moved, parentChanged }`，失败返回 `{ ok:false, reason, message }`，
`reason ∈ self | notFound | cycle | notContainer | unsavedTarget`，文案由调用方经 `messages` 传入。

入参：`dragKey` / `dropKey` / `dropPosition('before'|'inside'|'after')`，
可选 `typeField` + `nonLeafValues`（inside 落点类型守卫）、`isUnsaved(id)`（草稿临时 id 不能当父级）。

**三个调用点已改写，行为保持不变**：
- `module-management/index.vue::onModuleDrop`：100 → 约 50 行（`typeField: b_module_type`）
- `menu-management/index.vue::onMenuDrop`：107 → 约 28 行（`typeField: b_menu_type`）
- `base/othercompany/index.vue::onCategoryDrop`：63 → 约 18 行（无类型守卫，失败也重载）

三个文件的 `@/utils/tree` import 均已收敛：`addRowUpdate` / `findNodePosition` /
`rebuildTreePositions` / `renumberSiblings` 已从页面移除（它们仍是 `computeTreeMove` 的内部实现）。

**踩坑**：`tree.js` 追加函数时多留了一个 `}`（第 412 行），导致 vite 报
`Failed to parse source for import analysis`，整个 `utils.spec.js` 无法运行。删掉即好。

### 5. `computeTreeMove` 单测（已加）

`tests/unit/utils.spec.js` 新增 `describe('utils/tree computeTreeMove：拖拽移动的守卫与落库行')`，12 个用例，
覆盖 5 条拒绝路径（self / notFound / cycle / notContainer / unsavedTarget）与
inside 换父、before/after 跨父与同级换序、同组索引修正、无变化时 `updatedRows` 为空。

写测试时踩到两个**自己对实现的误解**（代码是对的，断言错了）：
- `isLeaf` 只在 `dropNode.children` 为 falsy 时才补空数组并置 false；fixture 里给叶子写了
  `children: []`（truthy）就不会走该分支。要测就造**没有 children 字段**的节点。
- 同级换序后若 `b_xh` 重排结果与原值相同，`renumberSiblings` 不会产生 update，
  该节点在 `updatedRows` 里查不到（`rowById(...)` 返回 `undefined`），别断言它有值。

顺带清了该文件两处既有 lint 问题（unused `vi`、`Folder` 提升为模块级 `FolderIcon`），
测试 helper `makeMoveTree` / `rowById` 也提到模块级以满足 `consistent-function-scoping`。

### 环境情况

- `pnpm lint`（123 warnings + 3 errors，`no-underscore-dangle`）与 `pnpm fmt:check`（155/293 文件）
  **均为既有失败**，不是本轮引入。
- `pnpm vitest run tests/unit`：10 failed / 144 passed，失败项全是既有问题：
  `module-list-utils.spec.js` 导入了不存在的 `@/components/fms-module-list/moduleListUtils`；
  `_scratch-freeze.spec.js` 是临时 repro；其余是查询条件 UI 测试（`fms-module-list-page` /
  `module-list-components` / `module-pref`）。树相关 4 个 suite 全绿（51 passed）。
- git 对象库损坏（`git stash` / `git diff` 报 `unable to read <sha>` / `no initial commit`），
  无法用 git 做前后对比，验证时改用「改前改后各跑一次测试」的方式。
- `vite build` 会被本机 safe-delete 守卫拦下（`SAFE_DELETE_BULK_CONFIRM_REQUIRED`，一次要删
  `dist/assets` 下 672 个文件 > 阈值 50），与代码无关；要验证构建需换输出目录
  （`--outDir dist-verify --emptyOutDir`）。

### 6. 新增「系统管理 / 用户管理」路由占位（已改）

- 新建 `fms-vue/src/views/system/user/index.vue`：**空壳占位页**（只有空 div + 注释），
  待实现内容为左部门树（`b_dept`）+ 右用户列表（`b_user`）。
- `fms-vue/src/router/routes.js` 路由分组风格**统一为 /module 的写法**（本轮第二稿：
  原先 `/system/user` 用绝对路径、`/base/*` 是散列写法，均已归并）：

  ```js
  { path: '/base', children: [ { path: 'othercompany', name: 'base-othercompany', ... } ] }
  { path: '/module', meta: { adminOnly: true }, children: [ ... ] }
  { path: '/system', children: [ { path: 'user', name: 'system-user', ... } ] }
  ```

  三个分组节点一律：**不写 component、不写 redirect**，子页 path 写相对路径
  （含 `'othercompany/detail'`、`'contact/detail'` 这种两级相对路径，vue-router 支持）。
  完整路径（`/base/othercompany/detail` 等）与 `name` 全部保持不变 → 详情页内部的跳转、
  `AppSidebar` 里写死的 `/module/*`、`tests/router-menu-guard.spec.js` 的断言都不用改。

  去掉 `redirect` 的**理由**（原 `/module` 与 `/system` 都配了 redirect 到首个子页）：
  分组只是归类，不该自带「默认落地页」语义 —— 否则直接访问裸前缀 `/module`、`/base`
  会静默落在某个业务页上，形成「菜单里没配、却能进」的第二入口。去掉后裸前缀交给表尾
  `/:pathMatch(.*)*` 兜到工作台，业务入口一律由 `s_menu` + 菜单管理的「路由地址」维护。

- 未配 `moduleId`（`/system/user` 无对应 `s_module` 记录，配了会被权限守卫按无权限拦回工作台）。
- `/module` 的 `meta.adminOnly: true` **保留在分组节点上**（守卫按 `to.matched.some(r => r.meta.adminOnly)`
  判断，分组节点带标记即可覆盖整组子页），`collectMenuRoutes` 也靠它整组排除。

踩到的要点（新增页面路由时需遵守）：
- `meta.componentName` 必填且全局唯一：页签标签同时是 keep-alive 的 `include` 名。
- `meta.title` 决定页签是否出现（`AppTabs` 只在有 title 时 `addVisitedTab`）；三者缺一页签链路就断。
- **分组节点绝不能带 component**（哪怕只加一层无 router-view 的壳）：`resolve()` 的 `matched`
  会多出一条中间层记录（vue-router 会把中间节点的 path 推进 matched，即使它没有 components），
  一旦该节点有 component，路由层级判断就会变。校验方式：
  `resolved.matched.filter(r => r.components).map(r => r.path)` 必须只有 `['/', '<页面完整路径>']`。
- 分组改造的**回归验证方式**：枚举所有页面 fullPath 跑 `router.resolve()`，断言
  「路径仍能解析 + `name` 不变 + components 链只有 layout 与页面自身」，
  再加一条「裸前缀不落在任何页面」（`matched.some(r => r.components) === false`）。

顺带修了两个**既有 lint error**（都不是本轮引入）：
- `src/components/fms-tree/FmsTree.vue:47`：`export const ALL_CATEGORY_KEY` 违反 vue
  `no-export-in-script-setup`；该常量**无任何外部引用**（注释已写明"调用方不需要也不应引用"），
  去掉 `export` 即可。
- `tests/router-auth.spec.js:88`：`const pinia = createTestPinia()` 声明未使用，
  `createTestPinia()` 靠副作用生效 → 直接改成表达式语句（不要加 `_` 前缀，eslint 的
  `no-unused-vars` 配置此处不认下划线豁免）。
- 剩余 1 个 error 是既有问题：`src/components/fms-table/utils/createCellRenderer.old.js:214`
  未使用参数 `editingActive`（`.old.js` 文件本身疑似待删除的残留）。

### 7. FmsTree 接管 loading 与「全部分类」虚拟根约定（已改）

用户提的两点：loading 收到 FmsTree 内部维护；`ALL_CATEGORY_KEY` 交给内部处理。

**结论与落地**：

- **loading**：FmsTree 新增 `loading` prop，内部渲染 `.fms-tree__loading`（绝对定位居中 `Spin`
  + 60% 白遮罩），并留 `#loading` 插槽覆盖。**注意是覆盖层而非 v-else**：树始终渲染，
  避免加载完成后尺寸跳动。5 个消费方各自那份 loading 标记与 CSS 全部删除：
  `othercompany`（`.oc-tree-panel__loading`）、`otherdata`（`.od-tree-panel__loading`）、
  `FileCategoryPanel`（`.fc-panel__loading`）、`ModuleTreePanel`/`MenuTreePanel`（原
  `.mm-tree-empty`「加载中...」纯文本，且是 `v-if/v-else` 替换式，已一并统一为遮罩）。

- **虚拟根选中约定**：FmsTree 内部完成 `[]` ⇄ 虚拟根的双向映射 ——
  传入空选中键 → 渲染时补成 `[rootKey]` 让根高亮；`select` 事件里点中根 → 回传 `[]`。
  调用方用「falsy 的选中键」表达「全部」，**不再需要 import 或书写 `__fms_tree_root__`**。
  选这个方案（而不是 `v-model:selected-keys`）的依据：5 个消费方里已有 4 个本来就用
  falsy 值表示「未选中」（`otherdata` 用 `''`、`FileCategoryPanel` 用 `''`、
  两个 TreePanel 用 `null`），且都用同一个表达式 `x ? [String(x)] : []` 派生；
  方案一只是把这个既有约定泛化，`v-model` 反而与两个纯展示型 TreePanel 的定位冲突。
  常量随之改为 `FmsTree` 内部 local const（**不能 export**：`<script setup>` 禁止 ESM 导出，
  此坑在本日更早一轮已踩过并记录）。

**踩到的一个真 bug（我的回归，被测试抓到）**：
`effectiveSelectedKeys` 一开始写成读 `props.selectedKeys`，但 FmsTree **没有声明**该 prop
（它走 `$attrs` 透传），于是 `props.selectedKeys` 永远 `undefined`，非空选中项被覆盖成
虚拟根 → 表现为「选中任意分类，高亮的却是全部分类」。改用 `useAttrs()` 取值后修复。
写成了一个单测（选中业务节点时虚拟根不高亮）锁住。

**顺带修掉的既有回归（来自本日第 4 节的抽取）**：
`othercompany/index.vue::onCategoryDrop` 里写了 `updatedRows` 但没解构
（`const { updatedRows } = result` 漏了），`try/catch` 把 `ReferenceError` 吞成
「排序更新失败」，**拖拽分类实际完全不落库**。被 `tests/views/othercompany.spec.js`
的「跨级拖入时同批落库」用例抓到，已补上解构。教训：抽取后可运行的用例比肉眼比对可靠。

**验证**：新增 `tests/components/fms-tree.spec.js` 的 11 个用例（选中约定 6 + loading 4 + 插槽 1）。
FmsTree 28/28、othercompany 视图 9/9、utils 35/35、tree-external-drag 3/3、othercompany-utils 4/4
全绿；改动 8 文件 lint 0 warnings 0 errors；`vite build` 通过。
全量 384 passed / 13 failed，失败项仍全是既有问题（query-UI / router-auth / login / scratch repro）。

### 8. collectDescendantIds 抽取到 @/utils/tree（已改）

用户：「这个需求可能以后还比较多」→ 抽成公用。

**先查了有没有现成的**：`components/ui/tree/utils.js` 已有 `collectDescendants(rootKey, childrenMap)`，
但它作用于**已构建好的嵌套树 + 预计算 childrenMap**（供勾选联动用），
而业务页面从库里拿到的是**扁平行**（b_parent_id 邻接表），两者不能混用。
所以新增的是扁平行版本，放进 `@/utils/tree.js`，与 `buildSortedTree` / `applyTreePosition` 同族。

签名：`collectDescendantIds(rows, rootId, { idKey = 'b_id', parentKey = 'b_parent_id' } = {})`
返回「自身 + 全部下级」的 ID 数组（统一转字符串）。JSDoc 里写明了与 ui/tree 那个的区别，防混用。

**刻意保留的两个语义**（抽取不等于顺便改行为）：
- `visited` 兜环：b_parent_id 无外键约束，脏数据成环不能死循环；
- **rootId 不在 rows 里时仍返回 `[rootId]`**：拼成 `IN ('不存在')` 自然查不到数据，语义安全，
  调用方不必额外判空。这条写进 JSDoc 并配了单测。

新增 8 个用例（含数值/字符串 ID 混用、成环、自引用、字段名覆盖）。
`othercompany` 改为 `collectDescendantIds(categories.value, selectedCategoryKey.value)`。
utils 43/43、othercompany 视图 9/9 全绿，lint 0，`vite build` 通过。

**未动的一处同类逻辑（留给用户决定）**：`otherdata/index.vue` 的 `isDescendantOfRoot`
用 **b_path 前缀匹配**判断子孙（且排除根自身），与本次按 b_parent_id 展开是两种思路。
按 `FMS新系统核心表结构设计.md`，b_parent_id 才是权威关系、b_path 是派生字段，
理论上应该统一到新函数；但那会改动一个没坏的功能，按「只改必需文件」没动。

### ⚠️ 并发编辑警告（重要，影响后续所有验证）

本轮发现**有另一个会话在同时改这个工作区**：`src/router/routes.js`（19:47）与
`src/views/system/user/index.vue`（19:32）都不是本会话改的（对应本文件第 6 节的「用户管理路由占位」）。
它把路由分组节点的 `redirect` **去掉了**，并改了文件头注释：
「分组节点不配 redirect：分组只是归类，不该自带默认落地页语义 —— 直接访问 /base、/module
这类裸前缀时交给表尾的 /:pathMatch(.*)* 兜到工作台」。
于是 `/module` 现在 → `/dashboard`，而 `tests/unit/router-nested-groups.spec.js:30`
仍断言旧的 `/module/module-management`，**该用例随之失败**（全量 13 → 14 failed）。

这是**并发改动导致的陈旧测试**，不是本轮回归（本轮没碰 routes.js）。未擅自修改：
该文件属于那个会话，且新行为看起来是有意设计。**需要有人决定改测试还是改设计。**

教训：本工作区当前不可假设「只有自己在改」，验证结论时要先确认失败项是不是自己引入的
（可用 `find src tests -mmin -N` 按 mtime 排查）。

**后续处理（已改测试，未动 routes.js）**：确认工作区在 20:00 后无新并发改动后，
把 `tests/unit/router-nested-groups.spec.js` 对齐到新设计 —— 只改测试、不碰 routes.js，
避免与那个会话冲突：
- 文件头补上第二条分组约束（无 component **且**无 redirect）；
- 原用例「重定向到首个子页」改成「裸前缀兜到工作台」，`/module` → `/dashboard`
  （用例本意「不白屏」保留，只是落点变了）；
- 新增一条断言锁住设计：解析 `/module/i18n-type` 后 `matched[1]` 的 components 与
  redirect 均为 falsy。
踩坑：`/module` 嵌在 DefaultLayout children 里，顶层 `routes.find()` 找不到，
要改用 `router.currentRoute.value.matched[1]` 取分组记录。
结果：该 suite 4/4 通过，全量回到 **13 failed / 395 passed**（正是改动前既有基线），本轮零新增失败。

### 9. otherdata 子树裁剪统一到 collectDescendantIds（已改，收尾）

把第 8 节末尾「留给用户决定」的 `otherdata/index.vue::isDescendantOfRoot` 一并统一了。
动机是验证抽取真的可复用（用户说「这个需求可能以后还比较多」），且原实现有个**自相矛盾**：
同一个函数里「向下裁剪子树」用 `b_path` 前缀匹配，而紧接着「向上回溯祖先」用 `b_parent_id`，
两个权威源。按核心表结构文档 b_parent_id 才是权威、b_path 是派生，二者不一致时同函数会算出矛盾结果。

改法：

```js
const scopedIds = root ? new Set(collectDescendantIds(all, ROOT_MODULE_ID)) : new Set()
scopedIds.delete(ROOT_MODULE_ID) // 根是本页入口，不进树
const scoped = all.filter((item) => scopedIds.has(String(item.b_id)))
```

**做法：先针对旧实现写测试，再改**。新建 `tests/views/otherdata.spec.js` 5 个用例，
先在**未改动的 b_path 版本**上跑通 4/4，改完再跑仍 4/4（行为一致），
然后补第 5 条锁住 b_path 与 b_parent_id 冲突时以 b_parent_id 为准 → 5/5。
这条经验可复用：**重构前先给旧行为拍快照测试**，比肉眼比对可靠（第 7 节那个漏解构的 bug 也是这么抓到的）。

自引入 2 个 lint warning（`module_` 触发 no-underscore-dangle、`.sort()` 应 `toSorted()`）已修，
`oxfmt` 格式化后 lint 0 warnings 0 errors。

最终验证：`vite build --outDir dist-verify --emptyOutDir` 通过（15.82s），dist-verify 已清理；
相关 5 个 spec 89/89 全绿（utils 43 / fms-tree 28 / otherdata 5 / othercompany-utils 4 / othercompany 9）；
全量 **13 failed / 400 passed**（413 tests / 46 files），失败项仍是既有基线，通过数 395 → 400（+5 新用例）。

### 10. 用户拍板（2026-09-15 晚，后续照此执行）

- **设计器死代码 → 暂时保留，不删**。
  `TableDesignEditor` 的 `subtable` 分支（`isSubtable` 恒 false）与 `fieldDefaults.js::createListConfigRow`
  （零调用点）**都不要动**。虽然 `开发规范.md` 有「没有调用点的代码必须删除」，但
  `TableDesignEditor.vue:18` 的注释已把 subtable 标为「V2 移除 b_edit_mode 后已无宿主，**暂未启用**」——
  是前人有意为未来子表编辑留的骨架，不是无意遗留。再有人提删除时先回看这条。
- **13 个既有测试失败 → 暂时不管**。非本轮引入，是改动前基线（query-UI / router-auth / login / scratch repro）。
- **`collectDescendantIds` 抽取 → 用户确认没问题（已认可）**。

**otherdata 的页面定性（用户原话「比较特殊，只需要列下来就可以了，不参与编辑什么的」）**：
它是**只读展示页**——左侧 `s_module` 子树只负责列出来，不在这页增删/拖拽分类，分类结构一律去
「模块管理」维护。所以 `computeTreeMove` 对它不适用，只有 `collectDescendantIds`（读路径）相关。
这一点决定了改它的风险面：只在读路径，不写库。

**关于 b_path / b_parent_id 潜在不一致（未验证，待用户决定）**：
第 9 节那处改动的前提是「存在 b_path 未同步的脏数据」。**库里到底有没有，没查过** ——
远端生产库 `118.89.70.199:1433` 属外部系统，未经用户同意不应连接。
若要验证，只读校验 SQL 大致是（对比「父级 b_path + 自身 b_id」与自身 b_path）：

```sql
SELECT c.b_id, c.b_parent_id, c.b_path, p.b_path AS parent_path
FROM s_module c LEFT JOIN s_module p ON p.b_id = c.b_parent_id
WHERE c.b_path <> ISNULL(p.b_path, '/') + CAST(c.b_id AS varchar(200)) + '/'
```

本地只有 `config/dbconfigs/G3HD.properties` 与 `G3HY2025.properties`，**没有 FMS（新库）的配置**，
要连得先补 `FMS.properties` 或用同服务器凭据直连。

**顺带结论（本轮扫尾查证）**：树逻辑抽取已无遗漏 ——
全项目 `b_path` 前缀匹配找子孙的实现已清零（余下全是 `ORDER BY b_path` 与新增时派生赋值）；
业务侧 3 处 drop 处理器（`module-management` / `menu-management` / `othercompany`）**全部**走 `computeTreeMove`；
`components/ui/demo/tree.vue` 的裸 drop 是组件库 demo（演示低层 API，不应改用业务工具），
`FileListPanel.vue` 的 `handleDrop` 是文件上传（`dataTransfer.files`），均与树无关。

### 11. 模块中心侧栏图标 Settings → Blocks（已改）

`src/layouts/components/AppSidebar.vue`：`STATIC_MODULE_MENU.icon` 由 `Settings` 改为 `Blocks`，
import 同步替换（`Settings` 该文件内**仅此一处**使用，改后无残留引用，删掉即可）。

要点备忘：
- 模块中心的图标**不在 `s_menu` 里**，是代码写死的静态入口 `STATIC_MODULE_MENU`
  （超管工具导航不进 s_menu，避免被「菜单管理」误删后无入口修复）。要改它的图标就改这里，
  不要去数据库/菜单管理找。
- 同文件顶部还有 `{ title: '工作台', icon: LayoutGrid }`、`{ title: '组件库', icon: Component }`
  两个固定入口，以及 `icon: Settings` 之外的 `getIcon(node.b_icon)` 动态菜单图标解析
  （走 `@/utils/lucideIcons.js`，自动注册整个 `@lucide/vue`，接受 `lucide:block` 等写法）。
- 新增图标只需从 `@lucide/vue` import；`Blocks` 已确认在 `node_modules/@lucide/vue/dist/lucide-vue.d.ts` 中存在。

验证：lint 0/0；`menus.spec.js` + `router-menu-guard.spec.js` + `router-nested-groups.spec.js`
共 11/11 通过（**测试只断言入口存在与路由权限，不断言图标**，所以换图标不影响用例）；
`vite build` 通过（16.1s）。

### 12. 用户管理页（/system/user）落地：左部门树 + 右用户列表（已改）

用户需求：「在 http://localhost:5082/system/user，模块我还没创建，你看着办」。

**先做的调研**（结论决定了实现方式）：
- 项目里已有 2 个同构先例：`base/othercompany`（分类树+单位列表）、`base/otherdata`（模块树+数据列表）。
  三者都是「左侧一棵树 + 右侧 FmsModuleListPage + 选中即过滤」，**用户与部门的主从关系也属于这一类**。
  理由：`b_user.b_dept_id` → `b_dept.b_id`，「按部门筛人」「给部门加人」是最高频动作，同页体验最好。
- 决定性证据：`FMS业务表设计.md:235` 的视图里已经在 `left join dbo.b_dept d on d.b_id = u.b_dept_id`，
  说明 b_user / b_dept 是**既有核心表**（在 `sql/fms_core.sql` 建，不是本次要新建的）。

**产出三个文件**：

1. **`fms-vue/src/views/system/user/DeptTreePanel.vue`（新建，约 450 行）**
   部门树面板，自管加载 / 增删改 / 搜索 / 拖拽（拖拽走 `computeTreeMove`，与 othercompany 同构）。
   选中结果用 `defineModel('selectedKey')` 抛给编排层；`defineExpose({ reload })`。
   删除守卫两条：有子部门不让删；部门下有用户（查 `b_user.b_dept_id`）不让删。

2. **`fms-vue/src/views/system/user/index.vue`（占位页 → 实现）**
   编排层只做三件事：选中部门 → `fixedSearchCondition`（`collectDescendantIds` 含全部下级）、
   新增用户时补默认部门、用户增删改（`FmsModuleEditModal` + 批量删除）。
   按「面板式配置页」思路把树抽成独立组件，以后部门要是独立成页可直接搬走。

3. **`fms-vue/tests/views/system-user.spec.js`（新建，9 用例）**
   锁三块行为：选中部门→查询条件（含全部下级 / 只含本分支 / 叶子只匹配自身 /
   **b_path 与 b_parent_id 冲突时以 b_parent_id 为准**）、新增补默认部门（4 种边界）、未选中不加条件。

**`FmsModuleEditModal` 的钩子契约（踩坑，值得牢记）**：
`onBeforeSave(row, { isNew, record })` —— 签名里**没有 formData**，第一个参数就是**合并后的完整行**，
且在组装 `inserts` 之前调用，所以直接改 `row.b_dept_id` 即可。
**不要用 `extraUpdates`**：那条路径只作用于 `updates`，新增场景（`inserts`）拿不到。
（`FmsModuleListPage` 的 `reload` / `deleteSelected` 均已 `defineExpose`，可直接调。）

**测试踩的最大一个坑（已写进 MEMORY.md）**：
`tests/helpers/app.js` 的 `mountPage` 内部是 `shallowMount`，会打桩所有子组件。
给布局容器打桩时键名必须是 **Vue 推断出的组件名** —— `Splitter`/`SplitterPanel` 的 SFC
文件名是 `splitter.vue` / `panel.vue`，推断名是 **`'splitter'` / `'panel'`**，不是 `'SplitterPanel'`。
写错键 → 匹配不上 → 容器成空壳 → 插槽不渲染 → 页面 `depts` 恒为空，
表现成「查询条件只剩自身」，很容易误判成业务逻辑 bug。
另：`mountPage` 的 `global` 选项会**整体覆盖**内部 `stubs`，别在 `global` 里再写 `stubs`（我调试时踩过）。

**同时产出的 SQL 脚本 `sql/fms_module_user.sql`（需用户执行，我没有库凭据）**：
- 建查询视图 `v_b_user`（`left join b_dept` 取 `v_dept_name` 派生列）；
- 注册模块 `v_b_user`（parent `system`，view_table `v_b_user`，save_table `b_user`，key `b_id`）；
- 12 个 `s_field`；view / edit / query 三份 `s_module_schema` JSON；
- 菜单仅在已存在同路由时修正，**不擅自新建菜单行**（s_menu 由「菜单管理」维护）；
- 末尾带自检 select。

**未验证的部分（要用户确认）**：
- 我**没有连库**（无 FMS 库凭据，且属远端生产环境 `118.89.70.199`）。所以：视图、模块注册、
  b_user/b_dept 是否已真正建表，**全部未验证**；脚本只是按 `sql/fms_core.sql` 与文档写的。
- 页面在没有模块元数据时**能打开**（`/system/user` 无 `meta.moduleId`，守卫不拦），
  但右侧列表会因取不到 `s_module` 配置而空 —— 属预期，执行 SQL 后即可用。

验证：新增 2 文件 lint 0 warnings 0 errors；`system-user.spec.js` 9/9；
`vite build --outDir dist-verify` 通过（产物含 `user-*.js`，已确认页面进包）；
全量 **13 failed / 412 passed**（425 tests / 47 files），失败项仍是既有基线，**零新增失败**。

（**踩到的环境坑**：构建第一次报错，原因是 `--emptyOutDir` 与我在同一时刻跑的手动清理
`find dist-verify -delete` 撞车；重跑即通过。教训：清理临时目录别与构建并行。）

**收尾补的一个功能漏洞（自查发现）**：
`onEdit` 写好了但**没有接线**——列表没传 `row-actions`，导致用户只能新增/删除、**永远不能编辑**。
按 `开发规范.md`「没有调用点的代码必须删除」，这属于必须处理的死代码；
但正确做法是**接线而非删除**（编辑用户是必需功能）。
已补 `rowActions`（computed：edit 恒有 + delete 受 `canDeleteRow` 控制），
删除走 FmsTable 内置 confirm（与 i18n-type / contact 一致，不手工 Modal.confirm），
模板加 `:row-actions` 与 `:inline-action-limit="2"`，工具栏按钮补 `rowSaving` 禁用守卫。
补 3 个用例（12/12）：edit 操作存在且把该行交给弹窗、有删除权限时 keys = ['edit','delete']、
新增时清空 editingUser。

**踩坑**：断言 `editingUser` 用 `toBe` 会失败——它是 ref，读出来是**响应式代理**，
与传入的原始对象不同一（报错信息是误导性的 "serializes to the same string"）。用 `toStrictEqual`。

最终：lint 0/0；`system-user.spec.js` **12/12**；`vite build` 通过；
全量 **13 failed / 415 passed**（428 tests / 47 files），失败项仍是既有基线，零新增失败。

## 13. 用户授权连库 → `sql/fms_module_user.sql` 已实际执行并端到端验证

用户给了凭据路径 `fms-api/config/dbconfigs/G3HD.properties`（→ `118.89.70.199:1433` / `FMS` / sa）。

**本机没有 sqlcmd / pymssql / pyodbc**，但发现两条现成资源：
`/c/Users/admin/.m2/repository/com/microsoft/sqlserver/mssql-jdbc/13.4.0.jre11/mssql-jdbc-13.4.0.jre11.jar`
和 `/d/devtool/jdk/jdk17/bin/java`。于是写了个一次性 `SqlRunner.java`（按独立成行的 `GO` 分批执行 + 打印结果集）。
**这个套路以后可直接复用**（脚本已删，代码思路见下）。

**执行前先探查，结果与我的草稿假设差很多（重要）**：
- `s_module` **主键就是 `b_id`**，没有 `b_module_code` / `b_route` 列；它**本身也是一棵树**
  （`b_parent_id` / `b_depth` / `b_path`），另有 `b_module_type`（取值 `module` / `data`）、
  `b_query_sql`、`b_config_json`。我原稿里的 `b_module_code` / `b_route` 全是错的。
- `s_field` 主键是 **`(b_module_id, b_field)`**，没有 `b_id`；列为 `b_field`/`b_name`/`b_i18n`/`b_type`/`b_canuse`/`b_xh`。
- `s_module_schema` 主键是 `(b_module_id, b_schema_type)`。
- `b_user` / `b_dept` **确实已由 `fms_core.sql` 建好**（2026-09-11 建的）；`b_user` 2 行（`001`、`g3soft`），
  **`b_dept` 0 行**（还没建部门）。
- `s_menu` 里**已经有 `b_id = 'user'` 的 page 菜单**（route `/system/user`），但没有 `s_menu_module` 绑定。

**据此改了脚本**（`sql/fms_module_user.sql`）：
- 模块行 `b_id = 'v_b_user'`、`b_parent_id = 'system'`、`b_depth = 1`、`b_path = '/system/v_b_user/'`，
  `b_module_type = 'data'`，`b_order_sql = null`（跟随既有模块惯例，不写 `b_id ASC`）。
- **补了原稿漏掉的 `s_menu_module` 绑定**（`user` → `v_b_user`）——这是让侧栏入口出现在角色
  「菜单权限」树里、可被授权的关键。没有它，非超管看不到也授不了权。
- 保留「不新建菜单行」原则：菜单已存在，只做绑定 + 校正 route/path。

**执行结果**：12 个批次全绿，自检 6 项全对 —— 模块 1 / 字段 12 / 界面配置 3 / 菜单绑定 1 / 视图列 12 / 视图数据行 2。

**端到端验证（走真实后端 8088，比看 SQL 结果强得多）**：
- 登录：`POST /api/auth/login`，字段是**小写** `orgid` / `userid` / `password`（不是 orgId/username！），
  `orgid` 必须传 `G3HD`，否则报「机构码不能为空」。
- `POST /api/data/page`：参数为 `view_name` / `order_by` / `search_columns`（**真 JSON 数组**，不是字符串）/
  `search_condition` / `page_no` / `page_size`。用 `pageindex`/`pagesize`/字符串化的 search_columns 都会报错。
- 验证通过：`v_b_user` 返回 2 行且 `v_dept_name` 正常；`b_dept` 树加载正常；
  `[b_dept_id] IN ('d_x')` 这种 `collectDescendantIds` 拼出的条件是合法 SQL（返回 0 行）。
- **写路径也验了**：`POST /api/data/saveobjt` 的 body 是数组、每项必须带 **`key_field`**
  （`[{table, key_field, deletes, updates, inserts}]`，按 delete→update→insert 顺序执行）。
  实测建部门 `d_test` → 建挂在它下面的用户 `u_test` → 查 `v_b_user` 确认 `v_dept_name` 联出「测试部门」。
  **验证后已把 `u_test` / `d_test` 全部删除**，`b_user` 恢复 2 行、`b_dept` 恢复 0 行。