FR-066 檢測 Agent 原生安裝包 — LOG（append-only，每棒追加一 block，寫完永不改）

現況看同資料夾 FR-066-STATE.md；本檔只記脈絡：commits／決策（含被排除的）／教訓／推翻了什麼。

commits: BE c0d137be（discussion＋design＋README 登記，D1–D9 定案）／d9ec17f4（D8 補 Windows 可行性初判附錄）。evidence-agent 零改動（已切 feature/FR-066，HEAD 0c47463）。 Notion: 母案 CM-1284＋子需求 CM-1285~1288＋子任務 CM-1289~1300，17 卡連號一次建齊，全 Not started。

做了什麼:

• 走 big-feature-workflow：兩支 Explore 平行探脈（①agent 現況——三容器結構、agent-db 實際只服務 upload_files 一張表、指紋 workaround、DI 靜態清單；②FR-063/064/065 可複用資產盤點——build 管線／私房 wheel／簽章泛用層／install.sh 七步）→ 討論稿 D1–D9 → user 逐項拍板 → design.md 落地（含分工概述節）→ 17 卡建立。
• 討論稿／design 皆產 HTML（doc-site-build）。

決策（含被排除的，全文見 design.md §3）:

• D2 SQLite 化：由決策者「agent 有本地 db？」的質疑觸發查證——追碼確認 agent-db（postgres:16）只服務 jedi-file-upload 一張表、create(checkfirst=True) 自建無 migration，遂裁換 SQLite。被排除：要求宿主裝 PG（違背一鍵安裝）；bundle PG（為一張表多維運一個服務）。Q2 方言掃描列 T-1.1 前置守門。
• D3 工具全包一顆：決策者裁定，理由＝封閉網路（FR-059.3 已驗證的既定支援情境）下分層附加包漏帶即現場死局、無網可補；體積 ~1GB+ 明示接受。被排除：分層附加包、宿主前置需求清單（後者另踩 CINC 授權紅線——客戶自裝官方 InSpec）。
• D6 簽章瘦身版：首腦列 FR-064 複用選項後決策者問「有需要嗎」，裁定值得但瘦身——只做 build 期 manifest 簽章＋啟動驗章（agent 以 root 跑客戶機、握 mTLS 憑證，是信任鏈最易被摸的一端）；排除 runtime 全家桶（抽查／lockdown，對 agent 過重）。
• D8 Windows：只出評估文件不實作；另口頭討論形成可行性初判（Nuitka/SQLite/paramiko 路線恰好都沒堵死 Windows；瓶頸在工具鏈離線化＋SmartScreen code signing），決策者令補入 design 附錄（d9ec17f4），明標「初判非定案」作 T-4.3 起點。
• D9 指紋不預抽 OS 抽象層：Windows 未定案，為未定需求預先抽象＝過度設計；排除「先抽象層」案。

教訓: Case No 連號一次建完有效——母→子需求→子任務依序建，17 卡號段乾淨無散落，跨 session 溝通只講卡號即可。

推翻了什麼: 無（本 arc 首棒）。

留給下一棒: 等 user 發令派第一棒 T-1.1（CM-1289 SQLite 化，含 Q2 前置掃描）；T-4.3（CM-1300 Windows 評估）無依賴可平行先派。改 code 一律在 evidence-agent repo（feature/FR-066），BE 只放文件。

commits（皆已 push）: evidence-agent e6aff6a（SQLite 化）／b003db9（程式改造）／7c3ea0c（依賴對齊＋欄位自癒清單驅動）／6e48236＋cab945a（build 管線＋Q3）／1425a61（lock 入版控）／265f5f8（jedi_* 判定統一）。jedi-common 53e03e1＋ec3d4ee（0.0.31 已發 Nexus）。 Notion: 追加開 CM-1303（T-1.3.1）／CM-1304（T-1.3.2）；CM-1289/1290/1291 收 修正待驗證。

做了什麼: 派 4 棒 runner 走完 FR-066.1 三張原卡＋兩張追加卡。每棒親驗不採信自報（自己跑 pytest／自己造舊 DB 測自癒／自己解析 lock／自己做突變測試）。

決策（含被排除的）:

• T-1.1 SQLite 化採 B 案（修 jedi-common）：runner 查出擋點是 jedi-common session_scope() 無條件下 SET LOCAL（PG 專屬），停下報 A（agent 端 monkey patch）/ B（改套件）。首腦查證後推翻 runner 的成本估計——B 對主專案零風險（主專案釘 0.0.30、agent 釘 0.0.25，本來就版本隔離；改法依 dialect 判斷，PG 路徑行為恆等），且開發期走 path dependency 不卡卡。排除 A：等於在 Nuitka 二進位裡藏對第三方套件內部實作的覆寫，落地版產品不該留。
• storage_scope 自癒補欄從「附帶」升為必做：runner 列為 A 案附帶項，首腦實測後認定阻斷性——該欄 nullable=False，既有 agent.db 升 jedi-file-upload 0.0.22 後所有上傳直接 OperationalError。同時實測 SQLite 接受帶 DEFAULT 的 NOT NULL ADD COLUMN。並要求改成欄位清單驅動而非再寫死一支。
• 依賴組合對齊主專案（A 案）：runner 發現首腦漏列 python-dotenv 擋點（與 Flask 同源，皆 c6188f7 資安修抬下限），停下報 A（升 jedi-file-upload 0.0.22）/ B（升 0.0.19 最小可解）/ C（放寬下限）。裁 A：B 省下的不是風險而是版本分岔，日後每次升級都要重解同題且跨度更大；C 與 Flask 同源，退回資安修補。
• poetry.lock 入版控：BE .gitignore:213 證據顯示 BE 2026-08-15 踩過同一顆雷、原文用詞「歷史誤加」，理由同為落地版產線的可重現保證。agent 照 BE 收斂，並讓解析改吃 lock（比 BE 原版更穩，兩種宣告格式皆適用）。

