长期路线：finding 语义级去重与链式发现合并机制（#87 的后续）
关联 #87（防垃圾洞四层改进）。#87 的签名去重（host+path+category+词面 Jaccard）解决"同端点同缺陷"，本 issue 跟踪两个它覆盖不到的长期方向。
方向一：语义级去重（接入 knowledge-retrieval 的 trigram 索引）
问题：词面 Jaccard 对"同一缺陷换措辞"不敏感。实测一轮 SRC 中同一 CORS 缺陷被以不同措辞报告 ~283 次，签名去重只归并了同 path 部分，跨措辞变体仍依赖阈值运气。
提案：
- 复用
knowledge-retrieval.mjs 已有的字符 trigram TF-IDF 余弦索引与 index.bin 缓存机制（该索引已服务于知识卡检索，零新依赖），为 Finding 建第二个索引：语料 = title + category + endpoint path
- auto-triage 判重时从"词集 Jaccard"升级为"词集 Jaccard + trigram 余弦"双通道：任一超阈即候选重复，双通道交叉确认再 reject（降低误杀）
- 阈值建议：余弦 ≥0.85 且词集 J≥0.3 → 近重复；0.6-0.85 灰区 → triaged 但 reason 标
possible_dup，供面板人工裁决
方向二：链式发现的跨 worker 合并机制
问题：deep/exploit-chainer worker 被鼓励产出"链式整合报告"（EXPLOIT CHAINER / MASTER / L3 chain 类），同一攻击链被多个 worker 各自整合成独立 finding——实测同一链条存在 5-6 份变体，且链式 finding 的首个 URL 各不相同，签名去重天然失效。
提案：
- 链签名：chain 类 finding（category 含 chain/exploit-chain）按"涉及 Endpoint 集合的哈希 + 根因类别集合"生成
chain_sig，写入时同签名 → 409 引用既有链（与写入时签名去重同机制）
- 证据追加而非新建：同链新证据走
/write/signal 并 [:AT] 到链内端点；Finding.repro 只增补差异步骤
- 面板呈现：d2d Findings 看板按 chain_sig 聚簇展示，簇内展开各 worker 的独立证据
优先级建议
- 方向一成本低（索引/缓存/纯函数基建都在），建议先行
- 方向二依赖 chain 类 finding 的结构化约定（目前 category 命名混乱：exploit-chain/attack-chain/chain/complete-abuse-chain 混用），需先定 category 枚举口径
长期路线：finding 语义级去重与链式发现合并机制（#87 的后续）
方向一：语义级去重（接入 knowledge-retrieval 的 trigram 索引）
问题：词面 Jaccard 对"同一缺陷换措辞"不敏感。实测一轮 SRC 中同一 CORS 缺陷被以不同措辞报告 ~283 次，签名去重只归并了同 path 部分，跨措辞变体仍依赖阈值运气。
提案：
knowledge-retrieval.mjs已有的字符 trigram TF-IDF 余弦索引与index.bin缓存机制（该索引已服务于知识卡检索，零新依赖），为 Finding 建第二个索引：语料 =title + category + endpoint pathpossible_dup，供面板人工裁决方向二：链式发现的跨 worker 合并机制
问题：deep/exploit-chainer worker 被鼓励产出"链式整合报告"（EXPLOIT CHAINER / MASTER / L3 chain 类），同一攻击链被多个 worker 各自整合成独立 finding——实测同一链条存在 5-6 份变体，且链式 finding 的首个 URL 各不相同，签名去重天然失效。
提案：
chain_sig，写入时同签名 → 409 引用既有链（与写入时签名去重同机制）/write/signal并[:AT]到链内端点；Finding.repro 只增补差异步骤优先级建议