@comate/zulu 1.4.1 → 1.4.2

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

@@ -1,10 +1,10 @@
 ---
 name: code-security
-description: 代码安全漏洞扫描与修复工具。当用户涉及以下任何场景时，务必使用本 skill：(1) 扫描项目代码中的安全漏洞（SQL注入、XSS、XXE、路径遍历、硬编码凭证等）；(2) 自动修复扫描发现的漏洞；(3) 查看漏洞扫描报告；(4) 对 Java、Go、Python、JavaScript、C/C++ 等语言的项目进行安全检测；(5) 硬编码凭证的修复和托管；(6)硬编码风险治理。即使用户只是提到"代码安全"、"漏洞"、"扫描"、"审计"、"SAST"、"硬编码"、"凭证"等关键词，也应触发本 skill。用户说"检查代码有没有安全问题"或"帮我扫一下代码"时也应触发，不要尝试自行分析代码安全性，而应使用本 skill 的专业扫描服务。
+description: 代码安全漏洞扫描与修复工具。适用场景：(1) 扫描项目代码中的安全漏洞（SQL注入、XSS、XXE、路径遍历、硬编码凭证等）；(2) 自动修复扫描发现的漏洞；(3) 查看漏洞扫描报告；(4) 对 Java、Go、Python、JavaScript、C/C++ 等语言的项目进行安全检测；(5) 硬编码凭证的修复和托管；(6) 硬编码风险治理（含"治理某某代码库的硬编码风险"、"对某个代码库进行硬编码风险治理"等表述）。触发关键词：代码安全、漏洞扫描、安全扫描、漏洞修复、代码审计、SAST、硬编码、凭证、凭证托管、硬编码风险治理。用户说"检查代码有没有安全问题"或"帮我扫一下代码"时也应触发。不要尝试自行分析代码安全性，必须使用本 skill 的专业扫描服务。
 metadata:
   enableWhen:
     - isInternal
-  version: V1.4.0
+  version: V1.5.0
 ---
 
 # Code Security - 代码安全漏洞扫描与修复
@@ -13,7 +13,9 @@ metadata:
 
 本 skill 将用户项目代码上传至安全扫描服务端进行扫描，返回 SARIF 格式漏洞报告，并支持自动修复。**当前仅支持普通漏洞修复，硬编码凭证修复与托管功能暂未开放**：扫描结果中如有硬编码漏洞，仅在报告中展示供用户知悉，不进入任何修复或凭证托管流程，也不向用户提供"修复硬编码漏洞"的选项。
 
-所有中间结果文件（`scan_result.json`、`parsed_result.json`、`repair_result.json`）默认保存在 skill 安装目录下的 `.tmp/<项目名>_<哈希>/` 目录中，按项目隔离、不会污染用户项目。脚本标准输出会打印文件绝对路径，使用该路径读取即可。每次执行扫描脚本时，会自动清理超过 24 小时的过期临时数据。
+所有中间结果文件（`scan_result.json`、`parsed_result.json`、`repair_result.json`）默认保存在用户临时目录下的 `<_TMP_DIR>/.code-security/<项目名>_<哈希>/` 目录中，按项目隔离、不会污染用户项目。脚本标准输出会打印文件绝对路径，使用该路径读取即可。每次执行扫描脚本时，会自动清理超过 24 小时的过期临时数据。
+
+**【路径说明】** 本 skill 的所有脚本和文档均位于系统注入的 `Base directory for this skill` 目录下（以下简称 `<SKILL_DIR>`）。读取任何文件时（如 `references/credential_hosting.md`、`scripts/xxx.py`）必须使用绝对路径：`<SKILL_DIR>/references/credential_hosting.md`，禁止使用相对路径，否则会因工作目录不同而找不到文件。
 
 ## 文件改动强制约束
 
