Split PChome review low-score buckets

docs/AI_INTELLIGENCE_MODULE_SOT.md

@@ -2,7 +2,7 @@
 
 > **最後更新**: 2026-05-24 (台北時間)
 > **狀態**: 🟢 四 AI Agent 自動化閉環已落地；LLM 路由紅線升級為 Ollama-first 三主機級聯，Gemini 備援預設關閉
-> **適用版本**: V10.450
+> **適用版本**: V10.451
 
 ---
 
@@ -82,6 +82,7 @@ SQL漏斗(~300筆)
 - PChome / MOMO 競價摘要出口 `services/competitor_intel_repository.py` 使用 30 分鐘共享快取（`COMPETITOR_INTEL_CACHE_TTL_SECONDS` 可調），避免 `/growth_analysis`、`/daily_sales`、PPT/AI 報表每次請求重跑昂貴覆蓋率與價差趨勢查詢；`run_competitor_price_feeder_task` 與 PChome backfill 完成後會主動清除快取。快取只包摘要輸出，不改 matcher 的高信心門檻與 identity_v2 準確性規則。
 - 商品看板第一屏：`/` 的 V2 看板直接以 `products`、`price_records`、`competitor_prices`、`competitor_match_attempts`、`competitor_match_reviews`、`ai_price_recommendations` 顯示比對覆蓋率、PChome 優勢、MOMO 威脅、AI 挑品、待比對優先清單與 PChome 覆核隊列；`filter=ai_picks` 可查看 50 品 AI 挑品列表，`filter=pchome_review` 可直接查看需人工處理的比價覆核 SKU，並以 DB 分頁支援 search/category/status 後的完整隊列，不得只截前 50 筆。覆核狀態篩選必須至少包含全部、需單位價、已排除、低信心、價格過期、找不到同款與人工閉環，讓人工可依 matcher 診斷類型分批處理。列內顯示候選 PChome 商品、候選價、match score、單位價換算摘要、人工動作與 matcher 診斷原因標籤（品牌不符、商品線不符、容量差異、組合差異、需單位價、價差極端等），不得只顯示籠統「待比對」。`/api/export/excel/pchome-review` 必須匯出同一套覆核隊列、人工處置、候選 PChome、單位價比較與原始診斷，讓人工覆核、簡報與後續 AI 分析共用同一份證據。`/api/pchome-review/<sku>/decision` 是人工閉環入口：`accept_identity` 才可把候選寫入 `competitor_prices` 與 `competitor_price_history` 並打上 `manual_review/manual_accept/identity_v2`；`reject_identity`、`unit_price_required` 與 `needs_research` 只寫 `competitor_match_reviews` 並追加 manual attempt，不得把不同販售組合或否決候選灌入正式價差。PChome feeder 後續搜尋同一候選時必須讀取 `competitor_match_reviews`：已否決候選寫 `manual_rejected` 並跳過正式寫入，且必須繼續評估下一個候選，不能讓已否決候選長期阻塞同 SKU；已標記單位價候選寫 `manual_unit_price_required`；已要求補搜尋候選寫 `manual_needs_research` 並停留在覆核隊列；已採用候選可保守補到最低門檻並保留 `manual_review/manual_accept` 標籤。搜尋候選池只有強同款分數達 `0.90` 才可提前停止，避免 0.76 灰區候選卡掉後續更精準搜尋詞。人工 `reject_identity`、`unit_price_required`、`needs_research` 若命中當前正式候選，必須將同候選 `competitor_prices` 過期，不得繼續顯示正式總價差。商品列表必須將 `manual_rejected`、`manual_unit_price_required`、`manual_needs_research` 顯示為明確人工閉環狀態，不可回落成籠統「待比對」。`fetch_competitor_coverage()` 必須輸出人工採用、人工否決、人工單位價與採用率，daily/growth/PPT 共用 payload 必須顯示人工閉環成效，避免只呈現待審數。商品看板深度快取同時寫入 `data/dashboard_full_cache.pkl`，供多個 Gunicorn worker 共用，避免部署後各 worker 重複重建 7,000+ 商品統計造成開頁變慢；所有資料異動與 AI 挑品重算都透過 `clear_dashboard_cache()` 同步清除記憶體與共享快取，手動重算 API 會立即預熱商品看板快取，避免第一位使用者承擔重建成本。
 - PChome re-score 回收線：`rescore_accepted_current` 只能表示最新版 matcher 判定「可人工採用」，不可直接寫入正式 `competitor_prices`；`fetch_competitor_coverage()` 必須輸出 `rescore_accepted_count`，Dashboard、daily/growth 與 OpenClaw 競品摘要都要把「重算可採用待審」獨立呈現，避免和一般低信心/單位價覆核混在一起。
