feat：update 3 4

2026-07-02 10:04:32 +08:00
parent 604e7e68d7
commit 2fd8fc1f66
224 changed files with 12369 additions and 9 deletions
@@ -0,0 +1,73 @@
+---
+name: design-complex-business-module
+description: Use when designing a complex enterprise business module that needs RBAC permissions, frontend/backend permission controls, state transitions, illegal transition handling, audit logging, exception states, dashboard metrics, interface contracts, or acceptance-ready design assets.
+---
+
+# Design Complex Business Module
+
+## Core Principle
+
+Design the control surfaces before designing code. For complex business modules, produce permission, state, audit, exception, dashboard, and acceptance assets before implementation planning.
+
+Do not jump from a requirement to CRUD code. Every business rule must have an owner, a source, and a verification method.
+
+## Inputs
+
+Collect what exists, then mark gaps explicitly:
+
+- Business requirement or user stories.
+- Target project paths and project constraints.
+- Existing roles, permissions, menus, routes, API layer, backend controllers/services, data model, and audit/logging patterns.
+- Known non-goals and delivery deadline.
+- Existing rules, checklists, or project knowledge docs.
+
+If project evidence is missing, label outputs as `建议` or `待确认`, not `事实`.
+
+## Workflow
+
+1. Define scope: module name, actors, key workflows, non-goals, and acceptance boundary.
+2. Build the RBAC matrix: roles x features, with `允许`, `拒绝`, or `条件允许`.
+3. Translate RBAC into a permission control plan: page/menu, button, backend API, and data scope.
+4. Design the state machine: states, actions, allowed roles, preconditions, post-actions, and terminal states.
+5. List illegal transitions and rejection behavior.
+6. Design audit logging: actions, write timing, actor, target, old/new values, source/request id, masking, and failure behavior.
+7. Complete exception states: permission denied, missing data, invalid state, duplicate submit, validation failure, concurrency, empty dashboard, empty audit log.
+8. Define dashboard metrics: meaning, formula, dimensions, filters, data source, permission, empty state, and manual verification.
+9. Produce interface and acceptance notes only after the above assets are consistent.
+
+## Output Contract
+
+Generate these assets unless the user narrows scope:
+
+```text
+RBAC权限矩阵
+权限控制方案
+状态流转表
+非法流转清单
+审计日志SOP
+异常态清单
+看板指标字典
+看板接口验收记录
+不确定点清单
+```
+
+Use the templates in `assets/` when creating files.
+
+## Quality Gates
+
+- Every sensitive action has frontend visibility control and backend enforcement.
+- Data permissions are not replaced by button hiding.
+- Every state transition has a reverse or rejection story, or is explicitly terminal.
+- Every illegal transition has expected system response and validation method.
+- Every successful critical operation has an audit record; failed operations do not write success audit.
+- Every dashboard metric has a formula or filter logic that can be manually checked.
+- Every output distinguishes `事实`, `推断`, `建议`, and `待确认`.
+
+## Common Mistakes
+
+- Do not design UI first and add permissions later.
+- Do not use "admin can do everything" as a complete RBAC design.
+- Do not put all status rules into prose; use a state table.
+- Do not write "record audit log" without naming fields and write timing.
+- Do not define dashboard cards without metric formulas and data scope.
+- Do not turn project-specific permission strings into facts without source evidence.