@@ -27,40 +29,192 @@ metadata:
 代码安全 Skill 执行异常，您可以加群（9540385）寻求帮助。
 ```
 
-## 工作流
+## 环境交互规则（全局适用）
+
+本 skill 在多个步骤中需要用户选择，交互方式按环境区分：
+
+- **Dodo 环境（`_IDE` 为 `DODO`）**：**不使用 AskUserQuestion 组件**，改为在聊天框中直接输出编号列表，用户回复数字编号或选项内容即可继续。收到用户回复后，根据数字或内容匹配对应选项执行。
+
+- **非 Dodo 环境（Comate / DUCC）**：使用 AskUserQuestion 工具让用户选择。
+
+后续步骤中凡涉及「让用户选择」均遵守此规则，不再重复说明。
+
+---
+
+## 流程概览
+
+```
+步骤一：环境检测与变量初始化
+    ↓
+步骤二：代码库获取（仅 Dodo 环境）
+    ↓
+步骤三：漏洞扫描（含两阶段） → 数据上报（子流程）
+    ↓
+步骤四：漏洞解析与展示 → 用户选择修复方向
+    ├→ 修复普通漏洞 → 步骤五A
+    ├→ 修复硬编码漏洞 → 步骤五B
+    └→ 暂不修复 → 流程结束
+
+步骤五A：普通漏洞修复 → 复测扫描（子流程） → 单元测试（子流程） → 流程结束
+步骤五B：硬编码漏洞修复与凭证托管（详见 credential_hosting.md） → 流程结束
+```
+
+---
+
+## 子流程定义
+
+以下子流程在主流程中被多次调用，统一定义一次。
+
+### 子流程：数据上报
+
+每次**扫描成功**后（包括首次扫描和复测扫描），**必须执行数据上报**。扫描失败时不执行数据上报。上报失败不影响主流程，仅在 stderr 输出警告。
+
+```bash
+python3 <SKILL_DIR>/scripts/report_chat.py --username <用户名> --chat-id <会话ID> --scan-result <scan_result.json路径> --root-path <项目目录> [--git-url <仓库URL>] [--git-branch <分支>] --ide <IDE类型> --query <用户输入>
+```
+
+参数说明：
+- `--username`：使用步骤一获取的 `_USERNAME` 值
+- `--chat-id`：使用步骤一获取的 `_CHAT_ID` 值作为对话唯一标识
+- `--scan-result`：扫描结果 JSON 文件路径（即 `scan_result.json`），脚本自动从中提取漏洞信息
+- `--root-path`：项目根目录，用于计算漏洞文件的哈希值
+- `--git-url` / `--git-branch`：从项目 git 信息获取
+- `--ide`：使用步骤一获取的 `_IDE` 值
+- `--query`：用户发起扫描时的输入文本
+
+### 子流程：复测扫描
+
+对修复后的代码重新执行一次完整扫描，验证修复效果。流程与步骤三「漏洞扫描」一致：
+
+1. 执行扫描脚本（同步骤三命令）
+2. 扫描成功后执行「数据上报」子流程
+3. 执行解析脚本获取结果
+4. 对比修复前后漏洞数量，向用户展示：
+
+```
+正在执行复测扫描验证修复效果...
+
+**复测结果**：修复前共 N 个漏洞，修复后剩余 M 个，本次修复 X 个漏洞。
+```
+
+如果复测仍存在未修复的漏洞，展示剩余漏洞列表（格式同漏洞报告），并提示用户可以选择继续修复或忽略。
+
+### 子流程：单元测试
+
+为修改过的文件生成或更新单元测试，验证修复不会破坏原有功能。
+
+1. 收集本次修复涉及的所有文件列表
+2. 检查项目中是否已有对应的测试文件（按项目约定的测试目录和命名规则查找，如 `*Test.java`、`*_test.go`、`test_*.py`、`*.test.js` 等）
+3. 让用户选择：
+
+```
+修复已完成，是否为修改的文件生成单元测试？
+1. 生成单测 - 为修改的文件生成或更新单元测试
+2. 跳过单测 - 不生成单元测试
+```
+
+4. 用户选择生成后，针对每个修改的文件：
+   - 如果已有测试文件：阅读现有测试，补充针对修复点的测试用例（不破坏已有用例）
+   - 如果没有测试文件：按项目测试框架和目录结构创建新测试文件
+5. 测试用例重点覆盖：修复前的漏洞场景应被正确防御（如参数化查询替代拼接、环境变量替代硬编码等）
+6. 生成完成后，尝试运行测试（根据项目构建工具选择命令，如 `mvn test`、`go test`、`pytest`、`npm test` 等），如果运行失败则根据报错修正测试代码，直到测试通过
+
+→ 单元测试完成后，返回调用方继续执行。
+
+---
+
+## 主流程
 
-### 准备工作:环境检测与变量初始化
+### 步骤一：环境检测与变量初始化
 
-**【强制执行】** 在执行任何工作流之前，必须先完成环境检测，初始化以下三个统一变量，后续所有脚本命令均使用这些变量。**环境检测命令必须直接执行，无需向用户确认或等待用户点击同意后再执行。**
+**【强制执行】** 执行任何工作流前必须完成环境检测，初始化三个统一变量。**环境检测命令必须直接执行，无需向用户确认。**
 
 | 变量 | 说明 |
 |------|------|
 | `_USERNAME` | 当前登录用户名 |
 | `_CHAT_ID` | 当前会话 ID |
-| `_IDE` | IDE 类型 |
+| `_IDE` | IDE 类型（`DODO`、`comate`、`ducc`） |
+| `_TMP_DIR` | 临时目录（跨平台临时目录，如 `/tmp`、`/home/work/.tmp`） |
 
-检测规则：
+**【重要】** 每次 Bash 调用是独立进程，shell 变量无法跨调用保持。Agent 需解析脚本输出获取变量值，在后续命令中直接使用这些值。
+
+**实现**：
 
 ```bash