教訓:

• user 手動跑 build 抓出 runner 在本機驗不出的問題（兩次）。本機 macOS/aarch64 出不了 Linux 產物、Nexus 憑證在 keychain 帶不進容器，runner 跑不到 Step 1 後段。真 build 機才驗得出的東西，不要接受「本機驗過了」。
• 連續兩棒 runner 改完 code 就收工——CM-1303／1304 的 ③（188 build）④（smoke）都沒做、沒來要 push、沒回寫卡片狀態。派工單雖寫了「需要時明確請決策者 push」，仍失效。下一棒要把「未完成項要明說」寫得更硬。
• 「三處寫法不一致就統一」是形式思維（見下方推翻）。

推翻了什麼:

• 首腦推翻自己對 CM-1304 處②的判斷。原卡把 assert_protection（:533）判為「假通過、必須改用統一 helper」。runner 未照做並回報反駁；首腦親手實測驗證 runner 正確——加 __init__.py 濾網會跳過「Nuitka 只漏子模組、頂層無 __init__.py」這種真實漏收形態（實測：現行寫法 leaked=1 擋下，加濾網 leaked=0 放行）。處①③ 是身分清單（名字要 import／餵 --include-package，撈到 metadata 當場炸），處② 是洩漏掃描器（失敗方向是漏掃，範圍越寬越好），方向相反不該統一。首腦當初看到「三處不一致」就要求統一，是把形式一致看得比語意重要。runner 的 helper 也優於首腦建議（合法識別字白名單 vs 黑名單排除 *.dist-info）。
• 首腦在 T-1.2 派工單把 nmap.py _NMAP_BIN 誤列為「agent 本機執行、要配置化」，實為受測機工具（全程 client.exec_command）。runner 查證後正確拒改並回報，已於 T-1.3 卡更正。
• 首腦在 T-1.3 派工單漏列 python-dotenv 擋點（只查了 Flask 那半邊）。

留給下一棒: 唯一待辦＝188 完整 build + 五項 smoke（CM-1304 ③④）。265f5f8 已 push，188 git pull 即可。此關通過即 FR-066.1 收口，接著進 .2。T-4.3（CM-1300）仍可平行。

⚠️ 本棒收工時未更新 STATE/LOG（違反交接紀律），本 block 由第 4 棒接手後從 git/188/Notion 卡反推補記——細節以各卡（CM-1305~1308）上的首腦驗收紀錄為準。

commits（evidence-agent，皆已 push）: af56f2d（CM-1305 smoke_agent_release.sh 五項驗證）／ee0b1e0（CM-1306 EXCLUDE_COMPILE_PKGS 清空——排除編譯會讓產物啟動即死）／57ed03f＋4fa0e0b（CM-1307 身分守門＋空白名單誤判修正）／9a7a9ef＋9f0b804＋238d067（CM-1306/1308 smoke 第 4 項三修）／7b751ea（build 自動寫 log）。 Notion: 追加開 CM-1305~1308 四張卡，皆做完收 修正待驗證（各卡附首腦獨立驗收紀錄）。

做了什麼: 188 完整 build 通關（265f5f8，Step1 含 Nexus 依賴全綠、Nuitka 6m29s、產物 278M→後續 316M）；建立 smoke 五項量尺並連環抓出量尺自身三個假綠。

決策:

• EXCLUDE_COMPILE_PKGS 清空（CM-1306）：FR-063 BE 的排除名單照抄到 agent 會讓產物啟動即死，agent 依賴集合不同，名單歸零重評。
• assert_protection 三處寫法不統一是「語意不同」非「不一致」：處①③是身分清單（撈到 metadata 當場炸）、處②是洩漏掃描器（範圍越寬越好）——第二棒已記此教訓，本棒落實。

教訓（三次同型病，全靠突變測試抓出）:

• CM-1305：assert_protection 掃 0 個檔仍印通過；CM-1306：smoke 第 4 項檔案被移走仍 PASS；CM-1308：nmap.xsl「求得出值」即算通過。共同形態＝「沒看到壞消息 ≠ 好消息」——任何「驗證器」類程式，不做突變測試等於沒驗。
• 本棒沒補 STATE/LOG 就收工，第 4 棒接手時交接檔停在第二棒、與實況差一整棒，靠 git/Notion 反推才還原——交接檔補帳成本遠高於當下順手寫。

