FR-064 交接 LOG（append-only）

每棒收工 append 一個 block，寫完永不改。發現舊 block 有誤 → 在新 block「推翻了什麼」欄更正。

commits: BE eba7f5a0..4fe7638a 共 16 支（含 design 7ceb7188 前置）；LC 6ce339e/57c6566/076c06b。兩 repo 皆已 push 與 origin 同步。 Notion: CM-1208~1229 卡樹建立；CM-1215~1223/1226/1227/1230 → 修正待驗證；CM-1224/1225/1228/1229 未派；CM-1188 母案續掛。

做了什麼:

• 接手戰線 → CM-1207 驗收收 Done → big-feature-workflow 全程（探脈×2 → 討論稿 90828118 → D1–D10 拍板 → design.md 7ceb7188 → 22 張卡樹 CM-1208~1229）
• 五波 runner 派工與驗收（.1/.2/.3/.4/.6ab 全過，含夜間授權自主兩棒）
• 188 build 事故鏈排除（branch 未切／LC 三連炸／token 未進 shell）
• 簽章鏈首次全通實證（真 dist manifest → LC 簽 → BE 驗 → 抽檔 sha256 全中）

決策: D1–D10（詳 design.md §2）。D8 由 45min 改 4h+jitter（user 裁示，容錯靠 D10 二次確認與 jitter 防節奏）；D9/D10 討論中新增；unlock 走離線信封、棄 activation_code 線上模型。manifest 缺席行為＝dist 強制/源碼跳過（runner 自定，user 未明示追認——接手注意）。

教訓:

1. 「本機測試綠」≠「部署機會產出」——188 停舊 branch 讓 build 跑舊腳本，驗收漏了「碼到得了現場」這環，被 user 指正「呼嚨」；未實證清單要集中列給 user 看，不散落各棒回報。
2. env 變數自創撞名（LC_API_TOKEN vs 既有 LICENSE_CENTER_API_TOKEN）＋錯誤預設 port——已固化 CLAUDE.md 鐵則（f8d1632b）。
3. bash 腳本不讀 .env——user token 填了卻被判未設定，已修 fallback（4fe7638a）。
4. LC 部署三連炸（依賴／unit 過時 exit0／缺 migration）→ 四步 SOP 固化（memory＋LC CLAUDE.md 076c06b）。
5. 稽核判準「套件內有 getenv ≠ 產品要填」（GITLAB 誤收案例）。

推翻了什麼: C 棒自創參數名（6f37019e 廢除）；.env 稽核首輪誤收 9 支（4b2234ac 移除）。

在途: user 正重跑 188 build（本次起自動送簽）；AGENT_CERT_VALID_DAYS 已處置（9508c7f8）但其他 env 項 user 另 session 處理中。

留給下一棒: build 完先做真產物集中驗證（smoke＋gate 真驗＋改檔拒啟），再派 .5/.6.3。

commits: LC 7c2974d（tamper 事件接收端點＋migration＋tamper_report 模組）；BE d181fdc6（best-effort 回報模組＋兩處掛點）。兩邊皆未 push。

做了什麼:

• LC：POST /api/internal/report-tamper（走 62.10 internal API 形狀），新表 tamper_events，migration 4328af2b0ece 已套 DEV。
• BE：common/integrity/lc_report.py（stdlib-only、3s timeout、全域 except），掛進 startup_gate._record_and_refuse 與 runtime_check._respond_to_tamper。
• 三情境實測（非模擬）：源碼模式模擬 tamper → LC dev 收到並落 DB（清除測試資料）；LC 位址不通 → 3.01s 內返回無 traceback；未設 token → 0.0003s 靜默跳過。
• 回歸：BE 50 支 integrity 測試全綠；LC 360 支通過（另 2 支失敗屬其他並行 session 進行中改動，非本卡）。
• CM-1228 回寫「修正待驗證」＋白話補充。

教訓:

1. 同一 LC checkout 有另一 session 並行動 modules/integrity/（FR-064.5 T-5.1 unlock token 簽發）——非 worktree，即時撞了 models.py/repository.py 兩次被覆寫。發現後把本卡模組改放 modules/tamper_report/，未動對方任何檔案。後續派工若可能撞路徑，建議指定 worktree 或明確劃分模組命名。
2. Alembic autogenerate 在多 session 併發改 model 時會把「尚未落地的別人的表」一併抓進來——已手動裁剪 migration 只留自己的 tamper_events。

推翻了什麼: 無。

留給下一棒: .5 unlock 全鏈（CM-1224/1225）看起來已有另一 session 在跑（modules/integrity/、unlock.py、common/integrity/unlock.py 皆已出現改動但未經本棒驗證，接手者需自行盤點其進度）。T-6.3 完成後 .6 子需求全數修正待驗證，可推進 .7 E2E 收口前的整體 push 齊備檢查。

commits: BE（單支，純文件），git add 顯式列檔，訊息帶 CM-1234。

做了什麼:

• 落地 2026-08-16 拍板的 D11 三件事到 design.md：①鎖定溝通改 B 方案（lockdown 殼，取代純 exit）②forensic 證據規格擴充（mtime/ctime/owner/size＋依來源分級觸發脈絡）③邊界明文＋契約措辭建議（「是誰改的」應用層不可知，條款綁「完整性驗證失敗」而非「查明行為人」）
• design.md：§4.4 整段改寫（4.4.1–4.4.4）；§2 補 D11 決策列（含被排除的 A 純 exit／C 半套方案與理由）；§5 新增 FR-064.8 段（T-8.1–T-8.4，標注依賴關係）；檔頭 lede／變更紀錄補一行
• deployment-env.md（FR-063 資料夾，本案適用落點——找不到 FR-064 自己的部署文件，沿用 FR-063 落地版部署文件）新增 §9「客戶端主機層留證建議」：auditd 監控規則範例、log 外送建議、邊界明文；原 §9 交付前檢查清單順移為 §10
• 跑 doc-site-build 重 build FR-064 站，成功

決策: 無新決策，純落地既定拍板內容，不加料。

教訓: 無。

推翻了什麼: 無。

留給下一棒: T-8.1（lockdown 殼實作）／T-8.3（forensic 擴充）依賴 CM-1224/1225/1228 主鏈程式碼完成後才能開工；T-8.2（FE 認錯誤碼跳轉）契約已定可先行派工。

