插件支持更多gitlab链接

[flyhope]

参考gitlab merge request实现方法，插件实现以下URL兼容，也是和MR一样，用户完全可配

test_report

如：https://git.example.com/group/project/-/pipelines/1001/test_report

变量： {url}

ISSUE

如：https://git.example.com/group/project/-/issues/2001

变量：{url} {title}

Pipeline

如：https://git.example.com/group/project/-/pipelines/3001

变量：{url}

[flyhope]

Issue #17 执行计划：插件支持更多 GitLab 链接（test_report / issues / pipelines）

目标

参考现有 GitLab Merge Request 实现方式，为插件新增三种 GitLab URL 类型的兼容支持，并对 MR 配置键进行重命名以与其它类型对齐。每种类型与 MR 一样完全可配置，并自动注入 wegent_code_bot workspace 动态工具。

用户确认的关键决策

1. 配置体系：新增四个独立配置键 gitLabMR / gitLabTestReport / gitLabIssues / gitLabPipelines，与现有 gitLab 并列；同时兼容旧的 gitLab 键。当 gitLabMR 与 gitLab 同时存在时，优先识别 gitLabMR。
2. 页面派发：保留单一 GitLabPage.vue，内部按 URL 路径派发到 mr / issue / pipeline / test_report 四种类型。
3. test_report 来源：使用 Pipeline 的 test_report API（URL 形如 /-/pipelines/:id/test_report），不走 MR test_reports。
4. workspace 注入：三种新类型全部注入 wegent_code_bot workspace 动态工具。

需求变量（来自 issue）

类型	URL 示例	业务变量
test_report	https://git.example.com/group/project/-/pipelines/1001/test_report	{url}
issue	https://git.example.com/group/project/-/issues/2001	{url} {title}
pipeline	https://git.example.com/group/project/-/pipelines/3001	{url}

（MR 保持现有 {mrUrl} {mrTitle} 不变。）

配置键兼容策略

存储与读取优先级

读取 MR 配置时：
  if stored.gitLabMR?.actions 存在 → 使用 gitLabMR
  else if stored.gitLab?.actions 存在 → 回退使用 gitLab（兼容旧数据）
  else → 使用 defaultConfig.gitLabMR（默认 JSON 同时写入 gitLabMR 和 gitLab 以保证回退可用）

• AIMixConfig 接口新增四个键：gitLabMR / gitLabTestReport / gitLabIssues / gitLabPipelines，每个键结构为 { actions: AIMixActionItem[] }。
• 保留 gitLab 键（类型不变），仅作为旧数据回退来源，不再写入新数据。
• AIMixStorageConfig 同样新增四个可选键，gitLab 保留为可选。
• 默认 JSON（ai-mix-defaults.json）新增四个键的默认 actions；gitLab 键保留并复制 gitLabMR 的内容，确保仅装旧版本的浏览器升级后仍能正常显示。
• saveAIMixConfig / applySubscriptionData：写入时只写四个新键，不再写 gitLab，避免双写。订阅源若同时提供 gitLabMR 与 gitLab，仅以 gitLabMR 为准写入。
• getAIMixConfig：返回值始终包含五个键（四个新键 + gitLab），其中 gitLab 的 actions 等于 gitLabMR 的 actions（用于 OptionsPage 等仍引用 gitLab 字段的旧 UI 兼容渲染，过渡期内不破坏现有界面）。

兼容性边界

• 旧版本用户的本地存储中只有 gitLab：升级后读取 MR 配置时回退使用 gitLab，行为不退化。
• 用户手动导入包含 gitLab 但不含 gitLabMR 的旧订阅 JSON：回退到 gitLab，行为不退化。
• 用户在新版本中保存配置后，gitLab 不再被写入，但 getAIMixConfig 仍会返回 gitLab（值等于 gitLabMR），保证 OptionsPage 等旧 UI 不报错。
• 后续版本可在 OptionsPage 完全切换到 gitLabMR 后，移除 gitLab 兼容逻辑。

实施步骤

Step 1 — 扩展 services/gitlabApi.ts