推翻了什麼: 第二棒 STATE 寫「唯一待辦＝188 build+smoke」低估了收口成本——build 一次過，但量尺可信度花了四張追加卡。

留給下一棒: smoke 得 4/5（第 4 項 4c 假紅，決策者 2026-08-20 09:41 親跑撞出）→ 開 CM-1309。

commits: evidence-agent 0fc80c8（CM-1309 smoke 第 4 項改抓路徑而非中文字串，本機=origin=188 三處同步）。BE：本棒 STATE/LOG 補帳。 Notion: CM-1309 開卡並收 修正待驗證；CM-1284 母卡／CM-1286（.2）改 In progress；CM-1285（.1）改 修正待驗證；CM-1292（T-2.1）補四項裁示後派出。

做了什麼:

• 接手時 STATE 停在第二棒，靠 git/188/Notion 反推還原第三棒實況（見上 block）。
• 應 user 要求調查 agent↔︎BE 連線與派工機制（兩支 Explore 平行）：派工＝agent 心跳 poll 夾帶 pending_tasks，非 BE push；控制面 agent 撥出（mTLS）、資料面 BE 反打 agent 8443（nginx sidecar 驗 mTLS＋60s JWT＋指紋）；報告 binary 留 agent 本地、BE 反向拉。與業界對照（Nessus/Qualys 同款心跳領工模式）確認 D1 方向正確。發現一個 .3 前置項：D4 寫 gunicorn/ssl 自起 8443，但 gunicorn 不在 agent 現行依賴內——T-3.1 要新增依賴並確認 Nuitka 相容。
• CM-1309 驗收：修法（抓 ASCII 路徑取代 grep 中文）正確，runner 主動加測紅 C（模擬路徑寫死）補齊雙向牙齒；產物本尊 5/5。FR-066.1 收口。

決策（.2 開工裁示，全文在 CM-1292 卡）:

• 工具包取得＝manifest＋fetch 腳本進版控、binary 走 build 機 cache（user 提出「compile 時自動拉，不然會忘」，取代首腦原提的「188 固定目錄＋文件」——docker 時代 Dockerfile 就是這個精神）。
• 支援範圍＝第一版正式支援 Ubuntu/Debian，不主動堵其他家族（保險性質）：bundle 盡量發行版無關形式；Q1 判準改「portable 優先」；字型直落檔；xsltproc→lxml 評估；git 降 Q5 查證（FR-059.3 後 profile 走雲端下發，Git URL 可能已是死路；封閉網路天生用不到）傾向不進 bundle。
• CINC 不改遙控器模式（user 問「可否像 OpenSCAP 改遙控」）：OpenSCAP 引擎在受測機成本趨近零（發行版官方源一行裝），CINC 無任何發行版源、275MB 要逐台散佈，agentless 正是其核心賣點；且 D3 已接受體積，動機不成立。
• T-4.3 不提前看（user 問「先看才不會 Linux/Windows 重工？」）：D9 已裁不預抽抽象層；.1 程式改造天然跨平台（D8 附錄逐層驗過）；會重工的部分（工具離線化/安裝腳本/服務形式）本來就是兩平台各寫，提前看省不掉。

教訓:

• runner 收工必須連 STATE/LOG 一起收——第三棒實作與驗收品質都好，唯獨沒補交接檔，第 4 棒花一整段還原。交接檔補帳應列入首腦每棒收工 checklist，不等 user 提醒。

推翻了什麼: 首腦原提「工具包放 188 固定目錄＋文件記載」被 user 的「build 時自動拉」方案取代（更優：可重現、防忘、防篡改三者兼得）。

留給下一棒: CM-1292 runner 進行中（等回報→首腦親驗）；後續 T-2.2（CM-1293）→T-2.3；T-4.3 可隨時平行；user 複驗 .1 後收 CM-1285＋10 張子卡 Done。

commits（evidence-agent，皆已 push）: T-2.1 系 393eef6~a73fc64（CM-1292/1310/1311/1312）／T-2.2 a19e68d＋LC 6c1d916（CM-1293）／T-2.3 a11ccf2+7925258（CM-1294，追加 CM-1313）／T-2.4 f20a7e1（build_all）／T-3.1 fc9cd23+0bc41b9+91cef8f（CM-1295）／T-3.2 a6dc132+f823e50+ff3429c（CM-1296）／T-3.3 d255fc1~9e0142e 7 顆（CM-1297）／T-3.4 34f7386（CM-1314）／T-3.5 ab849ce（CM-1315）。BE：a821638d（§2 概述判定欄）+8b83de06（雙層 manifest 回寫）。 Notion: 開 CM-1313（build_all）/1314（位址偵測）/1315（TOFU）/1316（installer PKI，掛 FR-065 CM-1189）/1317（時區 bug）；1292 收 Done、其餘 .2/.3 卡皆修正待驗證。

