用途：分析 main 分支最近 3 天的 CI 失败，识别损坏（100% 失败）与不稳定（失败率≥20%）的验收测试，并创建结构化 GitHub issue 供自动化修复流程处理。
主要能力：从预激活上下文读取 failed_run_ids、total_run_count、open_issues、issue_slots_available；用 gh api 列出运行中的作业，仅保留 conclusion 为 failure 且名称含 Matrix Acceptance Test 的作业；用 gh run view --job {job_id} --log | grep '^--- FAIL:' 流式扫描日志，避免加载完整大日志；按 ^--- FAIL: TestName (timing) 提取测试名并去除耗时；按运行 ID 去重后计算 fail_rate = fail_count / total_run_count；按基础测试名（首个下划线前部分）分组，每个基础名最多创建一个 issue；创建前用 gh api 查询带 flaky-test 标签的开放 issue 去重；对每个待创建 issue 做提交分析，检查相关提交是否已修复；issue 正文固定包含 Broken Tests、Flaky Tests、Commit Analysis、Sample Failure Output、Affected Stack Versions 五个部分；创建数量受 issue_slots_available 上限（最多 3）约束。
使用方式：按协议顺序执行，先解析 failed_run_ids，再逐运行获取作业与日志，聚合失败计数，应用阈值，分组去重，最后创建 issue 或调用 noop。
适用场景：Go 验收测试（TestAcc 前缀）在 CI 中反复失败或偶发失败，需要自动生成可追踪的修复工单。
限制：仅处理 main 分支最近 3 天失败运行；仅识别 --- FAIL: 行，忽略裸 FAIL；失败率低于 20% 视为噪声不创建 issue；不重新查询运行列表或 issue 数量；若全部失败已有开放 issue、全部低于阈值或未发现 --- FAIL: 行，则调用 noop 并说明原因。