@fitlab-ai/agent-infra 0.3.2 → 0.4.1

package/templates/.agents/skills/sync-pr/SKILL.zh-CN.md

@@ -1,296 +1,49 @@
 ---
 name: sync-pr
-description: >
-  将任务处理进度同步到对应的 Pull Request，包含 PR 元数据同步和单条幂等审查摘要。
-  当用户要求同步进度到 PR 时触发。参数：task-id。
+description: "将任务进度同步到 Pull Request"
 ---
 
 # 同步进度到 PR
 
-将任务处理进度同步到关联的 Pull Request。参数：task-id。
+同步 PR 元数据，并维护一条面向 reviewer 的摘要评论。
 
 ## 执行流程
 
 ### 1. 验证任务存在
 
-按优先顺序搜索任务：
-- `.agent-workspace/active/{task-id}/task.md`
-- `.agent-workspace/completed/{task-id}/task.md`
-- `.agent-workspace/blocked/{task-id}/task.md`
-
-注意：`{task-id}` 格式为 `TASK-{yyyyMMdd-HHmmss}`，例如 `TASK-20260306-143022`
+检查 `.agents/workspace/active/{task-id}/task.md`；如果任务不存在则立即停止。
 
 ### 2. 读取任务信息
 
-从 task.md 中提取：
-- `pr_number`（必需，如果缺失则提示用户）
-- `type`
-- `issue_number`（如适用）
-- `current_step`
-- 任务标题、描述、状态
-- `created_at`、`updated_at`、`last_synced_to_pr_at`（如存在）
+从 task.md 提取 `pr_number`、`issue_number`、任务标题、type 和最新时间戳。
 
 ### 3. 读取上下文文件
 
-检查并读取（如存在）：
-- 最高轮次的 `plan.md` / `plan-r{N}.md` - 技术方案
-- `implementation.md`、`implementation-r{N}.md` - 实现报告
-- `review.md`、`review-r{N}.md` - 审查报告
-- `refinement.md`、`refinement-r{N}.md` - 修复报告
-- 最高轮次的 `analysis.md` / `analysis-r{N}.md` - 需求分析（仅作为 `in:` label 的回退输入）
-
-### 4. 获取仓库坐标并检查 label 体系是否已初始化
-
-先获取仓库坐标，供后续 milestone 查询和评论同步复用：
-
-```bash
-repo="$(gh repo view --json nameWithOwner --jq '.nameWithOwner')"
-owner="${repo%%/*}"
-```
-
-执行：
-
-```bash
-gh label list --search "type:" --limit 1 --json name --jq 'length'
-```
-
-判断规则：
-- 返回 `0` -> 标准 label 体系缺失。先执行 `init-labels` 技能，然后重新执行本步骤
-- 返回非 `0` -> 继续后续 PR 元数据同步
-
-### 5. 同步 type label
-
-根据 task.md 的 `type` 字段按下表映射：
-
-| task.md type | GitHub label |
-|---|---|
-| bug、bugfix | `type: bug` |
-| feature | `type: feature` |
-| enhancement | `type: enhancement` |
-| refactor、refactoring | `type: enhancement` |
-| documentation | `type: documentation` |
-| dependency-upgrade | `type: dependency-upgrade` |
-| task | `type: task` |
-| 其他 | 跳过 |
-
-如果映射到具体 label，执行：
-
-```bash
-gh pr edit {pr-number} --add-label "{type-label}"
-```
-
-未映射到标准 type label 时跳过，不创建新 label。
-
-### 6. 同步 in: label
-
-从实现报告（优先）或分析报告中提取受影响模块：
-- 优先读取 `implementation.md` 与 `implementation-r{N}.md` 中 `## 修改文件` / `## 新建文件` 的文件路径
-- 如果实现报告不存在，则回退到分析报告中的受影响文件列表
-
-对每个文件路径：
-1. 取第一级目录作为模块名 `{module}`
-2. 去重
-3. 检查仓库中是否存在对应 label：
-
-```bash
-gh label list --search "in: {module}" --limit 10 --json name --jq '.[].name'
-```
-
-4. 只有存在精确匹配的 `in: {module}` label 时才执行：
-
-```bash
-gh pr edit {pr-number} --add-label "in: {module}"
-```
-
-5. 只添加，不移除现有的 `in:` labels
-
-### 7. 同步 Milestone
-
-根据 PR 当前状态、任务显式配置和分支策略，为 PR 关联线里程碑。
-
-**a) 检查 PR 是否已有 Milestone**
-
-执行：
-
-```bash
-gh pr view {pr-number} --json milestone --jq '.milestone.title // empty'
-```
-
-如果返回非空，保留现有里程碑并记录 `Milestone: {existing} (preserved)`，跳过后续里程碑同步。
-
-**b) 检查 task.md 是否显式指定 milestone**
-
-如果 task.md frontmatter 中存在非空 `milestone` 字段，优先使用该值作为目标里程碑。
-
-**c) 推断目标线里程碑**
-
-当 task.md 未显式指定 `milestone` 时，按以下顺序推断：
-
-1. 检测当前分支：
-
-```bash
-git branch --show-current
-```
-
-- 如果分支名匹配 `{major}.{minor}.x`，目标里程碑为同名线里程碑 `{major}.{minor}.x`
-
-2. 如果当前分支是 `main` 或 `master`，检测现有版本分支：
-
-```bash
-git branch -a | grep -oE '[0-9]+\.[0-9]+\.x' | sort -V | tail -1
-```
-
-- 如果存在最高版本分支 `X.Y.x`，则目标里程碑为 `(X+1).0.x`
-- 如果不存在版本分支，则读取最新 tag：
-
-```bash
-git tag --list 'v*' --sort=-v:refname | head -1
-```
-
-- 当最新 tag 存在且可解析为 `X.Y.Z` 时，目标里程碑为 `X.Y.x`
-
-3. 如果以上规则都无法得出结果，回退到 `General Backlog`
-
-**d) 查找并设置里程碑**
-
-执行：
-
-```bash
-gh api "repos/$repo/milestones" --paginate \
-  --jq '.[] | select(.title=="{target}") | .title' | head -1
-```
-
-- 如果目标里程碑不存在，则降级到查找 `General Backlog`
-- 如果 `General Backlog` 也不存在，则记录 `Milestone: skipped (not found)` 并跳过关联
-- 一旦找到目标标题，执行：
-
-```bash
-gh pr edit {pr-number} --milestone "{milestone-title}"
-```
-
-### 8. 同步 Development 关联
-
-如果 task.md 包含 `issue_number`，确保 PR body 关联当前 Issue。
-
-1. 读取 PR body：
+读取最新的方案、实现、审查和修复产物，用于生成 PR 元数据和 reviewer 摘要。
 
