ewoooc/docs/memory/current_execution_queue_20260524.md

# Current Execution Queue 2026-05-24

> 目的：把目前使用者要求的核心產品優化整理成單一執行佇列，避免 UI、比價、PPT、AI 觀測台與部署驗證漏項。
> 原則：準確率優先；不放寬 MOMO / PChome 全域比對門檻；正式部署不碰 `momo-db`；每個工作流都需有測試或正式 smoke。

## 0. 部署與驗證通道基準

- 確認 `main`、Gitea、正式環境版本一致。
- 修復或確認 SSH / Gitea / 188 hop 可用。
- 每次上線只 recreate `momo-app`、`scheduler`、`telegram-bot`，禁止使用 `--remove-orphans`，禁止影響 `momo-db`。
- 2026-05-24 21:33 CST 狀態：`main` 已推 Gitea 並部署到 188，正式 `/health` 為 `V10.451`。本輪只 recreate `momo-app`；`scheduler`、`telegram-bot` 未重建但保持 healthy；未使用 `--remove-orphans`，未碰 `momo-db`。Smoke 通過：主要頁面 HTTP 200、三個 app 容器 healthy、`/api/pchome-review/queue` 可用於 `recoverable_low_score` / `legacy_low_score` read-only 查詢，且 10 分鐘錯誤 log 未見 Traceback / ERROR。
- 2026-05-24 22:17 CST 狀態：`main` 已推 Gitea 並部署到 188，正式 `/health` 為 `V10.453`。本輪 recreate `momo-app`、`scheduler`、`telegram-bot`；未使用 `--remove-orphans`，未碰 `momo-db`。Smoke 通過：三個 app 容器 healthy、Gemini hard disabled 且 24 小時 `ai_calls` 無 Gemini provider、Ollama 順序維持 GCP-A → GCP-B → 111、`/api/pchome-review/queue` 三個 status 查詢成功、rescore audit read-only `selection_mode=latest_sku_only`。
- 2026-05-24 22:55 CST 狀態：`main` 已推 Gitea 並部署到 188，正式 `/health` 為 `V10.455`。本輪 recreate `momo-app`、`scheduler`、`telegram-bot`；未使用 `--remove-orphans`，未碰 `momo-db`。Smoke 通過：三個 app 容器 healthy、EventRouter `decision_envelope` 直送不進 L1/L2 AI handler、Telegram 信封顯示標的 SKU 與 PChome 候選、Gemini hard disabled 且 24 小時 `ai_calls` 無 Gemini provider、Ollama 順序維持 GCP-A → GCP-B → 111、`/api/pchome-review/queue?review_status=rescore_accepted` 查詢成功、10 分鐘錯誤 log 未見 Traceback / ERROR / CRITICAL。已執行 `--retract-variant-accepted`，最新 `rescore_accepted_current` 中 `variant_selection_review` 殘留為 0。
- 2026-05-24 23:05 CST 狀態：`main` 已推 Gitea 並部署到 188，正式 `/health` 為 `V10.456`。本輪 recreate `momo-app`、`scheduler`、`telegram-bot`；未使用 `--remove-orphans`，未碰 `momo-db`。Smoke 通過：三個 app 容器 healthy、`/api/pchome-review/queue?review_status=rescore_accepted` 每筆帶 `decision_envelope`、guardrail `can_auto_execute=false`、Gemini hard disabled 且 24 小時 `ai_calls` 無 Gemini provider、Ollama 順序維持 GCP-A → GCP-B → 111、5 分鐘三容器錯誤 log 未見 Traceback / ERROR / CRITICAL。
- 2026-05-24 23:17 CST 狀態：`main` 已推 Gitea 並部署到 188，正式 `/health` 為 `V10.457`。本輪 recreate `momo-app`、`scheduler`、`telegram-bot`；未使用 `--remove-orphans`，未碰 `momo-db`。Smoke 通過：三個 app 容器 healthy、Dashboard PChome 覆核頁顯示 `dashboard-review-envelope` 與 HITL、`/api/pchome-review/queue?review_status=rescore_accepted` 仍帶 `decision_envelope` 且 `can_auto_execute=false`、Excel flatten helper 輸出決策信封 ID/資料品質/自動執行允許/證據摘要、Gemini hard disabled 且 24 小時 `ai_calls` 無 Gemini provider、Ollama 順序維持 GCP-A → GCP-B → 111、5 分鐘三容器錯誤 log 未見 Traceback / ERROR / CRITICAL。
- 2026-05-24 23:30 CST 狀態：`main` 已推 Gitea 並部署到 188，正式 `/health` 為 `V10.458`。本輪 recreate `momo-app`、`scheduler`、`telegram-bot`；未使用 `--remove-orphans`，未碰 `momo-db`。Smoke 通過：三個 app 容器 healthy、`summarize_review_decision_envelopes()` 產生 3 條 HITL 摘要且全數 `can_auto_execute=false`、`_fetch_competitor_summary()` 帶 `review_decision_text`、`/api/pchome-review/queue?review_status=rescore_accepted` 仍帶 `decision_envelope` 且 `can_auto_execute=false`、核心頁面 `/daily_sales`、`/growth_analysis`、`/observability/ppt_audit_history`、`/market_intel/matches`、`/vendor-stockout/list` HTTP 200；5 分鐘三容器錯誤 log 未見 Traceback / ERROR / CRITICAL，最新 `rescore_accepted_current` 中 `variant_selection_review` 殘留為 0。
- 2026-05-24 23:43 CST 狀態：`main` 已推 Gitea 並部署到 188，正式 `/health` 為 `V10.459`。本輪 recreate `momo-app`、`scheduler`、`telegram-bot`；未使用 `--remove-orphans`，未碰 `momo-db`。Smoke 通過：三個 app 容器 healthy、`/api/pchome-review/queue?review_status=protected_existing_match` 輸出 `existing_match_conflict`，建議動作為 `compare_existing_identity` 且 `can_auto_execute=false`、Dashboard protected filter / daily / growth / PPT audit HTTP 200；5 分鐘三容器錯誤 log 未見 Traceback / ERROR / CRITICAL。
- 2026-05-24 23:59 CST 狀態：`main` 已推 Gitea 並部署到 188，正式 `/health` 為 `V10.460`。本輪 recreate `momo-app`、`scheduler`、`telegram-bot`；未使用 `--remove-orphans`，未碰 `momo-db`。Smoke 通過：三個 app 容器 healthy、`scripts/check_sales_charts_runtime.js --base-url https://mo.wooo.work --routes /daily_sales,/growth_analysis` 通過，daily/growth 主要 canvas 均有 Chart.js instance、非零資料點與彩色像素；核心頁面 `/daily_sales`、`/growth_analysis`、`/observability/ppt_audit_history`、PChome protected queue API HTTP 200；5 分鐘三容器錯誤 log 未見 Traceback / ERROR / CRITICAL。
- 2026-05-25 08:12 CST 狀態：`main` 已推 Gitea 並部署到 188，正式 `/health` 為 `V10.461`。本輪 recreate `momo-app`、`scheduler`、`telegram-bot`；未使用 `--remove-orphans`，未碰 `momo-db`。Smoke 通過：三個 app 容器 healthy、Dashboard template 已顯示「尚未搜尋」與「尚未進入 PChome 補抓」、Gemini hard disabled 且 24 小時 `ai_calls` 無 Gemini provider、Ollama 順序維持 GCP-A → GCP-B → 111；5 分鐘三容器錯誤 log 未見 Traceback / ERROR / IntegrityError。
- 2026-05-25 08:18 CST 狀態：`main` 已推 Gitea 並部署到 188，正式 `/health` 為 `V10.462`。本輪 recreate `momo-app`、`scheduler`、`telegram-bot`；未使用 `--remove-orphans`，未碰 `momo-db`。Smoke 通過：三個 app 容器 healthy、Dashboard / AI 中樞 / API / 前端 confirm 均改用「PChome 補抓產線 / 補抓未搜尋 / 未搜尋補抓」、Gemini hard disabled 且 24 小時 `ai_calls` 無 Gemini provider、Ollama 順序維持 GCP-A → GCP-B → 111；5 分鐘三容器錯誤 log 未見 Traceback / ERROR / IntegrityError。
- 2026-05-25 08:38 CST 狀態：`main` 已推 Gitea 並部署到 188，正式 `/health` 為 `V10.464`。本輪 recreate `momo-app`、`scheduler`、`telegram-bot`；未使用 `--remove-orphans`，未碰 `momo-db`。Smoke 通過：三個 app 容器 healthy、`/`、`/?filter=pchome_review`、`/daily_sales`、`/growth_analysis`、`/observability/ppt_audit_history`、PChome rescore queue API HTTP 200。DR.WU 三筆 SKU read-only rescore 全數 `gate_pass=3/3`，`--apply-accepted` 後 latest 狀態為 `rescore_accepted_current`、`best_match_score=1.0`、`price_basis=total_price`；整體 latest counts 變為 `true_low_confidence=778`、`rescore_accepted_current=34`。5 分鐘 log 未見 Traceback，但有既有 `[Embed] all hosts failed` 錯誤，需列入下一輪 Ollama embedding 健康檢查。
- 2026-05-25 10:04 CST 狀態：`main` 已推 Gitea 並部署到 188，正式 `/health` 為 `V10.465`。本輪 recreate `momo-app`、`scheduler`、`telegram-bot`；未使用 `--remove-orphans`，未碰 `momo-db`。Smoke 通過：三個 app 容器 healthy、`/`、`/daily_sales`、`/growth_analysis`、`/observability/ppt_audit_history`、PChome rescore queue API HTTP 200；容器內 routing smoke 證明 resolver 回 111 且 `allow_111_fallback=false` 時會改試 GCP-A/GCP-B，輸出 `tried=['http://34.87.90.216:11434','http://34.21.145.224:11434']`；真實短 embedding 在 GCP-A `/api/version` timeout、GCP-B 200 情境下成功回 1024 維向量，耗時 4.59 秒。3 分鐘三容器錯誤 log 未見 Traceback / ERROR / CRITICAL。
- 2026-05-25 12:10 CST 狀態：已部署 `V10.467` 到 188，正式 `/health` 為 `V10.467`。本輪 recreate `momo-app`、`scheduler`、`telegram-bot`；未使用 `--remove-orphans`，未碰 `momo-db`。Smoke 通過：三個 app 容器 healthy、`/`、`/daily_sales`、`/growth_analysis`、`/observability/ppt_audit_history`、PChome rescore queue API HTTP 200。Production pilot 將 9 筆 focused exact total-price SKU 追加為 `rescore_accepted_current`，整體 latest counts 從 `true_low_confidence=802` / `rescore_accepted_current=38` 變為 `true_low_confidence=793` / `rescore_accepted_current=47`；目標 SKU 的 `competitor_prices` 最新 `crawled_at` 仍停在 2026-05-22～2026-05-23，確認本輪未寫正式價差表。已知後續：GCP-A / GCP-B Ollama `/api/version` 目前連線失敗，背景 embedding 正確沒有落 111，但 app/scheduler log 仍會出現 `[Embed] all 2 hosts failed`，需另開 Ollama 健康處理。
- 2026-05-25 12:27 CST 狀態：已部署 `V10.468` 到 188，正式 `/health` 為 `V10.468`。本輪 recreate `momo-app`、`scheduler`、`telegram-bot`；未使用 `--remove-orphans`，未碰 `momo-db`。Smoke 通過：三個 app 容器 healthy、`/`、`/daily_sales`、`/growth_analysis`、`/observability/ppt_audit_history`、PChome review queue API `/api/pchome-review/queue` HTTP 200；容器內 mock smoke 證明背景 embedding 在 GCP-A / GCP-B 全失敗後會開啟 60 秒 failure circuit，第二筆不再重複打兩台 GCP，且不落 111。GCP 維運盤點：GCP-A `22/11434` refused；GCP-B `22` open 但現有 key publickey denied，部署 smoke 時 GCP-B `11434` 已恢復 200、`get_ollama_host()` 選到 GCP-B；111 `/api/version` 可用，但 111 仍不得承接背景 `bge-m3`。
- 2026-05-25 12:39 CST 狀態：已部署 `V10.469` 到 188，正式 `/health` 為 `V10.469`。本輪 recreate `momo-app`、`scheduler`、`telegram-bot`；未使用 `--remove-orphans`，未碰 `momo-db`。Smoke 通過：三個 app 容器 healthy、首頁 / daily / growth / PChome review queue HTTP 200、Gemini hard disabled；`allow_111_fallback=False` 時 GCP-only embedding 全失敗會開啟 failure circuit 並記 WARNING，不再把預期內的背景熔斷打進 ERROR 通道。觀測到 GCP-B `/api/version` 200，但 `/api/embed` 仍可能 15s timeout，下一步需修 GCP-A primary 與 GCP-B runner/model 負載。
- 2026-05-25 12:53 CST 狀態：已部署 `V10.470` 到 188，正式 `/health` 為 `V10.470`。本輪 recreate `momo-app`、`scheduler`、`telegram-bot`；未使用 `--remove-orphans`，未碰 `momo-db`。Smoke 通過：三容器 healthy、host health page HTTP 200 並顯示 Runtime 狀態、scheduler probe 寫入 DB。最新 `host_health_probes`：GCP-A unhealthy（11434 refused）、GCP-B unhealthy（`EmbedProbe ReadTimeout`, `/api/tags` 仍可列出 4 模型）、111 healthy；這補上「HTTP API 活著但模型 runtime 卡住」的假健康監控缺口。
- 2026-05-25 13:38 CST 狀態：已部署 `V10.471` 到 188，正式 `/health` 為 `V10.471`。本輪 recreate `momo-app`、`scheduler`、`telegram-bot`；未使用 `--remove-orphans`，未碰 `momo-db`。Smoke 通過：三容器 healthy、首頁 / daily / growth / host_health / ppt_audit_history / PChome review queue HTTP 200。GCP-B `bge-m3` `/api/embed` 直接實測約 6.4s、7.3s、23.5s，原 `OLLAMA_EMBED_MAX_TIMEOUT=15` 與 host health `OLLAMA_HOST_HEALTH_EMBED_TIMEOUT=8` 會誤殺慢但成功的 embedding；預設改為 30s。正式容器內 embedding smoke 回 1024 維、耗時 10.07s；手動 host health probe 後最新狀態為 GCP-A unhealthy、GCP-B healthy、111 healthy。背景 embedding 路由安全不變：GCP-A → GCP-B，不落 111。
- 2026-05-25 14:10 CST 起，`V10.472` 補 rootless GCP Ollama failover 診斷腳本與 DevOps SOP：`scripts/ops/diagnose_ollama_gcp_failover.sh` 會檢查 direct GCP-A/GCP-B/111、110 proxy `11435/11436` 與 GCP-B `bge-m3` runtime。現況輸出：GCP-A direct `/api/version` failed/refused、GCP-B direct OK、111 OK、110:11435 502、110:11436 OK、GCP-B embed OK；110 無免密 sudo，`ssh gcp-a` 22 refused、`ssh gcp-b` publickey denied，因此 primary 修復需 GCP/SSH 或 110 root 權限。
- 2026-05-25 14:12 CST 起，`V10.473` 進行背景 embedding host_health skip：`allow_111_fallback=false` 的背景 embedding 會讀最近 `host_health_probes`，若 GCP-A/GCP-B runtime 已被標 unhealthy，直接跳過該節點並開 GCP circuit，不等待 30 秒 timeout、不落 111；DB 讀取失敗 fail-open。
- 2026-05-25 14:45 CST 起，`V10.474` 補 PChome near-threshold matcher / feeder 下一階段：HOOOME 白色經典香氛暖燈、Gdesign Aroma Lava 2.0 進 total-price exact；Recipe Box 可撕式水性兒童指甲油保留 identity_review，不自動寫正式價差；Pavaruni 蠟燭 vs 精油與 DASHING DIVA 不同款式仍不放行。known-id refresh 會對 hard-veto 舊候選跑 fresh search recovery；missing known-id 若 fresh search 只有低分候選，也保留 best candidate + diagnostics，不再只記 `refresh_no_result`；正式覆寫保護新增 stronger existing guard。
- 2026-05-25 15:20 CST 起，`V10.475` 補 rescore CLI 與高分錯配防線：audit CLI 預設不再只掃 `strong_exact_spec_match`，避免新版 `focused_exact_*` 理由漏掃；matcher 對香氛暖燈 S/M/L 尺寸差、NITORI 香氛噴霧器型號差直接 hard veto，彩妝色號單邊出現時送 `variant_selection_review`，避免高分但不同 variant 的候選被誤推入 accepted queue。
- 2026-05-25 16:15 CST 起，`V10.476` 補商業條件差防線：即期品、效期/保存期限、盒損、福利品等條件只出現在單側時，matcher 加 `commercial_condition_gap` 並送 `variant_selection_review`，不讓同名但商品狀態不同的候選自動進 accepted queue。
- 2026-05-25 19:20 CST 起，`V10.477` 補高分錯配防線：SPF 數值不同直接 veto，MAKE UP FOR EVER 定妝噴霧 vs 活氧水不同線直接 veto；多款任選對單一款與單側色號改送 `variant_selection_review`，涵蓋私密潔浴露、身體去角質、美體乳液與染眉膏等。
- 2026-05-25 21:05 CST 起，`V10.480` 補 accepted-current 風險樣本防線：rom&nd 零絲絨/果凍唇釉 vs 果汁唇釉多款 listing 直接 `romand_lip_line_conflict` hard veto；Relove 潔淨凝露若傳明酸/淨白活性只出現在單側，保留高分但進 `variant_selection_review`；1990 融燭燈不同設計（歐式可彎 vs 韓風原木底座）直接 `selection1990_wax_lamp_design_conflict` hard veto。
- 2026-05-25 21:25 CST 起，`V10.481` 補 rescore accepted retraction 工具缺口：退回工具會用當前 matcher 重判 latest `rescore_accepted_current`，凡新版已變 `variant_selection_review / low_score_current` 的舊 accepted 會追加退回 `true_low_confidence`，避免人工覆核隊列保留舊版安全閘門放行的候選。Production 已部署 `/health=V10.481`；保守 materialize 15 筆安全 SKU 後再退回 7 筆舊 accepted 變體風險，最新 accepted audit 為 `scanned=89 / gate_pass=89 / still_low=0`。
- 2026-05-25 21:47 CST 起，`V10.482` 補 exact variant-safe 回收：LUSH 櫻之花身體噴霧 200ml、ARTMIS 金縷梅/蔓越莓私密清潔慕斯 250ml、SO NATURAL FIXX 120ml plain 與 Baan 原味/草莓同 catalog，若雙方同品名、同規格且同明確 variant，移除過度保守的 `variant_selection_review` 並進 `exact / total_price / price_alert_exact`；SO NATURAL 經典款/光澤款/霧面款/夏日款 catalog 對單款 120ml 仍維持人工覆核。Production 已部署 `/health=V10.482`，只 materialize 5 筆新增 exact-line SKU 到 `rescore_accepted_current`；latest accepted audit 為 `scanned=94 / gate_pass=94 / still_low=0`，三應用容器 healthy、`momo-db` 未 recreate。
- 2026-05-25 23:03 CST 起，`V10.483` 收斂舊 gate pass 風險：NARS 遮瑕蜜任選、LOREAL 玻尿酸啵啵精華水/液態紫熨斗 vs 水光精華、SEBAMED 洗髮乳任選、Schick 舒綺 2-in-1 型號落差、TAICEND 保護膜 vs 噴霧，現在都會保留高分但加 `variant_selection_review` 與專屬 reason，不再被 rescore 自動送進 accepted queue。Production 已部署 `/health=V10.483`；目標 5 SKU audit `gate_pass=0 / still_low=5`，並用 `--retract-variant-accepted` 退回 4 筆舊 accepted 變體風險，latest accepted audit 為 `scanned=90 / gate_pass=90 / still_low=0`。
- 2026-05-25 12:05 CST 狀態：`main` 已部署到 188，正式 `/health` 為 `V10.467`，待推 Gitea。兩段變更已合併驗證：V10.466 rescore duplicate 改看 latest-state，7 筆 SKU 最新 attempt 全為 `rescore_accepted_current`，`competitor_prices` / `competitor_price_history` 目標計數未變；V10.467 focused exact matcher 在容器內回 `exact / total_price / price_alert_exact`。本輪 recreate `momo-app`、`scheduler`、`telegram-bot`；未使用 `--remove-orphans`，未碰 `momo-db`。Smoke 通過：三容器 healthy、PChome rescore queue API HTTP 200、Gemini 24 小時無 provider 紀錄、Ollama env 順序維持 GCP-A → GCP-B → 111、3 分鐘三容器 log 未見 Traceback / ERROR / CRITICAL / IntegrityError。

