@comate/zulu 1.4.0-beta.4 → 1.4.0-beta.6

package/comate-engine/assets/skills/auto-commit/SKILL.md

@@ -5,6 +5,8 @@ user-invocable: false
 metadata:
   enableWhen:
     - isInternal
+  disableWhen:
+    - isZuluCli
 ---
 
 # 智能提交助手

package/comate-engine/assets/skills/auto-commit-sandbox-comate/SKILL.md

@@ -3,7 +3,7 @@ name: auto-commit-sandbox
 description: 当用户完成代码修改、需要提交代码时，必须使用此 skill，而非直接执行 git commit。自动获取 git diff、匹配 iCafe 活跃卡片、生成 commit message，并自动完成绑定卡片和代码提交。
 metadata:
   enableWhen:
-    - isInternal
+    - isInternalZuluCli
 ---
 
 # 智能提交助手（自动版）
@@ -261,4 +261,4 @@ cd /Users/ddz/project && git push origin HEAD:refs/for/feature/login
 | 脚本 | `scripts/git_utils.py` | Git 工具函数 |
 | 参考 | `references/data_structures.md` | 数据结构定义 |
 | 参考 | `references/query_reference.md` | IQL 语法参考 |
-| 参考 | `references/issue_type_mapping.json` | 卡片类型映射 |
+| 参考 | `references/issue_type_mapping.json` | 卡片类型映射 |

package/comate-engine/assets/skills/code-review/SKILL.md

@@ -2,6 +2,7 @@
 name: code-review
 description: >-
   使用此 skill 审查代码变更（git diff、暂存区改动、分支差异或指定 commit），检查 bug、安全风险、性能问题和代码质量。当用户想要审查、检视或检查代码改动时触发——包括"code review"、"review my changes"、"帮我审查代码"、"看看改动有没有问题"、"review HEAD~N"、"check my PR"、"CR"、"帮我过一遍"、"这段改动有没有问题"，或任何在合入/推送前评估代码变更是否正确安全的请求。此 skill 检查 diff 并输出按优先级排序的问题清单与修复建议。
+disable-model-invocation: true
 ---
 
 # Code Review
@@ -20,11 +21,11 @@ description: >-
 
 ## SubAgent 调用规范
 
-本 skill 通过 `delegate_subtask` 工具启动审查 SubAgent。每个 SubAgent 是独立的 Agent 实例，拥有只读工具集，能够自行获取 diff、搜索代码库、读取文件。
+本 skill 通过 `delegate_subagent` 工具启动审查 SubAgent。每个 SubAgent 是独立的 Agent 实例，拥有只读工具集，能够自行获取 diff、搜索代码库、读取文件。
 
 - **agent_type 固定为 `"Explore"`**
 - **query**：只传递路径和范围，**不注入文件原文**——让 SubAgent 自行读取指令文件
-- 深度审查模式下，所有 `delegate_subtask` 调用**必须在同一轮响应中并行发起**，不要串行等待
+- 深度审查模式下，所有 `delegate_subagent` 调用**必须在同一轮响应中并行发起**，不要串行等待
 
 > Query 构建模板和各模式的完整调用示例见 `{SKILL_DIR}/references/dispatch-template.md`。主 Agent 执行 Step 3/4/5 时须读取该文件获取模板。
 
@@ -100,7 +101,7 @@ description: >-
 
 #### 自定义规则探测
 
-检查 `{SKILL_DIR}/references/custom-rules/` 目录：
+检查仓库根目录下 `.comate/custom-rules/` 目录：
 - 如果存在**非模板**的 `.md` 文件（`RULE_TEMPLATE.md` 不算）→ 标记 `HAS_CUSTOM_RULES = true`
 - 如果目录不存在、为空或只有 `RULE_TEMPLATE.md` → 标记 `HAS_CUSTOM_RULES = false`
 
@@ -116,7 +117,7 @@ description: >-
 
 设 `SKILL_DIR` 为本 skill 目录的绝对路径（即 SKILL.md 所在目录）。
 
-按 `{SKILL_DIR}/references/dispatch-template.md` 中对应模式（常规/深度）的模板发起 `delegate_subtask` 调用。若 `HAS_CUSTOM_RULES = true`，在同一轮响应中追加 custom-reviewer 调用。
+按 `{SKILL_DIR}/references/dispatch-template.md` 中对应模式（常规/深度）的模板发起 `delegate_subagent` 调用。若 `HAS_CUSTOM_RULES = true`，在同一轮响应中追加 custom-reviewer 调用。
 
 每个 SubAgent 会自行读取对应的 reviewer 指令和输出格式，自行决定重点关注 diff 的哪些部分。
 
@@ -190,7 +191,7 @@ SubAgent 通过 `SKILL_DIR` 路径自行读取以下文件：
 - `references/dispatch-template.md`：SubAgent 调度模板（主 Agent 读取）
 - `references/report-format.md`：报告输出格式（主 Agent 读取）
 - `references/telemetry.md`：埋点上报逻辑（主 Agent 读取）
-- `references/custom-rules/*.md`：用户自定义审查规则文件（`RULE_TEMPLATE.md` 为模板，不参与扫描）
+- `.comate/custom-rules/*.md`：用户自定义审查规则文件（位于仓库根目录，`RULE_TEMPLATE.md` 为模板，不参与扫描）
 
 ## 备注
 

package/comate-engine/assets/skills/code-review/agents/custom-reviewer.md

@@ -10,11 +10,11 @@
 
 ## 第一步：加载自定义规则文件
 
-读取 `../references/custom-rules/` 目录下的所有 `.md` 文件。
+读取仓库根目录下 `.comate/custom-rules/` 目录中的所有 `.md` 文件。
 
 - 如果该目录不存在或没有任何 `.md` 文件（仅有模板文件 `RULE_TEMPLATE.md` 不算），直接返回：
   ```json
-  {"reviewer": "custom", "summary": "未找到自定义规则文件，跳过扫描。请在 references/custom-rules/ 目录下添加规则文件。", "findings": []}
+  {"reviewer": "custom", "summary": "未找到自定义规则文件，跳过扫描。请在 .comate/custom-rules/ 目录下添加规则文件。", "findings": []}
   ```
 - 如果规则文件中声明了适用语言或适用范围（`applies_to` 字段），只加载与变更文件语言/路径匹配的规则文件，忽略不相关的规则文件
 - 加载所有满足条件的规则文件后，合并全部规则，准备扫描

package/comate-engine/assets/skills/code-review/agents/meta-reviewer.md