-```bash
-gh pr view {pr-number} --json body --jq '.body // ""'
-```
-
-2. 检查 body 是否已经包含以下任一关键词：
-- `Closes #{issue-number}`
-- `Fixes #{issue-number}`
-- `Resolves #{issue-number}`
-
-3. 如果已存在任一关键词，跳过更新
-4. 如果不存在，在 body 末尾追加：
-
-```bash
-gh pr edit {pr-number} --body "$(cat <<'EOF'
-{existing-body}
-
-Closes #{issue-number}
-EOF
-)"
-```
+### 4. 解析仓库坐标并检查 label 就绪状态
 
-5. 如果 task.md 不包含 `issue_number`，记录 `Development: N/A`
+先解析 `repo="$(gh repo view --json nameWithOwner --jq '.nameWithOwner')"`，再确认 `type:` labels 是否已经初始化。
 
-### 9. 生成或更新单条幂等审查摘要
+### 5. 同步元数据
 
-复用步骤 4 已获取的仓库坐标，并拉取 PR 已有评论：
+把映射后的 type label、相关 `in:` labels 和 milestone 同步到 PR 上。
 
-```bash
-pr_comments_jsonl="$(mktemp)"
+> PR 状态保护、milestone 推断，以及 PR 已关闭/已合并时的跳过规则见 `reference/delivery-detection.md`。编辑 PR 元数据前先读取 `reference/delivery-detection.md`。
 
-gh api "repos/$repo/issues/{pr-number}/comments" \
-  --paginate \
-  --jq '.[] | {id, body}' > "$pr_comments_jsonl"
-```
+### 6. 同步 Development 关联
 
-用隐藏标识定位唯一 summary 评论：
+如果存在 `issue_number`，确保 PR 正文包含 `Closes #{issue-number}` 或等价的关闭关键字。
 
