# PChome 業績成長自動化作戰系統 — AI 競價情報模組 Single Source of Truth

> **最後更新**: 2026-07-15 (台北時間)
> **狀態**: 🟠 Partial。V10.796 source 新增 EwoooC / MOMO 兩個 canonical product 的公開唯讀 MCP/RAG aggregate receipt，但 production 部署與 AWOOOI durable federation readback 尚待同一 release 驗證；目前 production 仍以 V10.795 runtime truth 為準。V10.795 已把 PChome TOP50 比價主指標改為業績加權覆蓋、建立 MOMO 同商品 controlled apply 與 durable receipt/post-verifier，並以報表到檔 SLA 取代午夜切日造成的誤判；production 桌機/手機可見驗證已通過。目前業績覆蓋為 40%，但仍有 45/50 商品未形成正式同商品證據、外部平台 runtime 僅 1/15。SEC-P0-001 已完成 production closure，SEC-P0-002 維持 production hybrid canary-ready；full asset reconciliation、software supply chain、統一 controlled-apply envelope、restore drill、internal RAG canary 與 MCP/RAG runtime closure 尚未全部完成。任何局部 receipt 不得代表整體閉環完成。
> **適用版本**: V10.796 source；production runtime 需由 `/health` 與 federation post-verifier 另行確認

---

## 零之負三、AWOOOI MCP federation 公開唯讀契約（V10.796 source）

- 新增 `/api/public/mcp-federation-readback`，只輸出 `ewoooc` 與 `momo-pro-system` 兩個 canonical identity 的 aggregate metadata；既有需要登入的 AI automation API 不放寬權限。
- 每個 product receipt 僅包含 runtime version/health、MCP server IDs 與 counts、pgvector embedding metadata、PixelRAG platform/stage、blockers、Asia/Taipei timestamp，以及可由接收端重算的 SHA-256 fingerprint；不輸出 endpoint URL、tool registry、credential、request/response body、tool output、RAG 內容或正式商品價格。
- operation boundary 固定為唯讀：不得 network call、DB write、secret read、external tool call、RAG write 或 production price write。PixelRAG 仍只允許 visual evidence receipt，不得直接寫正式價差或 `ai_insights`。
- receipt 會誠實揭露 `:latest` embedding model 等 immutable supply-chain 缺口；本次 source/test 綠燈不代表 production 已部署，也不代表 `MCP-P0-001`、`RAG-P0-001` 或 12 產品 federation 已完成。

---

## 零之負二、PChome 比價可信度與同商品自動閉環（V10.795）

- 儀表板主要 KPI 使用 TOP50 近 7 天業績加權覆蓋，不再把原始商品筆數 `5/50 = 10%` 當成唯一或主要成效。Production readback 為可比價業績 `NT$40,201 / NT$100,507 = 40%`；10% 仍保留為商品覆蓋透明度，不得隱藏或改寫。
- TOP50 production partition 為 `5` 件正式可比價、`4` 件候選驗證、`41` 件未對應；剩餘 `45/50` 是 current P0 的真實 coverage gap，不得因 UI 改善標示完成。
- `pchome_same_item_reconciliation_v1` 以同一 `trace_id/run_id/work_item_id` 串接來源、正規化、SOT diff、AI candidate、風險政策、check-mode、bounded execution、exact DB post-verifier 與 durable per-target receipt。只有獨立同商品與規格驗證通過者可寫 `external_offers`；候選、阻擋頁與無安全候選 run 一律 no-write。
- 第一輪 production canary 寫入 2 件獨立驗證 MOMO 同商品；修正動態 TOP50 導致的 verifier 漂移後，exact DB identity/fingerprint replay 為 `2/2`。第二輪 run `d3db6b69a5fc46e4ad59424299d549cb` 無安全候選，4/4 durable receipts 為 `no_write`、0 failed，post-verifier terminal 為 `no_write_verified`，scheduler 依 1 小時 cooldown 自動重試。
- 最新業績日為 `2026-07-13`。V10.795 使用 `pchome_sales_freshness_sla_v1`：台北時間每日 `20:00` 前，上一日報表仍在等待到檔視窗，`2026-07-15 01:44` 的 raw calendar lag 為 2 天、SLA lag 為 0、狀態為 `grace` 且 `decision_ready=true`；20:00 後若仍未收到 `2026-07-14` 才會依政策阻斷決策。scheduler receipt `0f24219e0bbb4740b7ad6645e7952296` 與 explicit canary receipt `6e2df008f65544fe8e557c11ff0dbb93` 均為 `completed_no_write`，durable decision 為 `no_candidate_fresh_no_write`，證明無新檔時安全不寫且不再於午夜誤停業務。live 與 persisted source readiness 均為 `1/4`；Google Drive 可用，HTTPS、IMAP、local 仍未形成冗餘，因此 Lane A 只關閉 freshness runtime，source continuity 仍是 partial。
- Dashboard 的 mapping backlog 與 AI automation evidence 已改為結構化 grid 與 progressive disclosure；V10.795 首屏可見 `業績日 2026-07-13 · 到檔 SLA 內`。Desktop `1512px` 與 mobile `390px` DOM 驗證均無水平溢位，`430px` mobile screenshot 亦完整顯示標題、SLA 與 40% 業績覆蓋。這只代表該頁可見 UX closure，完整全站 UI/UX 仍依 `UX-P1-001` 推進。

## 零之負一、資訊安全與治理自動化基準（2026-07-10）

- ADR-038 採 NIST CSF 2.0 `GOVERN / IDENTIFY / PROTECT / DETECT / RESPOND / RECOVER` 作為 program 結構，OWASP ASVS 5.0.0 L2 作為應用基準，NIST SSDF SP 800-218 v1.1 作為供應鏈基準。
- `governance/ewoooc_asset_inventory.json` 是 full-asset seed；欄位完整不等於 runtime reconciliation 完成。
- `services/http_access_policy_service.py` 統一保護 vendor、import、CI/CD、crawler、category、logs 與 operator surfaces；public exception 必須有明確 transport auth 或 public allowlist。
- `services/security_governance_review_service.py`、`scripts/ops/report_security_governance_review.py` 與 `/api/ai-automation/security-governance-review` 提供 machine-readable checks、completion、release gate 與 ordered work items。
- Gitea CD 必須執行 `report_security_governance_review.py --strict`，且不得解析 GitHub action/source/image。
- production 安全與治理完成度必須分開顯示 program、asset coverage、runtime closure；目前結論是 partial，不是 complete。
- 目前 ordered P0 以 `docs/guides/ai_automation_mainline_work_items.md` 為準：SEC-P0-001 access exposure 已關閉，current P0 是 identity/RBAC，之後依序為 webhook trust、supply chain、asset reconciliation、controlled-apply envelope、internal RAG canary 與 MCP/RAG runtime closure。
- V10.786 起 `/metrics` 不再是 public exception；應用中央政策與 Nginx exact-match edge policy 僅允許 loopback / Docker transport，Prometheus 必須以內部 canary 證明 target `up`，且 public/LAN readback 必須拒絕。監控 Compose 不得保存明文 Grafana 管理密碼，Prometheus 對外埠預設只綁 loopback。
- V10.787 依 live ingress 修正 metrics transport：production ingress 實際位於 188，110 global Prometheus 只能經專用 `172.20.0.1:19191` Docker-only Nginx bridge 抓取；bridge 以系統 CA、`mo.wooo.work` SNI/Host 轉送至 188，應用僅額外允許 `192.168.0.110/32` 單一監控主機，不得放行整段 LAN，也不得把 110 的其他 vhost 誤當 EwoooC production ingress。controlled apply 支援新 include 建立、Prometheus bind-mount reconciliation、`momo_app_info`/health/database product marker canary、精確 scrape URL、worker reload convergence 與失敗自動移除/回滾；production 已讀回 public 404、internal 200、target up、Prometheus identity preserved、8/8 anonymous matrix 與 `momo-db` unchanged，證據在 `governance/evidence/SEC-P0-001-20260711T122758Z.json`。
- V10.788 把既有 `users/login_history/user_permissions` 正式接入登入：`auto` 模式先以 hybrid 維持回滾能力，只計 active admin 的 database-auth success durable receipts，預設連續兩次後自動轉為 database-only；legacy shared Session 下一次請求自動撤銷。鎖定改由 `login_history` 跨 worker 持久化，Session 綁定 password/role/active identity version，中央 policy 區分 read/operate/admin，且只有 allowlisted direct proxy peer 才能提供 `X-Forwarded-For/X-Real-IP`。帳號建立、身份更新、密碼變更、停用與權限異動會在同一交易寫入不含密碼的 audit event，commit 失敗時兩者一併 rollback。`/api/auth/governance` 與 `report_auth_identity_governance.py` 僅輸出非機密 readback；source ready 不等於 production cutover completed。
- V10.777 起 web process 只能註冊 OpenClaw Blueprint，不得在 import 或 `record_once` 啟動 APScheduler、timed jobs 或 embedding thread；10 個 OpenClaw timed jobs 與唯一 embedding worker runtime owner 必須由 `momo-scheduler` 明確啟動。每日 04:15 的 codebase inventory 只掃描程式與前端資產並寫 artifact receipt，不讀 secret、不寫業務 DB。

---

## 零、LLM 路由紅線（2026-05-12）

- 所有 AI Agent、LLM 推理與 embedding 預設必須走 Ollama 三主機級聯：GCP-A `34.87.90.216:11434` → GCP-B `34.21.145.224:11434` → 111 `192.168.0.111:11434`。
- `services/ollama_service.resolve_ollama_host()` 是主機解析契約；`OLLAMA_HOST`、`HERMES_URL`、`EMBEDDING_HOST`、`OLLAMA_API_BASE` 只接受 GCP-A / GCP-B / 111 或 110 的核准轉發端口。
- 188 直連 GCP-A / GCP-B timeout 時，resolver 可先使用同順位 110 proxy rescue：GCP-A direct → `192.168.0.110:11435` → GCP-B direct → `192.168.0.110:11436` → 111。proxy rescue 只是同一順位的可用入口，不代表 GCP direct host 已恢復。
- `OLLAMA_RESOLVE_HOST_HEALTH_SKIP_ENABLED=true` 時，resolver 會讀最近 `host_health_probes`；若 direct GCP-A/GCP-B 在視窗內已被判定不健康，會直接略過該 direct endpoint，先試同順位 proxy rescue，避免每 120 秒 cache refresh 都等待 direct timeout。此 skip 只套用 direct GCP，不套用 110 proxy。
- `config.OLLAMA_HOST`、`config.HERMES_URL`、`config.EMBEDDING_HOST` 只保留為舊 caller 相容常數；import-time 不得 probe network，也不得因 GCP-A/GCP-B 短暫不可用而 freeze 到 111。需要即時路由時一律呼叫 `get_ollama_host()`、`get_hermes_url()`、`get_embedding_host()` 或 `OllamaService`。
- Gemini 只能作為 Ollama 主路徑失敗後的備援；MCP Grounding、PPT/vision、週/月報、Code Review、EA AI 例外決策、複雜 SKU 升級等舊鎖定場景也必須先走 GCP-A → GCP-B → 111。
- 188 `192.168.0.188` 僅是 App / DB / scheduler / Telegram bot 容器宿主與 AutoHeal target，不可作為 Ollama 節點。
- 通用 AI 文案、關鍵字、商品洞察與 Telegram Q&A 第一響應不得 Gemini-first。
- Hermes intent / analyst 路徑不得手刻 `/api/generate` 或只 resolve 單次 host；必須走 `OllamaService`。預設 `HERMES_ALLOW_111_FALLBACK=false`，同一請求只跑 GCP-A → GCP-B；兩台都失敗時回規則引擎或 DB 證據 fallback，不把批量價格分析轉嫁到 111。救急時才可顯式設 true 允許 111 接手。
- NemoTron qwen3 dispatch 的 `/api/chat` tool-calling 路徑也必須同一請求最多嘗試三台 Ollama，第一台失敗要 `mark_unhealthy()` 後再試下一台，最後才 fallback NIM。
- PPT vision、PPT 文案 final fallback、MCP 離線 final fallback 等特殊 Ollama 路徑也不得只打單一 host；如需 `/api/generate`，一律透過 `OllamaService.generate()`。
- Code Review pipeline 也必須 Ollama-first：Hermes scan 與 OpenClaw assessment 都走 `OllamaService` 三主機 retry；Gemini telemetry 只能以 `code_review_openclaw_gemini` 出現，表示 Ollama/可選 Claude 備援都失敗後才啟用。
- Code Review Hermes scan 預設不呼叫 LLM，改用 deterministic fast static scan，避免部署後先卡三段 Ollama timeout；需要 LLM 掃描時才以 `CODE_REVIEW_HERMES_LLM_SCAN_ENABLED=true` 啟用本地矩陣。
- Code Review Hermes LLM scan 啟用時才使用本地模型矩陣，且預設只跑 GCP-A `qwen2.5-coder:7b` → GCP-B `gemma3:4b`；`CODE_REVIEW_ALLOW_111_FALLBACK=true` 時才允許落到 111，並由 `OllamaService` 降級到 `llama3.2:latest`。不啟用 Gemini 備援，本地掃描失敗時只回空 findings 並交由 OpenClaw 本地矩陣續跑。
- Code Review OpenClaw assessment 預設只跑 GCP-A → GCP-B：GCP-A `qwen2.5-coder:7b`、GCP-B `gemma3:4b`；primary timeout 預設 `15s`、secondary timeout 預設 `60s`，讓 A 掛時快速讓位給 B，且 B 有足夠時間完成審查 prompt。111 是最後救急節點，但部署後重分析預設不打 111；只有 `CODE_REVIEW_ALLOW_111_FALLBACK=true` 才允許 111 接手，並降級到 `llama3.2:latest`。Code Review 的 Ollama `keep_alive` 預設為 `5m`，不得再用 `24h` 長駐 runner 壓住 GCP-B/111。GCP-A/GCP-B 都失敗且 Claude/Gemini 未顯式開啟時，必須回 deterministic 本地降級摘要，不呼叫 Gemini、不落 111、不走其他雲端模型。
- Embedding / semantic RAG 背景任務預設只跑 GCP-A → GCP-B：`OpenClawLearningService` embedding worker 與 `RAGService` 查詢 embedding 呼叫 `OllamaService.generate_embedding(..., allow_111_fallback=False)`；111 只可作人工明確指定的救急路徑，不承接 `bge-m3` 背景批次。`OLLAMA_EMBED_TIMEOUT` / `OLLAMA_EMBED_MAX_TIMEOUT` 預設 `30s`、`OLLAMA_EMBED_KEEP_ALIVE=1m`、`OLLAMA_EMBED_MAX_CHARS=4000`；此上限依 GCP-B `bge-m3` 實測 6–23s 波動調整，避免慢但成功的 embedding 被 15s cap 誤殺。
- `allow_111_fallback=False` 時，若 resolver 因 unhealthy cache 回傳 111，不得直接結束 embedding；必須強制改試尚未嘗試的 GCP-A / GCP-B，避免正式 log 出現 `tried=[]` 或只試單台 GCP-B。
- `allow_111_fallback=False` 且 GCP-A / GCP-B 皆失敗時，背景 embedding 會開啟短暫 GCP failure circuit（預設 60 秒），期間不重複打兩台 GCP、不落 111，避免 worker 與 log 被連續失敗拖慢；GCP 恢復後會自然再試。
- 背景 embedding 的 GCP-only 熔斷屬於可降級背景能力，應記錄為明確 WARNING 與 circuit 狀態，不應每次污染 ERROR 通道；真正允許三主機 fallback 的同步 embedding 全失敗仍保留 ERROR。
- OpenClaw embedding worker 遇到 GCP-only failure circuit 時，必須把已 claim 任務退回 `pending` 並延後處理，不得扣 `attempts`、不得把同批任務刷成 `failed`；熔斷期間也不得繼續 claim 新任務。
- Scheduler host health probe 不只看 `/api/tags`；GCP-A / GCP-B 節點必須再通過 `bge-m3` `/api/embed` 實作探針，才算 healthy。探針 timeout 預設 30s，111 預設不納入這個背景 embedding 探針，避免監測任務把 fallback Mac 載入 `bge-m3`。
- 背景 embedding 會讀取最近 `host_health_probes` runtime 結果；若 GCP-A / GCP-B 在 `OLLAMA_EMBED_HOST_HEALTH_SKIP_WINDOW_MINUTES=20` 視窗內已被標為 unhealthy，`OllamaService.generate_embedding(..., allow_111_fallback=False)` 會先跳過該節點並開啟短暫 GCP circuit，不再等待 30 秒 timeout，也仍不落 111。此功能由 `OLLAMA_EMBED_HOST_HEALTH_SKIP_ENABLED=true` 控制，DB 讀取失敗時 fail-open 回到原本網路 retry。
- BGE-M3 一致性檢查是監測任務，不是 fallback 壓測；預設只比對 GCP-A / GCP-B。111 Mac fallback 只有 `EMBED_CONSISTENCY_INCLUDE_111=true` 時才納入，避免每週背景檢查把 `bge-m3` 載入 111。
- OpenClaw Telegram Q&A 主路徑也不得綁單一 host：`_call_qwen3_qa()` 必須透過 `OllamaService` 跑 GCP-A → GCP-B → 111，並把實際落點寫入 `ai_calls.provider`。
- OpenClaw Telegram 圖片商品辨識也必須 Ollama-first：`_identify_product_name_with_ollama_vision()` 透過 `OllamaService` 嘗試 GCP-A → GCP-B → 111；Gemini 只允許以 `openclaw_bot_image_gemini` caller 作為失敗後備援。
- OpenClaw 週報、月報、Meta analysis、日報洞察、Telegram PPT 分析與 MCP fallback 也必須 Ollama-first；Gemini caller 只能帶 `_gemini_fallback` 或明確 fallback caller 語意，且不得先於 Ollama/NIM 被呼叫。OpenClaw strategy 的 Ollama `keep_alive` 預設為 `5m`，避免報告型任務把 GCP-B/111 runner 長駐 24h。
- OpenClaw 週報、月報、Meta analysis、日報洞察與每日報告的 Gemini/NIM 備援 caller 必須登錄在 caller registry、AI 觀測台 agent group 與 Telegram 狀態統計，避免 fallback 用量被歸類為未知或漏算。
- `ai_calls.provider='ollama_other'` 只允許作為 unresolved/unknown Ollama telemetry bucket，例如全 host 失敗、尚未選定實際 GCP-A/GCP-B/111 host 或舊 caller 未帶 host；不得把 `ollama_other` 當成實際路由目標或新增非核准 Ollama host。
- GCP-B 若缺 caller 指定的 coder/large 模型，`OllamaService` 必須先在 GCP-B 改用 `OLLAMA_SECONDARY_MODEL_FALLBACK`（預設 `gemma3:4b`），不可因 model 404 把整台 GCP-B 標成 unhealthy 後直接推到 111；真正 timeout / HTTP 5xx 才標 host unhealthy。
- Gemini API 出站有第二道 kill switch：`GEMINI_FALLBACK_ENABLED` 預設為 `false`。即使 `GEMINI_API_KEY` 存在，通用 AI fallback、OpenClaw 報告/QA/PPT/圖片、MCP Grounding 與 Code Review L3 都不得呼叫 Gemini；只有操作員明確設為 `true` 時，Gemini 才能作緊急備援。
- `docker-compose.yml` 的 `momo-app`、`scheduler`、`telegram-bot` 必須明確設定 `GEMINI_API_HARD_DISABLED=${GEMINI_API_HARD_DISABLED:-true}` 與 `GEMINI_FALLBACK_ENABLED=${GEMINI_FALLBACK_ENABLED:-false}`；`.env` 可保留 `GEMINI_API_KEY`，但不得因 key 存在就讓核心容器產生 Gemini 付費出站。
- OpenClaw 日/週/月/Meta 等敘事報告屬長任務，Ollama 只能走 GCP-A → GCP-B；不得使用 111 final fallback 承接長文生成。GCP 兩台都不可用時，應走既有 Gemini hard-disabled guard 後的 NIM / deterministic degraded path，避免 111 被非即時分析壓高負載。
- Gemini 不可被任何狀態面板或 router 推薦為主提供者：`AIProviderService._get_recommended_provider()` 不得回傳 `gemini`，只能顯示為 fallback 狀態；`llm_model_router` 的 `ea_engine` 若收到 `gemini-*` default 必須改回 `hermes3:latest`，需要深推理時才升本地 `deepseek-r1:14b`。
- ElephantAlpha prompt / agent registry 不得再把 OpenClaw 描述為 Gemini 主模型；OpenClaw 是 `qwen2.5-coder:7b` / `qwen3:14b` Ollama-first 策略師，Gemini 僅能在 guard 顯式解鎖後作 emergency fallback。
- 111 `192.168.0.111` 只是最後一道 Mac fallback，不承接 7B+、vision、long-context 模型長駐；`OllamaService.generate()` 落到 111 時會將 `qwen3`、`deepseek-r1`、`hermes3`、`qwen2.5*`、`gemma3`、`llava`、`minicpm-v` 與 7B+ 模型依 `OLLAMA_111_MODEL_DOWNGRADE_PATTERNS` 降級到 `OLLAMA_111_MODEL_FALLBACK=llama3.2:latest`，並以 `OLLAMA_111_KEEP_ALIVE=5m`、`OLLAMA_111_MAX_TIMEOUT=20`、`OLLAMA_111_NUM_CTX=4096`、`OLLAMA_111_NUM_PREDICT=512` 封頂。OpenClaw 報告型路徑的業務 keep-alive 預設 `5m`；Code Review 以 `CODE_REVIEW_ALLOW_111_FALLBACK=false`、Hermes 以 `HERMES_ALLOW_111_FALLBACK=false` 預設跳過 111，避免 16GB RAM 主機與 GCP-B 被長駐 runner、長輸出與 24h keep-alive 壓到高 load。
- Scheduler 每 15 分鐘執行 `run_ollama_111_usage_guard_check()`，只讀 `ai_calls` 統計最近視窗的 GCP-A / GCP-B / 111 呼叫量；預設 60 分鐘內 Ollama 呼叫至少 20 次、111 至少 3 次且占比 >= 5% 才推 Telegram。這是觀測護欄，不改路由、不寫 DB、不自動重啟服務。
- `OllamaService` 對 111 final fallback 有 circuit breaker：預設最近 60 分鐘 Ollama 呼叫至少 20 次、111 至少 5 次且占比 >= 5% 時，短暫跳過 111（`OLLAMA_111_CIRCUIT_CACHE_SEC=60`），避免 111 在已偏高時繼續承接長任務；DB 觀測失敗時 fail-open，不讓主要 GCP-A/GCP-B 路由被觀測層中斷。
- 111 的 LAN 入口必須經 `scripts/ops/ollama111_allow_proxy.py` allowlist proxy：真實 Ollama 綁 `127.0.0.1:11434`，proxy 綁 `192.168.0.111:11434`，預設只允許 111 本機與 188 生產宿主；110 / 121 / 其他 LAN client 不能直接打 111，避免跨專案 CI 或 VM 繞過 momo-pro router 載入 7B+ runner。111 上以 `scripts/ops/install_ollama111_allow_proxy.sh` 安裝 user LaunchAgent，安裝器會把 proxy script 複製到 `~/.local/share/momo-pro-system/ollama111_allow_proxy.py`，讓 LaunchAgent 不依賴 iCloud repo 掛載路徑，並讓 proxy 與 `OLLAMA_HOST=127.0.0.1:11434` 在登入/重啟後自動恢復。拒絕日誌以 `OLLAMA111_PROXY_REJECT_LOG_DEDUP_SEC=60` 去重，避免 121 這類旁路探測刷爆 111 磁碟日誌。
- ElephantAlpha 的 `price_drop_alert` / `market_opportunity` Telegram AI 例外決策 告警必須把同款證據獨立呈現，至少包含 `match_type`、`price_basis`、`alert_tier` 與 `match_score`；沒有高信心同款與總價可比證據時，不得把 PChome/MOMO 價差寫成可直接跟價建議。

## 零之零、產品定位正名（2026-06-15）

