anr-fc-analysis.yaml

# 示例：真实规模的 ANR/FC 根因分析 pipeline（已脱敏）
#
# 这不是玩具示例，而是一条在用的复杂 pipeline 的脱敏版，用来展示 hydra 的
# 全套特性怎么组合：DAG 分层并行、resume 继承 session、check + routes 路由、
# 回跳修正循环（trigger:route + loop_body + max_iterations）、逐步收紧的
# allowed_tools、compact_before_resume 等。
#
# 脱敏说明：凡是 <尖括号> 的都是占位符，套用时替换成你自己的：
#   <知识库路径>      分析方法论/领域知识的目录
#   <代码索引>        本地代码仓位置索引
#   <版本映射表>      版本号→分支的映射文件（CSV 等）
#   <问题跟踪系统>    你的 issue/工单系统
# prompt 里的领域方法论（证据分级 [观察]/[推断]/[假设]、承重环节、可废止性
# 闸门等）原样保留——它们是这条 pipeline 的核心设计，也最能说明 hydra 怎么
# 承载有纪律的多步推理。

name: anr-fc-analysis
version: 1

inputs:
  issue_id:
    description: "问题单号"
    required: true

defaults:
  model: claude-sonnet-4.6[1m]
  retry: 1
  # 不设 timeout：analyze 这类重活单步可达 ~14 分钟，默认不限墙钟。
  # 需要为某步兜底时，在该步单独写 timeout: <秒>。
  allowed_tools: [Read, Write, Bash, Glob, Grep]

workdir: "./{{ inputs.issue_id }}"

# 每个 step 的工作目录已被设为本单的 workdir。凡是你自己动手创建或修改的文件
# （下载的日志、issue-info.md、就地编辑 root-cause.md 等），一律用相对当前工作
# 目录的路径写入、文件名直接写，不要加任何绝对路径前缀（不要写成 /home/... 或
# ~/...）——加绝对前缀会把文件丢到工作目录外，导致后续 step 注入时找不到而中断。
# （被 output: 捕获的交付物由框架从回复正文保存，不在此列，见框架的 Output contract。）
user_preamble: |
  你自己动手创建或修改的文件（下载的日志、issue-info.md、就地编辑 root-cause.md 等）
  一律用相对当前工作目录的路径、直接写文件名，别加 /home/... 或 ~/ 之类绝对前缀，
  否则会写到工作目录外、下游找不到。

