メモリ機構: GC（定期再評価）

背景

docs/plan/memory.md §GC の実装。Phase 2 は情報統合寄りだが、それでも残る重要度低下・類似 slug 乱立・replaced 滞留・sources 累積・現状不整合を整理する定期再評価経路。人間 offer はかけず、結果は git diff で検証する建て付け。

保護閾値は使用頻度メトリクスの明示 invoke frequency に依存する。

要件

Trigger

定期実行（累積 input token ベース推奨、具体値は設定で tune、実装判断）

実行主体と渡すツール

GC Agent が spawn
Phase 2 と同じ汎用 CRUD + 検索ツール + post-write Linter Hook
入力: GC 対象 record 群 + Linter Warn + 使用頻度メトリクス + replaced chain + sources 過多情報

操作粒度

ファイル単位: 丸ごと drop / 複数ファイル merge / 1 ファイルの split
ファイル内部分: 節・箇条の削除 or 圧縮、sources 古いエントリの trim

評価カテゴリ

outdated, superseded, unused, noisy を GC 理由の分類として使う。record に一律の「stale」フラグは付けない。drop / merge / split / trim / rewrite のどれを選ぶかをこのカテゴリで説明可能にする。

判断ルール

保護閾値: 明示 invoke の frequency >= 1.0 invokes/Mtoken の record は drop / 大幅圧縮の対象外
- 初期値 1.0、workspace 設定でカスタマイズ可
- model_invokation 注入による常駐は計数対象外（別指標として参照のみ）
単一 record が複数カテゴリに該当してもよい
直接削除してよいが、誤判定しやすいものは merge / trim を優先（prompt 側で誘導）

prompt

docs/plan/memory-prompts.md §GC prompt に従う

範囲外

監査 LLM 層（将来検討）
Vector index / FTS5 導入（将来検討、GC 判断には影響しない）
Workflow の GC 対象化（初期は触らない）

完了条件

Trigger で GC Agent が走り、不要 record が整理される
Linter Warn で検出した類似 slug 乱立などが GC でまとめて収斂する
保護閾値超過 record が drop / 大幅圧縮から外れる
置き換えは status: replaced + replaced_by で残り、直接削除と区別可能
git diff で drop / merge / split / trim / rewrite の理由が読める

参照

docs/plan/memory.md §GC / §使用頻度メトリクス / §判断ルール
docs/plan/memory-prompts.md §GC prompt
tickets/memory-phase2-consolidation.md（ツール構成の共通化）
tickets/memory-usage-metrics.md（保護閾値の依存）

2.6 KiB Raw Blame History Unescape Escape