- 本專案的營運定位正名為「PChome 業績成長自動化作戰系統」。
- 主要目標是提升 PChome 銷售業績；MOMO 是目前已接入的外部價格參考來源，不再把 PChome 視為附屬競品語意。
- 使用者可見 UI、Telegram 與報表文案必須白話、可行動，優先使用「商品對應」「可直接比價」「待補對應」「放大價格優勢」「檢查售價與活動」等營運語言，避免把 `identity_v2`、`match_score`、`candidate queue` 等工程詞直接丟給使用者。
- `services/pchome_revenue_growth_service.py` 是第一版只讀作戰清單：讀 PChome 後台業績與已驗證 MOMO 外部價格參考，輸出 `/api/ai/pchome-growth/opportunities`。此服務不呼叫 LLM、不抓外站、不寫 DB。
- 2026-06-15 只讀盤點確認：`daily_sales_snapshot."商品ID"` 與 `competitor_prices.competitor_product_id` 在正式資料中直接重疊為 0。因此第一版作戰清單不得硬接兩邊 ID；若沒有可驗證對應，只能輸出「先補商品對應」任務。
- 外部主流平台不得只限 PChome / MOMO 視角；MOMO 是已接入參考來源，Shopee、Lazada、Amazon、Google Merchant / Shopping、TikTok Shop、LINE 購物、Rakuten、Yahoo 購物、露天、品牌官網 / Shopify、Meta Commerce 與 Coupang 必須先納入來源治理契約。未取得合法穩定來源前只能顯示「待接入 / 不進告警」，不得假裝 AI 已監控或抓到促銷。
- 所有外部平台資料進作戰清單前必須正規化為同一商品報價格式：平台商品 ID、商品名稱、賣場連結、商品圖、售價、促銷/券/活動、庫存、資料時間、取得方式、同款狀態、資料可信度。缺商品 ID、缺賣場連結、缺圖片時，UI 必須明確顯示待補狀態，不得留下空白、破圖或資料庫欄位名稱。
- 商品清單、AI 挑品、比價覆核與待確認候選必須採商品身份優先 UI：縮圖、商品 ID、平台、賣場連結、價格/促銷狀態、可信度與下一步動作需在同一商品區塊內可一眼掃描；AI 建議不得只顯示長段理由，必須同時提供可開啟的賣場入口。
- 蝦皮與酷澎等未接入來源暫停接入，不進作戰清單、不發告警；後續只可透過 official API / provider API / manual CSV 進 `external_offers` 類正規化層，並清楚標示資料品質。
- V10.607 新增 `external_market_sources` / `external_offers` 正規化層與 `/api/ai/pchome-growth/source-contract` 只讀 API。MOMO 先以既有比價快取橋接進來源狀態；蝦皮與酷澎只保留 official API、provider API、manual CSV contract，預設暫停且不進告警。
- V10.608 新增 `/api/ai/pchome-growth/external-offers/csv-dry-run` 與 AI 情報頁「外部報價預檢」。CSV 預檢只讀、不寫 DB；逐列回報「可使用」「需 AI 自動驗證確認」「不能使用」，並支援中文表頭，避免格式小錯造成整批匯入失敗。
- V10.609 明確把外部報價主路徑改為自動化：`run_external_offer_sync_task` 每 4 小時將已確認同款的既有比價快取同步進 `external_offers`。CSV 只保留為 API / crawler / provider 失敗時的備援預檢入口，不是日常營運主流程。
- V10.610 起 `/api/ai/pchome-growth/opportunities` 優先讀取 `external_offers` 的自動同步資料；只有新資料層缺資料時才 fallback 舊 `competitor_prices`。API stats 會回傳資料來源計數，方便確認作戰清單是否已走新資料層。
- V10.611 起 `/ai_intelligence` 是營運使用者主入口；V10.617 已將舊「今日作戰入口 / 外部報價預檢」改為「今日重點總覽 / 備援資料檢查」，主流程不得再把人工 CSV 放在前段。
- V10.612 起 `/api/ai/icaim/dashboard` 的「MOMO 外部價格參考」表格也優先讀 `external_offers`，缺資料才 fallback `competitor_prices`；價差與風險改採 PChome 視角，正數代表 PChome 比 MOMO 外部參考價高。
- V10.613 起高可見前台頁面必須以繁體中文呈現：程式碼審查、AI 自動化健康檢查、PPT 產線與商品看板操作標籤不得使用英文工程標題或簡體字；測試需防止頁面文案退回英文。
- V10.614 起部署監控、基礎設施生命線與 PPT 產線狀態也納入繁中守門：前台不得顯示 `Dashboard`、`Pipeline`、`Runtime` 等工程詞，動態階段需轉成「測試 / 建置 / 部署」。
- V10.615 起 AI 智慧推薦頁必須把 Ollama 顯示為「Ollama 主路徑」，Gemini 只能顯示為「Gemini 備援」且手動選項停用；使用者可見錯誤與搜尋流程不得出現 `Web Search`、`Token:`、半形英文冒號等工程文案。
- V10.616 起主商品看板 `/` 的統計與補強區塊也納入繁中守門：不得顯示 `ACTIVE`、`PICK COUNT`、`AVG CONFIDENCE`、`EVIDENCE GAP`、`PCHOME MATCH BACKFILL` 等工程標籤；畫面需使用「有效商品」「挑品數」「平均信心」「待補證據」「PChome 比價補強」等白話營運文案。
- V10.617 起 `/ai_intelligence` 必須採「先給下一步」的作戰導向 UI：首屏需先回答「今天先做什麼」，再呈現商品處理進度、外部價格來源與操作捷徑；今日處理清單需用表格呈現優先級、建議動作、商品、近 7 天業績、比價結果、資料可信度與下一步；MOMO 外部價格參考需顯示價格風險分佈，且表格需以 PChome 價格優先，明確顯示「PChome 貴 / PChome 便宜」與可信度，不得只用大段文字說明使用方式。
- V10.618 起 `/price_comparison` 也必須採「先給下一步」的比價決策 UI：首屏需顯示目前卡在哪一步、PChome / MOMO 資料準備狀態與下一個按鈕；比價結果需先呈現「需檢查價格 / 可主推曝光 / 價格接近」分佈，再用表格列出每筆商品的下一步，不得只呈現 Step 流程或原始價差表。
- V10.619 起 MOMO 比價候選來源新增「PChome 商品導向搜尋」：當比價 API 已有 PChome 商品但缺 MOMO 清單時，必須用每筆 PChome 商品名稱產生精準搜尋詞反查 MOMO，保留品牌、品名、容量與組合線索；新版 MOMO 搜尋頁需解析 Next.js `goodsInfoList` payload。此路徑只擴大候選池，不放寬同款 matcher 門檻。
- V10.620 起 `unit_comparable` 不再一律丟 AI 自動驗證確認：若 `build_unit_price_comparison()` 可產生明確容量/數量、MOMO 單位價、PChome 單位價與差距百分比，候選需標為「自動單位價比較」並回傳 `auto_compare_type=unit_price`。此類候選可自動呈現價格壓力，但不得混入舊總價同款比價表，也不得直接寫入正式價差或自動改價；無法產生單位證據時才維持「需 AI 自動驗證確認」。
- V10.621 起 `/price_comparison` 的「自動找 MOMO 候選」會把可直接總價比價與自動單位價候選同步到 `external_offers`，`ingestion_method='targeted_momo_search'`，AI 自動驗證確認候選不得寫入。`external_offers.raw_payload_json.price_basis='unit_price'` 時，作戰清單必須使用 `unit_price_comparison` 的 MOMO / PChome 單位價與 `unit_gap_pct` 判斷價格壓力；不得把 MOMO 組合總價與 PChome 單品總價直接相減。此同步只影響外部價格參考與作戰清單，不寫 `competitor_prices`，也不自動改價。
- V10.622 起任何 `external_offers` 自動同步成功寫入後，必須呼叫 `mark_pchome_growth_cache_stale()` 寫入共享 cache epoch；`/api/ai/pchome-growth/opportunities` 讀快取前必須比對 `get_pchome_growth_cache_epoch()`。這是跨 Gunicorn worker 的可見性保護，避免自動候選已進外部價格參考，但 AI 情報頁仍回 120 秒舊作戰清單。
- V10.623 起 `/price_comparison` 與 `/ai_intelligence` 不得只靠大段文字說明流程：比價頁第一屏必須有主 KPI、目前卡點、四步流程與結果決策摘要；作戰頁第一屏必須有今日任務、可立即處理、待補比價與最新業績日。所有狀態都要由實際 API/前端狀態驅動，讓使用者一眼知道下一步要按哪個動作。
- V10.638 起 PChome 導向 MOMO 補抓會把「找到但不能自動比價」的候選以 `match_status='needs_review'`、`data_quality_status='needs_review'` 保存到 `external_offers`；這些候選不得進價格壓力判斷，也不得發告警，但 `/api/ai/pchome-growth/opportunities` 可回傳待確認候選數，讓 UI 顯示「已有候選待確認」而不是只顯示無法比價。
- V10.639 起待確認候選排序必須容忍缺少單位數量；沒有 `momo_total_quantity` / `competitor_total_quantity` 時仍可保存為 `needs_review`，不得中斷 PChome 導向 MOMO 回填。
- V10.640 起 `/ai_intelligence` 必須提供 MOMO 待確認候選操作佇列；使用者可直接確認同款或排除候選。確認後 `external_offers` 會轉為 `verified/verified` 並進入作戰清單，排除後轉為 `rejected/rejected`，兩者都必須清掉 PChome 成長作戰清單快取。
- V10.641 起 `/ai_intelligence` 的摘要數字不可只是靜態文字；第一屏 KPI、商品處理進度、待確認數字都必須可點擊並導向對應明細。今日清單若已有 MOMO 待確認候選，下一步必須顯示「確認候選」並跳到候選面板，不得再只顯示「補齊比價」。
- V10.642 起 `/ai_intelligence` 的摘要卡與商品處理數字不可只跳到大區塊；點擊後必須開啟商品明細面板，列出商品名稱、分類、近 7 天業績、業績變化、MOMO 比價狀態與下一步按鈕。明細需至少支援全部、價格壓力、價格優勢、待確認、缺比價與有外部價切換；外部價格風險分佈也必須能一鍵篩選下方表格。
- V10.643 起 `/ai_intelligence` 的商品明細上方必須提供「商品策略分流」視覺摘要，至少包含價格壓力、價格優勢、待確認、缺比價四類；每一類需顯示件數、近 7 天業績與比例條，且可點擊切換明細。舊 KPI 卡也不得是靜態數字，需可導向全部商品、可處理商品、高風險比價或處理紀錄。
- V10.725 source-ready 起 PChome growth 必須提供 `/api/ai/pchome-growth/ai-automation-readiness` 與 Dashboard「AI 主流程」狀態列；同一摘要要聚合缺口偵測、同款搜尋包、候選決策包、證據收據與受控落地，並明確輸出 `primary_human_gate_count=0`、`automation_policy.primary_flow=ai_controlled`。PChome mapping 不得把 AI 例外決策當主流程；所有例外都要進 AI machine-verifiable auto-resolution，產生 failure reasons、下一個機器動作與 rollback/readback 路徑。
- 2026-07-02 起 PChome AI 自動化主線工作順序以 `docs/guides/pchome_ai_automation_priority_backlog.md` 為可執行 backlog；使用者中途插入的 production truth、版本不得錯、GitHub freeze、推版到 Gitea/正式環境、AI 自動化取代人工主流程、外部專業 benchmark、主流專業產品網站、實作結果與完整優先順序要求，都必須列入 backlog 並依 P0/P1/P2/P3/P4 推進。未在 backlog 的支線不得蓋過 P0 runtime truth / controlled apply closure。
- 2026-07-02 起 AI automation smoke 必須例行執行 PChome controlled-apply drift monitor；`PChome 受控落地 drift monitor` 會以 read-only 方式重放 receipt replay + drift verifier，將 drift detected 或 verifier write-risk 升為 `critical`，並在 `/api/ai-automation/smoke` 與每日 smoke 摘要中回報 selector/readback/drift/artifact hash 狀態。
- 2026-07-02 起 PChome controlled-apply drift 必須提供 read-only rollback / re-apply recommendation package；`/api/ai/pchome-growth/mapping-backlog/direct-mapping-retry-candidate-exception-controlled-apply-drift-recovery-package` 會輸出 drift recovery actions、controlled re-apply SQL shape、rollback SQL shape、selector bindings、acceptance gates 與 artifact hash verifier。此 package 不執行 SQL、不寫 DB，0 drift 時必須產生 no-op evidence，drift detected 時才輸出 ready_for_controlled_reapply actions。
- 2026-07-02 起 PChome controlled-apply 必須提供 compact latest readback endpoint；`/api/ai/pchome-growth/mapping-backlog/direct-mapping-retry-candidate-exception-controlled-apply-compact-readback-package` 會收斂 apply、receipt replay、drift verifier、drift recovery 四段 receipt，輸出 product status、next machine action、selector readback、drift count、recovery action count 與 artifact hash 狀態。此 endpoint 是後續產品 UI 的主要資料來源，不執行 SQL、不寫 DB。
- 2026-07-02 起 PChome controlled-apply artifacts 必須提供 read-only retention policy；`/api/ai/pchome-growth/mapping-backlog/direct-mapping-retry-candidate-exception-controlled-apply-artifact-retention-package` 會掃描 verifier inputs、identity readback、controlled apply preflight、executor、replay、drift verifier、drift recovery、compact readback 八類 artifacts，依 `keep_latest_per_family` 保留最新 evidence 並保護 active compact readback chain，只輸出 prune candidates 與 retention receipt，不直接刪檔、不寫 DB、不執行 destructive prune。
- 2026-07-02 起 PChome dashboard 第一視窗必須呈現 AI automation product truth：`_load_pchome_growth_command_center` 需 read-only 聚合 receipt replay、drift verifier、drift recovery、compact readback 與 artifact retention policy，產品面直接顯示 selector readback、drift count、retention 保留數與 automation lane 狀態；不得退回只有 raw API / artifact / log 才看得到 AI 自動化結果的模式。
- 2026-07-02 起 PChome dashboard 第一視窗可見文案必須使用繁中營運語言；`retention`、`Compact`、`Artifact`、`DB writes`、`prune` 等工程詞只能留在 API / artifact / 測試證據層，不得出現在第一視窗。產品面用「異動」、「最新回讀」、「證據留存」、「資料寫入」、「清理建議」呈現同一批 AI 自動化 truth。
- 2026-07-02 起 PChome AI automation dashboard 必須符合外部 benchmark guardrails：參考 Grafana / Datadog / New Relic / Atlassian Statuspage 的狀態分層、下一步優先、證據按需與 golden signals 做法；第一視窗必須輸出「已自動落地、已驗證、異動狀態、下一步」，且 `tests/test_pchome_dashboard_benchmark_guardrails.py` 必須鎖住這些要求。
- 2026-07-02 起 PChome safe mapping lane expansion 必須先從 direct mapping candidate decision lane 開始；`/api/ai/pchome-growth/mapping-backlog/direct-mapping-candidate-decision-lane-closeout-package` 會把 candidate decision package 收斂成 lane receipt、receipt replay、drift verifier 與 product readiness，輸出 `primary_human_gate_count=0`、`drift_count`、`next_machine_action` 與 hash evidence。此 endpoint 預設不執行搜尋、不開 DB、不寫 DB、不持久化候選，只在 `execute_search=1` 時走 controlled read-only candidate search。
- 2026-07-02 起 AI automation scheduled health summary 必須提供 machine-readable endpoint；`/api/ai-automation/scheduled-health-summary` 會只讀 smoke history，並可選擇 `include_current_smoke=1` 執行不寫 history 的 current smoke，收斂 AI smoke、PChome drift monitor、history freshness、daily summary delivery readiness 四個 family，輸出 `primary_human_gate_count=0`、`writes_database_count=0`、`next_machine_actions` 與 scheduled output endpoints。此 endpoint 不寄 Telegram、不寫 DB、不改排程，只提供排程/監控可消費的健康摘要。
- 2026-07-02 起 PChome controlled apply rollback evidence 必須提供聚合 endpoint；`/api/ai/pchome-growth/mapping-backlog/direct-mapping-retry-candidate-exception-controlled-apply-rollback-evidence-package` 會聚合 receipt replay、drift verifier、drift recovery、compact readback、artifact retention 五類 evidence，輸出 rollback required / ready actions / protected chain / next machine action。此 endpoint 不執行 rollback、不執行 re-apply、不執行 SQL、不寫 DB；0 drift 時必須輸出 no-op evidence，drift detected 時才輸出 check-mode reapply action。
- 2026-07-02 起 `/metrics` 必須匯出 AI automation scheduled health summary gauges：`momo_ai_automation_scheduled_health_summary_total`、`momo_ai_automation_scheduled_health_family_status`、`momo_ai_automation_scheduled_health_primary_human_gate_count`、`momo_ai_automation_scheduled_health_writes_database_count`。Prometheus scrape 不得寄 Telegram、不寫 DB、不執行 current smoke，只讀 scheduled health summary history。
- 2026-07-02 起 P4 source / deployment governance 必須提供 machine-readable report：`scripts/ops/report_source_deploy_runtime_truth.py` 會分層輸出 Gitea / origin / local HEAD source truth、部署檔案 SHA256 readback、正式 `/health` runtime truth、optional container readback 與 GitHub freeze / `momo-db` protected / no DB write / no secret read 安全紅線。此 report 是推 Gitea 與正式部署後的 P4 收斂證據，不得把 source-control success 直接等同 deployment success 或 production runtime success。
- 2026-07-02 起 `/ai_intelligence` 與 `/observability/overview` 必須同樣套用 AI automation benchmark golden signals：首屏需有 `AI 自動化狀態` 區塊，直接顯示「已自動落地、已驗證、異動狀態、下一步」。`/ai_intelligence` 需以 `/api/ai/pchome-growth/ai-automation-surface-summary` 只讀更新首屏，該 endpoint 由 `/api/ai/pchome-growth/ai-automation-readiness` 聚合 safe lanes 後輸出 `golden_signals`、`safe_automation_lanes`、`surface_contract`、`primary_human_gate_count=0`、`writes_database_count=0` 與 `next_machine_action`；`/observability/overview` 需用正式觀測資料分層呈現風險與下一步。raw endpoint、artifact、DB table、manual/human gate 文字不得進首屏訊號。
- 2026-07-02 起 `/ai_automation_smoke` 也必須採密集 AI 巡檢工作台：首屏使用 `data-density-guardrail="compact-smoke-workbench"`，以「AI 巡檢、風險優先、推播摘要」短標籤保留狀態模式；重複說明、趨勢教學與診斷細節提示必須退到 hidden contract，畫面第一層只保留狀態、數字、趨勢、每日摘要與檢查項目 summary。
- 2026-07-02 起 `/observability/agent_orchestration` 必須採密集 AI Agent 工作台：首屏使用 `data-density-guardrail="compact-agent-workbench"`，以「AI 分工、成本守門、知識命中」短標籤承接分工狀態；hero 說明、KPI 小註、列內描述、卡片描述與頁尾重複標題不得佔用第一層視覺，畫面先保留呼叫總量、主力路徑占比、付費成本、知識命中率、分工矩陣與工具協作表。
- 2026-07-02 起 `/observability/ai_calls` 必須採密集 AI 流量工作台：首屏使用 `data-density-guardrail="compact-ai-calls-workbench"`，以「流量監控、成本守門、知識命中」短標籤承接 AI 呼叫狀態；hero 說明、KPI 小註、素材說明與頁尾重複標題不得佔用第一層視覺，畫面先保留呼叫總量、用量、成本、延遲、知識命中、錯誤、情境矩陣與最近呼叫。
- 2026-07-02 起 `/observability/quality_trend` 必須採密集 AI 品質工作台：首屏使用 `data-density-guardrail="compact-quality-workbench"`，以「品質回饋、知識可靠、行動成效」短標籤承接 AI 建議可靠性；hero 說明、KPI 小註與頁尾重複標題不得佔用第一層視覺，畫面先保留反饋總量、最低均分、蒸餾樣本、知識評分、使用情境反饋、根因建議與實際動作成效。
- 2026-07-02 起 `/observability/budget` 必須採密集 AI 成本工作台：首屏使用 `data-density-guardrail="compact-budget-workbench"`，以「成本守門、節流狀態、知識策略」短標籤承接成本治理；hero 說明、按鈕註解、KPI 小註與頁尾重複標題不得佔用第一層視覺，畫面先保留當月花費、預算使用率、預警、已節流、預算線、成本趨勢、成本集中與 AI 價格決策成效。
- 2026-07-02 起 `/observability/business_intel` 必須採密集 AI 商業工作台：首屏使用 `data-density-guardrail="compact-business-workbench"`，以「戰果追蹤、閉環成效、競品訊號」短標籤承接 AI 商業狀態；hero 說明、決策節奏註解、KPI 小註、panel 說明與頁尾資料來源不得佔用第一層視覺，畫面先保留高信心未跟進、平均信心分、有效率、競品監測、外部促銷活動監控、策略族群、最近建議與閉環學習紀錄。
- 2026-07-02 起 `/observability/host_health` 必須採密集 AI runtime 工作台：首屏使用 `data-density-guardrail="compact-runtime-workbench"`，以「主機級聯、自癒閉環、成本節流」短標籤承接 AI runtime 狀態；hero 說明、KPI 小註與頁尾重複標題不得佔用第一層視覺，畫面先保留建議服務離線、AIOps 未解、自癒成功率、節流供應商、AI 建議服務主機、健康趨勢、自癒閉環、工具層與事件紀錄。
- 2026-07-02 起 `/observability/rag_queries` 必須採密集 AI 知識工作台：首屏使用 `data-density-guardrail="compact-knowledge-workbench"`，以「知識命中、省模閉環、回饋學習」短標籤承接 RAG 召回狀態；hero 說明、KPI 小註與頁尾重複標題不得佔用第一層視覺，畫面先保留查詢數、命中率、省模型、回饋分、查詢串流、使用情境品質與命中內容查閱。
- 2026-07-03 起 `/observability/promotion_review` 必須採密集 AI 晉升例外工作台：首屏使用 `data-density-guardrail="compact-promotion-workbench"`，以「AI 例外、去重守門、防污染」短標籤承接知識晉升例外狀態；hero 說明、KPI 小註與頁尾重複標題不得佔用第一層視覺，畫面先保留待決策、知識庫、30 日採用、污染攔截、例外佇列、策略權重與最近知識；不得把人工審核呈現為 primary flow。
- 2026-07-03 起 `/observability/ppt_audit_history` 必須採密集 AI 視覺 QA 工作台：首屏使用 `data-density-guardrail="compact-ppt-workbench"`，以「預覽就緒、視覺審核、修復閉環」短標籤承接 PPT 產線狀態；hero 說明、KPI 小註、runtime/env var、DB/table wording 與頁尾重複標題不得佔用第一層視覺，畫面先保留最新簡報、產線健康度、最近可預覽簡報、工作隊列、視覺問題追蹤、產出紀錄與修復流程。
- 2026-07-03 起高可見 AI observability surfaces 必須有 route-level rendered HTML readback guard；`/observability/overview`、`/observability/ai_calls`、`/observability/quality_trend`、`/observability/budget`、`/observability/business_intel`、`/observability/host_health`、`/observability/rag_queries`、`/observability/agent_orchestration`、`/observability/promotion_review`、`/observability/ppt_audit_history` 必須在 Flask client render 後仍保留 compact density marker，且不得漏出 `PPT_VISION_ENABLED=`、`PPT_AUTO_GENERATION_ENABLED=`、`ppt_generation_runs`、DB write raw wording、manual/human gate primary wording、Artifact retention / Compact 回讀等產品面不該可見的 engineering copy。
- 2026-07-03 起高可見 AI surface HTML readback 必須納入 runtime AI smoke：`/api/ai-automation/surface-html-readback` 會 read-only 檢查 10 個 AI observability template contract，`/api/ai-automation/smoke` 需包含 `AI surface HTML readback` 檢查，`/api/ai-automation/scheduled-health-summary` 需輸出 `ai_surface_html_readback` family；此檢查不得寫 DB、不得送通知、不得要求 browser，失敗時下一個機器動作是 `repair_ai_surface_html_contract`。
- 2026-07-03 起整站 UI/UX 專業化必須由 Sitewide UI/UX Agent 管理：`/api/ai-automation/sitewide-ui-ux-agent` 會掃描真正頁面模板、排除 partial/components/base layouts，輸出高優先頁、compact guardrail、raw engineering issue 與 next machine action；`/api/ai-automation/sitewide-ui-ux-repair-package` 會產生 no-write controlled repair package。當前 Agent 判定為 55 個頁面模板、31 個高優先模板、29 個已具 compact guardrail、0 個待專業化、0 個 raw engineering leak，Sitewide Agent 狀態為 `ok`，repair package 為 `no_op`。四批 controlled UI/UX repair 已完成 AI observability、AI 建議、PPT/CI/CD/業績/比價/成長/供貨風險高優先 surface；下一個機器動作為 `keep_sitewide_ui_ux_agent_monitoring`，後續只接受 Agent 新增 issue 或更高階 visual/mobile QA 的證據驅動修復。
- 2026-07-03 起 Sitewide UI/UX Agent 歸零狀態必須納入 AI automation runtime monitoring：`/api/ai-automation/smoke` 需包含 `Sitewide UI/UX Agent readback` 檢查，要求 `issue_surface_count=0`、`repair_package_status=no_op`、`repair_action_count=0`；`/api/ai-automation/scheduled-health-summary` 需輸出 `sitewide_ui_ux_agent` family；`/metrics` 需以 `momo_ai_automation_scheduled_health_family_status{family="sitewide_ui_ux_agent",...}` 暴露 scheduled family。此監控不得寫 DB、不得送通知、不得要求人工審核。
- 2026-07-03 起整站 desktop/tablet/mobile visual QA 必須進入 AI automation runtime monitoring：`scripts/check_responsive_overflow.js --artifact-output data/ai_automation/sitewide_visual_qa_latest.json` 會輸出機器可讀 artifact；`/api/ai-automation/sitewide-visual-qa-readback` 只讀該 artifact 並回報 route_count、viewport_count、failed_count、overflow_issue_count、stale 與 next_machine_action；`/api/ai-automation/smoke` 需包含 `Sitewide visual QA readback`，`/api/ai-automation/scheduled-health-summary` 需輸出 `sitewide_visual_qa` family，`/metrics` 需暴露 `momo_ai_automation_scheduled_health_family_status{family="sitewide_visual_qa",...}`。readback 不啟動 browser、不寫 DB、不送通知；artifact 生成才需要 Playwright/瀏覽器。
- 2026-07-09 起 external MCP/RAG integration 必須進入 AI automation runtime monitoring：`/api/ai-automation/external-mcp-rag-integration` 與 `scripts/ops/report_external_mcp_rag_integration.py` 需輸出 9 個 capability 的 absorbed / unresolved 狀態、內部治理落點與 runtime flags；`/api/ai-automation/smoke` 需包含 `External MCP/RAG integration readback`，`/api/ai-automation/scheduled-health-summary` 需輸出 `external_mcp_rag_integration` family。`MCP_ROUTER_ENABLED=false` 或 `RAG_ENABLED=false` 必須被視為 runtime gap，不得因 registry 已完成就宣稱 MCP/RAG runtime 已全面啟用。
- 2026-07-09 起 PixelRAG visual receipts 必須可轉為內部 RAG candidate replay readback：`/api/ai-automation/pixelrag-rag-candidate-replay` 與 `scripts/ops/report_pixelrag_rag_candidate_replay.py` 只讀 `capture_receipt.json`，拆分 eligible / blocked / invalid receipts，輸出 tile/missing/barrier count、candidate text、promotion boundary 與 next machine action；`/api/ai-automation/smoke` 需包含 `PixelRAG RAG candidate replay`，`/api/ai-automation/scheduled-health-summary` 需輸出 `pixelrag_rag_candidate_replay` family。blocked / 403 / captcha / access denied / verify traffic page 只能進 platform probe 或 structured API 策略，不得當作商品資料、不得寫正式價格表、不得直接寫 `ai_insights`。
- 2026-07-09 起 PixelRAG visual receipts 進入 OCR/VLM 前必須先輸出 no-write replay contract：`/api/ai-automation/pixelrag-ocr-vlm-replay` 與 `scripts/ops/report_pixelrag_ocr_vlm_replay.py` 只讀 saved tiles，輸出欄位 schema、輸出 schema、confidence/evidence validation rules、Ollama-first route contract 與 next machine action；`/api/ai-automation/smoke` 需包含 `PixelRAG OCR/VLM replay contract`，`/api/ai-automation/scheduled-health-summary` 需輸出 `pixelrag_ocr_vlm_replay` family。此 contract 不執行 OCR/VLM、不呼叫模型、不讀 secret、不連外、不寫 DB、不寫 `ai_insights`、不寫正式價格表；blocked / 403 / captcha / access denied / verify traffic page 只能進 platform probe 或 structured API 策略。
- 2026-07-09 起 PixelRAG 可整合/可運用範圍必須有機器可讀 application portfolio：`/api/ai-automation/pixelrag-application-portfolio` 與 `scripts/ops/report_pixelrag_application_portfolio.py` 需輸出 commerce、RAG、UX、ops、marketing、governance lanes，每條 lane 必須包含 priority、status、integrates_with、use_cases、current_capability、next_machine_action、no-write 邊界與 forbidden guardrails。此 portfolio 不抓外站、不呼叫模型、不讀 secret、不寫 DB；其用途是把「還可以整合哪些」變成可排程、可驗證、可拒絕違規場景的主線工作項目。
- 2026-07-09 起 PixelRAG ready receipts 必須有 Ollama-first VLM replay worker：`/api/ai-automation/pixelrag-vlm-replay-worker` 與 `scripts/ops/run_pixelrag_vlm_replay_worker.py` 預設 dry-run，`execute=true&write_receipt=true` 才呼叫 approved Ollama VLM route 並寫 artifact receipt；`/api/ai-automation/smoke` 需包含 `PixelRAG VLM replay worker`，`/api/ai-automation/scheduled-health-summary` 需輸出 `pixelrag_vlm_replay_worker` family。此 worker 不讀 secret、不寫 DB、不寫 `ai_insights`、不寫正式價格表；blocked / 403 / captcha / access denied receipt 自動跳 platform probe 或 structured API，ready receipt 的 VLM 結果仍須 identity matcher replay 與 PromotionGate 才能進候選知識層。
- 2026-07-09 起 PixelRAG VLM route readiness 必須在 execute 前可讀回：`/api/ai-automation/pixelrag-vlm-route-readiness` 與 `scripts/ops/report_pixelrag_vlm_route_readiness.py` 只讀 approved Ollama `/api/tags`，輸出 configured model、candidate model、reachable host、model_route_ready 與 next machine action；`/api/ai-automation/smoke` 需包含 `PixelRAG VLM route readiness`，`/api/ai-automation/scheduled-health-summary` 需輸出 `pixelrag_vlm_route_readiness` family。此 readback 不呼叫 `/api/generate`、不讀 secret、不寫 DB；worker execute 必須使用它自動避開缺模型路由，完全缺候選時寫 `model_route_not_ready` artifact receipt。
- 2026-07-10 起 PixelRAG platform probe 必須把 blocked / interstitial receipt 轉成機器可執行下一步：`/api/ai-automation/pixelrag-platform-probe` 與 `scripts/ops/report_pixelrag_platform_probe.py` 需讀取 capture receipts 與 VLM replay receipts，辨識 Shopee language / region / generic marketplace slogan / traffic verification 與 Coupang 403 / access denied，輸出 public browser context probe、structured source fallback、platform backoff、blocked page not product data 與 no-write 邊界；`/api/ai-automation/smoke` 需包含 `PixelRAG platform probe readiness`，`/api/ai-automation/scheduled-health-summary` 需輸出 `pixelrag_platform_probe` family。此 readback 不抓外站、不讀 secret/cookie/session、不寫 DB、不寫 `ai_insights`、不寫正式價格表；capture worker 可消化 `public_browser_context` 的 locale/timezone/Accept-Language，但必須濾掉 Cookie、Authorization、token/secret/key 類 header。
- 2026-07-10 起 PixelRAG platform probe 必須有 controlled worker：`/api/ai-automation/pixelrag-platform-probe-worker` 與 `scripts/ops/run_pixelrag_platform_probe_worker.py` 預設 dry-run，`execute=true&write_receipt=true` 才會對 Shopee language / traffic / generic landing 執行 public empty-context capture，並對 Coupang 403 / access denied 自動產生 structured-source/backoff artifact receipt；`/api/ai-automation/smoke` 需包含 `PixelRAG platform probe worker`，`/api/ai-automation/scheduled-health-summary` 需輸出 `pixelrag_platform_probe_worker` family。此 worker 不登入、不讀 cookie/session/secret、不寫 DB、不寫 `ai_insights`、不寫正式價格表；capture 成功後下一步固定為 RAG candidate replay，structured fallback 只產生機器可讀 package，不把 blocked page 當商品資料。
- 2026-07-10 起 PixelRAG platform probe worker 必須自動處理 capture runtime gap：若 production app 容器缺 Playwright，`execute=true&write_receipt=true` 不得退回人工審核或 critical dead-end；worker 必須寫 `capture_runtime_unavailable_structured_fallback_package` artifact receipt，標記 `network_call=false`、`writes_database=false`、`primary_human_gate_count=0`，並把下一步改為 `run_structured_source_or_install_pixelrag_capture_runtime`。
- 2026-07-10 起 PixelRAG marketplace source-contract adapter dry-run 必須是正式 smoke/scheduled family：`/api/ai-automation/pixelrag-marketplace-source-contract-adapter-dry-run` 與 `scripts/ops/run_pixelrag_marketplace_source_contract_adapter_dry_run.py` 預設只讀 adapter preflight receipts 並做 deterministic mapping readiness；`execute=true&write_receipt=true` 只寫 `marketplace_adapter_dry_run_receipt.json` artifact，輸出 field contracts、offer candidate contracts、identity matcher / PromotionGate / embedding signature gates 與 no-write 邊界。此 worker 不抓外站、不呼叫模型、不讀 secret/cookie/session、不寫 DB、不寫 `ai_insights`、不寫正式價格表；dry-run receipt 只允許進 identity matcher replay，不得直接進價格表或候選知識層。
- 2026-07-10 起 PixelRAG marketplace identity matcher replay 必須是正式 smoke/scheduled family：`/api/ai-automation/pixelrag-marketplace-identity-matcher-replay` 與 `scripts/ops/run_pixelrag_marketplace_identity_matcher_replay.py` 預設只讀 adapter dry-run receipts 並產生 deterministic identity key / match contract；`execute=true&write_receipt=true` 只寫 `marketplace_identity_matcher_replay_receipt.json` artifact，輸出 identity candidate contracts、source provenance、PromotionGate readiness 與 no-write 邊界。此 worker 不抓外站、不呼叫模型、不讀 secret/cookie/session、不寫 DB、不寫 `ai_insights`、不寫正式價格表；identity replay receipt 只允許進 PromotionGate replay，不得直接進價格表或候選知識層。
- 2026-07-10 起 PixelRAG marketplace PromotionGate replay 必須是正式 smoke/scheduled family：`/api/ai-automation/pixelrag-marketplace-promotion-gate-replay` 與 `scripts/ops/run_pixelrag_marketplace_promotion_gate_replay.py` 預設只讀 identity matcher receipts 並產生 deterministic PromotionGate contract；`execute=true&write_receipt=true` 只寫 `marketplace_promotion_gate_replay_receipt.json` artifact，輸出 promotion candidate contracts、embedding signature guard readiness、source provenance 與 no-write 邊界。此 worker 不抓外站、不呼叫模型、不讀 secret/cookie/session、不寫 DB、不寫 `ai_insights`、不寫正式價格表；PromotionGate receipt 只允許進 embedding signature guard replay，不得直接進價格表或候選知識層。
- 2026-07-10 起 PixelRAG marketplace embedding signature guard replay 必須是正式 smoke/scheduled family：`/api/ai-automation/pixelrag-marketplace-embedding-signature-guard-replay` 與 `scripts/ops/run_pixelrag_marketplace_embedding_signature_guard_replay.py` 預設只讀 PromotionGate receipts 並產生 deterministic embedding signature guard contract；`execute=true&write_receipt=true` 只寫 `marketplace_embedding_signature_guard_replay_receipt.json` artifact，輸出 expected embedding signature、signature guard contracts、candidate knowledge replay readiness 與 no-write 邊界。此 worker 不產生 embedding、不抓外站、不呼叫模型、不讀 secret/cookie/session、不寫 DB、不寫 `ai_insights`、不寫正式價格表；embedding signature guard receipt 只允許進 candidate knowledge replay，不得直接進價格表或正式知識層。
- 2026-07-10 起 PixelRAG marketplace candidate knowledge replay 必須是正式 smoke/scheduled family：`/api/ai-automation/pixelrag-marketplace-candidate-knowledge-replay` 與 `scripts/ops/run_pixelrag_marketplace_candidate_knowledge_replay.py` 預設只讀 embedding signature guard receipts 並產生 deterministic internal RAG candidate knowledge contract；`execute=true&write_receipt=true` 只寫 `marketplace_candidate_knowledge_replay_receipt.json` artifact，輸出 candidate knowledge text、internal RAG preview readiness、source provenance 與 no-write 邊界。此 worker 不產生 embedding、不抓外站、不呼叫模型、不讀 secret/cookie/session、不寫 DB、不寫 `ai_insights`、不寫正式價格表；candidate knowledge receipt 只允許進 internal RAG candidate canary，不得直接進正式知識層或價格表。
- 2026-07-02 起 `/ai_intelligence` 商品明細與單品作戰詳情的四格價格證據必須可測：PChome 價格、MOMO 參考價、差距、可信度需以 `data-evidence` 固定，並以 `aria-label="價格證據"` 對應可掃描區塊；候選待確認或缺資料只能顯示「候選待確認 / 待補」，不得捏造價格或讓使用者打開 raw payload 才知道判斷依據。
- 2026-07-02 起 `/ai_intelligence` 必須是密集 AI 工作台，不得退回大段文字說明頁：首屏與明細可見內容只保留短狀態、數字、四格證據與下一步按鈕；KPI note、benchmark detail、alert 副句、策略說明、decision copy、來源長句與單品 reason list 不得佔用第一層視覺。`tests/test_ai_intelligence_text_density_guardrails.py` 必須鎖住 `data-density-guardrail="compact-ai-workbench"`、短任務文案、detail meta 與 hidden explanatory copy。
- 2026-07-02 起 `/observability/overview` 也必須採密集 AI 觀測工作台：首屏以 `data-density-guardrail="compact-observability-workbench"`、`AI 觀測 / 風險優先 / 下一步` 與 golden signals 先呈現狀態、數字與操作入口；hero lede、signal note、route desc、host meta 與資料來源長句不得佔用第一層視覺。`tests/test_observability_text_density_guardrails.py` 必須鎖住 compact marker 與 hidden explanatory copy。
- V10.644 起 `/ai_intelligence` 的商品明細列不得只用句子描述比價；每列必須顯示 PChome 價格、MOMO 參考價、差距、可信度四格價格證據，並保留下一步按鈕。單位價候選需顯示單位價與單位，候選待確認或缺資料則以「待補 / 候選待確認」呈現，不得捏造價格。
- V10.645 起 `/ai_intelligence` 的商品明細分流切換後，必須顯示「這類商品怎麼處理」的行動摘要，包含件數、近 7 天業績、平均可信度、最大價差、代表商品與主按鈕；使用者不得只能看到商品列表而不知道下一步。
- V10.646 起 `/ai_intelligence` 的商品明細必須提供搜尋與排序；搜尋至少涵蓋商品、分類、商品編號與 MOMO 候選資訊，排序至少支援優先級、近 7 天業績、價差、下滑幅度與可信度。搜尋/排序後的行動摘要與明細列表必須使用同一批結果。
- V10.647 起 `/ai_intelligence` 的商品明細每一筆都必須能打開單品作戰詳情，詳情需顯示商品、建議動作、近 7 天業績、業績變化、PChome/MOMO 價格證據、價差、可信度、判斷原因與下一步操作；不得只讓使用者看一排文字後自行猜測。
- V10.648 起 `/ai_intelligence` 的商品明細上方必須提供分類策略看板，把商品依分類彙總成可點擊的數據條列；每列至少顯示分類、近 7 天業績、商品數、價格壓力、價格優勢、缺比價、待確認與建議下一步。點擊分類後必須切到該分類商品明細。
- V10.649 起 `/ai_intelligence` 必須提供銷售策略建議看板，把商品分成價格防守、主推曝光、組合/單位價、資料補齊等營運路徑；每張策略卡需顯示件數、近 7 天業績、代表商品與可點擊下一步，點擊後必須切到對應商品明細。
- V10.650 起 `/ai_intelligence` 必須提供「今日策略動作」清單，從作戰商品中挑出前 5 件具體行動；每列需顯示處理順序、動作、商品、近 7 天業績、原因與可點擊的詳情/處理入口，避免使用者只看到分類與策略後仍不知道下一步要做哪一件商品。
- V10.651 起從「今日策略動作」或其他非明細列入口打開單品作戰詳情時，商品明細列表中的對應商品仍必須標示為目前選取；使用者需能看出詳情與明細列的關聯。
- V10.652 起正式首頁 `/` 必須顯示「PChome 業績成長自動化作戰系統」，舊商品看板僅保留在 `/dashboard` 或 `/product-dashboard`；「今日策略動作」必須放在首屏任務摘要後方，不能只藏在商品明細區；每列必須直接顯示價格證據，至少包含 PChome、MOMO、差距與可信度四格。候選待確認或缺資料時需以待確認/待補呈現，不得要求使用者先打開詳情才知道判斷依據。
- V10.654 起全站側邊欄第一個主入口必須命名為「業績成長指揮台」；舊商品看板只能以「舊商品看板」保留在 `/dashboard`，比價工作台必須直連 `/dashboard?filter=pchome_review...`，不得再使用 `/` query 轉址，避免正式首頁與舊頁混淆。
- V10.655 起正式首頁 `/` 必須以 HTTP 200 原地渲染「業績成長指揮台」，不得 302 跳轉到 `/ai_intelligence`；側邊欄第一個主入口必須直連 `/`。`/ai_intelligence` 只作為相容入口保留，不得成為主導流路由。
- V10.656 起正式首頁首屏必須是「PChome 業績成長系統」專業儀表板，而非大段說明型頁首；第一屏需直接呈現近 7 天業績、同款比價證據、下滑商品、待補同款、正式資料平台、下滑商品 TOP 5、比價覆蓋圓環與處理狀態，且全部使用 `/api/ai/pchome-growth/opportunities` 真資料渲染。
- V10.789 起首頁禁止用無分母的「比價可用率」代表全站資料品質。`comparison_metric_contract.version=pchome_comparison_coverage_v2` 必須分開公布 TOP 高優先商品、近七日活躍商品與正式 runtime 平台三個 scope 的分子、分母與比率；`comparison_ready`、`candidate_validation`、`unmatched` 必須互斥且總和等於候選數。業績過期時 `operational_decision.ready=false`，UI 顯示決策暫停但保留歷史證據，不得把 stale 數字包裝成今日建議。`momo-scheduler` 必須以獨立防重入 watchdog 依序執行授權業績取得與 bounded comparison backfill，避免同步 `schedule.run_pending()` 被長任務阻塞後讓比價覆蓋永久停滯。
- V10.658 起全站頁面必須回到「提升 PChome 業績」同一產品主線；共用 shell 需提供短流程骨架：評估、分析、建議、解法、治理。頁首、hero、任務卡與提示區不得依賴大段文字讓使用者理解狀況；首屏應以短指標、狀態分流、下一步動作與可執行入口呈現專業評估、分析、建議與解決方案。
- V10.659 起主要入口頁的首屏文案必須改為流程職責語言，而不是功能說明書。當日業績負責找出下滑與價差壓力，匯入負責資料新鮮度，AI 建議負責把證據轉成銷售建議，比價負責同款與價差決策，缺貨負責避免主推商品斷貨，月結分析負責判斷成長、毛利與品類結構。

