| name | generic-issue-log-analysis |
| description | 分析当前仓库或用户明确指定的公开 GitHub issue（完整 URL 或 `#1234`）。优先读取 issue 正文和评论，按需下载日志包、截图、配置导出和崩溃转储，建立时间线后结合仓库代码、文档和必要的上游依赖判断根因，并给出修复建议或下一步排查建议。 |
Generic Issue Log Analysis
Scope
- 默认把
#1234 视为当前仓库 issue。
- 如果用户给了完整 issue URL，则以该 URL 为准。
- 只分析可以直接访问的公开 issue、评论、截图和附件。
- 如果缺少日志、现场图、配置导出或崩溃信息，要先明确说明证据不足，再基于现有材料给出初步判断。
- 如果问题依赖私有环境、外部服务或用户本地状态，而仓库内证据不足，要明确列出还缺哪些材料。
Workflow
-
规范化输入。
#1234 视为当前仓库 issue。- 完整 issue URL 以 URL 为准。
- 如果用户给的是模糊描述，先在 issue 文本里定位编号、链接或关键上下文。
-
获取 issue 内容。
- 读取正文和评论。
- 提取这些信息：版本、分支、平台、环境、任务或入口、预期行为、实际行为、复现步骤、维护者评论、附件链接。
- 如果维护者、机器人或其他评论已经给出结论，不要直接照抄；仍要用日志、代码和文档自行验证。
-
提取附件和现场证据。
- 优先关注日志包、截图、配置导出、崩溃转储、诊断报告和资源导出。
- 不要假定附件命名固定；除了项目约定命名，也要留意
log、report、debug、crash、dump、config、trace、screenshot 等常见关键词。
- 如果同一个 issue 有多份日志，先看最新一次复现；如果 issue 在对比不同版本、不同环境或不同控制器，再补看旧样本。
-
下载并解压附件。
- 二进制附件不要只靠网页抓取工具直接分析，应先下载到工作区临时目录，例如
.temp/.trash/issue-logs/issue-<number>/。
- 解压后先列目录，不要假定内部结构固定。
- 只读取和结论直接相关的文件，不要把整份大日志、整份配置或整个转储内容直接塞进回复。
-
建立时间线。
- 先从 issue 文本确定“用户认为出问题的时刻”和复现条件。
- 再把界面日志、服务日志、运行时日志、截图、配置快照和崩溃信息串成一条时间线。
- 优先锁定这次复现对应的
task_id、session_id、请求 ID、时间戳或其他稳定标识，再追踪细节。
-
回溯到代码和文档。
- 先看本仓库文档、配置定义和实现代码。
- 如果问题明显落在上游依赖、共享组件、绑定层或外部工具，再按需查看相关仓库或文档。
- 只看真正相关的模块，不要为了“完整”而把整个依赖栈都扫一遍。
-
区分 issue 当时环境和当前分支。
- 先以 issue 文本、附件、部署清单、环境变量快照和缓存状态还原用户当时的实际环境。
- 再对照当前仓库代码，判断问题是当前仍存在，还是当时存在但现在可能已修复。
- 如果 issue 很旧，或 PostgreSQL/MySQL schema、API schema、Redis 策略或 Ingress 拓扑与当前主线明显不一致，必要时按对应 tag、release 或历史提交复核旧逻辑。
- 输出给用户时，接口、环境变量、数据库字段和错误码必须以 API 合约、migration 或实际响应为准；不要把 Rust 内部类型名、SQL 列名或 Redis key 误当作对外接口。
-
输出结论。
-
输出结论。
- 明确区分“已证实的根因”“高概率怀疑点”“证据不足的待确认项”。
- 给出能执行的下一步，例如修复方向、需要补充的材料、临时绕过方案、是否建议升级或回滚。
Artifact Map
HTTP / API Access Logs
- 模块归属：Ingress、负载均衡器、HTTP middleware、API handler。
- 最适合看：请求方法、路径、状态码、CORS 预检、
x-request-id、延迟和来源地址。
- 先用请求 ID、时间戳或稳定客户端哈希把同一次请求跨层关联起来。
Application Logs
- 模块归属：Rust 服务、业务合约、数据库/Redis 适配。
- 最适合看：启动、migration、校验失败、限流、依赖降级、错误链路和优雅退出。
- 不得把完整连接 URL、Secret 或原始遥测内容复制到结论中。
PostgreSQL / MySQL Evidence
- 模块归属：PostgreSQL/MySQL schema migration、事务、唯一约束和持久化真相层。
- 最适合看：driver、migration 版本、约束冲突、锁等待、连接耗尽、查询错误和数据是否真正写入。
Redis Evidence
- 模块归属：跨 Pod 限流、短期协调和缓存。
- 最适合看：连接失败、命令错误、TTL、限流计数和降级行为。
- Redis 证据不能单独证明业务数据已可靠持久化；应回到当前部署使用的 PostgreSQL 或 MySQL 验证。
Kubernetes / Ingress Evidence
- 模块归属：Deployment、Pod、Service、Ingress、DNS、TLS 和 NetworkPolicy。
- 最适合看：就绪/存活探针、滚动升级、重启、端点分布、代理头、证书与流量是否到达 Pod。
Config Snapshots
- 模块归属：环境变量、ConfigMap、Secret 引用、Helm/Kustomize 参数和发布记录。
- 最适合看：实际生效的非敏感配置、镜像版本、端口、依赖地址是否指向预期环境。
Dumps / Crash Reports / Metrics
- 模块归属：崩溃现场、panic、OpenTelemetry/Prometheus 指标与诊断报告。
- 最适合看：异常退出、资源耗尽、吞吐、错误率、请求延迟和跨 Pod 不一致。
How To Filter Evidence
-
先从 issue 文本拿到这些锚点：
- 版本、分支、镜像 tag、提交、发布日期
- 集群、命名空间、节点、Ingress Controller、数据库/Redis 版本
- API 路径、请求 ID、触发方式、环境变量与复现时间窗口
-
再从日志和指标里找高价值信号：
error、warn、panic、timeout、retry、connection refusedrequest_id、trace ID、Pod 名称、migration 版本、SQLSTATE、Redis key 前缀- readiness 失败、Pod 重启、5xx、429、CORS 和 TLS 错误
-
先锁定“这一次复现”再下钻。
- 一个日志流通常混有多个 Pod、多个版本和历史重试。
- 如果 issue 文字说失败，但同一请求 ID 的最终请求成功，要明确写出“本次证据未复现用户描述的问题”。
-
区分表象和根因。
- HTTP 状态码、浏览器报错或告警规则经常只是表象。
- 如果数据库、Redis、Ingress 或应用日志已经给出更直接的错误链路，应优先以最接近根因的证据为准，再解释上层现象。
Common Patterns
-
维护者评论已经给出判断，但日志和代码证据并不支持：
- 以可验证证据为准，把维护者评论当成补强而不是唯一依据。
-
issue 文本说“失败 / 卡死 / 误点”，但对应复现日志最终成功：
- 先明确“本次日志没有复现出用户描述的问题”。
- 再区分是用户补错了日志，还是代码里确实存在脆弱点但这次没触发。
-
用户日志里的流程与当前主线代码明显不一致：
- 先确认 issue 当时的版本、tag 或 release。
- 不要用当前主线直接否定旧版本问题。
-
配置快照和实际运行日志不一致：
- 不要立刻认定是用户表述错误。
- 先确认配置是否在复现后又被修改、是否有多个配置文件、是否存在缓存或导出时机差异。
-
日志显示现场图、诊断包或转储已保存，但附件里没有对应文件：
- 把“缺失的关键证据”单独写出来。
- 不要假装已经验证过那部分现场。
-
多层架构项目里某一层日志只暴露表象：
- 先在最接近问题根因的那层日志定性，再回到上层解释用户看到的现象。
-
证据更接近“场景不支持”而不是“实现缺陷”：
- 必须给出代码、配置白名单、文档限制或运行时分支依据，而不是只给主观判断。
Correlating With Code
- 先看 issue 模板、README、API 合约、migration、部署清单和运行手册。
- 再看 HTTP 入口、配置定义、业务合约、数据库/Redis 适配与健康检查实现。
- 只有当证据已经明显指向上游 crate、托管数据库、Ingress Controller 或云服务时，才继续看外部仓库或官方文档。
API 与领域名称
- 总结 API、字段、环境变量、错误码、探针或部署资源时，优先使用仓库 API 合约、Rust 类型、migration 和 Kubernetes 清单中已经存在的名称。
- 用户以中文描述概念时，先用原始中文检索文档和代码，再补充已存在的 Rust 标识符或对外 API 名称；不得自行翻译后假定名称。
- 如果日志带有用户自定义名称或 hash，输出时优先保留其脱敏形式；不得反向推断或展示原始身份信息。
Linking Code Evidence
- 如果要指向具体代码行，不要写本地路径加行号，也不要写绝对路径。
- 统一给出对应仓库的远端 GitHub
blob 行号链接。
- 链接格式：
https://github.com/<owner>/<repo>/blob/<commit>/<path>#L14-L20
<owner>/<repo> 应使用本次实际分析的代码仓库；如果引用的是上游依赖或外部仓库，就用那个仓库自己的链接。<commit> 必须是本次分析实际依据的代码版本：
- 默认使用当前检出的
HEAD
- 如果为了复核旧 issue 切到了某个 tag / commit，就使用那个版本解析后的 SHA
- 如果引用的是文档、配置样例或资源定义，也尽量给对应远端链接，而不是本地路径。
Output Format
最终回答用这个结构：
## Issue 概要
- issue：`#1234`
- 版本 / 分支 / 镜像 / 环境：
- API / 资源 / 相关配置：
- 用户现象：
## 证据概览
- 实际可读材料：
- 缺失或未上传的关键证据：
## 关键证据
- issue 正文 / 评论：
- Ingress / HTTP：
- 应用、PostgreSQL/MySQL、Redis：
- Kubernetes / 配置：
- 代码依据：如需指向具体实现，直接附远端 GitHub 行号链接。
## 根因判断
- 已证实的根因：
- 高概率怀疑点：
- 当前主线是否可能已修复：
## 修复方案
1. 代码、schema、配置或部署层修复
2. 需要补充的测试、日志、指标或集群证据
3. 临时缓解与回滚边界
## 置信度
- 高 / 中 / 低
- 还缺什么证据
Reminders
- 不要只看一个日志文件下结论。
- 不要把 issue 评论、机器人提示或维护者判断当成唯一证据。
- 不要把当前分支代码直接当成 issue 当时的真实环境。
- 日志和截图冲突时，优先解释冲突，再决定更可信的证据链。
- 如果问题本身没有在当前日志中复现，要明确写“证据未复现”，不要硬凑结论。
- 如果 issue 版本较旧，要明确区分“当时的根因”和“当前主线是否已修复”。
- 如果回答里出现任务名、入口名、设置项、按钮名、提示文案，优先先搜索项目里的翻译 / 本地化文件，再使用实际用户可见文案；必要时才补原始 key / id。
- 如果回答里引用了具体代码行，直接给远端 GitHub
blob 行号链接，不要给本地路径加行号。
- 如果证据表明问题已在新版本修复，明确建议升级；如果怀疑安装包、资源文件或配置损坏，明确建议重建；如果判断为真实代码缺陷且暂无 workaround，明确建议等待修复。
