FR-065 落地版 Installer — LOG（append-only，每棒追加一 block，寫完永不改）

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

commits: BE 320599c1（design.md 落地，D1–D13 定案）／fbb20544（追加 T-2.0 DEV 清理＋D13 收斂）／c16f497c（design 補分工概述節＋docs-conventions 立「先概述後詳細」規範）／95acbf2c＋0668e260（big-feature-workflow skill 補兩規則）。皆未 push（branch 無 upstream）。 Notion: 母案 CM-1189 In progress；子需求 CM-1243~1246；子任務 .1＝CM-1247~1251、.2＝CM-1266+CM-1252~1257、.3＝CM-1258~1262、.4＝CM-1263~1265；戰線外 follow-up CM-1267（root admin 密碼永不過期）。26 卡一次建齊。 做了什麼:

• 走 big-feature-workflow 全程：4 支 Explore 平行探脈（build／部署資產、FE 注入機制、license 雞生蛋、升級／e2e-env）→討論稿 D1–D13→user 逐項拍板→design.md 落地→26 卡建立。
• 討論稿／design／db-init-inventory 皆產 HTML（doc-site-build）。

決策（含被排除的）:

• D1 外接 DB：決定「compose 註解自改」。理由：客戶場景單純；被排除的：首腦原建議 --external-db 參數，user 裁定過度工程、簡化。
• D10 安裝介面：兩度拍板。第一輪定純 bash（排除 TUI——維護成本高、終端相容性風險）；後 user 問市面產品模式，補採 Web 設定精靈（setup token 防搶注）成混合式——bash 起環境、瀏覽器做設定。
• root admin 密碼永不過期：原擬入 .2（T-2.7），user 裁定移出戰線改 CM-1267 follow-up（FR-065 完成後另案）。理由：非安裝主線、避免 scope creep。
• D11.9 debug view：從「不出貨」升級為「連 DEV 都刪」。

教訓／新規則: user 兩條反饋固化進 skill＋docs-conventions＋memory——①設計文件先概述後詳細；②開卡夠白話（卡名寫做什麼、內文首段白話）。

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

留給下一棒: 派 .1 地基棒。派工單原文：

執行 FR-065.1 地基棒：CM-1247 → CM-1248 → CM-1249 → CM-1250 → CM-1251 依序做，
內容都在卡裡。母案 CM-1189、子需求卡 CM-1243。
BE repo branch feature/FR-065 不切；FE repo 會動到（T-1.3）。
完成每張卡回寫「修正待驗證」＋白話已完成修正段＋commit hash。
全部做完停下等驗收，不自動往 .2 或收尾跑。

commits: BE d526c12a(T-1.1)／8c503ae5(T-1.3 BE 側)／3644d794(T-1.4)／ceffeae0(T-1.5)；FE bb174b6(T-1.2)／33bd78c(T-1.3 FE 側)。皆未 push（BE 領先 6 含前棒 docs 兩筆、FE 領先 2）。 Notion: CM-1247~1251 全數「修正待驗證」＋白話已完成修正段；CM-1243 維持 In progress 待子卡驗收。

做了什麼:

• compose 從 BE 兩服務擴充為 full-stack（+DB +Redis +MinIO 選配），BE 改 expose、加 depends_on healthcheck 鏈。
• FE 側產出 nginx.onprem.conf（落地版反代）＋.env.onprem 新 build mode；BE 側產出 build_fe_image.sh 把 FE image 併進 build 管線。
• .env.example 範本落地，.gitignore 開白名單例外。
• 端到端實跑：自 188 docker save 取 BE image（唯讀、未動 188），配自 build 的 FE image 與 DEV pg_dump restore 的暫行 DB，本機起完整五服務——全 healthy、經 HTTPS 反代登入成功、讀 tenant-scoped 資料正確。測試環境事後全清。

決策（含被排除的）:

• T-1.1 recreate 風險：卡片原傾向「DB/Redis 獨立成另一個 compose project」。選了同 project——因為 depends_on: service_healthy 跨 project 無法表達，而那正是「up 完即可用」的前提。代價（裸打 up -d 會 recreate DB）改以三層防護吸收：檔頭警語＋installer 一律帶 service 名＋資料在 named volume（最壞是中斷不是消失）。被排除的獨立 project 方案代價更高：失去啟動順序保證。
• T-1.3 兩個 build-time 參數：不改 .env.production，另立 build:ONPREM mode。理由：.env.production 服務既有 AWS/ECS 管線，且 site-regression 測案依賴 VITE_DEV_MODE=true 才看得到的元素（.env.e2e 檔內已明文記載此相依），改 false 會讓既有測案全紅。被排除的「直接改 PRD」會同時汙染兩條既有戰線。
• T-1.3 Turnstile：維持測試 key 但顯式寫出（原本留空是隱式 fallback）。刻意不在本卡做停用——那是 BE/FE 一對的開關，屬 T-3.5，越界會做出半套。
• T-1.4 選配形式：用 compose profiles: 而非「註解掉整段」。註解掉會逼客戶手改 YAML（易改壞，且升級換新 compose 檔時客戶改動被覆蓋）；profile 讓啟用與否變成啟動參數。

