20260803225403

code/fms/CLAUDE.md

@@ -82,9 +82,10 @@ Vue 3 `<script setup>` SFCs, Pinia for state, **antdv-next** components (auto-im
 `src/services/api.js` (on the axios wrapper `src/services/http.js`, baseURL `/api`) exposes `loginApi`, `loadDataApi`, `pageDataApi`, `saveObjectApi`, `nextIdApi`, `nextCodeApi`, `describeApi`, `loadDataBySqlApi`. Feature code should call these (or wrap them), never introduce new backend URLs from the frontend.
 
 ### Routing & permissions
-- `src/router/index.js` + `routes.js` register views via **static explicit `import()`**. Data-backed routes carry `meta.moduleId` (a data-module `b_code`, e.g. `m_metadata`, `s_login_log`), plus `title`, `section`, `menuKey`, `requiresAuth`.
-- The `beforeEach` guard checks auth, then loads the permission store and calls `canAccess(meta.moduleId)`.
-- `src/stores/permissions.js` loads `s_module` / `b_user_module` / `b_user_power` / `s_module_power`, resolves a `moduleId` to its parent **page** module through `s_module` (see `resolvePageId`), and checks the page grant. Account `g3soft` is a super-admin bypass. Permission enforcement is currently **frontend-only**; backend interception is not implemented.
+- `src/router/pageComponents.js` is the explicit hand-written page component whitelist; `routes.js` registers only keys from that registry.
+- `AppSidebar` reads `v_s_function_node`. The router guard authorizes the matching FunctionNode route.
+- `stores/permissions.js` reads the effective FunctionNode, PageNode and Action permission views. Roles provide primary grants; direct user grants are additive. Super access comes from `b_role.b_is_super`, never from an account-name bypass.
+- Permission enforcement is currently frontend-only; backend data-scope and write interception remain reserved.
 - Other stores: `stores/auth.js` (token/user, persisted), `stores/app.js` (locale default `zh-CN`, sidebar collapse, visited tabs).
 
 ### Shared components & utils
@@ -94,13 +95,13 @@ Vue 3 `<script setup>` SFCs, Pinia for state, **antdv-next** components (auto-im
 - `utils/dataChanges.js` — clone/diff/merge helpers for `saveobjt` (e.g. `diffRows`, `allocateTemporaryIds`, `remapForeignKeys`, `tableChange`, `hasChanges`); `utils/tempId.js`, `utils/tree.js`, `utils/i18n.js`.
 
 ### Module-management feature
-`src/views/module-management/index.vue` is a three-panel page (module tree + tabs) over `s_module`. Panels: `components/ModuleBasicPanel.vue`, `ModuleFieldsPanel.vue`, `ModuleListConfigPanel.vue`, `ModuleEditConfigPanel.vue`, `ModuleQueryConfigPanel.vue`, `ModuleAutoCodePanel.vue`, `ModulePowersPanel.vue`, `ModuleI18nPanel.vue`, plus `FieldGroupManager.vue` / `I18nQuickSetModal.vue`. `src/data/moduleDemo.js` is demo data — the real page must not depend on it.
+`src/views/module-management/index.vue` only coordinates three maintenance areas: FunctionNode structure, PageNode composition, and Module resources. State and persistence live in the three `composables/`; independent panels own editing UI. Resource configuration is saved through one `/data/saveobjt` transaction.
 
 ## Database & migrations
 
-- SQL Server; the migration scripts are `fms-api/config/migrations/` (numbered `000`–`026`, plus `verify_business_schema.sql`). They target the `FMS` database, assert the DB name, use `XACT_ABORT ON` + explicit transactions, and are idempotent (re-runnable).
+- SQL Server; the migration scripts are under `fms-api/config/migrations/`. Module cutover uses `033_create_module_structure.sql`, then `034_module_runtime_views.sql`, then the read-only `verify_module_architecture.sql`. The cutover is one-time and intentionally removes the old metadata model.
 - `config/migrations/tools/` has Java helpers to generate/run/verify business-schema migrations; `数据库迁移计划.md` documents the plan and 2026-07-29 execution results.
-- Core metadata tables: `s_module`, `s_module_field`, `s_module_field_group`, `s_module_field_list`, `s_module_field_edit`, `s_module_field_query`, `s_module_power`, `s_module_auto_code`, `b_user_module`, `b_user_power`, `b_i18n`, `b_i18n_type`. `s_module.b_id` is an immutable Snowflake ID; `b_code` is a mutable, unique lowercase code (e.g. `m_metadata`); `b_module_type` is `directory` / `page` / `data`. Follow `新数据库结构.md` exactly.
+- Core architecture is `s_module` plus type tables, `s_function_node`, `s_page_node`, `s_module_profile`, capability tables, and explicit role/user grant tables. IDs and technical codes are immutable. Follow `新数据库结构.md` exactly.
 
 ## Conventions (from `开发规范.md`)