p-PP: フィルタリングの仕組み検討
/suggestは過善の余地が大きい
このロジックだとヒットしないタスクが多分ある
効果的にjsonlを分ける方法が微妙
1つのdataにまとめて、プログラム的に機械的に分けて渡した方がいいか？
今までは機械的処理を入れないためにわざわざjsonlを分けていた
→1つのテーブルにまとめた
/suggest の現在のロジック
1. 基本的なフロー
1. 基礎フィルタリング (GenerateTaskSuggestions.ts:74-77)
task.canBeWorkedOnWith(availableTime, energy) でタスクを絞り込み
利用可能時間とエネルギーレベルに適合するタスクのみ選出
2. 優先度スコア計算 (PriorityCalculationService)
決定論的な数式で各タスクにスコアを算出
5つの要素の重み付き合計で総合スコアを計算
3. タイプ別候補選出 (GenerateTaskSuggestions.ts:381-458)
Quick/Deep/Maintenanceの3タイプを 決定論的に 選出
各タイプ固有のフィルター条件で最適な候補1つを選択
4. LLM分析
選出済み候補をLLMに送信し、done_def/pitfalls/slicesを生成
タスク選択はLLMが行わない - 既に決定済みの候補のみ分析
2. 決定論的フィルタリングの詳細
優先度スコア算出 (PriorityCalculationService.ts:52-81):
priority = w1×deadline_urgency + w2×polaris_contribution + w3×effort_inverse + w4×energy_fit + w5×recent_activity
重み：
deadline_urgency: 0.3 (期限の緊急度)
polaris_contribution: 0.25 (北極星Goal寄与度)
effort_inverse: 0.2 (作業量の逆数、Quick Win検出)
energy_fit: 0.15 (エネルギー適合度)
recent_activity: 0.1 (最近の活動)
タイプ別選出ロジック (GenerateTaskSuggestions.ts:398-457):
1. Quick候補:
estimateMinutes <= 25 かつ effortInverse > 0.2
effortInverseでソート → 上位1つ
2. Deep候補:
estimateMinutes >= 20 かつ (polarisContribution > 0.1 || deadlineUrgency > 0.1)
polarisContribution + deadlineUrgencyでソート → 上位1つ
3. Maintenance候補:
isRoutine === true または recentActivity < 0.5
totalScoreでソート → 上位1つ
3. 決定論性の保証
数値ベースの判定: 全てのフィルターが数値計算による明確な基準
ソート基準の固定: 各タイプで使用するソート基準が決定されている
上位1つ選択: 同一スコアでも配列順序で一意に決定
LLM非依存の選出: タスク選択にLLMを使用せず、決定論的アルゴリズムのみ
いくつかのユースケースに分けて考える
まず3つのタスクについて考察する
すぐ終わるタスク
緊急度が高くてすぐ終わるものがあったらこれもここで出してほしい
定量：
実行時間が短い
コアタスクに含まれるものが優先優先する
コアタスク
定量priorityが高いgoalに関連するタスクを出す。
priority順にソートしてgoalを3つ取得する
goalに紐づくtaskをすべて取得する
ゴールとそれに紐づくtaskをLLMに渡して判断させる
maintenance
定性：長期的には重要だが、pritority（優先度）はあまり高くないタスク
定量：polarisに関連しているpriorityの高くない（core taskの水準以下の）goalに関連するタスク
つまり、SQLで以下の情報を取得し、LLMに渡せばいい
ゴールとそれに紐づくタスク
実行時間が短いタスクとその文脈（ゴール）
polarisに関連しているpriorityの高くない（core taskの水準以下の）goalに関連するタスク
振り返り定期実行
終わったタスク農地古いもの（コンテキストとして不要なもの）をアーカイブする
priorityが高いタスクがなくなったらpriorityを見直す
盲点はある？