教訓／實測推翻的既有記載（詳見 STATE §8，此處只記結論）:

• ENABLE_MULTI_TENANT 漏設的症狀與文件寫的不同：文件說「查無資料且無錯誤訊息」，實測是登入仍成功但租戶端點回 LICENSE_403001 此模組未在授權範圍內——訊息指向錯誤方向（看起來像 license 壞了）。範本已照實測改寫。
• DB_PORT 不填不會連錯埠：config.py:37 現行預設就是 5432，e2e-env 註解記載的「硬編 25432」已過時。範本從「事實宣稱」降級為「建議」。
• 空庫 grant cm_app 是硬前置：restore 後 BE crash loop exit 139（SIGSEGV，第一直覺會誤判成 Nuitka 產物或跨架構模擬問題），根因是 cm_app 零權限。這是 T-2.1「權限掃描零缺口」驗收條件的實證。
• 方法上：兩條「照文件抄」的敘述都是實跑才發現不成立——範本／手冊類產出只要有辦法實跑，就不要只靠既有文件轉抄。

推翻了什麼: 推翻 e2e-env 註解與 deployment-env.md 對 ENABLE_MULTI_TENANT 漏設症狀、DB_PORT 預設值兩處記載（上述）。未推翻任何設計決策。

與平行 session 的交會: 工作期間另一 session commit 5f215b41（D2 補裁 HTTPS 憑證由 install.sh 產 per-install 自簽）。已對照——本棒 T-1.2 做的是「掛載路徑約定＋80→443 轉址」、產憑證留給 T-2.5，與新裁決一致，未返工。

留給下一棒: user 驗收 .1 五卡 → 收 CM-1243 → push（BE 6／FE 2）。之後 .2 派工前先讀 STATE §8（T-2.1 與 T-2.5 都有本棒的實證輸入）。.2 開工仍卡在 user 功課：D11.2 清單核對＋D11.5 labels＋CMMC 初始化資料。

commits: 本棒 docs/追補類：f58def0a／5f215b41（D2 憑證補裁）／17dc4964（D11.1 改版＋D11.5＋D13 收案）／87b1225c＋79c7638c（D11.2 兩階段定案）／gitignore 877d79e1／T-2.2 追補（清舊產品線殘影＋seed 重產）／STATE 更新×4。runner commits 見各卡。皆未 push（BE 領先 26、FE 領先 2）。 Notion: .1（CM-1243＋1247~1251）與 .2（CM-1244＋1266/1252~1257）全 Done。

做了什麼:

• 接手盤點→派 .1→驗收抓到 guidant-fe service 缺漏（返工補齊）→user 本機複驗→收口。
• 本機 compose 全鏈實測協助（.env/guidant.env 分工、自簽憑證、DEV dump restore、cm_app grant 補權限）。
• 派 .2 前半棒→驗收（親跑 init.sh 空機全程）→user 匯 CMMC L1/L2 進基線庫→放行後半棒→總驗收（抽刀：基線未汙染/labels 動態產生/digest 時序/PROD 守門/停點紀律）→追補清舊產品線殘影→全棒收口。

決策（含被排除的）:

• D2 補裁：HTTPS 憑證＝install.sh 產 per-install 自簽（動機：精靈複製鈕 Clipboard API 需 secure context）。排除：bundle 帶共用憑證（＝所有客戶同一把私鑰）；只跑 80（複製鈕失效）。
• T-2.0 改道：DEV 不動，clone 進 188 空庫 guidant_ai 清理（user 裁定，優於原案：可重來＋DB 名即 D11.10 新制）。
• D11.1 改版：CMMC 框架由原廠（user 本人）在基線庫走正規 PDF 匯入，bundle 不帶檔。排除原「客戶自匯 OSCAL JSON」案。
• D11.2 全定案：flow_templates 只帶 id 1＋3（兩筆 inactive 內建砍）；workflow_templates 清空不 seed——經追碼證實 AO 範本是「建資源庫」時自動產生的衍生資料（初判「匯入時產生」有誤，實測修正）。
• D11.5 定案：labels FUNCTION 群以 ui_routes enable=1 動態重建（SELECT 產生非硬編），舊產品線殘留不帶。
• D11.9 修正又復原：一度確認「DEV 保留 debug view」，user 釐清後改判連 DEV 都刪（首腦手動 drop，與原文一致）。
• D13 殘項收案：v1 不做 root 介面硬擋，先出一版再調。
• 追補：基線清 ui_routes 舊產品線 7 列＋cruise-project capabilities 7 筆（含 FK 連帶），seed 重產。