@@ -15,7 +15,7 @@
 
 对每个 finding，默认立场是"这条可能是噪音"，要求它自证价值：
 - **问题是否真实存在**？读取对应文件和行号，确认 finding 描述的问题确实存在于代码中。如果无法通过读取代码确认，直接移除
-- **问题是否有实际影响**？即使问题存在，它是否会在真实场景中被触发？纯理论风险、极端边界条件、概率极低的竞态应降级到 P3 或移除
+- **问题是否有实际影响**？即使问题存在，它是否会在真实场景中被触发？纯理论风险、极端边界条件、概率极低的竞态应降级到 P3 或移除。**例外：来源为 `style-reviewer` 的 finding 不适用本项检查——格式问题本身没有运行时后果，问题存在即成立，不以"影响"为移除依据**
 - **严重等级是否合理**？一个 P1 的问题是否真的会在合入后造成显著影响？一个 P3 的问题是否可能比标注的更严重？
 - **建议是否可执行**？"应该优化"这种建议不够具体，需要给出怎么优化
 - **证据是否充分**？复用审查中提到的"已有函数"是否真的存在并且签名兼容？
@@ -80,5 +80,5 @@
 
 - **积极过滤**：对每条 finding 的默认态度是怀疑而非信任。常见的移除理由包括但不限于：代码行在 diff 中不存在或被误读、问题已被上下文代码处理、基于对语言/框架的错误理解、纯理论风险在真实场景中不会触发。如果无法确定是否应该移除，优先用 adjust_severity 降级而非保留原样
 - **不要凭空添加**：missed_findings 必须基于你对 diff 的实际分析，不要为了"找到遗漏"而强行添加
-- **宁缺毋滥**：给用户 3 条高价值 finding 远比 10 条掺杂噪音的 finding 有用。对于无法明确说出"这个问题在什么场景下会造成什么后果"的 finding，果断移除或降级
+- **宁缺毋滥**：给用户 3 条高价值 finding 远比 10 条掺杂噪音的 finding 有用。对于无法明确说出"这个问题在什么场景下会造成什么后果"的 finding，果断移除或降级。**例外：`style-reviewer` 的 finding 不适用"说出后果"的要求——格式类问题天然没有运行时后果，只要格式违规存在于代码中即为有效 finding，不得以此为由移除或降级**
 - **结果自检**：审核完成后回顾整体结果——如果几乎没有移除或调整，考虑是否审核力度不足；如果大面积移除，考虑是否对变更类型的理解有偏差

package/comate-engine/assets/skills/code-review/agents/style-reviewer.md

@@ -2,7 +2,10 @@
 
 ## 核心原则
 
-- **有规则文件时严格按规则扫描**：匹配到支持语言时，只报告规则文件中明确列出的问题
+- **有规则文件时逐条扫描，不得遗漏**：对规则文件中的每一条规则都必须逐一检查，即使某条规则出现频率低也不得跳过
+- **"不确定"只限于具体 case 的判定，不允许用于跳过整条规则**：对于某个代码片段是否触发规则存疑时可不报；但每条规则本身必须被检查到
+- **行长度规则无豁免**：超过规定长度的行（Python/Java/JS ≤120字符，Go ≤160字符）**无论什么情况都必须报告**，包括字符串字面量、URL、注释、import 语句等所有场景，不得以任何理由跳过
+- **输出前必须确认每条规则都被检查**：在输出结果前，强制逐条对照规则清单确认，特别关注容易被忽略的类型（行长度、命名、编程实践等）
 - **无规则文件时基于通用知识审查**：未匹配到支持语言时，基于你对该语言的编码规范知识进行审查，只报有明确代码证据的问题，不报纯风格偏好
 - **来自 [Critical] 标记规则的 finding，必须设置 `locked: true`**，Meta-Review 不得修改其 severity
 - 来自非 [Critical] 规则的 finding 不设 locked（或 `locked: false`）
@@ -24,16 +27,77 @@
 
 ---
 
-## 第二步：审查
+## 第二步：按语言确认扫描范围
 
-### 分支 A：有规则文件（匹配到支持语言）
+加载规则文件后，按下表确认本次需覆盖的规则总数与大类，扫描时必须全部过一遍：
+
+### Java（`.java` 文件）— 共 14 条规则
+
+| 大类 | 规则数 | 规则 ID 与检查项 | 扫描要点 |
+|------|--------|----------------|---------|
+| Import | 2 | JAVA010 未使用 import；JAVA008 禁通配符 import | 检查所有 import 语句，识别通配符 `*` 和未使用的引用 |
+| 命名 | 3 | JAVA028 方法名小驼峰；JAVA029 常量全大写下划线；JAVA032 包名纯小写 | 检查方法名、常量名、package 声明 |
+| 格式 | 5 | JAVA018 单行≤120字符；JAVA003 禁 Tab 缩进；JAVA014 左花括号 K&R；JAVA068 控制语句必须花括号；JAVA020 关键字/运算符周围空格 | JAVA018: 逐行计算；JAVA014: 检查花括号位置；JAVA020: 关注 `if/for/while` 等关键字和运算符 |
+| 结构 | 1 | JAVA013 重载方法必须相邻 | 检查同名方法的定义位置 |
+| 注释 | 1 | JAVA070 类/public字段/public方法注释必须用 Javadoc | 检查类、public 字段、public 方法是否有 `/** */` 格式的注释 |
+| 编程实践 | 2 | JAVA044 equals 防 NPE（字面量放左）；JAVA041 覆写方法必须加 @Override | 检查 `equals` 调用；检查所有覆写方法是否带 `@Override` 注解 |
+
+### Python（`.py` 文件）— 共 8 条规则
+
+| 大类 | 规则数 | 规则 ID 与检查项 | 扫描要点 |
+|------|--------|----------------|---------|
+| 格式 | 4 | PY023 单行≤120字符；PY030 逗号/分号/冒号空格；PY031 二元运算符前后空格；PY032 关键字参数等号不加空格 | PY023: 逐行计算字符数；PY030-PY032: 关注符号和运算符周围的空格 |
+| 文档 | 2 | PY033 module/function/class/method 必须有 docstring（三双引号）；PY034 docstring 须含功能简介、Args、Returns | 检查所有函数、类、方法是否缺少 docstring 或使用单引号 |
+| 编程实践 | 1 | PY018 禁止用 `==`/`!=` 判断 None，应使用 `is`/`is not` | 搜索所有 `== None` 和 `!= None` 的模式 |
+| 命名 | 1 | PY039 类名（含异常类）必须大驼峰 PascalCase | 检查所有 `class` 关键字后的类名 |
+
+### Go（`.go` 文件）— 共 17 条规则
+
+| 大类 | 规则数 | 规则 ID 与检查项 | 扫描要点 |
+|------|--------|----------------|---------|
+| 命名 | 4 | GoRule001 驼峰命名+缩写词全大写；GoRule002 包级 error 变量加 Err/err 前缀；GoRule004 receiver 名称简短且一致；GoRule006 包内类型不以包名为前缀 | 检查变量名、常量名、receiver 名称；检查 package 级别 error 变量命名 |
+| 格式 | 3 | GoRule102 源文件 UTF-8 编码；GoRule103 单行≤160字符；GoRule301 使用 tab 缩进 | GoRule103: 逐行计算字符数；GoRule301: 检查缩进是否为 tab |
+| Import | 3 | GoRule307 import 按标准库→第三方→项目内分三组；GoRule308 禁止点号 import；GoRule309 `_` import 必须加注释说明原因 | 检查 import 语句分组；检查 `.` import 和 `_` import |
+| 错误处理 | 5 | GoRule201 通过 go vet 检查（copy lock/loop closure/lost cancel/struct tag/printf）；GoRule202 if/for 中禁止对 bool 做等值比较；GoRule204 error 必须作最后一个返回值；GoRule205 函数返回的 error 必须处理；GoRule206 包装 error 用 `%w` | 检查所有返回 error 的函数调用是否被处理；检查 bool 类型的等值比较；检查 error 包装格式 |
+| Error String | 1 | GoRule310 error string 首字母不大写，结尾不带标点 | 检查所有 `fmt.Errorf` 和 `errors.New` 的字符串参数 |
+| 编程实践 | 1 | GoRule203 if 块以 return 结尾时删除 else（early return 风格） | 检查 if-else 结构，当 if 块以 return 结尾时应删除 else |
+
+### JavaScript / TypeScript（`.js` `.ts` `.jsx` `.tsx` `.vue` `.css` 等）— 共 35 条规则
 