-```html
-<!-- sync-pr:{task-id}:summary -->
-```
+### 7. 发布 reviewer 摘要
 
-从评论列表中提取已有 summary comment id：
-
-```bash
-summary_comment_id="$(
-  jq -r 'select(.body | contains("<!-- sync-pr:{task-id}:summary -->")) | .id' \
-    "$pr_comments_jsonl" | head -1
-)"
-```
+> 隐藏标记、幂等 summary 评论更新、review history 格式，以及评论创建/更新规则见 `reference/comment-publish.md`。发布摘要前先读取 `reference/comment-publish.md`。
 
-摘要内容要求：
-- 面向代码审查者，不重复罗列 PR diff 已经展示的文件变更
-- 从 `plan.md` 的 `## 决策`、`## 技术方法`、`## 实施步骤` 中提取 2-4 条关键技术决策
-- 关键技术决策的描述必须自包含，不要引用内部文档的编号或术语（如 `方案 A/B`）；审查者应能独立理解每条决策的含义
-- 从 `review.md`、`review-r{N}.md`、`refinement.md`、`refinement-r{N}.md` 构建审查历程表格
-- 从 `implementation.md` 或 `refinement.md` 的测试章节提取测试结果
+> **Shell 安全规则**（发布评论前必读）：
+> 1. `{comment-body}` 必须替换为**实际的内联文本**。先用 Read 工具读取文件，再将全文粘贴到 heredoc body 中。**禁止**在 `<<'EOF'` 内部使用 `$(cat ...)`、`$(< ...)`、`$(...)`、`${...}`。带引号 heredoc 会阻止所有命令替换和变量展开，它们会被当作字面文本输出。
+> 2. 构造含 `<!-- -->` 的字符串时，**禁止使用 `echo`**。bash/zsh 中 `echo` 会将 `!` 转义为 `\!`，导致隐藏标识可见。所有评论内容统一使用 `cat <<'EOF'` heredoc 或 `printf '%s\n'` 构造。
 
-审查历程表格建议字段：
-- `轮次`
-- `结论`
-- `问题统计`，例如 `B:1 M:2 m:0`
-- `修复状态`
-
-如果尚无审查产物，使用一行占位记录，例如 `Round 1 | Pending | N/A | N/A`。
-
-候选评论格式：
-
-```markdown
-<!-- sync-pr:{task-id}:summary -->
-## 审查摘要
-
-**任务**：{task-id}
-**更新时间**：{当前时间}
-
-### 关键技术决策
-
-- {decision-1}
-- {decision-2}
-
-### 审查历程
-
-| 轮次 | 结论 | 问题统计 | 修复状态 |
-|------|------|----------|----------|
-| Round 1 | Pending | N/A | N/A |
-
-### 测试结果
-
-- {test-summary}
-
----
-*由 AI 自动生成 · 内部追踪：{task-id}*
-```
-
-幂等规则：
-- 如果 `summary_comment_id` 为空 -> 创建新评论
-- 如果 `summary_comment_id` 存在且内容发生变化 -> 更新原评论
-- 如果 `summary_comment_id` 存在且内容无变化 -> 跳过
-
-创建新评论时，执行：
-
-```bash
-gh api "repos/$repo/issues/{pr-number}/comments" -X POST -f body="$(cat <<'EOF'
-{comment-body}
-EOF
-)"
-```
-
-更新已有评论时，执行：
-
-```bash
-gh api "repos/$repo/issues/comments/{comment-id}" -X PATCH -f body="$(cat <<'EOF'
-{comment-body}
-EOF
-)"
-```
-
-### 10. 更新任务状态
+### 8. 更新任务状态
 
 获取当前时间：
 
@@ -298,37 +51,22 @@ EOF
 date "+%Y-%m-%d %H:%M:%S"
 ```
 
-在 task.md 中添加或更新 `last_synced_to_pr_at` 字段为 `{当前时间}`。
-- **追加**到 `## Activity Log`（不要覆盖之前的记录）：
-  ```
-  - {yyyy-MM-dd HH:mm:ss} — **Sync to PR** by {agent} — PR metadata synced, summary {created|updated|skipped} on PR #{pr-number}
-  ```
-
-### 11. 告知用户
+更新 `last_synced_to_pr_at`，并追加 Sync to PR 的 Activity Log。
 