## 1. MOMO / PChome 核心比價準確率

- 查正式 `competitor_match_attempts` 最新狀態分布與高量低信心 cohort。
- 以小批次 pilot 處理 `recoverable_low_score`，優先品線：
  - DASHING DIVA
  - aroma / diffuser / essential oil
  - lip / cosmetic variant
  - private-care / body-care
- 2026-05-24 22:10 CST 起，PChome rescore audit 預設對齊 review queue 最新狀態：先取每個 SKU 最新 attempt，再套用 status / reason 篩選；歷史候選回看需明確使用 `--include-historical-candidates`。
- 2026-05-24 22:20 CST 起，matcher replay 先套用 V10.453 安全修正：`EX8` 型號不視為 `x8` 入數，香氛固體凝膠一側泛稱、一側具體香味/No. 款式走 veto；Herbacin 小甘菊護手霜 20ml brandless 可作窄範圍安全回收。
- 2026-05-24 22:42 CST 起，feeder / rescore audit 套用 V10.454 安全閘門：`identity_review` / `manual_review` / `variant_selection_review` 的近門檻候選只能留在覆核，不能由 replay、refresh 或 `accepted_current` 入隊語意自動寫正式 PChome 價差。
- 2026-05-24 22:48 CST 已執行 production rescore 入隊：745 筆 `true_low_confidence` 中先有 2 筆通過舊 gate；V10.454 gate 補上 `variant_selection_review` 排除後，SKU `8884618` KATE 多款任選唇膏已退回最新 `true_low_confidence`，最終只保留 SKU `10922465` Herbacin 小甘菊護手霜 20ml 為 `rescore_accepted_current` 人工覆核 attempt；正式價格表未寫入，Dashboard / competitor intel cache 已清除。
- 2026-05-24 22:44 CST 起，rescore audit 補 `--retract-variant-accepted` 工具化退回路徑；若最新 `rescore_accepted_current` 仍帶 `variant_selection_review`，只追加 `true_low_confidence` attempt，不刪歷史、不寫正式價格表。
- 只新增窄範圍、可解釋 matcher 規則。
- 保留 `MIN_MATCH_SCORE`、`identity_veto`、既有正式候選覆寫保護。
- 驗收：`matched` 有增加、目標 `low_score` 下降、`needs_review` 不異常上升、無明顯跨色號/跨款式/跨劑型錯配。