教訓:

• .1 抓到「驗完但沒收尾」實例：runner 端到端用臨時 override 起 FE，版控 compose 卻沒有 guidant-fe service——驗收必查「版控檔能否獨立重現驗證結果」。
• 憑證掛檔缺失時 docker 建成目錄、nginx 報格式錯誤（誤導向），與 machine-id 同類陷阱（已入 compose/env 註解）。
• 首腦對機制的初判（AO 範本產生時機）被實測推翻——回寫卡片時區分「已驗證」與「推測」的紀律再次證明必要。

推翻了什麼: LOG Block 2 之後的裁決推翻了卡片原文多處（T-2.0 執行方式、D11.1/D11.2/D11.5 原案、D11.9 卡內第一段確認）——各卡以卡內最新裁決段為準。

留給下一棒: 派 .3（CM-1258~1262，D13 已收不卡）。三件出貨動作（PROD 鑰四步／進版／推 Harbor）機制就緒待 user 裁時機。push 待 user（BE 26／FE 2）。T-4.1 手冊素材：install.sh README／bundle 佔位 docs／T-3.5 外連盤點。

commits: BE eb039851+60835a71(T-3.1)／ca72122c+FE fe99bc0(T-3.2)／e0a8f423(T-3.3)／ad6ddc3b(T-3.4)／3f17ff1b+FE 85c8bf2(T-3.5)／43630553+fe80adeb+1b06556b(CM-1270)／8038abb0(CM-1271)／FE b90f4aa(CM-1272)／8c2ca7e5(design 同步+HTML)。BE 領先 2、FE 領先 1 未 push（user 中途 push 過一批）。 Notion: .3 五卡＋修補三卡皆「修正待驗證」（親驗通過，等 user 總測收）；新開 CM-1270/1271/1272；CM-1268 掛 SeaweedFS 連動登記；母卡 CM-1189 掛「出貨前決策清單」。

做了什麼:

• .3 驗收（親跑 setup 測試 34 綠、抽刀 Turnstile 成對/migrate 守門/fingerprint）。
• 188 真機首測全鏈走通（user 親測、首腦隨行排障）：build→bundle→install→精靈→LC 簽照（issue→activate）→匯照開通。排障途中：FE repo deploy key、STG 舊容器清場、venv 舊路徑重建、pull postgres/redis。
• 首測撞出三張追補卡並全數完成：CM-1270（sudo 化/既有安裝偵測//srv/guidant-ai/維運子命令）、CM-1271（credentials/rotate/自帶密碼）、CM-1272（開通後自動刷選單 3→28）。
• build_all 加 --all/--skip-be；build_fe_image 尋徑補 /opt/guidant-ai-fe；BE 部署路徑標準名改 /opt/guidant-ai-be。
• design.md 同步（23 卡/188 首測/§7 決策清單）＋HTML 重建（subagent）。

決策（含被排除的）:

• license 匯入時機：定案「裝完後 Web、登入後走既有 FR-062 開通頁」；runner 提的「不在精靈內等簽發往返」偏離獲 user 確認（排除：精靈內匯入＝要求客戶掛頁等隔天回覆）。
• D11.9 二轉：一度確認 DEV 保留 debug view→user 釐清後改判連 DEV 都刪（首腦手動 drop，與原文一致）。
• 憑證管理三分法：預設自產不問（排除讓客戶發明密碼）＋credentials 匯出供集中控管＋rotate 輪換；JWT/加密鑰刻意不輪換（換＝全員登出/密文永久解不開）。
• 明文 .env 存密碼：user 質疑資安後裁定維持（GitLab/Nextcloud 同型業界標準＋root 即遊戲結束威脅模型），防線改投 rotate/備份保管紀律/手冊說明。
• 出貨前決策凍結區：AI 功能開放、Drive OAuth 路線、SeaweedFS 換裝——收攏至母卡＋design §7，帶公司議，不在工程線展開。

教訓:

• 環境檢查「驗了空間沒驗可寫」＝一次列齊精神的漏洞；venv 不可搬移（目錄改名必重建）；compose down 也要 --env-file；postgres image 的 POSTGRES_USER 天生 superuser（降規設計只在受管 DB 場景生效）。
• CM-1271 六 bug 中「新版 bash 綠/舊版壞」再證突變測試紀律；「密碼含 $/引號開頭/前後空白」被 compose 靜默弄壞的一類坑選擇擋下而非代改。

推翻了什麼: 卡片原文多處被實測推翻——T-3.2 精靈內匯照、CM-1270 的 guidant.env chown 給容器 uid（實測檔根本沒掛進容器，chown 反降安全）、D11.9 第一段確認。各卡以卡內最新段為準。

留給下一棒: ①user push→188 重打 bundle（--all --skip-be）；②user 第二輪全鏈總測（新驗點見 STATE §3）；③收 .3+修補+CM-1245；④.4 三卡＋§7 決策清單。殘項：shellcheck、SeaweedFS 三裁（CM-1268）、AI/Drive 公司議。

commits: 無新 code commit（本段為收口）。BE/FE 已由 user push 同步。 Notion: .3 五卡＋CM-1245＋修補三卡（CM-1270/1271/1272）全收 Done——計 20/23 卡完成，剩 .4 三卡。

做了什麼: CM-1271 親驗通過（三件＋6 bug 自抓＋突變測試抓到 bash 版本差異假綠）；188 第二輪總測起跑前排障：uninstall 對「修補前版本裝的存量」無安裝紀錄→訊息給對出路（已記 CM-1270 註記）；確認指紋不因重裝而變（license 可復用）。

決策: docker 缺席行為維持「擋下不代裝」（GitLab 同型），T-4.1 手冊補各發行版與 air-gap 安裝指引——記素材清單不開卡。

留給下一棒（下個首腦）: ⓪CM-1270 二輪實測退回「修正待驗證」——「舊庫無設定檔」訊息的 (B) 清理指令兩處壞＋compose up 偶發掛住需防護（修點在卡尾 2026-08-18 段），總測完開回 runner 修；①等 user 二輪總測結果；②.4 派工——T-4.3 無前置可先派，T-4.1 卡 design §7 四題公司決策（AI/Drive OAuth/SeaweedFS/三件出貨動作），T-4.2 最後；③殘項 shellcheck。⚠️ .4 是本 FR 最後一棒，收完走 closing-and-handoff 全案收尾（SUMMARY 由本 LOG 各 block 濃縮、母卡 CM-1189 收 Done、spec/手冊盤點）。

第 5 棒補記（2026-08-18 上午續）：二輪總測連撞三事——①compose up -d 偶發掛住（容器實已 healthy，CLI 不返回）；②「舊庫無設定檔」訊息 (B) 指令自身不可用（兩處）；③「一樣不行」實為既有安裝偵測正確擋下 /srv/guidant-ai-test 殘留（非 bug，uninstall 手動後半未清目錄）。①②收進 CM-1270 回修（卡已退「修正待驗證」），user 裁定總測完一起派。回修派工 prompt：

回修 FR-065 卡 CM-1270（T-2.5b）：188 二輪實測撞出兩件待修，
詳見卡尾 2026-08-18 兩段（python3 scripts/notion_case.py get CM-1270 讀取）——
①「偵測到舊庫但設定檔不存在」訊息的 (B) 清理指令不可用（裸 compose down
缺 --env-file 自身會失敗＋volume in use 未教先移容器），改為直接拆容器的指令；
②install.sh 的 compose up -d 呼叫加掛住防護：up 後輪詢容器 health 判成功，
不倚賴 CLI 返回（188 docker 29.2.1/compose 5.1.0 實測掛住一次）。
母案 CM-1189、子需求卡 CM-1244。BE repo branch feature/FR-065 不切。
🔴 環境紀律：本機容器測試；DEV/基線庫/STG/POC 不碰。
完成回寫補充段＋commit hash，狀態維持「修正待驗證」，停下等驗收。

commits（BE，本棒協調期間累計）: 1334c949/e0bed9ce（docs 回修登記）→ runner 35ab5ceb(CM-1270 三件)→ c28a9d63/1fe2e060（D14＋拆分表＋派棒註）→ .5 棒 41f5a714(1280)/eeed4b68(1276)/50f7a79d+b8538b3f(1277)/af9fcbf8(1278)/fe61a323（pin 0.0.22）→ 6804639e（排程重整）→ 7b4d4872/e937d93d（框架 PDF 入庫＋L3 移除）。jedi repo：1694812/57fc797（jedi-file-upload 0.0.22 發版）。 Notion: CM-1270 追加③後回修完成（修正待驗證，待 188 真機複驗）；新開 CM-1275~1279（.5 卡樹＋遷移 follow-up）；CM-1280 併 .5 棒；.5 四卡皆修正待驗證；CM-1189/1268/1269 排程與方案回寫。