-```
-进度已同步到 PR #{pr-number}。
-
-已同步内容：
-- Labels：{type-label-result}, {in-label-result}
-- Milestone：{milestone-result}
-- Development：{development-result}
-- Summary：{created|updated|skipped}
+### 9. 告知用户
 
-查看：https://github.com/{owner}/{repo}/pull/{pr-number}
-```
+汇总已同步的 labels、milestone、development 状态、summary 结果以及 PR URL。
 
 ## 注意事项
 
-1. `sync-pr` 面向代码审查者，只维护一条 reviewer-facing summary 评论，不逐轮发布完整产物。
-2. PR 元数据同步必须可重复执行；重复执行时仅补齐缺失信息，不制造额外噪音。
-3. 由于 Pull Request 共享 Issue 评论接口，summary 评论应使用 `issues/{pr-number}/comments` API 创建。
-4. 如果 `issue_number` 缺失，Development 应记录为 `N/A`，不要让整个流程失败。
+- 隐藏 summary 标记必须保持 `<!-- sync-pr:{task-id}:summary -->`
+- 面向 reviewer 只保留一条摘要评论
+- 如果 PR 已关闭或已合并，必须报告 `PR #{number} is closed/merged, metadata sync skipped`
+- 发布摘要时遵守步骤 7 的 Shell 安全规则，不要在带引号 heredoc 中依赖命令替换，也不要用 `echo` 构造 HTML 注释标记
 
 ## 错误处理
 
-- 任务未找到：提示 `Task {task-id} not found`
-- 缺少 PR 编号：提示 `Task has no pr_number field`
-- PR 未找到：提示 `PR #{number} not found`
-- PR 已关闭/已合并：提示 `PR #{number} is closed/merged, metadata sync skipped`
-- gh 认证失败：提示 `Please check GitHub CLI authentication`
+- 任务未找到：`Task {task-id} not found`
+- 缺少 PR 编号：`Task has no pr_number field`
+- PR 不存在：`PR #{number} not found`
+- GitHub CLI 认证失败：`Please check GitHub CLI authentication`

package/templates/.agents/skills/sync-pr/reference/comment-publish.md

@@ -0,0 +1,82 @@
+# PR Summary Comment Publication
+
+Read this file before creating or updating the single reviewer-facing PR summary comment.
+
+## Create or Update the Single Idempotent Review Summary
+
+Use the hidden marker:
+
+```html
+<!-- sync-pr:{task-id}:summary -->
+```
+
+Fetch existing comments through the Issues comments API, not a separate PR comment API.
+
+Recommended summary sections:
+- `## Review Summary`
+- `### Key Technical Decisions`
+- `### Review History`
+- `### Test Results`
+
+Summary content rules:
+- write for reviewers, not for end users
+- do not restate the raw file diff
+- extract 2-4 self-contained technical decisions from `plan.md`
+- avoid internal shorthand such as `Plan A/B`; each decision must make sense on its own
+- build a review-history table from `review.md`, `review-r{N}.md`, `refinement.md`, and `refinement-r{N}.md`
+- include test results from `implementation.md` or refinement artifacts
+
+Recommended review-history columns:
+- `Round`
+- `Verdict`
+- `Finding Counts`
+- `Fix Status`
+
+If a summary comment already exists:
+- update it only when the content changed
+- otherwise skip the write
+
+If no summary comment exists:
+- create one with the marker and the current summary body
+
+Update an existing comment with:
+
+```bash
+gh api "repos/$repo/issues/comments/{comment-id}" -X PATCH -f body="$(cat <<'EOF'
+{comment-body}
+EOF
+)"
+```
+
+Suggested summary body:
+
+```markdown
+<!-- sync-pr:{task-id}:summary -->
+## Review Summary
+
+**Task**: {task-id}
+**Updated At**: {current-time}
+
+### Key Technical Decisions
+
+- {decision-1}
+- {decision-2}
+
+### Review History
+
+| Round | Verdict | Finding Counts | Fix Status |
+|-------|---------|----------------|------------|
+| Round 1 | Pending | N/A | N/A |
+
+### Test Results
+
+- {test-summary}
+
+---
+*Generated by AI · Internal tracking: {task-id}*
+```
+
+## Update Task Status
+
+Append:
+`- {yyyy-MM-dd HH:mm:ss} — **Sync to PR** by {agent} — PR metadata synced, summary {created|updated|skipped} on PR #{pr-number}`