新增 URL 解析函数（与 parseMergeRequestUrl 同模式）：

• parseIssueUrl(url) → 正则 ^\/(.+?)\/-\/issues\/(\d+)，返回 { projectPath, issueIid, baseUrl }
• parsePipelineUrl(url) → 正则 ^\/(.+?)\/-\/pipelines\/(\d+)，返回 { projectPath, pipelineId, baseUrl }
• parseTestReportUrl(url) → 正则 ^\/(.+?)\/-\/pipelines\/(\d+)\/test_report，返回 { projectPath, pipelineId, baseUrl }

在 GitLabApiService 类新增方法：

• getIssue(projectId, issueIid) → GET /api/v4/projects/:id/issues/:issue_iid
• getPipeline(projectId, pipelineId) → GET /api/v4/projects/:id/pipelines/:pipeline_id
• getPipelineTestReport(projectId, pipelineId) → GET /api/v4/projects/:id/pipelines/:pipeline_id/test_report

新增对应接口：

• GitLabIssue：iid、title、description、state、web_url、project_id
• GitLabPipeline：id、sha、ref、status、web_url、project_id
• GitLabTestReport：total_count、success_count、failed_count、skipped_count、error_count、test_suites（结构按 GitLab API 实际返回字段声明，先以 unknown 兜底再按需补字段）
• GitLabProject 接口补 default_branch?: string 字段（Issue 类型注入 workspace 时使用，GitLab /projects/:id 接口默认返回该字段）

复用现有 extractCsrfToken 与 createGitLabApiService，无需新增工厂函数。

Step 2 — 扩展 services/config.ts

AIMixConfig 接口新增四个键：

export interface AIMixConfig {
  dingTalk: { actions: AIMixActionItem[] };
  gitLab: { actions: AIMixActionItem[] };              // 兼容旧数据/旧 UI
  gitLabMR: { actions: AIMixActionItem[] };            // 新增
  gitLabTestReport: { actions: AIMixActionItem[] };    // 新增
  gitLabIssues: { actions: AIMixActionItem[] };        // 新增
  gitLabPipelines: { actions: AIMixActionItem[] };     // 新增
  jira: { actions: AIMixActionItem[] };
}

AIMixStorageConfig 新增四个可选键，gitLab 保留为可选。

getAIMixConfig 合并逻辑改造（核心：MR 优先 gitLabMR，回退 gitLab）：

const gitLabMRActions = stored.gitLabMR?.actions
  ?? stored.gitLab?.actions           // 回退旧数据
  ?? defaultConfig.gitLabMR.actions;

return {
  dingTalk:          { actions: stored.dingTalk?.actions        ?? defaultConfig.dingTalk.actions },
  gitLab:            { actions: gitLabMRActions },              // 镜像，供旧 UI 读取
  gitLabMR:          { actions: gitLabMRActions },
  gitLabTestReport:  { actions: stored.gitLabTestReport?.actions ?? defaultConfig.gitLabTestReport.actions },
  gitLabIssues:      { actions: stored.gitLabIssues?.actions     ?? defaultConfig.gitLabIssues.actions },
  gitLabPipelines:   { actions: stored.gitLabPipelines?.actions  ?? defaultConfig.gitLabPipelines.actions },
  jira:              { actions: stored.jira?.actions            ?? defaultConfig.jira.actions },
};

applySubscriptionData：写入时只写四个新键 + dingTalk + jira，不再写 gitLab：

if (data.dingTalk?.actions)         config.dingTalk         = { actions: data.dingTalk.actions };
if (data.gitLabMR?.actions)         config.gitLabMR         = { actions: data.gitLabMR.actions };
if (data.gitLabTestReport?.actions) config.gitLabTestReport = { actions: data.gitLabTestReport.actions };
if (data.gitLabIssues?.actions)     config.gitLabIssues     = { actions: data.gitLabIssues.actions };
if (data.gitLabPipelines?.actions)  config.gitLabPipelines  = { actions: data.gitLabPipelines.actions };
if (data.jira?.actions)             config.jira             = { actions: data.jira.actions };