做了什麼: 一天內走完 .2 後半＋.3 全部＋真機驗收主體。每卡首腦親驗（自跑 smoke/自比 kid/自查 188 清理/DB 反查），三次抓到自己環境操作錯誤而非 runner 錯誤。決策者親手走「compile→打包→搬 123→裝→上線」全鏈，撞出三個只有真實部署才現形的缺口，全數當日立卡、兩張當日修復。

決策（各卡詳情在卡上）:

• T-2.3 雙層 manifest（agent 層＝啟動 gate／bundle 層＝交付完整性，互鎖）——實作發現單份與 gate 掃描錨點衝突，正常包必誤判竄改；首腦判定為正確的落地調整並令回寫 design。
• D6 邊界再確認（決策者三問三答）：防護定位＝防第三方植入＋出貨損壞，不宣稱擋機器擁有者；只啟動時驗一次「就夠了」；「塞新檔不擋」維持與主產品一致。
• 產線即真相（決策者拍板）：撤掉 .1 基準產物保護與全部 .build-tXX，出貨＝build_all 裸跑，「上線產生的就是要好的」→ memory feedback_no_golden_artifact_hoarding_pipeline_is_truth。
• push 概括授權（限本 FR）＋188 jedi 免密 sudo 開通——runner 迭代速度明顯加快。
• T-3.5 TOFU 而非 http 降級：決策者問「認自簽 or 開 8000 走 http」，裁 TOFU（首連指紋確認、無 insecure 開關）；http 快解嘗試後放棄（188 8000 未曝露且 80 強轉 https），「先不搞特例」。
• 設計文件概述升級（決策者反饋「太工程師」）：§2 加「完成怎麼判定（決策者檢查法）」欄，規則固化進 big-feature-workflow skill＋docs-conventions＋memory。

教訓:

• 真機驗收的價值無可替代：容器裡全綠的東西，真機一天撞出三缺口（自簽憑證/installer PKI/時區判離線）——全是「DEV 環境恰好不觸發」的類型。arc 尾聲必須排真機真環境親測，越早越好。
• T-3.5 順帶抓到三處「拿內部 CA 驗雲端 https」的既有錯鏈——http 時代無症狀的錯，證明「一次修齊全部呼叫點」的派工要求是對的。
• 188 手動補 PKI 撞權限坑（鑰 root:600 但容器 app 以 guidant 跑→500）：installer 自動化時 owner 必須一次做對，已寫進 CM-1316 規格。

推翻了什麼: 「.1 產物不可覆蓋」紅線由決策者主動撤銷（產線自證可重現後基準無意義）——首腦原本還在為它鋪 BUILD_ROOT 繞路，應更早主動提議解除。

留給下一棒: CM-1317（BE 時區）＋CM-1316（installer PKI）兩棒跑中等驗；.4 三張（T-4.1 收口/T-4.2 手冊/T-4.3 Windows）；design D6 註記；DEV 測試資料收尾清。

commits（BE，均在 feature/FR-066）: eee68284（CM-1316 installer agent 對接段，scripts/installer/ 專屬）／7c037530（CM-1317 時區分流：agent 心跳統一 UTC＋公告日期改營運時區＋backfill SQL，DEV 已套）。 Notion: CM-1316/1317 收 修正待驗證；CM-1299（手冊）範圍升級為含憑證金鑰全景清單（決策者拍板，動機「這麼多要簽的東西沒紀錄，除錯要重頭挖很恐怖」）。

做了什麼: 兩棒衍生修正親驗收訖；188 手補 PKI 走到終態（換 RSA JWT 鑰＋123 重 enroll）；憑證文件化裁示落卡。

決策:

• CM-1317 修法二分（runner 查證後定案，優於原卡假設）：agent 心跳＝機器時戳→統一 UTC；公告上下架＝使用者填的日曆日期→維持原值、比對改台北營運時區（改存 UTC 會讓 8/20 變 8/19 16:00）。「時戳在未來即判離線」防護——寧可誤報離線，不讓死 agent 假活。
• backfill 裁示自我修正：首腦原裁「一律 backfill」，後修正為查證項——心跳每 5 分鐘自然覆寫，活 agent 無需 backfill；runner 最終以「未來時戳」為條件做冪等 backfill（只動確實漂移的列），DEV 4 列換算淨。
• 188 JWT 換 RSA（CM-1316 runner 抓到 ed25519 雷：兩端寫死 RS256，register/heartbeat 不簽所以全綠，第一次資料面呼叫才炸）：188 重生 RSA 2048→api 重啟→123 清憑證重 enroll（uid 不變，指紋接回）。
• 憑證三世界全景入 T-4.2：產品簽章（LC 鑰/硬編公鑰）／Agent 通訊 PKI（一站一組四件：agent CA、agent 憑證、BE client 憑證、RSA JWT 鑰）／Web TLS（自簽 https＋TOFU 信任檔）——每張列用途/落點/效期/演算法限制/換發影響/缺件症狀。

教訓:

• runner 查證推翻首腦開卡假設（8 小時差是首腦 psql 查證方法錯誤，非程式行為；真 bug 方向相反=TZ=UTC 假活）——開卡的「實測證據」也可能是查證方法的假象；且首腦被打臉後給的下一個裁示（backfill）仍未查證，應對剛被推翻的領域加倍謹慎。
• 「查證後再修」派工模式全勝：1317 若照原卡直接修就修錯方向還可能弄壞好的（落地版本來自洽）。
• 手動補環境（188 PKI）連補的人都會埋雷（ed25519）——「手動步驟固化進 installer」不只是省工，是把驗證程式碼化（installer 生的鑰用 BE 真實 code 驗過全鏈）。

推翻了什麼: CM-1317 開卡的根因假設（時區混算致離線）——實際離線成因是 BE 缺 cloud client 憑證（健康檢查覆蓋心跳判定），時區是另一顆方向相反的真 bug。兩者都已收。

留給下一棒: §3 的端到端閉環驗證（新 installer 從零裝→agent 接→派真任務）＝T-4.1 主體；T-4.2（含憑證全景）/T-4.3 待派；D6 註記；收卡與 DEV 資料清理。本棒為第五棒收官，首腦交接在即——接手者走 §0 讀序即可冷接。

（第五棒尾註，2026-08-21 晨追記）: 決策者走 OpenSCAP 首單（123 掃 151）時撞出capability 申報鏈缺口：測試連線回「本租戶尚無可用的檢測 Agent」——detection_tool_service.py 篩 detection_scan capability，但 enroll 從不寫 capabilities、DB 恆為預設 ["file_storage"]。已盤點入 STATE §3 第 0 條（含待查證項：FR-057 當時怎麼過的），留給下一棒查證開卡。SSH 稽核鑰模型已與決策者對齊（一把共用鑰：公鑰灑受測機、私鑰貼工具設定、UI 單憑證組是產品缺口候選）。Rocky Linux 支援現況也已對齊（Ubuntu/Debian 正式支援、EL 系未驗證不主動擋、有需求再開 EL9 驗證卡）。

commits（BE，均已 push）: d723e064（CM-937 心跳接收 capabilities）／02aa4e27（PDF 預覽 500）／23772d2f（CM-1322 基線補漏：stage_objects＋哨兵＋PGTZ）／e87b35b0（CM-1322 Profile 進基線＋id 重排）。evidence-agent: ee31c4c（CM-937 自報 capabilities，0.2.28）。 Notion: CM-937（7 月舊卡復活修畢）＋CM-1322（新開）皆收 Done；CM-1322 卡上累積 8 段追加（裁決軌跡完整）。

做了什麼: 接手日即實戰日——決策者在 188 走 OpenSCAP 首單，一路撞出的缺口當日全收：①capability 申報鏈（enroll 從不寫→CM-937 心跳自報，runner 修畢）②188 落地版 stage_objects 全缺（基線漏收→手灌解封＋CM-1322 根治）③FR-059 Profile 庫 seed 全缺（同病）④分類字典不在基線⑤BE image 缺 CINC（解析失敗→override 掛宿主）⑥build_bundle storage-seed 非空跳過重建（靜默漏 8 支 profile 檔→清目錄重打）。三工具首單全通：OpenSCAP 103 findings 回收入池、CINC（sudo NOPASSWD:ALL 換 oscap 單項後通）、GCB（正規匯入＋重解析後通）；ZAP 為工具自身連線池壞死（重啟解）；160 實為 Windows 機（WinRM 路線）。

決策:

• D11.4 推翻（決策者：「不可能讓管理員做，要預設裝好就有」）→ Profile 比照 D11.1 原廠匯好進基線，三件套（資料列＋upload_files＋檔案實體）同進；CINC 取捨＝方案 1+3（基線帶解析結果、image 不裝、自傳場景文件掛載法）。
• seed id 連續（決策者要求）→ dump 時重編 1..N，引用欄位同步、uid 不動、四條 join 防呆。
• 188 資料三分類（決策者裁示）：UI 匯入合規框架＝基礎資料不可清（合規資源庫不在保護傘）；首腦手灌照裁示；殘渣逐項請示不批次清。
• flow_templates 走 A 案維持 D11.2 兩筆（runner 三度以既有拍板擋下首腦錯誤指令）。

教訓:

• 首腦開卡連錯三次同型錯（D11.2/D11.4/「DEV 現值當真相」）——開卡前必查 FR-065 D11 系列出貨決策；runner 堅持查證優先是本棒最大品質來源。
• 手灌抄捷徑必產壞連結：GCB 派工當場炸出 file_id 斷鏈，正是 D11.4 預言的坑由首腦親手種下；「走正規 API 匯入」才是原廠備料的唯一正解。
• venv root 殘骸（sudo pip 遺毒）讓一般身分修復靜默失敗、build 反覆炸同一斷言——sudo 清骸＋拔 direct_url.json 後根治；勿對專案 venv 用 sudo pip。
• 靜默失敗三連發（storage-seed 跳過重建／哨兵 UPDATE 0 筆／capability 恆空）——共同解法＝把斷言埋進建庫與打包，缺料當場中止。

