# 2026-04-09

## 本地运行配置说明

- 复核了当前仓库和文档中的本地运行前置条件：本机需 Node.js >= 18.15，当前环境 `v22.18.0` 已满足。
- 对于给 AI IDE 使用 CloudBase MCP，本地模式最小配置只需要 MCP client 中加入 `npx @cloudbase/cloudbase-mcp@latest`；CodeBuddy IDE 版无需手写 MCP 配置。
- `CLOUDBASE_ENV_ID`、`TENCENTCLOUD_SECRETID/SECRETKEY` 等环境变量属于可选项；大多数本地开发场景可直接走登录引导，不必预先配置。
- 如果是跑本仓库源码，则需分别安装根目录与 `mcp/` 下的 npm 依赖，再执行根目录 `npm run build` 或 `mcp/` 下的 `npm test`。

## MCP attribution 自动化处理

- 使用 `mcp-attribution-worktree` 流程处理了 2 条高价值 tool 归因：`issue_mnqe2uml_cfjti4` 已回写为 `in_progress` 并链接 PR #484；`issue_mnqer9x4_hmir6c` 已回写为 `resolved` 并链接已合并 PR #445。
- 在 `feature/attribution-querypermissions-storage-not-found` worktree 上复核了专项测试，通过后触发 fresh eval `atomic-js-none-describe-storage-acl-not-found/2026-04-08T22-09-25-aef335`；结果显示 MCP 已返回缺失 bucket 错误，但 grader 仍因直接调用 `DescribeStorageSafeRule` 的环境/语义差异而失败。
- 本轮确认本地 report-api 实际可用端口是 `127.0.0.1:3010`，而不是不可达的 `5174`。

## PR #483 / Codex review 复核