## 2. 商品列表與人工覆核閉環

- 商品列表不得再大量顯示籠統「待對比」。
- 將狀態拆成：尚未搜尋、價格過期待刷新、近門檻可救回、證據不足、既有強配對保護、已排除、需單位價比較、找不到同款。
- 每筆覆核要顯示候選 PChome 商品、候選價、match score、診斷原因、下一步動作。
- 人工採用 / 否決 / 單位價 / 補搜尋必須能回寫 review queue，並影響 feeder 後續行為。
- 2026-05-25 00:15 CST 起，PChome 補抓操作入口同步收斂為「PChome 補抓產線 / 補抓未搜尋 / 未搜尋補抓」，包含 Dashboard、AI 中樞、前端 confirm 與 API 回覆，不再讓操作入口殘留籠統「待比對」。
- 2026-05-25 00:06 CST 起，尚未進入 PChome 搜尋/補抓的商品列表文案改為「尚未搜尋」與「尚未進入 PChome 補抓」，不再顯示籠統「待比對」，避免和低信心待人工覆核混淆。
- 2026-05-24 23:40 CST 起，`protected_existing_match` 的 review `decision_envelope` 會解析 `existing_match_conflict`，列出既有正式候選、新候選、雙方 score 與 delta；這類案件仍不可自動覆蓋正式價差，但人工覆核、Agent 與 PPT 不再只看到籠統「既有保護」。

## 2.1 近門檻 / 高信心待審 matcher 補強

