spec(retrieval): the same Li+ source file duplicated across repos takes several top-k slots

[liplus-lin-lay]

目的

#189 の重複 3 軸のうち軸 (c)（配布の重複）を分割して受け取った issue。2026-08-02 の実測により、当初の前提が事実と異なることが判明したため、本文を書き換えた。

実測（2026-08-02、deploy 済みインデックス）

当初の前提（誤り）

Li+ source は各 user repo の .claude/ に複製されているため、同内容のファイルが repo 数だけ索引に存在する。

2 点とも成立していない。

1. 複製を持つのは 4 repo 中 1 repo だけ。

repo	.claude/ の tracked file 数
github-webhook-mcp	65
github-rag-mcp	0
neuron-graph-rag	0
liplus-desktop	0

「repo 数だけ存在する」構造的な配布は起きていない。

2. 「同内容」ではない。3 ヶ月前の 1 スナップショット。

github-webhook-mcp の .claude/CLAUDE.md sentinel は build-2026-05-03.3。最終更新は 369265b（2026-05-06、"chore(li+): regenerate .claude adapter to build-2026-05-03.3"）。現行 Li+ は build-2026-08-02.1。

現行 Li+ source と突き合わせた結果:

	現行にも存在	現行から消滅
rules	18	16
skills	21	5

消滅済みパスの例: rules/model/as-if-evaluation.md / expansion-limit.md / one-step-two-step.md / output-density.md / prohibited-loops.md / loop-safety.md、rules/operations/release-version.md / repo-first-execution.md、skills/task-retrieval-orchestration/SKILL.md など。

「現行にも存在」側の 39 本も、内容は build-2026-05-03.3 時点のまま。パスが生きているぶん、こちらのほうが現行と誤認されやすい。

検索での実害

Trigger Check Gate の 5 軸チェックはいつ実行するのか / top_k: 10:

rank	実体	updated_at
1	rules/model/trigger-check-gate.md（liplus-language、正本）	2026-06-21
2	.claude/rules/model/trigger-check-gate.md（github-webhook-mcp、複製）	2026-05-25

枠を 1 つ取られること自体より、古い規則本文が rank 2 で配膳されることのほうが実害。#189 の集約は referent 単位なので、この 2 行は別実体として正しく残る（畳めば古さが見えなくなるので、畳むのは誤り）。

前提の訂正が導く結論

当初は「retrieval 側に複製判定の機構を置くか」という問いだった。実測後の問いは違う。

構造的な配布重複は存在せず、3 ヶ月前の生成物が 1 repo に commit されたまま残っているだけ。 retrieval 側に機構を足すのは、原因が 1 commit にある問題を検索層で塞ぎにいく形になる。

したがって本 issue の対象は github-rag-mcp ではなく github-webhook-mcp の .claude/ の扱いに移る。

未決（Master 判断待ち）

github-webhook-mcp が単独の Claude Code workspace root として開かれることがあるか。

• 開かれる → .claude/ は load-bearing。削除ではなく build-2026-08-02.1 へ再生成する。ただし以後も同じ古さが再発するので、生成物を commit し続けるかどうかは別途判断が要る
• 開かれない（現行レイアウトでは workspace root = C:\Users\smile\Code で、.claude/ はそこに 1 つある） → repo 内の .claude/ は残置物。削除する

どちらでも「3 ヶ月前のまま置く」だけは選択肢に無い。単独で開けば消滅済み規則がそのセッションに注入され、開かなくても検索が古い規則本文を上位で返す。

github-rag-mcp 側の残作業

上記のどちらを採っても、索引から該当行が消えることの確認が要る。doc 行の削除検出が commit された file の削除に追随するかは未確認。

参考

• 分割元 = 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
• spec(retrieval): top-k is crowded by multiple rows of the same underlying entity #189 の同一実体定義（referent であって event ではない）は本 issue でも維持。複製と正本は別 referent で、その差分（古さ）が情報

[liplus-lin-lay]

決着

本 issue の軸 (c)（配布の重複）は、retrieval 側の機構ではなく残置物の削除で解消した。

経緯

当初の前提「Li+ source が各 user repo の .claude/ に複製されている」は実測で崩れた。複製を持つのは 4 repo 中 github-webhook-mcp の 1 本だけで、内容も同一ではなく build-2026-05-03.3（2026-05-06 生成）の 3 ヶ月前スナップショット。現行 Li+ から消滅済みのパスが rules 16 本 / skills 5 本含まれていた。

構造的な配布重複ではなく 1 commit の残置物だったため、対処は github-webhook-mcp 側へ移した。

• github-webhook-mcp #243 / PR #244 = .claude/ 65 ファイルと Li+config.md を削除、.gitignore で再混入を封鎖。merge 済み

残作業（索引からの消失確認）の結果

D1 FTS 側は完全に reap された。search_docs の type='doc' / repo='Liplus-Project/github-webhook-mcp' に .claude/ 行は 0 件（残 9 行はいずれも docs/ と README 系）。doc の削除検出（currentPaths 差分 → Vectorize / FTS5 / store の削除）は設計どおり機能している。

ただしこの確認の過程で、本 issue の範囲外の欠陥が 2 件露出した。いずれも別 issue に切り出し済み。

• bug(docs): the doc reap has no per-run cap and its teardown is not surface-independent #203 — doc の reap が graph edge を消さない（wiki の reap は消す）／ per-run 上限が無い（wiki は 5 件で cap）。コード側の非対称
• bug(index): pre-D1 doc vectors linger in Vectorize and the reap cannot reach them #204 — 現行 D1（作成 2026-04-19）より前の世代の doc ベクトルが Vectorize にのみ残っており、docVectorId 経由の削除で到達できない。生きているファイルが doc 行を 2 本持つ状態が常態化しており、削除済みの .claude/CLAUDE.md（updated_at 2026-04-10）が今も返るのはこの層

#189 の定義との関係

「同一実体 = 行が指す対象であって、行を生んだ作業ではない」は本 issue でも維持された。正本と複製を畳まなかったのは正しく、畳んでいれば複製が 3 ヶ月古いという事実が見えなくなっていた。差分そのものが情報だった、という当初の判断が実測で裏付けられた形。

close。残る 2 軸は #203 / #204 が持つ。