做了什麼:

• CM-1270 追加第③件（資源門檻改警告）→ runner 回修三件收工，親驗通過（dc_up/check_warn/(B) 指令實檔抽查＋突變驗證紀錄），留 188 真機複驗。
• D14 SeaweedFS 替換定案（五點：出廠即啟用/B 案正式 type/bundle 帶 image/框架 PDF 隨包/MinIO 段移除）→ 開 FR-065.5 卡樹（CM-1275~1278）＋遷移工具 follow-up（CM-1279）→ .5 棒一棒四卡（含 CM-1280 log rotation 併棒）收工，親驗通過。jedi-file-upload 發版 0.0.22（決策者於 runner session 指示）、pin 已還原。
• user 糾正排程漏盤：.4 前置不只 design §5——重盤出 CM-1235（PyMuPDF AGPL，出貨合規硬前置）/CM-1273（install log 落檔）/CM-1269（系統檔修復）。T-4.3 Windows 裁示本次跳過；CM-1274/1279 維持全案後另排。
• CM-1269 事實反轉：基線庫 CMMC 匯入早已完成、資料列在，PDF 實體失於 /tmp fallback → 就地修復不重匯；原始 PDF 由決策者提供入 repo scripts/init/framework-pdfs/（L1/L2，MD5 與資料列 checksum 全驗相符）；L3 確認匯入失敗殘留（framework_versions 僅 L1/L2）→ 修復棒一併 DELETE。
• 派出兩棒（user 已派）：棒 A＝CM-1235 PyMuPDF 替換；棒 B＝CM-1273＋CM-1269（基線庫 188 guidant_ai 修復寫入已獲授權）。

決策（含被排除的）:

• CM-1270 資源門檻「軟擋＋逃生門」→「純警告」；SKIP 開關隨之移除（無物可繞）。
• D14 五點（被排除：沿用 MinIO＝閉源化；A 案零改碼＝長期語意債；維持選配＝遷移支線複雜）。
• CM-1280 併 .5 棒排最前（同動 compose 檔避免兩棒互踩）。
• 儲存切換防線分層：v1 手冊警語（storage-backend-warning.md，system-scope 當場斷為重點）＋遷移工具 CM-1279 後排。

教訓:

• 排程盤點不能只盯 design §5 拆分表——散卡（合規/維運/落點類）掛在 Notion 母案戰線外圍，重盤要掃 Notion 全清單。本棒被 user 抓到漏 CM-1235/1269/1273。
• system-scope 檔讀取走「當下 root STORAGE_CONFIG」不看檔案自記 type——客戶切 storage 系統檔當場斷，與 customer-scope 行為不同（警語排序理由已記 storage-backend-warning.md）。
• SeaweedFS -volume.max 是 per-bucket collection 配額非全域池；容量不足回 S3 InvalidRequest 看不出真因（.5 棒實測，已入 SOP）。

推翻了什麼: CM-1269 卡原文「出貨方式待決」四題全由 D14 收掉；SOP「重新匯入」路線被「就地修復」取代（匯入早已完成）；本棒 LOG 第一版 block（CM-1270 三件 prompt）已被執行消化，重寫為本版。

留給下一棒:（本段由棒 A/B 收工後更新）見下方補記。

第 6 棒補記（2026-08-18 下午～晚，棒 A/B 收工＋§7 收口＋188 第三輪起跑）:

• §7 第 1/2 題定案（design c5721d1c）：AI 維持開放（token 絕不進 bundle、裝機後配置；Key 維護/token 限制後續不入本次）；Drive OAuth 沿用 Demo 憑證出貨、正式申請後替換。§7 僅剩「三件出貨動作」＝工程執行項。T-4.1 決策閘全清。
• 棒 A（CM-1235）收工親驗過：a16fc126（pdf_backend.py shim 336 行、三 util 只改 import、fitz 歸零）＋7907e0b4（pin jedi-project 0.0.8，lock 內 pymupdf 歸零）；jedi repo e24d207（0.0.8 發版，user 明示）。回歸 diff 四解析器過（少 2 筆為 fitz 誤判、新版更正確）；CMMC 線上 parser 本走 pdfplumber 不受影響；效能 65s 屬 pdfplumber 引擎地板非 bug（離線腳本可接受，已記卡）。
• 棒 B（CM-1273＋1269）收工親驗過：146c1d2c install log 落檔（五驗收全過＋卡外自抓兩件：setup token 不落檔、stdout/stderr FIFO 合流防交錯）；4db149c9 基線庫修復——L1/L2 兩筆改 seaweedfs、L3 孤兒 DELETE（1289 文字欄位全掃零引用）、STORAGE_CONFIG 補 D14 出廠值（user 當場授權）、真實 pdf-preview 端點 200＋MD5 符、修復 SQL 落 scripts/sql/ 含交易內筆數驗證。首腦直查 188 基線庫複核三項皆符。
• 決策：棒 A 效能問題裁「修掉再收」（後查明為引擎地板，接受）；棒 B STORAGE_CONFIG 落差裁「隨卡一併補」（D14 既定值補套非新決策，驗完還原出廠 endpoint）；CM-1204（手冊下載端點死碼）裁「不進前置、T-4.1 收尾時裁要不要活化」；agent 安裝包裁定另起新 FR（非 docker——agent 要貼宿主量測，容器化是反模式；建議 Nuitka 單檔＋tarball＋systemd，FR-065 收口後啟動）。
• 教訓：pymupdf 殘留來源在 jedi-project 誤留宣告——拔依賴要看整棵 lock 樹的引入路徑，主專案 pyproject 拔乾淨不代表 lock 乾淨。
• 現況（本補記時點）：BE/FE/jedi 全 push 同步。user 於 188 起第三輪：pull → build_all.sh --all（BE 必重編：程式碼＋依賴樹皆變）→ build_bundle.sh（自動收 seaweedfs image＋storage-seed 2 PDF）→ 裝機實測。
• 實測 checklist（第三輪一次收）：CM-1270 三件／CM-1273 install log／.5 四卡（六服務、log rotation、seaweedfs 上傳下載）／CM-1269 框架 L1/L2 預覽可開無 L3／CM-1235 匯框架解析正常。
• 實測綠後：收「修正待驗證」9 卡（1270/1273/1269/1235/.5 四卡/1268）→ 派 T-4.1 手冊棒 → 三件出貨動作（等放行）→ T-4.2 → closing-and-handoff 全案收尾。

第 6 棒補記 2（2026-08-18 晚）：手冊 T-4.1 收（0f056776，11 章 1733 行，親驗事實正確性＋憑證掃描過）；CM-1281/1282 收（FUNCTION 標籤走 labels 表非 system_menus——派工單寫錯表被 runner 查證糾正；AO 範本 0 筆判非缺口＝建資源庫時才衍生；建租戶帶儲存設定兩入口全接）。事故＋教訓：改基線庫沒 regenerate seed——user 全新裝機發現仍無 SeaweedFS 選項，根因＝出貨 seed 是靜態檔（scripts/init/04/05），基線庫三筆異動後沒重跑 gen_seed_sql.sh；已修（18ba8645）＋鐵則入 scripts/init/README.md。GCB 8 支入 repo（b28b8659）＋storage-seed 自動重建（e465052e）＋per-tenant key 前綴裁「先不管」記 CM-1279。

第 6 棒補記 3（2026-08-18 深夜，交棒）：user 裝機實測撞出兩件→開 CM-1283。①FE 儲存設定表單鍵名 bug（已查證根因）：DB 列用通用鍵（endpoint/access_key/…，install.sh 回填），FE StorageConfigForm.vue 綁舊 minio_* 鍵→畫面全空、按儲存會把空值蓋回（BE 讀取端 T-5.1 有雙相容、FE 漏）。②root admin 疑未實作：D13 說「seed 建、密碼裝機生成交原廠」，但 06-admin.sql 刻意留空（D10）、seed 驗證段斷言 users=0、install.sh 無產生段——兩定案打架，查證補建劃入 CM-1283，設計歧異回決策者裁。細節與修法全在卡。派工 prompt：

接手 FR-065 卡 CM-1283：裝機實測回修兩件——①FE 儲存設定頁欄位全空
（鍵名對不上，根因已查證在卡）＋②root admin 疑未實作查證補建。
細節、修法、驗收完整在卡（python3 scripts/notion_case.py get CM-1283 讀取）。
①在 FE repo（compliance-manager-fe，feature/FR-065 不切）：getConfig 鍵名正規化
＋送出用通用鍵＋欄位標籤去 Minio 硬字樣＋「系統內建」資訊條＋空值防蓋回。
②在 BE repo：先查證 root admin 有無實作點，沒有→照 D13 補（密碼 gen_pw 產生
走 credentials 保管機制、不印終端不進 log）；建立時機等設計歧異停下回報決策者。
跨 repo 分開 commit 顯式 add。🔴 環境紀律：本機容器測試；DEV/STG/POC/基線庫不碰。
完成回寫卡「修正待驗證」＋白話段＋commit hash，停下等驗收。