package/templates/.agents/skills/sync-pr/reference/comment-publish.zh-CN.md

@@ -0,0 +1,82 @@
+# PR 摘要评论发布
+
+在创建或更新面向 reviewer 的唯一 PR 摘要评论之前先读取本文件。
+
+## 创建或更新唯一且幂等的审查摘要
+
+使用如下隐藏标记：
+
+```html
+<!-- sync-pr:{task-id}:summary -->
+```
+
+已有评论必须通过 Issues comments API 获取，而不是单独的 PR comments API。
+
+推荐摘要章节：
+- `## Review Summary`
+- `### Key Technical Decisions`
+- `### Review History`
+- `### Test Results`
+
+摘要内容规则：
+- 面向 reviewer 编写，而不是面向终端用户
+- 不要简单复述原始文件 diff
+- 从 `plan.md` 中提取 2-4 条自包含的技术决策
+- 避免使用 `方案 A/B` 这类内部简称；每条决策都必须独立可读
+- 用 `review.md`、`review-r{N}.md`、`refinement.md` 和 `refinement-r{N}.md` 构建审查历程表
+- 包含来自 `implementation.md` 或修复产物中的测试结果
+
+推荐审查历程列：
+- `轮次`
+- `结论`
+- `问题统计`
+- `修复状态`
+
+如果摘要评论已经存在：
+- 只有内容发生变化时才更新
+- 否则跳过写入
+
+如果摘要评论不存在：
+- 使用隐藏标记和当前摘要正文创建一条新评论
+
+更新已有评论时，使用：
+
+```bash
+gh api "repos/$repo/issues/comments/{comment-id}" -X PATCH -f body="$(cat <<'EOF'
+{comment-body}
+EOF
+)"
+```
+
+建议摘要正文：
+
+```markdown
+<!-- sync-pr:{task-id}:summary -->
+## 审查摘要
+
+**任务**：{task-id}
+**更新时间**：{当前时间}
+
+### 关键技术决策
+
+- {decision-1}
+- {decision-2}
+
+### 审查历程
+
+| 轮次 | 结论 | 问题统计 | 修复状态 |
+|------|------|----------|----------|
+| Round 1 | Pending | N/A | N/A |
+
+### 测试结果
+
+- {test-summary}
+
+---
+*由 AI 自动生成 · 内部追踪：{task-id}*
+```
+
+## 更新任务状态
+
+追加：
+`- {yyyy-MM-dd HH:mm:ss} — **Sync to PR** by {agent} — PR metadata synced, summary {created|updated|skipped} on PR #{pr-number}`

package/templates/.agents/skills/sync-pr/reference/delivery-detection.md

@@ -0,0 +1,54 @@
+# PR Metadata Guards
+
+Read this file before inferring milestones or deciding whether metadata sync should be skipped.
+
+Initialize label state first:
+
+```bash
+gh label list --search "type:" --limit 1 --json name --jq 'length'
+```
+
+If the result is `0`, run `init-labels` before retrying metadata sync.
+
+Type label examples:
+- `bug`, `bugfix` -> `type: bug`
+- `refactor`, `refactoring` -> `type: enhancement`
+
+## Sync the Milestone
+
+Milestone priority:
+1. current PR milestone
+2. explicit `milestone` in task.md
+3. milestone inherited from the Issue
+4. inferred release line
+5. `General Backlog`
+
+Milestone inference algorithm:
+1. if the current branch matches `{major}.{minor}.x`, use that exact release line
+2. if the current branch is `main` or `master`, inspect existing `{major}.{minor}.x` branches and target `(X+1).0.x`
+3. if no release line branch exists, inspect the latest `vX.Y.Z` tag and fall back to `X.Y.x`
+4. if none of the above resolve, fall back to `General Backlog`
+
+Execution order:
+1. preserve an existing PR milestone when present
+2. otherwise prefer explicit `milestone` in task.md
+3. otherwise inherit the Issue milestone if it exists
+4. otherwise apply the branch/tag inference above
+5. if the target milestone is unavailable, fall back to `General Backlog`
+6. if even `General Backlog` is unavailable, record `Milestone: skipped (not found)`
+
+Useful commands:
+
+```bash
+gh pr view {pr-number} --json milestone
+gh issue view {issue-number} --json labels,milestone
+git branch --show-current
+git branch -a | grep -oE '[0-9]+\.[0-9]+\.x' | sort -V | tail -1
+git tag --list 'v*' --sort=-v:refname | head -1
+gh pr edit {pr-number} --add-label "{type-label}"
+gh pr edit {pr-number} --add-label "in: {module}"
+gh pr edit {pr-number} --milestone "{milestone-title}"
+```
+
+If the PR is closed or merged, stop metadata sync and report:
+`PR #{number} is closed/merged, metadata sync skipped`

