fix(memory): preserve valid sources when unresolved identity is present #263

目的

識別できない資料が1件混ざっても、正常な資料の検索履歴・利用記録を保存できるようにする。残存する未解決コメントの原因も、既存証拠と取り込み処理の調査により説明する。

前提

• main / v0.12.0 は c3e5126。src/memory-api.ts の rememberResult は results、graph_results、same_entity.others の全資料を identifySource で識別してから保存する。1件の識別失敗で全 trace が保存されない。
• docs/2-feedback-memory.ja.md は未解決 source を含む検索全体の記録を停止する仕様。誤った provenance に学習を結び付けない目的を維持して、資料ごとに記録可否を扱う。
• 本番の残存1件は Liplus-Project/liplus-language Issue #1428 の issue_comment。vector_id は ic:B9kDYNPm4eKCVyazFWiY_sjR6YvOPt6Cw-OVIOi1OEE、comment_id=0、review_id=0。取得した DO canonical イベント集合と現在の GitHub コメントIDに一致しない。本文・timestampは現在の公開コメントと異なる。commentのvector ID方式は導入時から同じで、方式移行の証拠は無い。対象1件の欠落原因は未確定。
• 既存データを削除する障害ではない。個人履歴は IssueStore DO SQLite に保存され、D1検索索引とは別。

要求と制約

• 検索結果・順序を維持する。識別成功した資料だけを既存の原子的な保存処理に渡し、trace_id を発行する。
• 部分記録と除外件数・理由を明示し、個々の未解決資料の feedback が利用できないことを返す。履歴を読み直しても部分記録の状態が分かるようにする。
• 全資料が未解決の場合と、正常な0件検索の場合を区別する。未解決資料に source_id を捏造しない。
• 未解決資料や、それに由来する検証できない graph path を利用・強化対象にしない。正常な資料の既存 selected/validated/used、確認 receipt と取り消しを維持する。
• DB保存失敗、実際の検索処理の不完全さ等のエラーを一律に隠さない。識別失敗だけを資料単位で扱う。
• results / graph_results / same_entity.others の混在、全件未解決、正常0件、保存失敗、履歴再読込、安全な graph feedback を意味のある回帰テストで確認する。
• 原因調査は既存のローカル修復証拠、Git履歴、GitHubの公開データをまず使用する。確定した原因と未確認の仮説を分ける。再発する取り込み経路の欠陥を確認した場合は、その狭い範囲で修正し回帰テストを追加する。
• 本番DBを変更しない。過去の一括修復SQLを再実行しない。Cloudflare / Worker 管理はログイン済み Owner Chrome のみとし、Wrangler・管理API・トークン変更を使用しない。
• リリース作成・版番号更新はこの修正には含めない。

対象

src/memory-api.ts、既存MemoryStoreのsettings保存、src/graph.tsとsrc/mcp.tsの経路node確認、関連スキーマ・生成物・ツール説明、memory関連テスト、README、docs/2-feedback-memory.ja.md と要求仕様。原因の再現証拠に応じた取り込み関連コード・テスト。調査結果は docs に保存し、実装と整合させる。

調査で確定した欠陥と追加要求

• 旧D1行のevent ID欠落は、コメント導入時1edf74dでFTS upsertにIDを渡さず、0008で両列をDEFAULT 0追加したことが原因。4594bb6で通常/unchanged ingestとcanonical backfillの補修経路は実装済み。
• 2026-10-02の限定stored-content fetchで残存行の本文を取得。2026-05-30T11:15:02Zの中間検証報告で、現在の#1428コメントID4582731637（11:47:48Zの重複close報告）とも#1430公開コメントとも一致しない。削除済みという断定はしない。
• 導入時と現行のissue_comment.deletedはVectorize/FTS削除例外後もDO canonical削除を続け202を返す。FTSのみ失敗→索引残存/canonical削除の欠陥を再現できる。対象1件との因果は未確認。
• このhandlerの狭い修正として、索引両surfaceの削除成功までDO canonicalを保持し、片側失敗・DO非2xx/例外は503 partial_deleteを返す。失敗surface/ID/エラー理由をログに残す。正常削除、片側失敗、明示的な再配送を回帰で確認する。自動再試行/queueは追加しない。
• 詳細証拠・限界・検証はdocs/3-unresolved-source-investigation.ja.mdに保存する。追加対象はsrc/webhook.tsと削除経路のsyntheticテスト。本番DB変更・一括補修再実行は含めない。