20260804223152

code/fms/CODEBUDDY.md

@@ -87,17 +87,16 @@ Vue 3 `<script setup>` SFCs, Pinia for state, **antdv-next** components (auto-im
 Feature code should call these, or wrap them in a dedicated service like `src/services/moduleManagement.js` (e.g. `loadModuleConfiguration`, `nextIds`, `saveChanges`). Do not introduce new backend URLs from the frontend — reuse the generic endpoints.
 
 ### Routing & permissions
-- `src/router/pageComponents.js` is the explicit hand-written component whitelist. `routes.js` registers components from it.
-- `AppSidebar` reads `v_s_function_node`; the route guard checks the matching FunctionNode route.
-- `stores/permissions.js` reads effective FunctionNode, PageNode and Action permission views. Roles are primary and direct user grants are additive; super access is role-based, not account-name-based.
-- Enforcement is currently frontend-only; backend data-scope and write interception remain reserved.
+- `src/router/index.js` registers view components via **static explicit `import()`**, not a dynamic whitelist. Data-backed routes carry `meta.dataCode` (e.g. `d_login_log`), plus `menuKey`, `title`, `requiresAuth`; legacy system pages without data nodes may temporarily use `meta.moduleCode`.
+- A `beforeEach` guard checks auth, then resolves `meta.dataCode` to its parent page and checks that page's `b_user_module` grant. `src/stores/permissions.js` loads `s_module` / `b_user_module` / `b_user_power` / `s_module_power` and gates page entry and button enable/disable. Currently permission enforcement is **frontend-only**; backend interception is not yet implemented.
+- `src/layouts/components/AppSidebar.vue` still uses a hardcoded `fallbackMenuItems` array. It should fall back to this static menu when the generic-interface module load fails.
 
 ### State & i18n
 - Pinia stores: `stores/auth.js` (token/user, persisted), `stores/app.js` (locale, sidebar collapse, visited tabs), `stores/permissions.js` (module/power grants).
 - i18n: `app` store holds `locale` (default `zh-CN`); translation text comes from the DB `b_i18n` table (loaded via `loadModuleConfiguration`), not vue-i18n.
 
 ### Module management feature
-`src/views/module-management/index.vue` coordinates three areas: FunctionNode structure, PageNode composition, and Module resources. Editing state and persistence live in dedicated composables and panels. The authoritative schema and migration order are in `新数据库结构.md`; IDs and technical codes are immutable, and bigint IDs are frontend strings.
+`src/views/module-management/` holds `ModuleManagementView.vue` plus `components/` panels (`ModuleTreePanel`, `ModuleBasicInfoPanel`, `ModuleFieldDefinitionPanel`, `ModulePowerPanel`, `ModuleTranslationsPanel`). Demo data lives in `src/data/moduleDemo.js` — the real page must not depend on it. The table design (six tables: `s_module`, `s_module_field`, `s_module_power`, `b_user_module`, `b_user_power`, `b_i18n`) is in `新数据库结构.md`; follow that schema exactly. `s_module.b_id` is an immutable snowflake ID; `s_module.b_code` is a mutable, unique lowercase code (e.g. `m_biz`). Bigint IDs are returned to the frontend as strings.
 
 ## Cross-cutting conventions
 - Reuse existing components and antdv-next; extract shared logic into components/composables/services only when it genuinely reduces duplication. Keep new CSS scoped to the component.