package/templates/.agents/skills/sync-pr/reference/delivery-detection.zh-CN.md

@@ -0,0 +1,54 @@
+# PR 元数据保护规则
+
+在推断 milestone 或决定是否跳过元数据同步之前先读取本文件。
+
+先初始化 label 状态：
+
+```bash
+gh label list --search "type:" --limit 1 --json name --jq 'length'
+```
+
+如果结果是 `0`，先执行 `init-labels`，再重试元数据同步。
+
+Type label 示例：
+- `bug`, `bugfix` -> `type: bug`
+- `refactor`, `refactoring` -> `type: enhancement`
+
+## 同步 Milestone
+
+Milestone 优先级：
+1. PR 当前已有的 milestone
+2. task.md 中显式设置的 `milestone`
+3. 从 Issue 继承的 milestone
+4. 推断得到的 release line
+5. `General Backlog`
+
+Milestone 推断算法：
+1. 如果当前分支匹配 `{major}.{minor}.x`，直接使用该 release line
+2. 如果当前分支是 `main` 或 `master`，检查现有的 `{major}.{minor}.x` 分支，并目标设为 `(X+1).0.x`
+3. 如果不存在 release line 分支，则检查最新的 `vX.Y.Z` tag，并回退到 `X.Y.x`
+4. 如果以上都无法得出结果，则回退到 `General Backlog`
+
+执行顺序：
+1. 如果 PR 已经设置 milestone，优先保留
+2. 否则优先使用 task.md 中显式设置的 `milestone`
+3. 否则继承已有的 Issue milestone
+4. 否则应用上面的分支 / tag 推断规则
+5. 如果目标 milestone 不可用，则回退到 `General Backlog`
+6. 如果连 `General Backlog` 都不可用，则记录 `Milestone: skipped (not found)`
+
+常用命令：
+
+```bash
+gh pr view {pr-number} --json milestone
+gh issue view {issue-number} --json labels,milestone
+git branch --show-current
+git branch -a | grep -oE '[0-9]+\.[0-9]+\.x' | sort -V | tail -1
+git tag --list 'v*' --sort=-v:refname | head -1
+gh pr edit {pr-number} --add-label "{type-label}"
+gh pr edit {pr-number} --add-label "in: {module}"
+gh pr edit {pr-number} --milestone "{milestone-title}"
+```
+
+如果 PR 已关闭或已合并，停止元数据同步，并报告：
+`PR #{number} is closed/merged, metadata sync skipped`

package/templates/.agents/skills/test/SKILL.md

@@ -1,8 +1,6 @@
 ---
 name: test
-description: >
-  Execute the project's full test workflow (compilation check + unit tests).
-  Triggered when the user requests running tests or verifying code quality.
+description: "Run the full project test workflow"
 ---
 
 # Run Tests

package/templates/.agents/skills/test/SKILL.zh-CN.md

@@ -1,8 +1,6 @@
 ---
 name: test
-description: >
-  执行项目完整测试流程（编译检查 + 单元测试）。
-  当用户要求运行测试或验证代码质量时触发。
+description: "执行项目完整测试流程"
 ---
 
 # 执行测试

package/templates/.agents/skills/test-integration/SKILL.md

@@ -1,9 +1,6 @@
 ---
 name: test-integration
-description: >
-  Execute the project's integration test workflow.
-  Triggered when the user requests running integration tests
-  or end-to-end verification.
+description: "Run the integration test workflow"
 ---
 
 # Run Integration Tests

package/templates/.agents/skills/test-integration/SKILL.zh-CN.md

@@ -1,8 +1,6 @@
 ---
 name: test-integration
-description: >
-  执行项目集成测试流程。
-  当用户要求运行集成测试或端到端验证时触发。
+description: "执行项目集成测试流程"
 ---
 
 # 运行集成测试