commits: FE repo（compliance-manager-fe，branch feature/FR-064）單支 de23772，git add 顯式列檔，訊息帶 CM-1232。未 push。

做了什麼:

• src/config/axios/axios-interceptors.js：response interceptor 新增 INTEGRITY_503001 分支（形狀對齊既有 LICENSE_403001 靜默分支）——不 emit axios-error（不 toast）、把 BE lockdown 殼回應 data.machine_fingerprint/tamper_event_id/detected_at 透過 query 帶進 router.push({name:'system-locked', query:{fp,eid,at}})；模組級旗標防同一瞬間多隻請求重複導向。
• src/config/router/index.js 新增 /system-locked route（不掛 AppLayout、無 requiresAuth——被鎖時可能拿不到 token）。
• 新頁 src/views/default/SystemLocked.vue：視覺沿用 NotFound.vue 品牌光暈骨架，顯示「系統已鎖定」＋聯繫原廠 hint-bar＋三值（機器指紋／事件編號／偵測時間，前兩者帶複製按鈕，複製邏輯抄 LicenseActivation.vue 的 copyMachineCode 形狀）；query 缺值時 fallback「請洽系統管理員查閱伺服器紀錄」；頁面不發任何 API。
• 新 i18n 檔 system-locked.json（en/zh-tw，system_locked namespace），已在 config/locales/index.js 註冊；error-code.json（en/zh-tw）補 INTEGRITY_503001 條目（雖不 toast，仍照 BE error code 同步 FE i18n 慣例補齊）。

決策: 無新決策，純照派工 prompt 定死契約實作。

驗收（dev server + chrome devtools MCP 實測）:

1. 直接 GET /system-locked?fp=...&eid=...&at=...——三值正確渲染，複製按鈕點擊成功彈「已複製到剪貼簿」toast，console 無 error。
2. 直接 GET /system-locked（無 query）——正確落 fallback 文案。
3. 直接呼叫 axios 已註冊的 response interceptor rejected handler、餵入模擬 BE lockdown 殼回應（error_code: INTEGRITY_503001）的 fake error——確認未 emit axios-error（無 toast）且 router 正確跳轉並帶對三個 query 值，證實「BE 回 503 → FE 認碼 → 跳鎖定頁」整條路徑成立。
4. 登入頁 smoke（渲染、無 console error）確認未影響既有流程。

教訓: 無。

推翻了什麼: 無。

留給下一棒: T-8.1（lockdown 殼實作，BE）／T-8.3（forensic 擴充）仍待 CM-1224/1225/1228 主鏈程式碼完成後才能開工；T-8.2 完成後，一旦 T-8.1 殼落地即可整鏈端到端驗（真殼回 503 → 真瀏覽器打真 API → 跳鎖定頁）。

commits: LC 651db9c（CM-1224）／BE f8133e72（CM-1225）。兩 repo 皆 branch feature/FR-064，顯式 git add，未 push。

做了什麼:

LC 側（T-5.1）——新 modules/integrity/（models/repository/service）＋SSR 後台頁 /unlock ＋ CLI issue-unlock-token 保底＋ migration 49629d9e5d99（表 unlock_token_issuance，只套 DEV）。payload 依 design §4.3 定死，走 6ce339e 的泛用 sign_payload（無第二套簽章實作）。效期預設 72h（1–336h）。service 層守門（三入口共享）：指紋 64 hex、event_id evt- 前綴、效期範圍。下載檔名固定 unlock.token、不套 v3 armor（armor 標頭寫 GUIDANT LICENSE，會讓客戶誤當授權照上傳）。log 依安全鐵律：指紋只記 fingerprint_digest 前 12 碼、nonce 不記。

BE 側（T-5.2）——新 common/integrity/unlock.py（同套件約束：只 stdlib＋無依賴純函式）。核銷四關（驗章→指紋→event_id→nonce）＋效期關，掛進 startup_gate.run_startup_gate() 的 FS 標記分支。成功則清標記＋記 nonce＋刪 token 檔＋留回執，繼續往下跑 manifest 比對（不 return）。DB 側 unlocked_at/unlock_nonce 由 sync_unlock_receipt_to_db() ＋ repo.mark_unlocked() 回填，掛在 scheduler 首輪同一 tick。

決策（三項，皆屬派工單留給實作棒的形式選擇）:

1. LC 入口選 SSR 後台頁，不做 internal API——要解鎖的機器正處於拒啟狀態，跑不起來也就打不了 API；行為者是坐在瀏覽器前接客戶電話的內部人員，形狀同「離線開通受理」。CLI 為 air-gapped 保底（同 issue／sign-manifest 雙軌）。沒有第三軌 API：沒有呼叫端的端點只是多開攻擊面。
2. unlock 另立 modules/integrity/ 不塞 licensing——unlock token 不是授權照（無 Plan／訂單／展延／開通綁定），塞進去只會讓那模組變雜物間；共用的「同私鑰、同 sign_payload」本就在 core/crypto。
3. DB 回填走「回執檔」而非從 nonce 帳末筆推導——標記清除後 event_uid 就沒了，而那正是 UPDATE 的 WHERE 依據。回執寫不進去不阻斷解鎖（解鎖已成立，純紀錄失敗不該否定已成立的授權行為）。

幾個刻意取捨（避免下一棒「好心修掉」）:

• nonce 帳毀損取寬鬆側（回空清單）：取嚴格側會讓一次檔案損毀就再也解不開只能重灌；寬鬆側最多讓某張已用 token 再用一次，仍受效期／指紋／事件三關拘束。與標記檔「毀損即視同鎖定」方向相反是刻意的。
• 標記毀損時一律不放行解鎖：否則「先把標記改亂碼、再拿任一張舊 token」就成了繞法。
• nonce 寫不進去時不放行（記不住＝失去防重放），但訊息明確標示為環境權限問題，避免現場誤判成 token 有問題而白跑一輪重簽。
• 四種失敗訊息各自不同且含處置建議：含糊訊息會讓現場把「指紋抄錯」誤判成「原廠簽錯了」。

驗收（全部用 LC 真 DEV 鑰簽出的 token，非模擬信封）:

1. 正確 token → 核銷成功、標記清除、nonce 入帳、token 檔刪除、回執產生 ✅
2. 重放同 nonce → 拒 ✅　3. 事件編號不符 → 拒 ✅
3. 另簽一張 fingerprint=b*64 的真 token → 指紋關擋下 ✅（不是靠改檔破壞簽章矇混——那只驗得到驗章關）
4. 回溯 issued_at 簽一張真的過期 token → 效期關擋下 ✅
5. 未放 token → 靜默拒啟不噪音 ✅
6. DB 回填（真 DEV DB）：FS→DB inserted=True → 回執回填 updated=True → 回執清除 → 重複回填 False（unlocked_at IS NULL 生效）→ 無回執 no-op；psql 查得兩欄正確落列，測試列已清除 ✅
7. LC 後台頁走完整 HTTP 流程（登入→表單→簽發→結果頁→下載）簽出的檔，直接放進標記目錄被 BE 核銷成功——跨 repo 端到端 ✅

測試：LC 17 條（全站 378 綠）／BE 16 條（license+integrity 相關 120 綠）。突變驗證：BE 四關逐一停用各紅對應那一條、還原復綠（每關獨立可證）；LC tamper_event_id 組錯→2 紅、預設效期 72→71→1 紅。

教訓:

• 自證式斷言抓不到東西：assert expires - issued == timedelta(hours=DEFAULT_VALID_HOURS) 拿常數比自己，把 72 改成 71 測試照樣綠。改成字面 72 才有牙齒——突變測試就是為了逼出這種。
• 「用改壞的檔案驗某一關」是假驗證：改 payload 會同時破壞簽章，於是四關全被第一關攔下，看起來全過、實際只驗到驗章。指紋關與效期關各補簽一張真的才算數。
• base.html 加導覽項會連帶打斷測試：test_csrf / test_login_lockout 的最小 app fixture 逐一 stub 了每個 nav endpoint，新增一項就要同步補，否則 url_for BuildError。
• load_dotenv() 是相對呼叫檔解析而非 cwd——臨時驗證腳本放 scratchpad 時要帶絕對路徑。

推翻了什麼: 無。design §4.3 的契約與派工單裁定（FS 通道、四關、nonce 落 FS、DB 補寫比照 T-3.3）全部照做，未偏離。

留給下一棒:

• .5 只在源碼模式驗過（GUIDANT_TAMPER_MARKER_DIR 指臨時目錄、手造標記檔）。真 Nuitka dist 的完整重啟循環（gate 拒啟 → 放 token → 重啟解鎖 → 檔案未還原立刻再鎖）未跑，建議併入「真產物集中驗證」一起做。
• DB 回填走的是直接呼叫 service（真 DEV DB），非經 scheduler tick 實跑。
• LC migration 只套 DEV；STG/POC 上版時 alembic upgrade head 會一併帶 49629d9e5d99 與平行棒的 4328af2b0ece。
• 平行棒（CM-1228 T-6.3）同時段在 LC 動工，本棒的 migrations/env.py 一行 import 被掃進其 7c2974d——內容正確，僅歸屬提醒。
• 零新增環境變數（兩側皆沿用既有），.env.sample / deployment-env.md 無須異動。

commits: BE 520fc5e3（CM-1231 lockdown 殼）／24834d73（CM-1233 forensic 擴充）／aeb2bd44（CM-1233 補 boot 的 app.log 尾段，review 後補）。branch feature/FR-064，顯式 git add，未 push。LC 側零改動（見下）。

做了什麼:

T-8.1 lockdown 殼——新 common/integrity/lockdown.py（stdlib http.server，無 Flask/DI/DB、零寫入面）。任何路徑任何方法回 HTTP 503；內容協商：Accept: text/html 或瀏覽器 UA → 繁中鎖定頁，其餘 → JSON envelope（code:0／error_code:INTEGRITY_503001／data 三欄），契約照 FE de23772 定死未動。startup_gate._refuse() 收斂全部拒啟路徑：印完整 log → 起殼 → 殼起不來才 SystemExit。runtime 抽查／埋點維持既有「寫落點＋os._exit」不變。

T-8.3 forensic——新 common/integrity/forensic.py。collect_file_metadata（mtime/ctime/owner/size，個別 stat 失敗記 error 不阻斷）＋collect_trigger_context 依來源分級（boot app.log 尾段／scheduler 活躍 session 快照／hook 當下帳號＋IP）。三落點吃同一份 detail 物件（一處建構三處同步）。

決策（實作棒的形式選擇）:

1. 殼要放 CORS——派工單沒提，但不放行 preflight 的話跨源 FE 收到的是 network error 而非 INTEGRITY_503001，「FE 認碼跳鎖定頁」整條契約會斷。殼本來就沒有機密與寫入面，Allow-Origin: * 不放寬任何能力。
2. 活躍 session 資料源選 public.api_logs——HTTP middleware 全自動寫入，是唯一「不必額外埋點就有帳號＋IP＋時間」的現成來源。不為一份旁證另建活躍 session 表。窗口 30 分鐘（抽查週期 4h，太長會把早已離線的人算進來）。排除 user_name 為空字串的未登入流量（那不是 session）。
3. 不符檔案的「路徑清單」與「人類可讀描述」分開回傳（_GateFailure.mismatched_paths／_check_files 回 tuple）——從描述字串反解路徑會依賴訊息格式，訊息一改 forensic 就靜默失準。

確認不需要動的兩件事（派工單列為「若…則…」的分支，實查後都不成立）:

• DB 無須 migration：integrity_tamper_events.detail 本來就是 JSONB（psql \d 確認）。
• LC 端無須調整：report-tamper 的 detail 收 ma.fields.Raw、schema unknown=EXCLUDE，實打真 LC dev 回 200 且新欄位完整落庫。

驗收（全部實跑，非模擬簽章）:

1. 用 LC DEV 真私鑰簽的 manifest（kid 2ce3bb59a6f5a2ce）：改檔 → 拒啟起殼；curl / 與任意路徑得三欄 JSON、Accept: text/html 得 HTML 頁（三值渲染正確）、OPTIONS 得 204＋preflight 標頭 ✅

2. FS 標記存在（檔案已還原、只剩標記）重啟 → 同樣起殼，三欄取自標記 ✅

3. 完整解鎖循環：以真私鑰簽 unlock token → 放進標記目錄重啟 → 核銷成功、標記清除、殼不起、gate 往下跑完 manifest 比對、正常啟動（exit 0）✅

