@comate/zulu 1.4.0-beta.5 → 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-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`：用户发起扫描时的输入文本
 
 上报时机：

package/comate-engine/assets/skills/code-security/references/credential_hosting.md

@@ -1,30 +1,77 @@
 # 硬编码漏洞修复与凭证托管
 
-硬编码修复有四个步骤：凭证配置 → 代码修复 → 用户确认 → 凭证托管。
+**【强制执行总则】** 以下步骤必须严格按顺序执行，不得跳过任何步骤，不得调换顺序。每个步骤完成后才能进入下一步。
 
-## 步骤一：打开凭证配置网页
+## 流程概览
 
-输出可点击的链接让用户打开凭证托管助手网页，网页 URL 格式及输出示例如下：
 ```
-请点击以下链接打开凭证托管助手，配置凭证信息：
+步骤一：打开硬编码风险治理网页
+    ↓
+步骤二：等待凭证配置完成（立即执行轮询脚本）
+    ↓
+步骤三：修复硬编码代码（本地修复，按 vul_repair_sensitive.md 规则）
+    ↓
+步骤四：托管凭证（用户选择托管或跳过）
+    ├→ 托管凭证 → 执行托管脚本 → 步骤五
+    └→ 跳过托管 → 步骤五
+    ↓
+步骤五：提交代码并合入
+    ├→ 选择1：代码提交且合入 → 步骤六（清理历史 commit）→ [申请结单?是] → 清理临时文件 → 结束
+    │                                                      └→ [申请结单?否] → 复测扫描 → [申请结单?是] → 清理临时文件 → 结束
+    │                                                                                    └→ [申请结单?否] → 清理临时文件 → 结束
+    ├→ 选择2：未提交合入，复测扫描 → 复测扫描 → [申请结单?是] → 清理临时文件 → 结束
+    │                                           └→ [申请结单?否] → 清理临时文件 → 结束
+    ├→ 选择3：未提交合入，单元测试 → 单元测试 → 复测扫描 → [申请结单?是] → 清理临时文件 → 结束
+    │                                                      └→ [申请结单?否] → 清理临时文件 → 结束
+    └→ 选择4：未提交合入，流程结束 → 清理临时文件 → 结束
+```
+
+---
+
+## 步骤一：打开硬编码风险治理网页
+
+**【强制执行】** 必须根据当前环境执行对应脚本，不得跳过此步骤。
+
+### Comate 环境
+
+脚本会自动构建凭证配置网页 URL，并在 IDE 内嵌浏览器中自动打开：
+
+```bash
+python3 scripts/credential_open_page.py \
+  --chat-id "${_CHAT_ID}" \
+  --username "${_USERNAME}" \
+  --ide-name "${_IDE}" \
+  --project-dir "<项目目录绝对路径>"
+```
 
-[打开凭证托管助手](//command:simpleBrowser.api.open?https%3A%2F%2Fcomate-sec-test.baidu-int.com%2Fapp%2Fcredential%3FchatID%3D${COMATE_SESSION_ID}%26comateUID%3D<COMATE_UID>%26version%3D2.9.1%26repo%3D<REPO>%26ideType%3D${COMATE_IDE_NAME})
+脚本说明：
+- `--project-dir`：当前扫描的项目目录，用于自动从 git remote 获取 `repo` 标识；若无 git 信息则使用目录名
+- 脚本通过 comate-kernel socket 在 IDE 内嵌浏览器中自动打开网页
+- 若 kernel socket 不可用，自动降级为 `--open-url` 触发 `simpleBrowser.api.open`
 
-配置完成后请在网页中点击「生成代码」按钮，我会自动检测到配置完成并继续执行修复。
+### DUCC 环境
+
+`credential_open_page.py` 负责输出可点击链接，`scripts/ducc/open_browser.py` 负责在内嵌浏览器中打开，两者接收相同参数，共用公共模块 `credential_url.py` 构建 URL：
+
+```bash
+# 在内嵌浏览器中打开
+python3 scripts/ducc/open_browser.py \
+  --chat-id "${_CHAT_ID}" \
+  --username "${_USERNAME}" \
+  --ide-name "${_IDE}" \
+  --project-dir "<项目目录绝对路径>"
 ```
 
-其中：
-- `COMATE_UID` 为 `${COMATE_USERNAME}` 的 MD5 字符串的前 12 位，使用 `python3 -c "import hashlib; print(hashlib.md5('${COMATE_USERNAME}'.encode()).hexdigest()[:12])"` 计算
-- `REPO` 是代码库标识，可以从项目目录的 git remote 获取（如 `baidu/scan/cnap-test`），如果没有 git 信息则使用项目目录名
+---
 
-要使用实际构造的字符串来替换上述的 url 参数，url 中的%26不要解码，避免 & 符号影响 markdown 链接。
+**【强制执行】** 无论哪种环境，无论网页是否成功自动打开，都必须将脚本的 stdout 输出（含可点击链接）完整展示在聊天框中，不得省略。
 
 ## 步骤二：等待凭证配置完成
 
-打开网页后，立即执行轮询脚本等待用户配置，使用 `--output` 将结果保存到临时目录：
+**【强制执行】** 必须等到聊天框中已成功输出可点击链接后，才能开始执行以下轮询脚本，不得提前执行、不得跳过、不得等待用户回复后再执行。此步骤是后续修复流程的前置依赖，未执行将导致整个硬编码修复流程中断。
 
 ```bash