- 2026-05-25 08:30 CST 起，rescore audit 支援 `--sku` repeatable 精準篩選；production pilot 可只指定 3-10 個 SKU 執行 read-only audit 或 `--apply-accepted`，避免寬範圍掃描誤把不同 cohort 混在同一次驗證。
- 2026-05-25 08:25 CST 起，`DR.WU / DR WU / DRWU / 達爾膚` 視為同一品牌 alias；正式樣本中的 DR.WU 玻尿酸保濕精華乳 50ML、2入組與杏仁酸亮白煥膚精華 18% 30ML 2入組，在不調整全域門檻下可由 brandless identity review 回到 exact total-price lane。
- 2026-05-25 08:36 CST production pilot：SKU `10362820`、`10653216`、`10653329` 已從 `true_low_confidence` materialize 為 `rescore_accepted_current`，只進人工覆核隊列，不寫 `competitor_prices`。
- 2026-05-25 11:55 CST 起，rescore audit duplicate 判斷只看最新 attempt；若歷史已有 accepted 但後續 crawler 又追加低信心列，可重新 materialize 成最新 `rescore_accepted_current`。Production pilot 已將 SKU `14756069`、`11159042`、`13842560`、`8394210`、`15192547`、`10509765`、`10603780` 入人工覆核隊列；正式 `competitor_prices` / `competitor_price_history` 未寫入或改變。
- 2026-05-25 12:20 CST 起，matcher 新增 `focused_exact_total_price_safe` 窄範圍通道；目前只覆蓋 3W CLINIC 粉底液 2入、花美水凝膠 3支、The Ordinary 咖啡因 EGCG 30ml、KUSSEN 屁屁膏 3入、Bone 擴香禮盒、1990 融燭燈白色款與 CANMAKE 淚袋盤等已確認同款樣本。這讓高信心 `exact/manual_review` 能轉為 `exact/total_price` 供 rescore pilot 入人工覆核；DASHING DIVA、唇彩、香味、色號/款式敏感商品仍不放行。
- 2026-05-25 12:25 CST production pilot：SKU `6101639`、`10074951`、`7760902`、`TP00074980000005`、`14774766`、`10142589`、`10262470`、`10262471`、`11308520` 已從 `true_low_confidence` materialize 為 `rescore_accepted_current`，全數 `exact/total_price/price_alert_exact` 且理由含 `focused_exact_total_price_safe`。SKU `6101784` 因「即期品」商業條件不同，刻意保留在 `true_low_confidence`，不納入本輪自動入隊。
- 2026-05-25 14:45 CST 起，matcher 擴充至香氛/精油近門檻安全 cohort：HOOOME 白色經典香氛暖燈與 Gdesign Aroma Lava 2.0 可進 `exact/total_price/price_alert_exact`；Recipe Box 可撕式水性兒童指甲油只進 `identity_review`，因兒童指甲油仍可能藏色款/款式。DASHING DIVA 與 Pavaruni cross-type 負例已補測試，避免跨款式、跨劑型誤配。
- 2026-05-25 15:20 CST 起，新增三個正式觀察到的高分負例防線：PRAY 守夜人暖燈 L vs S、NITORI 香氛噴霧器 5510 vs YX168、LA MER 氣墊粉霜通用 listing vs `11 Rosy Ivory` 色號。前兩者 hard veto，後者保留高分但不進 accepted queue。
- 2026-05-25 16:15 CST 起，新增商業條件差負例：KAMERIA 足膜、3W CLINIC 粉底液、Sisley 全能乳液等若一側標示即期/效期/盒損，仍可顯示高相似度，但只進 identity review，不自動入 accepted queue。
- 2026-05-25 19:20 CST 起，新增高分負例：Jealousness SPF25 vs SPF50、MAKE UP FOR EVER 超光肌控油定妝噴霧 vs 超光肌活氧水、rom&nd 染眉膏通用 listing vs `03 摩登米`、Lactacyd 多款潔浴露 vs 單一亮肌柔滑、我的心機多款身體去角質 vs 單一香型。前兩者 hard veto，其餘進 identity review。
- 2026-05-25 20:05 CST 起，新增高分錯配 / catalog 變體防線：AUS LIFE 檸檬草 vs 茶樹滾珠精油、NOW 椰子油膏 vs 乳木果油、港香蘭漢本 vs 艾魔菈爽身粉改為 hard veto；多色 / 多香 / 數字區間 catalog 對單一款式（KATE 粉餅盒、植村秀眉筆、PERIPERA 01~07 眼線膠筆、Jo Malone 車用擴香蕊芯等）只進 `variant_selection_review`。
- 2026-05-25 20:35 CST 起，依 production audit 續補二階風險：同規格但一側為潔膚露、一側為修護乳/乳液直接 `cleanser_lotion_line_conflict` hard veto；私密防護慕絲多款可選 vs 單一香型、滋養霜單側清爽型只進 `variant_selection_review`。
- 2026-05-25 21:05 CST 起，依 accepted-current 二次抽樣續補三類風險：rom&nd 唇釉不同品線不可互收；Relove 潔淨凝露傳明酸/淨白變體不可自動 accepted；1990 融燭燈同色但不同燈座/結構不可互收。下一步先部署 V10.480，再回查 accepted-current 是否仍有上述 4 筆風險 SKU。
- 2026-05-25 21:25 CST 起，accepted queue 清潔不再只靠舊 `diagnostic_codes`：`--retract-variant-accepted` 改為先抓 latest accepted，再用當前 matcher 判斷是否需要退回。這能清掉 V10.480 後才被新規則判為 `variant_selection_review` 的舊 accepted。正式最新狀態：`true_low_confidence=751`、`rescore_accepted_current=89`、`identity_veto=3994`、`matched=1570`、`unit_comparable=379`。
- 2026-05-25 23:45 CST 起，`V10.484` 拆分 manual gate exact 與型錄風險：POWERMAN 男性私密養護液 30ml、PHYSIOGEL AI 冰鎮精華露 200ml 2入、TS6 緊彈水嫩凝膠 40g、DERMA 寶寶洗髮沐浴露 150/500ml、Clarins 黃金亮眼萃 20ml、Cetaphil 長效潤膚乳 237/473ml 等明確同款可走 `exact / total_price / price_alert_exact`；COCODOR 大豆蠟燭單側多款任選保留 `variant_selection_review`，Pavaruni 雙側 20 香味蠟燭保持 total-price exact。測試：`tests/test_marketplace_product_matcher.py`、`tests/test_competitor_match_attempts_persistence.py`、`tests/test_competitor_match_attempt_rescore_audit.py` 通過。
- 2026-05-25 23:55 CST 起，`V10.485` 補 NITORI 香氛噴霧器短型號防線：near-threshold read-only pilot 中唯一 gate pass 為 5510 vs J82 LBR，已判定不該入隊；matcher 將 `J82` 這類短英數型號納入 NITORI diffuser model conflict，與 5510 / YX168 等不同型號一樣 hard veto。Production 已部署 `/health=V10.485`；120 筆 near-threshold audit 由 `gate_pass=1` 變 `gate_pass=0`，accepted audit `scanned=89 / gate_pass=89 / still_low=0`。
- 2026-05-29 起，`V10.486` 補 PChome near-threshold 風險邊界：NEW DIRECTIONS 甜杏仁油 vs 酪梨油直接 hard veto；COCODOR 經典擴香瓶多款任選、KAMERIA 足膜任選三款、Hakugen 白元入浴劑橘盒/綠盒不同變體都保留 `variant_selection_review`，不進可採用 gate。Production 已部署 `/health=V10.486`；240 筆 near-threshold audit `gate_pass 83→79`、`identity_veto 0→1`、`still_low 157→160`。
- 2026-05-29 起，`V10.488` 新增市場情報 MCP Fetch Run Receipt 安全預覽 gate，只審核操作員 dry-run receipt，不執行 CLI、不抓外站、不寫 DB。
- 2026-05-29 起，`V10.489` 補 PChome 低分同款人工覆核回收與 gate-pass 風險邊界：TS6 超美白香氛誘霜 120g/ml、W 修護保養蝸牛特潤修護面膜 6 片、Derma 大地 Eco 植萃護膚油 2 入，從低信心升成 `identity_review` 候選；Clarins 輕盈美體護理油 vs 身體調和護理油、台塑生醫嬰兒沐浴/洗髮組合數量反轉、isLeaf 私密慕絲香型數量不一致改 hard veto；HOOOME 大理石暖燈 vs 泛稱經典款只留 `variant_selection_review`，不進 total-price accepted。Production 已部署 `/health=V10.489`；500 筆 read-only audit 由 V10.486 基線 `gate_pass=129 / identity_veto=1 / still_low=370` 收斂為 `gate_pass=124 / identity_veto=4 / still_low=372`，三應用容器 healthy、`momo-db` 未 recreate。
- 2026-05-31 起，`V10.490` 補 ElephantAlpha / OpenClaw 舊策略 action 相容：正式日誌觀察到 `agent=openclaw action=generate_market_strategy` 被當未知步驟丟錯；此類 OpenClaw strategy 產生步驟已定義為 advisory skipped，只記 warning，不觸發 circuit breaker、不執行外部策略、不影響價格行動。測試覆蓋 `generate_market_strategy` 與 `generate_resource_optimization_strategy`，未知 action 仍維持 fail-fast。
- 2026-05-31 起，`V10.491` 新增市場情報 MCP Fetch Result Parser Review gate：在 receipt gate 後只審核操作員 shell parser 貼回的結構化摘要，對齊 source/path、公開 URL、候選必要欄位、小批次上限、raw HTML/secret/side-effect 風險；仍不讀 artifact、不執行 CLI、不連外、不寫 DB、不掛 scheduler。
- 2026-05-31 起，`V10.492` 收緊 PChome 近門檻自動回刷：`run_retryable_candidate_revalidation()` 只回刷 `recoverable_low_score` 與 legacy `low_score / refresh_low_score`，且 SQL 端要求 `hard_veto=false`、`comparison_mode=exact_identity`、diagnostic reasons 命中同品線/identity anchor；`identity_veto`、`unit_comparable`、`true_low_confidence` 不再進每日自動回刷隊列，需等待新證據或人工處理。
- 2026-05-31 起，`V10.493` 新增市場情報 MCP Fetch Candidate Handoff Review gate：在 parser review 通過後只審核候選交接包，要求 source/candidate key 完全對齊、queue policy 維持 manual preview、小批次上限與操作員無寫入/無連外/無排程確認；仍不建立 queue、不寫 DB、不讀 artifact、不連外、不掛 scheduler。
- 2026-05-31 起，`V10.494` 新增市場情報 MCP Fetch Candidate Queue Review gate：在 handoff review 通過後只審核人工 queue review 草案，要求候選 key 完全對齊、review_state 只停在 `needs_review`、allowed actions 限人工操作、queue_write_status 維持 `not_persisted`；仍不建立 queue、不更新 review_state、不寫 DB、不連外、不掛 scheduler。
- 2026-05-31 起，`V10.495` 新增市場情報 MCP Fetch Candidate Queue Writer Preflight gate：在 queue review 通過後只審核 writer preflight 草案，要求 target table、write mode、dedupe strategy、insert columns、payload rows 與候選 key 完全對齊；仍不開 DB、不執行 CLI、不建立 queue、不更新 review_state、不寫 DB、不連外、不掛 scheduler。
- 2026-05-31 起，`V10.496` 新增市場情報 MCP Fetch Candidate Queue Writer CLI Review gate：在 writer preflight 通過後只審核 CLI review 草案，要求 script path、target table、preflight id、row count、candidate/dedupe keys 與 read-only command argv 對齊；仍不執行 CLI、不讀 approval token、不寫檔、不開 DB、不寫 queue、不掛 scheduler。
- 2026-05-31 起，`V10.497` 新增市場情報 MCP Fetch Candidate Queue Writer Run Package Review gate：在 CLI review 通過後只審核 operator run package 草案，要求 artifact manifest、operator shell command sequence、package identity、candidate/dedupe keys 與 CLI review 對齊；仍不產檔、不讀 approval token、不執行 CLI、不開 DB、不寫 queue、不掛 scheduler，只放行到 run readiness review。
- 2026-05-31 起，`V10.498` 新增市場情報 MCP Fetch Candidate Queue Writer Run Readiness gate：在 run package review 通過後只審核 operator readiness 證據，要求 run readiness artifact、reviewed sample、備份、read-only preflight 與 post-write smoke 路徑安全，並確認 CLI-only、approval token shell-only、無 API/DB/file/scheduler 副作用；仍不產檔、不讀 token、不執行 CLI、不開 DB、不寫 queue、不掛 scheduler，只放行到後續 run receipt review。
- 2026-05-31 起，`V10.499` 新增市場情報 MCP Fetch Candidate Queue Writer Run Receipt Review gate：在 run readiness 通過後只審核操作員 shell writer run 的 receipt 摘要，要求 readiness linkage、run package id、候選/dedupe keys、writer output、post-write smoke、backup path 與 operator confirmation 對齊；仍不讀 receipt 原文、不讀 token、不執行 CLI、不開 DB、不寫 queue、不做 post-write query、不掛 scheduler，只放行到 closeout review。
- 2026-05-31 起，`V10.500` 新增市場情報 MCP Fetch Candidate Queue Writer Run Closeout Review gate：在 receipt review 通過後只審核 operator closeout 摘要，要求 receipt linkage、closeout artifact、receipt review artifact、post-closeout inventory plan、writer output / post-write smoke / backup manifest、rollback note 與 operator confirmation 對齊；仍不讀 receipt 原文、不讀 token、不執行 CLI、不開 DB、不寫 queue、不做 post-closeout query、不掛 scheduler，只放行到 read-only post-closeout inventory review。
- 2026-05-31 起，`V10.501` 新增市場情報 MCP Fetch Candidate Queue Writer Post-Closeout Inventory Review gate：在 closeout review 通過後只審核 operator live inventory read-only 摘要，要求 closeout linkage、row count、inventory artifact、closeout review artifact、read-only query result、missing/duplicate rows 與 operator confirmation 對齊；仍不讀 token、不執行 CLI、不開 DB、不寫 queue、不做 inventory query、不掛 scheduler，只放行到 candidate queue review handoff。
- 2026-05-31 起，`V10.502` 修正 AiderHeal 自動修復診斷鏈：先檢查 ADR-020 檔案白名單再執行 110 preflight，`tests/` finding 會明確略過而不誤報 repo preflight；Code Review 完成通知會把全數不在白名單的 finding 標成需人工處理，不再宣稱已觸發 AiderHeal；白名單放行 `services/routes/database` 子目錄 Python 檔，preflight 通知帶遠端錯誤細節，健康檢查接受 `/health` 回 `healthy`。
- 2026-05-31 起，`V10.503` 新增市場情報 MCP Fetch Candidate Queue Writer Review Handoff gate：在 post-closeout inventory review 通過後只審核 operator candidate queue review handoff 摘要，要求 inventory linkage、handoff identity、target table、row count、artifact paths、review contract、forbidden API actions 與 operator confirmation 對齊；仍不讀 token、不執行 CLI、不開 DB、不寫 queue、不更新 review_state、不掛 scheduler，只放行到人工 candidate queue review。
- 2026-05-31 起，`V10.504` 新增市場情報 MCP Fetch Candidate Queue Writer Review Inventory gate：在 writer review handoff 通過後只審核 operator read-only candidate queue inventory 摘要，要求 handoff identity、target table、row count、dedupe keys、review_state、artifact paths、read-only query result、missing/duplicate rows 與 operator confirmation 對齊；仍不讀 token、不執行 CLI、不開 DB、不寫 queue、不更新 review_state、不做 inventory query、不掛 scheduler，只放行到後續人工 candidate queue review。
- 2026-05-31 起，`V10.505` 新增市場情報 MCP Fetch Candidate Queue Writer Review Decision gate：在 review inventory 通過後只審核 operator candidate queue review decision 摘要，要求 decision identity、target table、row count、dedupe keys、`needs_review` 現態、允許決策、evidence refs、matched row exact-identity/variant/overwrite guard 與 operator confirmation 對齊；仍不讀 token、不執行 CLI、不開 DB、不寫 decision record、不更新 review_state、不寫 match result、不補 queue、不掛 scheduler，只放行到 decision approval / writer preflight 設計。
- 2026-05-31 起，`V10.506` 新增市場情報 MCP Fetch Candidate Queue Writer Review Decision Approval gate：在 review decision 通過後只審核 operator human approval 摘要，要求 decision linkage、approval identity、target table、row count、dedupe keys、`approved_for_writer_preflight` approval result、decision/approval evidence refs、artifact paths、matched row exact-identity/variant/overwrite guard 與 operator confirmation 對齊；仍不讀 token、不執行 CLI、不開 DB、不寫 approval record、不寫 decision record、不更新 review_state、不寫 match result、不補 queue、不掛 scheduler，只放行到後續 writer preflight 設計。
- 2026-05-31 起，`V10.509` 新增市場情報 MCP Fetch Candidate Queue Writer Review Decision Approval Writer Preflight gate：在 human approval 通過後只審核 operator writer preflight 摘要，要求 approval linkage、writer_preflight_id、target operation、row count、dedupe keys、approved decision 到 target review_state 的逐列映射、decision/approval/preflight evidence refs、matched row exact-identity/variant/overwrite guard 與 operator boundary；仍不讀 token、不執行 CLI、不開 DB、不寫 preflight/approval/decision/match、不更新 review_state、不補 queue、不掛 scheduler，只放行到後續 CLI review / run package 設計。
- 2026-06-01 起，`V10.566` 新增市場情報 Professional Source Governance gate：將 robots/REP、sitemap/lastmod、JSON-LD / schema.org structured data、canonical URL、rate limit、公開資料邊界、provenance、snapshot hash 與 idempotency key 納入 source contract，並接上 `/api/market_intel/mcp_professional_source_governance`、UI preview panel、deployment readiness check 與 production smoke target；仍不抓外站、不讀 robots/sitemap、不開 DB、不寫檔、不掛 scheduler。
- 2026-06-04 起，`V10.579` 補 PChome 高信心 total-price safe family：SAB 私密防護舒緩噴霧 30ml、Herbacin 小甘菊 20ml 護手霜在同款式同規格且無 variant/commercial gap 時可進 `exact / total_price / price_alert_exact`；跨款式反測仍擋在 review，`MIN_MATCH_SCORE` 不變。同版將 Code Review GCP-B secondary timeout 收斂到 25 秒，GCP-A/GCP-B 都慢時更快回 local degraded。
- 2026-06-04 起，`V10.580` 補 PChome 重複單品組 total-price 窄門與核心油種 veto：同品牌、同入數、同基礎規格且名稱高度對齊的重複單品組（例如 Bioneo 150ml x2、Cetaphil 150ml x2、Avene 300ml x4、Schick 2+1 入）可進 `exact / total_price / price_alert_exact`；正式部署前估算 213 筆高分 `true_low_confidence` 中僅 7 筆會被自動寫入。NEW DIRECTIONS 甜杏仁油 vs 杏桃核仁油改 hard veto，Paula's Choice 缺 30ml 規格的雙入組仍留 manual review；`MIN_MATCH_SCORE` 不變。
- 2026-06-04 起，`V10.581` 將重複單品組安全線接進 retryable revalidation：只收 `true_low_confidence` 中舊診斷為 `match_type=exact / price_basis=manual_review`、無 commercial / variant / count / bundle 等阻擋，且命中具名安全商品線的候選；最後仍由最新版 matcher 與 overwrite protection 決定是否寫正式比價。
- 2026-06-04 起，`V10.582` 補 PChome 比價通知專業分級與 Nick 副標身份證據：NemoTron 決策信封保留 MOMO / PChome 價格、價差與 7 日業績變化；Telegram decision envelope 將 `exact / total_price / price_alert_exact` 等工程路徑翻成直接價格威脅、單位價覆核、身份覆核或壓制告警，並把「單位價/身份未確認不得用總價直接告警」寫進操作邊界。PChome `Nick` 副標會以 `match_name` 參與 matcher，比價可用到容量、入數、濃度資訊，但不改 UI/DB 正式顯示品名。
- 2026-06-04 起，`V10.583` 補 Paula's Choice 身體乳 PChome Nick 具名 alignment：`2%水楊酸身體乳210ml二入` 可和 PChome `Nick` 補出的 `水楊酸身體乳雙入組 / 210ml x2` 對齊並進 safe total-price；此版不泛用放寬中文入數，`118ml二入組(金蓋限定版)` 對上 PChome 效期品仍維持 manual review。
- 2026-06-04 起，`V10.584` 補 PChome Nick 清洗與 stale recovery 單品窄門：Nick 先去 HTML、行銷星號與重複品名，避免同一商品副標讓規格被重複計數；新增 NIVEA 妮維雅霜 100ml、Schick 舒綺敏感肌除毛刀片 3 入、TS6 沁涼潔淨慕斯 100g 具名 exact total-price alignment。IBL 沐浴/洗髮用途落差、唇色目錄款、效期/限定版差異仍留 review。
- 2026-06-05 起，`V10.601` 收斂 Gemini / 111 治理：正式 `ai_calls` 近 24 小時與近 7 天沒有 Gemini provider；舊 K8s/n8n/scripts/docs/Google Drive token 檔中的已知實密鑰改占位符並補全 repo secret 掃描測試；OpenClaw 日/週/月/Meta 長報告改為 GCP-A/GCP-B only，不再讓 `openclaw_meta` 落到 111。
- 2026-06-05 起，`V10.600` 收斂 AI Intelligence 競品表前台標籤：PChome 競品 footer 不再顯示 TTL / 比對門檻等工程參數，改顯示已通過身份比對的使用者語意；已知 matcher tag 轉成中文 badge，未知 tag 隱藏，避免 raw internal tag 出現在營運畫面。
- 2026-06-05 起，`V10.599` 補全站巡檢降載與前端工作溝通隔離：CONSTITUTION 新增第 14.2 條，禁止把施工紀錄、版本發布說明、Codex/Claude 評估、推版語氣放進使用者可見頁面；市場情報停用頁改為輕量產品狀態頁；ICAIM dashboard API 增加短快取、stale fallback、5 秒 PostgreSQL statement timeout、LATERAL 最新價與最新 PChome identity row 查詢，避免全站巡檢與使用者開頁時被重查詢拖慢。
- 2026-06-04 起，`V10.578` 修正 Code Review deterministic scan 的 timeout 判定，多行 `requests.*(... timeout=...)` 不再被誤報為未設定 timeout。
- 2026-06-04 起，`V10.577` Code Review OpenClaw 會在 explicit Ollama host generate 前先做短 `/api/version` preflight；GCP-A 不通時快速跳 GCP-B，避免 15 秒 timeout 後才降級，且仍不呼叫 Gemini / 111。
- 2026-06-04 起，`V10.576` 修正 GCP-only Ollama retry：caller 禁用 111 fallback 時，resolver 若回到 111 會改試 GCP-A/GCP-B allowlist，不再讓 Hermes / Code Review 類任務因 resolver 快取到 111 而 `all 0 hosts failed`。
- 2026-06-04 起，`V10.575` 拆分 PChome 型錄可比覆核 lane：`catalog_comparable` 會依 diagnostic evidence 分成選項/色號、單位/入數與身份採用三條人工處理路徑，Dashboard、decision envelope、coverage 與 Webcrumbs host data 使用同一套統計與 HITL guardrail。
- 2026-06-03 起，`V10.574` 新增市場情報 Source Governance → Fetch Target bridge：`/api/market_intel/mcp_fetch_target_source_governance_review` 交叉審核 Professional Source Governance 與 MCP Fetch Target Review，要求 target `platform_code/source_key` 全部命中已治理 source contract；仍不抓外站、不讀 robots/sitemap、不開 DB、不寫檔、不執行 CLI、不掛 scheduler，只放行到後續人工 fetch run package review。
- 2026-06-02 起，`V10.567` 將 MCP 市場洞察 fallback 收斂為 GCP-A / GCP-B only，不再讓 111 承接非即時市場分析長任務；預設 timeout 25 秒、`num_predict` 500，GCP 不可用時直接保守降級，避免 Elephant Alpha 60 秒 timeout 與 111 負載尖峰。
- 2026-06-02 起，`V10.568` 將價格類 `decision_envelope` 的 Telegram 直送訊息改為專業 brief：標的、價格證據、比對證據、人工下一步四段式；review queue 信封 subject 同步帶 `momo_price` / `competitor_price`，讓 Telegram、PPT、Webcrumbs 與 AI 摘要共用價格證據。
- 2026-06-02 起，`V10.569` 將 Webcrumbs host data 串到 `summarize_review_decision_envelopes()`，payload 新增 `reviewDecisionBrief` 與 review queue / HITL / auto-execute-blocked metadata；共用 UI runtime 讀同一份 PChome 覆核信封摘要，仍只讀 DB、不呼叫 LLM、不抓外站、不寫資料。
- 2026-06-15 起，`V10.605` 修正 PChome 後台業績 Excel 匯入韌性：auto import 會掃所有 worksheet / 表頭列並選擇 `即時業績明細` 類明細 sheet，欄位或日期不合格的檔案會移至 Drive `匯入失敗` 避免 30 分鐘重複告警；同版修復 scheduler 容器缺 `pg_dump` 的備份告警。Production 匯入任務 #54 成功寫入 12,460 筆，`daily_sales_snapshot` 與 `realtime_sales_monthly` 最新日期皆為 2026-06-14；資料新鮮度 probe 降為 `gap=1 / info / notified=false`，daily/growth chart runtime guard 通過。
- 2026-06-15 起，`V10.606` 正名為「PChome 業績成長自動化作戰系統」並新增只讀 `/api/ai/pchome-growth/opportunities`：作戰清單以 PChome 後台業績為主、MOMO 作為外部價格參考，蝦皮與酷澎先暫停且不進告警。正式只讀盤點確認 `daily_sales_snapshot."商品ID"` 與 `competitor_prices.competitor_product_id` 直接重疊為 0，因此第一版不硬接 ID；無可驗證對應時只輸出「先補商品對應」任務。AI 競情頁同步改成白話營運文案，避免把工程術語直接呈現給使用者。