## 零之一、12 Agent 決策信封（2026-05-24）

- 12 角色分工不作為 12 個常駐模型；在產品層統一收斂成 `decision_envelope`，由 Hermes / NemoTron / OpenClaw / ElephantAlpha 與 AI 例外決策、PPT QA、競品 review queue 共用。
- `decision_envelope` 必須至少能表達：`decision_type`、`severity`、`evidence[]`、`recommended_action`、`expected_impact`、`confidence`、`guardrails`、`trace`。
- `guardrails.can_auto_execute=false` 是預設；價格調整、正式比價覆寫、PPT 發送與修復執行都必須遵守 AI 例外決策或既有 service guard，不得因 Agent 信心高就繞過 matcher / feeder / review service。
- 證據不足時不得輸出空泛效益預測；必須標記 `data_quality=missing|partial|stale`，並把建議行動降級成 `human_review`、`needs_research` 或 `silence_alert`。
- Telegram `triaged_alert()` 已支援渲染 `decision_envelope`，讓告警固定呈現嚴重度、證據、建議行動、預期影響、信心度與追蹤 ID；後續觀測台與 PPT 也應共用同一份欄位語意。
- NemoTron `price_alert` / `human_review` 派發會把同款證據、價差、七日銷量變化、營收流失、AI 例外決策 邊界與資料品質寫入同一份 `decision_envelope`，並同步放入 EventRouter event 與 KM metadata；12 Agent 後續只能沿用此信封補充分析，不得繞過 matcher / feeder / review service 直接改價或覆寫比價資料。
- EventRouter / Telegram 的 AI 例外決策 callback 必須優先使用 `decision_envelope.decision_id` 作為事件追蹤 ID；若上游未帶 `event.id`，`triaged_alert()` 仍會用 `decision_id` 產生 `momo:eig:*` callback，避免價格決策審核落成 `unknown`。所有 `momo:eig:*` callback 必須以 UTF-8 byte-safe 截斷，確保 `callback_data` 不超過 Telegram 64-byte 限制。
- 競品比價相關的 Agent 建議只能讀 `competitor_match_attempts` / review queue / `competitor_prices` 的既有證據；不得直接寫 `competitor_prices` 或覆蓋 `_should_upsert_competitor_price()` 的保護規則。
- 已帶 `decision_envelope` 的價格/覆核事件必須由 EventRouter 直接渲染證據模板，不再進 L1/L2 AI 重新摘要；Telegram 決策信封需顯示標的 SKU、商品名稱、PChome 候選、evidence、guardrails 與 AI 例外決策 動作，避免已有實證的比價告警被二次生成文字稀釋或造成額外模型成本。
- PChome 覆核隊列本身也必須輸出 `decision_envelope`：`fetch_competitor_review_queue()`、`fetch_competitor_review_queue_page()` 與 `/api/pchome-review/queue` 的每筆候選需帶相同的 `subject`、`evidence`、`recommended_action`、`expected_impact` 與 `guardrails`，供 Dashboard、Agent、Telegram 與 PPT 共用；任何下游不得另寫一套比價狀態翻譯或繞過 AI 例外決策 guardrails。
- Dashboard 覆核卡與 `/api/export/excel/pchome-review` 也必須顯示/匯出 `decision_envelope` 的等級、資料品質、建議代碼、AI 例外決策、trace 與 `can_auto_execute=false` 邊界；操作員離開系統畫面或下載 Excel 後，仍要看得到「不可自動寫正式價差」的 guardrails。
- OpenClaw 週報/日報/月報與 competitor PPT 不得再各自重算或翻譯 PChome 覆核狀態；必須透過 `competitor_intel_repository.summarize_review_decision_envelopes()` 讀取同一份 `decision_envelope` 摘要，並在 prompt / data_summary / KPI slide 保留 AI 例外決策與 `can_auto_execute=false` 邊界。
- Webcrumbs / Shared UI host data 也必須透過 `summarize_review_decision_envelopes()` 輸出 `reviewDecisionBrief`，並在 metadata 保留 review queue、AI 例外決策、auto-execute-blocked、`decision_support_rate`、`catalog_comparable_count` 與 catalog review lane counts；不得另寫一套 PChome 覆核摘要或在前端 runtime 重新推論價格行動。
- ElephantAlpha 的 `resource_optimization` 與低信心 `ea_escalation` 也必須輸出 `decision_envelope`：資源壓力信封只能使用 `action_plans`、CPU 實測、hygiene 結果與 insight/action trace，不得加入 LLM 預測效益；`triaged_alert()` 對 `ea_escalation` 亦需渲染信封並以 `decision_id` 作為 callback 追蹤 ID。

## 一、四 AI Agent 路由架構

```
SQL漏斗(~300筆)
     ↓
[Hermes 3 8B] — 分析師 (Ollama 三主機級聯, 零成本)
  模型: hermes3:latest @ GCP-A → GCP-B → 111
  任務: 競價威脅分類 → TOP 20 HIGH/MED/LOW
     ↓
[NemoTron / qwen3] — 派發器
  主路徑: qwen3:14b @ GCP-A/GCP-B；落到 111 時自動降級 llama3.2
  備援: NVIDIA NIM meta/llama-3.1-8b-instruct
  任務: Tool Calling → Telegram 告警 / DB 寫入
     ↓
[OpenClaw] — 策略師 (Ollama-first；Gemini 僅備援 / 鎖定場景)
  任務: 週策略報告、洞察報告、L3 AI 例外決策 建議
     ↓
[ElephantAlpha] — 編排者 (L3 Orchestrator)
  任務: 跨 Agent orchestration、AI 例外決策、AutoHeal bridge、受控 log scan
```

### 1.1 PChome 挑品 Agent（2026-05-01）

`services/ai_product_pick_agent.py` 新增 PChome 銷售用挑品 Agent：

- 只讀真實資料表：`products`、`price_records`、`competitor_prices`、`competitor_price_history`，若 `daily_sales_snapshot` 可用則納入近 7 天銷售額、數量、毛利或成本推算毛利率。
- 將 PChome 比 MOMO 有價格優勢、比對信心足夠、且有歷史快照或銷售動能的品項寫入 `ai_price_recommendations`。信心度不以固定倍率灌高，而是由商機分數與證據完整度共同決定，證據包含 PChome match score、歷史快照、銷售/毛利、PChome 商品 ID/名稱、抓取時間與促銷/評價/庫存標籤。每次重算只保留最新 50 品為 `status='pending'`，未進榜舊品標為 `superseded`，避免統計與清單超量。
- 寫入策略使用 `strategy='product_pick'`，保留在既有 AI 決策表，不新增假頁面或暫存 JSON。
- 後台入口：`POST /api/ai/product-picks/generate`，`/ai_intelligence` 可手動產生清單。
- 配對來源仍以 PChome crawler 真實搜尋結果為準；無競品資料時不生成挑品。
- 比對覆蓋率補強入口：`POST /api/ai/pchome-match/backfill`，優先補抓仍無有效 PChome 配對的高價 ACTIVE 商品，完成後自動重算 AI 挑品清單。
- 過期價格刷新入口：`POST /api/ai/pchome-match/refresh-stale`，只針對已建立 `identity_v2` 但 `expires_at` 過期的 PChome product_id 執行 `run_expired_identity_refresh()`；不得跑 fresh search recovery，不得呼叫 LLM，完成後重算 AI 挑品並清除 Dashboard / competitor intel cache。
- 過期 identity 搜尋救援入口：`POST /api/ai/pchome-match/recover-stale` 預設必須關閉主操作入口，僅保留只讀 preview；正式 smoke 顯示小批次成功率不足且耗時偏高時，不得在 Dashboard 顯示日常操作按鈕。若需操作員手動執行，必須先明確設定 `PCHOME_STALE_RECOVERY_ENABLED=true`，再對已過期 `identity_v2` 先走既有 PChome product_id refresh；只有舊 ID 查無商品或重評低於門檻時，才允許受控 fresh search recovery。救援隊列必須先排除 variant、catalog、commercial condition、count、bundle、unit-price 與任選 / 多款 / 香味 / 色號 / 即期 / 融燭燈 / 香氛蠟燭 / `+` / `xN` / `*N` / 具名香味或膚感版本等高風險名稱訊號。這條路徑可抓 PChome，但不得呼叫 LLM；正式寫入仍必須通過 matcher、hard veto、auto price write safety 與 overwrite protection。
- 補抓狀態入口：`GET /api/ai/pchome-match/backfill/status` 除背景任務狀態外，必須回傳 read-only coverage snapshot：`active_with_price` / `valid_matches` / `match_rate` / `fresh_matches` / `fresh_match_rate` / `decision_ready_matches` / `decision_ready_rate` / `stale_matches` / `pending` / `actionable_review_count`，供 Dashboard 顯示目前該刷新過期價格或補抓未搜尋商品；此端點不寫 DB、不呼叫 LLM、不抓外站。`match_rate` 是身份覆蓋率，`fresh_match_rate` 是已配對 identity 內的新鮮比例，`decision_ready_rate` 才是可直接進入決策、圖表與簡報的 ACTIVE 商品比價覆蓋率。
- 排程閉環：`run_pchome_match_backfill_task` 每日 10:30 執行，補抓 PChome 待比對商品、寫入歷史價格，再重算 `strategy='product_pick'` 清單。
- 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` 可直接查看需 AI 例外處理的比價覆核 SKU，並以 DB 分頁支援 search/category/status 後的完整隊列，不得只截前 50 筆。覆核狀態篩選必須至少包含全部、需單位價、已排除、低信心、價格過期、找不到同款與 AI 例外閉環，讓 AI 可依 matcher 診斷類型分批處理。列內顯示候選 PChome 商品、候選價、match score、單位價換算摘要、AI 例外動作與 matcher 診斷原因標籤（品牌不符、商品線不符、容量差異、組合差異、需單位價、價差極端等），不得只顯示籠統「待比對」。`/api/export/excel/pchome-review` 必須匯出同一套覆核隊列、AI 例外處置、候選 PChome、單位價比較與原始診斷，讓 AI 例外決策、簡報與後續 AI 分析共用同一份證據。`/api/pchome-review/<sku>/decision` 是AI 例外閉環入口：`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 灰區候選卡掉後續更精準搜尋詞。AI 例外 `reject_identity`、`unit_price_required`、`needs_research` 若命中當前正式候選，必須將同候選 `competitor_prices` 過期，不得繼續顯示正式總價差。商品列表必須將 `manual_rejected`、`manual_unit_price_required`、`manual_needs_research` 顯示為明確AI 例外閉環狀態，不可回落成籠統「待比對」。`fetch_competitor_coverage()` 必須輸出AI 採用、AI 否決、AI 單位價與採用率，daily/growth/PPT 共用 payload 必須顯示AI 例外閉環成效，避免只呈現待審數。商品看板深度快取同時寫入 `data/dashboard_full_cache.pkl`，供多個 Gunicorn worker 共用，避免部署後各 worker 重複重建 7,000+ 商品統計造成開頁變慢；所有資料異動與 AI 挑品重算都透過 `clear_dashboard_cache()` 同步清除記憶體與共享快取，手動重算 API 會立即預熱商品看板快取，避免第一位使用者承擔重建成本。
- PChome re-score 回收線：`rescore_accepted_current` 只能表示最新版 matcher 判定「值得AI 例外決策身份」，不可直接寫入正式 `competitor_prices`；`no_match`、`price_basis=none`、`alert_tier=suppress`、`variant_selection_review` 不得進入此隊列。`fetch_competitor_coverage()` 必須輸出 `rescore_accepted_count`，Dashboard、daily/growth 與 OpenClaw 競品摘要都要把「重算待 AI 例外決策」獨立呈現，避免和一般低信心/單位價覆核混在一起。
- PChome 低信心操作分流：Dashboard 與 read-only `/api/pchome-review/queue` 必須把近門檻可救、證據不足、低信心舊候選拆成 `recoverable_low_score`、`true_low_confidence`、`legacy_low_score` 三個可篩選桶；廣義 `low_score` 僅作 repository/export 相容查詢，不可在 UI 中冒充單一操作分流。
- PChome coverage 的 `attempt_status` / `rescore_accepted_count` / `actionable_review_count` 口徑必須與 review queue 對齊：統計「沒有新鮮有效 identity」的商品，而不是只統計「完全沒有 identity」的商品；已過期但可重算採用的 stale identity 仍應出現在待審數字中，避免 API 與 Dashboard 漏報。
- `run_retryable_candidate_revalidation()` 的自動回刷主戰場仍限 `low_score` / `refresh_low_score` / `recoverable_low_score`；`true_low_confidence` 只有在已補 focused exact 規則的窄範圍品線、舊分數 >= 0.95、`comparison_mode='exact_identity'`、含 `strong_exact_spec_match` 且不含 commercial / variant / count / bundle / refill 等阻擋理由時，才可進入重評，不得全面打開AI 例外池。`rescore_accepted_current` 只允許命中具名 focused exact 品線、舊分數 >= 0.76、且仍無 hard veto / 阻擋理由時進窄門回刷；最後仍由最新版 matcher 判定是否可寫正式價差，像不同指甲油型號 / 色號必須 hard veto。
- 高分 `true_low_confidence` 的自動救回只能用具名 focused exact 線逐批擴充；同品牌、同品線、同規格/同組合的花美水 Relax、St.Clare 私密呼呼、BIOPEUTIC 果酸、台塑生醫嬰兒沐浴洗髮、Elizabeth Arden 八小時護唇膏與理膚寶水全面修復潤唇膏可走 total-price，色號、香味、款式、即期品與 catalog selection 仍維持 review / veto。
- `true_low_confidence` focused exact 線必須同步接入 `run_retryable_candidate_revalidation()` 的 SQL 窄門，讓舊候選可被批次回收；該窄門只允許具名品線豁免 `variant_selection_review`，其他 hard veto / 型別、款式、香味、件數、組合、refill、commercial condition 阻擋仍不得回刷。
- 任選 catalog focused exact 只允許雙方都明確是同品線任選賣場且規格一致的窄範圍案例，例如 FLORTTE 眼線液筆 0.5ml、露得清護手霜 56g 無香/有香、Kanebo ALLIE 持采亮化 UV 防曬水凝乳 60g；若有 `commercial_condition_gap`（即期品、短效、航空版等狀態差異），focused bypass 不得移除 `variant_selection_review`，不得自動寫正式價差。
- O.P.I 指彩救回只允許同品牌、同 `類光繚` / `如膠似漆` 指甲油或指彩線，且共享 `ISL...` 精準型號 token 的案例自動走 total-price；不同型號/色號仍維持人工或 veto。此規則可接入 `true_low_confidence` revalidation 窄門，但不得變成「同品線即通過」。
- 其他正式覆核池 focused exact 線只能針對「已在正式頁面反覆出現且有硬規格」的窄範圍族群，例如 The Ordinary 咖啡因 EGCG、Natures Care 綿羊油同入數、TOMOON 指甲剪同尺寸、HH 雙 200ml 組、SEBAMED 200ml x2、YES 9cm 剪刀；同尺寸、同入數、同組合或單側漏規格必須可由 matcher 明確判斷，不能只因同品牌同品線通過。
- `/api/ai/pchome-match/backfill/status` 必須把近門檻重評池與過期 identity 救援池以只讀 `revalidation_preview` / `stale_recovery_preview` 曝光給操作員；預覽只復用正式候選 SQL 並受 limit / 60 秒快取限制，不啟動 PChome 搜尋、不呼叫 LLM、不寫 `competitor_match_attempts` / `competitor_prices`。重評 preview 必須先從最新 `competitor_match_attempts` 縮小候選，再用 `JOIN LATERAL` 取單一最新 MOMO 價；救援 preview 必須從過期 `competitor_prices` 小集合出發並用 `JOIN LATERAL` 取最新 MOMO 價，兩者都不得掃全量 `price_records`；Dashboard 只能顯示「可救援」觀測值，不得在未開啟 `PCHOME_STALE_RECOVERY_ENABLED` 時提供 recover-stale 執行按鈕；其中 `review_gated_count` 僅代表窄門 `true_low_confidence` exact 候選，不得被解讀為全量人工池可自動回刷。
- PChome re-score audit 預設必須先取每個 SKU 的最新 `competitor_match_attempts` 狀態，再套用 status / reason 篩選；舊低信心歷史候選只能透過 `--include-historical-candidates` 明確進入考古掃描，避免已入隊、已否決或已修正 SKU 被舊紀錄重新推回報表。
- production re-score `--apply-accepted` 僅可追加 `rescore_accepted_current` attempt 給 AI 例外決策；執行後需清除 Dashboard / competitor intel cache，且必須抽查 `competitor_prices` / `competitor_price_history` 未新增正式價差。
- production re-score 若曾把 `variant_selection_review` 追加成 `rescore_accepted_current`，必須用 `audit_competitor_match_attempt_rescore.py --retract-variant-accepted` 追加最新 `true_low_confidence` 退回列；此路徑只寫 `competitor_match_attempts`，不得刪歷史紀錄，也不得寫 `competitor_prices` / `competitor_price_history`。
- PChome matcher replay 必須先守住假陽性：`EX8` 等型號不可被誤解析成 `x8` 入數；香氛固體凝膠 / 空氣芳香劑若一側為泛稱、一側含明確香味或 No. 款式，必須走 `aroma_scent_variant_conflict` veto，不得因同品牌同重量直接寫正式價差。
- PChome matcher 對「同規格同數量」的多件組可以安全回收，但必須同時滿足：商品型別完全對齊、品牌同線、規格與數量對齊、沒有 variant / count / bundle / commercial / unit-price / price-ratio 阻擋理由，才可打 `safe_multi_component_exact_total_price` 並進 `exact / total_price / price_alert_exact`；混合組、香味款、色號款、catalog 任選仍需留在 `identity_review` 或 veto。護唇品 focused total-price 僅允許已明確建規則的 DHC 純欖 1.5g、FRUDIA 蜂蜜藍莓 10g、SEBAMED 嬰兒護唇膏 4.8g x2、理膚寶水滋養修護潤唇膏 4.7ml，不得把所有 lip/cosmetic catalog 一次放行。
- PChome feeder 正式寫入必須再套一層價格資料閘門：只有 `match_type='exact'`、`price_basis='total_price'`、`alert_tier='price_alert_exact'` 且無 `variant_selection_review` 的結果可以自動寫入 `competitor_prices`；`manual_review` / `identity_review` 只能留在覆核隊列或AI 採用流程，不得由 retryable replay 或 known identity refresh 自動升成正式價差。Rescore audit 若遇到 `variant_selection_review`，也不得產生 `accepted_current`。