-对每个变更文件，按照对应语言的规则文件逐条扫描：
+| 子类 | 规则数 | 主要检查项 | 扫描要点 |
+|------|--------|-----------|---------|
+| JS 通用 | 24 | 行尾空白、引号风格（单引号）、分号、行长度≤120、控制语句花括号、尾逗号、禁多余空格、逗号空格、运算符空格、函数括号前空格、注释空格、对象冒号空格、关键字空格、对象花括号不加空格、点号访问、代码块前空格、箭头函数参数括号、每行单语句、严格相等（===）、运算符换行位置、禁混用空格Tab、箭头符号空格、禁混淆箭头函数、parseInt 必须指定基数 | 检查所有字符串引号是否为单引号；逐行计算字符数；检查 `if/for/while` 是否有花括号；检查所有 `==` 应改为 `===`；检查 parseInt 是否有第二个参数 |
+| Vue 专项 | 8 | 每行最多2个属性；HTML闭合括号换行；组件属性 kebab-case；禁未使用 ref；插值花括号内加空格；禁未使用 v-for 变量；禁多模板根元素；button 必须有 type | 检查模板属性数量；检查 ref 变量是否被使用；检查 v-for 变量是否被使用；检查 button 是否有 type 属性 |
+| React 专项 | 1 | JSX 缩进4空格 | 检查 JSX 元素的缩进层级 |
+| San 专项 | 1 | HTML 缩进4空格 | 检查 HTML 标签的缩进层级 |
+| CSS 专项 | 1 | CSS 规则块之间必须有空行 | 检查 CSS 选择器块之间是否有空行 |
 
-1. 精确定位问题行号
-2. 确认问题在源文件中真实存在（源文件复核）
-3. 记录触发的规则名称（包含其标记：[Critical] 或 [high]/[middle]/[low]）
-4. 宁缺毋滥：不确定的不报
+> **注意**：JS 文件只检查 JS 通用规则；`.vue` 文件额外检查 Vue 专项；`.jsx`/`.tsx` 文件额外检查 React 专项；CSS/SCSS 文件检查 CSS 专项。
+
+---
+
+## 第三步：审查
+
+### 分支 A：有规则文件（匹配到支持语言）
+
+**按以下流程逐条过规则，确保不遗漏：**
+
+1. **建立规则清单**：从规则文件中提取所有规则编号（如 Python 的 PY023, PY030-PY034, PY018, PY039），作为本次扫描的 checklist
+2. **显式遍历检查**：对清单中的**每一条规则**，依次执行以下步骤：
+   - 阅读该规则的完整描述（包括豁免场景）
+   - 在变更文件中专门查找该规则对应的代码模式
+   - 对匹配到的每个位置判断是否违规（结合豁免场景）
+   - 如果是违规，精确定位行号并记录
+3. **发现问题时**：
+   - 精确定位问题行号
+   - 确认问题在源文件中真实存在（源文件复核）
+   - 记录触发的规则编号和名称（含标记：[Critical] / [high] / [middle] / [low]）
+4. **边界模糊时**：对某个具体 case 无法判定是否违规，可跳过该 case，但**该规则的其他明确 case 仍需检查**
+5. **输出前的强制自检**：在输出结果前，**必须确认**：
+   - 检查清单中的每条规则都被检查过了
+   - 特别关注容易被忽略的规则类型（如行长度、命名、编程实践等）
+   - 如果发现某条规则未被检查，立即补检
+6. **完成后**：每条规则都必须被检查到，形成完整覆盖
 
 ### 分支 B：无规则文件（未匹配到支持语言）
 
@@ -45,8 +109,6 @@
 
 ## 严重等级参考
 
-规范类问题的 severity 按以下原则分配：
-
 | 规则标记 | 建议 severity | locked |
 |---------|--------------|--------|
 | [Critical] | P0 | `true` |

package/comate-engine/assets/skills/code-review/references/dispatch-template.md

@@ -23,10 +23,10 @@
 
 ## 常规审查模式
 
-发起一个 `delegate_subtask` 调用：
+发起一个 `delegate_subagent` 调用：
 
 ```
-delegate_subtask(
+delegate_subagent(
   agent_type="Explore",
   description="Code review - 综合审查",
   query="""
@@ -50,7 +50,7 @@ delegate_subtask(
 **若 `HAS_CUSTOM_RULES = true`**，在同一轮响应中**并行**追加一个 custom-reviewer 调用：
 
 ```