## 3. 12 Agent 決策信封整合

- `decision_envelope` 已接到 NemoTron 價格告警與人工覆核，下一步要讓 OpenClaw、ElephantAlpha、PPT QA 與 review queue 共用同一份 evidence contract。
- 2026-05-24 22:44 CST 起，EventRouter 對已附 `decision_envelope` 的事件直接渲染證據模板，不呼叫 L1/L2 AI handler；這讓 NemoTron 價格告警、人工覆核與後續 Agent 共用同一份 SKU / PChome / evidence / guardrails，不再二次生成摘要。
- 2026-05-24 23:00 CST 起，`fetch_competitor_review_queue()`、`fetch_competitor_review_queue_page()` 與 `/api/pchome-review/queue` 每筆候選也帶 `decision_envelope`，包含 SKU/PChome 標的、match evidence、人工下一步、預期價差與不可自動寫正式價差的 guardrails；Dashboard、Agent、Telegram、PPT 後續共用此 contract。
- 2026-05-24 23:15 CST 起，Dashboard 覆核卡與 PChome 覆核 Excel 匯出也顯示/輸出信封摘要、資料品質、HITL、trace、自動執行阻擋原因與證據摘要；下載檔不得丟失 guardrails。
- 2026-05-24 23:25 CST 起，OpenClaw 週報/日報/月報與 competitor PPT 使用 `summarize_review_decision_envelopes()` 的同一份 HITL 信封摘要，不再手寫 attempt_status 統計或自行翻譯覆核狀態。
- 2026-05-24 23:40 CST 起，`compare_existing_identity` 成為 `protected_existing_match` 的明確建議動作；Agent 只能提示「比較既有正式候選與新候選」，不得因新候選分數較高自動寫正式價差。
- 2026-05-24 23:55 CST 起，ElephantAlpha `resource_optimization` / `ea_escalation` 都必須帶 deterministic `decision_envelope`；Telegram 按鈕 callback 使用 `decision_id`，證據只允許 action_plans、CPU 實測、hygiene 與 trigger trace。
- 告警不得再輸出空泛「預期效益」；必須帶資料品質、證據來源、HITL 邊界與 trace id。
- Agent 建議只能輔助排序與分析，不得繞過 matcher / feeder / review service 寫正式價格。