| 角色 | 模型 | 主機 | 成本 | 每日限額 |
|------|------|------|------|---------|
| Hermes 分析師 | hermes3:latest / bge-m3 | GCP-A → GCP-B → 111 Ollama | 零 | 無限 |
| NemoTron 派發器 | qwen3:14b；111 fallback 降級 llama3.2；NIM fallback | GCP-A → GCP-B → 111；NVIDIA NIM 備援 | Ollama 零；NIM 配額內免費 | NIM 80 |
| OpenClaw 策略師 | qwen2.5-coder:7b / qwen3:14b；111 fallback 降級 llama3.2 | Ollama-first；Gemini emergency fallback only | Ollama 零；Gemini 預設封鎖 | — |
| ElephantAlpha 編排者 | ElephantAlpha | 依部署環境 | 受控 | AI 例外決策 / 任務制 |

---

## 一之一、AI 自動化閉環實況（2026-04-29）

```text
事件 / 排程失敗 / code review finding
  → EventRouter 分流、去重、降級
  → Hermes L1 摘要或 NemoTron L2 tool calling
  → L2 SAFE_ACTIONS / AutoHeal / OpenClaw memory
  → Telegram 通知，失敗則 file queue，成功後 replay
  → ai_insights + embedding_retry_queue
  → OpenClaw / ElephantAlpha 後續策略與 AI 例外決策
```

硬性邊界：

- EventRouter 是告警與 L2 safe action 的入口。
- AutoHeal 是自癒副作用入口。
- `momo-db` / `momo-postgres` 不可被 AI 自動 restart / stop / recreate。
- raw `ai_insights` insert 必須接 `enqueue_insight_embedding()` 或可被 backfill。
- ElephantAlpha 只做編排與 bridge，不可繞過 ADR-011 / ADR-012 / ADR-013。
- ElephantAlpha / NemoTron 不可直接執行商品價格調整；`execute_price_adjustment`、`adjust_price` 等動作必須攔截並寫入 `human_review`，等待人工核准。

可觀測性：

- `/metrics` 匯出 `momo_ai_event_router_dispatch_total`。
- `/metrics` 匯出 `momo_ai_event_router_latency_ms_count/sum/max`。
- `/metrics` 匯出 `momo_ai_event_router_safe_action_total`。
- `/metrics` 匯出 `momo_ai_event_router_replay_total`。
- `/metrics` 匯出 `momo_ai_autoheal_action_total` 與 `momo_ai_autoheal_duration_ms_count/sum/max`。
- `/metrics` 在尚無事件時仍輸出 `momo_ai_*` zero-baseline series，讓 Prometheus/Grafana 重啟後可立即看到 metric names。
- `/ai_automation_smoke` 提供登入後 AI 自動化健康檢查頁。
- `/api/ai-automation/smoke` 提供 read-only JSON 狀態，不做外部網路呼叫。
- `/api/ai-automation/smoke` 必須包含 `PChome auto-policy authorization guard`：read-only 組裝 PChome auto-policy DB apply guard lane，檢查 no-secret、no-SQL、no-DB-write、machine-verifiable contract、`manual_review_mode=exception_only` 與 `primary_human_gate_count=0`。此 check 不做外部 fetch、不寫 DB、不發 authorization；`/api/ai-automation/scheduled-health-summary` 需輸出 `pchome_auto_policy_authorization_guard` family，`/metrics` 需暴露對應 `momo_ai_automation_scheduled_health_family_status`。
- `/api/ai-automation/smoke` 必須包含 `PChome auto-policy decision preflight`：以本機 deterministic machine evidence adapter 推進 `execute_fetch=True` 的 no-write decision preflight ready path，並明確回報 `payload_source=local_contract_fixture`、`machine_fetch_evidence_source=local_schema_fixture`、`outbound_network=false`、`business_data_source=false`、`writes_database_count=0`、`primary_human_gate_count=0`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`。此 check 不讀 secret、不執行 shell/SQL、不寫 DB、不使用外部 PChome 網路、不把 fixture 當商業資料；`/api/ai-automation/scheduled-health-summary` 需輸出 `pchome_auto_policy_decision_preflight` family，`/metrics` 需暴露對應 `momo_ai_automation_scheduled_health_family_status`。
- `/api/ai-automation/smoke` 必須包含 `PChome auto-policy decision closeout`：以本機 deterministic contract fixture 與 machine evidence adapter 推進 no-write decision closeout ready path，並明確回報 `post_apply_verifier_required_count=1`、`same_run_truth_required_count=1`、`payload_source=local_contract_fixture`、`outbound_network=false`、`business_data_source=false`、`writes_database_count=0`、`primary_human_gate_count=0`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`。此 check 不讀 secret、不執行 shell/SQL、不寫 DB、不發 apply authorization；`/api/ai-automation/scheduled-health-summary` 需輸出 `pchome_auto_policy_decision_closeout` family，`/metrics` 需暴露對應 `momo_ai_automation_scheduled_health_family_status`。
- `/api/ai-automation/smoke` 必須包含 `PChome auto-policy authorization issuer gate`：以本機 deterministic contract fixture 與 machine evidence adapter 推進 no-write issuer gate ready path，並明確回報 `required_issuer_evidence_count=9`、`nonsecret_authorization_claim_count=8`、`payload_source=local_contract_fixture`、`outbound_network=false`、`business_data_source=false`、`writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`、`secret_material_included=false`。此 check 不讀 secret、不執行 shell/SQL、不寫 DB、不簽發 apply authorization；`/api/ai-automation/scheduled-health-summary` 需輸出 `pchome_auto_policy_authorization_issuer_gate` family，`/metrics` 需暴露對應 `momo_ai_automation_scheduled_health_family_status`。
- `/api/ai-automation/smoke` 必須包含 `PChome auto-policy signing decision preflight`：以本機 deterministic contract fixture 與 machine evidence adapter 推進 no-write signing decision preflight ready path，並明確回報 `signing_decision_input_requirement_count=10`、`signing_decision_rejection_reason_count=11`、`payload_source=local_contract_fixture`、`outbound_network=false`、`business_data_source=false`、`writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`、`secret_material_required_in_preview=false`。此 check 不讀 secret、不執行 shell/SQL、不寫 DB、不簽發 apply authorization；`/api/ai-automation/scheduled-health-summary` 需輸出 `pchome_auto_policy_signing_decision_preflight` family，`/metrics` 需暴露對應 `momo_ai_automation_scheduled_health_family_status`。
- `/api/ai-automation/smoke` 必須包含 `PChome auto-policy signing decision closeout`：以本機 deterministic contract fixture 與 machine evidence adapter 推進 no-write signing decision closeout ready path，並明確回報 `signing_decision_closeout_check_count=12`、`signing_decision_input_requirement_count=10`、`signing_decision_rejection_reason_count=11`、`payload_source=local_contract_fixture`、`outbound_network=false`、`business_data_source=false`、`writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`、`secret_material_included=false`、`secret_material_required_in_preview=false`。此 check 不讀 secret、不執行 shell/SQL、不寫 DB、不簽發 apply authorization；`/api/ai-automation/scheduled-health-summary` 需輸出 `pchome_auto_policy_signing_decision_closeout` family，`/metrics` 需暴露對應 `momo_ai_automation_scheduled_health_family_status`。
- `/api/ai-automation/smoke` 必須包含 `PChome auto-policy signing issuer guard`：以本機 deterministic contract fixture 與 machine evidence adapter 推進 no-write signing issuer guard ready path，並明確回報 `signing_issuer_guard_check_count=12`、`signing_decision_closeout_check_count=12`、`signing_decision_input_requirement_count=10`、`signing_decision_rejection_reason_count=11`、`payload_source=local_contract_fixture`、`outbound_network=false`、`business_data_source=false`、`writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`、`secret_material_included=false`、`secret_material_required_in_preview=false`、`ready_for_future_signable_request_boundary=true`。此 check 不讀 secret、不執行 shell/SQL、不寫 DB、不簽發 apply authorization；`/api/ai-automation/scheduled-health-summary` 需輸出 `pchome_auto_policy_signing_issuer_guard` family，`/metrics` 需暴露對應 `momo_ai_automation_scheduled_health_family_status`。
- `/api/ai-automation/smoke` 必須包含 `PChome auto-policy signing issuer closeout`：以本機 deterministic contract fixture 與 machine evidence adapter 推進 no-write final signable request package ready path，並明確回報 `signing_issuer_closeout_check_count=12`、`signing_issuer_guard_check_count=12`、`signing_decision_input_requirement_count=10`、`signing_decision_rejection_reason_count=11`、`payload_source=local_contract_fixture`、`outbound_network=false`、`business_data_source=false`、`writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`、`secret_material_included=false`、`secret_material_required_in_preview=false`、`ready_for_future_final_signable_request_package=true`。此 check 不讀 secret、不執行 shell/SQL、不寫 DB、不簽發 apply authorization；`/api/ai-automation/scheduled-health-summary` 需輸出 `pchome_auto_policy_signing_issuer_closeout` family，`/metrics` 需暴露對應 `momo_ai_automation_scheduled_health_family_status`。
- `/api/ai-automation/smoke` 必須包含 `PChome auto-policy signing execution preflight`：以本機 deterministic contract fixture 與 machine evidence adapter 推進 no-write operator-held secret boundary preflight path，並明確回報 `signing_execution_preflight_check_count=12`、`signing_issuer_closeout_check_count=12`、`operator_held_secret_boundary_count=1`、`signing_execution_input_requirement_count=10`、`signing_execution_abort_condition_count=8`、`rollback_boundary_count=4`、`payload_source=local_contract_fixture`、`outbound_network=false`、`business_data_source=false`、`reads_secret_count=0`、`writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`secret_reference_mode=external_runtime_reference_only`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`、`secret_material_included=false`、`secret_material_required_in_preview=false`、`ready_for_future_signing_execution_preflight=true`。此 check 不讀 secret、不執行 shell/SQL、不寫 DB、不簽發 apply authorization；`/api/ai-automation/scheduled-health-summary` 需輸出 `pchome_auto_policy_signing_execution_preflight` family，`/metrics` 需暴露對應 `momo_ai_automation_scheduled_health_family_status`。
- 健康檢查 API 會將最近檢查結果保存到 JSONL，頁面顯示最近狀態趨勢。
- 健康檢查歷史支援 JSONL 匯出、清理與每日「正常 / 注意 / 嚴重」摘要。
- 健康檢查每日摘要支援手動 Telegram 推播，並由 `momo-scheduler` 每日 09:10 呼叫 `run_ai_smoke_daily_summary_task()`。
- Grafana provisioning 新增 `docker/grafana/provisioning/dashboards/json/ai-automation-overview.json`，觀測 EventRouter dispatch/latency、safe action、Telegram replay 與 AutoHeal action/duration。
- Active monitoring stack 使用 `monitoring/prometheus.yml` 的 `momo-app` job scrape `momo-pro-system:80/metrics`；Prometheus container 需加入 `momo-network`。
- Active Blackbox HTTP targets 必須探測 `/health`（188 stack 目前 `https://mo.wooo.work/health` 與 `http://momo-pro-system:80/health`；110 gateway stack 目前 `https://mo.wooo.work/health`），不可探測 Dashboard 首頁 `/`，避免監控流量觸發重型 DB 查詢。
- `/metrics` 對 `realtime_sales_monthly` 只用 raw `SELECT COUNT(*)` 取得總筆數，避免 ORM schema drift 讓 Prometheus scrape 產生 warning。
- `momo-app` 必須 bind mount `./gunicorn.conf.py:/app/gunicorn.conf.py:ro`，讓 CD sync/rebuild 後的 Gunicorn runtime 設定與 repo 保持一致。
- Gunicorn runtime 預設 `worker_class = gthread`、`GUNICORN_THREADS=4`、`preload_app = False`；此組合讓 HUP 熱重載可用，也避免 Dashboard 長查詢完全阻塞 `/health`。
- CD rebuild 模式必須先 build image 成功，再短暫 stop/rm/recreate 三應用容器，避免 no-cache build 造成長時間 502。
- ElephantAlpha 使用 NVIDIA NIM hosted API；production 預設模型為 `nvidia/llama-3.3-nemotron-super-49b-v1.5`，`ELEPHANT_ALPHA_FALLBACK_MODELS` 需保留至少一個可呼叫備援；403/404、408/409/425/429、5xx、timeout 與 connection error 必須嘗試下一個模型。
- ElephantAlpha L3 AI 例外決策 只允許發送有實證、可審核、可行動的升級告警；價格類 trigger 無 Hermes 具體威脅時，只記錄 suppressed escalation telemetry 與 cooldown，不寫 pending `human_review`，不發 Telegram 空告警。
- ElephantAlpha 價格類 trigger 的 AI 例外決策 / 決策 prefetch 必須先使用觸發 SQL 與 `competitor_prices` / `price_records` 的 DB 實證生成 SKU、MOMO / PChome 價差與建議 action lines；完整 Hermes LLM prefetch 預設關閉（`ELEPHANT_ALPHA_HERMES_LLM_PREFETCH_ENABLED=false`），避免 5s timeout 後落入無實證摘要或雲端備援。若無 DB 實證，只記錄 suppressed telemetry / cooldown，不發 Telegram 空告警。
- ElephantAlpha `price_drop_alert` / `market_opportunity` trigger 不得對整張 `price_records` 做全表最新價聚合；必須先篩最近有效 `identity_v2` PChome 候選，再用 per-SKU `JOIN LATERAL` 讀最新 MOMO 價格，並把 `match_score`、`tags`、`match_diagnostic_json` 帶入 evidence。
- ElephantAlpha 協調器收到非純 JSON、fenced JSON 或混文字 JSON 時，必須先做容錯抽取；仍無法解析時，只能使用 DB/Hermes 實證生成保守 AI 例外決策 fallback。fallback 不得放入 OpenClaw `generate_*` 類舊策略步驟，也不得暗示已自動調價。
- V10.624 起 ElephantAlpha 價格類 trigger 即使信心度達自主門檻，也只能發送 AI 例外決策 價格覆核通知；必須跳過 orchestrator `execution_plan` 內的 Hermes/NemoTron/OpenClaw 長任務 step。這是價格決策護欄：避免 60 秒 execution timeout 卡住 scheduler，也避免把價格策略誤描述為已自動執行。
- ElephantAlpha 執行器若遇到舊版 OpenClaw strategy 類步驟（含 `generate_market_strategy` / `generate_dynamic_pricing_strategy` / `generate_resource_optimization_strategy`），只能記錄為 advisory skipped，不得觸發 circuit breaker，也不得轉成實際排程、外部呼叫或價格行動。
- `resource_optimization` 不再交給 LLM 生成「預期效益 / 已執行」敘事，顯示名稱統一為「資源壓力治理」。此 trigger 必須先由程式量測 `action_plans` backlog、P1/P2 數、pending_review、逾時項目與 CPU load；只有 CPU 達門檻、P1/P2 積壓或逾時積壓才發 Telegram「資源壓力告警」。單純 queue 大但 CPU 正常只記錄 telemetry，不派發 Hermes/NemoTron、不宣稱 48 小時效益；Telegram 段落使用「系統處置紀錄」而非泛稱「已執行」，避免暗示 AI 已完成未經驗證的外部動作。
- `resource_optimization` 的 Telegram 必須包含 `decision_envelope` 區塊，標明 `source_agent=elephant_alpha`、資料品質、量測證據、`can_auto_execute=false` 與 deterministic trace；此路徑不呼叫 Gemini、不呼叫 Hermes/NemoTron，也不得把 queue backlog 翻譯成主機資源耗盡。
- `resource_optimization` 會先執行 `ActionPlanHygieneService` 清理過期噪音：只關閉超過 72 小時的 `code_review_fix` / `openclaw_recommendation` 類 advisory action_plans，以及 NemoTron `direct_response/reply_simple` 舊聊天回覆計畫；將狀態改為 `auto_disabled` 或 `rejected` 並寫入 `metadata_json.hygiene_history`。不刪資料，也不碰 NemoTron human_review / pricing / tool action 類業務行動。
- `momo-scheduler` 每 6 小時固定執行 `run_action_plan_hygiene_task()`，讓過期 advisory action_plans 的關閉不再依賴 `resource_optimization` 告警觸發；排程失敗會經 EventRouter 發送 `action_plan_hygiene_failure`。
- `action_plans` 產生端必須防重：Code Review 同一檔案已有 active `code_review_fix` 時不重建；OpenClaw recommendation 會寫入文字 fingerprint 並跳過同一建議；AIOrchestrator 不再把 NemoTron `direct_response/reply_simple` 聊天回覆存成 action plan，真正需工具、審核或執行的 NemoTron action 才能進 queue。
- OpenClaw/Hermes embedding 優先呼叫 Ollama `/api/embed`，只在舊節點不支援時 fallback `/api/embeddings`；timeout 由 `EMBEDDING_TIMEOUT` / `OLLAMA_EMBED_TIMEOUT` 控制，並受 `OLLAMA_EMBED_MAX_TIMEOUT` 封頂。背景 worker / RAG 查詢不得落 111，除非 caller 顯式允許 `allow_111_fallback=True`。
- PPT 自動產線由 `momo-scheduler` 依節奏執行 `run_ppt_auto_generation_task(schedule_kind)`：每日 20:30 產日報、週一 20:40 產週報/市場情報、每月 1 日 20:50 產月報與管理型簡報、季初 21:00 產季報、半年初 21:10 產半年報、年初 21:20 產年報，再交給 22:00 `ppt_vision_audit` 做視覺審核；每次嘗試會寫入 `ppt_generation_runs`，`/observability/ppt_audit_history` 以精準參數檢查目標版本是否已產生，並可用 `/observability/ppt_audit/generate_missing` 手動補齊缺漏，總開關為 `PPT_AUTO_GENERATION_ENABLED`。PPT vision 需 `PPT_VISION_ENABLED=true` 與容器內 LibreOffice；`/observability/ppt_audit_file/<filename>` 會把 PPTX 轉成 PDF 快取供站內線上預覽，原始 PPTX 仍保留下載。QA 失敗項目的「重跑」必須從檔名推回原 report_type，並只失效相同 `report_type + parameters` 的 active `ppt_reports` cache，避免拿到舊 PPT 或誤重跑 daily。

---

## 二、真實資料庫 Schema（已校對確認）

### 2.1 `products` 表（SQLAlchemy ORM，SQLite/PostgreSQL 通用）

| 欄位 | 型別 | 說明 |
|------|------|------|
| `id` | Integer PK | 主鍵 |
| `i_code` | String(50) UNIQUE | **MOMO 商品代碼**（爬蟲來源，即商品 SKU） |
| `name` | String(255) | 商品名稱 |
| `url` | String(500) | MOMO 商品頁 URL |
| `image_url` | Text | 商品圖片 URL |
| `category` | String(100) | 分類名稱（直接欄位） |
| `status` | String(20) | 預設 `'ACTIVE'` |
| `created_at` | DateTime | 建立時間 |
| `updated_at` | DateTime | 更新時間 |
| `category_id` | Integer FK → categories.id | 分類關聯（可選） |

> **重要**: `i_code` = MOMO 網站上的商品 ID（例如 `I132467614`）

### 2.2 `price_records` 表

| 欄位 | 型別 | 說明 |
|------|------|------|
| `id` | Integer PK | 主鍵 |
| `product_id` | Integer FK → products.id | 商品關聯 |
| `price` | Float | **MOMO 自家售價**（爬蟲抓取） |
| `timestamp` | DateTime indexed | 抓取時間戳 |

> ⚠️ **架構限制**: `price_records` **只存 MOMO 自家售價**，無 `source` 欄位，無競品（PChome）價格。
> PChome 比價資料必須由外部爬蟲即時抓取，以 `pchome_prices: dict` 形式注入 `HermesAnalystService.run()`。

### 2.3 `daily_sales_snapshot` 表（PChome 後台業績匯出，動態表）

> **重要**: 此表由 `import_service.py` 使用 `df.to_sql()` 動態建立。
> 欄位名稱**完全繼承自 PChome 後台匯出的業績 Excel 原始欄位**，加上程式碼追加的 `snapshot_date`。
> V10.605 起，匯入器會掃描所有 worksheet 與前 15 列表頭，優先選擇含「日期 / 商品名稱 / 總業績或銷售金額」的明細工作表；格式或日期真的不合格的檔案會移到 Google Drive `匯入失敗`，避免每 30 分鐘重複告警。
> V10.776 起，`pchome_sales_acquisition_service.py` 依序探測 Google Drive、顯式授權 HTTPS、顯式授權 IMAP 與受控落地目錄；所有非 Drive 檔案先做副檔名/魔術碼/大小檢查與 SHA-256 冪等，再由 `import_service.py` 在同一 DB transaction 內 replace、寫入及驗證 `daily_sales_snapshot` 與 `realtime_sales_monthly`。任一步失敗必須整批 rollback，不得留下半同步狀態。每次 run 需把 `trace_id`、OpenTelemetry-compatible `span_id`、`run_id`、`work_item_id`、來源、政策、check、execution、post-verifier 與 terminal 寫入 `pchome_sales_acquisition_receipts`；舊版人工暫停旗標不得停止此 medium-risk controlled-apply lane。V10.790 起再以 `pchome_sales_source_reconciliation_v1` 跨 run 累積 provider 空跑/失敗次數，disabled 來源不得冒充 `no_candidate`，ready-empty 走固定重試、provider failure 走有界指數退避，所有已啟用 fallback 仍依序探測；相同狀態 fingerprint 在 cooldown 內抑制重複通知，決策與 `next_retry_at` 一併寫入原 receipt。正式完成仍要求最新業績 <= 1 天，不能以 source/test/UI 綠燈取代 production freshness closure。

#### 已確認的關鍵欄位（PChome 後台報表欄位名稱）

| 欄位 | 型別 | 說明 | 備注 |
|------|------|------|------|
| `snapshot_date` | Date | 資料所屬日期（程式追加） | 由 `import_service.py` 從「日期」欄位解析 |
| `商品ID` | VARCHAR | PChome 後台 / 訂單目錄商品識別碼 | ⚠️ 不可假設等於 `products.i_code` |
| `商品名稱` | TEXT | 商品名稱 | |
| `總業績` / `銷售金額` | NUMERIC | 銷售業績金額 | 匯入器以欄位群組模糊比對，兩者皆可 |
| `數量` | NUMERIC | 銷售數量 | |
| `總成本` | NUMERIC | 成本 | |
| `廠商名稱` | VARCHAR | 廠商名稱 | |
| `商品館` / `館別` | VARCHAR | 分類 | |

#### 欄位自動偵測邏輯（`find_col`）

系統使用 keyword 模糊比對，**不要求欄位名完全固定**：

```python
SKU/商品ID   = find_col(['商品ID', 'Product ID', 'ID', 'i_code', 'Item Code'])
商品名稱     = find_col(['商品名稱', '品名', 'Name', 'Product'])
銷售金額     = find_col(['銷售金額', '業績', '金額', 'Amount', 'Sales', 'Total'])
成本         = find_col(['成本', 'Cost', '進價', '總成本'])
數量         = find_col(['銷售數量', '銷量', '數量', 'Qty', 'Quantity'])
日期         = find_col(['日期', '訂單日期', '交易日期', 'Date'])
分類         = find_col(['商品館', '館別', '分類', 'Category'])
```

### 2.4 `competitor_prices` 表（Migration 004 — 已建立）

競品價格快取表，由 `competitor_price_feeder.py` Worker 寫入，AI Pipeline LEFT JOIN 消費。

| 欄位 | 型別 | 說明 |
|------|------|------|
| `id` | SERIAL PK | 主鍵 |
| `sku` | VARCHAR(50) | MOMO 商品代碼（= products.i_code） |
| `source` | VARCHAR(30) | 競品來源：`'pchome'`（預留 shopee 等） |
| `price` | NUMERIC(10,2) | 競品售價 |
| `original_price` | NUMERIC(10,2) | 競品原價 |
| `discount_pct` | INTEGER | 折扣 %（NULL=未折扣） |
| `competitor_product_id` | VARCHAR(100) | PChome 商品 ID |
| `competitor_product_name` | TEXT | PChome 商品名稱（核對用） |
| `match_score` | NUMERIC(4,3) | 商品身份比對分數（0~1），< 0.76 不寫入正式快取 |
| `tags` | JSONB | 語意標籤，如 `["on_sale","discount_20pct"]` |
| `crawled_at` | TIMESTAMP | 爬取時間 |
| `expires_at` | TIMESTAMP | TTL = crawled_at + 48h（可由 `PCHOME_FEEDER_TTL_HOURS` 調整），過期後 Hermes 忽略；UI 身份覆蓋率不因價格 TTL 過期歸零 |

**UNIQUE**: `(sku, source)` — 同一 SKU+來源只有一筆，ON CONFLICT UPDATE

**語意標籤字典**：

| 標籤 | 觸發條件 |
|------|---------|
| `on_sale` | PChome `is_on_sale = True` |
| `discount_10pct` | 折扣 10-19% |
| `discount_20pct` | 折扣 20-29% |
| `discount_30pct` | 折扣 ≥ 30% |
| `low_stock` | 庫存 < 10 |
| `high_rating` | 評分 ≥ 4.5 |

### 2.5 `ai_price_recommendations` 表（Migration 003 — 已建立）

此表需執行 `migrations/003_ai_price_recommendations.sql` 才能完整寫入 DB：

```sql
CREATE TABLE IF NOT EXISTS ai_price_recommendations (
    id          SERIAL PRIMARY KEY,
    sku         VARCHAR(50) UNIQUE NOT NULL,
    name        TEXT NOT NULL,
    reason      TEXT,
    status      VARCHAR(20) DEFAULT 'pending',  -- pending / approved / rejected
    created_at  TIMESTAMP DEFAULT NOW(),
    updated_at  TIMESTAMP DEFAULT NOW()
);
```

> **現狀**: `nemoton_dispatcher_service.py` 的 `_exec_add_to_recommendation()` 在 engine 注入且表存在時才寫入，否則只發 Telegram 通知，不會 crash。

---

## 三、SQL 漏斗設計（PChome 業績 ID 邊界）

`daily_sales_snapshot` 來自 PChome 後台業績匯出，`商品ID` 與 `products.i_code` 不保證同一套 ID。任何跨表分析必須先經過可驗證的 mapping / identity contract，不能只用字串相等把 PChome 後台銷售資料與 MOMO 商品主檔硬接。

歷史上曾以如下漏斗概念描述近 7 天銷售額下滑，但此 SQL 只能在 ID 已確認同源時使用：

```sql
WITH latest_momo_price AS (
    -- 從爬蟲商品庫取最新 MOMO 售價
    SELECT
        p.i_code      AS sku,      -- MOMO 商品代碼
        p.name,
        p.category,
        pr.price      AS momo_price,
        ROW_NUMBER() OVER (PARTITION BY p.id ORDER BY pr.timestamp DESC) AS rn
    FROM products p
    JOIN price_records pr ON pr.product_id = p.id
    WHERE p.status = 'ACTIVE'
),
recent_sales AS (
    -- 從每日業績快照計算近7天 vs 前7天銷售額
    SELECT
        "商品ID"     AS sku,      -- ⚠️ 實際欄位名為「商品ID」(非「商品編號」)
        SUM(CASE WHEN snapshot_date >= CURRENT_DATE - 7
                 THEN COALESCE("銷售金額"::numeric, 0) ELSE 0 END) AS sales_7d_curr,
        SUM(CASE WHEN snapshot_date >= CURRENT_DATE - 14
                  AND snapshot_date < CURRENT_DATE - 7
                 THEN COALESCE("銷售金額"::numeric, 0) ELSE 0 END) AS sales_7d_prev
    FROM daily_sales_snapshot
    GROUP BY "商品ID"
)
SELECT lmp.sku, lmp.name, lmp.category, lmp.momo_price,
       rs.sales_7d_curr, rs.sales_7d_prev
FROM latest_momo_price lmp
JOIN recent_sales rs ON rs.sku = lmp.sku
WHERE lmp.rn = 1
  AND rs.sales_7d_prev > 0
  AND (rs.sales_7d_curr - rs.sales_7d_prev) / rs.sales_7d_prev < -0.10
ORDER BY (rs.sales_7d_curr - rs.sales_7d_prev) / rs.sales_7d_prev ASC
LIMIT 300
```

**ID 邊界**:
- `products.i_code` 是 MOMO 商品主檔 / 價格爬蟲 SKU。
- `daily_sales_snapshot."商品ID"` 是 PChome 後台業績匯出中的商品識別碼。
- 兩者不可被文件、Agent 或報表預設視為相同。需要合併分析時，必須先建立可審核 mapping 或沿用已驗證的 PChome identity / 商品名稱證據。

---

## 四、競品價格補給線架構（已實裝）

### 生產者-消費者解耦設計

```
[competitor_price_feeder.py Worker]  ←← 每 4 小時獨立運行
  ↓ 搜尋 PChome（search_products）
  ↓ 商品身份比對（marketplace_product_matcher.py）
  ↓ 提取語意標籤
  ↓ UPSERT competitor_prices（預設 TTL 48h）
                ↓
[HermesAnalystService.fetch_candidates()]  ←← AI Pipeline 消費端
  ↓ LEFT JOIN competitor_prices（零網路等待）
  ↓ 有效期內（expires_at > NOW()）+ match_score ≥ 0.76 + tags 含 identity_v2 才 JOIN
  ↓ pchome_price + competitor_tags 一起傳給 Hermes
```