推翻了什麼: D11.4（帶檔＋UI 匯入）整條路線；CM-1322 開卡時的兩項指令（flow_templates 4 筆／Profile 進基線的原始理由）；首腦「瀏覽/派掃正常只有下載壞」的錯誤斷言（GCB 派工即讀檔）。

留給下一棒: ①build_bundle storage-seed 完整性檢查（對映表並集比對）未派——prompt 已擬在對話中；②「188 同時是運行庫與 seed 真相來源」結構問題，runner 已正式提報建議另開卡；③PROD 簽發鑰四步組（FR-062 既有待辦，正式客戶包前必辦）；④e2e 機（guidant-ai-e2e）上的驗裝與 cm-e2e 舊 agent 三容器並存，正式 T-4.1 驗收仍應乾淨機重走；⑤1316/1317 等「修正待驗證」卡與 .4 三張照舊。決策者宣告本段結束，下一戰線＝agent 改結構。

commits（詳各卡）: evidence-agent 05c181a（T-6.2）→1132150+2584e25（T-6.1）→b08a14c（T-6.5）→85275e1~ac5045a 6顆（T-6.3）→dd62b00~b50e52a 6顆（T-6.6）→86a04dd~6f86303 5顆（T-6.7）。BE daa982b7（.5 拆卡）→2ecf1e5d（.6 拆卡）→13141f62（T-6.5/D14）→664912e7（T-6.6/D15）→4fa4d18c（T-6.7）→7058a9b6（CM-1331 守門）→ffca7c41（CM-1333 恢復）→429a4c21（skill 收工硬檢查）。FE af04fe1（409001 i18n）→1143e37（恢復按鈕）。三 repo 皆已 push。 Notion: 開 1318~1321（.5，全暫緩）／1323~1330（.6 主線）／1331~1332（守門修正+主體包）／1333~1335（恢復預設三張）。1324/1325/1326/1328/1330/1331/1333/1334 修正待驗證（皆首腦親驗）；1335 已派跑動中。

做了什麼: 兩天走完三波需求變化——.5（Rocky/RHEL）開卡即被 PM 暫緩；PM 揭示 agent 本源是跨網段證據存放（FR-039），拍板 .6：compose 形態＋SeaweedFS 內建儲存＋指紋二源化；接著三個 UX 追加（互動安裝程式/顯示名稱/恢復預設）與一顆守門 bug（191 撞出）。

決策（詳 design.md §3）:

• D11 指紋二源化全域（拿掉 MAC）：docker 下 MAC 量不到，machine-id/product_uuid 掛載可得；撞號防護搬 BE enroll 端。runner 實測抓到守門第一版形同虛設（指紋 fallback resolve 到被撞列）＋upgrade 不更新 ctl 副本，皆修。
• D12 雙形態單產線：compose=有 docker 首選/原生=封閉網路；同一顆 Nuitka 產物同一套簽章，build_all 兩出口；升級包不帶 seaweedfs image，形態宣告寫 manifest 檔頭（不靠檔案在不在推論）。
• D13 「使用 Agent 服務」=FR-039 既有功能：首腦原判為新功能被決策者糾正——BE/FE 零新功能，只做 agent 端。
• D14 儲存設定 CLI 先做、web 下發開評估卡（CM-1329 等 PM，資安題：客戶儲存憑證進不進雲端）。
• D15 compose 版配互動安裝程式（照 FR-065 主產品模式）：首版「手填 .env+compose up」被決策者打回——受眾是一線工程師/業務，不假設會 docker。
• 恢復預設方案（1333/1334/1335）：出廠快照（主產品 FACTORY_DEFAULT 隱藏列/agent factory-defaults.env）＋一鍵恢復，user 不翻帳密；排除動態讀現值/教 user 翻 credentials/恢復重生帳密。
• CM-1331 守門 A 案：系統設定四頁 route 掛 system_config.* 但 seed 發的是分頁式能力點，191 DB trigger 證實 system_config.* 是平台能力點不可掛 tenant 角色→route 按 GROUP 分流。191 blsadmin 臨時 break-glass 升 super_admin（1335 驗四頁前必收回）。
• T-6.2 防篡改查證：SeaweedFS 3.99 Object Lock 實測有效但整桶刪擋不住＋我們根本沒啟用→對外只可講「改動必被偵測」（雲端 sha256 錨點），不可講 WORM/不可刪除。
• agent 自更新：記 follow-up 不開卡；觸發重估=單客戶 agent 十台級。registry 拉取=與封閉網路結構衝突，否決不記。

教訓:

• runner 收尾漏是系統性的（1330/1334 連兩棒 code 全好但狀態/回寫全漏）→ skill 補「開工標 In progress」（d553bcf1，runner 自修）＋「收工硬檢查四項」（429a4c21）。開工早於 skill 修正的棒吃不到，首腦驗收時代收。
• 驗收環境打折會掩蓋真缺口：T-6.6「乾淨機」在有既存 stack 的 188 模擬，剛好機上有 seaweedfs image→「第三方 image 沒進包、封閉網路裝不起」被掩蓋，決策者提問才暴露。已立 CLAUDE.md「打折要當場講明」。
• 逐項驗證是時間殺手（T-6.6 八支子命令七輪）：已立 CLAUDE.md「批次驗證」；後續派工 prompt 標配「單卡只驗增量+smoke，全景留部署卡」。
• 首腦兩次誤判被決策者糾正（D13 既有功能/D15 交付受眾）——需求的「給誰用」比「做什麼」更容易想當然。