## 3.1 Ollama / Embedding 健康

- 2026-05-25 08:48 CST 起，`OllamaService.generate_embedding(..., allow_111_fallback=False)` 若 resolver 回 111，會強制改試尚未嘗試的 GCP-A/GCP-B，不再讓背景 embedding 在 111 disabled 情境直接退出或只試單台 GCP-B；111 仍不承接背景 `bge-m3`。
- 2026-05-25 12:27 CST 起，背景 embedding 在 GCP-A/GCP-B 全掛時開啟短暫 failure circuit；這是降載保護，不代表 primary 已恢復。部署 smoke 時 GCP-B `/api/version` 已恢復 200，下一步仍需恢復 GCP-A Ollama 或更新 110 的可用 SSH/GCP 操作憑證。
- 2026-05-25 12:37 CST 起，背景 embedding GCP-only failure circuit 改用 WARNING 記錄，避免可預期降級污染 ERROR 告警通道。
- 2026-05-25 13:35 CST 起，GCP-B `bge-m3` 實測 P95 波動已超過 15s，背景 embedding / host health model probe timeout 預設改 30s；若 30s 仍常 timeout，需進一步處理 GCP-B runner/CPU/模型併發，而不是再把 111 納入背景任務。
- 2026-05-25 14:10 CST 起，GCP-A refused 已明確歸類為 infra blocker；應用層不得改成 111 背景 fallback，也不得把 110:11435 502 當成 momo-app 故障。背景 embedding 可依 `host_health_probes` 跳過近期 unhealthy GCP host，但查 DB 必須 fail-open。

## 4. 業績分析資料與圖表修復

- 修正即時業績匯入 `snapshot_date text = date` 類型錯誤。
- PChome 後台業績匯出前半段仍需自動化：優先確認 PChome 後台是否支援排程寄信 / Email 附件 / FTP / API；若無，改做 110 或獨立 worker 的受控 browser 下載，再把檔案放進 Google Drive `當日業績匯入/`。
- `/daily_sales`、`/growth_analysis` 圖表不得空白；需保留原本圖表並升級成更專業的呈現。
- 圖表需通過 runtime nonblank canvas 檢查與手機版 responsive。
- daily/growth/PPT 必須共用 `competitor_intel_repository` 的比價資料出口，避免價差方向或統計口徑分裂。
- 2026-05-24 23:55 CST 起，daily/growth chart 判斷不再只看 series 長度；若序列全 0，顯示 chart-empty 狀態而不是畫只有座標軸的假圖。正式 smoke 需跑 `scripts/check_sales_charts_runtime.js` 確認主要 canvas 非空。

## 5. PPT 視覺 QA 與自動簡報產線

- 每日、每週、每月、每季、半年、年度簡報需依排程產出。
- 每次產出與視覺 QA 結果必須完整寫入 DB。
- `/observability/ppt_audit_history` 必須清楚顯示 runtime 狀態、產出狀態、視覺 QA、問題追蹤與可預覽檔案。
- PPTX / PDF 預覽需可站內直接開啟，不能只下載。
- 2026-06-06 起，`V10.604` 修正定期簡報長期漏產：根因為 `schedule.run_pending()` 同步執行，20:30/20:40/20:50 精準時段會被 feeder / AI 長任務卡過且不自動 replay。新增每 10 分鐘 missed-run catch-up、scheduler 背景化補跑、排程型市場情報與價格甜蜜點快速 fallback；production 已補齊 `daily`、`market_intel`、`price_elasticity`，catch-up plan 顯示 daily/weekly/monthly/quarterly/half_yearly/annual 全數 ready，`/observability/ppt_audit_history` 可看到新檔與預覽入口。

## 6. 外部 BI / 協作入口

- `/metabase` 不可空白，需顯示可診斷 bridge 狀態或可用替代入口。
- `/grist` / 資料協作連結不得連到其他專案站。
- 側欄與 topbar 外部工具入口要統一走 momo-pro bridge route。

## 7. AI 觀測台與全站 UI/UX