- 检查了 `TencentCloudBase/CloudBase-MCP` 的 PR #483，Codex 仅对早期复杂版 issue 自动处理实现给出 3 条评论：matrix 输出被双重 JSON.stringify、shell 单引号包裹 Claude 输出、失败评论未传 `COMMENT_BODY`。
- 这些评论对应旧文件 `.github/workflows/issue-auto-processor.yml` 与 `.github/scripts/issue-processor/scan-issues.js`，如果这些旧文件继续保留在 PR 中，评论仍然成立；如果改走简化版 CodeBuddy CLI workflow，应该把旧实现从 PR 中移除再重新 review。
- 复核时还发现 PR #483 当前 diff 混入了与 issue automation 无关的改动（如 `app-auth`、`auth-tool`、`git-workflows` 等），且简化版 workflow 本身也存在新的 shell 引号风险：`issues='${{ steps.get-issues.outputs.result }}'` 遇到单引号或多行 JSON 可能直接炸。
- 后续已在隔离 worktree 中把 PR #483 重写到 `origin/main` 基线上，只保留 6 个 issue automation 相关文件；简化版 workflow 改为单文件实现，使用 `actions/github-script` 落盘 issue JSON、`codebuddy -p --output-format json`、临时文件 comment/PR body，并由 workflow 自己控制 branch/commit/push/PR。
- 已将清理后的提交 `fea40082` 强推到 `feature/issue-auto-processor`，PR #483 描述也同步更新；当前 CI 中 `Analyze` / `sync` 已通过，`build-and-publish` 仍在 pending。
- 运行这版简化 issue auto processor 的最小配置是：仓库 secret 提供 `CODEBUDDY_AUTH_TOKEN` 或 `CODEBUDDY_API_KEY` 二选一；中国版若走 API key，再补一个 repository variable `CODEBUDDY_INTERNET_ENVIRONMENT=internal`；GitHub Actions 侧需允许 `GITHUB_TOKEN` 拥有 contents/issues/pull-requests write，并允许 Actions 创建 PR。
- 当前保留在 PR #483 的简化 workflow 触发方式只有两种：`schedule`（每 4 小时）和 `workflow_dispatch(issue_number)`；如果后续要更即时的入口，优先考虑加 `issue_comment` 的 `@ai fix` / `@ai skip`，或 `issues` 的 `labeled/reopened` 触发，而不是再回到复杂扫描脚本方案。
- 远端 main 上的 `🤖 Issue Auto Processor` 在 issue #488 上产出了空 AI 评论。根因不是模型没答，而是 workflow 的 `extract_result_text` 假设 `codebuddy --output-format json` 返回对象并取 `.result`，但实际 run 24176930760 里拿到的是 JSON 数组；日志明确报 `jq: Cannot index array with string "result"`，随后脚本仍继续发出了只有标题和 footer 的空评论。
- 后续在 PR #483 上补了 `scripts/issue-auto-processor.cjs` 和 `tests/issue-auto-processor.test.js`，把 `/cloudbase fix|skip|continue` 命令解析、issue 全线程 prompt 拼装、CodeBuddy 输出 object/array/text 兼容提取收口到可测试 helper；并给 workflow 增加“空结果即失败”兜底。
- 在远端分支 `feature/issue-auto-processor` 上两次手动重跑 issue #488：第一次验证修复了空评论，但暴露出 `ai-processing` 残留问题；随后又修了 workflow 的标签状态同步和 CodeBuddy 20 分钟超时，并再次重跑，最终 issue #488 只保留 `ai-processed` 标签且删除了最早的空 AI 评论。
- 按用户选择又清理了 issue #488 上较早那条重复的有效 AI 评论，当前仅保留最新一条有效 AI 评论作为最终结果。
- 进一步确认了这套 issue automation 的实际使用方式：`/cloudbase fix|continue|skip` 这类 `issue_comment` 命令只有在 workflow 文件已进入默认分支后才会触发；在 PR 分支阶段只能先用 `workflow_dispatch(issue_number)` 手动验证，合入默认分支后再通过评论命令让 AI 基于完整 issue 线程继续处理。
- 已在 PR #483 worktree 的 `CONTRIBUTING.md` 增补 `Issue Auto Processor` 说明，覆盖前置配置、手动/定时/评论触发方式、`/cloudbase fix|continue|skip` 语义，以及“仅默认分支可用 issue_comment、每次从完整 issue 线程重建上下文”的边界。
- 继续排查 issue #488 时确认了两个新事实：第一次重跑（run `24178917557`）之所以没提 PR，是因为当前 bug 判定主要看英文关键词/标签，issue 标题正文是中文，结果走了 `Route: non-bug -> analysis only`；之后主分支上的 `/cloudbase fix` 运行（run `24180011882`）虽然走了修复路径，但 `git commit` 因 runner 未配置有效 identity 报 `fatal: empty ident name`，导致分支 `ai-fix/issue-488` 与 `main` 指向同一提交，`gh pr create` 又报 `No commits between main and ai-fix/issue-488`，最终出现“AI Fix Attempt 评论里没有 PR 链接”的假成功现场。
- 已在 PR #483 worktree 中继续修 `issue-auto-processor-simple.yml`：commit 前显式设置 `github-actions[bot]` git identity，把 commit/push/PR 查询与创建都改成 fail-closed，PR URL 为空也直接走失败评论；同时把 bug 判定切到 helper，并补了中文报错关键词识别。对应 `tests/issue-auto-processor.test.js` 回归测试已扩到 7 条并通过，YAML 与主 bash step 语法校验也通过。
- 已清理 issue #488 当前假成功现场：删除了那条空 PR 链接的 `AI Fix Attempt` 评论，并移除了错误的 `ai-fix` 标签；当前 issue 只保留有效分析评论和 `ai-processed` 标签。 
- 在 `pr-483-cleanup` worktree 上继续把两组修复提交并推到 `feature/issue-auto-processor`：`838b3eb3` 负责 fix 路径可靠性（git identity、fail-closed、中文 bug 判定），`403e1701` 负责让自动修复分支始终基于仓库默认分支，并让 `gh pr create --base` 跟随默认分支而不是写死 `main`。
- 用分支版 workflow 两次手动重跑 issue #488：第一次 rerun（run `24180941957`）成功创建了 PR #493，但也暴露出“从 feature 分支手动验证时，修复 PR 会把整条 feature diff 一并带上”的基线问题；修复后第二次 rerun（run `24181378609`）把同一个 PR #493 收敛为只包含 `mcp/src/tools/databaseNoSQL.ts` 与 `mcp/src/tools/databaseNoSQL.test.ts` 两个真实修复文件，当前 CodeQL check 已通过。
- 这轮还顺手清理了 rerun 产生的重复 `AI Fix Attempt` 评论，issue #488 现在保留一条最新 PR 结果评论，标签为 `ai-processed` + `ai-fix`，PR #493 处于打开状态且 diff 已干净。
- 继续排查 schedule run `24181640397` 为什么只处理了 issue #375：确认这次 run 跑在 `main@9bebfc11`，按 workflow 的年龄/标签规则理论上至少还有 5 个 open issue（如 #378/#380/#439/#462/#467）也符合条件，因此“只处理一个”更像是循环提前结束而不是筛选结果只有一条；最可疑根因是 `while read ... done < <(jq ...)` 循环里直接调用 `codebuddy`，未断开 stdin，导致 CLI 吃掉了后续 issue JSON，循环只跑第一条。
- 随后在 `pr-483-cleanup` worktree 中补了回归测试并提交 `3003c70a`，把批处理逻辑改成 `mapfile` 先收集 issue 数组再 `for` 循环处理，同时给两条 `codebuddy` 调用都加上 `</dev/null`。推到 `feature/issue-auto-processor` 后手动触发 run `24183056464`，日志确认已连续处理 5 个 issue（#378/#380/#439/#462/#467），说明“只跑第一条”的 stdin 截断问题已经修复；但也顺带暴露出 #462 和 #467 在 `gh pr create` 阶段仍会失败，后续需单独排查 PR 创建返回空 URL 的根因。