推翻了什麼: .5 的「於 .4 收口前完成」（PM 暫緩改最後）；T-6.3 首版交付形態（手填 .env 被 D15 打回，產物保留當積木）；CM-1317 之前「188:443=PRD」的疑慮（查實為 FR-066 測試環境，容器標籤而已）。

留給下一棒: ①1335 跑動中（回報後親驗，含收 1330/1332/1333 未驗清單＋191 break-glass 收回＋190 sudo 收回）；②T-6.4（1327）端到端=1335 後下一棒；③T-4.3（1300）零依賴可平行派；④T-4.1（1298）含斷網驗證；⑤T-4.2（1299）手冊（含憑證全景+雙形態）等前面收完；⑥design D6 註記；⑦總複測收卡等決策者。新環境座標：190=agent 驗收機（臨時免密 sudo 待收）、191=落地版 PRD 驗收機（blsadmin 臨時 super_admin 待收）。

commits（BE）: 4d172cae（CM-1300 Windows 評估文件，runner 產出）＋本棒 design/STATE/LOG 更新（commit 待收）。evidence-agent: a89a701（CM-1335 runner：交付包收斂一顆，已 push）。 Notion: .6 全系 1323~1328/1330~1335 收 Done（決策者裁示 .6 通過）；1298 改暫緩（D16）＋卡上補裁示註記；1299 補範圍調整註記（compose 為主）；1286/1287 對齊「修正待驗證」、1288 改 In progress；1300 修正待驗證（首腦親驗合格，等決策者過目）。

做了什麼: 接手即三事——①派 T-4.3（CM-1300）Windows 評估（決策者追加四項：docker 過渡/互動設定對應/工時/宿主覆蓋），runner 產出後親驗抽查實碼引用全對；②1335 回報進來親驗（191 break-glass 收回 DB 實查 f、升級補快照實跑通過、四頁守門決策者手測）；③決策者揭示「原生暫不出貨」裁示未落文件——查證屬實（LOG/design 全無此記錄），補立 D16 落 design.md＋全卡對齊。

決策:

• D16 出貨形態收斂（決策者，本棒補記）：原生 tarball 暫不出貨、現階段一律 compose 版；開發成果保留、解凍等商務需求。T-4.1 暫緩、T-4.2 改 compose 為主。⚠️ 斷網封閉網路驗證（D3 根基、至今無人跑）不隨原生凍結，歸屬待裁示。
• 交付包一顆通吃（決策者於 1335 過程裁示，推翻 CM-1330 裁示①）：install/upgrade 兩包差僅 82MB seaweedfs image，兩條路維護不值；客戶端以「本機已有該 image」為升級放行。
• WSL 過渡風險接受度（決策者口頭）：指紋重置後可重綁定即可接受——T-4.3 的「不建議」限縮為「不當長期正式形態」，PoC/短期過渡可行。
• T-4.3 用高階 model 派工（評估文件=決策依據，裁量/整合/錯誤隱蔽三軸全高）。

教訓:

• 口頭裁示不落文件會斷鏈：「原生暫不出貨」這種案級方向性翻盤，前幾棒未收進 LOG/design，第八棒靠決策者本人提醒才補——方向性裁示當場落 LOG 應成慣例，別等交接才整理。
• T-4.3 評估修正了 D8 附錄兩處初判（NSSM 已死改 WinSW 系；Azure Trusted Signing 台灣不可用）——初判素材與正式查證的差距實證。

推翻了什麼: D12 的出貨面（雙形態同時出貨→compose 單軌，D16）；CM-1330 裁示①（兩包制→一顆通吃）；T-4.3 初判的 NSSM 建議。

留給下一棒: ①190 砍掉重裝驗證（onepack 首裝全鏈＋恢復循環＋upgrade，1335 未驗假設①②）；②T-4.2 手冊（範圍已定，可派）；③1300 等決策者過目收 Done；④design D6 註記；⑤殘餘修正待驗證卡（1286/1287/1293~1297/1316/1317）等總複測；⑥懸置裁示項：斷網驗證歸屬、191 免密 sudo 收回、PROD 簽章鑰。

commits（BE）: d481ee49（.7 立案 D17）→239641f8（驗收機 161→160）→bdc21d2d（T-7.1 探路報告，runner）→50af617e（T-7.1 附錄：時鐘偏差 JWT P0，runner）→0cfb886a（.8 立案 D18）→0004a4f2（T-7.4 判死報告，runner）→9187d91d（D19 全凍）＋STATE/LOG 本更新。 Notion: 開 1336~1339（.7）／1340~1345（.8）／1346（T-7.4）／1347（主產品手冊對齊）；1337/1346 探路完成收 Done；其餘 Windows 卡全暫緩＋凍結註記；1299 復活（Linux only 範圍）。

