@comate/zulu 1.4.0-beta.3 → 1.4.0-beta.5

package/comate-engine/assets/skills/code-review/evals/agents/score-judge.md

@@ -1,168 +0,0 @@
-# Precision Judge
-
-你是一个代码审查评测的判分器。你的任务是判定 code-review skill 的输出是否发现了已知问题。
-
-## 背景
-
-评测流程：
-1. 从 git 历史中取出 commit 的 diff
-2. 样本分两类：
-   - **bug-fix 样本**：从 bug-fix commit 中取出的**反转 diff**（修复后 → 修复前），模拟"有人提交了引入 bug 的代码"
-   - **clean 样本**：从 feature/enhance commit 中取出的正常 diff（修改前 → 修改后）
-3. GT 生成器和 code-review skill 都只看到 diff（不知道样本类型），各自独立产出分析结果
-4. 你需要结合样本类型和 GT，判断 skill 的表现
-
-## 输入
-
-- **样本类型**：`bug-fix` 或 `clean`（来自 candidates.json，不是 GT 生成器标注的）
-- **GT findings**: GT 生成器独立分析产出的 findings（可能为空）
-- **Predicted findings**: skill 在审查报告中实际说了什么
-
-## 维度映射
-
-GT 的 `dimension` 与主 skill 的 `reviewer`/`category` 对应关系如下。判分时用此映射理解 skill 输出的分类含义：
-
-| GT `dimension` | 主 skill `reviewer` | 对应的 `category` 值 |
-|---|---|---|
-| `correctness` | `correctness` | `null-safety`, `type-error`, `data-structure`, `exception-handling`, `variable-param`, `string-format`, `control-flow`, `oop-error`, `framework-bug` |
-| `reliability` | `reliability` | `resource-leak`, `concurrency-race`, `thread-safety`, `db-operation`, `async-issue`, `auth-missing`, `auth-bypass`, `auth-logic-error`, `performance-issue` |
-| `style` | `style` | `code-format`, `naming-convention`, `code-style`, `comment-style`, `vue-style`, `react-style` |
-| `reuse` | `reuse` | `duplicate-function`, `inline-reimplementation`, `similar-pattern` |
-
-**注意**：
-- 判分时**不要因为 dimension/reviewer 不匹配就判定 miss**。GT 的 dimension 和 skill 输出的 reviewer/category 只是辅助信息，最终判分依据仍然是 `expected_review` 与 skill 输出的**语义一致性**。
-- 如果 GT finding 的 `dimension` 为 `efficiency` 或 `quality`（历史数据），将其映射到 `reliability`（performance-issue 等）。
-
-## 判分逻辑
-
-### 对于 bug-fix 样本
-
-bug-fix 样本使用反转 diff，diff 中的 `+` 行是引入 bug 的代码。skill 的任务是发现这些新引入代码中的问题。
-
-#### 情况 A：GT 有 findings
-
-对每个 GT finding，判断 skill 是否命中：
-
-**命中（hit=1）**：skill 的输出和 GT 的 `expected_review` 语义一致，指向同一个底层问题。文件必须匹配，问题的核心相同。
-
-**未命中（hit=0）**：skill 说"审查通过"、发现了完全不同的文件、或发现了 GT 中没有的其他问题。
-
-#### 情况 B：GT 无 findings（bug 过于隐蔽，GT 也未发现）
-
-此情况说明这个 bug 即使在反转 diff 中也很难看出。标记为 `gt_blind=true`。
-- 如果 skill 也没发现：`hit=0`，但 `gt_blind=true`（不计入 Recall 分母，因为 GT 也看不出来）
-- 如果 skill 反而发现了：`hit=1`，`gt_blind=true`（skill 表现超出 GT，是加分项）
-
-### 对于 clean 样本
-
-#### 情况 A：GT 无 findings（GT 也认为 diff 无问题）
-
-**正确（correct=1）**：skill 说"审查通过"或"未发现需要阻断合入的问题"，或只报告了 P3 级别的代码风格建议。
-
-**误报（false_positive=1）**：skill 报告了 P0/P1/P2 级别的问题。
-
-#### 情况 B：GT 有 findings（GT 独立发现了 clean 样本中的问题）
-
-此情况说明这个 feature commit 实际上也存在问题。按 bug-fix 样本的逻辑判分：
-- 如果 skill 的 finding 和 GT 的 finding 语义匹配：`hit=1`（skill 正确发现了问题，不算误报）
-- 如果 skill 的 finding 和 GT 的 finding 不匹配：按正常逻辑判断是命中、未命中还是误报
-
-**关键**：当 GT 在 clean 样本上也发现了问题时，skill 发现同样的问题是正确行为，**绝不能算误报**。
-
-## 输出
-
-仅输出 JSON，不要包含任何其他内容：
-
-### bug-fix 样本（GT 有 findings）
-
-```json
-{
-  "sample_type": "bug-fix",
-  "gt_blind": false,
-  "gt_count": 1,
-  "pred_count": 3,
-  "hits": 1,
-  "false_positives": 2,
-  "correct_negatives": 0,
-  "details": [
-    {
-      "gt_idx": 0,
-      "gt_description": "新引入代码的 bug 描述",
-      "matched_pred": "skill 实际说了什么",
-      "hit": true,
-      "reason": "判定理由"
-    }
-  ]
-}
-```
-
-### bug-fix 样本（GT 也未发现 bug，gt_blind）
-
-```json
-{
-  "sample_type": "bug-fix",
-  "gt_blind": true,
-  "gt_count": 0,
-  "pred_count": 1,
-  "hits": 1,
-  "false_positives": 0,
-  "correct_negatives": 0,
-  "details": [
-    {
-      "gt_idx": null,
-      "gt_description": "GT 未发现问题（bug 过于隐蔽）",
-      "matched_pred": "skill 实际发现的问题",
-      "hit": true,
-      "reason": "skill 在 GT 也看不出的情况下独立发现了 bug，超出 GT 基准"
-    }
-  ]
-}
-```
-
-### clean 样本（GT 无 findings，skill 也无问题）
-
-```json
-{
-  "sample_type": "clean",
-  "gt_blind": false,
-  "gt_count": 0,
-  "pred_count": 0,
-  "hits": 0,
-  "false_positives": 0,
-  "correct_negatives": 1,
-  "details": []
-}
-```
-
-### clean 样本（GT 有 findings，skill 也发现了同样问题）
-
-```json
-{
-  "sample_type": "clean",
-  "gt_blind": false,
-  "gt_count": 1,
-  "pred_count": 1,
-  "hits": 1,
-  "false_positives": 0,
-  "correct_negatives": 0,
-  "details": [
-    {
-      "gt_idx": 0,
-      "gt_description": "GT 在 clean 样本中发现的问题",
-      "matched_pred": "skill 发现的同样问题",
-      "hit": true,
-      "reason": "skill 和 GT 一致发现了 clean 样本中的真实问题，不算误报"
-    }
-  ]
-}
-```
-
-## 规则
-
-1. **重点看 `expected_review`**：这是 GT 中最关键的判分依据。
-2. **宽松但不过度宽松**：skill 的表述不需要和 GT 完全一致，但必须指向同一个底层问题。如果只是"同一个文件的不同问题"，不算命中。
-3. **P3 风格建议不算命中也不算误报**：如果 skill 只报告了命名风格、代码组织等 P3 问题，而 GT 是 P0/P1 的正确性 bug，这算未命中（不是误报）。
-4. **误报只针对 P0-P2 级别**：skill 报告了一个不存在的 P0/P1/P2 问题才算误报。P3 不算。
-5. **保守判定**：如果不确定，判定为 miss（hit=0）。
-6. **尊重 GT 的盲审结果**：GT 生成器不知道样本类型，它的 findings 反映了"仅从 diff 能看出的问题"。当 GT 和 skill 一致发现问题时（即使在 clean 样本上），这是正确行为。
-7. **gt_blind 标记**：当 bug-fix 样本的 GT 为空时，标记 `gt_blind=true`，这些样本在计算 Recall 时需要特殊处理。