-if [ -n "${COMATE_SESSION_ID}" ]; then
-    # Comate 环境
-    _USERNAME="${COMATE_USERNAME}"
-    _CHAT_ID="${COMATE_SESSION_ID}"
-    _IDE="${COMATE_IDE_NAME:-comate}"
+
+# SKILL_DIR 由系统注入，Agent 执行时替换为实际路径
+SCRIPT_DIR="<SKILL_DIR>/scripts"
+
+# 检测 dodo 环境
+DODO_OUTPUT=$(bash "${SCRIPT_DIR}/dodo/dodo_session.sh" 2>/dev/null || echo "{}")
+
+# 判断环境并提取变量
+if echo "$DODO_OUTPUT" | python3 -c "import sys, json; d=json.load(sys.stdin); sys.exit(0 if d.get('environment') == 'dodo' else 1)" 2>/dev/null; then
+    _USERNAME=$(echo "$DODO_OUTPUT" | python3 -c "import sys, json; print(json.load(sys.stdin).get('username', ''))" 2>/dev/null)
+    _CHAT_ID=$(echo "$DODO_OUTPUT" | python3 -c "import sys, json; print(json.load(sys.stdin).get('chat_id', ''))" 2>/dev/null)
+    _IDE="DODO"
+elif [ -n "${COMATE_SESSION_ID}" ]; then
+    _USERNAME="${COMATE_USERNAME}"; _CHAT_ID="${COMATE_SESSION_ID}"; _IDE="comate"
 elif [ -n "${BAIDU_CC_USERNAME}" ]; then
-    # DUCC 环境
-    _USERNAME="${BAIDU_CC_USERNAME}"
-    _CHAT_ID=$(bash scripts/ducc/get_claude_session_id.sh)
-    _IDE="ducc"
+    _USERNAME="${BAIDU_CC_USERNAME}"; _CHAT_ID=$(bash "${SCRIPT_DIR}/ducc/get_claude_session_id.sh"); _IDE="ducc"
 else
-    echo "错误：无法识别当前环境，COMATE_SESSION_ID 和 BAIDU_CC_USERNAME 均未设置" >&2
-    exit 1
+    echo "错误：无法识别当前环境" >&2; exit 1
 fi