做了什麼: 一天內走完 Windows 三路線的立案→實測→翻盤→收束：D17（Docker Desktop 先行）→決策者實際使用發現登出全滅→T-7.1 實測確認 P0＋D18（原生版唯一出貨路線＋code signing 階段策略）→PM 轉向 B→T-7.4 生死驗證判死→PM 最終拍板 D19 全凍、Linux 為主。轉向手冊戰線：開 1347、復活 1299、雙派工 prompt 備妥。

決策（詳 design.md D17/D18/D19）:

• 技術結論鏈：Docker Desktop 綁登入 session（出貨不可）；WSL VM 閒置 60 秒凍 userspace、四種挽救全滅（B 判死）；Windows 無人值守唯一活路＝原生服務版；掃 Windows 的現行解＝Linux agent CINC WinRM 遠端掃（既有功能）。
• code signing 階段策略（D18 內）：現在不買、第一個正式 Windows 客戶在望買 OV、救火買 EV。
• 首腦 Hyper-V appliance 提案被決策者當場駁回（＝要客戶出一台 Linux，非解法）——正確的駁回。

教訓:

• 探路卡的錢極值：T-7.1/T-7.4 兩張小卡（各一天）擋下了 10~30 人日級的錯誤投資；T-7.4 runner 的觀察者效應發現（wsl.exe 探測會喚醒 distro、把死的看成活的）是本 arc 品質最高的實測之一。
• 決策者的實際使用是最強測試：登出全滅是決策者日常操作撞出來的，評估文件與探路清單都沒排進去。
• 需求的分岔要早問：「要掃 Windows」vs「agent 要裝在 Windows」是兩個需求，前者既有功能已解——這題早問可能省掉整條 .7/.8。

推翻了什麼: D17（Docker Desktop 先行——當日即被 T-7.1 P0 推翻）；D18 的「C 唯一路線」執行面（PM 裁投資等訊號）；首腦誤收母卡（Windows/手冊未完，決策者糾正後撤銷）；首腦 Hyper-V 提案（決策者駁回）。

留給下一棒: ①雙手冊派工（1347/1299，prompt 在對話中已交付決策者）；②手冊收完＋user 過目→母卡收口；③design D6 註記仍欠；④掛置項見 STATE §3 第 5 條。

（第八棒續尾註，2026-08-23）: 決策者拍板 189 路線：手冊收完→v1.16.0 進版→189 由源碼裸跑遷 FR-065 bundle 形態，之後全環境統一 --upgrade 升級模式。189 盤點發現：跑已退役 main_app.py、main HEAD 8c82e8e6（~1.13 era）、DB 在機上 postgres 容器 25432。前置與順序已入 STATE §3 v2。版本事實：main=v1.15.0 正式；feature/FR-066 有 4 顆功能 commit 未 merge（BE 1331/1333、FE 1324/1333）；191 跑的 1.15.0 bundle 內容超前 main 同版號（烙印 429a4c21），進版時收斂。context 過半，本 session 收到「雙手冊親驗完」為止，其後交下一棒。

（第八棒收官尾註，2026-08-23 午後）: 手冊戰線四卡收 Done——1347（onprem 對齊 55 commit 落差，抓到「檢測 Agent 全線在手冊不存在」最大缺口）／1299（agent 手冊 11 章：憑證三世界全景＋資料保護責任＋時鐘同步排錯）／1348（決策者初審「看不懂」打回 → 21 章全面白話化，每章導言＋術語括號註解＋指令前後白話句）／1349（build 工具洞：HTML 內 .md 互連未改寫致連結全壞——修渲染層非修文件；衍生 SPEC 站白名單補 license-guide＋system-integrity 兩頁清 pre-existing 死連結，runner 撞「不可動」清單正確停下請示、決策者裁選項 1）。教訓：①手冊受眾校準要在派工 prompt 就給白話範本（design §2 文風），首版沒給就返工一輪；②文件站 build 產物要實際點過連結才算驗（本棒自己漏了，決策者點出）。BE 領先 origin 16 顆待 push。交接：決策者要討論新需求（另開 session），本 session 止於此；下一棒接 §3 主線（v1.16.0 前置），開工先問決策者「發版前要先處理的需求」是什麼。

（第八棒終註——全案收口，2026-08-23）: 決策者下令收尾。母卡 CM-1284 收 Done（卡上有完整交付清單＋殘項）；FR-065 側同日收 1246（.4）/1264（T-4.2）/1275（.5）——1264 首腦驗後按縮減範圍收：①全鏈與③負面案由既有棒次驗證涵蓋，②PROD 鑰窄驗證移出（實查 public_keys.py 僅 DEV/STG/POC 三把，PROD 鑰未生成）移轉 189 遷移線補做；1265（FR-065 Windows 評估）標暫緩由 FR-066 三份文件取代。FR-065 剩母卡 CM-1189 收口（等 SUMMARY＋189 線）。FR-066 未做 SUMMARY——決策者未下令，殘項與教訓已在母卡與本 LOG 齊備，需要時由 LOG 濃縮。BE 領先 origin 17+ 顆待 push。