-python3 scripts/credential_poll.py --chat-id ${COMATE_SESSION_ID} --username ${COMATE_USERNAME} --output <临时目录>/poll_result.json
+python3 scripts/credential_poll.py --chat-id ${_CHAT_ID} --username ${_USERNAME} --output <临时目录>/poll_result.json
 ```
 
 `<临时目录>` 使用与 `scan_result.json` 同一目录（即 `.tmp/<项目名>_<哈希>/`）。
@@ -35,13 +82,13 @@ python3 scripts/credential_poll.py --chat-id ${COMATE_SESSION_ID} --username ${C
 - `data.credentials`：凭证名值对列表
 - `data.deployment`：托管平台信息（platform、platformName）
 - `data.repo`：代码库语言和框架信息
-- `data.succMsg`：托管成功提示信息
-- `data.errorMsg`：托管失败提示信息
+- `data.succMsg`：配置成功提示信息
+- `data.errorMsg`：配置失败提示信息
 - `chatUUID`：此次会话 ID
 
 ## 步骤三：修复硬编码代码
 
-收到凭证配置数据后，在本地直接修复硬编码漏洞，不调用后端修复服务。修复流程参考 `references/vul_repair_sensitive.md` 文档中的详细说明。
+**【强制执行】** 收到凭证配置数据后，必须在本地直接修复硬编码漏洞，不调用后端修复服务。必须先读取 `references/vul_repair_sensitive.md` 文档中的修复规则再执行修复。
 
 修复输入数据来自 `poll_result.json` 文件（由步骤二保存），其中 `data.files`、`data.repo`、`data.deployment` 包含了修复所需的全部信息。
 
@@ -51,52 +98,167 @@ python3 scripts/credential_poll.py --chat-id ${COMATE_SESSION_ID} --username ${C
 3. 根据每个漏洞的 `extra.secret.credentialName`、`extra.secret.start`、`extra.secret.end` 定位敏感信息并替换为环境变量读取方式
 4. 如果 `data.deployment.platform` 为 4，还需引入 keyless-sdk（参考 `references/vul_repair_sensitive.md` 的「引入SDK」章节）
 
-## 步骤四：凭证托管
+## 步骤四：托管凭证
 
-代码修复完成后，提示用户确认修复结果，然后提供托管选项：
+**【强制执行】** 代码修复完成后，以表格方式总结展示修复变化（文件路径、代码行位置、内容变化），然后必须使用 Questions 组件向用户提供以下选项，等待用户确认后再继续，不得自动跳过：
+
+Questions 组件使用规范：
+- **不得展示「Other」选项**
+- **选项为必选**，用户未做选择时 Continue 按钮不可点击
 
 ```