4. forensic 三落點：FS 標記含四欄 metadata；FS→DB 補同步後 psql 查得 detail 完整；D9 payload 先經 mock 端點原樣落檔確認擴充有送出，再以真 LC dev 打通（回 200，tamper_events.detail 查得新欄位）✅

5. 三種來源分級各自實跑：boot（log_tail 取回 50 行，最後一行與 tail -1 log/app.log 逐字相同）／scheduler（接真 DEV DB 得具名快照 Billows Admin＋IP＋時間；無 DB 時落 unavailable 不 raise）／hook（真 Flask request context＋真 UserContextDTO，得帳號與 XFF 首段 IP）✅

6. socketio 模式：RUN_MODE=socketio SOCKET_PORT=18102 → 殼綁 18102、api port 空著 ✅

7. 測試：新增 22（lockdown）＋18（forensic）條，integrity＋license＋manifest 共 295 綠。突變驗證：lockdown 六項（error_code／狀態碼／CORS 標頭／port 分流／內容協商／起不來回傳值）、forensic 六項（mtime 取值／owner 欄位／分級條件／XFF 首段／stat 容錯／上限）、log tail 四項（boot 不含 log_tail／不 seek 整檔讀／失敗回空清單／50 行上限失效）、wiring 三項（gate 不掛 forensic／runtime 不掛 metadata／gate 拒啟不起殼），逐一驗紅後還原。

8. ddd-compliance-reviewer 掃過本棒 diff：PASS，唯一 Warning 即上述 log tail 落差，已補（aeb2bd44）。其餘（套件 stdlib-only 約束、lazy import＋全域 except、無憑證誤入、INTEGRITY_503001 不走 common/code/ 是 D11 明文的合理例外）皆判合規。

測試資料已清除：DEV integrity_tamper_events、LC dev tamper_events 與臨時 api_token 皆已刪，count 回 0（已驗）。

教訓:

1. 「測試全綠」可能是環境巧合：首次跑 gate 測試 0.57s 全綠，實情是本機 BE 佔著 port 8000 讓殼起不來、退回 SystemExit——port 空著時整份 suite 會被 serve_forever() 卡死。凡是新引入「會阻塞的東西」，要先問「為什麼它沒卡住」而不是「綠了就好」。
2. 只攔不斷言＝白攔：把 enter_lockdown monkeypatch 掉之後，wiring 突變（整行拿掉起殼）測試照樣全綠。fixture 改成記錄呼叫參數並斷言「拒啟必起殼＋三欄傳對」才有牙齒。
3. load_dotenv() 相對呼叫檔解析（第 5 棒已記過，本棒又踩）：scratchpad 驗證腳本讀不到 repo 的 .env，engine 靜默用預設值連 localhost:5432，錯誤訊息指向 socket 而非設定。臨時腳本一律帶絕對路徑。
4. 合棒要先想 commit 邊界：兩張卡的改動落在同一批檔案，第一次 commit 時把 forensic 的 hunk 一起 add 進 T-8.1。未 push，reset --soft 後拆成「T-8.1 只含殼」「T-8.3 只含 forensic」兩支，各自單獨可編譯可測。合棒時應在動手前就規劃好切分點。
5. 派工單的簡述 ≠ 規格，要回 design 逐條對：派工單 T-8.3 寫 boot 分級「僅檔案 metadata（無 session 可查）」，照著做就漏了 design §4.4.2 表格明列的「＋app.log 尾段」。被 ddd-compliance-reviewer 抓到才補（aeb2bd44）。派工單是導引，design 才是驗收基準。
6. 突變測試也會寫出假的：驗「大檔只讀檔尾」時第一版斷言「最後 50 行對不對」——把 seek 整段拿掉照樣全綠（整檔讀進來再切最後 50 行結果一樣）。這條測的是記憶體行為，就得斷言實際讀進的 bytes 數。突變沒紅時要先懷疑斷言，不是慶幸。

推翻了什麼: 無。派工單裁定（殼只在 gate 拒啟路徑起、runtime 維持 exit）與 design §4.4 一致，未偏離。

留給下一棒:

• 本棒全在源碼模式（GUIDANT_INTEGRITY_FORCE=1＋臨時 dist）驗過，真 Nuitka dist 與真容器未跑——併入「真產物集中驗證」。
• BE↔︎FE 整鏈端到端未跑（真殼回 503 → 真瀏覽器打真 API → FE 跳鎖定頁）。T-8.1/T-8.2 兩端都已落地，條件成立。
• 殼在真部署承載下的邊界：容器 healthcheck／LB 打到殼會拿 503（預期，但未觀察 orchestrator 反應）；若正式環境有殘留 process 佔 port，殼起不來會退回 exit（不放行，但也沒有鎖定頁）。
• 零新增環境變數（PORT／SOCKET_PORT／RUN_MODE 皆既有），.env.sample／deployment-env.md 無須異動。

commits: BE e1190f86（locale）／4e64ca07（殼協商修）／2d56edb6（compose）／f929abe7（build_all）／4c06ddc8（scripts 盤點）＋docs 若干，皆已 push。LC/FE 無新 commit（第 2~5 棒的已入）。 Notion: CM-1231~1234 驗收完（修正待驗證）；新開 CM-1236（scripts 盤點✅）/1237（build_all✅）/1238（compose✅）/1239（解鎖 SOP，未派）。

做了什麼:

• 真產物集中驗證首通：188 真 dist smoke 七項＋gate 真驗章（1304 檔）＋改檔拒啟三段（改→拒／改回仍拒／清標記恢復）
• 抓到兩個出貨阻斷 bug 並修復驗證：①ASCII locale 下 gate 印中文炸 UnicodeEncodeError（e1190f86：stdout errors=replace＋image 釘 C.UTF-8）②殼內容協商 UA 嗅探讓 XHR 拿 HTML、FE 解不出 error_code 不跳鎖定頁（4e64ca07：只看 Accept）——後者是 user 真瀏覽器實測抓到的
• D11 拍板（lockdown 殼＋forensic 存證＋行為人不可知邊界）→ 四棒派出並親驗全過（詳第 2~5 棒 block）
• 部署定式化：docker-compose（含 pki volume 補洞——原 run 指令漏掛，rm 容器會洗掉鎖定標記）＋build_all.sh 一鍵管線；188 已用 compose 起正式容器（read_only 生效，root 也寫不進 /app）
• 188 實環境驗過：正式容器 gate 通過、D4 唯讀、locale C.UTF-8、pki 掛載；user 實測竄改→鎖定→FE（抓到殼 bug）→清標記復原
• LC 部署四步走完（188 STG：unlock 簽發＋tamper 接收，migration 至 head 49629d9e5d99）