package/comate-engine/assets/skills/code-review/evals/references/cli-query-template.md

@@ -1,114 +0,0 @@
-# CLI Query Template (Full Mode)
-
-Full mode 下，每个样本通过独立的 CLI 进程运行完整 code-review skill。本文件定义 CLI 命令模板和 query 模板。
-
-## CLI 命令模板
-
-### zulu
-
-```bash
-zulu run \
-  -l "{LICENSE}" \
-  --activate-skill code-review \
-  --cwd "{REPO}" \
-  --display task \
-  -q "{QUERY}"
-```
-
-### baidu-cc
-
-```bash
-baidu-cc \
-  -p "{QUERY}" \
-  --allowedTools "Bash,Read,Write,Edit,Glob,Grep,Agent" \
-  --cwd "{REPO}"
-```
-
-> `baidu-cc` 走内部认证，不需要 license。`--allowedTools` 确保 CLI 进程拥有完整工具集以支持多 Agent pipeline。
-
-## Query 模板
-
-以下 query 用于每个 CLI 进程的 `-q` / `-p` 参数：
-
-```
-请审查以下代码变更。
-
-## 范围（已确定，跳过 Step 1）
-
-执行以下命令获取待审 diff：
-git diff {DIFF_BASE} {DIFF_TARGET} -- {SOURCE_FILES}
-
-注意：范围已确定，不需要执行 Step 1 的范围检测逻辑。直接使用上述 diff 命令获取变更内容。
-
-## 约束
-
-- 跳过 Step 1（范围检测）：审查范围已由上述 diff 命令确定
-- 跳过 Step 8（用户交互）：不要调用 ask_user_question，完成审查报告后直接结束
-- 输出格式严格按照 Step 6 的报告格式
-
-## 审查要求
-
-- 不要预设代码中存在 bug。diff 可能是 bug 修复、功能新增、重构或其他任何类型的变更
-- 从正确性、可靠性、风格、复用四个维度进行审查
-- 如果代码实现正确且合理，直接说"审查通过"，不要硬凑问题
-- 如果发现问题，按严重等级（P0-P3）分类输出
-
-请从 Step 2 开始执行审查流程。
-```
-
-## 占位符说明
-
-| 占位符 | 来源 | 说明 |
-|--------|------|------|
-| `{REPO}` | 参数 `repo` | 目标 git 仓库绝对路径 |
-| `{LICENSE}` | 参数 `license` | zulu SaaS license key，仅 `cli=zulu` 时需要 |
-| `{DIFF_BASE}` | 根据样本类型决定 | bug-fix 样本：`commit`（反转方向）；clean 样本：`parent_commit`（正常方向） |
-| `{DIFF_TARGET}` | 根据样本类型决定 | bug-fix 样本：`parent_commit`（反转方向）；clean 样本：`commit`（正常方向） |
-| `{SOURCE_FILES}` | `candidates.json` 中的 `source_files` | 空格分隔的源码文件路径列表 |
-| `{QUERY}` | 上方 Query 模板填充后的完整文本 | CLI 的 prompt 参数 |
-
-### Diff 方向规则
-
-| 样本类型 | diff 命令 | 含义 |
-|----------|-----------|------|
-| bug-fix | `git diff {COMMIT} {PARENT_COMMIT} -- {FILES}` | 反转 diff：修复后 → 修复前，模拟"引入 bug 的变更" |
-| clean | `git diff {PARENT_COMMIT} {COMMIT} -- {FILES}` | 正常 diff：修改前 → 修改后，"引入新功能的变更" |
-
-## 设计说明
-
-### 为什么跳过 Step 1
-
-生产环境中 Step 1 通过 `git status` 探测工作区变更来确定审查范围。但 eval 场景下 diff 来自历史 commit 而非工作区，Step 1 的探测逻辑会走到错误分支。因此直接提供 diff 命令，跳过范围检测。
-
-### 为什么跳过 Step 8
-
-Step 8 调用 `ask_user_question` 等待用户选择修复方案。eval 需要全自动运行数十个样本，不能每个都停下来等人交互。
-
-### 为什么反转 bug-fix diff
-
-真实的 code review 场景是审查"有人提交了一段新代码"。如果直接用 bug-fix commit 的 diff（修复前 → 修复后），skill 看到的是"有人在修 bug"，会合理地认为"修复正确，审查通过"。反转后，skill 看到的是"有人提交了引入 bug 的代码"，这才是测试 bug 检测能力的正确方式。Clean 样本本身就是"引入新功能"，不需要反转。
-
-### 信息对称
-
-Query 中**不包含** commit subject 和样本类型（bug-fix / clean），确保 skill 和 GT 生成器在相同信息条件下运行。
-
-## Shell 并发控制模板
-
-主 Agent 根据 `candidates.json` 生成完整脚本。以下是并发控制的关键模式：
-
-```bash
-MAX_PARALLEL=5
-RUNNING=0
-
-for ARGS in "${SAMPLES[@]}"; do
-  run_review $ARGS &
-  RUNNING=$((RUNNING + 1))
-  if [ "$RUNNING" -ge "$MAX_PARALLEL" ]; then
-    wait -n 2>/dev/null || wait  # bash 4.3+ 支持 wait -n，低版本回退到 wait 全部
-    RUNNING=$((RUNNING - 1))
-  fi
-done
-wait
-```
-
-> `wait -n` 在 bash 4.3+ 可用，等待任一后台进程完成。低版本 bash 可用 `wait` 等待全部完成后再启动下一批。