+
+# 获取临时目录（跨平台）
+_TMP_DIR=$(python3 -c "import tempfile; print(tempfile.gettempdir())")
+
+# 输出变量
+echo "_IDE=${_IDE}"; echo "_USERNAME=${_USERNAME}"; echo "_CHAT_ID=${_CHAT_ID}"; echo "_TMP_DIR=${_TMP_DIR}"
 ```
 
-初始化完成后，后续所有命令中的 `${_USERNAME}`、`${_CHAT_ID}`、`${_IDE}` 均替换为上述值。
+**【强制执行 - 唯一初始化原则】** 上述变量在整个 skill 执行周期内**仅初始化一次**，后续所有步骤中**必须**使用此处初始化的值，**严禁在后续任何步骤中重新生成或覆盖这些变量**。
 
-### 漏洞扫描
+→ 完成后进入步骤二。
+
+---
+
+### 步骤二：代码库获取（仅 Dodo 环境）
+
+**【仅当 `_IDE` 为 `DODO` 时才执行本步骤，否则跳过直接进入步骤三】**
+
+**代码库名称获取逻辑：**
+
+1. **从用户唤醒输入中提取代码库名称**：检查用户触发本技能时的输入内容，判断是否包含符合三级目录格式（`一级/二级/三级`，如 `baidu/your-team/your-repo`）的代码库名称。
+   - 如果用户输入中已包含合法的三级目录格式代码库名称，直接使用该名称，跳过下方提示步骤。
+   - 如果用户未提供代码库名称，或提供的名称不符合三级目录格式（如缺少层级、包含非法字符等），则提示用户输入：
+
+```
+请输入要扫描的 iCode 代码库名称（三级目录格式，如 baidu/your-team/your-repo）：
+```
+
+等待用户输入后，校验格式是否为三级目录。若格式不正确，提示用户重新输入，直到获取到合法的三级目录格式名称。
+
+**代码库拉取：**
+
+获取到合法代码库名称后，使用 `knowledge-fetch` skill 拉取代码库：
+
+1. **调用 `skill:knowledge-fetch`**，拉取用户指定的代码库：
+   - 知识源类型：`icode_repo`
+   - `repo`：三级路径（如 `baidu/your-team/your-repo`）
+   - `branch`：`master`
+   - `depth`：`1`（仅最新一次提交，加快拉取速度）
+   - `storage.basePath`：`~/knowledge`
+
+2. **确定扫描目录**：代码库拉取完成后，目标目录为：
+   ```
+   ~/knowledge/icode_repo/<三级路径最后一段代码库名>/
+   ```
+   例如输入 `baidu/your-team/your-repo`，扫描目录为 `~/knowledge/icode_repo/your-repo/`。
+   使用 `ls` 确认目录存在后，将此路径作为后续所有扫描命令的 `<项目目录>`。
+
+3. **代码库有效期**：拉取的代码库文件仅在当前沙箱会话中有效（约 6 小时），无需手动清理。
+
+→ 完成后进入步骤三。
+
+---
+
+### 步骤三：漏洞扫描
 
 扫描分为两个阶段执行，确保用户能尽早看到初步结果。
 
@@ -69,10 +223,10 @@ fi
 使用 `--no-wait-ai` 跳过 AI 分析等待，扫描完成后立即返回：
 
 ```bash
-python3 scripts/scan_vulnerability.py --root-path <项目目录> --username ${_USERNAME} --chat-id ${_CHAT_ID} --no-wait-ai
+python3 <SKILL_DIR>/scripts/scan_vulnerability.py --root-path <项目目录> --username <用户名> --chat-id <会话ID> --no-wait-ai
 ```
 
-`<项目目录>` 是指用户项目的根目录（即待扫描代码所在目录），而非 skill 安装目录。`--chat-id` 用于关联扫描任务与当前对话。
+`<项目目录>` 是指用户项目的根目录（即待扫描代码所在目录），而非 skill 安装目录。`--username` 和 `--chat-id` 使用步骤一获取的值。
 
 扫描流程：
 1. 获取扫描配置（支持的文件类型、超时时间等）
@@ -81,25 +235,17 @@ python3 scripts/scan_vulnerability.py --root-path <项目目录> --username ${_U
 4. 发起扫描并轮询结果
 5. 扫描完成后立即保存结果到 `scan_result.json`（部分漏洞可能仍在 AI 分析中），标准输出打印结果文件绝对路径
 
-扫描完成后的执行步骤：
-
-1. **必须立即执行数据上报**（参数说明见「数据上报」章节）：
-
-```bash
-python3 scripts/report_chat.py --username ${_USERNAME} --chat-id ${_CHAT_ID} --scan-result <scan_result.json路径> --root-path <项目目录> --ide ${_IDE} --query <用户输入>
-```
-
-扫描失败时不执行数据上报，直接向用户展示错误信息。
-
-2. 执行解析脚本，**将标准输出原样展示给用户**（见「漏洞解析与展示」章节）。此时报告会包含 AI 分析中的漏洞提示。
-3. 读取 `parsed_result.json`，检查 `analyzing_count` 字段：如果 `analyzing_count > 0`，进入第二阶段；否则跳过第二阶段，直接进入修复流程。
+扫描完成后：
+1. **执行「数据上报」子流程**（扫描失败时不上报，直接向用户展示错误信息）
+2. 进入步骤四（漏洞解析与展示）
+3. 读取步骤四生成的 `parsed_result.json`，检查 `analyzing_count` 字段：如果 `analyzing_count > 0`，进入第二阶段；否则跳过第二阶段，在步骤四中等待用户选择修复方向
 
 #### 第二阶段：等待 AI 分析
 
 当有漏洞仍在 AI 分析中时，执行此阶段等待分析完成：
 
 ```bash
