report-analyzer-issue

技能：报告分析器问题

将疑似引擎级问题整理为一份独立的 .opentaint/issues/<slug>.md 报告。此技能本身不运行任何分析——只根据调用方提供的信息撰写报告。问题分为两类：

• analysis 问题——调用方无法通过规则或模型解决的疑似引擎级污点传播问题（分析器的结果看起来不正确）
• resource 问题——完整项目扫描在用尽允许的重试、内存上限或超时后备措施后仍未生成 SARIF；无需诊断污点问题，只需记录触发问题的设置，以便引擎团队复现

输入

由调用方提供，缺省时使用默认值。只有在必需输入缺失且没有合理默认值时才询问补充。

• project-root（可选）——目标项目的根目录。Opentaint 会将所有分析产物存放在固定的 <project-root>/.opentaint/ 目录下，因此下文所有 .opentaint/... 路径都以此为根目录解析。默认值：当前目录
• diagnosis（analysis 必需）——调用方对引擎级原因的简要说明：污点大致在哪个环节消失，以及原因。用于交接的简短说明，并非已证实的跟踪结果
• artifact（analysis 必需）——问题涉及的规则或近似模型：规则的完整 ID 和规则集，或近似模型的目标方法
• name（可选，analysis）——追踪该产物时使用的测试项目名称；其目录树位于 .opentaint/test-projects/<name>，模型位于 .opentaint/test-compiled/<name>，报告中应引用这些路径，以便引擎团队复现
• setup（resource 必需）——扫描失败且未生成 SARIF 时的运行设置：规则集、近似模型目录、项目模型、最终内存上限、超时或后备措施的结果、扫描日志，以及提交哈希（git rev-parse HEAD）

工作流程

1. 判定类型

输入决定问题类型：diagnosis（加上 artifact）表示 analysis 问题；setup 表示 resource 问题。

对于 analysis 问题，根据调用方提供的简要原因撰写——不要自行验证、复现或运行任何内容。这是交给引擎团队的初步近似说明，并非已证实的诊断；调用方提供的内容足以撰写报告。

对于 resource 问题，判定条件更简单：调用方确认完整项目扫描已完成允许的重试或后备处理，但仍未生成有效的 SARIF。无需诊断污点问题——根据运行设置撰写报告即可。

2. 撰写报告

写入 .opentaint/issues/<slug>.md，作为独立完整的交付物；<slug> 是简短的 kebab-case 症状名称。开头使用固定格式的标题，方便引擎团队快速分诊；下方为自由格式的详细内容。

两种类型都要包含以下标题信息：

• Type — analysis 或 resource
• Setup — 可复现问题的准确命令：analysis 类型填写 opentaint test rule … / test approximation run，resource 类型填写失败的 opentaint scan；每条命令都要包含模型、规则集和近似目录（resource 类型还要填写最终内存用量和超时/后备处理结果）
• Run logs — 按路径列出本次运行的日志文件：analysis 类型填写调用方引用的任何调试日志或事实可达性 SARIF（如有）；resource 类型填写扫描的输出日志
• Minimal repro — 能够展示问题的最小文件/文件夹集合：analysis 类型填写指定的测试项目 .opentaint/test-projects/<name>（如有）；resource 类型填写涉及的项目模型、规则集和近似目录（附大致大小）
• TL;DR — 用 2–3 句话描述症状；analysis 类型还要说明污点似乎在哪里中断，以及引擎应该如何处理

标题信息下方使用自由格式，至少包含：

• analysis — 被测试的 artifact（规则 ID + 规则集，或近似目标方法）；调用方简述的原因；实际结果与预期结果，以及事实可达性跟踪信息（如调用方提供）；用 1–3 句话提出引擎可能出错之处的假设（假设，而非修复方案）
• resource — 模型的大致规模（已知时填写类/模块数量）和构建该模型时的提交哈希（git rev-parse HEAD）

内容精简：标题信息加正文约占一屏。

输出

产物

• .opentaint/issues/<slug>.md — 独立完整的问题报告（交付物）

摘要

• 类型（analysis / resource）和一句话症状；对于 analysis 问题，说明污点似乎在哪里中断