package/comate-engine/assets/skills/code-review/evals/references/gt-schema.md

@@ -1,77 +0,0 @@
-# Semantic Ground Truth Schema
-
-每个被评估的样本对应一个 JSON 文件，存放在 `semantic_gt/` 目录下。
-
-## 文件命名
-
-`<sample_id>.json`，例如 `sample-0001.json`（bug-fix 样本）或 `clean-0001.json`（clean 样本）
-
-## Schema
-
-### 有 findings 的样本
-
-GT 生成器从 diff 中独立判断新引入代码存在问题时产出：
-
-```json
-{
-  "sample_id": "sample-0001",
-  "findings": [
-    {
-      "file": "packages/webview/src/components/Chat.tsx",
-      "line_range": [754, 765],
-      "dimension": "correctness",
-      "severity": "P1",
-      "description": "新引入的 hasAcceptedPath 是模块级单值变量，多文件采纳时只有最后一个被保护",
-      "root_cause": "变量被设计为单值字符串而非 Set，导致跨文件的采纳操作互相覆盖",
-      "expected_review": "新增的 hasAcceptedPath 守卫仅保护单一路径，多文件场景下后续采纳会覆盖先前状态；应改为 Set 或使用 Map 追踪所有已采纳路径"
-    }
-  ]
-}
-```
-
-### 无 findings 的样本
-
-GT 生成器从 diff 中独立判断新引入代码无明显问题时产出：
-
-```json
-{
-  "sample_id": "clean-0001",
-  "findings": []
-}
-```
-
-**注意**：GT 生成器不知道样本的真实类型（bug-fix 或 clean）。因此：
-- bug-fix 样本的 GT **通常**有 findings（反转 diff 中新增的 `+` 行就是有 bug 的代码），但如果 bug 非常隐蔽、仅从 diff 看不出来，GT 也可能为空
-- clean 样本的 GT **通常**为空，但如果 GT 生成器从 diff 中发现了新引入代码的真实问题，也可能有 findings
-
-这是信息对称设计的核心：GT 的质量反映的是"仅从 diff 能看出多少问题"，和 skill 的评判条件完全一致。
-
-## 字段说明
-
-### 顶层字段
-
-| 字段 | 类型 | 必填 | 说明 |
-|------|------|------|------|
-| `sample_id` | string | 是 | 样本 ID，与 candidates.json 中的 id 一致 |
-| `findings` | array | 是 | findings 数组，有问题时至少一条，无问题时为空数组 `[]` |
-
-### Finding 字段
-
-| 字段 | 类型 | 必填 | 说明 |
-|------|------|------|------|
-| `findings[].file` | string | 是 | 相对于仓库根目录的文件路径 |
-| `findings[].line_range` | [int, int] | 是 | 问题所在的代码区域 |
-| `findings[].dimension` | string | 是 | `correctness` / `reliability` / `style` / `reuse`，与主 skill 的四个审查维度对齐 |
-| `findings[].severity` | string | 是 | `P0` / `P1` / `P2` / `P3` |
-| `findings[].description` | string | 是 | 描述**新引入的代码**存在什么问题（diff 中 `+` 行的缺陷） |
-| `findings[].root_cause` | string | 是 | 为什么存在这个问题（深层原因） |
-| `findings[].expected_review` | string | 是 | 一个优秀 reviewer 看到这个 diff 时应该指出什么（判分关键锚点） |
-
-## 核心原则
-
-- **描述新引入代码的问题**：`description` 说"新引入的代码什么地方有问题"（diff 中 `+` 行的缺陷）
-- **expected_review 是判分锚点**：它描述 reviewer 看到这个 diff 时应该说什么，和 skill 的输出最直接可比
-- **一个问题 = 一条 finding**：不要按 diff hunk 展开，按逻辑问题聚合
-- **severity 反映问题严重度**：不是修复的重要性
-- **信息对称**：GT 生成器和 code-review skill 只能看到 diff，不能利用 commit subject、样本类型等额外信息
-- **独立判断**：GT 生成器不知道样本是 bug-fix 还是 clean，必须完全依赖 diff 内容判断