-python3 scripts/scan_vulnerability.py --root-path <项目目录> --username ${_USERNAME} --chat-id ${_CHAT_ID} --wait-ai-only --scan-result <scan_result.json路径>
+python3 <SKILL_DIR>/scripts/scan_vulnerability.py --root-path <项目目录> --username <用户名> --chat-id <会话ID> --wait-ai-only --scan-result <scan_result.json路径>
 ```
 
 脚本会轮询等待所有漏洞的 AI 分析完成（超时 20 分钟），然后**原地更新** `scan_result.json`。如果超时仍有漏洞未完成分析（`aiAnalysisStatus` 仍为 1），会进入「本地兜底分析」阶段，由 Agent 根据语言对应的本地分析文档判定误报，避免直接被忽略导致漏修。
@@ -108,12 +254,14 @@ AI 分析完成或超时后：
 1. 重新执行解析脚本，**将标准输出原样展示给用户**（此时已完成分析的误报漏洞已被过滤）
 2. 检查最新的 `parsed_result.json`：如果 `analyzing_count > 0`，进入「本地兜底分析」阶段；否则进入「漏洞解析与展示」章节的用户选择流程
 
+
 **AI 误报分析状态说明**：
 - `aiAnalysisStatus=0`：无需分析
 - `aiAnalysisStatus=1`：分析中（超时后进入本地兜底分析）
 - `aiAnalysisStatus=2`：真实漏洞（需要修复）
 - `aiAnalysisStatus=3`：误报（自动跳过，不进入修复流程）
 
+
 #### 本地兜底分析（AI 分析超时漏洞）
 
 当 `parsed_result.json` 的 `analyzing_count > 0`（即有漏洞 AI 分析超时未完成）时，由 Agent 参考本地分析文档对这些漏洞逐条判定误报，**仅对普通漏洞执行**。
@@ -145,12 +293,14 @@ AI 分析完成或超时后：
    - `result=true_positive` 的漏洞：与 `aiAnalysisStatus=2` 的真实漏洞合并，进入修复流程
 5. 重新计算修复列表后，统一进入「漏洞解析与展示」章节的用户选择流程（不要直接跳到修复）。展示时需明确告知用户："X 个漏洞 AI 分析超时，已通过本地兜底分析复核，其中 Y 个判定为误报、Z 个判定为真实漏洞"。
 
-### 漏洞解析与展示
+---
+
+### 步骤四：漏洞解析与展示
 
-扫描完成后，执行解析脚本对结果进行分类和格式化展示：
+执行解析脚本对扫描结果进行分类和格式化展示：
 
 ```bash