### 關鍵設計決策

| 決策 | 選擇 | 原因 |
|------|------|------|
| 解耦方式 | DB 表快取（非 Redis） | PostgreSQL 已是核心，無需額外依賴；支援 JOIN |
| TTL | 6 小時 | 與 AI Pipeline 排程週期對齊 |
| 比對算法 | 品牌 + 核心 token + 容量/重量/包數 + 品類 + 價格 sanity check | 由 `marketplace_product_matcher.py` 統一供 feeder、legacy crawler、AI/PPT 鏈路使用 |
| 最低比對門檻 | 0.76 | 核心比價寧可待審，不允許低信心錯配影響 AI 決策 |
| 已有不同 PChome 商品覆蓋門檻 | 0.84 | 新候選與既有正式配對不同時，除非超高信心，否則寫入 `needs_review` attempt 不覆蓋 |
| 單位價可比模式 | `unit_comparable` | 同核心商品但買送/套組/件數不同時，不寫正式總價差；只寫入 attempt，並以單位價證據供 Dashboard / PPT / AI 報表與 AI 例外決策 |
| Browse.sh 診斷 | optional wrapper | 只用於 selector / XHR / network trace 探勘；不得取代正式 crawler，也不得直接把輸出寫成正式競品價格 |
| 語意標籤 | JSONB 陣列 | 傳給 Hermes 提升情境感知品質 |

### 競品比對邏輯（`competitor_price_feeder.py`）

```
MOMO 商品名稱
  → marketplace_product_matcher.build_search_terms()
  → PChomeCrawler.search_products(keyword, limit=12)
  → marketplace_product_matcher.score_marketplace_match()
    → 品牌衝突 / 容量衝突 / 包數衝突 hard veto
    → 同核心但買送/套組/件數不同標記 unit_comparable，不進正式總價差
    → 同款高信心 score ≥ 0.76 才進 competitor_prices
    → 低信心、規格衝突、既有配對衝突寫入 competitor_match_attempts
```

### `fetch_candidates()` v2 漏斗（已更新）

```sql
LEFT JOIN competitor_prices cp
       ON cp.sku = lmp.sku
      AND cp.source = 'pchome'
      AND cp.expires_at > NOW()
      AND cp.match_score >= 0.76
      AND COALESCE(cp.tags, '[]'::jsonb) ? 'identity_v2'
```
→ 無競品資料的商品仍回傳，`pchome_price=NULL`，`_batch_analyze` 自動跳過

### 下游消費規範（2026-05-19 更新）

- Dashboard、AI pick、Hermes、Excel export、daily/growth 圖表與 competitor PPT 必須以 `competitor_prices + competitor_price_history + competitor_match_attempts` 為短期唯一生產真相源，且只消費 `identity_v2` matcher 驗證過的配對；舊版僅靠 `match_score` 的快取不可直接進入決策或簡報。
- `pchome_matches` 與 live `pchome_batch()` 僅保留 legacy compatibility，不得作為新簡報或 AI 決策主來源。
- `services/competitor_intel_repository.py` 是下游頁面、圖表、簡報的共用查詢出口；新增消費端不得各自硬寫不同 match threshold。所有競品報表的價差方向統一為 `MOMO - PChome`：正值代表 MOMO 較貴 / PChome 低價壓力，負值代表 MOMO 價格優勢；daily、growth、OpenClaw、PPT 不得使用反向定義。
- competitor PPT 不可只輸出 matched rows 造成覆蓋率假象；`fetch_competitor_comparison_results()` 必須用 `LEFT JOIN valid_competitor` 保留高營收/高價但尚未有效配對的 MOMO 商品，並帶出 `match_status`、`candidate_count`、`best_match_score` 與 `match_diagnostic`，讓簡報與 AI 文案明確區分「高信心比對」與「待補身份/價格」。
- `services/competitor_identity_revalidator.py` 可對既有 `competitor_prices` legacy row 離線重跑 `identity_v2`：只有新版 matcher 分數 `>= 0.76` 且無 hard veto 才補 `identity_v2` / `legacy_revalidated` tags；預設不刷新 `expires_at`，避免過期價格進入決策。
- `CompetitorPriceFeeder.run_expired_identity_refresh()` 會優先刷新已通過 `identity_v2` 但 TTL 過期的 PChome row：直接用既有 `competitor_product_id` 批次呼叫 PChome 商品 API，再用新版 matcher 重新驗證名稱/規格/價格 sanity，通過後寫回 `competitor_prices` 與 `competitor_price_history`。這條路徑提升新鮮價格覆蓋率，但不降低 match threshold，也不讓過期價格直接進入決策；佇列排序必須先處理既有 `price_basis_total_price` / `alert_tier_price_alert_exact` 或 diagnostic 等價欄位的安全價差 row，再處理需要 review 的舊 row。若既有 `competitor_product_id` 已查不到或回傳候選低於門檻，expired refresh 只寫 `refresh_no_result` / 低信心 attempt 並標記 `fresh_search_recovery_deferred`，不得在同一條價格刷新路徑 fresh search 替換正式 identity。fresh search recovery 只保留給 retryable candidate revalidation / unmatched priority 等補抓路徑。
- 過期 identity refresh 排序必須優先 `price_basis_total_price` / `alert_tier_price_alert_exact` 或 `match_diagnostic_json.price_basis='total_price'` / `alert_tier='price_alert_exact'` 的正式價差配對，再依 `expires_at` 與 MOMO 價格排序，避免高風險可決策價差長期排在低價或非告警型 stale row 後面。
- `marketplace_product_matcher.py` 的擴充只能走「正向證據 + 反向 veto」：品牌一致、商品線/型號訊號強、價格合理且無 hard veto 時才允許 `strong_product_line_match` 加分；補充瓶/補充包/refill 與一般正裝不互相配對，分享組/加量組/明星組等組合包不得誤配單品。
- 近門檻規則必須成對補「召回 + 防錯配」測試：可召回者需有品牌、商品線、規格或具名 identity anchor，例如 MUJI 精油芬香護手霜、Mustela 慕之幼爽身潤膚乳、Herbacin 小甘菊護手霜；防錯配者需成為 hard veto，例如 M·A·C Macximal 柔霧/緞光唇膏質地、ERBE 指甲清垢棒/指甲緣刨刀功能、Schick 舒芙/舒綺女用除毛刀品線。不得用單一同規格或同品牌放寬全域門檻。
- 套組/買送/件數不同但品牌、核心商品線與單一基礎規格一致時，matcher 必須回傳 `comparison_mode='unit_comparable'` 與 `unit_comparable` reason；Feeder 只能寫入 `competitor_match_attempts.attempt_status='unit_comparable'` 或 `refresh_unit_comparable`，不得寫入 `competitor_prices`。Dashboard 與 `competitor_intel_repository` 必須用 `build_unit_price_comparison()` 產生每 ml / 每 g / 每入單位價證據，讓 PPT / AI 報表可說明「需單位價比較」而不是把總價當同款價差。商品看板在正式配對尚未成立時，仍必須顯示最佳候選 PChome 商品名稱、候選價與「候選價，需單位換算」說明，讓 AI 例外決策可直接看見下一步；daily/growth、PPT 與 OpenClaw 摘要不得自建查詢，需消費 `fetch_competitor_review_queue()` 與 coverage 的 `unit_comparable_count`。若任一側含多個不同容量/重量規格，視為多品項套組，不可進 `unit_comparable`。
- PChome feeder 的外部 request timeout 由 `PCHOME_FEEDER_TIMEOUT` 控制，預設 12 秒；排程不得因單一 PChome 搜尋 API timeout 被拖到數分鐘。
- 品牌 alias 屬於正向身份證據，不是門檻放寬；`DR.WU / DR WU / DRWU / 達爾膚` 這類同品牌中英混寫必須正規化後再進 matcher，避免同規格真同款被誤降成 brandless identity review。
- 近門檻 rescore pilot 必須支援明確 SKU 篩選；`audit_competitor_match_attempt_rescore.py --sku <sku>` 可只重算指定 SKU，避免為了小批次驗證而掃整批 `true_low_confidence`。
- 商品看板的 PChome 狀態必須把 matcher 診斷原因翻成可行動語意：品牌不符已排除、規格不符已排除、補充包不相容、組合規格不相容、系列不符已排除、需單位價比較、低信心待補強等，不可只顯示籠統「待比對」或「身份否決」。
- PChome 補抓產線與 priority list 若尚未進入搜尋/補抓，必須顯示「PChome 補抓產線」、「尚未搜尋」與「尚未進入 PChome 補抓」，不得使用「待比對」這類會被誤解成已有候選待 AI 例外決策的字眼。
- 商品看板、PChome review queue 與 `/api/export/excel/pchome-review` 必須優先讀取 `match_diagnostic_json.reasons` 並轉成操作員可讀標籤；文字版 `error_message` 只作 legacy fallback。商品列的 PChome 狀態摘要也必須使用同一套專業標籤，避免 overview 顯示「妝效質地不同」但列表仍顯示籠統身份不符。新增 matcher reason 時需同步更新 `MATCH_DIAGNOSTIC_REASON_LABELS` 與 dashboard 狀態翻譯，避免 UI 顯示 `makeup_finish_conflict` 這類 machine code。PChome 標題缺品牌但有窄範圍 exact identity anchor 的商品，只能透過具名 brandless recovery 進 manual-review identity；多色任選 / 單一色號 gap 必須標記 `variant_selection_review`，並從 `recoverable_low_score` 降回 `true_low_confidence`，不得自動批次寫正式價差。
- Dashboard 必須把「待比對」拆成可診斷狀態：`價格過期待刷新`、`舊版配對待重驗`、`低分配對待補強`、`已排除`、`需單位價比較`、`找不到同款`、`抓取異常`、`尚未搜尋`。硬性不相容候選應顯示為已排除/不相容，不得讓使用者誤以為每筆都需要人工待審。

### 執行方式

```bash
# 手動觸發一輪抓取
python3 services/competitor_price_feeder.py

# 預覽 legacy PChome 快取 identity_v2 重驗證（不寫入）
python3 -m services.competitor_identity_revalidator --limit 500

# 寫入安全通過的 identity_v2 tag；不刷新過期價格
python3 -m services.competitor_identity_revalidator --limit 500 --apply

# 未來整合為 K3s CronJob（每 4 小時）
# k8s/jobs/competitor-price-feeder-cronjob.yaml
```

---

## 五、Telegram 語意化訊息規範（ChatOps 標準）

### 5.1 核心原則

1. **語意化排版 (Semantic Formatting)** — Emoji 作為視覺標籤，0.5 秒判斷嚴重性
2. **倒金字塔結構** — 結論先行 → 核心數據 → AI 洞察 → 建議行動 → 運算足跡
3. **收斂行動呼籲 (Call to Action)** — 每則訊息只有一個明確的 👉 建議行動
4. **底部運算足跡** — FinOps + Observability，用分隔線隔開主訊息
5. **EA AI 例外決策 專業 brief** — `ea_escalation` 必須分成決策狀態、背景摘要、風險摘要、TOP 待審 SKU 與建議處置；價格類行動不得用長 bullet 串接，必須拆出 MOMO/PChome 價格、價差、AI 例外處置與 PChome ID。
6. **價格類決策信封專業 brief** — `price_alert`、`pchome_match_review`、`competitor_price_review` 等含 PChome / 價格證據的 `decision_envelope`，EventRouter 必須直送 evidence template，不得進 L1/L2 重摘要；Telegram 內容必須拆成「標的、價格證據、比對證據、人工下一步」，並從信封讀取 `momo_price`、`competitor_price`、`candidate_gap_pct`、`match_score`、`unit_price_insight` 與 `existing_match_conflict`。
7. **Shared UI 信封摘要共用** — Webcrumbs host data 與其他共用 UI runtime 必須讀 `reviewDecisionBrief` / `decision_envelope` 的結構化證據，不在瀏覽器端重組比價判斷；這些 payload 只能讀 DB 既有覆核資料，不呼叫 LLM、不抓外站、不寫資料。

### 5.2 語意化 Emoji 字典

| 類別 | Emoji | 語意 |
|------|-------|------|
| 身份識別 | `⚡ NemoTron 派發器` | Dispatcher 身份 |
| 身份識別 | `🔍 Hermes 3 8B` | Analyst 身份（僅出現在足跡） |
| 風險級別 | `🚨` | 高危險，立即行動 |
| 風險級別 | `⚠️` | 中風險，AI 例外決策 |
| 風險級別 | `💡` | 低風險，策略建議 |
| 例行報告 | `📊` | 核心數據區塊標頭 |
| 業務屬性 | `💰` | 價格/毛利 |
| 業務屬性 | `📦` | 庫存/銷量 |
| 業務屬性 | `🏆` | 競品情報 |
| AI 洞察 | `🧠` | AI 分析結果 |
| 運算足跡 | `⚙️` | FinOps 底部區塊 |

### 5.3 三大類訊息模板（標準格式）

#### 類別一：緊急告警（`trigger_price_alert` 觸發）

```
🚨 [⚡ NemoTron 派發器] 競價高危險預警

⚠️ 核心問題：[A003 舒特膚 AD 乳液] 價格大幅落後競品，訂單流失中！

📊 關鍵數據：
• 我方價格：$1,200
• 競品價格：$980 (價差 22.4%)
• 銷量變化：近七天銷量 -35.0%

🧠 AI 洞察 (信心度 85%)：
價差已突破 20% 警戒線，且伴隨實質銷量下滑，高度判定為競品大力促銷攔截。

👉 建議行動：建議立即降價至 $1,000 迎戰，或發放 $200 專屬折價券

─────────────────────
⚙️ 運算足跡：
• 🔍 分析: Hermes 3 8B (GCP-A/GCP-B/111 Ollama) | 耗時: 34.2s | Tokens: 512 | $0 成本
• ⚡ 決策: NemoTron NIM | 185 Tokens | $0 (配額內 2/80)
```

#### 類別二：AI 例外決策（`flag_for_human_review` 觸發）

```
⚠️ [⚡ NemoTron 派發器] 異常波動需 AI 例外決策

🔍 待查商品：[A001 玻尿酸面膜10片裝]

📊 矛盾數據：
• 價格狀態：無明顯價差 (與競品齊平)
• 異常現象：過去 3 天銷量突然掛零 (平日日均 15 件)
• 庫存狀態：目前庫存充足 (500+ 件)

🧠 AI 洞察 (信心度 45%)：
數據出現矛盾訊號，AI 信心不足以自主決策，需 AI controlled apply 走查確認。

👉 建議行動：請 AI 例外流程立即進行可驗證走查。

─────────────────────
⚙️ 運算足跡：
• 🔍 分析: Hermes 3 8B (GCP-A/GCP-B/111 Ollama) | 耗時: 34.2s | Tokens: 512 | $0 成本
• ⚡ 決策: NemoTron NIM | 185 Tokens | $0 (配額內 2/80)
```

#### 類別三：策略執行通知（`add_to_recommendation` 觸發）

```
💡 [⚡ NemoTron 派發器] 潛力商品自動佈署

🏆 推薦品項：[A009 美白化妝水150ml] 已自動加入「首頁推薦區塊」

📊 決策依據：
我方價格低於市場 20%，近7天銷量回升，具備流量轉換潛力

🧠 AI 洞察 (信心度 82%)：
具備價格競爭優勢，NemoTron 主動提升曝光量以最大化業績。

👉 執行狀態：✅ 系統已自動寫入 ai_price_recommendations 推薦表

─────────────────────
⚙️ 運算足跡：
• 🔍 分析: Hermes 3 8B (GCP-A/GCP-B/111 Ollama) | 耗時: 34.2s | Tokens: 512 | $0 成本
• ⚡ 決策: NemoTron NIM | 185 Tokens | $0 (配額內 2/80)
```

#### 類別四：Gemini 備援 / 鎖定場景推理週報

```
... (前文省略) ...
─────────────────────
⚙️ 運算足跡：
• 🔍 彙整: Hermes 3 8B (GCP-A/GCP-B/111 Ollama) | 耗時: 12s | $0 成本
• 🧠 備援/鎖定場景: Gemini 2.5 Flash | 8,420 Tokens | 費用: 約 $0.003 USD
```

### 5.4 運算足跡資料來源

| 模型 | API Response 欄位 | 說明 |
|------|-----------------|------|
| Hermes (Ollama) | `eval_count`, `total_duration` | 生成 tokens 數 + 推理耗時 (ns→s) |
| NemoTron (NIM) | `usage.total_tokens` (OpenAI 格式) | prompt + completion tokens 合計 |
| Gemini | `usageMetadata.totalTokenCount` | 乘費率算 USD |

> **程式碼位置**: `nemoton_dispatcher_service.py` → `_build_footprint_block(hermes_stats, nim_stats)`

### 5.5 Inline Keyboard 按鈕（Level 2 互動，待實裝）

當收到類別一緊急告警時，訊息底部附帶互動按鈕（Telegram Bot API inline_keyboard）：

```
[ ✅ 批准降價 ]  [ ❌ 拒絕並忽略 ]  [ 🔗 查看報表 ]
```

- `✅ 批准降價` → 呼叫 MOMO PRO 後台 API 改價 + 決策寫入知識庫
- `❌ 拒絕並忽略` → 決策寫入知識庫（訓練未來在此品類保守點）
- `🔗 查看報表` → 跳轉至 MOMO PRO 該商品數據分析頁

> **現狀**: 尚未實裝，Inline Keyboard 需搭配 Telegram Webhook + callback_query handler

---

## 六、Telegram 告警架構

### 告警群組
- 群組: **小龍蝦** (業務情報專用，非 SRE 維運)
- Chat ID: `-1003940688311`
- Bot: `<TELEGRAM_BOT_TOKEN>`

### 單 Bot 多身份策略（One Bot, Multiple Headers）
| 模組 | Telegram 標頭 |
|------|--------------|
| Hermes 分析師 | `[Hermes 分析師]` |
| NemoTron 派發器 | `[NemoTron 派發器]` |
| Gemini 備援 | `[Gemini 備援]`（僅 Ollama 失敗或 ADR-028 鎖定場景） |

### 三種告警類型
| Tool | 觸發條件 | Telegram 格式 |
|------|---------|--------------|
| `trigger_price_alert` | HIGH 風險 (gap>15% + 銷量跌>20%) | 🔴/🟡 競價威脅告警 |
| `add_to_recommendation` | 我方價格低於競品且銷量正成長 | ⭐ 推薦商品候選 |
| `flag_for_human_review` | 信心 < 0.6 或情況複雜 | ⚠️ 需要 AI 例外決策 |

---

## 六、已驗證的服務參數

### Hermes 分析師
| 參數 | 值 |
|------|---|
| 模型 | `hermes3:latest` |
| Ollama URL | GCP-A `http://34.87.90.216:11434` → GCP-B `http://34.21.145.224:11434` → 111 `http://192.168.0.111:11434` |
| Timeout | 120s |
| Temperature | 0.1 |
| 實測推理時間 | **19.3s（3筆，實彈 2026-04-17）** |
| TOP_N | 20（每次最多輸出威脅數） |

### NemoTron 派發器
| 參數 | 值 |
|------|---|
| 模型 | `meta/llama-3.1-8b-instruct` |
| NIM API URL | `https://integrate.api.nvidia.com/v1` |
| Timeout | 60s |
| 每日配額上限 | 80（留 20 給 AWOOOI） |
| 配額耗盡 fallback | 直接派發 HIGH 風險告警，跳過 NIM |
| 實測 token 消耗 | **1206 tokens/輪（實彈 2026-04-17）** |

---

## 七、已知技術債與待辦

| 優先 | 項目 | 說明 |
|------|------|------|
| ✅ | Migration 003 + 004 | `competitor_prices` + `ai_price_recommendations` 已在 188 `momo_analytics` 執行 |
| ✅ | 188 生產容器實彈驗證 | Hermes + NIM + PostgreSQL + Telegram 全通 (2026-04-17) |
| ✅ | momo-app port 5001→5002 | docker-registry 佔用 5001，docker-compose.yml 改為 `127.0.0.1:5002:80`，已 Up healthy |
| ✅ | momo-app 雙網路連線 | 同時連 `momo-network` + `momo-pro_default`（後者含 `momo-db` alias `momo-postgres`）|
| P1 | PChome Feeder CronJob | `competitor_price_feeder.py` 每 4 小時排程 (Scheduler 整合) |
| P1 | 告警去重 TTL | 同一 SKU 短期內重複告警未防範 |
| ✅ | `daily_sales_snapshot` 欄位防禦 | V10.605 已支援多 worksheet / 表頭列掃描 / 格式失敗隔離 |
| P1 | PChome 後台業績匯出前半段自動化 | 現有 importer 已自動吃 Google Drive；仍需接 PChome 後台排程匯出、Email 附件或受控 browser 下載 |
| P2 | Scheduler 整合 | 每6小時自動觸發 Hermes→NIM→Telegram 管線 |
| P2 | Gemini 備援治理 | 僅保留 ADR-028 鎖定場景與 Ollama 失敗備援，新增 caller 必須走 ADR |

---

## 八、部署拓撲（2026-04-17 確認）

### 實體機器對應

| 服務 | 主機 | 容器名 | 說明 |
|------|------|--------|------|
| PostgreSQL | 192.168.0.188 | `momo-db` | pgvector/pgvector:pg14，含所有 AI 相關表 |
| momo-app | 192.168.0.188 | `momo-pro-system` | **Up healthy，port 5002:80**（5001 被 docker-registry 佔用，已改 5002） |
| momo-scheduler | 192.168.0.188 | `momo-scheduler` | 常駐排程容器 |
| Ollama Primary | 34.87.90.216 | Ollama 原生 | GCP-A，AI/LLM/embedding 主路徑 |
| Ollama Secondary | 34.21.145.224 | Ollama 原生 | GCP-B，同等備援 |
| Ollama Fallback | 192.168.0.111 | Ollama 原生 | 最後一道本地防線 |
| E2E 驗證容器 | 192.168.0.188 | `momo-e2e-test` | 臨時容器，含新服務模組 |

### 188 `/home/ollama/momo-pro/.env` 正確設定

```bash
TELEGRAM_BOT_TOKEN=<TELEGRAM_BOT_TOKEN>  # ← 唯一正確 token
TELEGRAM_CHAT_IDS=["-1003940688311"]  # 小龍蝦群組
NVIDIA_API_KEY=<NVIDIA_API_KEY>
USE_POSTGRESQL=true
POSTGRES_HOST=momo-db
# POSTGRES_DB / USER / PASSWORD 使用 docker-compose.yml 預設值
```

> ⚠️ **Split-brain 陷阱**：188 容器環境曾存在舊 bot token `8569720657`（不同 bot，不在小龍蝦群組），
> 已於 2026-04-17 深夜修正為正確 token `8610496165`。

---

## 九、校對歷程