-delegate_subtask(
+delegate_subagent(
   agent_type="Explore",
   description="Code review - 自定义规则扫描",
   query="你是自定义规则扫描专家。\n1. 读取审查指令：{SKILL_DIR}/agents/custom-reviewer.md\n2. 读取输出格式：{SKILL_DIR}/references/output-schema.md\n3. 执行：{git diff 命令}\n4. 完成审查并返回 JSON"
@@ -61,28 +61,28 @@ delegate_subtask(
 
 ## 深度审查模式
 
-在**同一轮响应**中，并行发起 4 个 `delegate_subtask`。主 Agent **不需要预读**任何 agents/*.md 或 references/*.md 文件，直接按模板构建 query：
+在**同一轮响应**中，并行发起 4 个 `delegate_subagent`。主 Agent **不需要预读**任何 agents/*.md 或 references/*.md 文件，直接按模板构建 query：
 
 ```
-1. delegate_subtask(
+1. delegate_subagent(
      agent_type="Explore",
      description="Code review - 复用审查",
      query="你是代码审查专家，负责复用审查。\n1. 读取审查指令：{SKILL_DIR}/agents/reuse-reviewer.md\n2. 读取输出格式：{SKILL_DIR}/references/output-schema.md\n3. 执行：{git diff 命令}\n4. 完成审查并返回 JSON\n{业务规则摘要}"
    )
 
-2. delegate_subtask(
+2. delegate_subagent(
      agent_type="Explore",
      description="Code review - 风格审查",
      query="你是代码审查专家，负责风格审查。\n1. 读取审查指令：{SKILL_DIR}/agents/style-reviewer.md\n2. 读取输出格式：{SKILL_DIR}/references/output-schema.md\n3. 执行：{git diff 命令}\n4. 完成审查并返回 JSON\n{业务规则摘要}"
    )
 
-3. delegate_subtask(
+3. delegate_subagent(
      agent_type="Explore",
      description="Code review - 可靠性审查",
      query="你是代码审查专家，负责可靠性审查（资源管理、并发安全、接口鉴权）。\n1. 读取审查指令：{SKILL_DIR}/agents/reliability-reviewer.md\n2. 读取输出格式：{SKILL_DIR}/references/output-schema.md\n3. 执行：{git diff 命令}\n4. 完成审查并返回 JSON\n{业务规则摘要}"
    )
 
-4. delegate_subtask(
+4. delegate_subagent(
      agent_type="Explore",
      description="Code review - 正确性审查",
      query="你是代码审查专家，负责正确性审查。\n1. 读取审查指令：{SKILL_DIR}/agents/correctness-reviewer.md\n2. 读取输出格式：{SKILL_DIR}/references/output-schema.md\n3. 执行：{git diff 命令}\n4. 完成审查并返回 JSON\n{业务规则摘要}"
@@ -92,7 +92,7 @@ delegate_subtask(
 **若 `HAS_CUSTOM_RULES = true`**，在上述 4 个调用的**同一轮响应**中追加第 5 个：
 
 ```
-5. delegate_subtask(
+5. delegate_subagent(
      agent_type="Explore",
      description="Code review - 自定义规则扫描",
      query="你是自定义规则扫描专家。\n1. 读取审查指令：{SKILL_DIR}/agents/custom-reviewer.md\n2. 读取输出格式：{SKILL_DIR}/references/output-schema.md\n3. 执行：{git diff 命令}\n4. 完成审查并返回 JSON"
@@ -108,7 +108,7 @@ delegate_subtask(
 当深度审查至少成功返回 2 个维度结果时，发起 Meta-Review：
 
 ```
-delegate_subtask(
+delegate_subagent(
   agent_type="Explore",
   description="Code review - Meta Review",
   query="""
@@ -136,7 +136,7 @@ delegate_subtask(
 
 ## 失败回退
 
-- 某个 `delegate_subtask` 失败或超时：继续合并剩余结果，报告中注明"部分维度降级"
+- 某个 `delegate_subagent` 失败或超时：继续合并剩余结果，报告中注明"部分维度降级"
 - 两个及以上失败：回退为单个综合审查（常规审查模式）
-- `delegate_subtask` 工具不可用：主 Agent 直接执行审查，报告中注明"降级为单 Agent 审查"
+- `delegate_subagent` 工具不可用：主 Agent 直接执行审查，报告中注明"降级为单 Agent 审查"
 - 上下文过大：缩小到高风险文件，必要时拆批执行

package/comate-engine/assets/skills/code-review/references/rules/Java/JAVA_STYLE_RULES.md

@@ -112,8 +112,6 @@ package org.apache.logging.log4j;
 
 **缺陷描述**：单行字符数不超过 120 个字符，超出需要换行。Tab 按 1 个字符计算。
 
-**豁免场景**：package 语句；import 语句；包含 URL 的行；单行字符串字面量。
-
 ---
 
 ### 7. JAVA003 FileTabCharacter - 禁止使用 Tab 字符 [Critical]
@@ -231,7 +229,8 @@ public class Example {
 
 ### 12. JAVA070 CommentsMustBeJavadocInSomeCase - 类/属性/方法注释必须用 Javadoc [Critical]
 
-**缺陷描述**：类、public/protected 字段、public/protected 方法的注释必须使用 `/** 内容 */` 格式，不得使用 `// xxx` 方式。
+**缺陷描述**：所有类声明（含 public 和包级类）、public/protected 字段、public/protected 方法的注释必须使用 `/** 内容 */` 格式，不得使用 `// xxx` 方式。
+
 
 **经典案例**：
 ```java
@@ -239,7 +238,9 @@ public class Example {
 // 用户服务类
 public class UserService {}
 
-// 错误写法
+// 辅助类：缺陷实现
+class DefectExample {}
+
 // 创建订单
 public Order createOrder(OrderDTO dto) {}
 
@@ -247,11 +248,16 @@ public Order createOrder(OrderDTO dto) {}
 /** 用户服务类 */
 public class UserService {}
 
+/** 辅助类：缺陷实现 */
+class DefectExample {}
+
 /** 创建订单 */
 public Order createOrder(OrderDTO dto) {}
 ```
 
-**不应报告的场景**：方法体内部的行间注释；private 成员注释；行尾注释；无注释的类/字段/方法（此规则只检查格式，不检查是否有注释）。
+**不应报告的场景**：分隔线注释（`// ===...===`）；行末尾的 `//` 注释（与代码同行，非独占一行描述用途的注释）。
+
+**核心原则：有 `//` 注释就算，不看内容。**
 
 ---
 

package/comate-engine/assets/skills/code-security/SKILL.md

@@ -1,21 +1,24 @@
 ---
 name: code-security
-description: 代码安全漏洞扫描与修复工具。当用户涉及以下任何场景时，务必使用本 skill：(1) 扫描项目代码中的安全漏洞（SQL注入、XSS、XXE、路径遍历、硬编码凭证等）；(2) 自动修复扫描发现的漏洞；(3) 查看漏洞扫描报告；(4) 对 Java、Go、Python、JavaScript、C/C++ 等语言的项目进行安全检测；(5) 硬编码凭证的修复和托管。即使用户只是提到"代码安全"、"漏洞"、"扫描"、"审计"、"SAST"、"硬编码"、"凭证"等关键词，也应触发本 skill。用户说"检查代码有没有安全问题"或"帮我扫一下代码"时也应触发，不要尝试自行分析代码安全性，而应使用本 skill 的专业扫描服务。
-disable-model-invocation: true
+description: 代码安全漏洞扫描与修复工具。当用户涉及以下任何场景时，务必使用本 skill：(1) 扫描项目代码中的安全漏洞（SQL注入、XSS、XXE、路径遍历、硬编码凭证等）；(2) 自动修复扫描发现的漏洞；(3) 查看漏洞扫描报告；(4) 对 Java、Go、Python、JavaScript、C/C++ 等语言的项目进行安全检测；(5) 硬编码凭证的修复和托管；(6)硬编码风险治理。即使用户只是提到"代码安全"、"漏洞"、"扫描"、"审计"、"SAST"、"硬编码"、"凭证"等关键词，也应触发本 skill。用户说"检查代码有没有安全问题"或"帮我扫一下代码"时也应触发，不要尝试自行分析代码安全性，而应使用本 skill 的专业扫描服务。
 metadata:
   enableWhen:
     - isInternal
-  version: V1.3.0
+  version: V1.4.0
 ---
 
 # Code Security - 代码安全漏洞扫描与修复
 
 ## 概述
 
-本 skill 将用户项目代码上传至安全扫描服务端进行扫描，返回 SARIF 格式漏洞报告，并支持自动修复。当前支持普通漏洞修复，硬编码凭证修复与托管功能暂未开放。
+本 skill 将用户项目代码上传至安全扫描服务端进行扫描，返回 SARIF 格式漏洞报告，并支持自动修复。**当前仅支持普通漏洞修复，硬编码凭证修复与托管功能暂未开放**：扫描结果中如有硬编码漏洞，仅在报告中展示供用户知悉，不进入任何修复或凭证托管流程，也不向用户提供"修复硬编码漏洞"的选项。
 
 所有中间结果文件（`scan_result.json`、`parsed_result.json`、`repair_result.json`）默认保存在 skill 安装目录下的 `.tmp/<项目名>_<哈希>/` 目录中，按项目隔离、不会污染用户项目。脚本标准输出会打印文件绝对路径，使用该路径读取即可。每次执行扫描脚本时，会自动清理超过 24 小时的过期临时数据。
 
+## 文件改动强制约束
+
+**【强制执行】** 当需要改动用户项目中的文件时（包括但不限于漏洞修复、代码替换、凭证替换等所有写文件场景），**必须使用 `edit_file` 工具进行修改**。严禁自行编写脚本（如 sed、awk、python 脚本、shell 重定向等）对代码文件进行批量或单点操作。即使脚本返回了 `diff_content`，也必须由 Agent 逐条调用 `edit_file` 工具完成替换，不得通过自写脚本绕过此约束。
+
 ## 异常处理
 
 当遇到影响流程的致命错误时（如扫描服务不可用、修复接口异常等），向用户提示：
@@ -26,6 +29,37 @@ metadata:
 
 ## 工作流
 
+### 准备工作:环境检测与变量初始化
+
+**【强制执行】** 在执行任何工作流之前，必须先完成环境检测，初始化以下三个统一变量，后续所有脚本命令均使用这些变量。**环境检测命令必须直接执行，无需向用户确认或等待用户点击同意后再执行。**
+
+| 变量 | 说明 |
+|------|------|
+| `_USERNAME` | 当前登录用户名 |
+| `_CHAT_ID` | 当前会话 ID |
+| `_IDE` | IDE 类型 |
+
+检测规则：
+
+```bash
+if [ -n "${COMATE_SESSION_ID}" ]; then
+    # Comate 环境
+    _USERNAME="${COMATE_USERNAME}"
+    _CHAT_ID="${COMATE_SESSION_ID}"
+    _IDE="${COMATE_IDE_NAME:-comate}"
+elif [ -n "${BAIDU_CC_USERNAME}" ]; then
+    # DUCC 环境
+    _USERNAME="${BAIDU_CC_USERNAME}"
+    _CHAT_ID=$(bash scripts/ducc/get_claude_session_id.sh)
+    _IDE="ducc"
+else
+    echo "错误：无法识别当前环境，COMATE_SESSION_ID 和 BAIDU_CC_USERNAME 均未设置" >&2
+    exit 1
+fi
+```
+
+初始化完成后，后续所有命令中的 `${_USERNAME}`、`${_CHAT_ID}`、`${_IDE}` 均替换为上述值。
+
 ### 漏洞扫描
 
 扫描分为两个阶段执行，确保用户能尽早看到初步结果。
@@ -35,7 +69,7 @@ metadata:
 使用 `--no-wait-ai` 跳过 AI 分析等待，扫描完成后立即返回：
 
 ```bash
-python3 scripts/scan_vulnerability.py --root-path <项目目录> --username ${COMATE_USERNAME} --chat-id ${COMATE_SESSION_ID} --no-wait-ai
+python3 scripts/scan_vulnerability.py --root-path <项目目录> --username ${_USERNAME} --chat-id ${_CHAT_ID} --no-wait-ai
 ```
 
 `<项目目录>` 是指用户项目的根目录（即待扫描代码所在目录），而非 skill 安装目录。`--chat-id` 用于关联扫描任务与当前对话。
@@ -52,7 +86,7 @@ python3 scripts/scan_vulnerability.py --root-path <项目目录> --username ${CO
 1. **必须立即执行数据上报**（参数说明见「数据上报」章节）：
 
 ```bash
-python3 scripts/report_chat.py --username ${COMATE_USERNAME} --chat-id ${COMATE_SESSION_ID} --scan-result <scan_result.json路径> --root-path <项目目录> --ide ${COMATE_IDE_NAME} --query <用户输入>
+python3 scripts/report_chat.py --username ${_USERNAME} --chat-id ${_CHAT_ID} --scan-result <scan_result.json路径> --root-path <项目目录> --ide ${_IDE} --query <用户输入>
 ```
 
 扫描失败时不执行数据上报，直接向用户展示错误信息。
@@ -65,21 +99,52 @@ python3 scripts/report_chat.py --username ${COMATE_USERNAME} --chat-id ${COMATE_
 当有漏洞仍在 AI 分析中时，执行此阶段等待分析完成：
 
 ```bash
-python3 scripts/scan_vulnerability.py --root-path <项目目录> --username ${COMATE_USERNAME} --chat-id ${COMATE_SESSION_ID} --wait-ai-only --scan-result <scan_result.json路径>
+python3 scripts/scan_vulnerability.py --root-path <项目目录> --username ${_USERNAME} --chat-id ${_CHAT_ID} --wait-ai-only --scan-result <scan_result.json路径>
 ```
 
-脚本会轮询等待所有漏洞的 AI 分析完成（超时 20 分钟），然后**原地更新** `scan_result.json`。如果超时仍有漏洞未完成分析（`aiAnalysisStatus` 仍为 1），这些漏洞会被忽略，不进入修复流程。
+脚本会轮询等待所有漏洞的 AI 分析完成（超时 20 分钟），然后**原地更新** `scan_result.json`。如果超时仍有漏洞未完成分析（`aiAnalysisStatus` 仍为 1），会进入「本地兜底分析」阶段，由 Agent 根据语言对应的本地分析文档判定误报，避免直接被忽略导致漏修。
 
 AI 分析完成或超时后：
-1. 重新执行解析脚本，**将标准输出原样展示给用户**（此时误报漏洞已被过滤）
-2. 根据最新的 `parsed_result.json` 进入修复流程
+1. 重新执行解析脚本，**将标准输出原样展示给用户**（此时已完成分析的误报漏洞已被过滤）
+2. 检查最新的 `parsed_result.json`：如果 `analyzing_count > 0`，进入「本地兜底分析」阶段；否则进入「漏洞解析与展示」章节的用户选择流程
 
 **AI 误报分析状态说明**：
 - `aiAnalysisStatus=0`：无需分析
-- `aiAnalysisStatus=1`：分析中（不进入修复流程，超时后直接忽略）
+- `aiAnalysisStatus=1`：分析中（超时后进入本地兜底分析）
 - `aiAnalysisStatus=2`：真实漏洞（需要修复）
 - `aiAnalysisStatus=3`：误报（自动跳过，不进入修复流程）
 
+#### 本地兜底分析（AI 分析超时漏洞）
+
+当 `parsed_result.json` 的 `analyzing_count > 0`（即有漏洞 AI 分析超时未完成）时，由 Agent 参考本地分析文档对这些漏洞逐条判定误报，**仅对普通漏洞执行**。
+
+**适用范围（严格遵守）**：
+- ✅ 仅对 `analyzing_vuls` 中的**普通漏洞**（即非 SCA、非硬编码）进行本地兜底分析
+- ❌ **SCA 漏洞**（漏洞条目 `importPath` 字段非空）：跳过分析，直接按真实漏洞处理（进入 SCA 本地修复流程）
+- ❌ **硬编码漏洞**（`ruleID` 含 `sensitive`）：跳过分析，由于硬编码修复流程当前未开放，直接在报告中展示，不做任何修复
+
+**兜底分析步骤**：
+
+1. 从 `parsed_result.json` 的 `analyzing_vuls` 中筛选出待分析的普通漏洞（按上述适用范围排除 SCA / 硬编码）
+2. 对每条漏洞，根据其 `ruleID` 在下表中查找对应的本地分析文档：
+
+   **ruleID 与分析参考文档映射表**：
+
+   | ruleID 关键词 | 分析文档 |
+   |--------------|---------|
+   | `java_sqli`、`java_sql_injection` | [references/vul_analysis-java_sql_injection.md](references/vul_analysis-java_sql_injection.md) |
+   | `go_sqli`、`go_sql_injection` | [references/vul_analysis-go_sql_injection.md](references/vul_analysis-go_sql_injection.md) |
+   | `php_sqli`、`php_sql_injection` | [references/vul_analysis-php_sql_injection.md](references/vul_analysis-php_sql_injection.md) |
+   | `python_sqli`、`python_sql_injection` | [references/vul_analysis-python_sql_injection.md](references/vul_analysis-python_sql_injection.md) |
+
+   匹配规则：ruleID 中包含表中任一关键词即命中（不区分大小写）。如果未匹配到任何分析文档，按真实漏洞处理（保守策略）进入修复流程。
+
+3. 读取分析文档后严格按其流程对每条漏洞进行复核，输出 `analyze_report.json`（与 `parsed_result.json` 同目录），格式见各分析文档的「结果输出」章节。
+4. 根据 `analyze_report.json` 处理：
+   - `result=false_positive` 的漏洞：**跳过**，不进入修复流程，并在最终展示给用户的报告中标注"经本地兜底分析判定为误报"
+   - `result=true_positive` 的漏洞：与 `aiAnalysisStatus=2` 的真实漏洞合并，进入修复流程
+5. 重新计算修复列表后，统一进入「漏洞解析与展示」章节的用户选择流程（不要直接跳到修复）。展示时需明确告知用户："X 个漏洞 AI 分析超时，已通过本地兜底分析复核，其中 Y 个判定为误报、Z 个判定为真实漏洞"。
+
 ### 漏洞解析与展示
 
 扫描完成后，执行解析脚本对结果进行分类和格式化展示：
@@ -90,48 +155,54 @@ python3 scripts/parse_scan_result.py --scan-result <scan_result.json路径> --pr
 
 脚本功能：
 1. 解析 SARIF 格式扫描结果，自动按 ruleID 是否包含 `sensitive` 分类为普通漏洞和硬编码漏洞
-2. **排除过滤**：`aiAnalysisStatus=3`（误报）和 `aiAnalysisStatus=1`（分析中/超时）的漏洞会被单独归类，不进入修复流程
+2. **状态归类**：`aiAnalysisStatus=3`（误报）和 `aiAnalysisStatus=1`（分析中/超时）的漏洞会被单独归类。误报永远不进入修复流程；分析中漏洞需先经「本地兜底分析」复核，被判定为真实漏洞的会被合并回修复列表
 3. 标准输出打印 Markdown 格式漏洞报告，包含漏洞名称、描述、位置链接、等级、数据流、修复建议。如果有漏洞仍在 AI 分析中，报告会自动提示
 4. 在输出目录生成 `parsed_result.json`（路径打印到 stderr），包含结构化漏洞数据供后续修复使用。其中 `analyzing_count` 字段表示仍在 AI 分析中的漏洞数量
 
 **展示要求（严格遵守）**：脚本标准输出的内容是已经格式化好的 Markdown 漏洞报告，**必须将标准输出内容原样展示给用户，禁止总结、改写、精简或重新组织**。不要用自己的话概述漏洞信息，直接复制粘贴脚本的标准输出即可。
 
-然后根据 `parsed_result.json` 中的 `common_count` 进入修复流程：
+**统计数字的权威来源（严格遵守）**：任何涉及“漏洞总数 / 真实漏洞 / 误报数量 / 分析中数量 / 修复率 / 修复前后对比”的表述，**必须**读取 `parsed_result.json` 的 `total`、`common_count`、`sensitive_count`、`false_positive_count`、`analyzing_count` 字段，或使用脚本 stdout/stderr 首行打印的 `STATS: total=… common=… sensitive=… false_positive=… analyzing=…` 作为事实来源。禁止通过数 Markdown 列表条目、或凭印象推断计数。当长报告可能被截断时，`STATS:` 行和 `parsed_result.json` 是唯一可信的数字来源；特别注意“分析中(analyzing)”的漏洞既不是真实漏洞也不是误报，不得在统计中被合并到任意一侧。
+
+**【强制执行】** 展示报告后，必须使用 Questions 组件让用户选择后续操作，不得自动进入修复流程。根据 `parsed_result.json` 中的 `common_count` 提供选项。`common_count` > 0 表示存在普通漏洞。
+
+> 注：硬编码凭证修复与托管功能暂未开放。即使 `sensitive_count > 0`，也**不**向用户提供"修复硬编码漏洞"选项；硬编码漏洞仅在报告中展示供用户知悉，不进入任何修复流程。
 
-- 如果存在普通漏洞（`common_count > 0`），直接进入普通漏洞修复流程
-- 如果没有普通漏洞（包括所有漏洞都是误报的情况），仅展示扫描报告，不进行修复
+选项必须严格按以下格式书写：
 
-<!-- TODO: 后续版本恢复硬编码漏洞修复支持
-- 如果同时存在两种漏洞，给出3个选项让用户选择（使用Questions组件）：
+- 如果存在普通漏洞（`common_count > 0`），提供以下选项：
   1. 修复普通漏洞 - 自动修复 SQL 注入、XXE 等常规漏洞
-  2. 修复硬编码漏洞 - 进入凭证托管流程，将硬编码凭证替换为环境变量
-  3. 仅查看漏洞信息，暂不修复
-- 如果只有普通漏洞，直接进入普通修复流程
-- 如果只有硬编码漏洞，直接进入硬编码修复流程
--->
+  2. 仅查看漏洞信息，暂不修复
+- 如果没有普通漏洞（`common_count == 0`），无论是否存在硬编码漏洞，都直接告知用户当前无可自动修复的漏洞，流程结束
+
+用户必须选择其中一项后才能继续。选择「暂不修复」则流程结束。
 
 ### 普通漏洞修复
 
+**SCA 类漏洞特殊处理**：SCA 漏洞的修复方式是升级依赖版本，与代码改写无关，后端修复接口对其无能为力。判定规则：**漏洞条目 `importPath` 字段非空**。
+
+处理策略统一为：**先由 Agent 在本地参考 [references/vul_repair-sca.md](references/vul_repair-sca.md) 用 `edit_file` 工具修复全部 SCA 漏洞（修改 `pom.xml` / `go.mod` / `requirements.txt` / `package.json` 等依赖声明文件），再调用 `repair_vulnerability.py` 处理剩余的非 SCA 普通漏洞。** 脚本会自动按 `importPath` 过滤掉 SCA 漏洞，不会重复发后端请求；如果 `common_vuls` 全部为 SCA，脚本会直接返回 `status=-3`、`fallback=true`、`sca_only=true`，此时无需再调用脚本，本地修复完成后直接进入复测。
+
 直接传入解析结果文件执行修复：
 
 ```bash
-python3 scripts/repair_vulnerability.py --root-path <项目目录> --username ${COMATE_USERNAME} --chat-id ${COMATE_SESSION_ID} --parsed-result <parsed_result.json路径>
+python3 scripts/repair_vulnerability.py --root-path <项目目录> --username ${_USERNAME} --chat-id ${_CHAT_ID} --parsed-result <parsed_result.json路径>
 ```
 
 脚本自动从 `parsed_result.json` 提取普通漏洞并按文件聚合，然后调用修复接口。
 
 修复逻辑：
-1. 一定要先调用工具脚本进行修复，不要擅自修改其他部分的代码
-2. 结果保存到 skill 临时目录下的 `repair_result.json`，标准输出打印结果文件绝对路径
-3. 执行完成后，使用 Read 工具读取结果文件获取修复结果
-4. **兜底修复**：如果脚本未能返回修复结果（如接口报错、返回空结果）或执行超时（超过 20 分钟），则跳过脚本修复，改为 Agent 参考修复指导手册自行修复。兜底流程：
-   1. 从 `parsed_result.json` 的 `common_vuls` 中获取每个漏洞的 `ruleID`
+1. **优先本地修复 SCA 漏洞**：在调用脚本前，先扫描 `parsed_result.json` 的 `common_vuls`，对所有 `importPath` 字段非空的漏洞，读取 [references/vul_repair-sca.md](references/vul_repair-sca.md) 并使用 `edit_file` 工具完成本地修复。SCA 修复完成后再调用脚本处理剩余漏洞；如果 `common_vuls` 全部是 SCA 漏洞，则跳过脚本调用，直接进入第 8 步复测
+2. 一定要先调用工具脚本进行修复，不要擅自修改其他部分的代码
+3. 结果保存到 skill 临时目录下的 `repair_result.json`，标准输出打印结果文件绝对路径
+4. 执行完成后，读取结果文件获取修复结果
+5. **兜底修复**：如果脚本未能返回修复结果（如接口报错、返回空结果）、执行超时（超过 5 分钟），或返回 `fallback=true`（如 `sca_only=true` 表示全部为 SCA 漏洞），则跳过脚本修复，改为 Agent 参考修复指导手册自行修复。兜底流程：
+   1. 从 `parsed_result.json` 的 `common_vuls` 中获取每个漏洞的 `ruleID`（SCA 漏洞按上述步骤 1 已处理，此处仅处理非 SCA 漏洞）
    2. 根据下方映射表查找对应的修复参考文档，读取该文档获取修复指导
    3. 阅读漏洞所在源文件，结合参考文档中的修复模式和最佳实践，自行完成代码修复
    4. 如果 ruleID 没有匹配的参考文档，则基于漏洞的 `description`、`suggestion` 和 `codeFlows` 信息，运用自身安全知识进行修复
-   5. 修复完成后，继续执行后续的复测扫描流程（步骤 6）
+   5. 修复完成后，继续执行后续的复测扫描流程（步骤 8）
 
-   **ruleID 与修复参考文档映射表**：
+   **ruleID 与修复参考文档映射表**（仅适用于非 SCA 漏洞；SCA 漏洞按 `importPath` 判定，统一使用 `references/vul_repair-sca.md`）：
 
    | ruleID 关键词 | 参考文档 |
    |--------------|---------|
@@ -141,9 +212,9 @@ python3 scripts/repair_vulnerability.py --root-path <项目目录> --username ${
    | `python_sqli`、`python_sql_injection` | [references/vul_repair-python_sql_injection.md](references/vul_repair-python_sql_injection.md) |
 
    匹配规则：ruleID 中包含表中任一关键词即命中（不区分大小写）。后续新增漏洞类型时，在此表中追加对应行并创建 `references/vul_repair-<类型>.md` 文件即可。
-5. 每获取一个文件修复结果，就读取 `diff_content`（JSON 数组，每个元素为 `{from_content, to_content}`），遍历数组逐个执行 `file_content.replace(from_content, to_content)` 替换文件内容，并默认采纳
-6. 如果是调用工具脚本进行修复的，修改完文件后要检查修改部分是否存在编码错误，比如缺失导入的包或组件、语法错误、逻辑错误等，如果存在则自动修复，直到没有编码错误为止
-7. 所有文件修复完成后，自动执行一次复测扫描（流程与「漏洞扫描」章节一致），对比修复前后的漏洞数量，向用户说明修复效果。**复测扫描完成后同样必须执行数据上报**（命令和参数同「漏洞扫描」章节中的上报步骤）。展示格式：
+6. 每获取一个文件修复结果，都必须使用 `edit_file` 工具，依据 `diff_content`（JSON 数组，每个元素为 `{from_content, to_content}`）逐条完成替换。严禁通过自写脚本/sed/awk 等方式批量替换文件内容
+7. 如果是调用工具脚本进行修复的，修改完文件后要检查修改部分是否存在编码错误，比如缺失导入的包或组件、语法错误、逻辑错误等，如果存在则自动修复，直到没有编码错误为止
+8. 所有文件修复完成后，自动执行一次复测扫描（流程与「漏洞扫描」章节一致），对比修复前后的漏洞数量，向用户说明修复效果。**复测扫描完成后同样必须执行数据上报**（命令和参数同「漏洞扫描」章节中的上报步骤）。展示格式：
 
 ```
 修复完成，正在执行复测扫描验证修复效果...
@@ -153,14 +224,12 @@ python3 scripts/repair_vulnerability.py --root-path <项目目录> --username ${
 
 如果复测仍存在未修复的漏洞，展示剩余漏洞列表（格式同漏洞报告），并提示用户可以选择继续修复或忽略。
 
-8. 复测完成后，临时文件无需手动删除。每次执行扫描脚本时会自动清理超过 24 小时的过期临时目录（即 `.tmp/<项目名>_<哈希>/`）。如果同时存在硬编码漏洞且用户后续还需修复，24 小时内的临时数据会保留，等硬编码流程结束后自然过期清理。
-9. 进入单元测试阶段（流程见「单元测试」章节）。
+9. 复测完成后，临时文件无需手动删除。每次执行扫描脚本时会自动清理超过 24 小时的过期临时目录（即 `.tmp/<项目名>_<哈希>/`）。
+10. 进入单元测试阶段（流程见「单元测试」章节）。
 
-<!-- TODO: 后续版本恢复硬编码漏洞修复支持
 ### 硬编码漏洞修复与凭证托管
 
-完整流程见 [references/credential_hosting.md](references/credential_hosting.md)。
--->
+**当前未开放**。扫描结果中的硬编码漏洞（`ruleID` 含 `sensitive` 的条目）仅在报告中展示供用户知悉，不进入任何修复或凭证托管流程，也不向用户提供相关选项。`references/credential_hosting.md`、`references/vul_repair_sensitive.md` 以及 `scripts/credential_*.py` 当前暂不被工作流引用，待后续版本重新开放。
 
 ### 单元测试
 
@@ -189,15 +258,15 @@ python3 scripts/repair_vulnerability.py --root-path <项目目录> --username ${
 每次**扫描成功**后（包括首次扫描和复测扫描），**必须执行数据上报**。扫描失败时不执行数据上报。上报失败不影响主流程，仅在 stderr 输出警告。
 
 ```bash
-python3 scripts/report_chat.py --username ${COMATE_USERNAME} --chat-id ${COMATE_SESSION_ID} --scan-result <扫描结果文件路径> --root-path <项目目录> [--git-url <仓库URL>] [--git-branch <分支>] --ide ${COMATE_IDE_NAME} --query <用户输入>
+python3 scripts/report_chat.py --username ${_USERNAME} --chat-id ${_CHAT_ID} --scan-result <扫描结果文件路径> --root-path <项目目录> [--git-url <仓库URL>] [--git-branch <分支>] --ide ${_IDE} --query <用户输入>
 ```
 
 参数说明：
-- `--chat-id`：使用 `${COMATE_SESSION_ID}` 作为对话唯一标识
+- `--chat-id`：使用 `${_CHAT_ID}` 作为对话唯一标识
 - `--scan-result`：扫描结果 JSON 文件路径（即 `scan_result.json`），脚本自动从中提取漏洞信息
 - `--root-path`：项目根目录，用于计算漏洞文件的哈希值
 - `--git-url` / `--git-branch`：从项目 git 信息获取
-- `--ide`：使用 `${COMATE_IDE_NAME}`
+- `--ide`：使用 `${_IDE}`
 - `--query`：用户发起扫描时的输入文本
 
 上报时机：