spec(retrieval): Li+ source copies distributed across repos each take a top-k slot

[liplus-lin-lay]

目的

#189 が扱う重複の 3 軸のうち、軸 (c)「配布の重複」を独立した検討対象として切り出す。Li+ source は各 user repo の .claude/ へ複製されるため、同内容のファイルが repo 数だけ索引され、repo 横断検索で枠を奪い合う。

前提

#189 の実測（2026-08-01、subagent への委譲はいつ必須になるのか / top_k: 10）で、skills/task-subagent-delegation/SKILL.md（liplus-language = 正本）と .claude/skills/task-subagent-delegation/SKILL.md（github-webhook-mcp 側の複製）が別々に 1 枠ずつを占めた。

#189 は同一実体を「その行が指している対象（referent）であって、その行を生んだ作業ではない」と定義し、(a) 版の重複と (b) スレッド内の重複を畳む実装に入った。軸 (c) はその実装から意図的に外してある。

外した理由（#189 本文より）

判定材料が索引に無い。

• 内容が同一かを見るには content hash が要るが、search_docs / Vectorize metadata に無く、入れるのは spec(retrieval): top-k is crowded by multiple rows of the same underlying entity #189 の「索引側は変更しない」制約に反する
• パスで判定するなら skills/X/SKILL.md と .claude/skills/X/SKILL.md を結ぶ正規化が要るが、ヒューリスティクスは本当に別物のファイルを誤って畳む
• 配布先の複製が古い場合、その差異自体が情報になる。畳むと「複製が同期されていない」という観測が消える

検討の材料

• content hash を索引に持たせる。判定は確実になるが索引側の変更を伴うので、容量と再索引コストの評価が要る
• 正本 repo（LI_PLUS_REPO）を優先して複製側を後ろへ回す（畳まずに順位だけ下げる）。索引変更なしで枠の奪い合いだけ緩む。ただし複製が古いことの発見は難しくなる
• 複製を索引対象から外す。最も単純だが、user repo 側で実際に読まれているのは複製の方なので、「その repo に何が入っているか」を問うクエリの答えが消える
• 現状維持。repo 横断検索でのみ顕在化する問題であり、単一 repo に絞ったクエリでは起きない

未解決

畳む / 順位を下げる / 索引から外す / 何もしない のどれを取るかは未決。#189 の定義（referent 単位で畳む）を素直に延長すると「同内容の複製は同一 referent」だが、上記のとおり「同内容か」を安価に判定できないため定義だけでは決まらない。

参考

• 分割元 = spec(retrieval): top-k is crowded by multiple rows of the same underlying entity #189 軸 (c)
• 同系 = measure: hybrid retrieval degrades to dense-only for Japanese queries, and top-k is crowded by same-file duplicates #180 事実2

[liplus-lin-lay]

重複のため close。同じ軸 (c)（配布の重複）を #202 が扱う。#189 本文と PR #201 が参照しているのは #202 側で、実装後の src/aggregate.ts を前提に書かれているぶん現状に即している。本 issue 固有だった検討材料 2 件（正本優先で順位だけ下げる案 / 現状維持）は #202 の検討の入口へ移してある。

二重起票の原因は委譲側の伝達漏れ（親が本 issue を先に立てたことを subagent へ渡していなかった）。