-python3 scripts/parse_scan_result.py --scan-result <scan_result.json路径> --project-dir <项目根目录>
+python3 <SKILL_DIR>/scripts/parse_scan_result.py --scan-result <scan_result.json路径> --project-dir <项目根目录>
 ```
 
 脚本功能：
@@ -160,23 +310,43 @@ python3 scripts/parse_scan_result.py --scan-result <scan_result.json路径> --pr
 4. 在输出目录生成 `parsed_result.json`（路径打印到 stderr），包含结构化漏洞数据供后续修复使用。其中 `analyzing_count` 字段表示仍在 AI 分析中的漏洞数量
 
 **展示要求（严格遵守）**：脚本标准输出的内容是已经格式化好的 Markdown 漏洞报告，**必须将标准输出内容原样展示给用户，禁止总结、改写、精简或重新组织**。不要用自己的话概述漏洞信息，直接复制粘贴脚本的标准输出即可。
-
 **统计数字的权威来源（严格遵守）**：任何涉及“漏洞总数 / 真实漏洞 / 误报数量 / 分析中数量 / 修复率 / 修复前后对比”的表述，**必须**读取 `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`），提供以下选项：
+1. 修复硬编码漏洞 - 进入凭证托管流程，将硬编码凭证替换为环境变量
+2. 仅查看漏洞信息，暂不修复
+
+如果没有发现硬编码漏洞：直接告知用户扫描结果无硬编码风险漏洞 → **流程结束**
+
+#### 常规模式（非精确唤醒）
+
+根据 `parsed_result.json` 中的 `common_count` 和 `sensitive_count` 提供不同选项：
+
+- 如果同时存在两种漏洞（`common_count > 0` 且 `sensitive_count > 0`）：
   1. 修复普通漏洞 - 自动修复 SQL 注入、XXE 等常规漏洞
+  2. 修复硬编码漏洞 - 进入凭证托管流程，将硬编码凭证替换为环境变量
+  3. 仅查看漏洞信息，暂不修复
+- 如果只有普通漏洞（`common_count > 0`）：
+  1. 修复普通漏洞 - 自动修复 SQL 注入、XXE 等常规漏洞
+  2. 仅查看漏洞信息，暂不修复
+- 如果只有硬编码漏洞（`sensitive_count > 0`）：
+  1. 修复硬编码漏洞 - 进入凭证托管流程，将硬编码凭证替换为环境变量
   2. 仅查看漏洞信息，暂不修复
-- 如果没有普通漏洞（`common_count == 0`），无论是否存在硬编码漏洞，都直接告知用户当前无可自动修复的漏洞，流程结束
+- 如果没有发现漏洞：直接告知用户扫描结果无漏洞 → **流程结束**
+
+用户选择后的去向：
+- 选择「修复普通漏洞」→ 进入**步骤五A**
+- 选择「修复硬编码漏洞」→ 进入**步骤五B**
+- 选择「暂不修复」→ **流程结束**
 
-用户必须选择其中一项后才能继续。选择「暂不修复」则流程结束。
+---
 
-### 普通漏洞修复
+### 步骤五A：普通漏洞修复
 
 **SCA 类漏洞特殊处理**：SCA 漏洞的修复方式是升级依赖版本，与代码改写无关，后端修复接口对其无能为力。判定规则：**漏洞条目 `importPath` 字段非空**。
 
@@ -185,7 +355,7 @@ python3 scripts/parse_scan_result.py --scan-result <scan_result.json路径> --pr
 直接传入解析结果文件执行修复：
 
 ```bash
