feat(skills): refresh marketplace release workflows

2026-08-20 10:34:16 +09:30
parent ba107a54a8
commit ad4e2b16a8
25 changed files with 488 additions and 463 deletions
@@ -13,16 +13,17 @@ description: 项目级代码评审检查清单。按项目积累特定检查项

 ## 使用方式

-1. `dev-review` 执行五视角扫描时，自动加载当前项目的检查清单
-2. 扫描完成后，逐条检查清单项
-3. 检查结果附加到 CR 报告的「项目检查清单」章节
+1. `dev-review` 执行五视角扫描时，先读取 `references/general.md`
+2. 如果仓库是 AI-Proj，读取 `references/ai-proj.md`；如果是 Coolbuy PaaS，读取 `references/coolbuy-paas.md`
+3. 扫描完成后，逐条检查适用的清单项
+4. 检查结果附加到 CR 报告的「项目检查清单」章节

 ## 检查清单文件

 ```
-review-checklist-plugin/
-├── skills/SKILL.md          # 本文件
-└── checklists/
+review-checklist/
+├── SKILL.md                 # 本文件
+└── references/
    ├── ai-proj.md           # AI-Proj 项目清单
    ├── coolbuy-paas.md      # 酷采3.0 项目清单
    └── general.md           # 通用清单（所有项目适用）
@@ -32,7 +33,7 @@ review-checklist-plugin/

 当 CR 中发现了一个**项目特有**的问题模式，且未来可能复发时：

-1. 打开对应项目的检查清单文件
+1. 打开 `references/` 中对应项目的检查清单文件
 2. 添加条目，格式：`- [ ] {检查项} — 教训：{来源}`
 3. 标注严重度和适用范围

@@ -0,0 +1,50 @@
+# AI-Proj 代码评审检查清单
+
+## 后端（Go + Gin + GORM）
+
+### 分层架构
+- [ ] Handler 是否直接 import `database/` 包？— 禁止，必须通过 Service 层。教训：架构退化导致循环依赖
+- [ ] 新 Handler 是否在 routes/ 中注册？— 遗漏会导致 404
+- [ ] MCP 专用 endpoint 是否包含 `/mcp/` 前缀？— 教训：缺少前缀导致 MCP bridge 404
+
+### 数据库
+- [ ] 新增 Migration 文件名是否符合 `YYYYMMDDHHMMSS_xxx.up.sql` 格式？
+- [ ] Migration 是否有对应的 `.down.sql`？
+- [ ] GORM 查询是否带 `tenant_id` 过滤？（多租户安全）
+- [ ] 软删除查询是否正确使用 `Unscoped()`？— 误用导致查不到已删除数据或查出已删除数据
+
+### 认证与权限
+- [ ] 新 API 是否配置了 Auth 中间件？— 遗漏导致未授权访问
+- [ ] JWT token 类型是否区分 access/refresh？— 教训：token 混用导致安全漏洞
+- [ ] bcrypt cost 是否使用 12？— 教训：默认 cost 10 导致登录失败
+
+### 租户隔离（多企业安全，源自 REQ-20260711-0004）
+- [ ] 隔离/权限类修复是否枚举了威胁模型的**所有读取面**？— list 枚举 + 单条直读 + 按 ID/pattern 查 + count + 关联子查询。教训：P1 只修 list 面漏了 find_task/get-by-id 直读面，直读即绕过枚举防护，audit 才逮到高危残留
+- [ ] 同一威胁在**镜像面**是否一并处理？— 一个对象类型（task）漏，同类（project/document/manual/history）大概率同漏
+- [ ] MCP 裸 SQL（不走仓储层）是否应用 `ResolveTenantScope` / scope 片段？— SSE 面 list_tasks/list_projects 曾裸 SQL 无企业过滤
+- [ ] context 注入的是**类型化 key**（`EnterpriseIDContextKey{}`）而非字符串 key？— 字符串 key 与 `ResolveTenantScope` 读的类型化 key 不通，静默失效
+- [ ] scope 解析不出 / 依赖为 nil 时是否 **fail-closed**（空哨兵拒绝）而非跳过（退化全量）？
+- [ ] MCP endpoint 参数是否 snake_case + camelCase 双绑？— CLI 发 snake、bridge 发 camel，gin 静默忽略不匹配参数（REQ-20260711-0003）
+
+### Redis
+- [ ] Redis key 是否有 TTL？— 缺少 TTL 导致内存泄露
+- [ ] Redis 不可用时是否降级到数据库？
+
+## 前端（React 18 + Ant Design）
+
+### Modal 安全
+- [ ] `Modal.success/info/warning/error` 之后是否有立即执行的 UI 操作？— 必须放在 `onOk` 回调中。教训：两个 Modal 同时弹出互相遮挡
+
+### 状态管理
+- [ ] React Query 的 queryKey 是否正确包含所有依赖参数？— 缺少导致缓存错误
+- [ ] 列表页分页是否正确重置 page？— 教训：筛选条件变更后 page 未重置导致空页
+
+### 类型安全
+- [ ] 是否有 `any` 类型？— 应使用具体类型
+- [ ] API 响应是否有 TypeScript 接口定义？
+
+## 通用
+
+- [ ] `.env` 等凭据文件是否被意外加入 git？
+- [ ] 是否有硬编码的 URL/IP/端口？— 应使用配置
+- [ ] 错误日志是否包含足够的上下文信息？（user_id, tenant_id, request_id）
@@ -0,0 +1,20 @@
+# Coolbuy PaaS（酷采3.0）代码评审检查清单
+
+## 后端（Go + Gin + MySQL）
+
+### 多租户
+- [ ] 所有查询是否带 `tenant_id` 和 `enterprise_id` 过滤？
+- [ ] 跨租户数据操作是否被阻止？
+
+### 数据迁移
+- [ ] 从酷采2.0迁移的字段映射是否正确？（varchar ID → bigint ID）
+- [ ] 迁移脚本是否处理了酷采2.0 的软删除标记（is_delete → deleted_at）？
+
+## 前端（Vue 3 + Ant Design Vue）
+
+### i18n
+- [ ] 新增文案是否使用 `$t()` 国际化？— 不允许硬编码中文
+- [ ] i18n key 是否在 zh-CN 和 en-US 都有定义？
+
+### 权限
+- [ ] 按钮/菜单是否有权限控制（v-permission 指令）？
@@ -0,0 +1,46 @@
+# 通用代码评审检查清单
+
+每次代码审查都应加载本清单。
+
+适用于所有项目，补充六视角扫描法（五传统视角 + Karpathy Scope 视角）。
+
+## Karpathy 反模式速查（Scope 审计者视角辅助）
+
+基于 [andrej-karpathy-skills](https://github.com/forrestchang/andrej-karpathy-skills) EXAMPLES.md 提炼。
+
+### ❌ 反模式 → ✅ 正确做法
+
+| 场景 | 反模式（LLM 常犯） | 正确做法 |
+|------|-----------------|---------|
+| "做个导出功能" | 静默假设文件格式/字段/分页，直接实现 | 列出3种解读（API/文件/任务队列），问用户选哪种 |
+| "让搜索更快" | 同时加缓存+索引+async，200行 | 列出3种"更快"含义+估算，等确认再做 |
+| "加个折扣计算" | Strategy+Abstract+Enum+DataClass，50行 | `def calc_discount(amount, pct): return amount * pct / 100` |
+| "修保存偏好的bug" | 顺手加 merge/validate/notify/cache | 只改最小范围，加注释"其他特性按需再加" |
+| "修空邮件校验bug" | 顺手加用户名校验+类型注解+docstring | 只改空邮件的那2行 |
+| "加日志到上传函数" | 改引号风格+加类型注解+重构return逻辑 | 只加日志，保持原有代码风格 |
+| "修认证bug" | "我会检查代码并做改进"（无标准） | 先写测试复现bug，再实现修复，再跑测试 |
+| "加限流" | 一次提交Redis+多策略+配置系统+监控 | 分4步，每步独立可验证可部署 |
+
+### 触发关键词（出现时加强 Scope 审计）
+
+`export/导出` `faster/更快` `manage/管理` `notify/通知` `fix/修复` `improve/改进` `refactor/重构` `add/添加`
+
+## API 设计
+- [ ] RESTful 命名是否规范？（复数名词、无动词）
+- [ ] 分页参数是否有默认值和上限？
+- [ ] 响应格式是否统一？（code/message/data）
+
+## 错误处理
+- [ ] 错误是否被正确传播？（不要吞掉错误）
+- [ ] 用户可见的错误消息是否友好？（不暴露技术细节）
+- [ ] 是否有 panic recover 兜底？
+
+## 性能
+- [ ] 列表查询是否有分页？（不允许无限制查询）
+- [ ] N+1 查询问题？（循环内查数据库）
+- [ ] 是否有不必要的全表扫描？（缺少索引）
+
+## 可维护性
+- [ ] 魔法数字是否提取为常量？
+- [ ] 复杂业务逻辑是否有注释说明？
+- [ ] 函数是否过长？（超过 100 行考虑拆分）