+- PChome 低信心操作分流：Dashboard 與 read-only `/api/pchome-review/queue` 必須把近門檻可救、證據不足、低信心舊候選拆成 `recoverable_low_score`、`true_low_confidence`、`legacy_low_score` 三個可篩選桶；廣義 `low_score` 僅作 repository/export 相容查詢，不可在 UI 中冒充單一操作分流。
 
 | 角色 | 模型 | 主機 | 成本 | 每日限額 |
 |------|------|------|------|---------|

docs/memory/current_execution_queue_20260524.md

@@ -8,7 +8,7 @@
 - 確認 `main`、Gitea、正式環境版本一致。
 - 修復或確認 SSH / Gitea / 188 hop 可用。
 - 每次上線只 recreate `momo-app`、`scheduler`、`telegram-bot`，禁止使用 `--remove-orphans`，禁止影響 `momo-db`。
-- 2026-05-24 21:20 CST 狀態：正式 `/health` 仍為 `V10.447`；本地 `main` 已提交到 `V10.450` 且比 `origin/main` ahead 3。`192.168.0.110` ping/SSH timeout、`192.168.0.188` direct SSH no route、Gitea public SSH 22/2222/3022 timeout；HTTPS fetch 可用但 push 會觸發 macOS keychain，因此暫停推版，待 110/Gitea SSH 通道恢復後再推 Gitea 並部署三個 app 容器。
+- 2026-05-24 21:28 CST 狀態：正式 `/health` 仍為 `V10.447`；本地 `main` 已提交到 `V10.451` 且預期比 `origin/main` ahead 5。`192.168.0.110` ping/SSH timeout、`192.168.0.188` direct SSH no route、Gitea public SSH 22/2222/3022 timeout；HTTPS fetch 可用但 push 會觸發 macOS keychain，因此暫停推版，待 110/Gitea SSH 通道恢復後再推 Gitea 並部署三個 app 容器。
 
 ## 1. MOMO / PChome 核心比價準確率
 

docs/memory/history_logs.md

@@ -13,6 +13,7 @@
 ## 📅 詳細更新日誌 (考古存檔)
 
 ### 2026-05-24：PChome 近門檻身份回收第二輪
+- **V10.451 low_score 操作分流拆分與 queue API**: Dashboard 比價覆核頁不再只給一個籠統低信心分頁；新增「近門檻可救」「證據不足」「低信心舊候選」三個篩選，`competitor_intel_repository.REVIEW_STATUS_FILTER_GROUPS` 同步提供對應分流，`/api/pchome-review/queue` 也能用同一套 `review_status` 做 read-only smoke / operator tools 查詢，讓 matcher 回刷、人工覆核、OpenClaw 報表能分清楚可自動回收、應保守等待、與需補搜尋的候選。
 - **V10.450 PChome 覆核 fast-count UI 語意與重算可採用指標**: 預設全量覆核頁跳過 exact count 時，模板會以「約」標記快取總數，避免操作員把快取總數誤認為即時計算；搜尋、分類與單一狀態分流仍保留精準總數。`fetch_competitor_coverage()` 同步輸出 `rescore_accepted_count`，Dashboard、daily/growth 與 OpenClaw 摘要會把「重算可採用待審」獨立顯示，不再只混在一般覆核隊列。
 - **V10.449 PChome 覆核 exact count 條件修正**: 只有預設「全部覆核、無搜尋、無分類」頁跳過 exact count；若使用搜尋詞、分類篩選或單一 review status，仍保留精準總數，避免操作員分頁資訊失準。
 - **V10.448 PChome 覆核全量頁跳過 exact count**: `review_status=all` 改用 shared overview cache 的待處理總數作為分頁總數提示，當頁只查 50 筆；單一狀態分流仍保留 exact count，避免每次操作全量覆核頁都為總筆數重掃整個 review queue。