steps:
  # 1. 拉取问题单信息和日志到本地
  - id: fetch_issue
    prompt: |
      使用 MCP 工具获取问题单 {{ inputs.issue_id }} 的详细信息：

      1. 获取该单的附件和评论中的日志链接
      2. 如果有下载命令，执行下载，把日志保存到 logs/ 目录
      3. 将问题单的标题、描述、状态等字段整理到 issue-info.md
      4. 确定桌面 APK 的版本号和分支，写入文档：
         - 版本号是能从日志里直接坐实的事实，优先直读，不要用 ROM 构建日期等间接信号反推。
           versionName 可能出现在多种记录里（进程/包信息 dump、崩溃头、各类埋点/上报事件的
           版本字段等），换关键词、跨日志文件找，别只查一个字段就下结论。
         - 断言"日志里没有版本号"前，先确认已跨来源找过；某个字段不含或被行长截断，不等于
           全局没有。只有确实找不到任何直读来源时，才退而用构建日期推断，并在文档中如实标注
           "版本号为推断、非日志直读"。
         - 拿到版本号后，用 <版本映射表> 查它对应的打包分支——版本号→分支这一步没有日志
           直证、依赖该映射表，是正常的推断。

      确保所有日志文件都下载到 logs/ 目录下。

  # 3. 根因分析（基于知识库指导 + 日志数据）
  - id: analyze
    after: [fetch_issue]
    inject:
      - issue-info.md
    # model: claude-opus-4-8[1m]
    prompt: |
      日志文件在 logs/ 目录下。
      本地代码仓库位置参考 <代码索引>
      根据知识库（<知识库路径>）的分析方法论，结合日志数据，分析这个 ANR/FC 问题的根因。

      按知识库分析框架逐步排查，从日志/源码的可验证事实推进。
      每条对结论有用的 claim 标为 [观察]/[推断]/[假设]，过不了本级闸门就降级。

      [观察]：工具/系统吐出的原文（日志行、代码文本、dump、trace），两道闸门都过：
        1 来源：是原文本身，不是任何人对它的解读或结论。"来源 S 主张 P" ≠ "P 成立"，
          无论 S 多权威（问题单描述、评论 bot、历史 case、家族文档结论、你自己的推断）；
          可把"S 主张了 P"记为 [观察]，但 P 本身要回原文坐实。
        2 定位符：不可变产物（已抓的日志/dump/trace）用 时间戳+tid+特征串；活代码用
          函数名+特征串 主锚并钉 @commit。裸行号不算——会漂移。

      [推断]：由 [观察] 经一步明写推理得到，两道闸门都过，并点名依赖哪几条 [观察]、用什么推理：
        1 区分性：所引 [观察] 能把结论从竞争解释里挑出，不只是相容。若同批观察同样相容
          另一根因 R 而无观察排除 R，则是 [假设]。
        2 可废止性：该类推理若有已知失效方式，先用观察排除。（"X 存在"推"X 生效"，
          先排除"X 存在但被绕过/未触发"。）

      [假设]：数据不能证实也不能证伪、或过不了上面闸门的环节（借用机制、跨案例类比、
        时间接近性关联、未被本案原文坐实的二手主张）。写明：靠什么间接迹象、要哪条证据
        才能升级、是否承重（为假则结论塌）。

      领域细节去查知识库（<知识库路径>），不凭印象：
        · 每条承重 [推断]：查该类推理已知的"不具区分力信号"（家族通用尾巴）和已知反例，
          据此过区分性/可废止性。
        · "fix 是否带入本 build" / 版本差异：按 code-baseline-verification 核（commit 哈希/
          Change-Id/特征串判带入、build 时间 vs fix 合入时间、警惕代码在但兜底失效的二次回归）。
        · 二手根因：官方 Resolved/Closed 字段相对可信，Open 描述+评论 bot 多未验证；
          无论可信度，仍受 [观察] 闸门1 约束，只能当 [假设] 或"来源主张"。

      核查到位即停：定位符成功解析一次即坐实，记下结论、往下走；不重跑已坐实的核查，
      除非上次命令报错或出现矛盾证据。布尔事实（在不在某分支/某行）一次确定结果即终局。
      每个承重环节都已坐实、或已如实降级为 [假设] 时，分析完成，出报告。

      组织结论：
        · 根因 = 从 [观察] 经 [推断] 到结论的链，链上 [假设] 显式标出。
        · 承重环节只能停在 [假设] 时，结论写成条件命题："若 X 成立则根因为 Y；X 需 ___ 坐实。"
        · 置信度按标签派生：全链 [观察]/[推断] 无承重假设→高；依赖非承重假设或借用未验证
          机制→中；承重环节仍是 [假设]（含仅时间接近的关联）→弱/条件性。
        · 证据不足不硬凑："现有日志不足以定位唯一根因"是合法结论——写出它、给最可能方向和缺失证据。

      输出到 root-cause.md，包含：根因结论（或条件命题）、带分级标签+定位符的证据链、
      修复建议、已排除的替代根因（写清用哪条 [观察] 排除的）、承重假设清单及其坐实条件。

  # 简要 review：不看日志，只做「证据分级自洽性」审计——纯逻辑核对，不核证据真假。
  # 靶子是"每条 claim 是否站在它声称的级别上"这份有限清单，逐条归位后即收敛。
  - id: mini-review
    after: [analyze]
    inject: [root-cause.md]
    # 只给 Read：本步是纯逻辑审计，prompt 明确「无法也不应查日志」。给全套
    # Read/Write/Bash/Glob/Grep 时 sonnet-5 稳定产出 0 output token（空输出）——
    # 任务被告知「不许用工具」却揣着一堆工具，模型卡在这个矛盾里空转。实测：5 工具
    # → 空；仅 Read → 正常出完整审计报告。工具集必须匹配任务设计。
    allowed_tools: [Read]
    prompt: |
      你在做「证据分级自洽性」审计。输入只有 root-cause.md，没有日志和源码，所以不
      核证据真伪、也不去补查，只判断每条 claim 的分级标签是否与它的内容相符。

      分级闸门（文档标签依此定义，据此核标签是否成立）：
        [观察]：①原始产物本身，非任何人对产物的解读/结论（"来源主张 P" ≠ "P 成立"）；
                ②带可复现定位符（不可变产物用 时间戳+tid；活代码用 函数名+特征串+@commit，
                裸行号不成立）。
        [推断]：该步推理①有区分性（所引观察能把结论从竞争解释中挑出，不止相容）；
                ②可废止（该类推理的已知失效方式已被排除）。
        [假设]：过不了上述闸门，或数据既不能证实也不能证伪者。
      置信度由标签派生，非独立设定。

      逐条核对，只判以下四类分级不自洽（均可纯读文档判定，且都动摇结论）：

      A. 标签名不副实（观察闸门失败）：标 [观察] 而实为某来源的解读/结论/评论分析
         或自身推断（"某文档说""评论认为""疑似"），非原始产物；或缺可复现定位符 /
         仅有裸行号。真实级别低于所标。
      B. 内部矛盾：文档一处引用的证据与另一处的 claim/结论直接冲突（如一处称 tid
         相同，另一处所引定位符却是两个不同 tid）。
      C. [推断] 闸门失败：标 [推断] 而该推理①不具区分性——同一批 [观察] 按文档自身
         叙述亦相容另一候选，且无区分性观察（实为 [假设]）；或②未排除其自己提及的
         已知失效方式。
      D. 承重假设裸奔：结论所依赖的某【承重】环节实为 [假设]，却按 [观察]/[推断]
         陈述，或结论未写成条件命题。承重判定："此环为假，根因是否即塌。"

      收敛规则：
      - 承重环节一旦已如实标为 [假设] 且结论已条件命题化，即为自洽，不得再 REJECT。
      - 以下不构成 REJECT 理由（不改变分级自洽性）：与标签一致的置信度档位、措辞
        松紧、缺免责句、完备性补充、证据置于正文或旁注。判据为标签与内容是否相符。

      判定：
      - 命中 A/B/C/D 任一且涉及【承重】环节（修正会改变结论或其成立条件）→ REJECT
      - 仅余非承重瑕疵，或不确定性已如实标为 [假设]+条件命题 → ACCEPT

      输出：
      1. 逐条列出发现：引用原文片段、归类 A/B/C/D、指出真实级别 vs 所标级别、是否承重。
      2. 若 REJECT，列必须修正项，每项注明：改标签／补定位符／补推理环节／改写为
         条件命题，及修正后结论的变化。
      3. 末行仅写 ACCEPT 或 REJECT。
    output: mini-challenge.md
    retry: 0  # REJECT 是审出的结论、不是瞬时错误：不该 retry，直接按 failure 路由到修正
    check:
      success_pattern: "ACCEPT"
    routes:
      # ACCEPT 无需显式 goto：四路深审 after:[mini-review]，由 DAG 分层并行放行
      #（forward-goto 会串行执行，丢掉并行度；靠 after 边走 DAG 才是并行扇出）。
      # 只有 REJECT 走回跳修正循环。
      - if: failure
        goto: mini-revise

  # 6. 修正分析（回跳后重新走审查流程）
  - id: mini-revise
    trigger: route
    resume: analyze
    # model: claude-opus-4-8[1m]  # 与 analyze 一致：resume 不继承模型，切模型会 cache miss + 降级
    inject: [mini-challenge.md]
    compact_before_resume: 50
    max_iterations: 3  # 结论级反对每次都是严肃信号；opus 回查 3 轮仍坐实不了，就交给有日志的深审
    # 回跳只重跑闸门本身；四路深审绝不能被卷进这个廉价修正循环（否则每轮重烧一大笔钱）
    loop_body: [mini-review]
    prompt: |
      分级自洽性审计指出证据链存在【承重环节分级不自洽】。汇总见上方注入文件。
      逐条回应，按其类型（A 标签名不副实 / B 内部矛盾 / C 推断不成立 /
      D 承重假设裸奔）走对应修法，并将该环节标签改到与内容相符：

      1. 优先升级为事实：回日志/源码查证，给 [观察] 补真定位符，或补齐 [推断] 缺的
         那一步推理。查证若推翻原结论，即改结论。
      2. 升不上去则降级+条件化：现有数据既不能坐实也不能推翻的承重环节，标为 [假设]，
         结论改写为条件命题："若 [假设]X 成立则根因为 Y；X 需 ___ 坐实。" 置信度随
         标签派生下调。
      3. B 类内部矛盾：使冲突两处与各自定位符一致，取证据真正支持的一版。
      4. 直接编辑 root-cause.md，只改涉及环节，不重写全文。
    routes:
      - if: success
        goto: mini-review
      # 回查 3 轮仍不收敛：说明存在现有日志难以坐实的承重步骤，交给有日志、算力更足的深审去啃
      - if: max_iterations
        goto: [challenge_evidence, challenge_reasoning, challenge_alternatives, challenge_fix]

  # 4. 并行深审：四个正交维度，各守证据链的一个关节（事实→因果→排他→修复+版本）。
  #    分开是为了每个方向都被深审，而不是一个 step 浅扫多个方向。
  # 4a. 事实落地：只管 [观察] 真不真，不碰因果链是否成立（那是 reasoning 的活）
  - id: challenge_evidence
    after: [mini-review]
    inject: [issue-info.md, root-cause.md]
    prompt: |
      你是一位资深 Android 系统工程师，负责【事实落地核验】。只核一件事：report 里
      每条 [观察] 是否真的存在于数据中、且原文确实是那个意思。因果链是否成立、有没有
      替代根因、修复是否正确，都不在本步范围内。

      日志文件在 logs/ 目录下。本地代码仓库位置参考 <代码索引>
      按知识库（<知识库路径>）的分析方法论执行。

      逐条核 [观察]：
      1. 将其定位符拉到真实数据核对：
         · 日志 [观察]（时间戳+tid+特征串）→ 该行是否存在？原文是否支持该 claim，
           抑或被误读 / 断章取义 / 混入注解？
         · 源码 [观察]（函数名+特征串，@commit 行号）→ 用【特征串】定位（行号会漂移，
           不据行号）；确认代码存在且与 report 所述一致。
      2. 判定每条 [观察] 是否过了两道闸门：
         · 来源闸门：是【原始产物本身】，还是某来源的解读/结论（问题单描述、评论区
           bot 分析、历史 case/家族文档的既有结论）被当作观察？后者只能是 [假设] 或
           "来源主张"。
         · 可复现闸门：定位符能否被第三方复现（源码用特征串@commit，非裸行号）。
      3. "某 fix 已带入/已验证本 build""版本或构建差异"这类事实断言，按知识库
         code-baseline-verification 核（是否带入用 commit/Change-Id/特征串判、比 build
         时间 vs fix 合入时间、留意代码在但兜底失效），不据 report 转述采信。

      每个发现指明：涉及 report 哪条 claim、所标级别 vs 核验后真实级别、是否【承重】
      （该环节为假根因是否塌）、严重程度（高/中/低）。
    output: review-evidence.md

  # 4b. 因果链：观察都为真的前提下，从观察到根因的推理是否成立、是否停在表层
  - id: challenge_reasoning
    after: [mini-review]
    inject: [issue-info.md, root-cause.md]
    prompt: |
      你是一位资深 Android 系统工程师，负责【因果链核验】。审查时假定 [观察] 都为真
      （它们的真实性不在本步范围内），只审从这些观察到根因的【推理】是否站得住。

      日志文件在 logs/ 目录下。本地代码仓库位置参考 <代码索引>
      按知识库（<知识库路径>）的分析方法论执行。

      report 的根因结论应是一条 [观察]→[推断]→根因 的链。逐环审：
      1. 每个 [推断]：所依赖的 [观察] 是否真能推出它？中间是否省略必要环节（推理
         跳跃）？抑或"证据 A"根本推不出"结论 B"？
      2. 借用机制是否本案自证：report 是否把"知识库/家族文档已验证的机制"直接当作
         本案已成立的因果，却无本案自身的 [观察] 坐实该机制此次确实生效？此类借用
         须标 [假设] 并说明承重性。
      3. 真根因抑或表层现象：因果链是否推到可修改的根因，还是停在某中间症状即收尾
         （把现象当根因）。
      4. 是否有循环论证 / 用结论证前提。

      每个发现指明：断在链条哪一环、缺失的必要环节、该环节真实是 [推断] 还是 [假设]、
      是否【承重】（断了根因是否塌）、严重程度（高/中/低）。
    output: review-reasoning.md

  # 4c. 排他性：现有证据是否真的只指向这一个根因，而不能同样支持别的
  - id: challenge_alternatives
    after: [mini-review]
    inject: [issue-info.md, root-cause.md]
    prompt: |
      你是一位资深 Android 系统工程师，负责【替代根因排他性核验】。只审一件事：
      report 给出的这套 [观察]，是不是真的只指向它的结论、而不能同样支持别的根因。
      证据真假、因果链是否成立、修复是否正确，都不在本步范围内。

      日志文件在 logs/ 目录下。本地代码仓库位置参考 <代码索引>
      根据知识库（<知识库路径>）的分析方法论执行。

      你核的是 report 每条承重 [推断] 的【区分性闸门】：所引观察能不能把结论从竞争解释
      里挑出来，还是只是相容。

      1. 列出与 report 现有 [观察] 证据【同样相容】的其他候选根因（能解释同一批观察行的）。
         去知识库（<知识库路径>）查：这类现场有哪些【已知的不具区分力信号】（多个子根因
         共有的通用"尾巴"），以及区分它们要靠哪种证据（如触发路径前驱）。不要凭印象，
         按知识库列的候选集来。
      2. 对每个候选，去日志里找能【区分】它与 report 结论的证据：
         · 找到能排除该候选的 [观察]（给定位符）→ 排他性成立；
         · 若 report 的结论主要靠"不具区分力信号"撑着、找不到能区分的观察 → 排他性
           不成立，等于把一个 [假设]（"是这个根因不是那个"）当成了结论，属承重问题。

      对每个发现，指明：候选根因是什么、用哪条 [观察]（定位符）能否排除它、
      report 的排他性是否成立、是否【承重】、严重程度（高/中/低）。
    output: review-alternatives.md

  # 4d. 修复方案 + 版本一致性：修复对不对，以及"这个 fix 到底在不在本 build"
  - id: challenge_fix
    after: [mini-review]
    inject: [issue-info.md, root-cause.md]
    prompt: |
      你是一位资深 Android 系统工程师，负责【修复方案 + 版本一致性核验】。
      日志文件在 logs/ 目录下。本地代码仓库位置参考 <代码索引>
      根据知识库（<知识库路径>）的分析方法论执行。

      report 里每条 claim 带分级标签（[观察]/[推断]/[假设]）。分两块审：

      ▍修复方案本身
      1. 修复是否针对已被 [观察]/[推断] 坐实的根因？若它针对的根因仍是 [假设]，那修复
         方案本身也只是 [假设]，必须如实写"以该假设成立为前提"。
      2. 修复涉及的代码事实去仓库核对：文件/函数/分支是否真实存在、与 report 所述是否
         一致（用【函数名+特征串】定位，不认死行号）。不要凭 report 转述就采信。
      3. 修复是否可能引入新问题/性能退化？有没有更简单或更安全的替代方案？

      ▍版本一致性（正交于上面，务必单独查——这是"代码在≠问题修好"的可废止性闸门）
      4. report 若用"某 fix 已合入/已验证本 build"来支撑判断，按知识库
         code-baseline-verification 的方法核对（那里写了如何判 fix 是否真在本 checkout、
         如何比 build 与 fix 的合入时间、以及"代码在但兜底失效的二次回归"这类反例）。
         结论：「代码在」是 [观察]，「所以本 build 没这个根因」是必须过可废止性闸门的
         [推断]——反例未排除前，它只是 [假设]。
      5. report 把某 fix 说成"已验证/对齐官方"时，核实它引的是该 fix 的真实改动，还是
         自己类比重构的方案——后者不能用"已验证"包装。

      对每个发现，指明：它依附的根因当前是哪一级证据、涉及的代码/版本事实是否已核对、
      是否【承重】、严重程度（高/中/低）。
    output: review-fix.md

  # 5. 汇总裁决
  - id: verdict
    after: [challenge_evidence, challenge_reasoning, challenge_alternatives, challenge_fix]
    inject: [root-cause.md, review-evidence.md, review-reasoning.md, review-alternatives.md, review-fix.md]
    prompt: |
      综合四份【看过日志的】正交核验意见（事实落地 / 因果链 / 排他性 / 修复+版本），
      给出最终裁决。裁决围绕证据分级（[观察]/[推断]/[假设]）：判断 report 的证据链在
      经日志核验后是否仍然自洽、承重环节是否都落在 [观察]/[推断] 上或已如实条件化。

      这四份意见都基于对日志/源码的实际核验，因此下面这些【经核验成立的事实性问题】
      都是合法 REJECT 理由：
      · 某条 [观察] 的定位符经核验解析不到、或原文并不支持该 claim（事实不实）；
      · 因果链某承重环节的推理经核验推不出、或借用机制未在本案自证（因果断裂）；
      · 存在一个现有 [观察] 无法排除、同样成立的替代根因（排他性不成立）；
      · 修复所依赖的"fix 已带入本 build"经版本核验不成立（版本一致性不成立）。

      对每个想据以 REJECT 的发现，先过测试：
        "修好它，改变的是【某承重环节的真实证据级别 / 证据是否属实 / 是否有未排除的
         替代根因】，还是只是【与标签一致的置信度档位、措辞、排版、锦上添花】？"
      只有前者计入判定。

      判定标准：
      - 存在【承重】环节的高严重度问题（承重 [观察] 被日志推翻、承重 [推断] 断裂、
        存在未排除且同样成立的替代根因）→ REJECT
      - 多个【承重】环节的中严重度问题 → REJECT
      - 只剩非承重瑕疵、或承重不确定性已被如实标成 [假设] 且结论已条件命题化 → ACCEPT
        （已写成"以 [假设]X 为前提、X 待坐实"的条件结论，不因 X 未坐实而 REJECT——
         这是如实分级的正确结果，交由最终报告呈现，而非无限打回。）

      输出：
      1. 逐条引用各核验的关键发现，标注承重/非承重 + 涉及的分级问题类型
      2. 如 REJECT，列出必须修正的要点，每条注明：改标签/补定位符/补推理/换结论/
         条件化，以及修好后结论会怎么变
      3. 最后一行只写 ACCEPT 或 REJECT
    output: challenge.md
    retry: 0  # 同 mini-review：REJECT 是裁决结论、不是瞬时错误，不该 retry。
              # 继承 defaults.retry=1 会让每次合理 REJECT 先白跑一遍 verdict 再路由。
    check:
      success_pattern: "ACCEPT"
    routes:
      - if: success
        goto: final_report
      - if: failure
        goto: revise

  # 6. 修正分析（回跳后重新走审查流程）
  - id: revise
    trigger: route
    resume: analyze
    # model: claude-opus-4-8[1m]  # 与 analyze 一致：resume 不继承模型，切模型会 cache miss + 降级
    inject: [challenge.md]
    compact_before_resume: 50
    max_iterations: 2  # 深审每轮要重跑三个带日志的审查，单轮极贵；2 轮不收敛就带最后一版出报告
    # 回跳重跑整个深审+裁决闭环（四路深审并行 → verdict 汇总）
    loop_body: [challenge_evidence, challenge_reasoning, challenge_alternatives, challenge_fix, verdict]
    prompt: |
      看过日志的审查者指出你的证据链有【承重环节分级不自洽】的问题。
      汇总意见见上方注入文件。逐条回应，把每个承重环节的分级标签改到与核验结果相符：

      1. 优先升级为事实：回日志/源码查证，给 [观察] 补真定位符或补齐 [推断] 的推理。
         若审查者已用某条 [观察] 推翻了原结论 → 改结论；若指出某替代根因无法排除 →
         要么找到能排除它的 [观察]，要么承认排他性不成立、相应弱化结论。
      2. 升不上去就诚实降级 + 条件化：既不能坐实也不能推翻的承重环节，标成 [假设]，
         结论改写成条件命题，置信度随标签派生下调，不要硬撑成定论。
      3. 直接编辑 root-cause.md，只改涉及的环节，不要重写全文。

      不要用降标签/加免责句去敷衍承重问题，也不要对查不动的环节硬标 [观察]。
    routes:
      - if: success
        goto: [challenge_evidence, challenge_reasoning, challenge_alternatives, challenge_fix]
      # 深审反复不过、改了 2 轮仍不收敛：带最后一版（含明确标注的未决前提）出报告，而非整体失败
      - if: max_iterations
        goto: final_report

  # 7. 最终报告
  - id: final_report
    trigger: route
    inject: [issue-info.md, root-cause.md, challenge.md]
    prompt: |
      整理最终的根因分析报告。全程保持证据分级（[观察]/[推断]/[假设]）的诚实标注，
      不要在汇总时把带保留的结论"洗"成确定结论。包含：
      - 问题概述
      - 根因结论：如果它是【条件性】的（依赖某个仍为 [假设] 的承重环节），就照条件
        命题写出来，不要包装成定论。
      - 证据链：按 [观察]→[推断]→结论 组织，[观察] 保留其定位符（日志 时间戳+tid /
        源码 路径:行号），让读者能自行复核。
      - 修复建议：注明它建立在哪一级证据的根因之上。
      - 已排除的其他可能性：写清各自用哪条 [观察] 排除的。
      - 承重假设与待坐实前提：把所有仍是 [假设] 的承重环节单列，写明缺哪条证据、
        怎样才能把它坐实或推翻。
      - 审查过程摘要。

      诚实优先：如果分析到此仍未定位到唯一根因，就如实写"现有证据不足以定论"，
      给出最可能的方向 + 缺失的关键证据清单。
    output: final-report.md
    routes:
      - if: success
        goto: issue_comment

  # 8. 问题单评论稿：把最终报告转成能直接贴进问题单的一段评论。
  #    只读 final-report.md（已是经审查修正后的结论），不重新分析。
  - id: issue_comment
    trigger: route
    inject: [final-report.md]
    prompt: |
      把上方 final-report.md 的结论整理成一段可直接粘贴进问题单的评论。
      读者是该问题单的研发/测试同学，他们只能看到这段评论本身。

      【自包含】这是硬要求——评论必须完全脱离本地环境独立成立：
      - 不出现任何本地路径（logs/、/home/... 、仓库目录）、本地 git 命令、
        run 目录、文件名。读者不会、也无法去翻这些东西。
      - 不写"见证据链 O10""详见上文"这类指向本地文档的交叉引用；要说的结论
        直接在评论里说完整。
      - 版本核验、fix 是否合入这类结论，直接给事实（版本号、分支名、commit、
        Gerrit 号、合入时间 vs 构建时间的先后），不要贴本地命令行或让读者自己去跑。
      - 日志证据用「时间戳 + 日志里的关键特征串」来指认（读者能在自己的日志里搜到），
        不要用只在本地文件里成立的裸行号。

      【内容】结论先行、面向行动：
      - 一句话结论：什么组件、什么场景、为什么 ANR/FC。
      - 根因说明：讲清触发场景和失效机制，让没读过分析过程的人也能看懂。
      - 若涉及某个 fix 是否已带入：明确说清它在不在本版本、起没起作用，尤其要防止
        读者做出错误动作（如重复 cherry-pick 已在的 commit）——这类要显著提示。
      - 修复建议：给到具体方向；有多个方案时标出推荐项和各自的注意点/风险。
      - 验证方式：怎么复现、修好后看什么现象算通过。
      - 关键证据：几条最能支撑结论的日志（时间戳 + 特征串）。
      - 已排除的其他可能：简要列，让 reviewer 知道结论是收敛过的。

      【语气】客观、就事论事。结论的确定性要与报告一致：报告里标为条件性/待坐实
      的环节，评论里也不能写成板上钉钉；报告是高置信度定论的，就直接下结论，不必
      堆砌不确定措辞。不使用证据分级的内部术语（[观察]/[推断]/[假设]）——那是分析
      过程的脚手架，评论按普通工程结论的方式陈述即可。
    output: issue-comment.md