- 10 個 AI 觀測台頁面必須符合新版字體、字級、暖墨色、焦糖 accent、點陣視覺與 responsive 規範。
- 全站主要頁面需通過 desktop / mobile overflow guard。
- 表格與圖表只允許在局部容器橫向滾動，不可造成整頁無限延伸。

## 8. 效能與可觀測性

- 持續降低 `/daily_sales`、`/growth_analysis`、商品看板、PChome queue、PPT audit 首屏 TTFB。
- 避免 worker cold start 重查重算；必要時使用共享快取與指紋失效。
- 111 fallback 只作最後救急；持續監控 GCP-A / GCP-B / 111 用量與 circuit breaker。

## 9. 每輪收尾

- Focused tests → full pytest 或合理範圍回歸 → production smoke。
- 更新 SOT / memory / TODO。
- 推 Gitea，正式部署，確認 `/health` 版本。
- 記錄未完成與下一輪入口。

## 10. 2026-06-15 V10.607 外部市場來源正規化

- 新增 `external_market_sources` / `external_offers`，作為 MOMO、未來蝦皮、未來酷澎、供應商 API 與手動 CSV 的共同資料入口。
- `/api/ai/pchome-growth/source-contract` 提供只讀來源狀態與欄位 contract；UI 只顯示白話狀態，例如「正在使用」「先暫停」「可用資料」。
- MOMO 目前先橋接既有已確認同款的比價快取；蝦皮與酷澎只保留 contract，預設暫停、不進告警。
- 下一步：做手動 CSV 匯入 dry-run 與外部報價品質檢查頁，讓未來無論官方 API 或 provider API 都能先經過同一套品質門檻。

## 11. 2026-06-15 V10.608 外部報價 CSV 預檢

- 新增 `/api/ai/pchome-growth/external-offers/csv-dry-run`，接受 CSV 檔案或貼上的 CSV 文字，只做預檢、不寫 DB。
- AI 情報頁新增「外部報價預檢」區塊，顯示可使用、待確認、不能使用；用字保持白話，不顯示工程欄位給一般使用者。
- 預檢支援中文表頭，例如「資料來源、外部商品ID、商品名稱、售價、資料時間、取得方式、PChome商品ID、同款狀態、資料可信度」。
- CSV 預檢是備援入口，不是日常主流程。

## 12. 2026-06-15 V10.609 外部報價自動同步

- 新增 `sync_legacy_momo_reference_offers()`，自動把已確認同款的既有比價快取同步進 `external_offers`。
- 新增 `run_external_offer_sync_task`，每 4 小時自動執行；排在 competitor feeder 後，同步 MOMO 外部價格參考資料層。
- CSV 保留為 API / crawler / provider 故障時的救援預檢；日常目標是自動抓、自動同步、自動進作戰清單。

## 13. 2026-06-16 V10.610 PChome 作戰清單優先讀新資料層

- `/api/ai/pchome-growth/opportunities` 已改成優先讀 `external_offers`，只有缺資料時才 fallback 舊 `competitor_prices`。
- `external_offers.raw_payload_json` 會保留舊比價快取中的 PChome 公開價，讓新資料層仍可算出 MOMO / PChome 價差。
- API stats 新增 `external_data_source_counts`，可看到「自動同步資料層」與「舊比價快取」各有多少筆。
- 下一步：把其他比價報表與 AI 告警逐步改讀 `external_offers`，讓 `competitor_prices` 降為 bridge/cache。

## 14. 2026-06-16 V10.611 作戰入口與資料來源可見化

- `/ai_intelligence` 是 PChome 業績成長自動化作戰系統的營運主入口；V10.617 起舊「今日作戰入口」已改為「今日重點總覽」，首屏需先顯示下一步與今日處理清單，不再把備援 CSV 放在主要流程前段。
- PChome 成長作戰區塊會依 API stats 顯示今日優先動作，例如先補商品對應、先處理可直接比價商品，避免使用者只看到數字不知道下一步。
- 同區塊新增資料來源摘要，直接顯示「自動同步資料層」或「舊比價快取」各有多少筆，方便確認 V10.610 新資料層是否真的被作戰清單採用。
- CSV 預檢在 UI 文案上維持備援定位；日常主流程仍是自動同步外部報價。

## 15. 2026-06-16 V10.612 MOMO 外部價格參考優先讀新資料層

- `/api/ai/icaim/dashboard` 的「MOMO 外部價格參考」已改為優先使用 `external_offers`，同一 MOMO SKU 若有自動同步資料就不再先讀舊 `competitor_prices`。
- 表格 stats 新增 `competitor_data_source_counts`，前端 footer 顯示「自動同步資料層 / 舊比價快取」各幾筆；每列狀態會顯示「自動同步」或「舊資料」。
- 價差與高風險統計改採 PChome 視角：正數代表 PChome 比 MOMO 外部參考價高，才列入需檢查價格。
- 下一步：把 Hermes / ElephantAlpha / AI product pick 等後端價格分析逐步改讀 `external_offers`，讓告警與頁面使用同一份資料來源。

## 16. 2026-06-16 V10.613 高可見頁面繁中化守門

- 使用者要求所有內容與頁面必須使用繁體中文；工程內部變數、CSS class、API key 名稱可保留英文，但使用者可見標題、按鈕、狀態與說明不得用英文工程語。
- 已把 `/code-review/` 顯示文字改成「AI 程式碼審查」「流程進度」「程式碼審查完成」，並將 OpenClaw 模型顯示改成「Ollama 優先」，避免前台誤以為 Gemini 是主路徑。
- 已把 AI 自動化健康檢查頁改為白話繁中命名，狀態顯示改成「正常 / 注意 / 嚴重 / 產生時間」。
- 已把 PPT 觀測台與商品看板高可見英文標籤改成「產線健康度 / 工作隊列 / 視覺問題 / 產線控制台 / 覆蓋率流程」，並新增測試防回歸。

## 17. 2026-06-16 V10.614 部署與基礎設施頁繁中化

- `/cicd` 對使用者顯示為「部署監控」，不再以前台標題顯示 `CI/CD Dashboard`；部署流程、部署歷史、GitLab 部署紀錄皆使用白話繁中。
- 部署流程圖會把後端階段代碼 `test / build / deploy` 轉成「測試 / 建置 / 部署」，診斷狀態也轉成「正常 / 注意 / 失敗」。
- `/observability/host_health` 與 PPT 產線視覺狀態把 `Runtime` / `Vision QA` 改成「執行環境」與「視覺檢查」，並更新測試防回歸。

## 18. 2026-06-16 V10.615 AI 智慧推薦頁 Ollama 主路徑文案

- `/ai_recommend` 的 AI 路徑顯示改成「Ollama 主路徑 / Gemini 備援」，Gemini 選項保留為角色提示但停用手動選擇，避免使用者誤以為可直接用 Gemini 生成文案。
- `page-ai-recommend.js` 的狀態 badge、生成結果 meta、搜尋/分析錯誤訊息改用繁中全形冒號與「權杖」用語。
- 新增測試守門：禁止 `Ollama (本地)`、`Gemini (雲端)`、`Web Search`、`Token:` 與半形英文錯誤前綴回到 AI 智慧推薦頁。

## 19. 2026-06-16 V10.616 主商品看板統計標籤繁中化

- `/` 主商品看板補齊高可見統計標籤繁中化，將 `ACTIVE`、`PICK COUNT`、`AVG CONFIDENCE`、`EVIDENCE GAP` 等工程詞改為「有效商品」「挑品數」「平均信心」「待補證據」。
- PChome 補強區塊標籤改為「PChome 比價補強」，空狀態改為「目前有效商品沒有高優先 PChome 覆核項目」。
- 測試新增禁止英文工程標籤回歸，讓主商品看板符合「所有內容包含頁面皆為繁體中文」紅線。

## 20. 2026-06-16 V10.617 AI 情報頁改為作戰導向 UI

- `/ai_intelligence` 不再只堆說明文字；首屏新增「下一步」動態指令、商品處理進度、外部價格來源與操作捷徑。
- 今日處理清單改為表格，欄位優先呈現「優先級、建議動作、商品、近 7 天業績、比價結果、資料可信度、下一步」，讓使用者先看到該做什麼，以及資料能不能信。
- MOMO 外部價格參考新增價格風險分佈，表格改為 PChome 價格在前、MOMO 參考價在後，價差明確顯示「PChome 貴 / PChome 便宜」，並新增「鎖定商品」操作。
- 備援 CSV 流程降級為「備援資料檢查」，移到主要作戰與價格表後面，避免誤導使用者以為日常仍要人工匯入。
- 前端補上 payload fallback、動態表格 escape、手機版 `data-label` 與補商品對應 busy lock，避免資料缺欄位、特殊字元或重複點擊造成壞畫面。

## 21. 2026-06-16 V10.618 比價頁改為下一步導向

- `/price_comparison` 改為「PChome 商品比價決策台」，首屏需先顯示「今天先做」與 PChome / MOMO 商品準備狀態，不再讓使用者從 Step 1/2/3 自行猜流程。
- 頁面會依目前資料狀態切換下一步：輸入關鍵字、取得 PChome 商品、匯入 MOMO 商品、開始檢查價差、查看需檢查價格或可主推商品。
- 比價結果新增判讀分佈：「需檢查價格」「可主推曝光」「價格接近」，表格第一欄直接呈現每筆商品下一步。
- Toast 改用純文字 DOM，手動輸入錯誤訊息不再塞 HTML；更新商品資料時會清掉舊比價結果，避免資料已更新但畫面仍顯示舊判讀。

