feat：update 3 4
This commit is contained in:
smart
@@ -0,0 +1,101 @@
|
||||
# JeecgBoot 工单案例包
|
||||
|
||||
这是一个独立培训案例包，用于在 TRAE 课程中训练学员把 AI 编程工具用于真实 JeecgBoot 类后台项目。案例围绕“企业工单与研发效能看板”展开，但不假设当前源码中已经存在完整工单模块。
|
||||
|
||||
## 适用场景
|
||||
|
||||
| 场景 | 用法 |
|
||||
| --- | --- |
|
||||
| 第 3 天功能开发闭环 | 用于需求拆解、接口契约、页面状态、测试点前置设计 |
|
||||
| 第 4 天复杂业务开发 | 用于权限、状态流转、审计、异常态、看板和 Review |
|
||||
| 企业内部二开培训 | 作为 JeecgBoot 项目入门和 TRAE 协作标准样例 |
|
||||
| 课后资产沉淀 | 拆分为 rules、Prompt、Command、Skill、SOP 和案例库 |
|
||||
|
||||
## 学习目标
|
||||
|
||||
完成本案例后，学员应该能做到：
|
||||
|
||||
1. 使用 TRAE 从真实项目中定位前端入口、后端入口、权限、路由、API、配置和数据库依据。
|
||||
2. 把“工单管理”需求拆成用户故事、字段、接口契约、页面状态和验收标准。
|
||||
3. 先生成权限矩阵和状态流转表，再设计代码修改计划。
|
||||
4. 对审计日志、异常态、看板指标和 Review 输出提出可验证要求。
|
||||
5. 识别 TRAE 输出中的事实、推断、建议和不确定点。
|
||||
|
||||
## 建议使用顺序
|
||||
|
||||
1. 先读 [source-map.md](./source-map.md)，建立 JeecgBoot 项目地图。
|
||||
2. 讲师按 [instructor-guide.md](./instructor-guide.md) 选择 2 小时、半天或 1 天节奏。
|
||||
3. 学员按 [learner-guide.md](./learner-guide.md) 完成实操。
|
||||
4. 每一步复制 [prompts.md](./prompts.md) 中的模板，但必须填入本组上下文。
|
||||
5. 课堂产出写入 [worksheets.md](./worksheets.md)。
|
||||
6. 交付前用 [acceptance-checklist.md](./acceptance-checklist.md) 验收。
|
||||
7. 课后按 [assets-index.md](./assets-index.md) 沉淀团队资产。
|
||||
8. 需要直接复用资产时，复制 [ai-dev-assets/README.md](./ai-dev-assets/README.md) 下列出的规则、Prompt、模板、检查清单、Skill 和反例。
|
||||
|
||||
## 课前准备
|
||||
|
||||
| 事项 | 要求 |
|
||||
| --- | --- |
|
||||
| 项目目录 | `../../../JeecgBoot` 存在，并包含 `jeecg-boot`、`jeecgboot-vue3` 和 `docs/project-knowledge` |
|
||||
| 工具 | TRAE、Git、Node 20.19+ 或 22.12+、pnpm、JDK 17、Maven |
|
||||
| 账号 | JeecgBoot 默认演示账号可用于讲解：`admin/123456`，真实环境不得复用 |
|
||||
| 数据 | 课堂可使用虚拟工单数据，不要求真实连接数据库 |
|
||||
| 协作约束 | 后端遵守 `../../../JeecgBoot/jeecg-boot/CLAUDE.md`，前端遵守 `../../../JeecgBoot/jeecgboot-vue3/CLAUDE.md` |
|
||||
|
||||
## 案例任务主线
|
||||
|
||||
工单模块用于管理研发团队内的任务、缺陷和支持请求。课堂不要求完整编码实现，而是训练“先理解、再设计、再计划、最后验收”的 AI 协作方式。
|
||||
|
||||
| 阶段 | 任务 | 产出 |
|
||||
| --- | --- | --- |
|
||||
| 项目理解 | 定位前后端入口、权限、API、配置和数据库 | 项目地图、源码依据表 |
|
||||
| 需求拆解 | 设计工单列表、详情、状态、指派、评论、看板需求 | 用户故事、字段清单、非目标范围 |
|
||||
| 接口契约 | 设计列表、详情、创建、编辑、指派、状态流转、审计查询接口 | 接口契约表 |
|
||||
| 权限设计 | 定义管理员、负责人、研发、测试、只读角色权限边界 | RBAC 权限矩阵 |
|
||||
| 状态流转 | 定义新建、处理中、待验证、已关闭、已驳回流转规则 | 状态流转表、非法流转清单 |
|
||||
| 审计与异常态 | 设计操作日志、重复提交、权限不足、非法状态等处理 | 审计字段表、异常态清单 |
|
||||
| 看板与 Review | 设计数量、周期、缺陷分布、趋势指标并审查方案 | 看板指标表、AI Review 报告 |
|
||||
|
||||
## 最终交付物
|
||||
|
||||
每个小组至少提交：
|
||||
|
||||
- 一份源码依据记录表。
|
||||
- 一份工单需求拆解表。
|
||||
- 一份接口契约表。
|
||||
- 一份 RBAC 权限矩阵。
|
||||
- 一份状态流转表和非法流转清单。
|
||||
- 一份审计日志设计表。
|
||||
- 一份异常态清单。
|
||||
- 一份看板指标表。
|
||||
- 一份 Review 记录和最终验收记录。
|
||||
|
||||
## 关键约束
|
||||
|
||||
- 不要直接让 TRAE “帮我做一个工单模块”。
|
||||
- 每次让 TRAE 输出结论前，先要求它列出依据文件、函数、接口或配置。
|
||||
- 所有输出必须区分事实、推断、建议和不确定点。
|
||||
- 涉及权限、状态流转、删除、审计和看板的任务必须先出方案，再讨论代码修改。
|
||||
- 后端实际改代码时必须遵守 `update-begin` / `update-end` 修改痕迹规则。
|
||||
- 前端实际改代码时必须复用 `/@/` alias、Pinia、动态路由和 `defHttp` 请求层。
|
||||
|
||||
## 文件索引
|
||||
|
||||
| 文件 | 用途 |
|
||||
| --- | --- |
|
||||
| [instructor-guide.md](./instructor-guide.md) | 讲师授课节奏和讲法 |
|
||||
| [learner-guide.md](./learner-guide.md) | 学员实操路径 |
|
||||
| [source-map.md](./source-map.md) | JeecgBoot 源码定位图 |
|
||||
| [prompts.md](./prompts.md) | 可复制的 TRAE Prompt 模板 |
|
||||
| [worksheets.md](./worksheets.md) | 课堂填写表 |
|
||||
| [acceptance-checklist.md](./acceptance-checklist.md) | 交付验收清单 |
|
||||
| [assets-index.md](./assets-index.md) | 课后资产沉淀建议 |
|
||||
| [ai-dev-assets/](./ai-dev-assets/README.md) | 可直接复制到团队资产库的具体产物 |
|
||||
|
||||
其中 [generate-project-constraints](./ai-dev-assets/skills/generate-project-constraints/SKILL.md) 是跨项目复用 Skill，用于在没有 `CLAUDE.md`、`AGENTS.md` 或 `README.md` 的项目中，也能从配置、源码模式、测试和 CI 中提取项目约束。
|
||||
|
||||
另外还提供 3 个可复用 Skill：
|
||||
|
||||
- [design-complex-business-module](./ai-dev-assets/skills/design-complex-business-module/SKILL.md)：生成权限、状态、审计、异常态和看板设计资产。
|
||||
- [review-business-delivery](./ai-dev-assets/skills/review-business-delivery/SKILL.md)：审查复杂业务交付中的权限、状态、审计、异常态、看板和验收风险。
|
||||
- [track-review-fix-loop](./ai-dev-assets/skills/track-review-fix-loop/SKILL.md)：把 Review 问题转成修复记录、验证证据和资产沉淀建议。
|
||||
@@ -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,76 @@
|
||||
# JeecgBoot 工单可复用资产包
|
||||
|
||||
这个目录里的文件不是大纲，而是课后可以直接复制到团队 `ai-dev-assets/` 的资产。
|
||||
|
||||
## 使用方式
|
||||
|
||||
1. 需要团队规则时，复制 `rules/`。
|
||||
2. 需要快捷提问时，复制 `commands/` 和 `prompts/jeecgboot/`。
|
||||
3. 需要把流程封装成团队能力时，复制 `skills/`。
|
||||
4. 需要课堂或项目交付表时，复制 `templates/` 和 `templates/jeecgboot/`。
|
||||
5. 需要验收和上线检查时，复制 `checklists/` 和 `checklists/jeecgboot/`。
|
||||
6. 需要反例教学时，复制 `examples/` 和 `examples/jeecgboot/`。
|
||||
|
||||
## 资产清单
|
||||
|
||||
### 第 3 天 Agent 工作流资产
|
||||
|
||||
- `rules/global.md`
|
||||
- `rules/frontend.md`
|
||||
- `rules/backend.md`
|
||||
- `rules/security.md`
|
||||
- `rules/testing.md`
|
||||
- `rules/delivery.md`
|
||||
- `commands/模块结构分析.command.md`
|
||||
- `commands/工单需求拆解.command.md`
|
||||
- `commands/接口契约生成.command.md`
|
||||
- `commands/代码生成Review.command.md`
|
||||
- `commands/PR说明生成.command.md`
|
||||
- `skills/JeecgBoot工单模块开发审查.skill.md`
|
||||
- `skills/generate-project-constraints/SKILL.md`
|
||||
- `skills/generate-project-constraints/assets/项目约束提取表.template.md`
|
||||
- `skills/generate-project-constraints/assets/项目约束验收清单.md`
|
||||
- `skills/generate-project-constraints/assets/项目约束生成.prompt.md`
|
||||
- `skills/design-complex-business-module/SKILL.md`
|
||||
- `skills/review-business-delivery/SKILL.md`
|
||||
- `skills/track-review-fix-loop/SKILL.md`
|
||||
- `templates/Plan任务模板.md`
|
||||
- `templates/AIReview报告模板.md`
|
||||
- `templates/Browser验证报告模板.md`
|
||||
- `checklists/任务成本与能力匹配表.md`
|
||||
- `checklists/Agent分工表.md`
|
||||
- `checklists/CLI-MCP-Skill封装决策表.md`
|
||||
- `examples/好Command与坏Command对照.md`
|
||||
- `examples/好Skill与坏Skill对照.md`
|
||||
- `examples/好Plan与坏Plan对照.md`
|
||||
|
||||
### 第 4 天 JeecgBoot 工单复杂业务资产
|
||||
|
||||
- `prompts/jeecgboot/RBAC权限矩阵生成.prompt.md`
|
||||
- `prompts/jeecgboot/权限控制方案生成.prompt.md`
|
||||
- `prompts/jeecgboot/状态流转设计.prompt.md`
|
||||
- `prompts/jeecgboot/异常态补齐.prompt.md`
|
||||
- `prompts/jeecgboot/看板指标设计.prompt.md`
|
||||
- `prompts/jeecgboot/看板接口验收.prompt.md`
|
||||
- `prompts/jeecgboot/阶段Review.prompt.md`
|
||||
- `prompts/jeecgboot/修复记录生成.prompt.md`
|
||||
- `templates/jeecgboot/RBAC权限矩阵.template.md`
|
||||
- `templates/jeecgboot/权限控制方案.template.md`
|
||||
- `templates/jeecgboot/状态流转表.template.md`
|
||||
- `templates/jeecgboot/审计日志SOP.template.md`
|
||||
- `templates/jeecgboot/异常态清单.template.md`
|
||||
- `templates/jeecgboot/看板指标字典.template.md`
|
||||
- `templates/jeecgboot/看板接口验收记录.template.md`
|
||||
- `templates/jeecgboot/阶段Review报告.template.md`
|
||||
- `templates/jeecgboot/修复记录.template.md`
|
||||
- `checklists/jeecgboot/权限上线前检查清单.md`
|
||||
- `checklists/jeecgboot/状态流转检查清单.md`
|
||||
- `checklists/jeecgboot/审计日志检查清单.md`
|
||||
- `checklists/jeecgboot/异常态检查清单.md`
|
||||
- `checklists/jeecgboot/看板指标口径检查清单.md`
|
||||
- `checklists/jeecgboot/看板接口验收清单.md`
|
||||
- `checklists/jeecgboot/Review修复闭环检查清单.md`
|
||||
- `examples/jeecgboot/权限遗漏反例.md`
|
||||
- `examples/jeecgboot/非法状态流转反例.md`
|
||||
- `examples/jeecgboot/审计日志缺失反例.md`
|
||||
- `examples/jeecgboot/看板指标口径不清反例.md`
|
||||
@@ -0,0 +1,12 @@
|
||||
# Agent 分工表
|
||||
|
||||
| Agent | 输入 | 动作 | 输出 | 验收 | 边界 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 需求拆解 Agent | 原始需求 | 拆用户故事、边界、异常 | 需求拆解文档 | 有验收标准 | 不直接写代码 |
|
||||
| 代码理解 Agent | 项目路径 | 找入口、链路、依据 | 源码依据表 | 能指向文件 | 不做业务决策 |
|
||||
| 规则审查 Agent | rules + 任务 | 判断规则命中 | 规则命中表 | 能解释触发原因 | 不改规则 |
|
||||
| 代码生成审查 Agent | 生成代码、字段表、rules | 查字段、查询、字典、异常态 | 代码生成 Review 清单 | 能指向文件和问题 | 不直接合入 |
|
||||
| 测试建议 Agent | 需求、diff | 生成测试点 | 测试点清单 | 覆盖正常/异常/权限/状态 | 不替代人工验收 |
|
||||
| Review Agent | diff、rules、测试结果 | 输出问题等级和建议 | Review 报告 | 问题可定位 | 不替代负责人判断 |
|
||||
| 文档整理 Agent | 课堂产出 | 归档资产 | 资产库条目 | 命名清楚 | 不编造产出 |
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
# CLI / MCP / Skill 封装决策表
|
||||
|
||||
| 需求 | 推荐封装 | 理由 | 验收 |
|
||||
| --- | --- | --- | --- |
|
||||
| 生成 PR 说明 | Command | 固定格式、低风险 | PR 模板字段完整 |
|
||||
| 检查代码生成结果 | Command | 输入固定、输出固定 | Review 清单完整 |
|
||||
| JeecgBoot 工单模块开发审查 | Skill | 多步骤、多文件、多规则 | 输出风险表和依据 |
|
||||
| 调用浏览器检查页面 | MCP / Browser | 需要真实页面状态 | 有截图或操作证据 |
|
||||
| 批量扫描源码指标 | CLI | 可脚本化、重复执行 | 命令输出稳定 |
|
||||
| 跨系统取数据 | MCP | 需要外部工具或系统 | 有鉴权和审计 |
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
# Review 修复闭环检查清单
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 问题编号 | 每个 Review 问题有编号 | |
|
||||
| 成立判断 | 每个问题说明是否成立 | |
|
||||
| 修改说明 | 成立问题说明修改文件和内容 | |
|
||||
| 验证结果 | 每个修复有验证证据 | |
|
||||
| 未修复说明 | 暂不修复的问题有原因和后续计划 | |
|
||||
| 资产沉淀 | 有复用价值的问题已进入检查清单或反例库 | |
|
||||
| 回归检查 | 修复后重新检查相关权限/状态/审计/看板 | |
|
||||
|
||||
@@ -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,11 @@
|
||||
# 任务成本与能力匹配表
|
||||
|
||||
| 任务 | 风险 | 上下文需求 | 推荐能力 | 验收方式 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 拆解工单需求 | 中 | 需求说明 + 项目规则 | Agent 分析 | 有用户故事和验收标准 |
|
||||
| 生成接口契约 | 中 | 需求 + 字段 + 权限 | Command | 接口表完整 |
|
||||
| 审查代码生成结果 | 中 | 生成代码 + rules | Command / Skill | 输出代码生成 Review 清单 |
|
||||
| 修改工单状态流转 | 高 | 相关文件 + rules + 测试 | Plan 后执行 | 状态机验证 + Review |
|
||||
| 生成 PR 说明 | 低 | diff + 测试结果 | Command | PR 模板字段完整 |
|
||||
| 修复 CI 失败 | 中 | CI 日志 + diff + rules | Agent 分析 | 失败原因和修复方案清楚 |
|
||||
|
||||
@@ -0,0 +1,38 @@
|
||||
# /PR说明生成
|
||||
|
||||
## 使用场景
|
||||
|
||||
工单模块阶段开发完成后，生成 PR 描述初稿。
|
||||
|
||||
## 输入
|
||||
|
||||
- diff 或变更文件清单。
|
||||
- 需求说明。
|
||||
- 测试结果。
|
||||
- Review 记录。
|
||||
- 风险和不确定点。
|
||||
|
||||
## 执行要求
|
||||
|
||||
1. 说明背景和目标。
|
||||
2. 列出变更范围。
|
||||
3. 标注不做什么。
|
||||
4. 写清测试和验收结果。
|
||||
5. 写清风险、回滚建议和 AI 使用记录。
|
||||
|
||||
## 输出格式
|
||||
|
||||
```md
|
||||
## 背景
|
||||
|
||||
## 变更内容
|
||||
|
||||
## 不做什么
|
||||
|
||||
## 测试与验收
|
||||
|
||||
## 风险与回滚
|
||||
|
||||
## AI 辅助记录
|
||||
```
|
||||
|
||||
@@ -0,0 +1,30 @@
|
||||
# /代码生成 Review
|
||||
|
||||
## 使用场景
|
||||
|
||||
JeecgBoot 基于工单表生成基础 CRUD 后，正式进入人工调整前使用。
|
||||
|
||||
## 输入
|
||||
|
||||
- 数据表字段说明。
|
||||
- 生成的前端页面。
|
||||
- API 模块文件。
|
||||
- 后端 Controller。
|
||||
- 后端 Service。
|
||||
- 当前 rules。
|
||||
|
||||
## 执行要求
|
||||
|
||||
1. 检查字段是否和数据模型一致。
|
||||
2. 检查查询条件、分页、排序是否完整。
|
||||
3. 检查状态、优先级、类型是否使用字典或枚举。
|
||||
4. 检查新增、编辑、删除、导出按钮是否需要权限控制。
|
||||
5. 检查后端接口是否有权限校验。
|
||||
6. 检查 loading、empty、error、forbidden 状态是否缺失。
|
||||
7. 标注不确定点。
|
||||
|
||||
## 输出格式
|
||||
|
||||
| 检查项 | 文件 | 现状 | 问题 | 建议 | 验收 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
|
||||
@@ -0,0 +1,26 @@
|
||||
# /工单需求拆解
|
||||
|
||||
## 使用场景
|
||||
|
||||
把“工单管理”这类业务需求拆成用户故事、字段、接口、状态和验收标准。
|
||||
|
||||
## 输入
|
||||
|
||||
- 原始需求说明。
|
||||
- 角色列表。
|
||||
- 当前项目规则。
|
||||
- 已定位的源码依据。
|
||||
|
||||
## 执行要求
|
||||
|
||||
1. 先列业务目标和非目标范围。
|
||||
2. 按角色拆用户故事。
|
||||
3. 输出字段清单和字典需求。
|
||||
4. 输出接口候选清单。
|
||||
5. 标注需要业务确认的不确定点。
|
||||
|
||||
## 输出格式
|
||||
|
||||
| 用户故事 | 角色 | 目标 | 字段/接口 | 验收标准 | 不确定点 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
# /接口契约生成
|
||||
|
||||
## 使用场景
|
||||
|
||||
需求拆解后，用于生成工单模块接口契约初稿。
|
||||
|
||||
## 输入
|
||||
|
||||
- 需求拆解表。
|
||||
- 字段清单。
|
||||
- 权限矩阵。
|
||||
- 状态流转表。
|
||||
- JeecgBoot API 约定。
|
||||
|
||||
## 执行要求
|
||||
|
||||
1. 覆盖列表、详情、新增、编辑、指派、状态流转、审计、看板。
|
||||
2. 每个接口写方法、路径、参数、响应、权限字符。
|
||||
3. 每个接口写成功和失败场景。
|
||||
4. 每个接口写验收方式。
|
||||
5. 路径建议必须标注为建议，不伪装成已有事实。
|
||||
|
||||
## 输出格式
|
||||
|
||||
| 接口 | 方法 | 路径建议 | 参数 | 响应 | 权限 | 失败场景 | 验收 |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
|
||||
@@ -0,0 +1,25 @@
|
||||
# /模块结构分析
|
||||
|
||||
## 使用场景
|
||||
|
||||
接手 JeecgBoot 或类似前后端分离后台项目时，用于快速建立项目地图。
|
||||
|
||||
## 输入
|
||||
|
||||
- 项目根目录。
|
||||
- 后端入口文件或父 POM。
|
||||
- 前端入口文件或 package.json。
|
||||
- 项目知识库或 README。
|
||||
|
||||
## 执行要求
|
||||
|
||||
1. 按前端、后端、权限、配置、数据库分组。
|
||||
2. 每个结论必须引用路径。
|
||||
3. 区分事实、推断、建议、不确定点。
|
||||
4. 输出后续应该深入阅读的 5-8 个文件。
|
||||
|
||||
## 输出格式
|
||||
|
||||
| 模块 | 路径 | 事实依据 | 作用 | 下一步验证 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
|
||||
@@ -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 |
|
||||
|
||||
@@ -0,0 +1,47 @@
|
||||
# 好 Command 与坏 Command 对照
|
||||
|
||||
## 坏 Command
|
||||
|
||||
```md
|
||||
# /检查代码
|
||||
|
||||
帮我看看代码有没有问题。
|
||||
```
|
||||
|
||||
问题：
|
||||
|
||||
- 没有使用场景。
|
||||
- 没有输入要求。
|
||||
- 没有执行步骤。
|
||||
- 没有输出格式。
|
||||
- 没有验收标准。
|
||||
|
||||
## 好 Command
|
||||
|
||||
```md
|
||||
# /代码生成 Review
|
||||
|
||||
## 使用场景
|
||||
JeecgBoot 基于 work_order 表生成工单模块基础代码后使用。
|
||||
|
||||
## 输入
|
||||
- 数据表字段说明
|
||||
- 生成的前端页面
|
||||
- api 模块文件
|
||||
- 后端 Controller
|
||||
- 后端 Service
|
||||
- 当前 rules
|
||||
|
||||
## 执行要求
|
||||
1. 检查字段是否和数据模型一致
|
||||
2. 检查查询条件、分页、排序是否完整
|
||||
3. 检查状态、优先级、类型是否使用字典或枚举
|
||||
4. 检查新增、编辑、删除、导出按钮是否需要权限控制
|
||||
5. 检查 loading、empty、error、forbidden 状态是否缺失
|
||||
6. 标注不确定点
|
||||
|
||||
## 输出格式
|
||||
| 检查项 | 文件 | 现状 | 问题 | 建议 | 验收 |
|
||||
|---|---|---|---|---|---|
|
||||
```
|
||||
|
||||
@@ -0,0 +1,55 @@
|
||||
# 好 Plan 与坏 Plan 对照
|
||||
|
||||
## 坏 Plan
|
||||
|
||||
```md
|
||||
1. 修改后端接口
|
||||
2. 修改前端页面
|
||||
3. 测试一下
|
||||
```
|
||||
|
||||
问题：
|
||||
|
||||
- 没有目标。
|
||||
- 没有范围。
|
||||
- 没有不做什么。
|
||||
- 没有文件路径。
|
||||
- 没有风险和验收。
|
||||
|
||||
## 好 Plan
|
||||
|
||||
```md
|
||||
# 工单删除逻辑调整 Plan
|
||||
|
||||
## 目标
|
||||
删除工单时补齐后端权限校验和审计日志。
|
||||
|
||||
## 范围
|
||||
- WorkOrderController 删除接口
|
||||
- WorkOrderService 删除逻辑
|
||||
- 工单审计日志写入
|
||||
- 前端删除按钮权限验证
|
||||
|
||||
## 不做什么
|
||||
- 不调整工单状态流转
|
||||
- 不重构列表页面
|
||||
- 不改动非工单模块
|
||||
|
||||
## 修改步骤
|
||||
| 步骤 | 文件/模块 | 动作 | 风险 | 验收 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | Controller | 增加后端权限校验 | 权限字符不一致 | 无权限账号返回 403 |
|
||||
| 2 | Service | 删除前写审计日志 | 事务不一致 | 删除后能查询审计 |
|
||||
| 3 | 前端页面 | 检查删除按钮权限 | 只隐藏按钮不安全 | 仍需后端拒绝 |
|
||||
|
||||
## 风险
|
||||
- 误删已关闭工单
|
||||
- 无权限绕过前端
|
||||
- 审计日志缺失
|
||||
|
||||
## 验收
|
||||
- 管理员可删除允许删除的工单
|
||||
- 普通研发账号请求删除接口失败
|
||||
- 删除操作产生审计记录
|
||||
```
|
||||
|
||||
@@ -0,0 +1,50 @@
|
||||
# 好 Skill 与坏 Skill 对照
|
||||
|
||||
## 坏 Skill
|
||||
|
||||
```md
|
||||
# 工单开发 Skill
|
||||
|
||||
帮我开发工单模块。
|
||||
```
|
||||
|
||||
问题：
|
||||
|
||||
- 没有触发场景。
|
||||
- 没有输入材料。
|
||||
- 没有执行步骤。
|
||||
- 没有输出格式。
|
||||
- 没有边界和验收。
|
||||
|
||||
## 好 Skill
|
||||
|
||||
```md
|
||||
# JeecgBoot 工单模块开发审查 Skill
|
||||
|
||||
## 触发场景
|
||||
涉及工单列表、详情、评论、状态、指派、看板、权限字符、数据权限、操作日志的需求拆解、代码生成或代码修改。
|
||||
|
||||
## 输入材料
|
||||
- PR diff 或相关文件
|
||||
- 工单需求说明
|
||||
- 数据模型与接口契约
|
||||
- 当前 rules
|
||||
- 前端页面文件
|
||||
- api 模块文件
|
||||
- 后端 Controller / Service
|
||||
|
||||
## 执行步骤
|
||||
1. 识别需求范围和非目标范围
|
||||
2. 检查字段、接口契约和页面状态是否完整
|
||||
3. 审查 JeecgBoot 生成代码的字段、查询、分页、字典和异常态
|
||||
4. 检查新增、编辑、删除、指派、状态变更的前端按钮与后端权限
|
||||
5. 检查操作日志、数据权限和测试缺口
|
||||
6. 输出风险、不确定点和验收建议
|
||||
|
||||
## 输出格式
|
||||
需求拆解表、接口契约表、代码生成 Review 清单、权限风险表、日志风险表、测试缺口清单、不确定点清单。
|
||||
|
||||
## 验收标准
|
||||
每个关键结论必须标注文件、函数、注解或调用链依据。
|
||||
```
|
||||
|
||||
@@ -0,0 +1,25 @@
|
||||
# RBAC 权限矩阵生成 Prompt
|
||||
|
||||
```text
|
||||
请基于 JeecgBoot 工单模块设计 RBAC 权限矩阵。
|
||||
|
||||
输入材料：
|
||||
- 工单模块需求：<粘贴需求>
|
||||
- 角色列表：管理员、工单负责人、研发处理人、测试验证人、只读观察者
|
||||
- 功能点：查看列表、查看详情、新建、编辑、指派、状态流转、关闭、删除、查看审计、查看看板、导出
|
||||
- 项目依据：<粘贴权限、路由、菜单相关路径>
|
||||
|
||||
输出要求：
|
||||
1. 先列事实依据：JeecgBoot 权限、菜单、动态路由相关路径。
|
||||
2. 输出 RBAC 权限矩阵：角色 x 功能点，允许、拒绝、条件允许。
|
||||
3. 输出权限字符建议，必须标注为建议。
|
||||
4. 输出页面级、按钮级、接口级、数据范围四层控制。
|
||||
5. 输出不确定点：哪些权限必须业务方确认。
|
||||
6. 输出验收方式：如何证明权限确实生效。
|
||||
|
||||
约束：
|
||||
- 不要直接改代码。
|
||||
- 不要把前端按钮隐藏当作安全边界。
|
||||
- 所有结论必须区分事实、推断、建议。
|
||||
```
|
||||
|
||||
@@ -0,0 +1,24 @@
|
||||
# 修复记录生成 Prompt
|
||||
|
||||
```text
|
||||
请根据阶段 Review 报告生成修复记录。
|
||||
|
||||
输入材料：
|
||||
- Review 报告：<粘贴>
|
||||
- 已完成修改说明：<粘贴>
|
||||
- 验证结果：<粘贴>
|
||||
|
||||
输出表格：
|
||||
Review 编号 | 问题 | 是否成立 | 修改文件 | 修改说明 | 验证结果 | 资产沉淀
|
||||
|
||||
要求：
|
||||
1. 如果问题不成立，说明理由和依据。
|
||||
2. 如果问题成立，说明修改了哪些文件。
|
||||
3. 每条修复必须有验证结果。
|
||||
4. 判断是否需要沉淀为资产，例如权限检查清单、状态流转检查清单、审计日志检查清单。
|
||||
|
||||
约束：
|
||||
- 不要模糊写“已修复”。
|
||||
- 没有验证结果的修复不能算完成。
|
||||
```
|
||||
|
||||
@@ -0,0 +1,24 @@
|
||||
# 异常态补齐 Prompt
|
||||
|
||||
```text
|
||||
请基于 JeecgBoot 工单模块，列出状态流转、指派、删除、查询详情、审计日志、看板相关的异常态和防御性逻辑。
|
||||
|
||||
输出表格：
|
||||
场景 | 触发条件 | 前端表现 | 后端响应 | 用户提示 | 测试点 | 验收
|
||||
|
||||
必须覆盖：
|
||||
- 权限不足
|
||||
- 工单不存在
|
||||
- 非法状态流转
|
||||
- 重复提交
|
||||
- 参数缺失
|
||||
- 并发修改
|
||||
- 看板无数据
|
||||
- 审计日志为空
|
||||
|
||||
约束：
|
||||
- 先列异常态，不要直接改代码。
|
||||
- 给出每个异常态的验收步骤。
|
||||
- 标注事实、推断、建议和不确定点。
|
||||
```
|
||||
|
||||
@@ -0,0 +1,24 @@
|
||||
# 权限控制方案生成 Prompt
|
||||
|
||||
```text
|
||||
请基于工单模块 RBAC 权限矩阵，生成 JeecgBoot 权限控制方案。
|
||||
|
||||
输入材料：
|
||||
- RBAC 权限矩阵：<粘贴>
|
||||
- 接口契约表：<粘贴>
|
||||
- 当前项目权限相关路径：<粘贴>
|
||||
- 当前 rules：<粘贴>
|
||||
|
||||
输出要求：
|
||||
1. 权限控制方案表，列为：操作、前端入口、权限字符、后端接口、后端校验、数据权限、验收。
|
||||
2. 影响范围：前端页面、API 文件、后端 Controller、Service、菜单配置、数据权限。
|
||||
3. 缺失风险：按钮隐藏、接口未校验、数据范围不清、权限字符不一致。
|
||||
4. 无权限访问验收步骤。
|
||||
5. 不确定点和需要人工确认的权限边界。
|
||||
|
||||
约束：
|
||||
- 不要直接改代码。
|
||||
- 后端接口权限必须单独说明。
|
||||
- 每个敏感操作必须有验收方式。
|
||||
```
|
||||
|
||||
@@ -0,0 +1,34 @@
|
||||
# 状态流转设计 Prompt
|
||||
|
||||
```text
|
||||
请为 JeecgBoot 工单模块设计状态流转规则。
|
||||
|
||||
状态候选：
|
||||
- 新建
|
||||
- 处理中
|
||||
- 待验证
|
||||
- 已关闭
|
||||
- 已驳回
|
||||
|
||||
动作候选：
|
||||
- 指派
|
||||
- 开始处理
|
||||
- 提交验证
|
||||
- 验证通过
|
||||
- 验证驳回
|
||||
- 关闭
|
||||
- 重新打开
|
||||
|
||||
输出要求：
|
||||
1. 状态流转表：当前状态、动作、目标状态、允许角色、前置条件、后置动作、验收。
|
||||
2. 非法流转清单：当前状态、尝试动作、问题、系统响应、验收。
|
||||
3. 接口设计建议。
|
||||
4. 测试点清单。
|
||||
5. 不确定点。
|
||||
|
||||
约束：
|
||||
- 先出状态表，不要直接写 if else。
|
||||
- 已关闭、越权、缺少说明、重复提交必须覆盖。
|
||||
- 每条规则必须有验收方式。
|
||||
```
|
||||
|
||||
@@ -0,0 +1,28 @@
|
||||
# 看板指标设计 Prompt
|
||||
|
||||
```text
|
||||
请为 JeecgBoot 工单模块设计研发效能看板指标。
|
||||
|
||||
指标方向：
|
||||
- 工单总数
|
||||
- 未关闭工单数
|
||||
- 平均关闭周期
|
||||
- 按优先级分布
|
||||
- 按类型分布
|
||||
- 缺陷趋势
|
||||
- 逾期工单数
|
||||
- 人员处理负载
|
||||
|
||||
输出要求：
|
||||
1. 指标字典：指标名、含义、口径、维度、过滤条件、数据来源、展示方式、权限。
|
||||
2. 看板统计接口契约建议。
|
||||
3. 空态、错误态、无权限态。
|
||||
4. 验收方式。
|
||||
5. 不确定点。
|
||||
|
||||
约束：
|
||||
- 每个指标必须可计算。
|
||||
- 不要只写页面 UI。
|
||||
- 指标口径不清必须写入不确定点。
|
||||
```
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
# 看板接口验收 Prompt
|
||||
|
||||
```text
|
||||
请为 JeecgBoot 工单看板统计接口生成验收记录。
|
||||
|
||||
输入材料：
|
||||
- 看板指标字典：<粘贴>
|
||||
- 看板接口契约：<粘贴>
|
||||
- 权限矩阵：<粘贴>
|
||||
|
||||
输出表格：
|
||||
验收项 | 账号/条件 | 请求参数 | 预期 | 实际 | 证据 | 结论
|
||||
|
||||
必须覆盖：
|
||||
- 有数据
|
||||
- 空数据
|
||||
- 无权限
|
||||
- 过滤条件
|
||||
- 指标口径
|
||||
- 时间范围
|
||||
- 数据范围
|
||||
|
||||
约束：
|
||||
- 不要只说“接口正常”。
|
||||
- 每个指标至少有一个验收动作。
|
||||
```
|
||||
|
||||
@@ -0,0 +1,30 @@
|
||||
# 阶段 Review Prompt
|
||||
|
||||
```text
|
||||
请对 JeecgBoot 工单模块阶段交付物做 Review。
|
||||
|
||||
输入材料：
|
||||
- RBAC 权限矩阵
|
||||
- 权限控制方案
|
||||
- 状态流转表
|
||||
- 非法流转清单
|
||||
- 审计日志 SOP
|
||||
- 异常态清单
|
||||
- 看板指标字典
|
||||
- 看板接口验收记录
|
||||
- 测试结果或验证记录
|
||||
|
||||
输出表格：
|
||||
等级 | 模块 | 问题 | 触发规则 | 风险 | 修复建议 | 验收
|
||||
|
||||
要求：
|
||||
1. 问题按 P0/P1/P2/P3 分级。
|
||||
2. 每个问题必须说明触发了哪条规则。
|
||||
3. 每条建议必须有验收方式。
|
||||
4. 输出不确定点和需要人工确认的内容。
|
||||
|
||||
约束：
|
||||
- 不要只说整体不错。
|
||||
- 不要直接改代码。
|
||||
```
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
# 后端规则
|
||||
|
||||
## 适用范围
|
||||
|
||||
Spring Boot、Controller、Service、Mapper、权限注解、事务、审计、状态流转。
|
||||
|
||||
## JeecgBoot 后端约束
|
||||
|
||||
1. 后端二开必须遵守 `update-begin` / `update-end` 修改痕迹规则。
|
||||
2. Controller 返回统一使用项目已有 `Result<T>` 风格。
|
||||
3. 查询优先复用项目已有 QueryWrapper/QueryGenerator 约定。
|
||||
4. 权限敏感接口必须有后端权限校验，不能只依赖前端按钮隐藏。
|
||||
5. 状态流转必须在 Service 层集中校验，不能只在前端限制。
|
||||
6. 删除、关闭、指派、状态变更必须考虑审计日志。
|
||||
7. 参数校验失败、数据不存在、非法状态、权限不足必须有明确响应。
|
||||
8. 涉及多步写入时必须说明事务边界。
|
||||
|
||||
## 输出验收
|
||||
|
||||
| 检查项 | 通过标准 |
|
||||
| --- | --- |
|
||||
| 修改痕迹 | 新增/修改代码块有 update 注释 |
|
||||
| 权限 | 无权限账号请求接口被拒绝 |
|
||||
| 状态 | 非法流转被 Service 拒绝 |
|
||||
| 审计 | 关键操作有日志记录方案 |
|
||||
| 事务 | 多表或多步骤写入说明事务 |
|
||||
|
||||
@@ -0,0 +1,33 @@
|
||||
# 交付规则
|
||||
|
||||
## 交付前必须准备
|
||||
|
||||
1. 需求拆解表。
|
||||
2. 接口契约表。
|
||||
3. 权限矩阵。
|
||||
4. 状态流转表和非法流转清单。
|
||||
5. 审计日志 SOP。
|
||||
6. 异常态清单。
|
||||
7. 看板指标字典。
|
||||
8. Review 报告。
|
||||
9. 修复记录。
|
||||
|
||||
## PR 或阶段交付说明必须包含
|
||||
|
||||
- 背景和目标。
|
||||
- 修改范围。
|
||||
- 不做什么。
|
||||
- 关键设计。
|
||||
- 测试和验收结果。
|
||||
- 风险和回滚建议。
|
||||
- AI 辅助使用记录。
|
||||
|
||||
## 输出验收
|
||||
|
||||
| 检查项 | 通过标准 |
|
||||
| --- | --- |
|
||||
| 范围 | 修改范围和非目标范围明确 |
|
||||
| 证据 | 关键结论有源码或表格依据 |
|
||||
| 验收 | 每个风险点有验证动作 |
|
||||
| 资产 | 可复用内容已归档到资产库 |
|
||||
|
||||
@@ -0,0 +1,26 @@
|
||||
# 前端规则
|
||||
|
||||
## 适用范围
|
||||
|
||||
Vue3、Vite、Pinia、路由、API 请求、页面状态、按钮权限、看板和表单。
|
||||
|
||||
## JeecgBoot 前端约束
|
||||
|
||||
1. 路径别名优先使用 `/@/`，不要随意引入新的 alias。
|
||||
2. API 请求必须复用项目请求层 `defHttp`，不要在页面中直接创建独立 axios 实例。
|
||||
3. 用户、权限、动态路由相关状态优先查 Pinia store。
|
||||
4. 新增页面必须考虑 loading、empty、error、forbidden 状态。
|
||||
5. 按钮权限不能作为安全边界，必须同步检查后端接口权限。
|
||||
6. 字典字段优先复用项目已有字典组件或工具，不在页面硬编码中文枚举。
|
||||
7. 表单提交必须考虑防重复提交、接口失败和参数校验反馈。
|
||||
|
||||
## 输出验收
|
||||
|
||||
| 检查项 | 通过标准 |
|
||||
| --- | --- |
|
||||
| API 层 | 页面没有绕过 `defHttp` |
|
||||
| 权限 | 页面按钮和后端接口都被检查 |
|
||||
| 状态 | loading、empty、error、forbidden 齐全 |
|
||||
| 字典 | 状态、优先级、类型不硬编码 |
|
||||
| 验证 | 给出浏览器或接口验收动作 |
|
||||
|
||||
@@ -0,0 +1,26 @@
|
||||
# 全局 AI 协作规则
|
||||
|
||||
## 适用范围
|
||||
|
||||
所有 TRAE 辅助分析、设计、编码、测试、Review 和文档任务。
|
||||
|
||||
## 必须遵守
|
||||
|
||||
1. 输出必须区分“事实依据、推断、建议、不确定点、下一步验证”。
|
||||
2. 项目事实必须标注文件、函数、接口、配置、日志或数据来源。
|
||||
3. 修改代码前必须先说明目标、范围、不做什么、影响文件、风险和验收方式。
|
||||
4. 复杂任务必须先生成 Plan，经人工确认后再进入修改。
|
||||
5. 不允许凭框架印象替代当前项目源码依据。
|
||||
6. 不允许删除历史逻辑，除非先说明影响范围和回滚方案。
|
||||
7. 不确定内容必须显式写入“不确定点”，不得包装成确定结论。
|
||||
|
||||
## 输出验收
|
||||
|
||||
| 检查项 | 通过标准 |
|
||||
| --- | --- |
|
||||
| 事实依据 | 每个关键结论能回到路径或代码 |
|
||||
| 推断 | 标注为什么是推断 |
|
||||
| 建议 | 有可执行下一步 |
|
||||
| 不确定点 | 明确需要谁确认或怎么验证 |
|
||||
| 验收方式 | 能由人或命令复核 |
|
||||
|
||||
@@ -0,0 +1,29 @@
|
||||
# 安全规则
|
||||
|
||||
## 必须禁止
|
||||
|
||||
1. 不允许提交密钥、Token、账号、密码、内网地址和真实租户 ID。
|
||||
2. 不允许在代码中硬编码生产环境地址。
|
||||
3. 不允许把前端按钮隐藏当作接口安全。
|
||||
4. 不允许在审计日志中明文记录敏感字段。
|
||||
5. 不允许让 AI 自行决定真实角色权限边界。
|
||||
|
||||
## 权限任务要求
|
||||
|
||||
权限相关输出必须覆盖：
|
||||
|
||||
- 页面是否可见。
|
||||
- 按钮是否可操作。
|
||||
- 接口是否可访问。
|
||||
- 数据范围是否受限。
|
||||
- 无权限访问如何验收。
|
||||
|
||||
## 输出验收
|
||||
|
||||
| 检查项 | 通过标准 |
|
||||
| --- | --- |
|
||||
| 敏感信息 | 输出未包含真实密钥或账号 |
|
||||
| 接口安全 | 后端权限校验被明确设计 |
|
||||
| 审计脱敏 | oldValue/newValue 有脱敏规则 |
|
||||
| 权限决策 | 标注待业务方确认 |
|
||||
|
||||
@@ -0,0 +1,32 @@
|
||||
# 测试规则
|
||||
|
||||
## 测试覆盖要求
|
||||
|
||||
每个功能至少覆盖：
|
||||
|
||||
1. 正常流。
|
||||
2. 异常流。
|
||||
3. 权限流。
|
||||
4. 状态流。
|
||||
5. 边界值。
|
||||
|
||||
## JeecgBoot 工单重点测试
|
||||
|
||||
| 类型 | 必测场景 |
|
||||
| --- | --- |
|
||||
| 权限 | 无权限账号直接请求删除/指派/关闭接口 |
|
||||
| 状态 | closed -> processing 等非法流转 |
|
||||
| 审计 | 编辑、指派、状态流转是否写审计 |
|
||||
| 异常态 | 工单不存在、重复提交、参数缺失 |
|
||||
| 看板 | 空数据、无权限、过滤条件、指标口径 |
|
||||
|
||||
## 输出验收
|
||||
|
||||
测试建议必须包含：
|
||||
|
||||
- 输入条件。
|
||||
- 操作步骤。
|
||||
- 预期结果。
|
||||
- 验证证据。
|
||||
- 不确定点。
|
||||
|
||||
@@ -0,0 +1,44 @@
|
||||
# JeecgBoot 工单模块开发审查 Skill
|
||||
|
||||
## 触发场景
|
||||
|
||||
涉及工单列表、详情、评论、状态、指派、看板、权限字符、数据权限、操作日志的需求拆解、代码生成或代码修改。
|
||||
|
||||
## 输入材料
|
||||
|
||||
- PR diff 或相关文件。
|
||||
- 工单需求说明。
|
||||
- 数据模型与接口契约。
|
||||
- 当前 rules。
|
||||
- 前端页面文件。
|
||||
- API 模块文件。
|
||||
- 后端 Controller / Service。
|
||||
- 权限矩阵。
|
||||
- 状态流转表。
|
||||
- 审计日志 SOP。
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. 识别需求范围和非目标范围。
|
||||
2. 检查字段、接口契约和页面状态是否完整。
|
||||
3. 审查 JeecgBoot 生成代码的字段、查询、分页、字典和异常态。
|
||||
4. 检查新增、编辑、删除、指派、状态变更的前端按钮与后端权限。
|
||||
5. 检查操作日志、数据权限和测试缺口。
|
||||
6. 检查看板指标口径和接口验收记录。
|
||||
7. 输出风险、不确定点和验收建议。
|
||||
|
||||
## 输出格式
|
||||
|
||||
- 需求范围确认。
|
||||
- 接口契约问题表。
|
||||
- 代码生成 Review 清单。
|
||||
- 权限风险表。
|
||||
- 状态流转风险表。
|
||||
- 审计日志风险表。
|
||||
- 测试缺口清单。
|
||||
- 不确定点清单。
|
||||
|
||||
## 验收标准
|
||||
|
||||
每个关键结论必须标注文件、函数、注解、配置或调用链依据。每条建议必须有验收方式。
|
||||
|
||||
+73
@@ -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.
|
||||
+7
@@ -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
|
||||
+16
@@ -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 | |
|
||||
|
||||
+25
@@ -0,0 +1,25 @@
|
||||
# RBAC 权限矩阵生成 Prompt
|
||||
|
||||
```text
|
||||
请基于 JeecgBoot 工单模块设计 RBAC 权限矩阵。
|
||||
|
||||
输入材料：
|
||||
- 工单模块需求：<粘贴需求>
|
||||
- 角色列表：管理员、工单负责人、研发处理人、测试验证人、只读观察者
|
||||
- 功能点：查看列表、查看详情、新建、编辑、指派、状态流转、关闭、删除、查看审计、查看看板、导出
|
||||
- 项目依据：<粘贴权限、路由、菜单相关路径>
|
||||
|
||||
输出要求：
|
||||
1. 先列事实依据：JeecgBoot 权限、菜单、动态路由相关路径。
|
||||
2. 输出 RBAC 权限矩阵：角色 x 功能点，允许、拒绝、条件允许。
|
||||
3. 输出权限字符建议，必须标注为建议。
|
||||
4. 输出页面级、按钮级、接口级、数据范围四层控制。
|
||||
5. 输出不确定点：哪些权限必须业务方确认。
|
||||
6. 输出验收方式：如何证明权限确实生效。
|
||||
|
||||
约束：
|
||||
- 不要直接改代码。
|
||||
- 不要把前端按钮隐藏当作安全边界。
|
||||
- 所有结论必须区分事实、推断、建议。
|
||||
```
|
||||
|
||||
+40
@@ -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. 多步写入失败时审计和业务数据保持一致。
|
||||
|
||||
+13
@@ -0,0 +1,13 @@
|
||||
# 审计日志检查清单
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 创建记录 | 创建工单后能查询审计记录 | |
|
||||
| 字段变更 | 编辑关键字段记录 oldValue/newValue | |
|
||||
| 指派记录 | 指派负责人记录原负责人和新负责人 | |
|
||||
| 状态记录 | 状态流转记录原状态和新状态 | |
|
||||
| 操作人 | actor_id 和 actor_name 可追溯 | |
|
||||
| 来源 | source 或 request_id 可追溯 | |
|
||||
| 脱敏 | 敏感字段不明文进入审计 | |
|
||||
| 失败处理 | 操作失败不写成功审计 | |
|
||||
|
||||
+13
@@ -0,0 +1,13 @@
|
||||
# 异常态检查清单
|
||||
|
||||
| 异常态 | 必须验证 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 空列表 | 页面显示空状态，不报错 | |
|
||||
| 详情不存在 | 提示工单不存在，页面不崩溃 | |
|
||||
| 权限不足 | 前端提示或隐藏，后端拒绝 | |
|
||||
| 非法状态 | 返回非法流转，状态不变 | |
|
||||
| 重复提交 | 只成功一次，只写一条有效审计 | |
|
||||
| 参数缺失 | 返回参数错误，业务数据不变 | |
|
||||
| 并发修改 | 拒绝覆盖或提示刷新 | |
|
||||
| 看板无数据 | 图表显示空态，不显示假数据 | |
|
||||
|
||||
+13
@@ -0,0 +1,13 @@
|
||||
# 工单异常态清单
|
||||
|
||||
| 场景 | 触发条件 | 前端表现 | 后端响应 | 验收 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 权限不足 | 无权限操作 | 按钮不可见或提示无权限 | 403 或业务拒绝 | 不完成操作 |
|
||||
| 工单不存在 | 传入错误 ID | 显示不存在 | 404 或业务错误 | 页面不崩溃 |
|
||||
| 非法状态流转 | closed -> processing | 提示非法流转 | 状态不变 | 数据状态不变 |
|
||||
| 重复提交 | 连续点击提交 | 按钮 loading/禁用 | 只处理一次 | 只生成一条有效审计 |
|
||||
| 参数缺失 | 驳回缺少原因 | 表单校验提示 | 参数错误 | 不改变状态 |
|
||||
| 并发修改 | 数据版本过期 | 提示刷新 | 拒绝覆盖 | 旧数据不覆盖新数据 |
|
||||
| 看板无数据 | 无匹配记录 | 空状态 | 返回空集合 | 页面不报错 |
|
||||
| 审计日志为空 | 无审计记录 | 空状态 | 返回空集合 | 页面不报错 |
|
||||
|
||||
+24
@@ -0,0 +1,24 @@
|
||||
# 异常态补齐 Prompt
|
||||
|
||||
```text
|
||||
请基于 JeecgBoot 工单模块，列出状态流转、指派、删除、查询详情、审计日志、看板相关的异常态和防御性逻辑。
|
||||
|
||||
输出表格：
|
||||
场景 | 触发条件 | 前端表现 | 后端响应 | 用户提示 | 测试点 | 验收
|
||||
|
||||
必须覆盖：
|
||||
- 权限不足
|
||||
- 工单不存在
|
||||
- 非法状态流转
|
||||
- 重复提交
|
||||
- 参数缺失
|
||||
- 并发修改
|
||||
- 看板无数据
|
||||
- 审计日志为空
|
||||
|
||||
约束：
|
||||
- 先列异常态，不要直接改代码。
|
||||
- 给出每个异常态的验收步骤。
|
||||
- 标注事实、推断、建议和不确定点。
|
||||
```
|
||||
|
||||
+12
@@ -0,0 +1,12 @@
|
||||
# 权限上线前检查清单
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 菜单权限 | 工单菜单只对授权角色可见 | |
|
||||
| 按钮权限 | 新增、编辑、删除、指派、状态按钮按权限显示 | |
|
||||
| 接口权限 | 无权限账号直接请求敏感接口失败 | |
|
||||
| 数据权限 | 普通用户只能看到授权范围内工单 | |
|
||||
| 权限字符 | 前端按钮、菜单配置、后端接口命名一致 | |
|
||||
| 审计 | 权限敏感操作成功后有审计记录 | |
|
||||
| 反例验证 | 无权限账号不能绕过前端执行删除/指派 | |
|
||||
|
||||
+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 | 权限注解 | 数据范围过滤 | 不同角色数据范围不同 |
|
||||
|
||||
+24
@@ -0,0 +1,24 @@
|
||||
# 权限控制方案生成 Prompt
|
||||
|
||||
```text
|
||||
请基于工单模块 RBAC 权限矩阵，生成 JeecgBoot 权限控制方案。
|
||||
|
||||
输入材料：
|
||||
- RBAC 权限矩阵：<粘贴>
|
||||
- 接口契约表：<粘贴>
|
||||
- 当前项目权限相关路径：<粘贴>
|
||||
- 当前 rules：<粘贴>
|
||||
|
||||
输出要求：
|
||||
1. 权限控制方案表，列为：操作、前端入口、权限字符、后端接口、后端校验、数据权限、验收。
|
||||
2. 影响范围：前端页面、API 文件、后端 Controller、Service、菜单配置、数据权限。
|
||||
3. 缺失风险：按钮隐藏、接口未校验、数据范围不清、权限字符不一致。
|
||||
4. 无权限访问验收步骤。
|
||||
5. 不确定点和需要人工确认的权限边界。
|
||||
|
||||
约束：
|
||||
- 不要直接改代码。
|
||||
- 后端接口权限必须单独说明。
|
||||
- 每个敏感操作必须有验收方式。
|
||||
```
|
||||
|
||||
+12
@@ -0,0 +1,12 @@
|
||||
# 状态流转检查清单
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 状态枚举 | 所有状态有统一枚举或字典 | |
|
||||
| 合法流转 | 状态流转表中的合法路径可执行 | |
|
||||
| 非法流转 | 非法路径被拒绝且状态不变 | |
|
||||
| 角色限制 | 不同角色只能执行被授权动作 | |
|
||||
| 前置条件 | 驳回原因、关闭条件、负责人等校验完整 | |
|
||||
| 审计日志 | 每次成功流转写审计 | |
|
||||
| 重复提交 | 重复点击不会产生重复有效流转 | |
|
||||
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
# 工单状态流转表
|
||||
|
||||
| 当前状态 | 动作 | 目标状态 | 允许角色 | 前置条件 | 后置动作 | 验收 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| 新建 | 指派 | 新建 | 管理员/负责人 | 工单未关闭 | 写审计日志 | 指派人变化且状态不变 |
|
||||
| 新建 | 开始处理 | 处理中 | 研发处理人/负责人 | 已指派处理人 | 写审计日志 | 状态变为处理中 |
|
||||
| 处理中 | 提交验证 | 待验证 | 研发处理人/负责人 | 处理说明不为空 | 写审计日志 | 状态变为待验证 |
|
||||
| 待验证 | 验证通过 | 已关闭 | 测试验证人/负责人 | 验证结果通过 | 写审计日志和关闭时间 | 状态变为已关闭 |
|
||||
| 待验证 | 验证驳回 | 已驳回 | 测试验证人/负责人 | 驳回原因不为空 | 写审计日志 | 状态变为已驳回 |
|
||||
| 已驳回 | 重新处理 | 处理中 | 研发处理人/负责人 | 驳回原因已读 | 写审计日志 | 状态变为处理中 |
|
||||
| 已关闭 | 重新打开 | 新建 | 管理员 | 重开原因不为空 | 写审计日志 | 状态变为新建 |
|
||||
|
||||
## 非法流转清单
|
||||
|
||||
| 当前状态 | 尝试动作 | 问题 | 系统响应 | 验收 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 已关闭 | 开始处理 | 关闭后不能直接处理 | 返回非法流转 | 状态不变 |
|
||||
| 新建 | 验证通过 | 未处理不能验证 | 返回非法流转 | 状态不变 |
|
||||
| 待验证 | 提交验证 | 重复提交验证 | 返回非法流转 | 只保留原状态 |
|
||||
| 处理中 | 验证通过 | 未进入待验证 | 返回非法流转 | 状态不变 |
|
||||
| 已驳回 | 关闭 | 驳回后不能直接关闭 | 返回非法流转 | 状态不变 |
|
||||
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
# 状态流转设计 Prompt
|
||||
|
||||
```text
|
||||
请为 JeecgBoot 工单模块设计状态流转规则。
|
||||
|
||||
状态候选：
|
||||
- 新建
|
||||
- 处理中
|
||||
- 待验证
|
||||
- 已关闭
|
||||
- 已驳回
|
||||
|
||||
动作候选：
|
||||
- 指派
|
||||
- 开始处理
|
||||
- 提交验证
|
||||
- 验证通过
|
||||
- 验证驳回
|
||||
- 关闭
|
||||
- 重新打开
|
||||
|
||||
输出要求：
|
||||
1. 状态流转表：当前状态、动作、目标状态、允许角色、前置条件、后置动作、验收。
|
||||
2. 非法流转清单：当前状态、尝试动作、问题、系统响应、验收。
|
||||
3. 接口设计建议。
|
||||
4. 测试点清单。
|
||||
5. 不确定点。
|
||||
|
||||
约束：
|
||||
- 先出状态表，不要直接写 if else。
|
||||
- 已关闭、越权、缺少说明、重复提交必须覆盖。
|
||||
- 每条规则必须有验收方式。
|
||||
```
|
||||
|
||||
+13
@@ -0,0 +1,13 @@
|
||||
# 看板指标口径检查清单
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 指标含义 | 每个指标有业务解释 | |
|
||||
| 计算口径 | 每个指标有公式或筛选条件 | |
|
||||
| 时间范围 | 明确按创建时间、关闭时间还是更新时间统计 | |
|
||||
| 数据范围 | 不同角色的数据范围清楚 | |
|
||||
| 空数据 | 空数据展示为 0 或空态，不误导 | |
|
||||
| 分组一致性 | 分组总和能和总数对齐 | |
|
||||
| 权限 | 无看板权限不能访问接口 | |
|
||||
| 验收证据 | 至少有一组样例数据手工校验 | |
|
||||
|
||||
+13
@@ -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 | 工单表 | 排行榜 | 管理员/负责人 | 数据范围正确 |
|
||||
|
||||
+28
@@ -0,0 +1,28 @@
|
||||
# 看板指标设计 Prompt
|
||||
|
||||
```text
|
||||
请为 JeecgBoot 工单模块设计研发效能看板指标。
|
||||
|
||||
指标方向：
|
||||
- 工单总数
|
||||
- 未关闭工单数
|
||||
- 平均关闭周期
|
||||
- 按优先级分布
|
||||
- 按类型分布
|
||||
- 缺陷趋势
|
||||
- 逾期工单数
|
||||
- 人员处理负载
|
||||
|
||||
输出要求：
|
||||
1. 指标字典：指标名、含义、口径、维度、过滤条件、数据来源、展示方式、权限。
|
||||
2. 看板统计接口契约建议。
|
||||
3. 空态、错误态、无权限态。
|
||||
4. 验收方式。
|
||||
5. 不确定点。
|
||||
|
||||
约束：
|
||||
- 每个指标必须可计算。
|
||||
- 不要只写页面 UI。
|
||||
- 指标口径不清必须写入不确定点。
|
||||
```
|
||||
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
# 看板接口验收 Prompt
|
||||
|
||||
```text
|
||||
请为 JeecgBoot 工单看板统计接口生成验收记录。
|
||||
|
||||
输入材料：
|
||||
- 看板指标字典：<粘贴>
|
||||
- 看板接口契约：<粘贴>
|
||||
- 权限矩阵：<粘贴>
|
||||
|
||||
输出表格：
|
||||
验收项 | 账号/条件 | 请求参数 | 预期 | 实际 | 证据 | 结论
|
||||
|
||||
必须覆盖：
|
||||
- 有数据
|
||||
- 空数据
|
||||
- 无权限
|
||||
- 过滤条件
|
||||
- 指标口径
|
||||
- 时间范围
|
||||
- 数据范围
|
||||
|
||||
约束：
|
||||
- 不要只说“接口正常”。
|
||||
- 每个指标至少有一个验收动作。
|
||||
```
|
||||
|
||||
+12
@@ -0,0 +1,12 @@
|
||||
# 看板接口验收清单
|
||||
|
||||
| 验收项 | 请求条件 | 通过标准 | 结果 |
|
||||
| --- | --- | --- | --- |
|
||||
| 默认查询 | 管理员默认条件 | 返回完整指标 | |
|
||||
| 时间过滤 | 指定 start/end | 只统计时间范围内数据 | |
|
||||
| 类型过滤 | 指定工单类型 | 只统计对应类型 | |
|
||||
| 空数据 | 无匹配条件 | 返回 0 或空集合 | |
|
||||
| 无权限 | 未授权账号 | 返回 403 或业务拒绝 | |
|
||||
| 数据范围 | 普通角色 | 只返回授权范围 | |
|
||||
| 指标一致性 | 固定样例数据 | 与手工计算一致 | |
|
||||
|
||||
+11
@@ -0,0 +1,11 @@
|
||||
# 工单看板接口验收记录
|
||||
|
||||
| 验收项 | 账号/条件 | 请求参数 | 预期 | 实际 | 证据 | 结论 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| 工单总数 | 管理员 | 默认筛选 | 返回总数 | | | |
|
||||
| 空数据 | 管理员 + 无匹配条件 | 不存在的日期范围 | 返回空集合或 0 | | | |
|
||||
| 无权限 | 只读外角色 | 默认筛选 | 返回 403 或业务拒绝 | | | |
|
||||
| 时间过滤 | 管理员 | start/end | 只统计范围内数据 | | | |
|
||||
| 数据范围 | 普通研发 | 默认筛选 | 只返回本人相关数据 | | | |
|
||||
| 指标口径 | 管理员 | 固定样例数据 | 与手工计算一致 | | | |
|
||||
|
||||
+125
@@ -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.
|
||||
+7
@@ -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
|
||||
+43
@@ -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 或测试要求时无法证明 | 新增核心逻辑需补测试或说明豁免 | 技术负责人 |
|
||||
+61
@@ -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
|
||||
## 规则名称
|
||||
|
||||
- 级别：
|
||||
- 适用场景：
|
||||
- 必须：
|
||||
- 禁止：
|
||||
- 来源证据：
|
||||
- 验收方式：
|
||||
- 迁移说明：
|
||||
```
|
||||
|
||||
最后输出：
|
||||
|
||||
- 已读来源。
|
||||
- 缺失证据。
|
||||
- 待确认问题。
|
||||
- 不能迁移到其他项目的项目特有约束。
|
||||
+44
@@ -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.
|
||||
+7
@@ -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
|
||||
+28
@@ -0,0 +1,28 @@
|
||||
# AI Review 报告模板
|
||||
|
||||
## Review 输入
|
||||
|
||||
- PR diff：
|
||||
- 需求说明：
|
||||
- rules：
|
||||
- 测试结果：
|
||||
- 历史问题：
|
||||
|
||||
## 结论
|
||||
|
||||
通过 / 有条件通过 / 不通过
|
||||
|
||||
## 问题清单
|
||||
|
||||
| 等级 | 文件/模块 | 问题 | 触发规则 | 风险 | 建议 | 测试/验收 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
|
||||
## 不确定点
|
||||
|
||||
| 不确定点 | 需要谁确认 | 验证方式 |
|
||||
| --- | --- | --- |
|
||||
|
||||
## 是否建议合入
|
||||
|
||||
说明理由。
|
||||
|
||||
+13
@@ -0,0 +1,13 @@
|
||||
# 审计日志检查清单
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 创建记录 | 创建工单后能查询审计记录 | |
|
||||
| 字段变更 | 编辑关键字段记录 oldValue/newValue | |
|
||||
| 指派记录 | 指派负责人记录原负责人和新负责人 | |
|
||||
| 状态记录 | 状态流转记录原状态和新状态 | |
|
||||
| 操作人 | actor_id 和 actor_name 可追溯 | |
|
||||
| 来源 | source 或 request_id 可追溯 | |
|
||||
| 脱敏 | 敏感字段不明文进入审计 | |
|
||||
| 失败处理 | 操作失败不写成功审计 | |
|
||||
|
||||
+13
@@ -0,0 +1,13 @@
|
||||
# 异常态检查清单
|
||||
|
||||
| 异常态 | 必须验证 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 空列表 | 页面显示空状态，不报错 | |
|
||||
| 详情不存在 | 提示工单不存在，页面不崩溃 | |
|
||||
| 权限不足 | 前端提示或隐藏，后端拒绝 | |
|
||||
| 非法状态 | 返回非法流转，状态不变 | |
|
||||
| 重复提交 | 只成功一次，只写一条有效审计 | |
|
||||
| 参数缺失 | 返回参数错误，业务数据不变 | |
|
||||
| 并发修改 | 拒绝覆盖或提示刷新 | |
|
||||
| 看板无数据 | 图表显示空态，不显示假数据 | |
|
||||
|
||||
+12
@@ -0,0 +1,12 @@
|
||||
# 权限上线前检查清单
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 菜单权限 | 工单菜单只对授权角色可见 | |
|
||||
| 按钮权限 | 新增、编辑、删除、指派、状态按钮按权限显示 | |
|
||||
| 接口权限 | 无权限账号直接请求敏感接口失败 | |
|
||||
| 数据权限 | 普通用户只能看到授权范围内工单 | |
|
||||
| 权限字符 | 前端按钮、菜单配置、后端接口命名一致 | |
|
||||
| 审计 | 权限敏感操作成功后有审计记录 | |
|
||||
| 反例验证 | 无权限账号不能绕过前端执行删除/指派 | |
|
||||
|
||||
+12
@@ -0,0 +1,12 @@
|
||||
# 状态流转检查清单
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 状态枚举 | 所有状态有统一枚举或字典 | |
|
||||
| 合法流转 | 状态流转表中的合法路径可执行 | |
|
||||
| 非法流转 | 非法路径被拒绝且状态不变 | |
|
||||
| 角色限制 | 不同角色只能执行被授权动作 | |
|
||||
| 前置条件 | 驳回原因、关闭条件、负责人等校验完整 | |
|
||||
| 审计日志 | 每次成功流转写审计 | |
|
||||
| 重复提交 | 重复点击不会产生重复有效流转 | |
|
||||
|
||||
+13
@@ -0,0 +1,13 @@
|
||||
# 看板指标口径检查清单
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 指标含义 | 每个指标有业务解释 | |
|
||||
| 计算口径 | 每个指标有公式或筛选条件 | |
|
||||
| 时间范围 | 明确按创建时间、关闭时间还是更新时间统计 | |
|
||||
| 数据范围 | 不同角色的数据范围清楚 | |
|
||||
| 空数据 | 空数据展示为 0 或空态，不误导 | |
|
||||
| 分组一致性 | 分组总和能和总数对齐 | |
|
||||
| 权限 | 无看板权限不能访问接口 | |
|
||||
| 验收证据 | 至少有一组样例数据手工校验 | |
|
||||
|
||||
+12
@@ -0,0 +1,12 @@
|
||||
# 看板接口验收清单
|
||||
|
||||
| 验收项 | 请求条件 | 通过标准 | 结果 |
|
||||
| --- | --- | --- | --- |
|
||||
| 默认查询 | 管理员默认条件 | 返回完整指标 | |
|
||||
| 时间过滤 | 指定 start/end | 只统计时间范围内数据 | |
|
||||
| 类型过滤 | 指定工单类型 | 只统计对应类型 | |
|
||||
| 空数据 | 无匹配条件 | 返回 0 或空集合 | |
|
||||
| 无权限 | 未授权账号 | 返回 403 或业务拒绝 | |
|
||||
| 数据范围 | 普通角色 | 只返回授权范围 | |
|
||||
| 指标一致性 | 固定样例数据 | 与手工计算一致 | |
|
||||
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
# 阶段 Review Prompt
|
||||
|
||||
```text
|
||||
请对 JeecgBoot 工单模块阶段交付物做 Review。
|
||||
|
||||
输入材料：
|
||||
- RBAC 权限矩阵
|
||||
- 权限控制方案
|
||||
- 状态流转表
|
||||
- 非法流转清单
|
||||
- 审计日志 SOP
|
||||
- 异常态清单
|
||||
- 看板指标字典
|
||||
- 看板接口验收记录
|
||||
- 测试结果或验证记录
|
||||
|
||||
输出表格：
|
||||
等级 | 模块 | 问题 | 触发规则 | 风险 | 修复建议 | 验收
|
||||
|
||||
要求：
|
||||
1. 问题按 P0/P1/P2/P3 分级。
|
||||
2. 每个问题必须说明触发了哪条规则。
|
||||
3. 每条建议必须有验收方式。
|
||||
4. 输出不确定点和需要人工确认的内容。
|
||||
|
||||
约束：
|
||||
- 不要只说整体不错。
|
||||
- 不要直接改代码。
|
||||
```
|
||||
|
||||
+28
@@ -0,0 +1,28 @@
|
||||
# 阶段 Review 报告
|
||||
|
||||
## Review 输入
|
||||
|
||||
- RBAC 权限矩阵：
|
||||
- 权限控制方案：
|
||||
- 状态流转表：
|
||||
- 非法流转清单：
|
||||
- 审计日志 SOP：
|
||||
- 异常态清单：
|
||||
- 看板指标字典：
|
||||
- 看板接口验收记录：
|
||||
|
||||
## 问题清单
|
||||
|
||||
| 等级 | 模块 | 问题 | 触发规则 | 风险 | 修复建议 | 验收 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| P1 | 权限 | 删除接口只隐藏按钮，后端缺少权限校验 | 前端按钮不是安全边界 | 可绕过前端删除工单 | 后端补权限校验 | 无权限账号请求返回 403 |
|
||||
|
||||
## 不确定点
|
||||
|
||||
| 不确定点 | 影响 | 需要谁确认 |
|
||||
| --- | --- | --- |
|
||||
|
||||
## 结论
|
||||
|
||||
通过 / 有条件通过 / 不通过
|
||||
|
||||
+71
@@ -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.
|
||||
+7
@@ -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
|
||||
+12
@@ -0,0 +1,12 @@
|
||||
# Review 修复闭环检查清单
|
||||
|
||||
| 检查项 | 通过标准 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 问题编号 | 每个 Review 问题有编号 | |
|
||||
| 成立判断 | 每个问题说明是否成立 | |
|
||||
| 修改说明 | 成立问题说明修改文件和内容 | |
|
||||
| 验证结果 | 每个修复有验证证据 | |
|
||||
| 未修复说明 | 暂不修复的问题有原因和后续计划 | |
|
||||
| 资产沉淀 | 有复用价值的问题已进入检查清单或反例库 | |
|
||||
| 回归检查 | 修复后重新检查相关权限/状态/审计/看板 | |
|
||||
|
||||
+8
@@ -0,0 +1,8 @@
|
||||
# Review 修复记录
|
||||
|
||||
| Review 编号 | 问题 | 是否成立 | 修改文件 | 修改说明 | 验证结果 | 资产沉淀 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| R01 | 删除接口缺少后端权限校验 | 是 | WorkOrderController | 增加权限校验 | 无权限请求被拒绝 | 权限检查清单 |
|
||||
| R02 | closed 可重新处理 | 是 | WorkOrderService | 补非法流转校验 | closed -> processing 失败 | 状态流转检查清单 |
|
||||
| R03 | 看板关闭周期口径不清 | 是 | 指标字典/看板接口 | 明确 create_time 到 close_time | 指标说明已更新 | 看板指标口径清单 |
|
||||
|
||||
+24
@@ -0,0 +1,24 @@
|
||||
# 修复记录生成 Prompt
|
||||
|
||||
```text
|
||||
请根据阶段 Review 报告生成修复记录。
|
||||
|
||||
输入材料：
|
||||
- Review 报告：<粘贴>
|
||||
- 已完成修改说明：<粘贴>
|
||||
- 验证结果：<粘贴>
|
||||
|
||||
输出表格：
|
||||
Review 编号 | 问题 | 是否成立 | 修改文件 | 修改说明 | 验证结果 | 资产沉淀
|
||||
|
||||
要求：
|
||||
1. 如果问题不成立，说明理由和依据。
|
||||
2. 如果问题成立，说明修改了哪些文件。
|
||||
3. 每条修复必须有验证结果。
|
||||
4. 判断是否需要沉淀为资产，例如权限检查清单、状态流转检查清单、审计日志检查清单。
|
||||
|
||||
约束：
|
||||
- 不要模糊写“已修复”。
|
||||
- 没有验证结果的修复不能算完成。
|
||||
```
|
||||
|
||||
+32
@@ -0,0 +1,32 @@
|
||||
# 审计日志缺失反例
|
||||
|
||||
## 场景
|
||||
|
||||
工单指派负责人成功，但没有记录审计日志。
|
||||
|
||||
## 问题表现
|
||||
|
||||
| 操作 | 结果 |
|
||||
| --- | --- |
|
||||
| 张三将工单指派给李四 | 工单负责人变更成功 |
|
||||
| 查询审计日志 | 没有负责人变更记录 |
|
||||
|
||||
## 风险
|
||||
|
||||
无法追溯负责人变化，出现延误或争议时无法定位责任。
|
||||
|
||||
## 修复要求
|
||||
|
||||
1. 指派成功后写审计日志。
|
||||
2. 记录原负责人、新负责人、操作人、时间、来源。
|
||||
3. 指派失败不写成功审计。
|
||||
4. 多步写入需要事务一致性。
|
||||
|
||||
## 验收
|
||||
|
||||
| 操作 | 预期 |
|
||||
| --- | --- |
|
||||
| 指派成功 | 审计列表出现 ASSIGN 记录 |
|
||||
| 指派失败 | 不出现成功审计 |
|
||||
| 查询详情 | 审计记录可在工单详情查看 |
|
||||
|
||||
+33
@@ -0,0 +1,33 @@
|
||||
# 权限遗漏反例
|
||||
|
||||
## 场景
|
||||
|
||||
工单删除按钮在前端按权限隐藏，但后端删除接口没有权限校验。
|
||||
|
||||
## 问题代码表现
|
||||
|
||||
| 层级 | 表现 |
|
||||
| --- | --- |
|
||||
| 前端 | 普通研发账号看不到删除按钮 |
|
||||
| 后端 | 直接请求 `/workOrder/delete` 仍可删除 |
|
||||
| 审计 | 删除记录可能缺失 |
|
||||
|
||||
## 风险
|
||||
|
||||
攻击者或误操作用户可以绕过前端直接调用接口删除工单。
|
||||
|
||||
## 修复要求
|
||||
|
||||
1. 后端删除接口增加权限校验。
|
||||
2. 删除前校验数据范围。
|
||||
3. 删除成功写审计日志。
|
||||
4. 无权限账号直接请求接口返回 403 或业务拒绝。
|
||||
|
||||
## 验收
|
||||
|
||||
| 账号 | 操作 | 预期 |
|
||||
| --- | --- | --- |
|
||||
| 管理员 | 删除允许删除的工单 | 成功并写审计 |
|
||||
| 普通研发 | 直接请求删除接口 | 失败 |
|
||||
| 只读用户 | 前端访问删除按钮 | 不可见 |
|
||||
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
# 看板指标口径不清反例
|
||||
|
||||
## 场景
|
||||
|
||||
看板展示“平均关闭周期”，但没有说明从哪个时间到哪个时间。
|
||||
|
||||
## 问题表现
|
||||
|
||||
| 指标 | 当前说明 |
|
||||
| --- | --- |
|
||||
| 平均关闭周期 | 最近工单平均处理时间 |
|
||||
|
||||
## 风险
|
||||
|
||||
不同人理解不同：可能是创建到关闭，也可能是开始处理到关闭，导致管理判断失真。
|
||||
|
||||
## 修复要求
|
||||
|
||||
1. 明确定义为 `close_time - create_time` 或其他确定口径。
|
||||
2. 明确是否排除未关闭工单。
|
||||
3. 明确时间范围过滤字段。
|
||||
4. 用样例数据手工校验。
|
||||
|
||||
## 验收
|
||||
|
||||
| 样例 | 预期 |
|
||||
| --- | --- |
|
||||
| 工单 A 创建 1 日、关闭 3 日 | 周期 2 天 |
|
||||
| 未关闭工单 | 不计入平均关闭周期 |
|
||||
| 过滤 7 月 | 只统计 7 月范围内符合口径的数据 |
|
||||
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
# 非法状态流转反例
|
||||
|
||||
## 场景
|
||||
|
||||
已关闭工单可以直接被改回处理中。
|
||||
|
||||
## 问题表现
|
||||
|
||||
| 当前状态 | 动作 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 已关闭 | 开始处理 | 状态变成处理中 |
|
||||
|
||||
## 风险
|
||||
|
||||
已关闭工单被重新打开但没有重开原因、没有审计、没有负责人确认，导致统计和责任链失真。
|
||||
|
||||
## 修复要求
|
||||
|
||||
1. Service 层集中校验状态流转。
|
||||
2. 已关闭工单只能通过“重新打开”动作变为新建。
|
||||
3. 重新打开必须填写原因。
|
||||
4. 所有成功流转写审计日志。
|
||||
|
||||
## 验收
|
||||
|
||||
| 操作 | 预期 |
|
||||
| --- | --- |
|
||||
| closed -> processing | 失败，状态不变 |
|
||||
| closed -> reopen -> new | 成功，必须有原因 |
|
||||
| 重开成功 | 审计记录 oldValue=closed, newValue=new |
|
||||
|
||||
@@ -0,0 +1,28 @@
|
||||
# AI Review 报告模板
|
||||
|
||||
## Review 输入
|
||||
|
||||
- PR diff：
|
||||
- 需求说明：
|
||||
- rules：
|
||||
- 测试结果：
|
||||
- 历史问题：
|
||||
|
||||
## 结论
|
||||
|
||||
通过 / 有条件通过 / 不通过
|
||||
|
||||
## 问题清单
|
||||
|
||||
| 等级 | 文件/模块 | 问题 | 触发规则 | 风险 | 建议 | 测试/验收 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
|
||||
## 不确定点
|
||||
|
||||
| 不确定点 | 需要谁确认 | 验证方式 |
|
||||
| --- | --- | --- |
|
||||
|
||||
## 是否建议合入
|
||||
|
||||
说明理由。
|
||||
|
||||
@@ -0,0 +1,23 @@
|
||||
# Browser 验证报告模板
|
||||
|
||||
## 验证对象
|
||||
|
||||
- 页面：
|
||||
- 分支/版本：
|
||||
- 账号/角色：
|
||||
- 浏览器：
|
||||
|
||||
## 验证项
|
||||
|
||||
| 验收项 | 账号/条件 | 操作步骤 | 预期 | 实际 | 证据 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 页面打开 | | | | | |
|
||||
| 主流程 | | | | | |
|
||||
| 权限态 | | | | | |
|
||||
| 空态 | | | | | |
|
||||
| 错误态 | | | | | |
|
||||
|
||||
## 结论
|
||||
|
||||
通过 / 有条件通过 / 不通过
|
||||
|
||||
@@ -0,0 +1,36 @@
|
||||
# Plan 任务模板
|
||||
|
||||
## 目标
|
||||
|
||||
说明本次任务要解决什么问题。
|
||||
|
||||
## 范围
|
||||
|
||||
列出会涉及的模块、页面、接口、数据和配置。
|
||||
|
||||
## 不做什么
|
||||
|
||||
明确排除项，避免 AI 扩大范围。
|
||||
|
||||
## 输入材料
|
||||
|
||||
- 需求说明：
|
||||
- 源码依据：
|
||||
- 规则文件：
|
||||
- 验收标准：
|
||||
|
||||
## 修改步骤
|
||||
|
||||
| 步骤 | 文件/模块 | 动作 | 风险 | 验收 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 1 | | | | |
|
||||
|
||||
## 风险点
|
||||
|
||||
| 风险 | 影响 | 应对 | 验收 |
|
||||
| --- | --- | --- | --- |
|
||||
|
||||
## 验证方式
|
||||
|
||||
列出命令、页面操作、账号、数据和预期结果。
|
||||
|
||||
@@ -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,8 @@
|
||||
# Review 修复记录
|
||||
|
||||
| Review 编号 | 问题 | 是否成立 | 修改文件 | 修改说明 | 验证结果 | 资产沉淀 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| R01 | 删除接口缺少后端权限校验 | 是 | WorkOrderController | 增加权限校验 | 无权限请求被拒绝 | 权限检查清单 |
|
||||
| R02 | closed 可重新处理 | 是 | WorkOrderService | 补非法流转校验 | closed -> processing 失败 | 状态流转检查清单 |
|
||||
| R03 | 看板关闭周期口径不清 | 是 | 指标字典/看板接口 | 明确 create_time 到 close_time | 指标说明已更新 | 看板指标口径清单 |
|
||||
|
||||
@@ -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 @@
|
||||
# 工单异常态清单
|
||||
|
||||
| 场景 | 触发条件 | 前端表现 | 后端响应 | 验收 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 权限不足 | 无权限操作 | 按钮不可见或提示无权限 | 403 或业务拒绝 | 不完成操作 |
|
||||
| 工单不存在 | 传入错误 ID | 显示不存在 | 404 或业务错误 | 页面不崩溃 |
|
||||
| 非法状态流转 | closed -> processing | 提示非法流转 | 状态不变 | 数据状态不变 |
|
||||
| 重复提交 | 连续点击提交 | 按钮 loading/禁用 | 只处理一次 | 只生成一条有效审计 |
|
||||
| 参数缺失 | 驳回缺少原因 | 表单校验提示 | 参数错误 | 不改变状态 |
|
||||
| 并发修改 | 数据版本过期 | 提示刷新 | 拒绝覆盖 | 旧数据不覆盖新数据 |
|
||||
| 看板无数据 | 无匹配记录 | 空状态 | 返回空集合 | 页面不报错 |
|
||||
| 审计日志为空 | 无审计记录 | 空状态 | 返回空集合 | 页面不报错 |
|
||||
|
||||
@@ -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,22 @@
|
||||
# 工单状态流转表
|
||||
|
||||
| 当前状态 | 动作 | 目标状态 | 允许角色 | 前置条件 | 后置动作 | 验收 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| 新建 | 指派 | 新建 | 管理员/负责人 | 工单未关闭 | 写审计日志 | 指派人变化且状态不变 |
|
||||
| 新建 | 开始处理 | 处理中 | 研发处理人/负责人 | 已指派处理人 | 写审计日志 | 状态变为处理中 |
|
||||
| 处理中 | 提交验证 | 待验证 | 研发处理人/负责人 | 处理说明不为空 | 写审计日志 | 状态变为待验证 |
|
||||
| 待验证 | 验证通过 | 已关闭 | 测试验证人/负责人 | 验证结果通过 | 写审计日志和关闭时间 | 状态变为已关闭 |
|
||||
| 待验证 | 验证驳回 | 已驳回 | 测试验证人/负责人 | 驳回原因不为空 | 写审计日志 | 状态变为已驳回 |
|
||||
| 已驳回 | 重新处理 | 处理中 | 研发处理人/负责人 | 驳回原因已读 | 写审计日志 | 状态变为处理中 |
|
||||
| 已关闭 | 重新打开 | 新建 | 管理员 | 重开原因不为空 | 写审计日志 | 状态变为新建 |
|
||||
|
||||
## 非法流转清单
|
||||
|
||||
| 当前状态 | 尝试动作 | 问题 | 系统响应 | 验收 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 已关闭 | 开始处理 | 关闭后不能直接处理 | 返回非法流转 | 状态不变 |
|
||||
| 新建 | 验证通过 | 未处理不能验证 | 返回非法流转 | 状态不变 |
|
||||
| 待验证 | 提交验证 | 重复提交验证 | 返回非法流转 | 只保留原状态 |
|
||||
| 处理中 | 验证通过 | 未进入待验证 | 返回非法流转 | 状态不变 |
|
||||
| 已驳回 | 关闭 | 驳回后不能直接关闭 | 返回非法流转 | 状态不变 |
|
||||
|
||||
@@ -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,11 @@
|
||||
# 工单看板接口验收记录
|
||||
|
||||
| 验收项 | 账号/条件 | 请求参数 | 预期 | 实际 | 证据 | 结论 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| 工单总数 | 管理员 | 默认筛选 | 返回总数 | | | |
|
||||
| 空数据 | 管理员 + 无匹配条件 | 不存在的日期范围 | 返回空集合或 0 | | | |
|
||||
| 无权限 | 只读外角色 | 默认筛选 | 返回 403 或业务拒绝 | | | |
|
||||
| 时间过滤 | 管理员 | start/end | 只统计范围内数据 | | | |
|
||||
| 数据范围 | 普通研发 | 默认筛选 | 只返回本人相关数据 | | | |
|
||||
| 指标口径 | 管理员 | 固定样例数据 | 与手工计算一致 | | | |
|
||||
|
||||
@@ -0,0 +1,28 @@
|
||||
# 阶段 Review 报告
|
||||
|
||||
## Review 输入
|
||||
|
||||
- RBAC 权限矩阵：
|
||||
- 权限控制方案：
|
||||
- 状态流转表：
|
||||
- 非法流转清单：
|
||||
- 审计日志 SOP：
|
||||
- 异常态清单：
|
||||
- 看板指标字典：
|
||||
- 看板接口验收记录：
|
||||
|
||||
## 问题清单
|
||||
|
||||
| 等级 | 模块 | 问题 | 触发规则 | 风险 | 修复建议 | 验收 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| P1 | 权限 | 删除接口只隐藏按钮，后端缺少权限校验 | 前端按钮不是安全边界 | 可绕过前端删除工单 | 后端补权限校验 | 无权限账号请求返回 403 |
|
||||
|
||||
## 不确定点
|
||||
|
||||
| 不确定点 | 影响 | 需要谁确认 |
|
||||
| --- | --- | --- |
|
||||
|
||||
## 结论
|
||||
|
||||
通过 / 有条件通过 / 不通过
|
||||
|
||||
@@ -0,0 +1,232 @@
|
||||
# 资产归档索引
|
||||
|
||||
本文件用于说明 JeecgBoot 工单案例如何沉淀为团队可复用资产。具体可直接复制使用的资产已经生成在 [ai-dev-assets/](./ai-dev-assets/README.md)。
|
||||
|
||||
如果要发给学员或项目团队，优先发：
|
||||
|
||||
```text
|
||||
cases/jeecgboot-work-order/ai-dev-assets/
|
||||
```
|
||||
|
||||
## 可沉淀资产
|
||||
|
||||
| 资产类型 | 来源 | 归档价值 |
|
||||
| --- | --- | --- |
|
||||
| 项目源码定位图 | [source-map.md](./source-map.md) | 新人快速理解 JeecgBoot 类项目 |
|
||||
| Prompt 模板 | [prompts.md](./prompts.md)、[ai-dev-assets/prompts/jeecgboot](./ai-dev-assets/prompts/jeecgboot) | 复用读项目、拆需求、Review 的提问方式 |
|
||||
| 课堂工作表 | [worksheets.md](./worksheets.md)、[ai-dev-assets/templates/jeecgboot](./ai-dev-assets/templates/jeecgboot) | 标准化小组交付物 |
|
||||
| 验收清单 | [acceptance-checklist.md](./acceptance-checklist.md)、[ai-dev-assets/checklists/jeecgboot](./ai-dev-assets/checklists/jeecgboot) | 建立统一验收标准 |
|
||||
| 优秀小组案例 | 学员提交结果 | 建立正向样例 |
|
||||
| 问题案例 | [ai-dev-assets/examples/jeecgboot](./ai-dev-assets/examples/jeecgboot) | 建立反例和风险库 |
|
||||
| 讲师经验 | [instructor-guide.md](./instructor-guide.md) | 沉淀授课节奏和常见问题 |
|
||||
|
||||
## 已生成的具体资产
|
||||
|
||||
### 规则文件
|
||||
|
||||
- [global.md](./ai-dev-assets/rules/global.md)
|
||||
- [frontend.md](./ai-dev-assets/rules/frontend.md)
|
||||
- [backend.md](./ai-dev-assets/rules/backend.md)
|
||||
- [security.md](./ai-dev-assets/rules/security.md)
|
||||
- [testing.md](./ai-dev-assets/rules/testing.md)
|
||||
- [delivery.md](./ai-dev-assets/rules/delivery.md)
|
||||
|
||||
### Command 模板
|
||||
|
||||
- [模块结构分析.command.md](./ai-dev-assets/commands/模块结构分析.command.md)
|
||||
- [工单需求拆解.command.md](./ai-dev-assets/commands/工单需求拆解.command.md)
|
||||
- [接口契约生成.command.md](./ai-dev-assets/commands/接口契约生成.command.md)
|
||||
- [代码生成Review.command.md](./ai-dev-assets/commands/代码生成Review.command.md)
|
||||
- [PR说明生成.command.md](./ai-dev-assets/commands/PR说明生成.command.md)
|
||||
|
||||
### Skill 设计卡
|
||||
|
||||
- [JeecgBoot工单模块开发审查.skill.md](./ai-dev-assets/skills/JeecgBoot工单模块开发审查.skill.md)
|
||||
- [generate-project-constraints/SKILL.md](./ai-dev-assets/skills/generate-project-constraints/SKILL.md)
|
||||
- [项目约束提取表.template.md](./ai-dev-assets/skills/generate-project-constraints/assets/项目约束提取表.template.md)
|
||||
- [项目约束验收清单.md](./ai-dev-assets/skills/generate-project-constraints/assets/项目约束验收清单.md)
|
||||
- [项目约束生成.prompt.md](./ai-dev-assets/skills/generate-project-constraints/assets/项目约束生成.prompt.md)
|
||||
- [design-complex-business-module/SKILL.md](./ai-dev-assets/skills/design-complex-business-module/SKILL.md)
|
||||
- [review-business-delivery/SKILL.md](./ai-dev-assets/skills/review-business-delivery/SKILL.md)
|
||||
- [track-review-fix-loop/SKILL.md](./ai-dev-assets/skills/track-review-fix-loop/SKILL.md)
|
||||
|
||||
### 通用模板与检查表
|
||||
|
||||
- [Plan任务模板.md](./ai-dev-assets/templates/Plan任务模板.md)
|
||||
- [AIReview报告模板.md](./ai-dev-assets/templates/AIReview报告模板.md)
|
||||
- [Browser验证报告模板.md](./ai-dev-assets/templates/Browser验证报告模板.md)
|
||||
- [任务成本与能力匹配表.md](./ai-dev-assets/checklists/任务成本与能力匹配表.md)
|
||||
- [Agent分工表.md](./ai-dev-assets/checklists/Agent分工表.md)
|
||||
- [CLI-MCP-Skill封装决策表.md](./ai-dev-assets/checklists/CLI-MCP-Skill封装决策表.md)
|
||||
|
||||
### JeecgBoot 专用 Prompt
|
||||
|
||||
- [RBAC权限矩阵生成.prompt.md](./ai-dev-assets/prompts/jeecgboot/RBAC权限矩阵生成.prompt.md)
|
||||
- [权限控制方案生成.prompt.md](./ai-dev-assets/prompts/jeecgboot/权限控制方案生成.prompt.md)
|
||||
- [状态流转设计.prompt.md](./ai-dev-assets/prompts/jeecgboot/状态流转设计.prompt.md)
|
||||
- [异常态补齐.prompt.md](./ai-dev-assets/prompts/jeecgboot/异常态补齐.prompt.md)
|
||||
- [看板指标设计.prompt.md](./ai-dev-assets/prompts/jeecgboot/看板指标设计.prompt.md)
|
||||
- [看板接口验收.prompt.md](./ai-dev-assets/prompts/jeecgboot/看板接口验收.prompt.md)
|
||||
- [阶段Review.prompt.md](./ai-dev-assets/prompts/jeecgboot/阶段Review.prompt.md)
|
||||
- [修复记录生成.prompt.md](./ai-dev-assets/prompts/jeecgboot/修复记录生成.prompt.md)
|
||||
|
||||
### JeecgBoot 专用模板
|
||||
|
||||
- [RBAC权限矩阵.template.md](./ai-dev-assets/templates/jeecgboot/RBAC权限矩阵.template.md)
|
||||
- [权限控制方案.template.md](./ai-dev-assets/templates/jeecgboot/权限控制方案.template.md)
|
||||
- [状态流转表.template.md](./ai-dev-assets/templates/jeecgboot/状态流转表.template.md)
|
||||
- [审计日志SOP.template.md](./ai-dev-assets/templates/jeecgboot/审计日志SOP.template.md)
|
||||
- [异常态清单.template.md](./ai-dev-assets/templates/jeecgboot/异常态清单.template.md)
|
||||
- [看板指标字典.template.md](./ai-dev-assets/templates/jeecgboot/看板指标字典.template.md)
|
||||
- [看板接口验收记录.template.md](./ai-dev-assets/templates/jeecgboot/看板接口验收记录.template.md)
|
||||
- [阶段Review报告.template.md](./ai-dev-assets/templates/jeecgboot/阶段Review报告.template.md)
|
||||
- [修复记录.template.md](./ai-dev-assets/templates/jeecgboot/修复记录.template.md)
|
||||
|
||||
### JeecgBoot 专用检查清单
|
||||
|
||||
- [权限上线前检查清单.md](./ai-dev-assets/checklists/jeecgboot/权限上线前检查清单.md)
|
||||
- [状态流转检查清单.md](./ai-dev-assets/checklists/jeecgboot/状态流转检查清单.md)
|
||||
- [审计日志检查清单.md](./ai-dev-assets/checklists/jeecgboot/审计日志检查清单.md)
|
||||
- [异常态检查清单.md](./ai-dev-assets/checklists/jeecgboot/异常态检查清单.md)
|
||||
- [看板指标口径检查清单.md](./ai-dev-assets/checklists/jeecgboot/看板指标口径检查清单.md)
|
||||
- [看板接口验收清单.md](./ai-dev-assets/checklists/jeecgboot/看板接口验收清单.md)
|
||||
- [Review修复闭环检查清单.md](./ai-dev-assets/checklists/jeecgboot/Review修复闭环检查清单.md)
|
||||
|
||||
### 可教学反例
|
||||
|
||||
- [好Command与坏Command对照.md](./ai-dev-assets/examples/好Command与坏Command对照.md)
|
||||
- [好Skill与坏Skill对照.md](./ai-dev-assets/examples/好Skill与坏Skill对照.md)
|
||||
- [好Plan与坏Plan对照.md](./ai-dev-assets/examples/好Plan与坏Plan对照.md)
|
||||
- [权限遗漏反例.md](./ai-dev-assets/examples/jeecgboot/权限遗漏反例.md)
|
||||
- [非法状态流转反例.md](./ai-dev-assets/examples/jeecgboot/非法状态流转反例.md)
|
||||
- [审计日志缺失反例.md](./ai-dev-assets/examples/jeecgboot/审计日志缺失反例.md)
|
||||
- [看板指标口径不清反例.md](./ai-dev-assets/examples/jeecgboot/看板指标口径不清反例.md)
|
||||
|
||||
## 目录建议
|
||||
|
||||
团队资产库可以按以下结构归档：
|
||||
|
||||
```text
|
||||
ai-engineering-assets/
|
||||
├── rules/
|
||||
│ └── jeecgboot/
|
||||
├── prompts/
|
||||
│ └── jeecgboot-work-order/
|
||||
├── commands/
|
||||
│ └── jeecgboot/
|
||||
├── skills/
|
||||
│ └── jeecgboot-work-order-review/
|
||||
├── cases/
|
||||
│ └── jeecgboot-work-order/
|
||||
├── sop/
|
||||
│ └── ai-assisted-development/
|
||||
└── reviews/
|
||||
└── examples/
|
||||
```
|
||||
|
||||
## 规则资产
|
||||
|
||||
适合沉淀为 rules 的内容：
|
||||
|
||||
- 修改代码前必须先输出影响范围和验收方式。
|
||||
- JeecgBoot 后端修改必须遵守 `update-begin` / `update-end` 注释规则。
|
||||
- JeecgBoot 前端修改必须复用 `/@/` alias、`defHttp`、Pinia 和已有组件。
|
||||
- 权限相关任务必须覆盖页面级、按钮级、接口级和数据范围。
|
||||
- 状态流转任务必须先提供状态表和非法流转清单。
|
||||
- 审计任务必须记录 actor、action、targetId、oldValue、newValue、source。
|
||||
- 看板任务必须定义指标口径、维度、过滤条件和数据来源。
|
||||
|
||||
## Prompt 资产
|
||||
|
||||
适合归档的 Prompt：
|
||||
|
||||
- 项目理解 Prompt。
|
||||
- 源码定位 Prompt。
|
||||
- 需求拆解 Prompt。
|
||||
- 接口契约 Prompt。
|
||||
- RBAC 权限矩阵 Prompt。
|
||||
- 权限落地检查 Prompt。
|
||||
- 状态机设计 Prompt。
|
||||
- 审计日志 Prompt。
|
||||
- 异常态 Prompt。
|
||||
- 看板指标 Prompt。
|
||||
- 修改计划 Prompt。
|
||||
- Review Prompt。
|
||||
|
||||
归档时建议增加元数据：
|
||||
|
||||
| 字段 | 示例 |
|
||||
| --- | --- |
|
||||
| 名称 | JeecgBoot 工单状态机设计 Prompt |
|
||||
| 适用项目 | JeecgBoot 3.9.x 类后台项目 |
|
||||
| 适用阶段 | 设计阶段 |
|
||||
| 输入材料 | 需求表、权限矩阵、源码依据 |
|
||||
| 输出格式 | 状态流转表、非法流转清单、测试点 |
|
||||
| 维护人 | 课程讲师或项目负责人 |
|
||||
| 更新时间 | 2026-07-01 |
|
||||
|
||||
## Command 与 Skill 资产
|
||||
|
||||
适合沉淀为 Command 的内容：
|
||||
|
||||
- `/jeecgboot-source-map`：根据项目路径输出源码依据表。
|
||||
- `/work-order-rbac-review`：检查权限矩阵是否覆盖页面、按钮、接口和数据范围。
|
||||
- `/work-order-state-review`：检查状态流转表和非法流转清单。
|
||||
- `/work-order-delivery-review`：按验收清单审查小组交付物。
|
||||
|
||||
适合沉淀为 Skill 的内容：
|
||||
|
||||
- 跨项目约束生成 Skill。
|
||||
- 复杂业务模块设计 Skill。
|
||||
- 业务交付 Review Skill。
|
||||
- Review 修复闭环 Skill。
|
||||
- JeecgBoot 工单模块开发审查 Skill。
|
||||
- JeecgBoot 类后台权限落地检查 Skill。
|
||||
- JeecgBoot 代码生成后 Review Skill。
|
||||
|
||||
Skill 应包含：
|
||||
|
||||
- 触发场景。
|
||||
- 必需输入。
|
||||
- 执行步骤。
|
||||
- 输出格式。
|
||||
- 验收标准。
|
||||
- 禁止事项。
|
||||
|
||||
## 案例库资产
|
||||
|
||||
建议沉淀三类案例：
|
||||
|
||||
| 案例类型 | 内容 | 用途 |
|
||||
| --- | --- | --- |
|
||||
| 优秀案例 | 证据充分、设计完整、验收清楚的小组成果 | 作为新人参考 |
|
||||
| 问题案例 | TRAE 幻觉、权限遗漏、状态遗漏、指标不可算 | 作为反例训练 |
|
||||
| 修复案例 | 从问题交付物到合格交付物的修改过程 | 训练 Review 和迭代 |
|
||||
|
||||
每个案例至少保存：
|
||||
|
||||
- 原始任务。
|
||||
- 输入上下文。
|
||||
- TRAE 输出。
|
||||
- 人工修订。
|
||||
- Review 记录。
|
||||
- 最终验收结论。
|
||||
|
||||
## 维护机制
|
||||
|
||||
| 机制 | 建议 |
|
||||
| --- | --- |
|
||||
| 资产负责人 | 每类资产指定一个维护人 |
|
||||
| 更新频率 | 每次培训后更新一次，项目大版本升级后复核一次 |
|
||||
| 废弃规则 | 与当前项目不再匹配的 Prompt 和规则必须标记废弃 |
|
||||
| 评审方式 | 由讲师、项目负责人和一名实际开发者共同评审 |
|
||||
| 版本记录 | 每次更新记录日期、原因和影响范围 |
|
||||
|
||||
## 课后行动清单
|
||||
|
||||
1. 从每组交付物中选 1-2 份优秀样例。
|
||||
2. 从 Review 中提取 3-5 个问题案例。
|
||||
3. 把高频 Prompt 收敛到团队 Prompt 库。
|
||||
4. 把稳定检查动作沉淀为 Command 或 Skill。
|
||||
5. 把项目约束沉淀到团队 rules。
|
||||
6. 约定下一次复核时间和维护人。
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user