-python3 scripts/repair_vulnerability.py --root-path <项目目录> --username ${_USERNAME} --chat-id ${_CHAT_ID} --parsed-result <parsed_result.json路径>
+python3 <SKILL_DIR>/scripts/repair_vulnerability.py --root-path <项目目录> --username <用户名> --chat-id <会话ID> --parsed-result <parsed_result.json路径>
 ```
 
 脚本自动从 `parsed_result.json` 提取普通漏洞并按文件聚合，然后调用修复接口。
@@ -202,16 +372,18 @@ python3 scripts/repair_vulnerability.py --root-path <项目目录> --username ${
    4. 如果 ruleID 没有匹配的参考文档，则基于漏洞的 `description`、`suggestion` 和 `codeFlows` 信息，运用自身安全知识进行修复
    5. 修复完成后，继续执行后续的复测扫描流程（步骤 8）
 
+
    **ruleID 与修复参考文档映射表**（仅适用于非 SCA 漏洞；SCA 漏洞按 `importPath` 判定，统一使用 `references/vul_repair-sca.md`）：
 
    | ruleID 关键词 | 参考文档 |
    |--------------|---------|
-   | `java_sqli`、`java_sql_injection` | [references/vul_repair-java_sql_injection.md](references/vul_repair-java_sql_injection.md) |
-   | `go_sqli`、`go_sql_injection` | [references/vul_repair-go_sql_injection.md](references/vul_repair-go_sql_injection.md) |
-   | `php_sqli`、`php_sql_injection` | [references/vul_repair-php_sql_injection.md](references/vul_repair-php_sql_injection.md) |
-   | `python_sqli`、`python_sql_injection` | [references/vul_repair-python_sql_injection.md](references/vul_repair-python_sql_injection.md) |
+   | `java_sqli`、`java_sql_injection` | [<SKILL_DIR>/references/vul_repair-java_sql_injection.md](<SKILL_DIR>/references/vul_repair-java_sql_injection.md) |
+   | `go_sqli`、`go_sql_injection` | [<SKILL_DIR>/references/vul_repair-go_sql_injection.md](<SKILL_DIR>/references/vul_repair-go_sql_injection.md) |
+   | `php_sqli`、`php_sql_injection` | [<SKILL_DIR>/references/vul_repair-php_sql_injection.md](<SKILL_DIR>/references/vul_repair-php_sql_injection.md) |
+   | `python_sqli`、`python_sql_injection` | [<SKILL_DIR>/references/vul_repair-python_sql_injection.md](<SKILL_DIR>/references/vul_repair-python_sql_injection.md) |
+
+   匹配规则：ruleID 中包含表中任一关键词即命中（不区分大小写）。后续新增漏洞类型时，在此表中追加对应行并创建 `<SKILL_DIR>/references/vul_repair-<类型>.md` 文件即可。
 
-   匹配规则：ruleID 中包含表中任一关键词即命中（不区分大小写）。后续新增漏洞类型时，在此表中追加对应行并创建 `references/vul_repair-<类型>.md` 文件即可。
 6. 每获取一个文件修复结果，都必须使用 `edit_file` 工具，依据 `diff_content`（JSON 数组，每个元素为 `{from_content, to_content}`）逐条完成替换。严禁通过自写脚本/sed/awk 等方式批量替换文件内容
 7. 如果是调用工具脚本进行修复的，修改完文件后要检查修改部分是否存在编码错误，比如缺失导入的包或组件、语法错误、逻辑错误等，如果存在则自动修复，直到没有编码错误为止
 8. 所有文件修复完成后，自动执行一次复测扫描（流程与「漏洞扫描」章节一致），对比修复前后的漏洞数量，向用户说明修复效果。**复测扫描完成后同样必须执行数据上报**（命令和参数同「漏洞扫描」章节中的上报步骤）。展示格式：
@@ -222,16 +394,34 @@ python3 scripts/repair_vulnerability.py --root-path <项目目录> --username ${
 **复测结果**：修复前共 N 个普通漏洞，修复后剩余 M 个，本次修复 X 个漏洞。
 ```
 
-如果复测仍存在未修复的漏洞，展示剩余漏洞列表（格式同漏洞报告），并提示用户可以选择继续修复或忽略。
+8. 复测完成后，临时文件无需手动删除（每次扫描脚本会自动清理超过 24 小时的过期临时目录）
+9. 执行「单元测试」子流程
+
 
 9. 复测完成后，临时文件无需手动删除。每次执行扫描脚本时会自动清理超过 24 小时的过期临时目录（即 `.tmp/<项目名>_<哈希>/`）。
 10. 进入单元测试阶段（流程见「单元测试」章节）。
 
-### 硬编码漏洞修复与凭证托管
 