importAIMixConfig 扩展导入选项，新增 importGitLabMR / importGitLabTestReport / importGitLabIssues / importGitLabPipelines，保留 importGitLab 作为兼容入口（导入时若只提供 gitLab 则写入 gitLabMR，若同时提供两者则以 gitLabMR 为准）。

Step 3 — 更新 public/config/ai-mix-defaults.json

新增四个键的默认 action（全部 type: "input"），并保留 gitLab 键内容与 gitLabMR 一致：

{
  "dingTalk": { "actions": [{ "type": "input", "aiConfig": { "promptTemplate": "{content}" } }] },
  "gitLab":    { "actions": [{ "type": "input", "aiConfig": { "promptTemplate": "{mrTitle}\n{mrUrl}" } }] },
  "gitLabMR":  { "actions": [{ "type": "input", "aiConfig": { "promptTemplate": "{mrTitle}\n{mrUrl}" } }] },
  "gitLabTestReport": { "actions": [{ "type": "input", "aiConfig": { "promptTemplate": "{url}" } }] },
  "gitLabIssues":     { "actions": [{ "type": "input", "aiConfig": { "promptTemplate": "{title}\n{url}" } }] },
  "gitLabPipelines":  { "actions": [{ "type": "input", "aiConfig": { "promptTemplate": "{url}" } }] },
  "jira": { "actions": [{ "type": "input", "aiConfig": { "promptTemplate": "分析并修复解决以下提案中的问题：\n\n## Jira Issue 信息\n\n### 标题\n{title}\n\n### 环境信息\n{environment}\n\n### 描述\n{description}" } }] }
}

Step 4 — 更新 entrypoints/background.ts

第 192 行订阅校验条件扩展为识别新键：

if (!data || (!data.dingTalk
  && !data.gitLab && !data.gitLabMR
  && !data.gitLabTestReport && !data.gitLabIssues && !data.gitLabPipelines
  && !data.jira))

其余逻辑（订阅轮询、autoConfig）无需改动。

Step 5 — 重构 components/GitLabPage.vue

URL 类型检测：将 checkMergeRequest 重构为 detectGitLabPageType，返回 { type, url }，其中 type ∈ 'mr' | 'issue' | 'pipeline' | 'test_report' | null。检测顺序（先长后短避免误匹配）：

1. /-/pipelines/<id>/test_report → test_report
2. /-/pipelines/<id> → pipeline
3. /-/issues/<id> → issue
4. /-/merge_requests/<id> → mr

新增 pageType ref，isMergeRequest 替换为 isSupportedPage。模板文案「当前页面不是 Merge Request 页面」改为「当前页面不是受支持的 GitLab 页面」。

URL 清理通用化：cleanMrUrl 重命名为 cleanGitLabUrl(url, type)，按类型剥离尾部子路径（如 /diffs、/commits、/test_report）。

业务数据函数（按类型分支）：

• mr → { mrUrl, mrTitle }（保留现有 getMrBusinessData）
• issue → { url, title }（调用 getIssue，title 取 issue.title）
• pipeline → { url }（调用 getPipeline 仅用于 workspace 注入）
• test_report → { url }（调用 getPipelineTestReport 仅用于 workspace 注入）

动态 code_bot workspace 注入：参数化单一函数 getCodeBotDynamicConfig(type)，workspace 字段来源：

• mr：git_url=sourceProject.http_url_to_repo, branch=mergeRequest.source_branch, git_repo=sourceProject.path_with_namespace（不变）
• issue：git_url=project.http_url_to_repo, branch=project.default_branch, git_repo=project.path_with_namespace
• pipeline：git_url=project.http_url_to_repo, branch=pipeline.ref, git_repo=project.path_with_namespace
• test_report：git_url=project.http_url_to_repo, branch=pipeline.ref（与 pipeline 同源）, git_repo=project.path_with_namespace