決策:

• D11（lockdown 殼 B 方案）＋forensic 證據規格＋契約措辭建議（綁「完整性驗證失敗」不綁「查明行為人」）——design §2/§4.4 已落
• unlock 核銷通道＝FS token 檔（放標記同目錄），不走 HTTP（被鎖時服務起不來）
• 排程決策：T-8.1/8.3 等主鏈完成後合棒（同檔衝突）；T-8.2 FE 契約定死先行——實證有效
• 選 model 按任務認知形狀三軸（裁量/整合/錯誤隱蔽），不再一律最高階——已落 memory

教訓:

1. 內容協商不能看 UA——XHR 的 UA 恆為瀏覽器，零鑑別力；活體驗證只 curl 過 JSON 路徑沒模擬「瀏覽器 UA＋JSON Accept」組合，讓 bug 溜到 user 面前
2. compose 的 read_only 讓「容器內改檔測竄改」不可行——測竄改一律用拋棄式可寫容器＋隔離 pki 目錄（/tmp/pki-test），別打正式落點；user 誤打正式落點後標記殘留 /srv/guidant/pki，復原＝清標記＋compose 重起
3. push 是 user 專屬動作（Claude 無權限，能力問題非授權問題）——已落 memory
4. deployment run 指令漏掛 VOLUME 宣告的 pki——Dockerfile VOLUME 不等於部署有掛，匿名 volume 會讓鎖定被 docker rm 洗掉

推翻了什麼: 殼的 UA 嗅探分支（520fc5e3 引入、4e64ca07 廢除）；STATE 第 5 棒 Notion 盤點表過期列（5084eeea 更正）。

在途: user 正在 188 rebuild（HEAD 4e64ca07，碼正確）——build 完換容器後，「FE 鎖定頁真瀏覽器整鏈」即可複驗。

留給下一棒（收尾棒）:

1. 殼修正後的 FE 整鏈複驗（rebuild 完成後：臨時可寫容器佔 8000 → 改檔 → FE 應跳鎖定頁）
2. CM-1229 E2E 五條＋license 迴歸＋4h 抽查真承載（未實證清單見 STATE）
3. CM-1239 解鎖 SOP 文件（卡已開未派）
4. version-bump（含 FR-064 出貨前）＋母案收尾（等 user 令收 Done）

commits: 無程式碼異動（本棒是實測棒）；docs 本 block＋STATE 更新（帶 CM-1229）。 Notion: CM-1229 → 修正待驗證（A/B/E 成果成立，A-2 FAIL 如實在卡、A-4/C-1/24h 留複驗輪，卡不收 Done）；新開 CM-1241（BUG-1 修復棒，調查與證據已轉載）。

做了什麼（真 image 1.14.0／HEAD 4e64ca07，全程拋棄式可寫容器＋/tmp/pki-test 隔離落點，正式 compose 容器與 /srv/guidant/pki 未受影響）:

• 🔴 抓到 BUG-1（P0 出貨阻斷，本棒最大產出）：真產物×gunicorn 下 hook 觸發 tamper 後服務沒死透——FATAL 印了、FS/DB 落點都寫了、fingerprint/event_id 正確，但 master 存活並 respawn，服務照常回 200；同一竄改重現 3 次（3 event／3 FATAL）服務都活著，容器全程 healthy、RestartCount=0。根因定位 runtime_check._terminate_process()：容器內 PID1＝gunicorn master、worker 與 master 同 PGID=1（killpg 確實送達），但 master 本就 catch SIGTERM（/proc/1/status SigCgt=0x108314e07，bit15 已設）走自己的 shutdown handler，實測反而 respawn。交 CM-1241 修，本棒不修（驗的人不修）。
• A-1 改檔拒啟 PASS（改 manifest 內 .mo 一 byte → 拒啟＋列不符檔＋fingerprint/event_id；.integrity-tamper 5928B 含 T-8.3 forensic 三段：file_metadata／trigger_context.source=boot／log_tail）
• A-1b 殼協商修正（4e64ca07）BE 側複驗 PASS——瀏覽器 UA＋Accept: application/json 回 503 application/json 帶 INTEGRITY_503001＋三欄 data（正是修正前錯回 HTML 的組合）；Accept: text/html 回鎖定頁
• A-3 重啟被拒 PASS（restart 直接認標記不再逐檔比對；docker rm -f 重建容器→仍拒啟、同一 event_uid，FS 落點跨容器生命週期生效）
• A-5 縮短版 PASS（乾淨容器 gate 1304 檔通過＋多輪 API 操作零誤報；24h 保留未實證）
• B License 迴歸 PASS：三環境三把 kid（DEV 2ce3bb59／STG 04b1e65f／POC f3b562a6）真實已簽發照全部驗章通過（皆止於商務層 400006/409002），兩條負控（簽章改 1 byte／payload zlib 解壓改內容再壓回）皆 LICENSE_400002 → 證明不是「什麼都放行」。四張真照 payload 皆無 payload_type 鍵，走「缺鍵視為 license」路徑 → D2 抽層對已出貨 license 零破壞
• E orchestrator 觀察完成：鎖定殼被判 unhealthy（failing=4）但 Docker restart policy 只看 process 退出不看 health → 不進重啟迴圈，殼穩定停在鎖定態回 503（符合預期）

決策:

• BUG-1 開新卡 CM-1241 交修復 runner，驗的人不修、修的人另驗（首腦裁定）
• C-1（源碼模式縮短間隔×兩承載）併入 CM-1241 開工第一步——它回答「scheduler 路徑是否同病」，是決定修法範圍的關鍵輸入，不在本棒跑
• A-4 unlock 真循環延到 BUG-1 修完的複驗輪（unlock 的意義是「解除鎖定」，而 BUG-1 動搖的正是「鎖定是否成立」這個前提）
• B 的 license 素材從三環境 DB 唯讀 SELECT 取真照打 DEV 容器——比自簽假照更有迴歸價值，且不違反環境紀律（只讀）

教訓:

1. docstring 的終止假設沒被任何測試驗過——_terminate_process() 檔頭洋洋灑灑寫明「killpg 讓 master 與所有 worker 同組收到終止……只 os._exit 的話 worker 死了 master 會再 respawn」，把失敗模式都預想到了，卻沒有任何測試在真承載上驗證這個假設；既有測試 monkeypatch 掉 _terminate_process 只驗落點副作用，等於把最關鍵的一環整個跳過。寫得越詳盡的設計註解越容易讓人以為「已經想清楚＝已經成立」。
2. Nuitka 產物的埋點選檔會退化成只驗 binary——_HOTPATH_PRIORITY_PREFIXES（common/license/、common/integrity/、common/authz/）在真產物中不存在為獨立檔（全編進 binary），manifest grep 三個前綴皆零命中。埋點實際只驗 binary 一檔，與源碼模式行為差很大，設計時的「個位數檔案」預期在真產物是「1 檔」。
3. 運行中的 binary 用 printf >> 改不動（Text file busy），但 unlink+rename 可以（Linux 語意）——測真產物竄改要用「複製→改→mv 換掉」，否則會誤以為 binary 天然免疫。
4. 拋棄式容器沿用 guidant.env 會指向 STG DB（該庫無 integrity_tamper_events 表，符合環境紀律）——要驗 DB 落點必須 -e DB_NAME=guidant_ai_dev 覆寫；啟動 gate 本就不寫 DB，所以 A-1 不受影響，但 C-2 需要。
5. K8s 下 E 的結論會反過來：liveness probe 失敗會 kill+重啟 pod，鎖定態變 CrashLoop。compose 落地版目前不受影響，FR-065 若上 K8s 需把鎖定態排除在 liveness 之外。

推翻了什麼: 「運行中偵測→服務立即終止」在真產物 gunicorn 下不成立（design §4.6／D8 的承諾、_terminate_process docstring 的三種承載死法宣稱，至少 api+gunicorn 這條是錯的）；STATE 原「抽查真承載未驗」一項的隱含前提（以為只差時間窗，實為機制本身有洞）。

留給下一棒:

1. CM-1241 修 BUG-1（開工第一步跑 C-1 定範圍；修完需複驗 C-2 死透／C-1 兩承載／A-4 unlock 真循環）
2. CM-1239 解鎖 SOP 文件（卡已開未派）
3. version-bump＋母案 CM-1188 收尾（BUG-1 未修不得出貨）

commits: 7cc7989e fix(CM-1241) tamper 終止改依承載送訊號（common/integrity/runtime_check.py＋main.py＋test/test_integrity_runtime_check.py）。未 push（等 user）。 Notion: CM-1241 → 修正待驗證（含根因更正、修法、各承載證據、未實測假設）。

做了什麼:

• 先跑 C-1 定範圍（首腦指定工序），但改用容器化 harness 而非 188 源碼環境：真 gunicorn 26 pre-fork、PID1=master、呼叫真的 _terminate_process，比改 SPOT_CHECK_INTERVAL_SECONDS 等 60s 更快且不佔 188。C-1 結論：scheduler 路徑不同病——master 執行緒自己呼叫時 os._exit(1) 直接讓 PID 1 退出，容器 exit=1 死透（修前修後皆然）。
• 🔴 推翻卡上的根因假設（本棒最大產出）：卡與 docstring 都寫「killpg 送達了 master，但 master catch SIGTERM 走 graceful handler 沒死」。實測：master 根本沒收到訊號。 容器內 pgid=1，而 killpg(1,sig) ＝ kill(-1,sig) 是 POSIX 廣播特例，Linux 明文排除 PID 1。真 image 1.14.0 內 perl 探針（image 無 python）：killpg(-1,TERM) 送達對象數=0／kill(1,QUIT) 送達=1 handler 有跑／kill(1,KILL) 回傳 1 但 PID1 仍存活（核心忽略無 handler 的訊號）。
• 連帶推翻卡上的候選修法：「SIGTERM 改 SIGKILL（不可 catch 必死）」對 PID 1 無效，改下去會從「不死」變成「還是不死且更難查」。
• 修法：_terminate_process 改依承載分流——gunicorn worker 指名對 master 送 SIGQUIT（有 handler 故 PID1 收得到；quick shutdown 直接 halt 不回主迴圈故不 respawn）；容器 PID 1 與非 leader 不送訊號只 os._exit(1)；bare metal 僅在 pgid == pid（自己是 group leader）才 killpg，保住 shell 不被波及。master pid 由 main.py post_fork 呼叫 register_gunicorn_master(server.pid) 登記而非猜。送訊號決策抽 _termination_signals() 純函式以便測試。

驗證（真 image 根因實證 ✅／harness 行為實證 ✅／真 image 端到端 ⏳ 待 push）: | 項目 | 結果 | |---|---| | 真 image 1.14.0 三種送法可達性 | killpg=0 對象／kill(1,QUIT)=1 且 handler 跑／kill(1,KILL) PID1 存活 | | harness hook 路徑（修前） | 復現：worker 死、master respawn、ping 200 | | harness hook 路徑（修後） | master Handling signal: quit → Shutting down: Master → 容器 exited、ping 000 | | C-1 scheduler（修前／後） | 皆 exit=1 死透（非同病） | | C-1 Flask dev server 單 process | 死透 exit=1 | | bare metal | 子進程被 killpg 收掉、呼叫端 shell 存活（/proc 掃描確認） | | 負控（拿掉 post_fork 登記） | 舊病完整復現 ping 200 → 證明修正承重 | | 單元測試 | +6 支；三次突變（SIGQUIT→SIGTERM／移除 PID1 守門／移除 reparent 守門）各自翻紅、還原全綠 | | 迴歸 | integrity 全套 133 passed；乾淨容器多輪請求零誤殺 |

決策:

• C-1 改用容器 harness 而非 188 源碼環境＋縮短間隔：同樣回答「scheduler 是否同病」，但更貼近真相（真 PID1／真 pre-fork，源碼模式在 shell 下 pgid≠1 反而測不到本 bug 的關鍵條件），且不佔 188、不需臨時改寫死參數。
• 選 SIGQUIT 不選 SIGTERM：後者走 graceful 要多等 graceful_timeout；不選 SIGKILL：對 PID1 無效（實測）。
• master pid 用 post_fork 登記不用 getppid() 猜：猜錯時 bare metal 會把使用者 shell 當 master 殺掉。

教訓:

1. 「訊號送出去」≠「送到了」——os.killpg 不 raise 不代表有對象收到（本例回 ESRCH 或 0 對象）。診斷訊號問題要驗接收端有沒有收到，不能只看發送端 syscall 成功。上一棒讀 /proc/1/status 看到 SigCgt bit15 已設，正確地證明了「master 有 handler」，卻被誤讀成「master 收到了訊號並用 handler 處理」——有能力接收 ≠ 實際收到。
2. PID 1 在容器內是特殊公民：kill(-1) 廣播排除它、沒註冊 handler 的訊號（含 SIGKILL）核心直接忽略。任何「送訊號讓服務死」的設計，在容器內必須針對 PID 1 單獨驗證。
3. 承接上一棒教訓 1 的下一層：docstring 假設沒測會錯，而卡片上「已定位的根因」同樣是假說——本棒若照卡直接改 SIGKILL 就會交出一個看似合理、實則無效的修正。派工卡的根因段要當待驗假說讀（[[feedback_upstream_hint_is_hypothesis_not_conclusion]]）。
4. 真 image 無 python，但有 perl——要在出貨產物內做系統層探針時 perl 是可用的後路。

推翻了什麼: CM-1229／CM-1241 卡上的根因（「master 收到 SIGTERM 但走 graceful handler 沒死」）與候選修法（SIGKILL）；_terminate_process 原 docstring 三種承載死法的整段敘述（已改寫並保留錯誤假設的說明，避免後人重蹈）。C-1 待答項銷案：scheduler 路徑不同病。

留給下一棒:

1. 真 image 端到端複驗（唯一未完項）：需 user push 7cc7989e → 188 pull → rebuild image → 重現 CM-1229 C-2 步驟（unlink+rename 換 binary → 打 /api/1.0/license/upload）→ 應服務死透（master+worker 全滅、容器 exit、不 respawn）→ restart 被 gate 攔、殼回 503
2. A-4 unlock 真循環（BUG-1 修完前提已恢復，可接著跑）
3. CM-1239 解鎖 SOP 文件；version-bump＋母案 CM-1188 收尾

commits: 19a086af fix(CM-1242) 掛載宿主 /etc/machine-id（docker/production/docker-compose.yml＋deployment-env.md）。未 push（等 user）。 Notion: CM-1242 → 修正待驗證（含修法／綁機回歸評估／V1–V5 證據／未實測假設 6 條）。

做了什麼:

• 修法選項 A 落地，code 零改動：compose x-guidant-common volumes 加 - /etc/machine-id:/etc/machine-id:ro（anchor 共用，api+socketio 兩 service 同時生效）。先驗掛載是否足夠再決定要不要動 code——足夠，故 machine_fingerprint.py 一行未改（三級 fallback 邏輯本身沒錯，錯的是部署沒把宿主 machine-id 帶進容器）。
• deployment-env.md 同步：三處 docker run fallback 各補一行、§4 掛載表六→七列、新增「宿主必須有 machine-id」前置檢查段（含 test -s 檢查與「machine-id 重生成會讓既有綁機憑證全失效」警語）。
• 既有 license 綁機回歸評估（唯讀 SELECT，未改資料）：DEV 25 列中 16 列綁舊指紋（4a837148…×15＝舊測試容器 MAC、f2ef9354…×1＝開發者本機 MAC 推導值，已用 sha256("mac:"+getnode()) 比對確認），但全部 is_current=false；三張現行照皆未綁機。STG 3 列／POC 1 列皆 null。結論：無回歸，不需資料遷移（真要處理也該是向 LC 重簽，改 DB 會讓照內簽章與 DB 值不一致）。

驗證（188 拋棄式容器；🔴 正式容器與 /srv/guidant/pki 全程未碰）: | 項目 | 結果 | |---|---| | V1 跨 docker restart | MAC e2:5c:9a…→換，指紋 ff793254…a3da080 不變 | | V2 跨 docker rm+重 run | MAC a2:83:dc:f7:ba:78（全新），指紋 仍相同 | | 錨點驗證 | sha256(宿主 machine-id d478e208…) ＝ ff793254… ✅ | | 負控（不掛載） | restart 前後 67c6dd9d…→63572f6d…，bug 完整復現（證明修正承重） | | V3-① 觸發 | unlink+rename 換 binary→打 /license/upload→服務死透（Handling signal: quit→Shutting down: Master、容器 Exited、ping 000）← 順帶端到端證實 CM-1241 BUG-1 修正在真 image 1.14.0 上成立（第 9 棒留的唯一未完項銷案） | | V3-② 鎖定態 | restart→gate 攔、lockdown 殼 503、訊息含 fingerprint+event_id | | V3-③ 負面案 4 條 | 他機／過期／錯事件編號／重放 全擋，四種訊息各異 | | V3-④ 正解鎖 | 核銷成功、標記清、nonce 入帳、token 用完即刪、ping 200；receipt→scheduler→DB 回填鏈完整（DB 實查 unlocked_at 非空、unlock_nonce=fe6e3cbc40d1…） | | V4 迴歸 | 乾淨容器 healthy 無誤鎖；integrity+license 指紋測試 131 passed | | V5 socketio 死透 | PID 1／eventlet／APScheduler 條件下 _termination_signals() 回 []、走 os._exit(1)、容器 Exited(1)、ping 000 |

決策:

• 能不改 code 就不改：先實測「掛載是否足夠」再決定，結果足夠。改 machine_fingerprint.py 的空檔 fallback 屬另一議題（建議做成「打包模式落到第三級時警示」而非拒啟——拒啟會讓沒有 machine-id 的極簡宿主完全裝不起來），不在本卡範圍。
• 過期 token 用 LC 私鑰直簽而非 CLI：CLI --valid-hours 有 1–336 下限（本身是正確的防呆），改用 sign_payload 直接造「真簽章但 expires_at 在過去」的 token——這樣驗到的是核銷的效期關，不是「簽發端擋住了」，兩者是不同的東西。
• V5 用 harness 而非真 image：socketio 模式不載 REST blueprint（main.py 設計），8002 上沒有埋點端點；抽查 4h 週期且參數寫死（D8 刻意不開放 env）。故重現承載條件（容器 PID 1＋monkey_patch(all=False, socket=True)＋socketio.run＋BackgroundScheduler）但執行 mount 進來的真源碼（PYTHONPATH=/src→/opt/guidant_ai），非複製品。承接第 9 棒同一手法。

教訓:

1. 「容器內有這個檔」不等於「這個檔有內容」——/etc/machine-id 在 Debian base image 是 0 bytes 佔位檔，os.path.exists() 為真、open().read().strip() 為空。三級 fallback 的 if value: 寫得完全正確，卻因為第一級「存在但空」而靜默降級到最不穩的第三級。檢查「來源可用性」時，存在性與有效性要分開驗。
2. 設計註解寫對了假設，不代表部署實現了它——machine_fingerprint.py docstring 白紙黑字寫「正式 Host 版部署預期跑在有 /etc/machine-id 的 Linux 容器宿主上」，這句話是對的（宿主確實有），但沒有人把宿主的檔帶進容器。這與第 8 棒教訓 1（docstring 假設沒被測過）同源：假設寫得越清楚越容易讓人以為它已成立。
3. 掛「檔」的陷阱：-v /etc/machine-id:/etc/machine-id:ro 在宿主缺檔時 docker 會建成目錄，容器讀檔失敗→靜默退回 MAC→症狀與完全沒掛一模一樣。凡是掛單一檔案的 bind mount，文件都要附「宿主須先存在」的前置檢查。
4. 綁機類欄位查回歸要看 is_current——tenant_licenses 是 replace 制，歷史列會累積一堆舊指紋，只看「有幾列綁了指紋」會嚇死自己（16 列！），實際受影響的只有現行列（0 列）。
5. 驗負面案要驗到「該關」而不是「任何一關」——過期案若用 CLI 的 --valid-hours -1，擋下來的是簽發端參數防呆，核銷的效期關根本沒被執行到。負面案要確保失敗發生在你想驗的那一關。

推翻了什麼: 無推翻（卡上根因與修法選項 A 皆經實測成立，是少見的「卡寫對了」）。銷案兩項：第 9 棒留的「真 image 端到端複驗」（V3-① 順帶完成）、STATE 未實證清單第 1 項的 ③A-4 unlock 真循環＋socketio 承載。

留給下一棒:

1. 正式／STG／POC 套用 machine-id 掛載（需 docker compose up -d recreate 兩容器）——等決策者放行，本棒只改 repo 檔
2. STATE 未實證清單餘項：scheduler×真 binary×4h 真窗、≥24h 長跑（A-5 完整版）、K8s liveness 下殼會 CrashLoop（FR-065 議題）
3. socketio 真 image 完整竄改→死透鏈（低風險，比對邏輯與 api 共用同一份 runtime_check，但未實跑）
4. CM-1239／CM-1240 等 user 收 Done；version-bump＋母案 CM-1188 收尾（BUG-1／BUG-2 皆已修，出貨阻斷解除）

commits: BE 29fead0(FE CM-1240 details 開關，FE repo)／19a086af(BUG-2 fix)／7cc7989e(BUG-1 fix)＋docs 若干，皆已 push 三 repo 與 origin 同步。

做了什麼:

• 接手驗收：FE 鎖定頁真瀏覽器截圖複驗（user 親見）；CM-1240 開卡→FE 指紋/時間預設隱藏（?details=1 才顯示，離線 unlock 鏈不斷）親驗收 Done
• 派 CM-1229 實機驗收棒 → A/B/E＋A-1/A-3/A-5 縮短版全過、B license 三環境三 kid 迴歸過，抓到 BUG-1 P0（hook 觸發不死透）
• CM-1229 卡名消歧（「E2E」→「實機驗收測試（人工實測非自動化碼）」）＋補白話段（user 反映看不懂術語）
• 派 CM-1241 修 BUG-1 → runner 更正根因（非「master 收訊號不理」而是 killpg 打不到 PID 1）→ 首腦親驗實碼＋自跑 integrity 157 passed
• CM-1241 複驗輪本體親跑：真 image C-2 死透（log 見 master 收 SIGQUIT→Shutting down 不 respawn）＋接力鏈（restart→gate 攔→殼 503）；跑 A-4 unlock 時抓到 BUG-2 P0（指紋 restart 就變）
• 開 CM-1242（卡內含完整執行指令，派工只給卡號）→ runner 修（compose 掛宿主 machine-id，code 不動）→ 首腦親驗：親算 sha256(宿主 machine-id) 對上容器指紋、親查 config.tenant_licenses 綁機無回歸、188 host 模式容器 restart 前後指紋不變
• user 重啟 188 → 首腦驗正式部署：HEAD 66f6dea8、image 含兩 P0、掛 machine-id、gate 1304 檔、指紋穩定
• 收尾：34 卡全 Done、SUMMARY、兩條 P0 memory、STATE/LOG 收尾標頭、母案回寫

決策:

• 派工模式改「工作內容全寫進 Notion 卡、派工只給卡號」（user 明示不要重複貼長 prompt）
• 卡名寫「做什麼」不寫代號、術語表前放白話段（user 反映看不懂）
• 不進版（現標 1.14.0）——FR-064 後面還有 FR-065，里程碑確定才進版
• CM-1242 把 A-4 unlock＋socketio 死透併入（指紋修好才跑得完 unlock）

教訓:

1. killpg 打不到容器 PID 1（POSIX 廣播特例排除 init）——已落 [[feedback_killpg_cannot_signal_container_pid1]]
2. 容器 /etc/machine-id 空檔→指紋退回隨機 MAC 每次重啟就變——已落 [[feedback_container_machine_id_empty_fallback_mac_drifts]]
3. 「實機驗收/end-to-end」與「自動化 E2E 測試碼」是兩回事，卡名用縮寫會誤導 PM——收尾把 CM-1229 改名並補白話
4. 首腦親跑複驗（非全外包）在本棒兩度直接抓到 P0——C-2/A-4 是首腦本體跑的，BUG-2 就是這樣現形；驗收「親驗不信自報」延伸到「關鍵鏈自己走一遍」

推翻了什麼: BUG-1 原卡假設「master 收 SIGTERM 走 graceful 沒死」（實為根本沒收到）；_terminate_process 原 docstring 的 killpg 宣稱（已改寫）；「docker restart 不換 fingerprint」的 SOP 前提（僅宿主有穩定 machine-id 時成立，容器需掛載）。

留給下一棒: FR-064 已收口。續戰線＝FR-065 installer（FE image/compose）；出貨前待辦見 SUMMARY §10（進版／推 Harbor／正式 PUBLIC_KEYS 鑰／K8s liveness 排除鎖定態）。