-代码修复已完成，请 Review 修复后的代码。确认无误后，选择「托管凭证」将凭证托管到平台。
+代码修复已完成，请 Review 修复后的代码。确认无误后，选择后续操作：
 1. 托管凭证 - 将凭证托管到 {platformName} 平台
 2. 跳过托管 - 仅完成代码修复，不托管凭证
 ```
 
-用户选择托管后执行：
+用户必须选择其中一项后才能继续。
+
+**用户选择「托管凭证」时**，执行：
 
 ```bash
-python3 scripts/credential_hosting.py --poll-result <poll_result.json路径> --username ${COMATE_USERNAME}
+python3 scripts/credential_hosting.py --poll-result <poll_result.json路径> --username ${_USERNAME}
 ```
 
 脚本自动从 `poll_result.json` 中提取 `chatUUID`、`deployment.platformName`、`data.credentials`，无需手动传递这些参数。
+托管完成后，从 `poll_result.json` 中读取 `data.succMsg`, 展示给用户:
+```
+{succMsg}
+```
+如果失败，从 `poll_result.json` 中读取 `data.errorMsg`, 展示给用户:
+```
+{errorMsg}
+```
+
+
+**用户选择「跳过托管」时**，直接进入步骤五。
+
+完成步骤四后，进入步骤五。
+
+## 步骤五：提交代码并合入
 
-托管完成后，从 `poll_result.json` 中读取 `data.succMsg` 展示给用户。如果失败，展示 `data.errorMsg`。
+**【强制执行】** 使用 Questions 组件向用户确认代码是否提交并推送合入远程仓库，不得自动跳过：
 
-托管成功后，通过 Questions 组件提示用户进行历史 commit 清理。`succMsg` 中包含清理平台地址，需要从中提取链接并突出展示。提示格式：
+Questions 组件使用规范：
+- **不得展示「Other」选项**
+- **选项为必选**，用户未做选择时 Continue 按钮不可点击
 
 ```
-凭证托管已完成。由于历史 commit 中可能仍残留硬编码凭证，建议立即清理 Git 历史记录，防止凭证泄露。
+请确认代码是否提交并合入，选择后续操作：
+1. 代码提交且合入 - 继续清理历史 git commit 记录
+2. 代码未提交合入 - 进行复测扫描
+3. 代码未提交合入 - 进行单元测试
+4. 代码未提交合入 - 流程结束，后续由用户自行处理
+```
 
-{succMsg}
+根据用户选择执行对应分支：
+
+- **选择 1（代码已合入）**→ 进入步骤六（清理历史 commit），清理完成后进入「复测扫描」→「单元测试」→「清理临时文件」
+- **选择 2（复测扫描）**→ 进入「复测扫描」→「清理临时文件」
+- **选择 3（单元测试）**→ 进入「单元测试」→「复测扫描」→「清理临时文件」
+- **选择 4（流程结束）**→ 进入「清理临时文件」后结束
+
+## 步骤六：清理历史 git commit 记录
+
+**【强制执行】** 仅当用户在步骤五选择「代码已合入」时执行此步骤。
+
+由于历史 commit 中可能仍残留硬编码凭证，需要提示用户清理 Git 历史记录。
+
+`REPO` 从项目目录的 git remote URL 中提取三级路径（格式为 `一级/二级/三级`，如 `baidu/scan/cnap-test`）：
+- SSH 格式（`git@icode.baidu.com:baidu/scan/cnap-test.git`）：取 `:` 后的部分，去掉 `.git` 后缀
+- HTTP 格式（`https://icode.baidu.com/baidu/scan/cnap-test`）：取域名后的路径部分，去掉 `.git` 后缀
+- 若无 git 信息则使用项目目录名；`/` 不需要编码，直接拼接
+
+1. 在聊天框输出可点击链接：
+
+```
+代码已合入，建议立即清理 Git 历史记录，防止历史 commit 中残留的硬编码凭证泄露。
+
+请点击以下链接进入清理平台：[历史 Commit 清理平台](https://commit-clean.baidu-int.com/task?repo=<REPO>)
+```
 