getPipelineTestReport 返回的测试报告数据本身不进入 workspace，仅用于校验 pipeline 可达；后续用户若需在 prompt 中引用测试报告详情，可在 Step 8 后续迭代中扩展 getBusinessData 返回更多键。

loadAIMixConfig 按 pageType 选择配置键：

const configKeyMap = {
  mr:          'gitLabMR',
  issue:       'gitLabIssues',
  pipeline:    'gitLabPipelines',
  test_report: 'gitLabTestReport',
} as const;

aiMixActions.value = config[configKeyMap[pageType]].actions.map(action => ({
  ...action,
  getAiConfig: () => getCodeBotDynamicConfig(pageType),
}));

getBusinessData 同样按 pageType 派发到对应实现。

Step 6 — 路由无需改动

entrypoints/popup/App.vue 中 git.* / gitlab.* → gitlab 路由保持不变，派发在 GitLabPage 内部完成。

Step 7 — components/include/* 无需改动

AIMix.vue / AIAction.vue / AIInput.vue 已是泛化实现，{url} {title} 等占位符会通过 getBusinessData 自动替换，mergeTools 已支持动态 workspace 注入。

Step 8 — OptionsPage 扩展（实施时确认）

实施前需先检查 components/OptionsPage.vue：

• 若已通用渲染任意平台键 → 仅需把渲染列表从 [dingTalk, gitLab, jira] 改为 [dingTalk, gitLabMR, gitLabTestReport, gitLabIssues, gitLabPipelines, jira]，并在标签文案中区分四种 GitLab 类型。
• 若硬编码了三键 → 需同步扩展为通用渲染，支持新增的四个键。
• 兼容旧 gitLab 键的导出/导入：导出时不再输出 gitLab，导入时若仅有 gitLab 则映射到 gitLabMR。

不在范围内

• 不修改技术栈、框架、构建配置。
• 不改动 Wegent API 客户端（services/wegentApi.ts）。
• 不改动钉钉/Jira 集成逻辑。
• 不引入新的 message 类型到 background。
• 不在 prompt 中暴露 test_report 的详细用例数据（仅 {url} 变量；用例详情扩展留待后续迭代）。

验收标准

1. MR 页面：在 /-/merge_requests/<iid> 打开插件 → 加载 gitLabMR.actions（旧数据无 gitLabMR 时回退到 gitLab.actions），{mrUrl} {mrTitle} 正确替换，code_bot workspace 用 sourceProject + source_branch 注入。行为与现状一致。
2. Issue 页面：在 /-/issues/<iid> 打开插件 → 加载 gitLabIssues.actions，{url} {title} 正确替换，code_bot workspace 用 project.default_branch 注入。
3. Pipeline 页面：在 /-/pipelines/<id> 打开插件 → 加载 gitLabPipelines.actions，{url} 正确替换，code_bot workspace 用 pipeline.ref 注入。
4. Test Report 页面：在 /-/pipelines/<id>/test_report 打开插件 → 加载 gitLabTestReport.actions，{url} 正确替换，code_bot workspace 用 pipeline.ref 注入。
5. 配置兼容：旧版本用户升级后，本地存储中仅有 gitLab 键时，MR 页面行为不退化；新版本保存配置后，gitLab 键不再被写入，但 getAIMixConfig 返回值中 gitLab 等于 gitLabMR，OptionsPage 旧 UI 不报错。
6. 订阅：订阅 JSON 同时包含 gitLabMR 与 gitLab 时，仅以 gitLabMR 为准写入；仅包含 gitLab 时，写入 gitLabMR。
7. 自定义配置：用户可在 OptionsPage 中独立自定义四种 GitLab 类型各自的 actions。
8. 类型检查：pnpm compile 通过；pnpm build 产出可加载的扩展。

待实施时确认的细节

• GitLabProject.default_branch 在自建 GitLab 实例的 API 返回中字段名一致，无需额外兼容处理。
• getPipelineTestReport 返回字段在不同 GitLab 版本间差异较大，先以 unknown 兜底，按目标实例的实际返回再补类型。
• OptionsPage 是否已通用渲染——实施 Step 8 时确认。