## 22. 2026-06-16 V10.619 PChome 導向 MOMO 精準候選搜尋

- 使用者指出只抓 MOMO 活動頁會讓比價候選池偏窄；V10.619 新增 `search_momo_products_for_pchome_products()`，用 PChome 商品名稱逐筆反查 MOMO 候選。
- 搜尋詞沿用 `marketplace_product_matcher.build_search_terms()`，保留品牌、品名、容量、單品與組合線索，例如 B5 40ml、500ml 2入組，避免只用品牌或活動頁商品池。
- `/api/price_comparison/compare` 在已有 PChome 商品但缺 MOMO 清單時，會優先走 PChome 導向 MOMO 搜尋；完全沒有 PChome 商品時才退回品牌搜尋。
- MOMO 搜尋 parser 已補新版 Next.js `goodsInfoList`，避免明明搜尋頁有商品但 crawler 回 0 筆。
- `/price_comparison` 已新增「自動找 MOMO 候選」操作，PChome 商品準備後可直接搜尋 MOMO；回傳會分成「可直接比價」與「需人工確認」。
- 新路徑只擴大候選池，不放寬 `score_marketplace_match()` 的 hard veto 與同款分數篩選；V10.619 當時先把 `unit_comparable` 候選保留為「需人工確認」，此限制已由 V10.620 的自動單位價分流取代。

## 23. 2026-06-16 V10.620 單位價候選自動化分流

- 使用者要求把需要人工處理的比價工作降到最低；V10.620 將 PChome 導向 MOMO 搜尋的 `unit_comparable` 候選改成三路分流：同款總價、可自動換算單位價、真正需人工確認。
- `search_momo_products_for_pchome_products()` 會在 `unit_comparable` 時呼叫 `build_unit_price_comparison()`；只有能算出雙方總容量/數量、單位價與差距百分比時，才標成 `auto_compare_type=unit_price` 與「自動單位價比較」。
- `/api/price_comparison/fetch_momo_for_pchome` 回傳 `products`、`unit_compare_candidates`、`review_candidates` 三段；舊總價比價只吃 `products`，避免把組合包總價誤當同款價差。
- `/price_comparison` 顯示「同款 / 單位價 / 需確認」三個數量，並新增自動單位價面板；若只找到單位價候選，下一步會引導使用者查看單位價結果，而不是人工確認。

## 24. 2026-06-16 V10.621 自動候選接入外部價格參考

- `/price_comparison` 正常操作「自動找 MOMO 候選」時會帶 `sync_external_offers=true`，把可直接總價比價與自動單位價候選同步進 `external_offers`；仍需人工確認的候選不寫入。
- 新增 `sync_targeted_momo_candidates_to_external_offers()`，只寫 `ingestion_method='targeted_momo_search'`、`match_status='verified'`、`data_quality_status='verified'` 的安全候選；`unit_price` 候選會在 `raw_payload_json.unit_price_comparison` 保留 MOMO / PChome 單位價、容量/數量與價差百分比。
- `build_pchome_growth_opportunities()` 已能讀 `external_offers.raw_payload_json.price_basis='unit_price'`：作戰清單會顯示「資料可用單位價判斷」，並用單位價差距做「檢查售價與活動 / 放大價格優勢」判斷。
- 此路徑只同步外部價格參考與作戰清單，不寫 `competitor_prices`，不自動改價；目標是減少人工補資料，而不是放寬正式價差寫入。

## 25. 2026-06-16 V10.622 外部報價同步後即時刷新作戰清單

- 新增 `services/pchome_growth_cache_state.py`，以 `data/pchome_growth_cache_epoch.txt` 作為跨 Gunicorn worker 的作戰清單快取失效標記。
- `sync_legacy_momo_reference_offers()` 與 `sync_targeted_momo_candidates_to_external_offers()` 只要成功寫入 `external_offers`，就呼叫 `mark_pchome_growth_cache_stale()`。
- `/api/ai/pchome-growth/opportunities` 的 in-memory cache 會記住建立時的 epoch；讀快取前若發現共享 epoch 較新，會直接重建，不再讓使用者看到 120 秒舊清單。
- 這讓「自動找 MOMO 候選 → 同步外部價格參考 → AI 情報頁作戰清單」變成同一條即時資料流，減少使用者手動重新整理或等待快取過期。

## 26. 2026-06-16 V10.623 比價與作戰頁工作台化

- 使用者指出前端仍像文字堆疊，無法快速知道怎麼操作；V10.623 將 `/price_comparison` 第一屏改為主 KPI、目前卡點、四步流程與下一步 CTA。
- `/price_comparison` 的結果區新增決策摘要，先顯示「需檢查售價或活動 / 可主推曝光 / 觀察賣點」三類數字與建議，再往下看明細表。
- `/ai_intelligence` 第一屏新增今日任務摘要，直接顯示今日任務、可立即處理、待補比價與最新業績日；資料來自現有 PChome growth API stats。
- 測試守門新增 `priceDecisionGrid`、`price-workflow-strip`、`price-result-summary-grid`、`growth-executive-strip` 與 `renderGrowthExecutiveSummary`，避免頁面退回只有文字說明的狀態。

## 27. 2026-06-18 V10.624 ElephantAlpha 價格決策只進 HITL

- 部署後觀察到 `price_drop_alert` 進入 ElephantAlpha execution plan 後可能卡在 Hermes/NemoTron step，最後以 60 秒 timeout 污染 scheduler log。
- V10.624 將價格類 trigger 的高信心路徑改為「有實證就發 L3 HITL 價格覆核通知」，不再執行 orchestrator `execution_plan`，避免長任務 timeout 與自動調價誤解。
- 新增 `price_decision_review` 決策信封，固定標示 `can_auto_execute=false`、`requires_hitl=true`、`execution_plan skipped`；通知只呈現 DB/Hermes 具體價差實證。
- 測試新增高信心價格決策不執行長任務 step 的守門，避免未來又把價格告警回退成自主執行。

## 28. 2026-06-18 V10.625 背景 embedding 熔斷不扣 retry

- 部署 V10.624 後 scheduler log 顯示 GCP-A 最近 host health 不健康，GCP-B `bge-m3` 仍可能 30 秒 timeout；embedding worker 會在同批任務中連續把多筆 queue 標成失敗，造成 attempts 被白白消耗。
- V10.625 將 GCP embedding failure circuit 狀態公開為 `is_embedding_gcp_circuit_open()` / `embedding_gcp_circuit_remaining_seconds()`，讓 worker 可用明確狀態判斷，不再猜測空向量原因。
- `OpenClawLearningService` worker 在熔斷中不 claim 新任務；若處理中開啟熔斷，當筆與同批剩餘任務會退回 `pending` 並寫入延後原因，不扣 `attempts`、不刷成 `failed`。
- 背景 embedding 仍維持 GCP-A → GCP-B，不落 111；111 不承接 `bge-m3` 背景批次的治理規則不變。

## 29. 2026-06-18 V10.626 GCP-A direct timeout 改走 110 proxy rescue

- 正式診斷腳本顯示：188 直連 GCP-A `34.87.90.216:11434` `/api/version` timeout，但 GCP-B direct、111、110 `11435` primary proxy、110 `11436` secondary proxy 都可用；GCP-B `bge-m3` embed 實測約 2.9 秒。
- V10.626 新增 `OLLAMA_HOST_PRIMARY_PROXY` / `OLLAMA_HOST_SECONDARY_PROXY`，預設為 `http://192.168.0.110:11435` / `http://192.168.0.110:11436`。
- `resolve_ollama_host()` 順序調整為 GCP-A direct → GCP-A via 110 proxy → GCP-B direct → GCP-B via 110 proxy → 111；proxy rescue 是同順位入口救援，不代表 direct GCP host 已恢復。
- 近 24 小時 `ai_calls` 只有 `ollama_secondary=51`、`gcp_ollama=3`、`nim=1`，沒有 Gemini provider；Gemini hard disabled / fallback disabled 的紅線仍有效。

## 30. 2026-06-18 V10.627 Resolver 讀 host_health 跳過 direct timeout

- V10.626 已能在 GCP-A direct timeout 後走 110 proxy，但 cache refresh 仍會先等一次 direct `/api/version` timeout。
- V10.627 新增 direct-only host health skip：`resolve_ollama_host()` 會讀最近 `host_health_probes`，若 GCP-A/GCP-B direct 在視窗內已 unhealthy，先跳過 direct endpoint，改試同順位 110 proxy；proxy rescue 不吃這個 skip，避免因 direct unhealthy 誤跳過可用 proxy。
- 新增 `OLLAMA_RESOLVE_HOST_HEALTH_SKIP_ENABLED=true` 與 `OLLAMA_RESOLVE_HOST_HEALTH_SKIP_WINDOW_MINUTES=20`；DB 讀取失敗 fail-open，回到原本網路探測。

## 31. 2026-06-18 V10.628 備份 partial 檔案清理

- 正式 `backup_log` 最新狀態已是 2026-06-18 02:00 成功備份，6/15 的 `pg_dump` not found 是舊失敗紀錄；`get_latest_backup_info()` 目前回 success，backup monitor 不會再因舊 row 告警。
- 備份目錄仍殘留 0 byte `momo_analytics_*.sql.gz` partial 檔，容易讓人工查檔誤判。
- V10.628 新增 `cleanup_partial_backups()`，`cleanup_old_backups()` 會先清除超過 `PARTIAL_BACKUP_MIN_AGE_MINUTES=60` 的 0 byte partial 備份；剛產生的 0 byte 檔不刪，避免誤傷正在寫入的備份。