用途：对 OpenTaint 扫描结果做静态分类（triage），为每条结果给出真阳性（TP）或假阳性（FP）判定。一个 finding 文件打包某条规则的全部结果，需逐条阅读代码流、拆分不同漏洞、各自独立判定。
输入：project-root（可选，默认当前目录，分析产物位于 <project-root>/.opentaint/）；language（必填，目标语言及对应指令）；findings（必填，待分类的 .opentaint/tracking/findings/<name>.yaml，其 sarif_hashes 打包一条规则的 SARIF 结果）。
流程：1）先核对：notes 以 reconcile 行开头的属于重扫结果，若与已分类 finding 的流（source→sink 同一关键路径）匹配，则把 sarif_hashes 并入该 finding、删除本文件并沿用原判定，不重复判定。2）逐条处理：对每个 hash 从 .opentaint/results/report.sarif 读取原始结果（hash 为 vulnerabilitySourceSinkHash/vulnerabilityWithTraceHash 指纹前 16 字符，与 fingerprints/partialFingerprints 匹配），逐步走完 source→hops→sink，并对照 .opentaint/project/sources/ 下应用源码与依赖代码核实，不能只看 trace 文本；每条结果独立判定，不因同规则共享结论。3）拆分：同一漏洞（同 sink、同关键流）保留为一个 finding，真正不同的移入新 finding 文件并带上其 sarif_hashes。4）判定并记录：TP 指 source 受攻击者控制、sink 对该输入确实危险且中间无净化；FP 指被净化/校验、source 非攻击者可控（配置、常量、服务端设置）、sink 对该输入安全（参数化、转义）或路径不可达，需记录具体原因。将 verdict 写入并在 notes 中追加理由。
输出：更新后的 .opentaint/tracking/findings/<name>.yaml；拆分时另写新 finding 文件（新名称、迁移的 sarif_hashes、从原包复制的 rule_id，notes 带入分析报告，poc 保持 pending）。摘要为每条 finding 一行：名称、判定、一句话理由。
限制：只写 finding 文件的 verdict 与 notes，绝不写 .opentaint/vulnerabilities.md（由编排器汇总）；不得改动 poc 字段或保留 finding 的 sarif_hashes；常见错误是未读 trace 就批量给出同一理由的判定。