| 日期 | 問題 | 修正 |
|------|------|------|
| 2026-04-17 | `fetch_candidates()` SQL 使用 `"商品編號"` | 修正為 `"商品ID"`；2026-06-15 追認此欄位來自 PChome 後台業績匯出，不可預設等於 MOMO `products.i_code` |
| 2026-04-17 | Hermes gap_pct 由 LLM 計算 → 誤差大 | 改為 Python 預算 `(momo-pchome)/pchome*100` |
| 2026-04-17 | 推理時間 52s | 預算 gap_pct 後降至 19.3s (3筆) |
| 2026-04-17 | `model_footprint` DB 欄位寫入 `{}` | 分離 `footprint_text`（Telegram 顯示）與 `footprint_data`（DB JSON）|
| 2026-04-17 | SQLite 語法 `NOW()` / `datetime('now')` / `::jsonb` | 全部改為 `CURRENT_TIMESTAMP` / Python 計算（跨 DB 相容）|
| 2026-04-17 | 本機 SQLite 測試通過但 188 未同步任何檔案 | rsync 推送 6 核心檔案 + 全站 dry-run 對帳 + migrations 跑通 |
| 2026-04-17 | 188 容器無 volume mount，`docker cp` 臨時解 | 重建 image（`COPY . .` bake 進新代碼）；port 5001 衝突記錄為技術債 |
| 2026-04-17 | 188 .env Telegram token 不正確（split-brain）| 修正為 `8610496165`，188→Telegram message_id=282 確認 |
| 2026-04-17 | NIM Tool Calling E2E | 真實 NVIDIA_API_KEY 驗證：dispatched=3, errors=[] |
| 2026-05-20 | PChome 商品身份比對仍可能因單一規格重疊誤放行 | V10.312 起 matcher 解析 mg/mcg 劑量、件組套組、多規格集合與同數字不同單位；劑量/容量/重量/件數/品類衝突會硬否決或導向單位價覆核，避免錯配污染 Dashboard、daily/growth、PPT 與 AI 競價分析 |
| 2026-05-20 | 正確 PChome 候選常因只掃第一頁或搜尋詞丟失品牌/規格而未進入 matcher | V10.314 起搜尋 API 依 limit 掃多頁、對暫時性錯誤有限重試；feeder 預設 5 組搜尋詞、20 候選、2 頁，並保留括號/方括號內品牌與規格，提升覆核隊列與正式比價的候選品質 |
| 2026-05-20 | 指定日期競品簡報可能混用目前 `competitor_prices` 快取價 | V10.315 起 `fetch_competitor_comparison_results()` 有 start/end date 時改用 `competitor_price_history` 期間快照，MOMO 價格取報表結束日前最新價；即時報表才使用目前有效 `competitor_prices` |
| 2026-05-20 | PChome 覆蓋率分子可能被非活躍或無 MOMO 現價 SKU 膨脹 | V10.317 起 `fetch_competitor_coverage()` 的 `valid_matches` 改為 active MOMO latest price 與有效 PChome `identity_v2` 價格交集，確保 daily/growth/PPT/AI 看到的比價資料品質不被舊快取列高估 |
| 2026-05-20 | EA AI 例外決策 告警可能把非 SKU 診斷誤排成待審 SKU，或在缺少 DB/Hermes 實證時打擾人工 | V10.318 起 `ea_escalation` 僅對含 SKU/價格比較的 actions 使用競價卡片；非 SKU 診斷改為「待確認事項」。價格類低信心事件若無 DB/Hermes 實證，測試鎖定只 suppress、不寫 human_review、不發 Telegram |
| 2026-05-21 | ElephantAlpha NIM/LLM 回應偶爾不是純 JSON，會觸發 `json.loads()` 失敗並落入舊式空泛策略 fallback | V10.383 起協調器容忍 fenced/混文字 JSON；無法解析時改用 DB/Hermes 實證 fallback，且 fallback 不再包含 OpenClaw `generate_*` 舊步驟或自動調價暗示 |
| 2026-05-20 | Telegram HTML parse mode 不支援 `<br>`，可能導致告警或報告送出 400 | V10.321 起 Telegram template 發送前會把 `<br>` / `<br/>` / `<BR />` 轉為換行；保留其他 HTML 標籤，非 HTML parse mode 不改寫 |
| 2026-05-20 | 部分舊 Telegram 入口繞過中央 sanitizer，且 RAG awaiting review 使用錯誤 `chat_id=` 參數會讓 AI 例外決策推播失敗 | V10.322 起 Bot API price decision 走 `send_telegram_with_result()`；`price_decision()` 補 `report_url` 相容並 escape 動態欄位；RAG awaiting review 改用 `chat_ids=[...]` 呼叫 `_send_telegram_raw()` |
| 2026-06-25 | UI/UX 不可只修首頁，導覽主入口必須同一套 PChome 業績提升語言 | V10.662 起作戰、分析、營運、AI 助手主入口與廠商缺貨子工具都使用短句對齊「評估、分析、建議、解法、治理」流程；首頁今日行動卡維持 980px 上限與高對比主按鈕，禁止回到全寬長文說明。 |
| 2026-06-25 | 首頁今日行動 CTA 不可被全域 Bootstrap guard 蓋成透明或低對比 | V10.663 起 `#commandTaskButton.growth-command-alert-action` 使用精準 selector 與 `background-color` hard override，正式 smoke 必須量測按鈕背景與卡片寬度。 |
| 2026-06-25 | 系統、舊入口與觀測台頁首不可用長篇工程說明取代決策用途 | V10.664 起舊入口、系統管理與 AI 觀測台頁首統一改為短句，聚焦資料新鮮度、成本、品質、RAG 與自癒如何支援 PChome 業績判斷。 |
| 2026-06-25 | 說明、空狀態與登入頁不可停在教學口吻，必須提示下一個業績動作 | V10.665 起 AI 助手說明、業績空狀態、缺貨舊首頁、登入頁與 PPT 視覺 QA 空狀態改為行動導向短句，避免使用者在說明文字中迷路。 |
| 2026-06-25 | PPT 視覺 QA 頁首不可依 runtime 條件退回描述型長句 | V10.666 起 PPT 視覺 QA 主頁首固定顯示「先確認簡報可預覽、可審核，再把問題交給修復流程」，避免 runtime 已就緒時失去行動導向。 |
| 2026-06-25 | 邊角工具頁不可只描述功能，必須說明如何支援 PChome 業績判斷 | V10.667 起 AI 生成歷史、PChome 爬蟲、趨勢資料、用戶管理、外部工具狀態與市場情報停用頁都改為短句，聚焦資料新鮮度、文案回收、權限治理與正式比價流程。 |
| 2026-06-25 | 低頻治理頁與舊入口不可出現英文工程狀態或教學句 | V10.668 起 legacy bridge、維護/權限、匯入、設定、通知模板、缺貨管理、登入歷史、系統日誌與 AI 健康檢查頁統一改為繁中短句，聚焦資料可靠、權限守門、供貨風險與部署治理如何支援業績流程。 |
| 2026-06-25 | 匯入頁不可把資料表流程當成使用者主訊息 | V10.669 起雲端匯入與系統匯入完成訊息改說明業績資料新鮮度與更新筆數，不再用「下載→匯入資料庫→刪除」或資料表名稱作為前台重點。 |
| 2026-06-25 | 可見操作頁不可把權杖、DB、Agent、Pipeline 當成主語 | V10.670 起 AI 助手、日報、銷售分析、缺貨、部署監控與觀測台頁面進一步改用「用量、產出紀錄、AI 分工、部署流程、知識命中」等營運可讀語言。 |
| 2026-06-25 | Google Drive 自動匯入不可在正式排程開瀏覽器 | V10.671 起背景匯入缺少 `config/google_token.json` 時 fail-closed 並提示一次性授權檔轉換；正式 scheduler 不再嘗試 `run_local_server()`，且 token refresh 必須能寫回共用 `config/` 掛載，避免主機重啟後再次出現 `could not locate runnable browser` 或授權檔遺失。 |
| 2026-06-25 | 待確認候選必須能一眼比對雙平台賣場 | V10.672 起 MOMO 待確認候選回傳 PChome/MOMO 兩個賣場連結與白話檢核點，前台改成雙欄比對並提供「同時開兩個賣場」，不再顯示 `variant_selection_review` 等工程 matcher tag。 |
| 2026-06-25 | 待確認候選 API 不可回傳 raw matcher code | V10.673 起 `match_reasons` 相容欄位也改回白話理由，避免前台或檢視 payload 時再次看到 `variant_selection_review`、`focused_exact_identity_*` 等工程代碼。 |
| 2026-06-25 | 共用成長流程列手機版不可溢出畫面 | V10.674 起全站 `momo-growth-rail` 在手機寬度改為換行呈現，避免「評估 / 分析 / 建議 / 解法 / 治理」流程 chip 超出視覺邊界。 |
| 2026-06-25 | 匯入、缺貨、設定與通知模板頁不可外露 SQL / 資料表 / 模板代碼 | V10.675 起匯入 job API 對前台回傳白話處置訊息，保留 raw error 於 DB/log；自動匯入失敗通知不再顯示 `psycopg2`、`daily_sales_snapshot`、`snapshot_date` 等內部字串；缺貨首頁、系統設定與通知模板列表改用營運語言，並補上逾時匯入任務重置與取消 API。 |
| 2026-06-25 | 觀測台入口與通知預覽不可用工程主語干擾營運判讀 | V10.676 起觀測台導覽統一使用「AI 分工矩陣」，通知模板列表會把 K8s/Pod/資料庫/CI Pipeline 等內部詞轉成服務健康、資料連線與部署流程；主機健康事件與自癒劇本改顯示任務/問題/處置提醒，不直接露 `unknown_task`、`scheduler_task_failure`、`CODE_FIX` 等 raw code。 |
| 2026-06-25 | 部署監控不得用退役正式域名判定失敗 | V10.677 起 CI/CD 狀態 API 與 active blackbox 監控預設以 `PUBLIC_URL` / `PROD_BASE_URL` 對齊現行正式入口 `https://mo.wooo.work/health`，不再把 `momo.wooo.work` timeout 判成正式部署失敗；Webcrumbs loader fallback 也改為資訊級降級訊號，避免健康頁與 log 產生假紅燈。 |
| 2026-06-25 | 匯入任務公開摘要不得回傳資料表或本機檔案定位 | V10.678 起 `/api/import_jobs` / `/api/import_job/<id>` 的 `import_summary` 只回傳營運摘要、日期範圍、匯入筆數與同步狀態，不再外露 `table_name`、`synced_to`、`daily_sales_snapshot`、`realtime_sales_monthly`、Google Drive file id 或本機暫存路徑。 |
| 2026-06-25 | 部署後 Code Review 不得把模型 timeout 寫成部署錯誤 | V10.679 起本地掃描可收斂的 Code Review 報告不再顯示「最後錯誤 / all hosts failed / OpenClaw timeout」等模型內部訊息；歷史 API 讀舊紀錄時也即時轉為「AI 延伸分析暫時略過，已以本地掃描完成部署後檢查」。 |
| 2026-06-25 | Code Review 歷史理由不得外露模型路由 | V10.680 起 Code Review history 的 `ea_decision.reasoning` 與舊報告讀取層會把 OpenClaw、GCP-A/GCP-B、111 重分析、fallback 等內部模型路由轉成「AI 延伸分析暫時不可用時，維持本地掃描收斂」。 |
| 2026-06-25 | 舊 Code Review 報告需廣義清除模型路由殘留 | V10.681 起舊 `openclaw_report` 讀取層用廣義規則移除 GCP-A/GCP-B、111 與 fallback 相關整段文字，避免歷史報告仍殘留內部模型拓撲。 |
| 2026-06-25 | 全站前台不可再把 AI 模型路由、資料表、raw log 當使用者訊息 | V10.682 起 PPT 視覺 QA、Logs、Code Review、AI 助手與觀測台主要頁面改用「AI 模型、知識命中、工具編排、產出紀錄、修復流程」等營運語言；PPT 審核舊錯誤與 Logs API 會即時脫敏 IP、模型失敗、金鑰路徑與資料表名稱，成長分析空狀態不再顯示 `realtime_sales_monthly`。 |
| 2026-06-25 | Code Review 歷史決策需清除所有 GCP/111 句型 | V10.683 起 `ea_decision.reasoning` 舊紀錄讀取層同時清除「GCP-A/GCP-B AI 架構檢查不可用時應暫停 111 重分析」等非 fallback 句型，避免正式 history 10 筆仍殘留模型拓撲。 |
| 2026-06-25 | Logs 頁不得露內部 Agent 服務名 | V10.684 起 `/api/logs` 會把 OpenClawBot、OpenClaw、Hermes、NemoTron 等內部 agent/service 名稱轉為 AI 自動化、架構檢查、掃描與派工服務，避免系統日誌頁重新暴露工程實作細節。 |
| 2026-06-25 | Code Review template 原始碼也不得殘留 OpenClaw 可掃描字串 | V10.685 起 `/code-review/` 的 CSS 註解與 JS 函式名稱改為 Architecture Report 命名，讓正式 HTML 掃描不需例外白名單即可確認無內部 agent 名稱。 |
| 2026-06-25 | MOMO 待確認候選必須是營運比對卡 | V10.686 起首頁候選區需以 PChome/MOMO 左右對照、商品圖、價格差異徽章、同款可信度、中文確認重點與「雙開賣場 / 單開賣場」操作呈現；前端不得把 `variant_selection_review`、`source_code`、`momo_reference` 等工程 key 或資料欄位名直接顯示給營運使用者。 |
| 2026-06-25 | 價格語意不得反轉 | V10.687 起 dashboard 的 `gap_pct >= 5` 一律顯示為「PChome 價格優勢」與 win tone；`gap_pct <= -5` 一律顯示為「MOMO 低價壓力」與 risk tone，避免把 PChome 較便宜誤標為價格壓力。 |
| 2026-06-25 | 覆核 note 不得保留反向價格詞 | V10.688 起單位價覆核 note 不再使用「不應誤判為 PChome 價格壓力」這類否定式錯誤詞，改用「需先檢查 PChome 售價、折扣與組合」等可執行語句。 |
| 2026-06-25 | 舊覆核資料輸出層也要清洗價格語意 | V10.689 起 dashboard template 會在輸出 `unit_price_insight.summary` 時清除舊資料殘留的反向價格詞，避免快取或歷史 row 繼續把錯誤字句顯示給營運使用者。 |
| 2026-06-25 | Google Drive 背景匯入不得尋找本機瀏覽器 | V10.690 起 `GoogleDriveService.authenticate()` 預設拒絕背景 OAuth；即使人工明確開啟互動授權，也使用 `open_browser=False` 並輸出授權網址，不在 scheduler/app 容器內尋找 runnable browser。 |
| 2026-06-25 | 全頁價格方向統一為 PChome 成長視角 | V10.691 起 AI Intelligence、Daily Sales、Growth Analysis、Dashboard、Telegram 與 AI 報告 prompt 不再使用「PChome 價格壓力 / MOMO 價格優勢 / MOMO 更便宜 / PChome 有優勢」等易混淆詞；統一為「PChome 價格優勢」與「MOMO 低價壓力」。 |
| 2026-06-25 | 候選比較卡與價格語意必須有測試防線 | V10.692 起 `tests/test_pchome_revenue_growth_service.py` 鎖定 `/ai_intelligence` 模板必須提供 PChome/MOMO 雙賣場連結、雙開賣場操作與白話候選理由，且不得再出現 `variant_selection_review`、`focused_exact_identity`、`source_code`、`momo_reference` 或反向價格詞。 |
| 2026-06-25 | 成長報表不得把比價內部指標整排丟給使用者 | V10.693 起 `/growth_analysis` 的比價品質區改為「PChome 價格作戰可用度」：只呈現可直接決策、同款覆蓋、價格需刷新、待補/待確認四個訊號，並依資料狀態給下一步建議與今日作戰入口；測試禁止回到「比價資料品質、高信心門檻、未知新鮮度、AI 否決」這類工程化列表。 |
| 2026-06-25 | 比價頁每筆結果也必須能雙開賣場 | V10.694 起 `/price_comparison` 的結果列在 PChome/MOMO 連結都存在時提供「雙開賣場」操作，Excel 與手動輸入提示改成白話作戰語言，不再顯示「格式說明、欄位、商品名稱,價格」這類工程化提示；`tests/test_frontend_v2_assets.py` 鎖定此行為。 |
| 2026-06-25 | 匯入任務列表只顯示處置提醒 | V10.695 起 `/auto_import` 任務列表不再把 `error_message` 原文當主要欄位顯示，而是由 `buildImportActionHint()` 轉成 Google Drive 授權、當日業績明細檔、重新匯入或通知維護人員等下一步，避免重啟後瀏覽器/授權/同步技術錯誤直接暴露給營運使用者。 |
| 2026-06-25 | 系統設定匯入提示不得顯示資料表或日誌口徑 | V10.696 起 `/system_settings` 不再用 `realtime_sales_monthly` 判斷前端提示，也不再顯示「資料落點、檢查日誌、發生系統錯誤」等內部口徑；所有匯入與備份失敗提示統一走 `toImportActionMessage()`，轉成重新授權、改用正確業績報表、重新匯入或通知維護人員。 |
| 2026-06-25 | 分析與建議頁必須使用 PChome 作戰流程語言 | V10.697 起 `/sales_analysis`、`/monthly_summary_analysis`、`/ai_recommend` 頁首與主要操作區統一使用「主推、守價、補比價、成長缺口、毛利貢獻、品類結構」等營運語言；前台不得把 AI 模型、權杖、資料庫、欄位、英文指標縮寫或內部錯誤作為使用者主訊息。 |
| 2026-06-25 | 治理與匯入頁也不得外露模型/權杖/欄位口徑 | V10.698 起缺貨匯入、供應商窗口、AI 歷史、預算、AI 流量、AI 分工與主機健康頁統一改用「必要資料、用量、建議引擎、建議路徑、雲端備援、AI 建議服務」等前台可讀詞，避免使用者在營運頁看到 raw model、token、欄位或模型品牌。 |
| 2026-06-25 | 工具頁與簡報頁也必須使用作戰語言；Google Drive token 必須固定到持久化掛載 | V10.699 起簡報預覽、品牌素材、比價、匯入、缺貨與觀測台操作提示移除英文/內部流程字，改成可直接理解的狀態與下一步；正式容器明確指定 `/app/config/google_token.json` 與 `/app/config/google_credentials.json`，背景匯入不得因主機重啟或工作目錄變動而改找瀏覽器授權。 |
| 2026-06-26 | 邊角治理頁不得把 raw caller、模型資料或推版代碼當主訊息 | V10.700 起 AI 流量、主機健康、通知模板與缺貨匯入提示再收斂為「使用情境、建議路徑、服務資料、更新摘要、先選擇供應商缺貨檔」等營運語言，避免低頻治理頁回流 `原始`、模型品牌、commit/pipeline 欄位或泛用檔案提示。 |
| 2026-06-26 | 靜態資源部署必須保持容器可讀 | V10.701 起部署 SOP 改用 Git 物件打包差異檔，並以測試檢查 `web/static` 檔案可被容器讀取，避免 macOS / iCloud 工作目錄權限造成正式 `/static/*` 500，讓全站 CSS/JS 不再因檔案模式回歸而失效。 |
| 2026-06-26 | 治理頁也要用營運情境語，不得渲染 raw caller、服務代碼或錯誤日誌 | V10.702 起 AI 流量頁把 caller/provider/上下文改成「使用情境、建議路徑、作戰素材」；服務更新監控頁隱藏 branch/sha/error log/pod 名稱等工程細節，改用「更新流程、服務元件、診斷線索」語言；缺貨頁移除英文 Vendor Stockout。 |
| 2026-06-26 | 關鍵決策框架不得因資料不足整段消失 | V10.703 起 AI 流量頁的「情境 × 知識命中矩陣」改為永遠顯示；資料不足時顯示營運空狀態，避免使用者看不到頁面應該如何判讀。 |
| 2026-06-26 | 使用者頁不得把提交、分支、JSON/API 或 raw caller 當主訊息 | V10.704 起成本治理、AI 分工、AI 健康檢查與登入頁再收斂：raw caller/server 改成使用情境與服務元件，JSONL/API/PostgreSQL/Session/CSRF 等工程語改成檢查紀錄、健康檢查服務、資料服務與工作階段。 |
| 2026-06-26 | 全站 UI/UX 工作重點必須文件化並納入入口索引 | V10.704 起新增 `docs/guides/pchome_growth_ui_ux_guardrails.md` 並由 `AGENTS.md` 索引；所有前台頁面以「提升 PChome 業績、快速判斷、直接下一步」為共同目標，避免後續工作再偏回局部文案修補。 |
| 2026-06-26 | 待確認商品必須能並排比較兩家賣場 | V10.705 起 `ai_intelligence` 與 `price_comparison` 的 MOMO 待確認候選都要以 PChome/MOMO 兩欄比較卡呈現，並提供「同時開兩家賣場」主要操作；不得只顯示候選摘要或只放單一平台連結。 |
| 2026-06-26 | 外部促銷活動要進商業情報與 PChome 解法 | V10.705 起商業情報頁新增外部促銷活動監控，從 24h 外部價格/折扣訊號推導外部低價壓力或促銷訊號，並用守價、組合、曝光、會員四類 PChome 業績提升解法承接。 |
| 2026-06-26 | 商品型 UI 必須顯示商品身份與賣場操作 | V10.706 起商品看板、AI 挑品與 MOMO 待確認候選需在主要商品區塊顯示商品圖、商品 ID、平台賣場連結、價格/可信度與下一步；缺圖需顯示「待補圖片」，不得留下破圖、空白或資料庫欄位名稱。 |
| 2026-06-26 | 外部主流平台需先納入來源治理 | V10.706 起外部來源契約擴充到 Shopee、Lazada、Amazon、Google Merchant / Shopping、Rakuten、Yahoo 購物、Meta Commerce 與 Coupang；未接合法穩定來源前標示待接入且不進告警，避免假裝 AI 已完成監控。 |
| 2026-06-26 | 外部來源視野不可停在少數平台 | V10.707 起外部來源契約再補 TikTok Shop、LINE 購物、露天、品牌官網 / Shopify；所有待接來源必須在 UI 顯示為待接入且不進告警，等官方 API、商品 feed、供應商 API 或人工 CSV 通過品質門檻後才可進作戰清單。 |
| 2026-06-26 | 同版 CSS 修正必須跳版本破快取 | V10.707 起 UI 修正若影響 `web/static` 資產，必須同步提升 `SYSTEM_VERSION`，讓正式 HTML 的 `?v=` 參數改變；不得在同一版本號下修改 CSS 後宣稱使用者一定看得到。 |
| 2026-06-26 | AI 挑品賣場操作必須固定可見 | V10.708 起 AI 挑品清單在桌面寬度固定「AI 建議 / 賣場操作」欄，橫向查看價格與更新欄時仍能直接開 MOMO / PChome 賣場；手機版維持卡片式堆疊。 |
| 2026-06-26 | Telegram 告警不得因非支援 HTML 送出失敗 | V10.709 起 Telegram HTML 發送前只保留 Bot API 支援的 `<b>`、`<i>`、`<code>`、`<pre>`、`<a href="">` 等白名單標籤；`<httpconnection(...)>`、原始錯誤物件或其他未知標籤會轉成可讀文字，避免營運告警因 parse error 400 消失。 |
| 2026-06-26 | 部署前備份入口必須備到專案根目錄 | V10.709 起根目錄 `backup_system.py` 與 `scripts/tools/backup_system.py` 共用同一套備份流程，預設打包專案根目錄並排除 `.env`、Google token、`.git`、runtime volume 與既有 backups，避免只備到 `scripts/tools` 或把敏感 runtime 檔案包入備份。 |
| 2026-06-26 | 低頻頁也不得藏工程 scaffold 或 raw fallback | V10.710 起市場情報停用頁移除舊 preview scaffold 註解，只保留營運可讀狀態與下一步；PChome 爬蟲匯出操作改為下載商品清單；AI 建議頁若外部訊號未整理成結構，不再直接顯示 raw content，而是提示重新整理或補商品線索。 |
| 2026-06-26 | 前台不得用爬蟲當使用者主語 | V10.711 起 PChome、設定、舊入口、market intel 與任務確認文字統一使用「商品監控 / 資料擷取 / 監控來源」，不再把「爬蟲」當頁首、導覽、CTA 或提示主語；內部 route/key 可保留以降低部署風險。 |
| 2026-06-26 | 匯入與設定頁不得回吐 raw 後端錯誤 | V10.712 起自動匯入與系統設定頁的未知錯誤 fallback 只顯示使用者可執行的下一步；Google Drive、格式、同步與資料處理異常可分類成營運文案，但不得把 SQL、snapshot、資料表欄位、driver error 或原始 exception 直接顯示在前台。 |
| 2026-06-26 | 正式容器不得繼承互動式 Google Drive OAuth | V10.713 起 `momo-app`、`momo-scheduler`、`momo-telegram-bot` 的 `GOOGLE_DRIVE_ALLOW_INTERACTIVE_AUTH` 固定為 `false`，不再允許 `.env` 在主機重啟後把排程帶回瀏覽器 OAuth；人工授權只可用一次性腳本完成，正式匯入缺 token 時必須 fail-closed 並回可處理訊息。 |
| 2026-06-26 | AI 銷售建議商品區塊必須商品身份優先 | V10.714 起 `/ai_recommend` 熱銷商品參考改為商品卡，後端 bestseller API 回傳平台、商品 ID、賣場連結與圖片欄位；前端必須顯示縮圖、平台、商品 ID、價格與開賣場操作，缺圖/缺連結需顯示待補狀態，並把商品 ID / URL 帶入銷售建議上下文。 |
| 2026-06-26 | AI 銷售建議前端不得保留 raw content 路徑 | V10.715 起 `/ai_recommend` 只使用已整理的外部訊號摘要與可用線索；搜尋或商品洞察結果若未整理成結構，前端只顯示可理解的待整理狀態，不再把 raw content 當上下文或 fallback 分支保留。 |
| 2026-06-26 | 首頁覆核候選必須標示為待確認商品 | V10.716 起首頁 PChome 覆核區不再使用「PChome 候選」作為可見主語，統一改為「PChome 待確認商品」與「開 PChome 待確認商品」，避免使用者把未確認同款誤認為正式比價結果。 |
| 2026-06-26 | 供貨風險頁不得使用資料表或英文模組名作為主語 | V10.717 起缺貨清單與補貨通知頁統一使用「供貨風險、缺貨處理清單、補貨通知紀錄」等營運語言，不再顯示「缺貨資料表、缺貨資料、Vendor Stockout」等資料庫或英文模組感文案。 |
| 2026-06-26 | AI 觀測頁不得外露 caller key | V10.718 起 AI 品質診斷與知識召回頁使用「使用情境」作為可見主語，並透過 `obs_label.caller()` 顯示營運名稱；前台不得直接顯示 `<code>{{ caller }}</code>`、`top_k` 或「全部呼叫端」等工程語言。 |
| 2026-06-26 | 商品來源頁不得提供 raw JSON 匯出 | V10.719 起 `/pchome_crawler` 改為「PChome 商品監控」營運清單，只提供表格與賣場清單 CSV；前台不得出現 `exportJson`、`JSON.stringify(currentProducts)`、`圖片URL`、`商品URL` 或 raw JSON 檔名。 |
| 2026-06-27 | 設定頁監控來源不得直接外露 crawler 命名 | V10.720 起 `/settings` 的商品監控來源由 API 邊界轉為營運名稱與說明，前端卡片再以 `escapeHtml(monitorText(...))` 顯示；啟停與頻率更新訊息統一使用「監控來源」，不得回傳「爬蟲 XXX 已啟用」這類工程主語。 |
| 2026-06-27 | 監控來源 API 不回傳前台不需要的內部設定欄位 | V10.721 起 `/api/crawlers` 的設定頁 response 會移除 `function`、`page_type`、`status`、`paused_date`，只保留前台需要的名稱、說明、啟用狀態、頻率、活動代碼與營運提示。 |
| 2026-06-27 | 服務更新監控頁不得以內部工具名當主語 | V10.722 起 `/cicd` 可見文字使用「測試站、正式站、監控圖表、自動化流程、今日更新」；前台模板不得用 `issue.error_log` 判斷顯示診斷資料，也不得顯示 `UAT 狀態`、`PROD 狀態`、`Grafana`、`n8n` 作為主按鈕文字。 |
| 2026-06-27 | 系統事件頁不得顯示或下載原始工程紀錄 | V10.723 起 `/logs` 改為「系統事件紀錄」，前台只顯示事件等級、營運判讀與建議處置；不得以 raw log 變數、舊下載檔名或「系統日誌／下載日誌」作為使用者可見介面。 |
| 2026-06-27 | AI 挑品必須直接顯示商品證據與賣場入口 | V10.724 起商品看板 AI 挑品清單會在 selection 階段合併最新 PChome 同款證據，卡片需顯示 MOMO 商品ID、PChome 商品ID、同款信心與兩邊賣場入口；商品圖需使用 PChome 圖片作為 fallback，不得只給一段建議理由。 |
| 2026-06-27 | Google Drive 自動匯入不得在背景排程啟動瀏覽器授權 | V10.725 起正式容器與排程服務即使誤設 `GOOGLE_DRIVE_ALLOW_INTERACTIVE_AUTH=true` 也會硬阻擋互動 OAuth；匯入前會檢查 JSON token 是否存在、可刷新且可寫回，Drive 測試與檔案列表 API 會 fail-closed 回傳可處理的授權狀態。 |
| 2026-07-03 | PChome auto-policy decision preflight 必須有 machine evidence runtime monitoring | V10.727 起 `/api/ai-automation/smoke`、`/api/ai-automation/scheduled-health-summary` 與 `/metrics` 必須輸出 `PChome auto-policy decision preflight` / `pchome_auto_policy_decision_preflight`；此 runtime check 使用本機 deterministic schema evidence adapter 與 `payload_source=local_contract_fixture` 自動驗證 `execute_fetch=True` 的 decision preflight ready path，但明確標記 `outbound_network=false`、`business_data_source=false`、`writes_database_count=0`、`primary_human_gate_count=0`，不讀 secret、不執行 SQL、不寫 DB、不發 apply authorization。 |
| 2026-07-03 | PChome auto-policy decision closeout 必須有 runtime monitoring | V10.728 起 `/api/ai-automation/smoke`、`/api/ai-automation/scheduled-health-summary` 與 `/metrics` 必須輸出 `PChome auto-policy decision closeout` / `pchome_auto_policy_decision_closeout`；此 runtime check 自動驗證 decision closeout ready path、post-apply verifier requirement、same-run production truth requirement 與 future authorization decision package，但明確標記 `writes_database_count=0`、`primary_human_gate_count=0`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`，不讀 secret、不執行 SQL、不寫 DB、不發 apply authorization。 |
| 2026-07-03 | PChome auto-policy authorization issuer gate 必須有 runtime monitoring | V10.729 起 `/api/ai-automation/smoke`、`/api/ai-automation/scheduled-health-summary` 與 `/metrics` 必須輸出 `PChome auto-policy authorization issuer gate` / `pchome_auto_policy_authorization_issuer_gate`；此 runtime check 自動驗證 issuer gate ready path、required issuer evidence、nonsecret authorization claims 與 final nonsecret envelope，但明確標記 `writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`、`secret_material_included=false`，不讀 secret、不執行 SQL、不寫 DB、不簽發 apply authorization。 |
| 2026-07-03 | PChome auto-policy signing decision preflight 必須有 runtime monitoring | V10.730 起 `/api/ai-automation/smoke`、`/api/ai-automation/scheduled-health-summary` 與 `/metrics` 必須輸出 `PChome auto-policy signing decision preflight` / `pchome_auto_policy_signing_decision_preflight`；此 runtime check 自動驗證 signing decision preflight ready path、signing decision input requirements 與 rejection policy，但明確標記 `writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`、`secret_material_required_in_preview=false`，不讀 secret、不執行 SQL、不寫 DB、不簽發 apply authorization。 |
| 2026-07-03 | PChome auto-policy signing decision closeout 必須有 runtime monitoring | V10.731 起 `/api/ai-automation/smoke`、`/api/ai-automation/scheduled-health-summary` 與 `/metrics` 必須輸出 `PChome auto-policy signing decision closeout` / `pchome_auto_policy_signing_decision_closeout`；此 runtime check 自動驗證 signing decision closeout ready path、unsigned signing decision package、post-apply verifier requirement 與 same-run production truth requirement，但明確標記 `writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`、`secret_material_included=false`、`secret_material_required_in_preview=false`，不讀 secret、不執行 SQL、不寫 DB、不簽發 apply authorization。 |
| 2026-07-03 | PChome auto-policy signing issuer guard 必須有 runtime monitoring | V10.732 起 `/api/ai-automation/smoke`、`/api/ai-automation/scheduled-health-summary` 與 `/metrics` 必須輸出 `PChome auto-policy signing issuer guard` / `pchome_auto_policy_signing_issuer_guard`；此 runtime check 自動驗證 signing issuer guard ready path、future signable request boundary、post-apply verifier requirement 與 same-run production truth requirement，但明確標記 `writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`、`secret_material_included=false`、`secret_material_required_in_preview=false`，不讀 secret、不執行 SQL、不寫 DB、不簽發 apply authorization。 |
| 2026-07-03 | PChome auto-policy signing issuer closeout 必須有 runtime monitoring | V10.733 起 `/api/ai-automation/smoke`、`/api/ai-automation/scheduled-health-summary` 與 `/metrics` 必須輸出 `PChome auto-policy signing issuer closeout` / `pchome_auto_policy_signing_issuer_closeout`；此 runtime check 自動驗證 final signable request package、signing issuer guard source chain、post-apply verifier requirement 與 same-run production truth requirement，但明確標記 `writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`、`secret_material_included=false`、`secret_material_required_in_preview=false`，不讀 secret、不執行 SQL、不寫 DB、不簽發 apply authorization。 |
| 2026-07-03 | PChome auto-policy signing execution preflight 必須有 runtime monitoring | V10.734 起 `/api/ai-automation/smoke`、`/api/ai-automation/scheduled-health-summary` 與 `/metrics` 必須輸出 `PChome auto-policy signing execution preflight` / `pchome_auto_policy_signing_execution_preflight`；此 runtime check 自動驗證 operator-held secret boundary、nonsecret signing inputs、future command preview、rollback boundary、abort conditions、post-apply verifier requirement 與 same-run production truth requirement，但明確標記 `reads_secret_count=0`、`writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`、`secret_material_included=false`、`secret_material_required_in_preview=false`，不讀 secret、不執行 SQL、不寫 DB、不簽發 apply authorization。 |
| 2026-07-03 | PChome auto-policy signing execution closeout 必須有 runtime monitoring | V10.735 起 `/api/ai-automation/smoke`、`/api/ai-automation/scheduled-health-summary` 與 `/metrics` 必須輸出 `PChome auto-policy signing execution closeout` / `pchome_auto_policy_signing_execution_closeout`；此 runtime check 自動驗證 unsigned signed-authorization receipt boundary、operator-held secret boundary、nonsecret signing inputs、rollback boundary、abort conditions、post-apply verifier requirement 與 same-run production truth requirement，但明確標記 `reads_secret_count=0`、`writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`signed_authorization_receipt_included=false`、`signature_material_included=false`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`、`secret_material_included=false`、`secret_material_required_in_preview=false`，不讀 secret、不執行 SQL、不寫 DB、不產生 signed receipt、不含 signature material、不簽發 apply authorization。 |
| 2026-07-03 | PChome auto-policy signed receipt preflight 必須有 runtime monitoring | V10.736 起 `/api/ai-automation/smoke`、`/api/ai-automation/scheduled-health-summary` 與 `/metrics` 必須輸出 `PChome auto-policy signed receipt preflight` / `pchome_auto_policy_signed_receipt_preflight`；此 runtime check 自動驗證 external signing receipt evidence boundary、required external receipt evidence、acceptance gates、operator-held secret boundary、post-apply verifier requirement 與 same-run production truth requirement，但明確標記 `reads_secret_count=0`、`writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`external_signed_authorization_receipt_included=false`、`signed_authorization_receipt_included=false`、`signature_material_included=false`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`、`secret_material_included=false`、`secret_material_required_in_preview=false`，不讀 secret、不執行 SQL、不寫 DB、不產生 signed receipt、不含 signature material、不簽發 apply authorization。 |
| 2026-07-03 | PChome auto-policy signed receipt closeout 必須有 runtime monitoring | V10.737 起 `/api/ai-automation/smoke`、`/api/ai-automation/scheduled-health-summary` 與 `/metrics` 必須輸出 `PChome auto-policy signed receipt closeout` / `pchome_auto_policy_signed_receipt_closeout`；此 runtime check 自動驗證 detached receipt verification boundary、required external receipt evidence、acceptance gates、detached verification checks、operator-held secret boundary、post-apply verifier requirement 與 same-run production truth requirement，但明確標記 `reads_secret_count=0`、`writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`requires_detached_signature_verification=true`、`detached_signature_verification_performed=false`、`external_signed_authorization_receipt_included=false`、`signed_authorization_receipt_included=false`、`signature_material_included=false`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`、`secret_material_included=false`、`secret_material_required_in_preview=false`，不讀 secret、不執行 detached verification、不執行 SQL、不寫 DB、不產生 signed receipt、不含 signature material、不簽發 apply authorization。 |
| 2026-07-03 | PChome auto-policy signed receipt evidence intake 必須有 runtime monitoring | V10.738 起 `/api/ai-automation/smoke`、`/api/ai-automation/scheduled-health-summary` 與 `/metrics` 必須輸出 `PChome auto-policy signed receipt evidence intake` / `pchome_auto_policy_signed_receipt_evidence_intake`；此 runtime check 自動驗證 detached verification evidence schema、12 個 evidence fields、10 個 detached verification acceptance gates、10 個 required external receipt evidence、8 個 external receipt acceptance gates、10 個 detached receipt verification checks、operator-held secret boundary、post-apply verifier requirement 與 same-run production truth requirement，但明確標記 `reads_secret_count=0`、`writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`requires_detached_signature_verification=true`、`detached_signature_verification_performed=false`、`external_signed_authorization_receipt_included=false`、`signed_authorization_receipt_included=false`、`signature_material_included=false`、`accepts_plaintext_secret=false`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`、`secret_material_included=false`、`secret_material_required_in_preview=false`，不讀 secret、不執行 detached verification、不執行 SQL、不寫 DB、不產生 signed receipt、不含 signature material、不接受 plaintext secret、不簽發 apply authorization。 |
| 2026-07-03 | PChome auto-policy detached verification evidence validation 必須有 runtime monitoring | V10.739 起 `/api/ai-automation/smoke`、`/api/ai-automation/scheduled-health-summary` 與 `/metrics` 必須輸出 `PChome auto-policy detached verification evidence validation` / `pchome_auto_policy_detached_verification_evidence_validation`；此 runtime check 自動驗證 verifier receipt closeout boundary、12 個 verifier receipt fields、10 個 verifier receipt acceptance gates、12 個 validation checks、10 個 required external receipt evidence、8 個 external receipt acceptance gates、10 個 detached receipt verification checks、post-apply verifier requirement 與 same-run production truth requirement，但明確標記 `reads_secret_count=0`、`writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`requires_detached_signature_verification=true`、`detached_signature_verification_performed=false`、`verifier_receipt_persisted=false`、`external_signed_authorization_receipt_included=false`、`signed_authorization_receipt_included=false`、`signature_material_included=false`、`accepts_plaintext_secret=false`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`、`secret_material_included=false`、`secret_material_required_in_preview=false`，不讀 secret、不執行 detached verification、不持久化 verifier receipt、不執行 SQL、不寫 DB、不含 signed receipt 或 signature material、不接受 plaintext secret、不簽發 apply authorization。 |
| 2026-07-03 | PChome auto-policy verifier receipt closeout 必須有 runtime monitoring | V10.740 起 `/api/ai-automation/smoke`、`/api/ai-automation/scheduled-health-summary` 與 `/metrics` 必須輸出 `PChome auto-policy verifier receipt closeout` / `pchome_auto_policy_verifier_receipt_closeout`；此 runtime check 自動驗證 verifier receipt evidence handoff、12 個 handoff fields、10 個 handoff acceptance gates、12 個 closeout checks、12 個 detached verification evidence validation checks、10 個 required external receipt evidence、8 個 external receipt acceptance gates、post-apply verifier requirement 與 same-run production truth requirement，但明確標記 `reads_secret_count=0`、`executes_script_count=0`、`executes_sql_count=0`、`writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`requires_detached_signature_verification=true`、`detached_signature_verification_performed=false`、`verifier_receipt_persisted=false`、`external_signed_authorization_receipt_included=false`、`signed_authorization_receipt_included=false`、`signature_material_included=false`、`accepts_plaintext_secret=false`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`、`secret_material_included=false`、`secret_material_required_in_preview=false`，不讀 secret、不執行 detached verification、不持久化 verifier receipt、不執行 SQL、不寫 DB、不含 signed receipt 或 signature material、不接受 plaintext secret、不簽發 apply authorization。 |
| 2026-07-03 | PChome auto-policy authorization evidence execution preflight 必須有 runtime monitoring | V10.741 起 `/api/ai-automation/smoke`、`/api/ai-automation/scheduled-health-summary` 與 `/metrics` 必須輸出 `PChome auto-policy authorization evidence execution preflight` / `pchome_auto_policy_authorization_evidence_execution_preflight`；此 runtime check 自動驗證 future database apply authorization verifier handoff、authorization evidence execution preflight package、12 個 preflight checks、12 個 execution fields、10 個 execution acceptance gates、verifier receipt closeout carry-forward、same-run production truth requirement 與 post-apply verifier requirement，但明確標記 `reads_secret_count=0`、`executes_script_count=0`、`executes_sql_count=0`、`writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`executes_authorization_evidence=false`、`requires_detached_signature_verification=true`、`detached_signature_verification_performed=false`、`verifier_receipt_persisted=false`、`external_signed_authorization_receipt_included=false`、`signed_authorization_receipt_included=false`、`signature_material_included=false`、`accepts_plaintext_secret=false`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`、`secret_material_included=false`、`secret_material_required_in_preview=false`，不讀 secret、不執行 authorization evidence、不執行 detached verification、不持久化 verifier receipt、不執行 SQL、不寫 DB、不含 signed receipt 或 signature material、不接受 plaintext secret、不簽發 apply authorization。 |
| 2026-07-03 | PChome auto-policy authorization evidence execution closeout 必須有 runtime monitoring | V10.742 起 `/api/ai-automation/smoke`、`/api/ai-automation/scheduled-health-summary` 與 `/metrics` 必須輸出 `PChome auto-policy authorization evidence execution closeout` / `pchome_auto_policy_authorization_evidence_execution_closeout`；此 runtime check 自動驗證 future database apply authorization final verifier gate、authorization evidence execution closeout package、12 個 closeout checks、12 個 closeout fields、10 個 closeout acceptance gates、authorization evidence execution preflight carry-forward、verifier receipt closeout carry-forward、same-run production truth requirement 與 post-apply verifier requirement，但明確標記 `reads_secret_count=0`、`executes_script_count=0`、`executes_sql_count=0`、`writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`executes_authorization_evidence=false`、`executes_database_apply=false`、`database_apply_authorized=false`、`requires_detached_signature_verification=true`、`detached_signature_verification_performed=false`、`verifier_receipt_persisted=false`、`external_signed_authorization_receipt_included=false`、`signed_authorization_receipt_included=false`、`signature_material_included=false`、`accepts_plaintext_secret=false`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`、`secret_material_included=false`、`secret_material_required_in_preview=false`，不讀 secret、不執行 authorization evidence、不執行 database apply、不執行 detached verification、不持久化 verifier receipt、不執行 SQL、不寫 DB、不含 signed receipt 或 signature material、不接受 plaintext secret、不簽發 apply authorization。 |
| 2026-07-03 | PChome auto-policy controlled apply final preflight 必須有 runtime monitoring | V10.743 起 `/api/ai-automation/smoke`、`/api/ai-automation/scheduled-health-summary` 與 `/metrics` 必須輸出 `PChome auto-policy controlled apply final preflight` / `pchome_auto_policy_controlled_apply_final_preflight`；此 runtime check 自動驗證 authorization evidence execution closeout carry-forward、database apply authorization final verifier gate、controlled apply final preflight package、rollback binding、post-apply verifier binding、12 個 final preflight checks、12 個 preflight fields、10 個 acceptance gates、dry-run-only、check-mode-only、same-run production truth requirement 與 future controlled dry-run package readiness，但明確標記 `reads_secret_count=0`、`executes_script_count=0`、`executes_sql_count=0`、`writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`rollback_execution_authorized=false`、`rollback_executes_sql=false`、`rollback_writes_database=false`、`post_apply_verifier_execution_authorized_in_preview=false`、`executes_database_apply=false`、`ready_for_database_apply_now=false`、`database_apply_authorized=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`，不讀 secret、不執行 authorization evidence、不執行 database apply、不執行 endpoint/SQL、不寫 DB、不簽發 apply authorization，只允許進入下一段 controlled dry-run package lane。 |
| 2026-07-03 | PChome auto-policy controlled dry-run package 必須有 runtime monitoring | V10.744 起 `/api/ai-automation/smoke`、`/api/ai-automation/scheduled-health-summary` 與 `/metrics` 必須輸出 `PChome auto-policy controlled dry-run package` / `pchome_auto_policy_controlled_dry_run_package`；此 runtime check 自動驗證 controlled apply final preflight carry-forward、rollback binding、post-apply verifier binding、12 個 dry-run package checks、12 個 package fields、10 個 acceptance gates、receipt preview、result parser、non-executable command shape、same-run production truth 與 future dry-run receipt closeout readiness，但明確標記 `receipt_execution_performed=false`、`receipt_stdout_included=false`、`receipt_stderr_included=false`、`command_shape_execution_allowed=false`、`database_apply_authorized=false`、`reads_secret_count=0`、`executes_script_count=0`、`executes_sql_count=0`、`writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`executes_authorization_evidence=false`、`executes_database_apply=false`、`ready_for_database_apply_now=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`，不讀 secret、不執行 dry-run、不捕捉 stdout/stderr、不執行 authorization evidence、不執行 database apply、不執行 endpoint/SQL、不寫 DB、不簽發 apply authorization，只允許進入下一段 dry-run receipt closeout lane。 |
| 2026-07-09 | PChome auto-policy controlled dry-run receipt closeout 必須有 runtime monitoring | V10.745 起 `/api/ai-automation/smoke`、`/api/ai-automation/scheduled-health-summary` 與 `/metrics` 必須輸出 `PChome auto-policy controlled dry-run receipt closeout` / `pchome_auto_policy_controlled_dry_run_receipt_closeout`；此 runtime check 自動驗證 controlled dry-run package carry-forward、dry-run result parser、receipt validation report、command-shape hash、rollback binding、post-apply verifier binding、12 個 receipt closeout checks、12 個 closeout fields、10 個 acceptance gates、same-run production truth 與 future runner readiness，但明確標記 `receipt_validation_status=preview_validated_not_executed`、`validation_execution_performed=false`、`validation_stdout_included=false`、`validation_stderr_included=false`、`validation_database_apply_authorized=false`、`reads_secret_count=0`、`executes_script_count=0`、`executes_sql_count=0`、`writes_database_count=0`、`signs_database_apply_authorization_count=0`、`primary_human_gate_count=0`、`executes_authorization_evidence=false`、`executes_database_apply=false`、`ready_for_database_apply_now=false`、`database_apply_authorized=false`、`issues_database_apply_authorization=false`、`signs_database_apply_authorization=false`，不讀 secret、不執行 dry-run、不捕捉 stdout/stderr、不執行 authorization evidence、不執行 database apply、不執行 endpoint/SQL、不寫 DB、不簽發 apply authorization，只允許進入下一段 controlled dry-run runner readiness lane。 |
| 2026-07-09 | PixelRAG / external MCP/RAG 必須有 runtime monitoring 與 candidate replay | V10.746 起 `/api/ai-automation/smoke`、`/api/ai-automation/scheduled-health-summary` 必須輸出 `External MCP/RAG integration readback` / `external_mcp_rag_integration` 與 `PixelRAG RAG candidate replay` / `pixelrag_rag_candidate_replay`；external MCP/RAG readback 回報 9 個 capability 的 absorbed / unresolved 與 `MCP_ROUTER_ENABLED`、`RAG_ENABLED` runtime flags，PixelRAG replay 只讀 visual receipt，拆分 eligible / blocked / invalid，並明確標記 blocked page 不是商品資料。此路徑不讀 secret、不呼叫外部網路、不寫 DB、不寫 `ai_insights`、不寫正式價格表；eligible receipt 仍需 OCR/VLM replay、identity matcher replay、PromotionGate 與 embedding signature guard。 |
| 2026-07-09 | PixelRAG OCR/VLM replay contract 必須有 runtime monitoring | V10.747 起 `/api/ai-automation/pixelrag-ocr-vlm-replay`、`scripts/ops/report_pixelrag_ocr_vlm_replay.py`、`/api/ai-automation/smoke` 與 `/api/ai-automation/scheduled-health-summary` 必須輸出 no-write OCR/VLM replay contract / `pixelrag_ocr_vlm_replay` family；readback 只讀 saved tiles 與 RAG candidate replay，輸出 ready / blocked / invalid contracts、field schema、output schema、validation rules、Ollama-first route contract、blocked page guard 與 next machine action。此階段明確標記 `extraction_execution_performed=false`、`ocr_execution_performed=false`、`vlm_execution_performed=false`、`writes_database=false`、`writes_ai_insights=false`、`writes_price_tables=false`、`network_call=false`、`secret_read=false`、`primary_human_gate_count=0`；ready receipt 才能進下一段 `run_ollama_first_vlm_replay_worker`，blocked receipt 只能進 platform probe 或 structured API 策略。 |
| 2026-07-09 | PixelRAG application portfolio 必須把可整合場景轉成主線工作項目 | V10.748 起 `/api/ai-automation/pixelrag-application-portfolio` 與 `scripts/ops/report_pixelrag_application_portfolio.py` 必須輸出 PixelRAG 在 commerce、RAG、UX、ops、marketing、governance 的可整合/可運用 lanes；每條 lane 需有 priority、status、integrates_with、use_cases、current_capability、next_machine_action、no-write 邊界與 forbidden guardrails。此 readback 依據 PixelRAG visual-RAG pattern、Google Merchant product data、Google Product structured data 與 Baymard product list UX 轉成內部工作項目；它不抓外站、不呼叫模型、不讀 secret、不寫 DB、不把像素結果當正式價格。 |
| 2026-07-09 | PixelRAG Ollama-first VLM replay worker 必須有 runtime monitoring | V10.751 起 `/api/ai-automation/pixelrag-vlm-replay-worker`、`scripts/ops/run_pixelrag_vlm_replay_worker.py`、`/api/ai-automation/smoke` 與 `/api/ai-automation/scheduled-health-summary` 必須輸出 controlled VLM replay worker / `pixelrag_vlm_replay_worker` family；readback 預設 dry-run，不呼叫模型、不寫 artifact，execute 模式只讀 saved tiles、呼叫 approved Ollama VLM route、驗證 JSON field confidence/evidence refs，並只寫 artifact receipt；model_error 也必須寫 failure artifact receipt，receipt 檔內需自證 `artifact_write_performed=true` 與 `receipt_path`。此 worker 明確標記 `writes_database=false`、`writes_ai_insights=false`、`writes_price_tables=false`、`secret_read=false`、`primary_human_gate_count=0`；blocked page 不得輸出商品欄位，ready VLM 結果仍需 identity matcher replay 與 PromotionGate。 |
| 2026-07-09 | PixelRAG VLM route readiness 必須有 runtime monitoring 與 execute 前自動選模 | V10.752 起 `/api/ai-automation/pixelrag-vlm-route-readiness`、`scripts/ops/report_pixelrag_vlm_route_readiness.py`、`/api/ai-automation/smoke` 與 `/api/ai-automation/scheduled-health-summary` 必須輸出 read-only approved Ollama route/model readiness / `pixelrag_vlm_route_readiness` family；readback 只打 `/api/tags`，不呼叫 `/api/generate`，輸出 reachable host、configured model available count、candidate model、candidate host、model_route_ready 與 next machine action。`run_pixelrag_vlm_replay_worker.py --execute` 預設必須使用此 readback 自動選擇已安裝候選模型；完全沒有候選時寫 `model_route_not_ready` artifact receipt，不得盲打 missing model。 |
| 2026-07-10 | PixelRAG VLM execute preflight 必須驗證 generate route | V10.753 起 `/api/ai-automation/pixelrag-vlm-route-readiness?probe_generate=true` 與 `scripts/ops/report_pixelrag_vlm_route_readiness.py --probe-generate` 可對已安裝候選模型執行極小 `/api/generate` preflight；smoke 預設仍不呼叫模型。`run_pixelrag_vlm_replay_worker.py --execute` 預設先執行 generate preflight，若 GCP-A direct / 110 proxy timeout、GCP-B candidate 雖安裝但 generate 不健康，worker 必須在送入 screenshot tiles 前寫 `model_route_not_ready` artifact receipt，輸出 `tag_model_route_ready`、`generate_route_ready`、`route_model_call_performed` 與 `tile_model_call_performed=false`，下一步固定為 `repair_ollama_vlm_generate_runtime_or_proxy_timeout`；不得把 tags 可見誤當 VLM 可執行。 |
| 2026-07-10 | PixelRAG VLM tile generate 必須綁定 preflight 選出的 host / exact model | V10.754 起 `run_pixelrag_vlm_replay_worker.py --execute` 若 route readiness 已輸出 `candidate_host`，tile VLM generate 必須使用該 approved host 與 exact `candidate_model` 直呼 `/api/generate`，不得重新進入全域 Ollama resolver、不得因 111 fallback 規則把 VLM 模型降級成文字模型、不得再出現 preflight 選 111 但 tile generate tried GCP-B/GCP-A/111 的 route drift。receipt 必須輸出 `route_candidate_host`，模型錯誤時下一步為 `repair_ollama_vlm_generate_runtime_or_proxy_timeout`，仍然不寫 DB、不寫正式價格表。 |
| 2026-07-10 | PixelRAG VLM no-probe 監控不得把 unknown 顯示成 failed | V10.755 起 smoke / scheduled-health 的 `pixelrag_vlm_route_readiness.details.generate_route_ready` 在 `generate_probe_performed=false` 時必須保留為 `null`，表示尚未做 `/api/generate` preflight；不得把未探測狀態轉成 `false`，避免 UI 或監控把 tags-only readiness 誤讀為 generate failure。 |
| 2026-07-10 | PixelRAG VLM 空欄位與 Shopee language interstitial 必須自動轉 platform probe | V10.756 起 VLM prompt 明確把 language / region / app-download / landing / loading / logo-only / cookie consent pages 視為非商品卡；若 VLM 回傳所有 offer fields 皆空且 required title / price 缺失，worker 會標記 `non_product_or_interstitial_detected=true`，receipt 下一步改為 `run_platform_probe_or_use_structured_api`，不得反覆要求人工審核或無限 rerun VLM。 |
| 2026-07-10 | PixelRAG VLM worker preflight 必須容納 111 VLM 冷啟延遲 | V10.757 起 `run_pixelrag_vlm_replay_worker.py --execute` 與對應 API 的 `route_generate_probe_timeout` 預設為 20 秒；111 `minicpm-v` 在正式環境可於約 4 到 20 秒間完成小型 `/api/generate` probe，8 秒容易造成假陰性。若 VLM receipt 已判定 `run_platform_probe_or_use_structured_api`，run-level `next_machine_action` 也必須同樣輸出 platform probe，不得停留在 rerun VLM 摘要。 |
| 2026-07-10 | PixelRAG VLM language note / generic marketplace slogan 必須視為 interstitial | V10.758 起若 VLM notes 或 title 顯示 `Language selection page`、語言/地區選擇，或只抽到 Shopee `蝦皮購物 | 花得更少買得更好` 這類網站 slogan 且 price/shop 缺失，worker validation 會標記 `interstitial_signal_detected` / `generic_marketplace_title_detected` 與 `non_product_or_interstitial_detected=true`，run-level 與 item-level 下一步都輸出 `run_platform_probe_or_use_structured_api`。 |
| 2026-07-10 | PixelRAG platform probe 必須自動消化 marketplace interstitial / blocked receipt | V10.759 起 `/api/ai-automation/pixelrag-platform-probe`、`scripts/ops/report_pixelrag_platform_probe.py`、`/api/ai-automation/smoke` 與 `/api/ai-automation/scheduled-health-summary` 必須輸出 platform probe / `pixelrag_platform_probe` family；Shopee traffic / language / generic landing 會轉成 `run_shopee_public_context_probe_then_structured_source_fallback`，Coupang 403 / access denied 會轉成 `use_structured_source_or_platform_backoff_policy`。probe plan 只產生 public empty browser context、structured adapter fallback 與 no-write contract，不讀或注入 cookie/session/login，不寫 DB、不寫 `ai_insights`、不寫正式價格表；capture worker 只允許 locale/timezone/非敏感 header 並濾掉 Cookie / Authorization / token / secret / key 類 header。 |
| 2026-07-10 | PixelRAG platform probe worker 必須把 probe plan 變成 controlled automation | V10.760 起 `/api/ai-automation/pixelrag-platform-probe-worker`、`scripts/ops/run_pixelrag_platform_probe_worker.py`、`/api/ai-automation/smoke` 與 `/api/ai-automation/scheduled-health-summary` 必須輸出 controlled platform probe worker / `pixelrag_platform_probe_worker` family；dry-run 只規劃 capture 或 structured fallback，execute 模式才執行 public empty-context capture 或寫 structured-source/backoff artifact receipt。此 worker 明確標記 `network_call` 只在 capture execute 時為 true、`model_call=false`、`writes_database=false`、`writes_ai_insights=false`、`writes_price_tables=false`、`secret_read=false`、`raw_cookie_or_session_read=false`、`primary_human_gate_count=0`；capture 成功後必須回到 PixelRAG RAG candidate replay，不得直接寫正式價格或把 blocked page 當商品資料。 |
| 2026-07-10 | PixelRAG platform probe worker 缺 capture runtime 時必須自動降級 | V10.761 起若 `run_pixelrag_platform_probe_worker.py --execute --write-receipt` 在 app 容器偵測到 `ModuleNotFoundError: playwright`，worker 會自動產生 `capture_runtime_unavailable_structured_fallback_package` receipt，`network_call=false`、`artifact_write=true`、`writes_database=false`、`primary_human_gate_count=0`，不再把 Shopee/Coupang platform probe runtime gap 變成人工主流程。 |
| 2026-07-10 | PixelRAG platform probe worker receipts 必須回到 RAG/source-contract replay | V10.762 起 `/api/ai-automation/pixelrag-rag-candidate-replay` 與 `scripts/ops/report_pixelrag_rag_candidate_replay.py` 必須同時讀 visual capture receipts 與 `platform_probe_worker_receipt.json`；worker receipts 只能成為 `source_contract_fallback` / `eligible_for_source_contract_replay` 候選，並輸出 `platform_probe_worker_receipt_count`、`source_contract_fallback_count`、`capture_runtime_gap_count` 與下一步 `run_source_contract_replay_for_platform_probe_worker_receipts`。此路徑不寫 DB、不寫 `ai_insights`、不寫正式價格表、不把 blocked page 當商品資料，也不得退回人工審核主流程。 |
| 2026-07-10 | PixelRAG RAG replay 下一步不得隱藏並行主線 | V10.763 起若同一批 PixelRAG replay 同時存在 ready visual receipt 與 platform probe worker `source_contract_fallback` receipt，`next_machine_action` 必須輸出 `run_ocr_vlm_replay_and_source_contract_replay`，避免只顯示 OCR/VLM 而把 marketplace source-contract 自動化 lane 藏在 summary 裡。 |
| 2026-07-10 | PixelRAG source-contract fallback 必須有 controlled replay worker | V10.764 起 `/api/ai-automation/pixelrag-source-contract-replay-worker`、`scripts/ops/run_pixelrag_source_contract_replay_worker.py`、`/api/ai-automation/smoke` 與 `/api/ai-automation/scheduled-health-summary` 必須輸出 PixelRAG source-contract replay worker / `pixelrag_source_contract_replay_worker` family；worker 只讀 platform probe worker `source_contract_fallback` receipts，驗證 structured package、source count、no-DB、network-deferred、blocked-page-not-product-data、source receipt provenance，execute 模式只寫 `source_contract_replay_receipt.json` artifact。此路徑不抓外站、不呼叫模型、不讀 secret/cookie/session、不寫 DB、不寫 `ai_insights`、不寫正式價格表，下一步只允許進 marketplace source-contract adapter replay preflight。 |
| 2026-07-10 | PixelRAG marketplace source-contract adapter 必須先有 no-write preflight | V10.765 起 `/api/ai-automation/pixelrag-marketplace-source-contract-adapter-preflight`、`scripts/ops/run_pixelrag_marketplace_source_contract_adapter_preflight.py`、`/api/ai-automation/smoke` 與 `/api/ai-automation/scheduled-health-summary` 必須輸出 PixelRAG marketplace adapter preflight / `pixelrag_marketplace_adapter_preflight` family；preflight 只讀 `source_contract_replay_receipt.json`，驗證 replay ready、source contract version、adapter code、source count、source checks all passed、blocked page not product data、no-DB、network-deferred、public source boundary、rate-limit contract、provenance contract、identity/promotion gates 與 canonical offer fields。execute 模式只寫 `marketplace_adapter_preflight_receipt.json` artifact，不抓外站、不呼叫模型、不讀 secret/cookie/session、不寫 DB、不寫 `ai_insights`、不寫正式價格表，下一步只允許進 marketplace source-contract adapter dry-run。 |
| 2026-07-10 | PixelRAG marketplace adapter dry-run 必須先產生 no-write mapping receipt | V10.766 起 `/api/ai-automation/pixelrag-marketplace-source-contract-adapter-dry-run`、`scripts/ops/run_pixelrag_marketplace_source_contract_adapter_dry_run.py`、`/api/ai-automation/smoke` 與 `/api/ai-automation/scheduled-health-summary` 必須輸出 PixelRAG marketplace adapter dry-run / `pixelrag_marketplace_adapter_dry_run` family；dry-run 只讀 `marketplace_adapter_preflight_receipt.json`，驗證 preflight ready、canonical offer fields、required gates、no-DB/no-network/no-model、blocked page not product data 與 price-write blocked。execute 模式只寫 `marketplace_adapter_dry_run_receipt.json` artifact，產生 deterministic field contracts / offer candidate contracts，不抓外站、不呼叫模型、不寫 DB、不寫 `ai_insights`、不寫正式價格表，下一步只允許進 identity matcher replay。 |
| 2026-07-10 | PixelRAG marketplace identity matcher replay 必須先產生 no-write match receipt | V10.767 起 `/api/ai-automation/pixelrag-marketplace-identity-matcher-replay`、`scripts/ops/run_pixelrag_marketplace_identity_matcher_replay.py`、`/api/ai-automation/smoke` 與 `/api/ai-automation/scheduled-health-summary` 必須輸出 PixelRAG marketplace identity matcher replay / `pixelrag_marketplace_identity_matcher_replay` family；replay 只讀 `marketplace_adapter_dry_run_receipt.json`，驗證 adapter dry-run ready、identity key fields、candidate contracts、required gates、no-DB/no-network/no-model、source provenance 與 price-write blocked。execute 模式只寫 `marketplace_identity_matcher_replay_receipt.json` artifact，產生 deterministic identity candidate contracts，不抓外站、不呼叫模型、不寫 DB、不寫 `ai_insights`、不寫正式價格表，下一步只允許進 PromotionGate replay。 |
| 2026-07-10 | PixelRAG marketplace PromotionGate replay 必須先產生 no-write promotion receipt | V10.768 起 `/api/ai-automation/pixelrag-marketplace-promotion-gate-replay`、`scripts/ops/run_pixelrag_marketplace_promotion_gate_replay.py`、`/api/ai-automation/smoke` 與 `/api/ai-automation/scheduled-health-summary` 必須輸出 PixelRAG marketplace PromotionGate replay / `pixelrag_marketplace_promotion_gate_replay` family；replay 只讀 `marketplace_identity_matcher_replay_receipt.json`，驗證 identity matcher ready、identity checks all passed、required promotion gates、embedding signature guard readiness、no-DB/no-network/no-model、source provenance 與 price-write blocked。execute 模式只寫 `marketplace_promotion_gate_replay_receipt.json` artifact，產生 deterministic promotion candidate contracts，不抓外站、不呼叫模型、不寫 DB、不寫 `ai_insights`、不寫正式價格表，下一步只允許進 embedding signature guard replay。 |
| 2026-07-10 | PixelRAG marketplace embedding signature guard replay 必須先產生 no-write signature receipt | V10.769 起 `/api/ai-automation/pixelrag-marketplace-embedding-signature-guard-replay`、`scripts/ops/run_pixelrag_marketplace_embedding_signature_guard_replay.py`、`/api/ai-automation/smoke` 與 `/api/ai-automation/scheduled-health-summary` 必須輸出 PixelRAG marketplace embedding signature guard replay / `pixelrag_marketplace_embedding_signature_guard_replay` family；replay 只讀 `marketplace_promotion_gate_replay_receipt.json`，驗證 PromotionGate ready、PromotionGate checks all passed、expected embedding signature、signature guard contracts、candidate knowledge readiness、no-DB/no-network/no-model、no embedding generation、source provenance 與 price-write blocked。execute 模式只寫 `marketplace_embedding_signature_guard_replay_receipt.json` artifact，產生 deterministic signature guard contracts，不產生 embedding、不抓外站、不呼叫模型、不寫 DB、不寫 `ai_insights`、不寫正式價格表，下一步只允許進 candidate knowledge replay。 |
| 2026-07-10 | PixelRAG marketplace candidate knowledge replay 必須先產生 no-write internal RAG candidate receipt | V10.770 起 `/api/ai-automation/pixelrag-marketplace-candidate-knowledge-replay`、`scripts/ops/run_pixelrag_marketplace_candidate_knowledge_replay.py`、`/api/ai-automation/smoke` 與 `/api/ai-automation/scheduled-health-summary` 必須輸出 PixelRAG marketplace candidate knowledge replay / `pixelrag_marketplace_candidate_knowledge_replay` family；replay 只讀 `marketplace_embedding_signature_guard_replay_receipt.json`，驗證 signature guard ready、signature checks all passed、expected embedding signature、knowledge candidate text、internal RAG preview readiness、no-DB/no-network/no-model、no embedding generation、source provenance、AI insights write blocked 與 price-write blocked。execute 模式只寫 `marketplace_candidate_knowledge_replay_receipt.json` artifact，產生 deterministic internal RAG candidate preview contracts，不產生 embedding、不抓外站、不呼叫模型、不寫 DB、不寫 `ai_insights`、不寫正式價格表，下一步只允許進 internal RAG candidate canary。 |
| 2026-06-29 | PChome DB apply 授權 lane 必須先通過 no-write guard / decision preflight / decision closeout / issuer gate / signing-decision preflight / signing-decision closeout / signing-issuer guard | V10.725 的 PChome mapping backlog auto-policy 已新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-authorization-lane-guard`、`/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-authorization-decision-preflight`、`/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-authorization-decision-closeout`、`/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-authorization-issuer-gate`、`/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-authorization-signing-decision-preflight`、`/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-authorization-signing-decision-closeout` 與 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-authorization-signing-issuer-guard`；這些 endpoint 只驗證 final exact request package、same-run production truth requirement、secret rejection、rollback boundary、lane entry requirements、decision input requirements、rejection policy、post-apply verifier、future authorization decision package、final nonsecret authorization envelope、signing decision preflight inputs、unsigned signing decision package 與 signable request boundary，不讀 secret、不執行 shell/SQL、不寫 DB，也不簽發 database apply authorization。 |
| 2026-06-29 | PChome DB apply 授權簽署發行者 lane 必須先產出 final signable request package | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-authorization-signing-issuer-closeout`；此 endpoint 只把 signing-issuer guard 的 signable request boundary 收斂成 final signable request package 與 closeout contract，確認 fresh production truth、post-apply verifier、migration hash、secret boundary 與 no-side-effect checks，不讀 secret、不簽發 authorization、不執行 shell/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-29 | PChome DB apply 授權簽署執行 lane 必須先通過 operator-held secret boundary preflight | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-authorization-signing-execution-preflight`；此 endpoint 只把 final signable request package 轉成 future signing execution preflight package、operator-held secret boundary contract、nonsecret signing inputs、command-shape preview、rollback boundary 與 abort conditions，不讀 secret、不接受 plaintext secret、不簽發 authorization、不執行 shell/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply 授權簽署執行 lane 必須先產出 unsigned receipt boundary closeout | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-authorization-signing-execution-closeout`；此 endpoint 只把 signing execution preflight 收斂成 unsigned signed-authorization receipt boundary 與 closeout contract，確認 nonsecret inputs、operator-held secret boundary、production truth、post-apply verifier、migration hash、rollback/abort boundary 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不簽發 authorization、不產生 signed receipt、不執行 shell/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply 授權簽署收據 lane 必須先定義 external receipt evidence boundary | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-authorization-signed-receipt-preflight`；此 endpoint 只把 unsigned receipt boundary 轉成 external signing receipt evidence boundary，定義 external receipt id、payload hash、receipt hash、signer key reference、signature algorithm reference、detached verification status、production truth、post-apply verifier 與 rollback/abort boundary，不讀 secret、不接受 plaintext secret、不包含 signed receipt、不包含 signature material、不簽發 authorization、不執行 shell/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply 授權簽署收據 closeout 必須先產出 detached verification boundary | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-authorization-signed-receipt-closeout`；此 endpoint 只把 external signing receipt evidence boundary 收斂成 detached receipt verification boundary，確認 external receipt evidence contract、detached verification checks、operator-held secret boundary、production truth、post-apply verifier、migration hash 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signed receipt、不包含 signature material、不執行 detached verification、不簽發 authorization、不執行 shell/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply 授權簽署收據 evidence intake 必須先定義 detached verification evidence schema | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-authorization-signed-receipt-evidence-intake`；此 endpoint 只把 detached verification boundary 收斂成 external signed authorization receipt evidence intake schema，定義 verifier receipt hash、source chain ids、payload/receipt hash、signer key reference、signature algorithm reference、detached verification status 與 acceptance gates，不讀 secret、不接受 plaintext secret、不包含 signed receipt body、不包含 signature material、不執行 detached verification、不簽發 authorization、不執行 shell/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply 授權 detached verification evidence validation 必須先產出 verifier receipt closeout boundary | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-authorization-detached-verification-evidence-validation`；此 endpoint 只把 detached verification evidence schema 收斂成 verifier receipt closeout boundary，定義 verifier receipt id、source chain ids、payload/receipt hash、detached verification status、verifier receipt hash、post-apply verifier 與 acceptance gates，不讀 secret、不接受 plaintext secret、不包含 signed receipt body、不包含 signature material、不執行 detached verification、不持久化 verifier receipt、不簽發 authorization、不執行 shell/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply 授權 verifier receipt closeout 必須先產出 verifier receipt evidence handoff | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-authorization-verifier-receipt-closeout`；此 endpoint 只把 verifier receipt closeout boundary 收斂成 verifier receipt evidence handoff，定義 handoff id、source chain ids、verifier receipt id reference、external receipt id reference、payload/receipt/verifier receipt hash、detached verification status、post-apply verifier 與 acceptance gates，不讀 secret、不接受 plaintext secret、不包含 signed receipt body、不包含 signature material、不執行 detached verification、不持久化 verifier receipt、不簽發 authorization、不執行 shell/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply 授權 evidence execution preflight 必須先產出 final verifier handoff | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-authorization-evidence-execution-preflight`；此 endpoint 只把 verifier receipt evidence handoff 收斂成 future database apply authorization verifier handoff、authorization evidence execution preflight package 與 contract，確認 source chain ids、payload/receipt/verifier hash、same-run production truth、post-apply verifier 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signed receipt body、不包含 signature material、不執行 detached verification、不持久化 verifier receipt、不執行 authorization evidence、不簽發 authorization、不執行 shell/endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply 授權 evidence execution closeout 必須先產出 final verifier gate | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-authorization-evidence-execution-closeout`；此 endpoint 只把 authorization evidence execution preflight 收斂成 future database apply authorization final verifier gate、evidence execution closeout package 與 contract，確認 source chain ids、payload/receipt/verifier hash、same-run production truth、post-apply verifier、rollback/post-apply binding 前置條件與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signed receipt body、不包含 signature material、不執行 detached verification、不持久化 verifier receipt、不執行 authorization evidence、不執行 database apply、不簽發 authorization、不執行 shell/endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled-apply final preflight 必須先綁定 rollback 與 post-apply verifier | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-apply-final-preflight`；此 endpoint 只把 final verifier gate 收斂成 controlled apply final preflight、rollback binding、post-apply verifier binding 與 contract，確認 target migration hash、same-run production truth、post-apply verifier、rollback requirement、dry-run-only/check-mode-only 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled dry-run package 必須先產出 receipt preview 與 non-executable command shape | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-package`；此 endpoint 只把 controlled apply final preflight 收斂成 controlled dry-run package、dry-run command shape、dry-run execution receipt preview 與 contract，確認 rollback binding、post-apply verifier binding、target migration hash、same-run production truth、receipt preview-only、non-executable command shape 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled dry-run receipt closeout 必須先驗證 result parser 與 receipt preview | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-receipt-closeout`；此 endpoint 只把 controlled dry-run package 收斂成 controlled dry-run receipt closeout、dry-run result parser、receipt validation report 與 contract，確認 parser schema、receipt preview fields、command-shape hash、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled dry-run runner readiness 必須先綁定 non-executable execution plan | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-runner-readiness`；此 endpoint 只把 controlled dry-run receipt closeout 收斂成 controlled dry-run runner readiness、execution plan binding 與 contract，確認 result parser verification、receipt validation、command-shape hash、rollback/post-apply verifier binding、target migration hash、same-run production truth、runner execution gate closed 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled dry-run execution plan closeout 必須先驗證 non-executable command artifact | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-execution-plan-closeout`；此 endpoint 只把 controlled dry-run runner readiness 收斂成 controlled dry-run execution plan closeout、non-executable command artifact 與 contract，確認 execution plan binding preview-only、command artifact hash、result parser/receipt validation carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth、runner execution gate closed 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 command text、不包含 argv、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled dry-run command artifact closeout 必須先產出 runner execution receipt preflight | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-command-artifact-closeout`；此 endpoint 只把 controlled dry-run execution plan closeout 收斂成 controlled dry-run command artifact closeout、runner execution receipt preflight 與 contract，確認 non-executable command artifact hash、no command text、no argv、receipt preflight no-execute、result parser/receipt validation carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不捕捉 stdout/stderr、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled dry-run runner execution receipt closeout 必須先產出 post-receipt parser verification | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-runner-execution-receipt-closeout`；此 endpoint 只把 controlled dry-run command artifact closeout 收斂成 controlled dry-run runner execution receipt closeout、receipt closeout preview、post-receipt parser verification 與 contract，確認 runner execution receipt preflight no-execute、receipt closeout preview-only、parser blocks execution、result parser/receipt validation carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不捕捉 stdout/stderr、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled dry-run post-receipt parser closeout 必須先產出 no-apply enforcement verification | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-post-receipt-parser-closeout`；此 endpoint 只把 controlled dry-run runner execution receipt closeout 收斂成 post-receipt parser closeout、no-apply enforcement verification 與 contract，確認 parser preview ready、receipt closeout not executed、endpoint execution disallowed、SQL execution disallowed、database write disallowed、database apply unauthorized、result parser/receipt validation carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不捕捉 stdout/stderr、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled dry-run no-apply enforcement closeout 必須先產出 final dry-run executor guard | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-no-apply-enforcement-closeout`；此 endpoint 只把 post-receipt parser closeout 收斂成 no-apply enforcement closeout、final dry-run executor guard 與 contract，確認 no-apply enforcement preview ready、endpoint/SQL/DB write/apply 全部 disallowed、final executor guard 不允許 invocation、stdout/stderr capture closed、parser/receipt preview carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不捕捉 stdout/stderr、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled dry-run final executor guard closeout 必須先產出 pre-apply replay verifier | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-final-executor-guard-closeout`；此 endpoint 只把 no-apply enforcement closeout 收斂成 final executor guard closeout、pre-apply replay verifier 與 contract，確認 final dry-run executor guard preview ready、guard 不允許 invocation、pre-apply replay 只允許 preview、endpoint/SQL/DB write/apply 全部 disallowed、no-apply enforcement carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不捕捉 stdout/stderr、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled dry-run pre-apply replay closeout 必須先產出 apply executor readiness contract | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-pre-apply-replay-closeout`；此 endpoint 只把 final executor guard closeout 收斂成 pre-apply replay closeout、apply executor readiness contract 與 12 項 closeout checks，確認 pre-apply replay verifier preview ready、apply executor readiness contract 不允許 dry-run invocation、endpoint/SQL/DB write/apply 全部 disallowed、final guard/no-apply enforcement carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不捕捉 stdout/stderr、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 dry-run executor、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled dry-run apply executor readiness closeout 必須先產出 dry-run invocation readiness receipt | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-apply-executor-readiness-closeout`；此 endpoint 只把 pre-apply replay closeout 收斂成 apply executor readiness closeout、dry-run invocation readiness receipt 與 12 項 closeout checks，確認 apply executor readiness contract preview ready、receipt 只允許 preview、dry-run executor invocation/endpoint/SQL/DB write/apply 全部 disallowed、pre-apply replay/final guard/no-apply enforcement carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不捕捉 stdout/stderr、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 dry-run executor、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled dry-run invocation receipt closeout 必須先產出 no-write invocation package | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-invocation-receipt-closeout`；此 endpoint 只把 apply executor readiness closeout 收斂成 invocation receipt closeout、no-write invocation package 與 12 項 closeout checks，確認 dry-run invocation readiness receipt preview ready、no-write invocation package 只允許 preview、dry-run executor invocation/endpoint/SQL/DB write/apply 全部 disallowed、apply executor readiness/pre-apply replay/final guard/no-apply enforcement carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不捕捉 stdout/stderr、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 dry-run executor、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled dry-run no-write invocation package closeout 必須先產出 execution preflight guard | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-no-write-invocation-package-closeout`；此 endpoint 只把 invocation receipt closeout 收斂成 no-write invocation package closeout、execution preflight guard 與 12 項 closeout checks，確認 no-write invocation package preview ready、execution preflight guard 只允許 preview、dry-run executor invocation/endpoint/SQL/DB write/apply 全部 disallowed、invocation receipt/apply executor readiness/pre-apply replay/final guard/no-apply enforcement carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不捕捉 stdout/stderr、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 dry-run executor、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled dry-run execution preflight guard closeout 必須先產出 runner invocation boundary | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-execution-preflight-guard-closeout`；此 endpoint 只把 no-write invocation package closeout 收斂成 execution preflight guard closeout、runner invocation boundary 與 12 項 closeout checks，確認 execution preflight guard preview ready、runner invocation boundary 只允許 preview、dry-run executor invocation/runner invocation/endpoint/SQL/DB write/apply 全部 disallowed、不捕捉 stdout/stderr、no-write package/invocation receipt/apply executor readiness carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 dry-run executor、不執行 runner、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled dry-run runner invocation boundary closeout 必須先產出 no-execution receipt handoff | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-runner-invocation-boundary-closeout`；此 endpoint 只把 execution preflight guard closeout 收斂成 runner invocation boundary closeout、no-execution receipt handoff 與 12 項 closeout checks，確認 runner invocation boundary preview ready、no-execution receipt handoff 只允許 preview、execution receipt 不存在且不要求、dry-run executor invocation/runner invocation/endpoint/SQL/DB write/apply 全部 disallowed、不捕捉 stdout/stderr、execution preflight/no-write package/invocation receipt carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 dry-run executor、不執行 runner、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled dry-run no-execution receipt handoff closeout 必須產出 final no-runner-execution proof | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-no-execution-receipt-handoff-closeout`；此 endpoint 只把 runner invocation boundary closeout 收斂成 no-execution receipt handoff closeout、final no-runner-execution proof 與 12 項 closeout checks，確認 no-execution handoff preview ready、final proof 只證明 dry-run executor 未 invoked、runner invocation 未 performed、endpoint 未 executed、SQL 未 executed、database 未 written、execution receipt 不存在且不要求、stdout/stderr 不包含、previous closeouts carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 dry-run executor、不執行 runner、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled dry-run final no-runner-execution proof closeout 必須產出 controlled executor quarantine proof | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-final-no-runner-execution-proof-closeout`；此 endpoint 只把 no-execution receipt handoff closeout 收斂成 final no-runner-execution proof closeout、controlled executor quarantine proof 與 12 項 closeout checks，確認 final proof preview ready、controlled executor quarantine proof 只證明 executor quarantine bound/enforced 且 dry-run executor 未 invoked、runner invocation 未 performed、endpoint 未 executed、SQL 未 executed、database 未 written、execution receipt 不存在且不要求、stdout/stderr 不包含、previous closeouts carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 dry-run executor、不執行 runner、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled dry-run controlled executor quarantine proof closeout 必須產出 dry-run execution envelope freeze proof | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-controlled-executor-quarantine-proof-closeout`；此 endpoint 只把 final no-runner-execution proof closeout 收斂成 controlled executor quarantine proof closeout、dry-run execution envelope freeze proof 與 12 項 closeout checks，確認 controlled executor quarantine proof preview ready、execution envelope frozen 且不可 mutation、dry-run executor 未 invoked、runner invocation 未 performed、endpoint 未 executed、SQL 未 executed、database 未 written、execution receipt 不存在且不要求、stdout/stderr 不包含、previous closeouts carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 dry-run executor、不執行 runner、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled dry-run execution envelope freeze proof closeout 必須產出 frozen envelope verifier handoff | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-execution-envelope-freeze-proof-closeout`；此 endpoint 只把 controlled executor quarantine proof closeout 收斂成 execution envelope freeze proof closeout、frozen envelope verifier handoff 與 12 項 closeout checks，確認 dry-run execution envelope freeze proof preview ready、execution envelope frozen 且不可 mutation、verifier handoff 已綁定但 verifier invocation 未允許且未執行、dry-run executor 未 invoked、runner invocation 未 performed、endpoint 未 executed、SQL 未 executed、database 未 written、stdout/stderr 不包含、previous closeouts carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 verifier、不執行 dry-run executor、不執行 runner、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-06-30 | PChome DB apply controlled dry-run frozen envelope verifier handoff closeout 必須產出 verifier invocation lock proof | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-frozen-envelope-verifier-handoff-closeout`；此 endpoint 只把 execution envelope freeze proof closeout 收斂成 frozen envelope verifier handoff closeout、verifier invocation lock proof 與 12 項 closeout checks，確認 frozen envelope verifier handoff preview ready、verifier invocation 已鎖住且未允許、verifier 未 invoked、verifier receipt 不存在且不要求、dry-run executor 未 invoked、runner invocation 未 performed、endpoint 未 executed、SQL 未 executed、database 未 written、stdout/stderr 不包含、previous closeouts carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 verifier、不執行 dry-run executor、不執行 runner、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-07-01 | PChome DB apply controlled dry-run verifier invocation lock proof closeout 必須產出 verifier no-execution receipt proof | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-verifier-invocation-lock-proof-closeout`；此 endpoint 只把 frozen envelope verifier handoff closeout 收斂成 verifier invocation lock proof closeout、verifier no-execution receipt proof 與 12 項 closeout checks，確認 verifier invocation lock proof preview ready、verifier invocation 已鎖住且未允許、verifier 未 invoked、verifier receipt 不存在且不要求、dry-run executor 未 invoked、runner invocation 未 performed、endpoint 未 executed、SQL 未 executed、database 未 written、stdout/stderr 不包含、previous closeouts carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signature material、不執行 authorization evidence、不執行 database apply、不執行 verifier、不執行 dry-run executor、不執行 runner、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-07-01 | PChome DB apply controlled dry-run verifier no-execution receipt proof closeout 必須產出 verifier receipt persistence guard proof | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-verifier-no-execution-receipt-proof-closeout`；此 endpoint 只把 verifier invocation lock proof closeout 收斂成 verifier no-execution receipt proof closeout、verifier receipt persistence guard proof 與 12 項 closeout checks，確認 no-execution receipt proof preview ready、receipt persistence guard preview ready、verifier receipt persistence locked 且 not allowed、verifier receipt 未 persisted、verifier 未 invoked、dry-run executor 未 invoked、runner invocation 未 performed、endpoint 未 executed、SQL 未 executed、database 未 written、stdout/stderr 不包含、previous closeouts carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signature material、不持久化 verifier receipt、不執行 authorization evidence、不執行 database apply、不執行 verifier、不執行 dry-run executor、不執行 runner、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-07-01 | PChome DB apply controlled dry-run verifier receipt persistence guard proof closeout 必須產出 receipt persistence storage boundary proof | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-verifier-receipt-persistence-guard-proof-closeout`；此 endpoint 只把 verifier no-execution receipt proof closeout 收斂成 verifier receipt persistence guard proof closeout、receipt persistence storage boundary proof 與 12 項 closeout checks，確認 receipt persistence guard proof preview ready、storage boundary proof preview ready、receipt persistence storage boundary locked 且 storage write not allowed、receipt persistence storage 未 written、verifier receipt 未 persisted、verifier 未 invoked、dry-run executor 未 invoked、runner invocation 未 performed、endpoint 未 executed、SQL 未 executed、database 未 written、stdout/stderr 不包含、previous closeouts carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signature material、不持久化 verifier receipt、不寫入 receipt persistence storage、不執行 authorization evidence、不執行 database apply、不執行 verifier、不執行 dry-run executor、不執行 runner、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-07-01 | PChome DB apply controlled dry-run receipt persistence storage boundary proof closeout 必須產出 storage boundary no-write ledger proof | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-receipt-persistence-storage-boundary-proof-closeout`；此 endpoint 只把 verifier receipt persistence guard proof closeout 收斂成 receipt persistence storage boundary proof closeout、storage boundary no-write ledger proof 與 12 項 closeout checks，確認 storage boundary proof preview ready、no-write ledger proof preview ready、storage boundary locked 且 storage/ledger write not allowed、storage boundary 未 written、ledger 未 written、receipt persistence storage 未 written、verifier receipt 未 persisted、verifier 未 invoked、dry-run executor 未 invoked、runner invocation 未 performed、endpoint 未 executed、SQL 未 executed、database 未 written、stdout/stderr 不包含、previous closeouts carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signature material、不寫 ledger、不持久化 verifier receipt、不寫入 receipt persistence storage、不執行 authorization evidence、不執行 database apply、不執行 verifier、不執行 dry-run executor、不執行 runner、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-07-01 | PChome DB apply controlled dry-run storage boundary no-write ledger proof closeout 必須產出 no-write ledger retention proof | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-storage-boundary-no-write-ledger-proof-closeout`；此 endpoint 只把 receipt persistence storage boundary proof closeout 收斂成 storage boundary no-write ledger proof closeout、no-write ledger retention proof 與 12 項 closeout checks，確認 no-write ledger proof preview ready、retention proof preview ready、ledger retention locked 且 retention/ledger write not allowed、retention 未 written、ledger 未 written、receipt persistence storage 未 written、verifier receipt 未 persisted、verifier 未 invoked、dry-run executor 未 invoked、runner invocation 未 performed、endpoint 未 executed、SQL 未 executed、database 未 written、stdout/stderr 不包含、previous closeouts carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signature material、不寫 retention、不寫 ledger、不持久化 verifier receipt、不寫入 receipt persistence storage、不執行 authorization evidence、不執行 database apply、不執行 verifier、不執行 dry-run executor、不執行 runner、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-07-01 | PChome DB apply controlled dry-run no-write ledger retention proof closeout 必須產出 retention boundary no-write archive proof | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-no-write-ledger-retention-proof-closeout`；此 endpoint 只把 storage boundary no-write ledger proof closeout 收斂成 no-write ledger retention proof closeout、retention boundary no-write archive proof 與 12 項 closeout checks，確認 retention proof preview ready、archive proof preview ready、retention archive locked 且 archive/retention/ledger write not allowed、archive 未 written、retention 未 written、ledger 未 written、receipt persistence storage 未 written、verifier receipt 未 persisted、verifier 未 invoked、dry-run executor 未 invoked、runner invocation 未 performed、endpoint 未 executed、SQL 未 executed、database 未 written、stdout/stderr 不包含、previous closeouts carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signature material、不寫 archive、不寫 retention、不寫 ledger、不持久化 verifier receipt、不寫入 receipt persistence storage、不執行 authorization evidence、不執行 database apply、不執行 verifier、不執行 dry-run executor、不執行 runner、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-07-01 | PChome DB apply controlled dry-run retention boundary no-write archive proof closeout 必須產出 archive retention sealed handoff proof | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-retention-boundary-no-write-archive-proof-closeout`；此 endpoint 只把 no-write ledger retention proof closeout 收斂成 retention boundary no-write archive proof closeout、archive retention sealed handoff proof 與 12 項 closeout checks，確認 archive proof preview ready、sealed handoff proof preview ready、sealed handoff manifest hash 存在、sealed handoff locked 且 handoff/archive/retention/ledger write not allowed、handoff 未 written、archive 未 written、retention 未 written、ledger 未 written、receipt persistence storage 未 written、verifier receipt 未 persisted、verifier 未 invoked、dry-run executor 未 invoked、runner invocation 未 performed、endpoint 未 executed、SQL 未 executed、database 未 written、stdout/stderr 不包含、previous closeouts carry-forward、rollback/post-apply verifier binding、target migration hash、same-run production truth 與 no-side-effect checks，不讀 secret、不接受 plaintext secret、不包含 signature material、不寫 handoff、不寫 archive、不寫 retention、不寫 ledger、不持久化 verifier receipt、不寫入 receipt persistence storage、不執行 authorization evidence、不執行 database apply、不執行 verifier、不執行 dry-run executor、不執行 runner、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。 |
| 2026-07-01 | PChome retention boundary archive closeout 正式 readback 預設必須 compact | V10.725 正式環境已把 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-retention-boundary-no-write-archive-proof-closeout` 預設回應改為 `response_mode=compact`，保留 summary、future_readiness、sealed_handoff_proof、contract、12 checks、safety 與 next_actions；完整 nested proof payload 僅在 `full=1` 時輸出，避免正式 readback 產生數百 MB body。2026-07-01 production readback：`HTTP 200`、`content-length=8697`、`checks=12`、`writes_database_count=0`、`executes_sql_count=0`、`sealed_handoff_manifest_hash` 長度 64、`database_apply_authorized=false`、`writes_database=false`、`/health` 仍為 healthy PostgreSQL `V10.725`。 |
| 2026-07-01 | PChome DB apply controlled dry-run archive retention sealed handoff proof closeout 必須產出 sealed handoff verifier transfer proof | V10.725 的 PChome mapping backlog auto-policy 新增 `/api/ai/pchome-growth/mapping-backlog/auto-policy-db-apply-controlled-dry-run-archive-retention-sealed-handoff-proof-closeout`；此 endpoint 預設 `response_mode=compact`，只把 archive retention sealed handoff proof 收斂成 archive retention sealed handoff proof closeout、sealed handoff verifier transfer proof 與 12 項 closeout checks，確認上一段 retention boundary no-write archive proof closeout ready、sealed handoff proof preview ready、sealed handoff manifest hash locked、verifier transfer proof bound、verifier transfer write locked、verifier invocation not allowed、verifier receipt not persisted、endpoint/SQL/DB 未執行、previous closeouts carry-forward、rollback/post-apply verifier binding、target migration hash 與 no-side-effect checks；完整 nested proof payload 僅 `full=1`，不讀 secret、不接受 plaintext secret、不包含 signature material、不寫 verifier transfer、不寫 handoff、不持久化 verifier receipt、不執行 authorization evidence、不執行 database apply、不執行 verifier、不執行 dry-run executor、不執行 runner、不執行 endpoint/SQL、不寫 DB，也不代表正式 DB apply 已授權。Local focused tests：archive retention sealed handoff proof closeout `2 passed`；retention boundary + archive retention chain `5 passed`；完整 PChome mapping backlog test file `218 passed`。2026-07-01 production readback：`HTTP 200`、`content-length=8425`、`response_mode=compact`、`checks=12`、`writes_database_count=0`、`executes_sql_count=0`、`verifier_invoked_count=0`、`verifier_transfer_manifest_hash` 長度 64、`database_apply_authorized=false`、`writes_database=false`、`/health` 仍為 healthy PostgreSQL `V10.725`。 |