package/comate-engine/assets/skills/code-review/references/custom-rules/RULE_TEMPLATE.md

@@ -1,141 +0,0 @@
-# 自定义规则模板
-
-> **使用说明**
->
-> 1. 复制此文件，重命名为你的规则集名称（如 `MY_PROJECT_RULES.md`、`TEAM_API_RULES.md`）
-> 2. 按照下方格式填写规则内容
-> 3. 将文件放在同一目录（`custom-rules/`）下，审查时会自动加载
-> 4. 本文件（`RULE_TEMPLATE.md`）本身不会被加载为规则
-
----
-
-## 文件头（必填）
-
-```yaml
-# 规则集名称（必填）
-title: 我的项目规则
-
-# 规则集描述（选填）
-description: 针对 XX 项目的业务规范和技术约束
-
-# 适用语言（选填）。留空 = 适用所有语言
-# 可选值: js, ts, go, java, python，逗号分隔
-applies_to: js, ts
-
-# 适用路径（选填）。只扫描匹配路径下的文件，支持通配符
-# 留空 = 不限制路径
-applies_to_path: src/api/**, src/service/**
-```
-
----
-
-## 规则格式说明
-
-每条规则包含以下字段：
-
-| 字段 | 必填 | 说明 |
-|------|------|------|
-| 规则 ID | 是 | 格式建议：`前缀_序号`，如 `PROJ_01` |
-| 规则名称 | 是 | 简短描述，建议 10 字以内 |
-| 等级标记 | 是 | `[Critical]` / `[high]` / `[middle]` / `[low]` |
-| `category` | 否 | 问题分类标识，用于输出的 category 字段；留空则为 `custom-rule` |
-| `检测` | 是 | 描述触发此规则的代码模式，越具体越好 |
-| `排除` | 推荐 | 满足哪些条件时不报告此问题 |
-| `复核` | 选填 | 上报前必须额外确认的条件，避免误报 |
-| 代码示例 | 推荐 | 反例（错误写法）和正例（正确写法） |
-
----
-
-## 规则示例
-
-以下是几条示范规则，覆盖不同等级和场景，请参照格式编写你自己的规则。
-
----
-
-### EXAMPLE_01. 禁止直接操作 DOM 绑定事件 [high]
-- **category**: `framework-misuse`
-- **检测**：在 Vue/React 组件中使用 `document.addEventListener` 或 `element.addEventListener` 绑定事件，而非框架提供的事件机制
-- **排除**：第三方库初始化必须手动绑定；在 `componentWillUnmount` / `onUnmounted` 中已有对应的 `removeEventListener`
-- **复核**：确认组件卸载时未清理事件监听，会导致内存泄漏
-
-```javascript
-// 反例 — 未清理的 DOM 事件
-mounted() {
-  document.addEventListener('keydown', this.handleKey)
-  // 忘记在 beforeUnmount 中移除
-}
-
-// 正例 — 使用框架事件机制
-// <template><div @keydown="handleKey"></div></template>
-
-// 正例 — 如必须手动绑定，记得清理
-mounted() { document.addEventListener('keydown', this.handleKey) }
-beforeUnmount() { document.removeEventListener('keydown', this.handleKey) }
-```
-
----
-
-### EXAMPLE_02. API 接口必须校验返回的分页参数 [middle]
-- **category**: `boundary-condition`
-- **检测**：调用分页接口后直接使用 `data.list` 进行渲染，未检查 `data.total` 或 `data.hasMore` 是否存在
-- **排除**：接口明确文档标注 `list` 永不为 null；接口已有统一的响应拦截器处理
-
-```javascript
-// 反例
-const { list } = await fetchPagedData({ page: 1 })
-this.items = list  // list 为 null 时直接崩溃
-
-// 正例
-const { list = [], total = 0 } = await fetchPagedData({ page: 1 })
-this.items = list
-this.total = total
-```
-
----
-
-### EXAMPLE_03. 禁止在生产代码中使用 console.log [low]
-- **category**: `code-style`
-- **检测**：非测试文件中出现 `console.log(` 调用
-- **排除**：文件路径包含 `test`、`spec`、`__tests__`；注释标注了 `// dev-only`；文件是独立的调试工具脚本
-
----
-
-### EXAMPLE_04. 用户输入必须通过 sanitize 函数处理 [Critical]
-- **category**: `reliability`
-- **检测**：将 `req.body`、`req.query`、`req.params` 中的字段直接拼入 SQL 查询字符串，或直接赋值给 `innerHTML`
-- **排除**：已通过 ORM 参数化查询；已通过 `DOMPurify.sanitize()` 或同等函数处理
-- **复核**：确认数据来源是用户可控的外部输入；确认目标是 SQL 或 HTML 上下文
-
-```javascript
-// 反例 — SQL 注入风险
-const sql = `SELECT * FROM users WHERE name = '${req.query.name}'`
-
-// 反例 — XSS 风险
-element.innerHTML = req.body.content
-
-// 正例
-const sql = 'SELECT * FROM users WHERE name = ?'
-db.query(sql, [req.query.name])
-
-// 正例
-element.innerHTML = DOMPurify.sanitize(req.body.content)
-```
-
----
-
-## 规则编写技巧
-
-**写好「检测」的关键**：
-- 描述具体的代码模式，而非抽象原则。"在 `if` 条件中使用 `=`" 比 "避免赋值运算符" 更好
-- 如果依赖上下文（如"在循环内"、"未 await"），明确说明上下文范围
-- 可以引用具体的函数名、API 名、字段名
-
-**写好「排除」的关键**：
-- 想清楚哪些情况下这个模式是合理的
-- 排除条件越明确，误报越少
-
-**等级选择参考**：
-- `[Critical]`：必报、Meta-Review 不得降级，用于安全漏洞、数据损坏等
-- `[high]`：高概率有实际影响的问题
-- `[middle]`：影响可维护性或稳定性，但不紧急
-- `[low]`：纯规范/偏好类，可忽略