本補記時點待 push：BE 領先 1（1fd32628 docs）＋本交棒 commit。交棒後下個首腦接手讀 STATE §0 讀序。

第 7 棒中途記（2026-08-18 深夜，首腦第四棒，夜間自動作業前）：CM-1283 四件收（runner）＋三裁示（基線庫/DEV migration 放行、明文不清留 PRD 前）＋user 實測撞出 P0 兩件開 CM-1301（①admin 登入間歇失敗，首腦診斷＝pool 連線殘留 RLS 變數，user 存疑認為是帳號未建——以夜間新裝驗收裁決：admin 連登 20 次全成＝診斷對；DB 查無 admin＝診斷錯即重寫卡；②SMTP/LDAP 被 license 過濾攔死，裁走基礎設施豁免不動 LC）。user 授權：push 憑證入 keychain（用後宜 revoke）＋夜間 push/188 rebuild/bundle/全預設裝機；範圍＝裝好只查 DB 不代測，license 檔從 LC 撈放 /home/jedi/。排程 02:04 起每小時查 runner commit。

commits（BE）: f0d1b570（LOG 中途記）→ runner d2c691f2(CM-1301①請求級 auth context 隔離)／11126d0d(②license 基礎設施豁免)／047697ad(review 採納) → 首腦親修 260a8f6b(③追修：共用設定讀取端落 ROOT＋write SQL 欄位錯)。FE：78ccb69／7f8e034（CM-1283①）。全數已 push。 Notion: CM-1283（四件）＋CM-1267 併棒收工；新開 CM-1301（P0 兩件）→ 收；新開 CM-1302（--upgrade --force，跑動中）。15 卡一次收 Done：1235/1263/1267/1268/1269/1270/1273/1276/1277/1278/1280/1281/1282/1283/1301。

做了什麼:

• CM-1283 四件收（FE 鍵名 bug／root admin 補建＋不可刪守門／SMTP-LDAP 下放／CM-1267 密碼永不過期），三裁示放行（基線庫＋DEV 套 capability migration、既有明文不清留 PRD 前）。
• user 裝機實測撞 P0 兩件 → CM-1301：①admin 登入間歇失敗（6 打 1 成）②業務租戶選單無 SMTP/LDAP。首腦逐層查證後開卡；runner 修完親驗。
• 首腦親修讀取端追修（user 回報新租戶 SMTP 頁空白）：③只修寫入沒修讀取，GET/PUT 回讀仍 tenant-scoped → 業務租戶受 RLS 看不到 ROOT 列。順抓 write_root_config_value 引用不存在的 updated_user 欄——共用設定儲存實際恆失敗（前棒只驗選單與讀取沒按過儲存）。DEV 實跑驗證全過。
• 夜間自動作業（user 授權 push＋188 rebuild）：02:04 排程醒→親驗→push→188 pull→build_all --all 五步全綠（20m10s）→ build_bundle 被 PROD 鑰檢查擋下（T-2.6 待辦，內測包需 --skip-prod-key-check）；監看誤判 pgrep 抓到自身 ssh 指令 → 後半未跑，早上由 user 接手。

決策（含被排除的）:

• ①登入修法：不動 jedi-common（set_user_context 是既有 public API，請求生命週期屬應用層職責）→ before_request/teardown 歸零 context。
• ②license：走基礎設施豁免（INFRASTRUCTURE_MODULES 單一集合、兩判定點共用）；不採加進簽發模板（郵件/LDAP 非商品模組，且已出貨照要重簽）。
• LDAP 全系統一組是永久定位非 v1 妥協——per-tenant LDAP 未來（含 SaaS）也不支援（內網協定，SaaS 直連客戶 AD 是反模式）；多租戶身分聯邦走 OAuth/OIDC，另開 FR。
• root admin 密碼維持固定式（A 案）；per-install 隨機生成（B 案）與換密碼留 PRD 出貨前再議。既有明文（tests/conftest.py＋docs/features-site/）裁定不動。
• 共用設定白名單維持 key 粒度（THIRD_PARTY_LOGIN 只有 LDAP 共用），storage 等 tenant-scoped group 完全不受影響（DEV 實測四 group 回歸一致）。
• --upgrade 同版擋下無逃生門 → 開 CM-1302 補 --force（不留 workaround）。

教訓:

• 修「讀寫兩端」的 bug 只修一端＝沒修——③寫入釘 ROOT 但讀取仍 tenant-scoped，症狀從「存了沒生效」變成「開頁全空白」，換一種壞法而已。驗收必須讀寫都用目標角色脈絡實跑（前棒用 root 脈絡自驗故全綠）。
• 首腦誤判成本：admin 登入 6 打 1 成時，首腦先歸因瀏覽器殘留 cookie（錯），user 質疑後才查出連線池 RLS 殘留（對）。教訓＝間歇性故障先做「同條件連打 N 次」量化，不要憑單次成功就下結論。
• 監看 loop 用 pgrep -f <name> 會抓到自己的 ssh/bash 指令字串而永遠為真——判存活要排除自身 PID 或改用 marker 檔。
• system_configs 無 created_user/updated_user 欄：寫 raw SQL 前先 \d 對欄位，不要照其他表的稽核欄慣例假設。

推翻了什麼: 首腦「cookie 殘留」診斷（被自身 curl 重現實驗推翻）；「後端是好的」早期回報（實為 5/6 失敗）；LOG 第 6 棒補記 3 的 CM-1283 派工 prompt 已執行消化。

留給下一棒: ①CM-1302 跑動中（同版 --force）→ 收後 user 重跑換版驗一輪；②三件出貨動作（PROD 鑰四步／進版 1.15.0／推 Harbor）等 user 放行——PROD 鑰是硬前置（bundle 檢查會擋，內測包才用 --skip-prod-key-check）；③T-4.2 正式真機驗收（CM-1264）；④全案收尾（SUMMARY 由本 LOG 濃縮、母卡 CM-1189 收 Done、spec/手冊盤點）。上版 checklist：三支 migration 補 STG/POC（fr058-22／fr063-1g／fr064-3）。

第 7 棒補記（2026-08-19 上午，收尾段）：

• CM-1302 收（a431bce7，親驗過）：--upgrade --force 補逃生門。品質點——--force 刻意做窄（不是萬用跳過，備份失敗／digest 不符／版號區間仍擋）、單獨帶不加 --upgrade 明確報錯不靜默忽略、註明同版時 compose 靠「tag 指向的 image ID」判定重建故 docker load 後照樣 recreate。手冊＋--help＋未知參數提示三處同步。
• CM-1264 範圍縮減入卡（決策者洞察：STG 鑰已走過全鏈＝機制已驗，PROD 鑰只新增「四步接線」風險）：①全鏈一輪用 STG 照②PROD 鑰窄驗證③負面案挑兩個；移出四項引用既有驗證。
• v1.15.0 進版（a5e32bb9）：走 version-bump skill 四步——RN（10 節）＋鏡射 spec 站＋pyproject 1.14.0→1.15.0（功能版號：194 commits／67 feat）＋FE package.json 對齊＋spec 快照 docs/specs/v1.15.0/ build（無 nav 警告）。Step 0 自動 gate 未跑，RN §0 寫明放行依據為決策者三輪裝機實測（比照 v1.14.0 前例）。兩 repo merge main、tag 已打並由 user 推。
• 188 升級實證：install.sh --upgrade 1.14.0→1.15.0 正規流程走完（非重裝），六服務 healthy、version 回 a5e32bb9、資料全保留（admin／blsadmin／兩租戶／SMTP 列／8 旗標）——順帶證明 CM-1302 沒弄壞跨版路徑。
• Harbor 出貨：be:1.15.0＝latest（d558ada9…）／fe（cd9bb261…）／init（207a2f76…）推完，pull 回比 digest 複驗（manifest inspect 在 jedi 帳號因 certs.d 私鑰權限失敗，改用 pull 驗證）。
• Notion 一次收 16 卡：15 卡（1235/1263/1267/1268/1269/1270/1273/1276/1277/1278/1280/1281/1282/1283/1301）＋CM-1302；「修正待驗證」歸零。
• 教訓（本補記新增）：①bundle 產出要等檔案大小穩定再解壓——build_bundle 回報完成時 gzip 仍在寫，早解會 unexpected end of file（判存活改用「size 連續兩次相同」而非 pgrep）。②188 jedi 帳號無 sudo 免密：install.sh 全系列（安裝／升級／uninstall）只能 user 本人跑，Claude 能做的是 build／打包／docker push／唯讀查驗——派工與夜間自動作業排程時要把這條算進去。③版號單一來源＝pyproject.toml，build 鏈全數由它推導（build_fe_image 另斷言 FE package.json 同版），出包不需帶版號參數。
• 留給下一棒：見 STATE §3 三選一（PROD 鑰四步／T-4.2 縮減版／全案收尾）。user 表示接下來優先做 FR-066 agent 原生安裝包（母案 CM-1284＋16 子卡已開、設計已定案，與 FR-065 無依賴），FR-065 這條先留著。