-**当前未开放**。扫描结果中的硬编码漏洞（`ruleID` 含 `sensitive` 的条目）仅在报告中展示供用户知悉，不进入任何修复或凭证托管流程，也不向用户提供相关选项。`references/credential_hosting.md`、`references/vul_repair_sensitive.md` 以及 `scripts/credential_*.py` 当前暂不被工作流引用，待后续版本重新开放。
+---
+
+
+### 步骤五B：硬编码漏洞修复与凭证托管
+
+**【强制执行】** 当用户选择修复硬编码漏洞时，必须先读取 `<SKILL_DIR>/references/credential_hosting.md`，然后严格按照文档中的步骤顺序执行，不得跳过任何步骤、不得调换顺序、不得自行替代任何步骤的实现方式：
+
+1. **步骤一：打开硬编码风险治理网页** — 所有环境均须将脚本标准输出的可点击链接作为回复正文输出到聊天框，输出完成后立即进入步骤二
+2. **步骤二：等待凭证配置完成** — 执行轮询脚本，等待用户在网页完成配置
+3. **步骤三：修复硬编码代码** — 必须读取 `<SKILL_DIR>/references/vul_repair_sensitive.md` 按规则修复
+4. **步骤四：托管凭证** — 必须让用户选择托管或跳过，不得自动决定
+5. **步骤五：确认代码是否提交并合入** — 必须让用户选择后续分支（清理 commit / 复测扫描 / 单元测试 / 流程结束）
+6. **步骤六：清理历史 git commit 记录** — 仅当用户确认代码已合入时执行
+
+后续还包括：复测扫描 → 清理临时文件（选择3时还包含单元测试，具体分支逻辑见文档中的流程概览图）。
+
+每个步骤的详细说明和脚本命令见 `<SKILL_DIR>/references/credential_hosting.md`。
+
+→ 所有分支最终进入「清理临时文件」→ **流程结束**。
 
-### 单元测试
 
 修复和复测完成后，为修改过的文件生成或更新单元测试，验证修复不会破坏原有功能。
 
@@ -273,18 +463,19 @@ python3 scripts/report_chat.py --username ${_USERNAME} --chat-id ${_CHAT_ID} --s
 1. 首次扫描成功后
 2. 复测扫描成功后
 
+
 ## 脚本说明
 
 脚本必须使用 python3 执行。执行脚本时**不要重定向 stderr**（如 `2>/tmp/xxx.txt`），脚本的 stderr 包含进度信息和输出文件路径，重定向会导致关键信息丢失。直接执行即可：
 
 ```bash
-python3 scripts/xxx.py --参数 值
+python3 <SKILL_DIR>/scripts/xxx.py --参数 值
 ```
 
 | 脚本 | 功能 |
 |------|------|
-| `scripts/scan_vulnerability.py` | 漏洞扫描：上传代码、创建 bundle、执行扫描，结果保存到 `scan_result.json`。支持 `--no-wait-ai`（跳过 AI 分析等待）和 `--wait-ai-only --scan-result <路径>`（仅等待 AI 分析） |
-| `scripts/parse_scan_result.py` | 扫描结果解析：解析 SARIF 格式结果，标准输出 Markdown 报告，生成 `parsed_result.json` 结构化数据。`--project-dir` 指定项目根目录，用于生成可点击的绝对路径链接 |
-| `scripts/repair_vulnerability.py` | 漏洞修复：支持 `--parsed-result` 直接传入解析结果文件（自动提取普通漏洞并聚合），或 `--vulnerability-info` 传入 JSON。结果保存到 `repair_result.json` |
-| `scripts/report_chat.py` | 对话结果上报：扫描成功后向服务端上报对话信息和漏洞数据 |
-| `scripts/utils.py` | 公共工具函数：各脚本共享的常量（HOST）、SHA256 计算、文件读取、请求头构建、git 信息获取等 |
+| `<SKILL_DIR>/scripts/scan_vulnerability.py` | 漏洞扫描：上传代码、创建 bundle、执行扫描，结果保存到 `scan_result.json`。支持 `--no-wait-ai`（跳过 AI 分析等待）和 `--wait-ai-only --scan-result <路径>`（仅等待 AI 分析） |
+| `<SKILL_DIR>/scripts/parse_scan_result.py` | 扫描结果解析：解析 SARIF 格式结果，标准输出 Markdown 报告，生成 `parsed_result.json` 结构化数据。`--project-dir` 指定项目根目录，用于生成可点击的绝对路径链接 |
+| `<SKILL_DIR>/scripts/repair_vulnerability.py` | 漏洞修复：支持 `--parsed-result` 直接传入解析结果文件（自动提取普通漏洞并聚合），或 `--vulnerability-info` 传入 JSON。结果保存到 `repair_result.json` |
+| `<SKILL_DIR>/scripts/report_chat.py` | 对话结果上报：扫描成功后向服务端上报对话信息和漏洞数据 |
+| `<SKILL_DIR>/scripts/utils.py` | 公共工具函数：各脚本共享的常量（HOST）、SHA256 计算、文件读取、请求头构建、git 信息获取等 |