+2. 执行以下命令在外部浏览器中自动打开清理平台：
+
+```bash
+python3 -c "import webbrowser; webbrowser.open('https://commit-clean.baidu-int.com/task?repo=<REPO>')"
+```
+
+3. 通过 Questions 组件让用户确认（**不得展示「Other」选项，选项为必选，未选择时 Continue 按钮不可点击**）：
+
+```
 请确认：
 1. 已完成清理 - 我已清理历史 commit，继续后续流程
 2. 稍后处理 - 跳过清理，继续后续流程
 ```
 
-用户选择后继续执行复测扫描。
+用户选择后，使用 Questions 组件询问是否申请结单（**不得展示「Other」选项，选项为必选**）：
+
+```
+是否申请结单？
+1. 是，立即申请结单
+2. 否，稍后手动处理
+```
+
+根据用户选择：
+- **选择「是，立即申请结单」**→ 执行「申请结单」→ 清理临时文件 → **流程结束，不再执行复测扫描**
+- **选择「否，稍后手动处理」**→ 进入「复测扫描」
+
+## 单元测试
+
+进入单元测试阶段（流程见 SKILL.md「单元测试」章节）。「单元测试」完成后进入「复测扫描」。
 
 ## 复测扫描
 
-托管成功后，自动执行一次复测扫描（流程与「漏洞扫描」章节一致），对比修复前后的硬编码漏洞数量，向用户说明修复效果。复测结果同样需要静默执行数据上报。展示格式：
+**【强制执行】** 必须自动执行一次复测扫描（流程与 SKILL.md「漏洞扫描」章节一致），不得跳过。对比修复前后的硬编码漏洞数量，向用户说明修复效果。复测结果同样必须执行数据上报。展示格式：
 
 ```
-托管完成，正在执行复测扫描验证修复效果...
+正在执行复测扫描验证修复效果...
 
 **复测结果**：修复前共 N 个硬编码漏洞，修复后剩余 M 个，本次修复 X 个漏洞。
 ```
 
 如果复测仍存在未修复的硬编码漏洞，展示剩余漏洞列表（格式同漏洞报告），并提示用户可以选择继续修复或忽略。
 
+复测扫描结束后，使用 Questions 组件询问是否申请结单（**不得展示「Other」选项，选项为必选**）：
+
+```
+是否申请结单？
+1. 是，立即申请结单
+2. 否，稍后手动处理
+```
+
+根据用户选择：
+- **选择「是，立即申请结单」**→ 执行「申请结单」→ 清理临时文件 → **流程结束**
+- **选择「否，稍后手动处理」**→ 进入清理临时文件
+
 ## 清理临时文件
 
-复测完成后，清理临时文件：`python3 -c "import sys; sys.path.insert(0, '<skill安装目录>/scripts'); import utils; utils.safe_rmtree('<临时目录绝对路径>')"` 删除该项目的临时目录（即 `.tmp/<项目名>_<哈希>/` 整个目录）。`safe_rmtree` 会校验路径位于 `.tmp` 下防止误删。然后进入单元测试阶段（流程见「单元测试」章节）。
+所有流程结束后，清理临时文件：`python3 -c "import shutil; shutil.rmtree('<临时目录绝对路径>')"` 删除该项目的临时目录（即 `.tmp/<项目名>_<哈希>/` 整个目录）。
+
+## 申请结单
+
+用户选择「是，立即申请结单」时：
+
+1. 在聊天框输出以下内容，提示用户前往网站申请结单：
+
+```
+请点击以下链接，在工单系统中申请结单：
+
+[申请结单](https://security.baidu.com/ticket/pending/list)
+```
+
+2. 执行以下命令在外部浏览器中自动打开申请结单页面：
+
+```bash
+python3 -c "import webbrowser; webbrowser.open('https://security.baidu.com/ticket/pending/list')"
+```
+
+3. 输出提示：
+
+```
+已为您打开申请结单页面，请在工单列表中找到对应工单并申请结单。流程至此结束。
+```
+
+流程结束。
+
+用户选择「否，稍后手动处理」时，跳过此步骤，继续后续流程。