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,63 @@
+# 安装说明
+
+## 方式一：安装到 Codex Skills 目录
+
+把 `skills/` 下的 4 个 Skill 文件夹复制到本机 Skills 目录：
+
+```text
+~/.codex/skills/
+```
+
+安装后目录应类似：
+
+```text
+~/.codex/skills/
+├── generate-project-constraints/
+├── design-complex-business-module/
+├── review-business-delivery/
+└── track-review-fix-loop/
+```
+
+每个 Skill 文件夹必须保留完整结构：
+
+```text
+skill-name/
+├── SKILL.md
+├── agents/
+│   └── openai.yaml
+└── assets/
+```
+
+## 调用方式
+
+在支持 Skill 的 AI 编程工具中，可以这样调用：
+
+```text
+Use $generate-project-constraints 为当前项目生成 AI 开发约束。
+Use $design-complex-business-module 设计这个业务模块的权限、状态、审计、异常态和看板。
+Use $review-business-delivery Review 这批阶段交付物。
+Use $track-review-fix-loop 根据 Review 报告生成修复闭环记录。
+```
+
+## 方式二：作为团队资产库使用
+
+如果当前 AI 工具暂不支持原生 Skill 机制，可以把本包作为团队资产库使用：
+
+```text
+ai-engineering-assets/
+├── skills/
+├── rules/
+├── prompts/
+├── templates/
+├── checklists/
+└── examples/
+```
+
+此时 `SKILL.md` 作为标准工作流说明，`assets/` 作为可复制模板、Prompt、检查清单和反例库。
+
+## 维护建议
+
+- 每次项目规则变化后，重新运行 `generate-project-constraints`。
+- 每次复杂业务模块交付后，把高频问题沉淀到 `review-business-delivery` 或 `track-review-fix-loop` 的 assets。
+- 不要把某个项目的专用规则直接复制成通用规则。
+- 对无法从源码或配置证明的内容，统一标记为待确认。
@@ -0,0 +1,46 @@
+# AI Engineering Skills Delivery
+
+本交付包提供 4 个可复用 AI 工程 Skill，覆盖真实项目中从项目约束生成、复杂业务设计、交付 Review 到修复闭环的完整流程。
+
+这些 Skill 不是单次 Prompt，而是可安装、可复制、可随项目持续维护的团队资产。
+
+## 交付内容
+
+```text
+客户AI工程Skill交付包/
+├── README.md
+├── INSTALL.md
+├── skills/
+│   ├── generate-project-constraints/
+│   ├── design-complex-business-module/
+│   ├── review-business-delivery/
+│   └── track-review-fix-loop/
+└── examples/
+    └── jeecgboot-work-order/
+```
+
+## Skill 列表
+
+| Skill | 用途 | 典型产物 |
+| --- | --- | --- |
+| `generate-project-constraints` | 从项目源码、配置、CI、文档中提取项目约束 | rules、约束提取表、验收清单 |
+| `design-complex-business-module` | 设计复杂业务模块的权限、状态、审计、异常态和看板 | RBAC 矩阵、状态流转表、审计 SOP、看板指标字典 |
+| `review-business-delivery` | 审查复杂业务交付物或 PR 的业务风险 | 阶段 Review 报告、风险清单、验收建议 |
+| `track-review-fix-loop` | 跟踪 Review 问题修复、验证和资产沉淀 | 修复记录、未闭环清单、资产更新建议 |
+
+## 推荐使用顺序
+
+1. 使用 `generate-project-constraints` 为客户项目生成项目规则。
+2. 使用 `design-complex-business-module` 生成复杂业务设计资产。
+3. 使用 `review-business-delivery` 审查设计、代码或阶段交付物。
+4. 使用 `track-review-fix-loop` 跟踪修复、验证结果和资产沉淀。
+
+## 适用项目
+
+适用于后台管理系统、低代码平台二开、CRM、工单、审批、运营系统、数据看板等企业业务项目。
+
+这些 Skill 不要求项目必须有 `CLAUDE.md`、`AGENTS.md` 或 `README.md`。如果项目没有显式说明文档，Skill 会从配置、源码模式、测试和 CI 中提取约束，并把无法证明的内容标记为待确认。
+
+## 示例说明
+
+`examples/jeecgboot-work-order/` 提供 JeecgBoot 工单案例参考，帮助理解这些 Skill 在真实后台项目中的使用方式。该示例不是通用 Skill 安装项。
@@ -0,0 +1,44 @@
+# JeecgBoot 工单模块开发审查 Skill
+
+## 触发场景
+
+涉及工单列表、详情、评论、状态、指派、看板、权限字符、数据权限、操作日志的需求拆解、代码生成或代码修改。
+
+## 输入材料
+
+- PR diff 或相关文件。
+- 工单需求说明。
+- 数据模型与接口契约。
+- 当前 rules。
+- 前端页面文件。
+- API 模块文件。
+- 后端 Controller / Service。
+- 权限矩阵。
+- 状态流转表。
+- 审计日志 SOP。
+
+## 执行步骤
+
+1. 识别需求范围和非目标范围。
+2. 检查字段、接口契约和页面状态是否完整。
+3. 审查 JeecgBoot 生成代码的字段、查询、分页、字典和异常态。
+4. 检查新增、编辑、删除、指派、状态变更的前端按钮与后端权限。
+5. 检查操作日志、数据权限和测试缺口。
+6. 检查看板指标口径和接口验收记录。
+7. 输出风险、不确定点和验收建议。
+
+## 输出格式
+
+- 需求范围确认。
+- 接口契约问题表。
+- 代码生成 Review 清单。
+- 权限风险表。
+- 状态流转风险表。
+- 审计日志风险表。
+- 测试缺口清单。
+- 不确定点清单。
+
+## 验收标准
+
+每个关键结论必须标注文件、函数、注解、配置或调用链依据。每条建议必须有验收方式。
+
@@ -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.
@@ -0,0 +1,7 @@
+interface:
+  display_name: "复杂业务模块设计"
+  short_description: "生成权限状态审计异常态看板等复杂业务设计资产"
+  default_prompt: "Use $design-complex-business-module to design permissions, state transitions, audit logs, exception states, and dashboard metrics for this business module."
+
+policy:
+  allow_implicit_invocation: true
@@ -0,0 +1,16 @@
+# 工单 RBAC 权限矩阵
+
+| 功能点 | 管理员 | 工单负责人 | 研发处理人 | 测试验证人 | 只读观察者 | 权限字符建议 | 备注 |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| 查看列表 | 允许 | 条件允许 | 条件允许 | 条件允许 | 条件允许 | work:order:list | 按数据范围 |
+| 查看详情 | 允许 | 条件允许 | 条件允许 | 条件允许 | 条件允许 | work:order:query | 仅可见范围 |
+| 新建工单 | 允许 | 允许 | 允许 | 允许 | 拒绝 | work:order:add |  |
+| 编辑工单 | 允许 | 条件允许 | 条件允许 | 拒绝 | 拒绝 | work:order:edit | 状态限制 |
+| 指派负责人 | 允许 | 条件允许 | 拒绝 | 拒绝 | 拒绝 | work:order:assign |  |
+| 状态流转 | 允许 | 条件允许 | 条件允许 | 条件允许 | 拒绝 | work:order:transition | 按状态 |
+| 关闭工单 | 允许 | 条件允许 | 拒绝 | 条件允许 | 拒绝 | work:order:close | 测试验证后 |
+| 删除工单 | 允许 | 拒绝 | 拒绝 | 拒绝 | 拒绝 | work:order:delete | 高危操作 |
+| 查看审计日志 | 允许 | 条件允许 | 条件允许 | 条件允许 | 拒绝 | work:order:audit |  |
+| 查看看板 | 允许 | 允许 | 条件允许 | 条件允许 | 条件允许 | work:order:dashboard | 按数据范围 |
+| 导出数据 | 允许 | 条件允许 | 拒绝 | 拒绝 | 拒绝 | work:order:export |  |
+
@@ -0,0 +1,25 @@
+# RBAC 权限矩阵生成 Prompt
+
+```text
+请基于 JeecgBoot 工单模块设计 RBAC 权限矩阵。
+
+输入材料：
+- 工单模块需求：<粘贴需求>
+- 角色列表：管理员、工单负责人、研发处理人、测试验证人、只读观察者
+- 功能点：查看列表、查看详情、新建、编辑、指派、状态流转、关闭、删除、查看审计、查看看板、导出
+- 项目依据：<粘贴权限、路由、菜单相关路径>
+
+输出要求：
+1. 先列事实依据：JeecgBoot 权限、菜单、动态路由相关路径。
+2. 输出 RBAC 权限矩阵：角色 x 功能点，允许、拒绝、条件允许。
+3. 输出权限字符建议，必须标注为建议。
+4. 输出页面级、按钮级、接口级、数据范围四层控制。
+5. 输出不确定点：哪些权限必须业务方确认。
+6. 输出验收方式：如何证明权限确实生效。
+
+约束：
+- 不要直接改代码。
+- 不要把前端按钮隐藏当作安全边界。
+- 所有结论必须区分事实、推断、建议。
+```
+
@@ -0,0 +1,40 @@
+# 工单审计日志 SOP
+
+## 记录原则
+
+所有会改变工单关键业务状态、负责人、可见性或结论的动作都必须记录审计日志。
+
+## 审计字段
+
+| 字段 | 含义 | 示例 |
+| --- | --- | --- |
+| ticket_id | 工单 ID | WO-001 |
+| actor_id | 操作人 ID | 1001 |
+| actor_name | 操作人名称 | zhangsan |
+| action | 操作类型 | ASSIGN |
+| field_name | 变更字段 | assignee |
+| old_value | 旧值 | lisi |
+| new_value | 新值 | wangwu |
+| source | 来源 | web |
+| request_id | 请求 ID | req-001 |
+| created_at | 操作时间 | 2026-07-01 10:00:00 |
+
+## 必须记录的动作
+
+| 动作 | 写入时机 | oldValue | newValue | 验收 |
+| --- | --- | --- | --- | --- |
+| 创建工单 | 创建成功后 | 空 | 工单摘要 | 审计列表可见 |
+| 编辑字段 | 保存成功后 | 修改前字段 | 修改后字段 | 字段前后值正确 |
+| 指派负责人 | 指派成功后 | 原负责人 | 新负责人 | 审计记录负责人变化 |
+| 状态流转 | 状态变更成功后 | 原状态 | 新状态 | 审计记录状态变化 |
+| 评论新增 | 评论保存后 | 空 | 评论摘要 | 审计记录评论动作 |
+| 关闭工单 | 关闭成功后 | 原状态 | 已关闭 | 审计记录关闭时间 |
+
+## 验收方式
+
+1. 执行关键操作后能在审计列表查询到记录。
+2. oldValue/newValue 和实际变更一致。
+3. 敏感字段已脱敏。
+4. 操作失败不写成功审计。
+5. 多步写入失败时审计和业务数据保持一致。
+
@@ -0,0 +1,13 @@
+# 审计日志检查清单
+
+| 检查项 | 通过标准 | 结果 |
+| --- | --- | --- |
+| 创建记录 | 创建工单后能查询审计记录 |  |
+| 字段变更 | 编辑关键字段记录 oldValue/newValue |  |
+| 指派记录 | 指派负责人记录原负责人和新负责人 |  |
+| 状态记录 | 状态流转记录原状态和新状态 |  |
+| 操作人 | actor_id 和 actor_name 可追溯 |  |
+| 来源 | source 或 request_id 可追溯 |  |
+| 脱敏 | 敏感字段不明文进入审计 |  |
+| 失败处理 | 操作失败不写成功审计 |  |
+
@@ -0,0 +1,13 @@
+# 异常态检查清单
+
+| 异常态 | 必须验证 | 结果 |
+| --- | --- | --- |
+| 空列表 | 页面显示空状态，不报错 |  |
+| 详情不存在 | 提示工单不存在，页面不崩溃 |  |
+| 权限不足 | 前端提示或隐藏，后端拒绝 |  |
+| 非法状态 | 返回非法流转，状态不变 |  |
+| 重复提交 | 只成功一次，只写一条有效审计 |  |
+| 参数缺失 | 返回参数错误，业务数据不变 |  |
+| 并发修改 | 拒绝覆盖或提示刷新 |  |
+| 看板无数据 | 图表显示空态，不显示假数据 |  |
+
@@ -0,0 +1,13 @@
+# 工单异常态清单
+
+| 场景 | 触发条件 | 前端表现 | 后端响应 | 验收 |
+| --- | --- | --- | --- | --- |
+| 权限不足 | 无权限操作 | 按钮不可见或提示无权限 | 403 或业务拒绝 | 不完成操作 |
+| 工单不存在 | 传入错误 ID | 显示不存在 | 404 或业务错误 | 页面不崩溃 |
+| 非法状态流转 | closed -> processing | 提示非法流转 | 状态不变 | 数据状态不变 |
+| 重复提交 | 连续点击提交 | 按钮 loading/禁用 | 只处理一次 | 只生成一条有效审计 |
+| 参数缺失 | 驳回缺少原因 | 表单校验提示 | 参数错误 | 不改变状态 |
+| 并发修改 | 数据版本过期 | 提示刷新 | 拒绝覆盖 | 旧数据不覆盖新数据 |
+| 看板无数据 | 无匹配记录 | 空状态 | 返回空集合 | 页面不报错 |
+| 审计日志为空 | 无审计记录 | 空状态 | 返回空集合 | 页面不报错 |
+
@@ -0,0 +1,24 @@
+# 异常态补齐 Prompt
+
+```text
+请基于 JeecgBoot 工单模块，列出状态流转、指派、删除、查询详情、审计日志、看板相关的异常态和防御性逻辑。
+
+输出表格：
+场景 | 触发条件 | 前端表现 | 后端响应 | 用户提示 | 测试点 | 验收
+
+必须覆盖：
+- 权限不足
+- 工单不存在
+- 非法状态流转
+- 重复提交
+- 参数缺失
+- 并发修改
+- 看板无数据
+- 审计日志为空
+
+约束：
+- 先列异常态，不要直接改代码。
+- 给出每个异常态的验收步骤。
+- 标注事实、推断、建议和不确定点。
+```
+
@@ -0,0 +1,12 @@
+# 权限上线前检查清单
+
+| 检查项 | 通过标准 | 结果 |
+| --- | --- | --- |
+| 菜单权限 | 工单菜单只对授权角色可见 |  |
+| 按钮权限 | 新增、编辑、删除、指派、状态按钮按权限显示 |  |
+| 接口权限 | 无权限账号直接请求敏感接口失败 |  |
+| 数据权限 | 普通用户只能看到授权范围内工单 |  |
+| 权限字符 | 前端按钮、菜单配置、后端接口命名一致 |  |
+| 审计 | 权限敏感操作成功后有审计记录 |  |
+| 反例验证 | 无权限账号不能绕过前端执行删除/指派 |  |
+
@@ -0,0 +1,12 @@
+# 工单权限控制方案
+
+| 操作 | 前端入口 | 权限字符 | 后端接口 | 后端校验 | 数据权限 | 验收 |
+| --- | --- | --- | --- | --- | --- | --- |
+| 新增工单 | 新增按钮 | work:order:add | /workOrder/add | 权限注解 | 无 | 无权限账号看不到按钮且直接请求失败 |
+| 编辑工单 | 编辑按钮 | work:order:edit | /workOrder/edit | 权限注解 + 状态校验 | 负责人/创建人范围 | 越权账号返回 403 或业务拒绝 |
+| 指派负责人 | 指派按钮 | work:order:assign | /workOrder/assign | 权限注解 | 管理员/负责人范围 | 普通研发无法指派他人 |
+| 状态流转 | 状态按钮 | work:order:transition | /workOrder/transition | 权限注解 + 状态机校验 | 相关工单范围 | 非法流转失败 |
+| 删除工单 | 删除按钮 | work:order:delete | /workOrder/delete | 权限注解 | 管理员范围 | 非管理员返回 403 |
+| 查看审计 | 审计页签 | work:order:audit | /workOrder/audit/list | 权限注解 | 相关工单范围 | 无权限不可见且接口拒绝 |
+| 看板 | 看板菜单 | work:order:dashboard | /workOrder/dashboard | 权限注解 | 数据范围过滤 | 不同角色数据范围不同 |
+
@@ -0,0 +1,24 @@
+# 权限控制方案生成 Prompt
+
+```text
+请基于工单模块 RBAC 权限矩阵，生成 JeecgBoot 权限控制方案。
+
+输入材料：
+- RBAC 权限矩阵：<粘贴>
+- 接口契约表：<粘贴>
+- 当前项目权限相关路径：<粘贴>
+- 当前 rules：<粘贴>
+
+输出要求：
+1. 权限控制方案表，列为：操作、前端入口、权限字符、后端接口、后端校验、数据权限、验收。
+2. 影响范围：前端页面、API 文件、后端 Controller、Service、菜单配置、数据权限。
+3. 缺失风险：按钮隐藏、接口未校验、数据范围不清、权限字符不一致。
+4. 无权限访问验收步骤。
+5. 不确定点和需要人工确认的权限边界。
+
+约束：
+- 不要直接改代码。
+- 后端接口权限必须单独说明。
+- 每个敏感操作必须有验收方式。
+```
+
@@ -0,0 +1,12 @@
+# 状态流转检查清单
+
+| 检查项 | 通过标准 | 结果 |
+| --- | --- | --- |
+| 状态枚举 | 所有状态有统一枚举或字典 |  |
+| 合法流转 | 状态流转表中的合法路径可执行 |  |
+| 非法流转 | 非法路径被拒绝且状态不变 |  |
+| 角色限制 | 不同角色只能执行被授权动作 |  |
+| 前置条件 | 驳回原因、关闭条件、负责人等校验完整 |  |
+| 审计日志 | 每次成功流转写审计 |  |
+| 重复提交 | 重复点击不会产生重复有效流转 |  |
+
@@ -0,0 +1,22 @@
+# 工单状态流转表
+
+| 当前状态 | 动作 | 目标状态 | 允许角色 | 前置条件 | 后置动作 | 验收 |
+| --- | --- | --- | --- | --- | --- | --- |
+| 新建 | 指派 | 新建 | 管理员/负责人 | 工单未关闭 | 写审计日志 | 指派人变化且状态不变 |
+| 新建 | 开始处理 | 处理中 | 研发处理人/负责人 | 已指派处理人 | 写审计日志 | 状态变为处理中 |
+| 处理中 | 提交验证 | 待验证 | 研发处理人/负责人 | 处理说明不为空 | 写审计日志 | 状态变为待验证 |
+| 待验证 | 验证通过 | 已关闭 | 测试验证人/负责人 | 验证结果通过 | 写审计日志和关闭时间 | 状态变为已关闭 |
+| 待验证 | 验证驳回 | 已驳回 | 测试验证人/负责人 | 驳回原因不为空 | 写审计日志 | 状态变为已驳回 |
+| 已驳回 | 重新处理 | 处理中 | 研发处理人/负责人 | 驳回原因已读 | 写审计日志 | 状态变为处理中 |
+| 已关闭 | 重新打开 | 新建 | 管理员 | 重开原因不为空 | 写审计日志 | 状态变为新建 |
+
+## 非法流转清单
+
+| 当前状态 | 尝试动作 | 问题 | 系统响应 | 验收 |
+| --- | --- | --- | --- | --- |
+| 已关闭 | 开始处理 | 关闭后不能直接处理 | 返回非法流转 | 状态不变 |
+| 新建 | 验证通过 | 未处理不能验证 | 返回非法流转 | 状态不变 |
+| 待验证 | 提交验证 | 重复提交验证 | 返回非法流转 | 只保留原状态 |
+| 处理中 | 验证通过 | 未进入待验证 | 返回非法流转 | 状态不变 |
+| 已驳回 | 关闭 | 驳回后不能直接关闭 | 返回非法流转 | 状态不变 |
+
@@ -0,0 +1,34 @@
+# 状态流转设计 Prompt
+
+```text
+请为 JeecgBoot 工单模块设计状态流转规则。
+
+状态候选：
+- 新建
+- 处理中
+- 待验证
+- 已关闭
+- 已驳回
+
+动作候选：
+- 指派
+- 开始处理
+- 提交验证
+- 验证通过
+- 验证驳回
+- 关闭
+- 重新打开
+
+输出要求：
+1. 状态流转表：当前状态、动作、目标状态、允许角色、前置条件、后置动作、验收。
+2. 非法流转清单：当前状态、尝试动作、问题、系统响应、验收。
+3. 接口设计建议。
+4. 测试点清单。
+5. 不确定点。
+
+约束：
+- 先出状态表，不要直接写 if else。
+- 已关闭、越权、缺少说明、重复提交必须覆盖。
+- 每条规则必须有验收方式。
+```
+
@@ -0,0 +1,13 @@
+# 看板指标口径检查清单
+
+| 检查项 | 通过标准 | 结果 |
+| --- | --- | --- |
+| 指标含义 | 每个指标有业务解释 |  |
+| 计算口径 | 每个指标有公式或筛选条件 |  |
+| 时间范围 | 明确按创建时间、关闭时间还是更新时间统计 |  |
+| 数据范围 | 不同角色的数据范围清楚 |  |
+| 空数据 | 空数据展示为 0 或空态，不误导 |  |
+| 分组一致性 | 分组总和能和总数对齐 |  |
+| 权限 | 无看板权限不能访问接口 |  |
+| 验收证据 | 至少有一组样例数据手工校验 |  |
+
@@ -0,0 +1,13 @@
+# 工单看板指标字典
+
+| 指标 | 含义 | 口径 | 数据来源 | 展示方式 | 权限 | 验收 |
+| --- | --- | --- | --- | --- | --- | --- |
+| 工单总数 | 当前筛选范围内工单数量 | count(ticket_id) | 工单表 | 指标卡 | 看板权限 | 与列表同条件数量一致 |
+| 未关闭工单数 | 状态不是已关闭的数量 | status != closed | 工单表 | 指标卡 | 看板权限 | 过滤状态验证 |
+| 平均关闭周期 | 从创建到关闭平均耗时 | avg(close_time - create_time) | 工单表 | 指标卡/趋势 | 看板权限 | 抽样计算一致 |
+| 按优先级分布 | 高中低优先级数量 | group by priority | 工单表/字典 | 饼图/柱状图 | 看板权限 | 分组总和等于总数 |
+| 按类型分布 | 缺陷/需求/支持数量 | group by type | 工单表/字典 | 柱状图 | 看板权限 | 分组总和等于总数 |
+| 缺陷趋势 | 按日期统计缺陷工单 | type=bug group by date | 工单表 | 折线图 | 看板权限 | 日期范围正确 |
+| 逾期工单数 | 超过 SLA 未关闭数量 | due_time < now and status != closed | 工单表 | 指标卡 | 看板权限 | SLA 口径明确 |
+| 人员处理负载 | 按负责人统计未关闭数量 | group by assignee | 工单表 | 排行榜 | 管理员/负责人 | 数据范围正确 |
+
@@ -0,0 +1,28 @@
+# 看板指标设计 Prompt
+
+```text
+请为 JeecgBoot 工单模块设计研发效能看板指标。
+
+指标方向：
+- 工单总数
+- 未关闭工单数
+- 平均关闭周期
+- 按优先级分布
+- 按类型分布
+- 缺陷趋势
+- 逾期工单数
+- 人员处理负载
+
+输出要求：
+1. 指标字典：指标名、含义、口径、维度、过滤条件、数据来源、展示方式、权限。
+2. 看板统计接口契约建议。
+3. 空态、错误态、无权限态。
+4. 验收方式。
+5. 不确定点。
+
+约束：
+- 每个指标必须可计算。
+- 不要只写页面 UI。
+- 指标口径不清必须写入不确定点。
+```
+
@@ -0,0 +1,27 @@
+# 看板接口验收 Prompt
+
+```text
+请为 JeecgBoot 工单看板统计接口生成验收记录。
+
+输入材料：
+- 看板指标字典：<粘贴>
+- 看板接口契约：<粘贴>
+- 权限矩阵：<粘贴>
+
+输出表格：
+验收项 | 账号/条件 | 请求参数 | 预期 | 实际 | 证据 | 结论
+
+必须覆盖：
+- 有数据
+- 空数据
+- 无权限
+- 过滤条件
+- 指标口径
+- 时间范围
+- 数据范围
+
+约束：
+- 不要只说“接口正常”。
+- 每个指标至少有一个验收动作。
+```
+
@@ -0,0 +1,12 @@
+# 看板接口验收清单
+
+| 验收项 | 请求条件 | 通过标准 | 结果 |
+| --- | --- | --- | --- |
+| 默认查询 | 管理员默认条件 | 返回完整指标 |  |
+| 时间过滤 | 指定 start/end | 只统计时间范围内数据 |  |
+| 类型过滤 | 指定工单类型 | 只统计对应类型 |  |
+| 空数据 | 无匹配条件 | 返回 0 或空集合 |  |
+| 无权限 | 未授权账号 | 返回 403 或业务拒绝 |  |
+| 数据范围 | 普通角色 | 只返回授权范围 |  |
+| 指标一致性 | 固定样例数据 | 与手工计算一致 |  |
+
@@ -0,0 +1,11 @@
+# 工单看板接口验收记录
+
+| 验收项 | 账号/条件 | 请求参数 | 预期 | 实际 | 证据 | 结论 |
+| --- | --- | --- | --- | --- | --- | --- |
+| 工单总数 | 管理员 | 默认筛选 | 返回总数 |  |  |  |
+| 空数据 | 管理员 + 无匹配条件 | 不存在的日期范围 | 返回空集合或 0 |  |  |  |
+| 无权限 | 只读外角色 | 默认筛选 | 返回 403 或业务拒绝 |  |  |  |
+| 时间过滤 | 管理员 | start/end | 只统计范围内数据 |  |  |  |
+| 数据范围 | 普通研发 | 默认筛选 | 只返回本人相关数据 |  |  |  |
+| 指标口径 | 管理员 | 固定样例数据 | 与手工计算一致 |  |  |  |
+
@@ -0,0 +1,125 @@
+---
+name: generate-project-constraints
+description: Use when a user needs to extract project-specific AI coding constraints, team rules, repository rules, .trae rules, Cursor rules, CLAUDE.md/AGENTS.md content, or reusable rules/checklists from an existing software project, including projects without README or explicit instruction files.
+---
+
+# Generate Project Constraints
+
+## Core Principle
+
+Generate constraints from evidence, not preference. Treat instruction files as optional inputs: if they exist, read them first; if not, use code-only mode and infer cautiously from config, source patterns, tests, CI, and runtime behavior.
+
+Every output rule must be labeled as `硬约束`, `观察性约束`, or `待确认约束`, and every non-obvious rule must cite source paths.
+
+## Evidence Order
+
+Read available sources in this order:
+
+1. Explicit instructions: `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `.trae/rules`, `.cursor/rules`, `.cursorrules`, `README*`, `CONTRIBUTING*`, team docs.
+2. Build/runtime manifests: `package.json`, lockfiles, `pom.xml`, `build.gradle`, `.env*`, `application*.yml`, Docker files, compose files.
+3. Quality gates: ESLint, Prettier, Stylelint, Checkstyle, Spotless, PMD, Jest/Vitest/JUnit/Playwright configs, CI workflows.
+4. Source patterns: API layer, response wrappers, auth/permission flow, routing, state management, controller/service/repository or mapper layers, error handling, audit/logging.
+5. Existing examples: representative modules that already implement the pattern requested by the user.
+
+If a source category is absent, record it in `缺失证据`, then continue. Never block only because `README.md`, `CLAUDE.md`, or `AGENTS.md` is missing.
+
+## Constraint Levels
+
+| Level | Use When | Wording |
+| --- | --- | --- |
+| `硬约束` | Directly proven by config, build files, CI, runtime settings, or explicit team docs | `必须` / `禁止` |
+| `观察性约束` | Repeated pattern appears in existing code but no written rule exists | `默认采用` / `优先复用` |
+| `待确认约束` | Needed for delivery but not provable from the repo | `需团队确认` |
+
+Do not upgrade an observed pattern into a hard rule unless a source explicitly requires it.
+
+## Workflow
+
+1. Define scope: target repo path, output path, desired rule categories, and whether the user wants installable Skill assets or plain rules.
+2. Inventory sources with fast shell commands such as `rg --files`, `find`, `sed`, and focused `rg` searches.
+3. Extract facts into an evidence table: source path, observed fact, affected area, confidence, and candidate rule.
+4. Normalize candidate rules into the output contract below.
+5. Validate each rule against at least one source path or mark it `待确认约束`.
+6. Write rules and checklists. Prefer small files such as `rules/backend.md`, `rules/frontend.md`, `rules/security.md`, `rules/testing.md`, `rules/delivery.md`.
+7. Run verification: placeholder scan, broken-path spot checks, and a final pass that every hard/observed rule has evidence.
+
+## Output Contract
+
+When the user asks to generate constraints, produce these artifacts unless they request a lighter output:
+
+```text
+ai-dev-assets/
+├── rules/
+│   ├── global.md
+│   ├── frontend.md
+│   ├── backend.md
+│   ├── security.md
+│   ├── testing.md
+│   └── delivery.md
+├── templates/
+│   └── 项目约束提取表.template.md
+└── checklists/
+    └── 项目约束验收清单.md
+```
+
+Each rule file should use this structure:
+
+```md
+## 规则名称
+
+- 级别：硬约束 | 观察性约束 | 待确认约束
+- 适用场景：
+- 必须：
+- 禁止：
+- 来源证据：
+- 验收方式：
+- 迁移说明：
+```
+
+Use `assets/项目约束提取表.template.md` and `assets/项目约束验收清单.md` as copyable starting points when helpful.
+
+## Code-Only Mode
+
+Use this when no explicit instruction files exist.
+
+Required behavior:
+
+- State that explicit project docs were not found.
+- Build constraints from manifests, configs, CI, tests, and repeated source patterns.
+- Label all pattern-derived rules as `观察性约束`.
+- Create a `待确认约束` section for business delivery rules that the repo cannot prove, such as review gates, branch policy, audit requirements, test minimums, and release process.
+
+Good wording:
+
+```md
+本项目未发现 `AGENTS.md`、`CLAUDE.md`、`.trae/rules` 或 `README.md` 中的明确 AI 协作规则。以下约束来自配置文件和源码模式；未能由仓库证明的内容已标记为待确认。
+```
+
+## JeecgBoot Example
+
+For the training case only, JeecgBoot evidence can generate rules such as:
+
+- `硬约束`: backend uses `Result<T>` response wrapper, from backend `CLAUDE.md`.
+- `硬约束`: frontend uses `defHttp` and backend menu permission mode, from frontend `CLAUDE.md`.
+- `硬约束`: backend modification blocks require `update-begin` / `update-end`, from backend `CLAUDE.md`.
+- `观察性约束`: business features should follow existing controller/service/mapper layering after verifying representative modules.
+
+Keep these examples out of generic outputs unless the target project is JeecgBoot or explicitly similar.
+
+## Quality Gates
+
+Before claiming completion:
+
+- List generated files.
+- Scan generated files for unfinished placeholders, dummy names, and empty headings.
+- Check hard and observed constraints cite source paths.
+- Confirm missing evidence is not silently converted into rules.
+- Report which sources were read and which rule categories remain `待确认`.
+
+## Common Mistakes
+
+- Do not require `CLAUDE.md`, `AGENTS.md`, or `README.md` to exist.
+- Do not turn general best practices into project rules without evidence.
+- Do not merge business constraints, technical constraints, and delivery constraints into one vague list.
+- Do not omit verification steps; rules are useful only if a learner or team can check them.
+- Do not copy JeecgBoot-specific constraints into unrelated projects.
@@ -0,0 +1,7 @@
+interface:
+  display_name: "项目约束生成"
+  short_description: "从项目证据提取可执行规则、模板和验收清单"
+  default_prompt: "Use $generate-project-constraints to extract project-specific AI coding constraints, rules, and checklists from this repository."
+
+policy:
+  allow_implicit_invocation: true
@@ -0,0 +1,43 @@
+# 项目约束提取表
+
+## 项目信息
+
+| 字段 | 内容 |
+| --- | --- |
+| 项目名称 |  |
+| 项目路径 |  |
+| 提取日期 |  |
+| 提取人 |  |
+| 目标输出 | rules / prompts / checklists / Skill |
+
+## 证据扫描记录
+
+| 证据类型 | 文件或目录 | 是否存在 | 关键发现 | 备注 |
+| --- | --- | --- | --- | --- |
+| 显式规则 | AGENTS.md / CLAUDE.md / .trae/rules / .cursor/rules |  |  |  |
+| 项目说明 | README / CONTRIBUTING / docs |  |  |  |
+| 后端构建 | pom.xml / build.gradle / settings.gradle |  |  |  |
+| 前端构建 | package.json / lockfile / vite.config / tsconfig |  |  |  |
+| 运行配置 | .env / application.yml / Dockerfile / compose |  |  |  |
+| 质量工具 | ESLint / Prettier / Checkstyle / CI / test config |  |  |  |
+| 源码模式 | API / Controller / Service / Router / Store |  |  |  |
+| 权限与安全 | auth / permission / role / route guard / interceptor |  |  |  |
+| 数据与迁移 | schema / migration / mapper / repository |  |  |  |
+
+## 候选约束
+
+| 编号 | 分类 | 约束内容 | 级别 | 来源证据 | 影响范围 | 验收方式 | 迁移说明 |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| C-001 | global / frontend / backend / security / testing / delivery |  | 硬约束 / 观察性约束 / 待确认约束 |  |  |  |  |
+
+## 缺失证据
+
+| 缺失项 | 影响 | 处理方式 |
+| --- | --- | --- |
+|  |  | 标记为待确认 / 询问团队 / 暂不生成规则 |
+
+## 待团队确认
+
+| 问题 | 为什么需要确认 | 建议默认值 | 决策人 |
+| --- | --- | --- | --- |
+| 是否强制单测 | 仓库未发现 CI 或测试要求时无法证明 | 新增核心逻辑需补测试或说明豁免 | 技术负责人 |
@@ -0,0 +1,61 @@
+# 项目约束生成 Prompt
+
+请为下面项目生成可复用的 AI 开发约束资产。
+
+## 项目输入
+
+- 项目路径：
+- 输出路径：
+- 目标项目类型：
+- 是否需要生成 rules：
+- 是否需要生成 checklist：
+- 是否需要生成 Skill：
+
+## 执行要求
+
+1. 先扫描项目中是否存在显式规则文件，例如 `AGENTS.md`、`CLAUDE.md`、`.trae/rules`、`.cursor/rules`、`README.md`、`CONTRIBUTING.md`。
+2. 如果不存在显式规则文件，不要停止，进入 code-only 模式。
+3. 从构建配置、运行配置、源码模式、测试配置、CI 配置中提取约束。
+4. 每条约束必须标注为：
+   - `硬约束`：由配置、CI、构建或显式规则直接证明。
+   - `观察性约束`：由多个源码样例归纳，但没有显式规则。
+   - `待确认约束`：项目无法证明，但交付前必须团队确认。
+5. 每条硬约束和观察性约束必须标注来源路径。
+6. 不要把通用最佳实践当成项目事实。
+7. 不要把某个项目的专用规则复制到另一个项目。
+
+## 输出格式
+
+请生成：
+
+```text
+rules/global.md
+rules/frontend.md
+rules/backend.md
+rules/security.md
+rules/testing.md
+rules/delivery.md
+templates/项目约束提取表.template.md
+checklists/项目约束验收清单.md
+```
+
+每条规则使用：
+
+```md
+## 规则名称
+
+- 级别：
+- 适用场景：
+- 必须：
+- 禁止：
+- 来源证据：
+- 验收方式：
+- 迁移说明：
+```
+
+最后输出：
+
+- 已读来源。
+- 缺失证据。
+- 待确认问题。
+- 不能迁移到其他项目的项目特有约束。
@@ -0,0 +1,44 @@
+# 项目约束验收清单
+
+## 基础完整性
+
+- [ ] 已列出目标项目路径和输出路径。
+- [ ] 已说明是否发现显式规则文件。
+- [ ] 已记录缺失证据，没有因为缺失 README / CLAUDE.md / AGENTS.md 而停止。
+- [ ] 已区分 `硬约束`、`观察性约束`、`待确认约束`。
+- [ ] 每条硬约束都有明确来源路径。
+- [ ] 每条观察性约束至少有一个代表性源码样例。
+- [ ] 每条待确认约束都写明需要谁确认。
+
+## 规则质量
+
+- [ ] 规则包含适用场景。
+- [ ] 规则包含必须做什么。
+- [ ] 规则包含禁止做什么，或说明没有禁止项。
+- [ ] 规则包含验收方式。
+- [ ] 规则包含迁移说明，说明换项目时能否复用。
+- [ ] 规则没有把通用最佳实践冒充为项目事实。
+- [ ] 规则没有把某个单一代码样例冒充为全项目硬约束。
+
+## 覆盖范围
+
+- [ ] global 约束覆盖项目理解、证据引用、事实/推断区分。
+- [ ] frontend 约束覆盖包管理器、框架、路径别名、API 层、路由和状态管理。
+- [ ] backend 约束覆盖语言版本、框架、分层、响应结构、异常和数据访问。
+- [ ] security 约束覆盖认证、权限、敏感信息、数据范围和接口防护。
+- [ ] testing 约束覆盖已有测试工具、运行命令和缺失测试时的处理。
+- [ ] delivery 约束覆盖计划、Review、验收记录、发布或交付要求。
+
+## 可复用性
+
+- [ ] JeecgBoot 等项目特有规则没有写进通用规则。
+- [ ] 每条规则都标注了“可直接复用 / 需重新扫描 / 不可迁移”。
+- [ ] 换项目时必须重新扫描的内容已经列出。
+- [ ] 可以从本清单反推出生成步骤。
+
+## 交付检查
+
+- [ ] 生成文件中没有未完成占位符、示例假名或空标题。
+- [ ] Markdown 链接或路径经过抽样检查。
+- [ ] 规则文件标题不为空。
+- [ ] 交付说明列出已读来源、未读来源和仍需确认的问题。
@@ -0,0 +1,89 @@
+---
+name: review-business-delivery
+description: Use when reviewing complex business delivery artifacts, AI-generated plans, PR diffs, or module designs for permission gaps, illegal state transitions, missing audit logs, weak exception handling, unclear dashboard metrics, missing tests, or incomplete acceptance evidence.
+---
+
+# Review Business Delivery
+
+## Core Principle
+
+Review behavior and risk before wording. Findings must be evidence-based, severity-ranked, and tied to a verification action.
+
+The review output should help the team decide whether to accept, conditionally accept, or reject the delivery.
+
+## Inputs
+
+Use any available inputs:
+
+- Requirement scope and non-goals.
+- RBAC matrix and permission control plan.
+- State transition table and illegal transition list.
+- Audit SOP and exception-state list.
+- Dashboard metric dictionary and API acceptance record.
+- Code diff, API contract, test result, Browser verification record, or PR description.
+- Project rules and constraints.
+
+If source evidence is missing, create an `证据缺口` section instead of guessing.
+
+## Review Flow
+
+1. Confirm delivery scope: what is being reviewed and what is outside scope.
+2. Check source evidence: paths, rules, design tables, test results, and verification records.
+3. Review permission risk: page/menu, button, backend API, and data scope.
+4. Review state risk: legal transitions, illegal transitions, terminal states, duplicate submits, and role restrictions.
+5. Review audit risk: action coverage, field completeness, masking, failure behavior, and consistency with business writes.
+6. Review exception risk: empty, missing, invalid, forbidden, duplicate, concurrent, and downstream failure states.
+7. Review dashboard risk: formula, filter, dimension, data source, permission, empty state, and manual calculation.
+8. Review tests and acceptance: commands, roles, sample data, browser evidence, and unresolved risks.
+9. Output findings sorted by severity.
+
+## Severity
+
+| Level | Meaning |
+| --- | --- |
+| P0 | Data loss, privilege bypass, irreversible wrong state, or release-blocking failure |
+| P1 | Security, permission, audit, or state-machine defect with realistic business impact |
+| P2 | Missing acceptance evidence, unclear metric, weak exception handling, or test gap |
+| P3 | Maintainability, naming, documentation, or minor consistency issue |
+
+## Output Contract
+
+```md
+## Review 结论
+
+通过 / 有条件通过 / 不通过
+
+## 问题清单
+
+| 等级 | 模块 | 问题 | 证据 | 风险 | 修复建议 | 验收方式 |
+| --- | --- | --- | --- | --- | --- | --- |
+
+## 证据缺口
+
+| 缺口 | 影响 | 需要谁补充 |
+| --- | --- | --- |
+
+## 待确认
+
+| 问题 | 决策人 | 建议默认值 |
+| --- | --- | --- |
+```
+
+Use the templates and checklists in `assets/` when writing files.
+
+## Quality Gates
+
+- Findings lead the response; summaries are secondary.
+- Every P0/P1 finding cites a source path, table row, endpoint, role, state, metric, or verification record.
+- Every finding has a concrete fix direction and acceptance method.
+- Review does not accept frontend-only security controls.
+- Missing tests or missing evidence are called out explicitly.
+- Unclear business rules are marked `待确认`, not invented.
+
+## Common Mistakes
+
+- Do not write "整体不错" before listing risks.
+- Do not merge all issues into one generic recommendation.
+- Do not downgrade permission bypass, illegal state transitions, or missing audit for critical actions.
+- Do not claim an issue is fixed without verification evidence.
+- Do not review only code style when the requested delivery is business behavior.
@@ -0,0 +1,7 @@
+interface:
+  display_name: "业务交付 Review"
+  short_description: "审查权限状态审计异常态看板测试与验收风险"
+  default_prompt: "Use $review-business-delivery to review complex business delivery artifacts for permission, state, audit, exception, and dashboard risks."
+
+policy:
+  allow_implicit_invocation: true
@@ -0,0 +1,28 @@
+# AI Review 报告模板
+
+## Review 输入
+
+- PR diff：
+- 需求说明：
+- rules：
+- 测试结果：
+- 历史问题：
+
+## 结论
+
+通过 / 有条件通过 / 不通过
+
+## 问题清单
+
+| 等级 | 文件/模块 | 问题 | 触发规则 | 风险 | 建议 | 测试/验收 |
+| --- | --- | --- | --- | --- | --- | --- |
+
+## 不确定点
+
+| 不确定点 | 需要谁确认 | 验证方式 |
+| --- | --- | --- |
+
+## 是否建议合入
+
+说明理由。
+
@@ -0,0 +1,13 @@
+# 审计日志检查清单
+
+| 检查项 | 通过标准 | 结果 |
+| --- | --- | --- |
+| 创建记录 | 创建工单后能查询审计记录 |  |
+| 字段变更 | 编辑关键字段记录 oldValue/newValue |  |
+| 指派记录 | 指派负责人记录原负责人和新负责人 |  |
+| 状态记录 | 状态流转记录原状态和新状态 |  |
+| 操作人 | actor_id 和 actor_name 可追溯 |  |
+| 来源 | source 或 request_id 可追溯 |  |
+| 脱敏 | 敏感字段不明文进入审计 |  |
+| 失败处理 | 操作失败不写成功审计 |  |
+
@@ -0,0 +1,13 @@
+# 异常态检查清单
+
+| 异常态 | 必须验证 | 结果 |
+| --- | --- | --- |
+| 空列表 | 页面显示空状态，不报错 |  |
+| 详情不存在 | 提示工单不存在，页面不崩溃 |  |
+| 权限不足 | 前端提示或隐藏，后端拒绝 |  |
+| 非法状态 | 返回非法流转，状态不变 |  |
+| 重复提交 | 只成功一次，只写一条有效审计 |  |
+| 参数缺失 | 返回参数错误，业务数据不变 |  |
+| 并发修改 | 拒绝覆盖或提示刷新 |  |
+| 看板无数据 | 图表显示空态，不显示假数据 |  |
+
@@ -0,0 +1,12 @@
+# 权限上线前检查清单
+
+| 检查项 | 通过标准 | 结果 |
+| --- | --- | --- |
+| 菜单权限 | 工单菜单只对授权角色可见 |  |
+| 按钮权限 | 新增、编辑、删除、指派、状态按钮按权限显示 |  |
+| 接口权限 | 无权限账号直接请求敏感接口失败 |  |
+| 数据权限 | 普通用户只能看到授权范围内工单 |  |
+| 权限字符 | 前端按钮、菜单配置、后端接口命名一致 |  |
+| 审计 | 权限敏感操作成功后有审计记录 |  |
+| 反例验证 | 无权限账号不能绕过前端执行删除/指派 |  |
+
@@ -0,0 +1,12 @@
+# 状态流转检查清单
+
+| 检查项 | 通过标准 | 结果 |
+| --- | --- | --- |
+| 状态枚举 | 所有状态有统一枚举或字典 |  |
+| 合法流转 | 状态流转表中的合法路径可执行 |  |
+| 非法流转 | 非法路径被拒绝且状态不变 |  |
+| 角色限制 | 不同角色只能执行被授权动作 |  |
+| 前置条件 | 驳回原因、关闭条件、负责人等校验完整 |  |
+| 审计日志 | 每次成功流转写审计 |  |
+| 重复提交 | 重复点击不会产生重复有效流转 |  |
+
@@ -0,0 +1,13 @@
+# 看板指标口径检查清单
+
+| 检查项 | 通过标准 | 结果 |
+| --- | --- | --- |
+| 指标含义 | 每个指标有业务解释 |  |
+| 计算口径 | 每个指标有公式或筛选条件 |  |
+| 时间范围 | 明确按创建时间、关闭时间还是更新时间统计 |  |
+| 数据范围 | 不同角色的数据范围清楚 |  |
+| 空数据 | 空数据展示为 0 或空态，不误导 |  |
+| 分组一致性 | 分组总和能和总数对齐 |  |
+| 权限 | 无看板权限不能访问接口 |  |
+| 验收证据 | 至少有一组样例数据手工校验 |  |
+
@@ -0,0 +1,12 @@
+# 看板接口验收清单
+
+| 验收项 | 请求条件 | 通过标准 | 结果 |
+| --- | --- | --- | --- |
+| 默认查询 | 管理员默认条件 | 返回完整指标 |  |
+| 时间过滤 | 指定 start/end | 只统计时间范围内数据 |  |
+| 类型过滤 | 指定工单类型 | 只统计对应类型 |  |
+| 空数据 | 无匹配条件 | 返回 0 或空集合 |  |
+| 无权限 | 未授权账号 | 返回 403 或业务拒绝 |  |
+| 数据范围 | 普通角色 | 只返回授权范围 |  |
+| 指标一致性 | 固定样例数据 | 与手工计算一致 |  |
+
@@ -0,0 +1,30 @@
+# 阶段 Review Prompt
+
+```text
+请对 JeecgBoot 工单模块阶段交付物做 Review。
+
+输入材料：
+- RBAC 权限矩阵
+- 权限控制方案
+- 状态流转表
+- 非法流转清单
+- 审计日志 SOP
+- 异常态清单
+- 看板指标字典
+- 看板接口验收记录
+- 测试结果或验证记录
+
+输出表格：
+等级 | 模块 | 问题 | 触发规则 | 风险 | 修复建议 | 验收
+
+要求：
+1. 问题按 P0/P1/P2/P3 分级。
+2. 每个问题必须说明触发了哪条规则。
+3. 每条建议必须有验收方式。
+4. 输出不确定点和需要人工确认的内容。
+
+约束：
+- 不要只说整体不错。
+- 不要直接改代码。
+```
+
@@ -0,0 +1,28 @@
+# 阶段 Review 报告
+
+## Review 输入
+
+- RBAC 权限矩阵：
+- 权限控制方案：
+- 状态流转表：
+- 非法流转清单：
+- 审计日志 SOP：
+- 异常态清单：
+- 看板指标字典：
+- 看板接口验收记录：
+
+## 问题清单
+
+| 等级 | 模块 | 问题 | 触发规则 | 风险 | 修复建议 | 验收 |
+| --- | --- | --- | --- | --- | --- | --- |
+| P1 | 权限 | 删除接口只隐藏按钮，后端缺少权限校验 | 前端按钮不是安全边界 | 可绕过前端删除工单 | 后端补权限校验 | 无权限账号请求返回 403 |
+
+## 不确定点
+
+| 不确定点 | 影响 | 需要谁确认 |
+| --- | --- | --- |
+
+## 结论
+
+通过 / 有条件通过 / 不通过
+
@@ -0,0 +1,71 @@
+# 验收清单
+
+本清单用于判断学员是否真正掌握 JeecgBoot 工单案例，而不是只复制了 TRAE 输出。建议讲师在小组展示时逐项打分。
+
+## 项目理解
+
+| 检查项 | 通过标准 | 结果 |
+| --- | --- | --- |
+| 能说明 JeecgBoot 前后端目录 | 至少指出 `jeecg-boot`、`jeecgboot-vue3`、`docs/project-knowledge` 的用途 |  |
+| 能定位后端入口 | 能指出 `JeecgSystemApplication.java` 和后端启动模块 |  |
+| 能定位前端入口 | 能指出 `src/main.ts`、路由、Pinia 和 API 请求层 |  |
+| 能区分事实和推断 | 对没有源码依据的业务规则标注为推断或待确认 |  |
+| 能记录不确定点 | 不确定内容没有被包装成确定事实 |  |
+
+## 需求与接口
+
+| 检查项 | 通过标准 | 结果 |
+| --- | --- | --- |
+| 用户故事完整 | 覆盖管理员、负责人、研发、测试、只读用户 |  |
+| 非目标范围明确 | 明确课堂不做完整编码、生产部署、真实数据迁移 |  |
+| 接口契约完整 | 覆盖列表、详情、新增、编辑、指派、状态、审计、看板 |  |
+| 失败场景明确 | 每个关键接口至少有权限、参数、状态或数据不存在失败场景 |  |
+| 验收方式明确 | 每个关键需求都有可执行检查方法 |  |
+
+## 权限与状态
+
+| 检查项 | 通过标准 | 结果 |
+| --- | --- | --- |
+| 权限矩阵完整 | 覆盖页面级、按钮级、接口级和数据范围 |  |
+| 权限字符合理 | 命名统一，并标注为建议而非源码事实 |  |
+| 后端权限未缺失 | 没有用前端按钮隐藏替代后端接口控制 |  |
+| 状态流转表完整 | 覆盖新建、处理中、待验证、已关闭、已驳回 |  |
+| 非法流转明确 | 至少列出 5 条非法流转和拒绝原因 |  |
+
+## 审计、异常态与看板
+
+| 检查项 | 通过标准 | 结果 |
+| --- | --- | --- |
+| 审计操作覆盖关键动作 | 创建、编辑、指派、状态流转、关闭、评论至少覆盖 5 类 |  |
+| 审计字段可追溯 | 包含 actor、action、targetId、oldValue、newValue、source |  |
+| 敏感信息处理 | oldValue/newValue 有脱敏说明 |  |
+| 异常态可测试 | 权限不足、重复提交、非法状态、数据不存在、并发修改均覆盖 |  |
+| 看板指标可计算 | 每个指标有口径、维度、过滤条件和数据来源建议 |  |
+
+## Review 与交付
+
+| 检查项 | 通过标准 | 结果 |
+| --- | --- | --- |
+| Review 有证据 | 问题能回到路径、表格或业务规则 |  |
+| 风险按严重程度排序 | 高风险问题优先展示 |  |
+| 建议可行动 | 每条建议有修复方向和验收方式 |  |
+| 交付物齐全 | [worksheets.md](./worksheets.md) 中最终交付记录完整 |  |
+| 能沉淀资产 | 能说明哪些内容进入 [assets-index.md](./assets-index.md) 的资产库 |  |
+
+## 评分建议
+
+| 等级 | 分数 | 描述 |
+| --- | ---: | --- |
+| A | 90-100 | 依据充分，设计完整，风险清楚，验收可执行 |
+| B | 75-89 | 主链路完整，少量不确定点或验收细节不足 |
+| C | 60-74 | 有基本产出，但权限、状态、审计或异常态明显薄弱 |
+| D | 0-59 | 泛泛总结项目，缺少源码依据或无法验收 |
+
+## 讲师判定原则
+
+- 优先看证据，不优先看文字是否漂亮。
+- 优先看权限、状态、审计、异常态，不只看 CRUD。
+- 优先看不确定点是否被诚实标出。
+- 优先看能否复用到团队资产库。
+- 对没有依据的自信结论扣分。
+
@@ -0,0 +1,94 @@
+---
+name: track-review-fix-loop
+description: Use when turning review findings into a fix-tracking record, deciding whether findings are valid, mapping fixes to files, verifying results, documenting unresolved items, or deciding which issues should become reusable rules, checklists, prompts, examples, or team assets.
+---
+
+# Track Review Fix Loop
+
+## Core Principle
+
+A review issue is not closed by saying "fixed". It closes only when the team records validity, changed artifacts, verification evidence, unresolved risk, and whether the lesson should become a reusable asset.
+
+## Inputs
+
+- Review report with numbered findings.
+- Requirement or acceptance criteria.
+- Code diff, design document, generated tables, or changed files.
+- Test results, Browser verification evidence, API response samples, or manual validation notes.
+- Existing team rules, checklists, examples, and asset index.
+
+If validation evidence is missing, mark the item as `未闭环`.
+
+## Status Model
+
+Use one of these statuses for each review item:
+
+| Status | Meaning |
+| --- | --- |
+| `成立-已修复` | Finding is valid, changed artifacts are listed, and verification evidence exists |
+| `成立-暂不修复` | Finding is valid but deferred with reason, owner, and follow-up date |
+| `不成立` | Finding is invalid with evidence |
+| `需确认` | Finding depends on business or technical decision not available in current evidence |
+| `未闭环` | Fix is claimed but evidence is missing |
+
+## Workflow
+
+1. Normalize review findings: ensure each issue has an ID, severity, module, risk, and suggested verification.
+2. Decide validity: `成立`, `不成立`, or `需确认`; cite evidence.
+3. Map valid fixes to changed files, tables, prompts, rules, or templates.
+4. Verify each fix using commands, API checks, browser steps, role-based tests, or manual calculation.
+5. Identify regressions: related permissions, states, audit actions, dashboard metrics, and exception states to re-check.
+6. Decide asset sedimentation: rule, checklist, prompt, Command, Skill, example, or no asset.
+7. Output unresolved items with owner and next step.
+
+## Output Contract
+
+```md
+## 修复闭环结论
+
+完成 / 部分完成 / 未完成
+
+## 修复记录
+
+| Review 编号 | 等级 | 问题 | 状态 | 修改文件/产物 | 验证证据 | 剩余风险 | 资产沉淀 |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+
+## 未闭环事项
+
+| 编号 | 原因 | 负责人 | 下一步 | 截止时间 |
+| --- | --- | --- | --- | --- |
+
+## 资产更新建议
+
+| 来源问题 | 资产类型 | 建议文件 | 更新内容 |
+| --- | --- | --- | --- |
+```
+
+Use `assets/修复记录.template.md` and `assets/Review修复闭环检查清单.md` when creating files.
+
+## Asset Decision Guide
+
+| If the issue is... | Asset |
+| --- | --- |
+| Repeated project convention violation | rule |
+| Repeated review checklist miss | checklist |
+| Reusable question or generation pattern | prompt |
+| One-step repeatable agent action | command |
+| Multi-step judgment workflow | skill |
+| Good or bad teaching sample | example |
+
+## Quality Gates
+
+- Every fixed issue has verification evidence.
+- Every deferred issue has owner and next step.
+- Every invalid issue has source evidence, not opinion.
+- P0/P1 issues cannot be marked complete without direct verification.
+- Asset updates are specific file suggestions, not vague "沉淀经验".
+
+## Common Mistakes
+
+- Do not close issues with "已修复" without evidence.
+- Do not erase invalid findings; keep why they are invalid.
+- Do not mark business decisions as technical fixes.
+- Do not create a Skill for a one-off checklist item.
+- Do not ignore regressions around permissions, state transitions, audit logs, and dashboard metrics.
@@ -0,0 +1,7 @@
+interface:
+  display_name: "Review 修复闭环"
+  short_description: "跟踪Review问题成立判断修复验证未闭环与资产沉淀"
+  default_prompt: "Use $track-review-fix-loop to turn review findings into verified fixes, unresolved decisions, and reusable team assets."
+
+policy:
+  allow_implicit_invocation: true
@@ -0,0 +1,12 @@
+# Review 修复闭环检查清单
+
+| 检查项 | 通过标准 | 结果 |
+| --- | --- | --- |
+| 问题编号 | 每个 Review 问题有编号 |  |
+| 成立判断 | 每个问题说明是否成立 |  |
+| 修改说明 | 成立问题说明修改文件和内容 |  |
+| 验证结果 | 每个修复有验证证据 |  |
+| 未修复说明 | 暂不修复的问题有原因和后续计划 |  |
+| 资产沉淀 | 有复用价值的问题已进入检查清单或反例库 |  |
+| 回归检查 | 修复后重新检查相关权限/状态/审计/看板 |  |
+
@@ -0,0 +1,8 @@
+# Review 修复记录
+
+| Review 编号 | 问题 | 是否成立 | 修改文件 | 修改说明 | 验证结果 | 资产沉淀 |
+| --- | --- | --- | --- | --- | --- | --- |
+| R01 | 删除接口缺少后端权限校验 | 是 | WorkOrderController | 增加权限校验 | 无权限请求被拒绝 | 权限检查清单 |
+| R02 | closed 可重新处理 | 是 | WorkOrderService | 补非法流转校验 | closed -> processing 失败 | 状态流转检查清单 |
+| R03 | 看板关闭周期口径不清 | 是 | 指标字典/看板接口 | 明确 create_time 到 close_time | 指标说明已更新 | 看板指标口径清单 |
+
@@ -0,0 +1,24 @@
+# 修复记录生成 Prompt
+
+```text
+请根据阶段 Review 报告生成修复记录。
+
+输入材料：
+- Review 报告：<粘贴>
+- 已完成修改说明：<粘贴>
+- 验证结果：<粘贴>
+
+输出表格：
+Review 编号 | 问题 | 是否成立 | 修改文件 | 修改说明 | 验证结果 | 资产沉淀
+
+要求：
+1. 如果问题不成立，说明理由和依据。
+2. 如果问题成立，说明修改了哪些文件。
+3. 每条修复必须有验证结果。
+4. 判断是否需要沉淀为资产，例如权限检查清单、状态流转检查清单、审计日志检查清单。
+
+约束：
+- 不要模糊写“已修复”。
+- 没有验证结果的修复不能算完成。
+```
+
@@ -0,0 +1,32 @@
+# 审计日志缺失反例
+
+## 场景
+
+工单指派负责人成功，但没有记录审计日志。
+
+## 问题表现
+
+| 操作 | 结果 |
+| --- | --- |
+| 张三将工单指派给李四 | 工单负责人变更成功 |
+| 查询审计日志 | 没有负责人变更记录 |
+
+## 风险
+
+无法追溯负责人变化，出现延误或争议时无法定位责任。
+
+## 修复要求
+
+1. 指派成功后写审计日志。
+2. 记录原负责人、新负责人、操作人、时间、来源。
+3. 指派失败不写成功审计。
+4. 多步写入需要事务一致性。
+
+## 验收
+
+| 操作 | 预期 |
+| --- | --- |
+| 指派成功 | 审计列表出现 ASSIGN 记录 |
+| 指派失败 | 不出现成功审计 |
+| 查询详情 | 审计记录可在工单详情查看 |
+
@@ -0,0 +1,33 @@
+# 权限遗漏反例
+
+## 场景
+
+工单删除按钮在前端按权限隐藏，但后端删除接口没有权限校验。
+
+## 问题代码表现
+
+| 层级 | 表现 |
+| --- | --- |
+| 前端 | 普通研发账号看不到删除按钮 |
+| 后端 | 直接请求 `/workOrder/delete` 仍可删除 |
+| 审计 | 删除记录可能缺失 |
+
+## 风险
+
+攻击者或误操作用户可以绕过前端直接调用接口删除工单。
+
+## 修复要求
+
+1. 后端删除接口增加权限校验。
+2. 删除前校验数据范围。
+3. 删除成功写审计日志。
+4. 无权限账号直接请求接口返回 403 或业务拒绝。
+
+## 验收
+
+| 账号 | 操作 | 预期 |
+| --- | --- | --- |
+| 管理员 | 删除允许删除的工单 | 成功并写审计 |
+| 普通研发 | 直接请求删除接口 | 失败 |
+| 只读用户 | 前端访问删除按钮 | 不可见 |
+
@@ -0,0 +1,31 @@
+# 看板指标口径不清反例
+
+## 场景
+
+看板展示“平均关闭周期”，但没有说明从哪个时间到哪个时间。
+
+## 问题表现
+
+| 指标 | 当前说明 |
+| --- | --- |
+| 平均关闭周期 | 最近工单平均处理时间 |
+
+## 风险
+
+不同人理解不同：可能是创建到关闭，也可能是开始处理到关闭，导致管理判断失真。
+
+## 修复要求
+
+1. 明确定义为 `close_time - create_time` 或其他确定口径。
+2. 明确是否排除未关闭工单。
+3. 明确时间范围过滤字段。
+4. 用样例数据手工校验。
+
+## 验收
+
+| 样例 | 预期 |
+| --- | --- |
+| 工单 A 创建 1 日、关闭 3 日 | 周期 2 天 |
+| 未关闭工单 | 不计入平均关闭周期 |
+| 过滤 7 月 | 只统计 7 月范围内符合口径的数据 |
+
@@ -0,0 +1,31 @@
+# 非法状态流转反例
+
+## 场景
+
+已关闭工单可以直接被改回处理中。
+
+## 问题表现
+
+| 当前状态 | 动作 | 结果 |
+| --- | --- | --- |
+| 已关闭 | 开始处理 | 状态变成处理中 |
+
+## 风险
+
+已关闭工单被重新打开但没有重开原因、没有审计、没有负责人确认，导致统计和责任链失真。
+
+## 修复要求
+
+1. Service 层集中校验状态流转。
+2. 已关闭工单只能通过“重新打开”动作变为新建。
+3. 重新打开必须填写原因。
+4. 所有成功流转写审计日志。
+
+## 验收
+
+| 操作 | 预期 |
+| --- | --- |
+| closed -> processing | 失败，状态不变 |
+| closed -> reopen -> new | 成功，必须有原因 |
+| 重开成功 | 审计记录 oldValue=closed, newValue=new |
+