建議 model：opus／effort：medium — 動的是出貨 build 線與安裝包，驗收要在乾淨環境做且有「驗收環境打折」的已知陷阱。

本卡屬 FR-107（母卡 CM-1843）第 .6 棒（子需求卡 CM-1849），子任務 T-6.4：把分類容器加進出貨的 build 與打包流程，讓客戶裝完就能用。

這張卡做什麼（白話）

寫設計時查出來的缺口：現行安裝包根本沒有帶分類容器 image（scripts/build/ 與 scripts/installer/ 兩處 grep classifier 零命中）。落地版客戶裝完，就算 API 都在，按分類會因為 docker run 找不到 image 而失敗。

決策者裁示：進安裝包，隨三顆主 image 一起 build（走 FR-065 的 build 線）。這張卡做三件事：

動哪些檔

主專案
scripts/build/build_all.sh       ← 加第四顆 image（現在是三顆）
scripts/build/build_bundle.sh    ← 打包進安裝包
scripts/installer/  compose 設定 ← 加對應 service／image 參照
scripts/build/README.md          ← build 細節的 canonical，要同步

image 來源：套件 repo 的 docker/（T-2.3 搬過去的）
image 名：evidence-classifier，tag＝套件版號（T-6.2 發的那個版）

🔴 build 機座標（BE build 一律在這裡跑，不在本機）
  188 的 /opt/guidant-ai-be（GitLab clone，更新走 git pull——部署機鐵律，禁 scp／rsync）
  開跑前必做：
    ① git pull 到目標 commit
    ② pgrep -f 'nuitka|build_all'  查有沒有別人在跑（互撞會 linker crash）
  產物落 .build/dist|bundle|logs/

🔴 驗收環境打折要當場講明

這張卡的驗收條件是「全新裝機（不手動 docker pull／docker load 分類 image）後能跑完一次分類」。如果因為環境限制只能「模擬」乾淨環境（例如在已經有 stack 的機器上改埠避開佔用），當下就要把打折處寫進回報，不可以報成「通過」。

這條是 2026-08-22 用一次真事故換來的：T-6.6 的「乾淨 docker 機」是在有既存 stack 的 188 上靠改埠模擬的，而那台機器剛好早就有 SeaweedFS image，於是「交付包沒把第三方 image 包進去、封閉網路裝不起來」這個真缺口被驗收環境掩蓋，直到決策者提問才暴露。本卡驗的正是同一類問題（image 有沒有真的進包），特別容易被同樣的方式掩蓋。

怎麼做（逐步）