FR-141 LOG（append-only）

• 取號 FR-141、母卡 CM-2799、雛形卡 CM-2800。兩支探脈（BE、FE）確認：AP 以行程為單位、方法掛 activity 只到控制項、control_objective_selections 從未寫入、terms-and-conditions 無表、AP 無任何匯出、FR-043 把六段塞進行程說明。
• 雛形三輪：①兩頁籤大表格＋固定格數 Excel；②評估目標改左樹右表單、匯入預覽併入同畫面、稽核次麵包屑；③Excel 改一格多值四頁、「場次」改名「計畫概要」、稽核單位單行、方法組不限。
• 推翻：D1 原裁「固定格數每格一般下拉」，決策者看雛形後改為一格多值（業界多採此法）。
• 討論稿與雛形第二輪原派 subagent，兩支在背景中斷（40 分鐘無產出），決策者令主 session 直接做。
• design 時 DEV 實查：assessment_findings.target_status_state 有 pending 113 筆，現行縮範圍只收 not-satisfied 會漏；P1 規則定為只排除 satisfied。method_keywords.py 已把「現場實地觀察」對到 EXAMINE，P3 做法列 B4 開工前問。
• commits：17245d37d 登記、0769fc7d0 雛形一、54e76c319 討論稿、809644d90 雛形二、194a2f6eb 雛形三、8d28afc51 design；子卡 CM-2802～2809 一次建完。

• CM-2802 runner 完成：BE ffa1ff4b0、套件 f9d19cad、FE 6cd46ec6。首腦核三 repo commit、DEV AP 1162（四列 terms、單一 task、organization party、cm_app 權限）、守衛 118 passed、FR-040 17 passed；通過，待複測。
• runner 發現：AR assessment-log 拿 task.uuid 當 related-task-uuid → 合併 task 改就地更新不重建；repo.update() 略過 None 會吞掉「拿掉角色」，已修。
• 小瑕疵（不退件，收口改）：PartyRepoImpl() 直接實例化，承襲 FR-040 先例。
• 陷阱：套件未發版，pin 狀態下 terms 方法不存在 → 後續卡都要切 path。

• 決策者要邊測 FR-140，裁 FR-141 三個 repo 都開 worktree（feature/FR-141），資料庫共用 DEV。
• 發現：A1 runner 驗完把主工作樹 pyproject.toml 整份還原，連 FR-140 三支套件的 path 設定一起刪了（venv 仍指本機原始碼，當下沒壞；下次 poetry 會悄悄退回發布版）。首腦補回那三行，未跑 poetry、未動 FR-140 的 BE。
• 架設：BE worktree 自建 .venv、PORT=8001、四支套件 path 指套件 worktree；FE worktree node_modules symlink 主工作樹、API 指 8001。8001 起得來，A1 overview 路由回 401（未帶 token）＝已註冊。
• 坑：在 worktree 跑 poetry 會往上找到主工作樹的 .venv，必先 export VIRTUAL_ENV=$PWD/.venv；FE 的 package-lock.json 未入版控，worktree 沒有。
• 未派的 CM-2803～2809 都 append 了工作目錄改 worktree 的說明。

• CM-2805：BE 1e0b69703、套件 ed48e82f（feature/FR-141）。套件不反向 import 主專案，由 DI 注入 A1 的 overview service；@transaction 巢狀沿用同一 session（查 jedi_common），set_tasks 與寫概要同一交易。亞航真 docx 實跑 parser→mapper 六欄正確。167 passed。通過、待複測。
• 打折：8001 完整 API 流程沒跑（本機手工簽 token 撞 login hook，不硬做），留到 A2 畫面後決策者手測。
• 發現：mapper 日期帶秒、A1 文件寫到分；已在 A2 卡註記顯示前統一。

• CM-2803：FE f6726c5b（worktree）。路由只換 component；日期以正則截到分（A4 帶秒自動吸收）；唯讀時儲存／匯入按鈕整顆隱藏，並接能力點與授權唯讀；build 首腦實跑過。通過、待複測。
• 打折：DEV 無可正常進入的規劃中專案（T8 驗收 專案 B 已刪）→ 複測前要新開；已結束稽核次切換未實跑；淺色主題日期框要實切。

• CM-2806：BE ed55368c0、套件 9d54809a、FE eb05d5b8（feature/FR-141）。SSP 共用檔只搬移函式一字未改；首腦自取 9d54809a^ 舊版 _planning_by_control 與新 planning_by_control 在 DEV 全部 4 份 AP 比對控制項層輸出，差異 0（FR-140 AR 畫面不受影響）。通過、待複測。
• AP 1162 受評控制項清空：log 證實 10:41 在主工作樹 8000 由 A1 runner 手測（overview→舊 tasks→overview）造成，改 worktree 前；屬已刪測試專案。
• 🔴 發現：assessment_plan_app_service.set_tasks（:615-616 刪全部 activity，再經套件 set_tasks 刪重建全部 task）仍被 FR-043 docx 匯入 confirm 呼叫 → B1 合入後，匯入 docx 會清掉逐 AO 的 activity 與 task.associated_activities.subjects，無錯誤訊息。單卡各自驗收都過，是跨卡整合問題。首腦建議甲：docx 匯入不再呼叫 set_tasks。待決策者裁。B2 卡已先註記舊 /tasks 路徑。

• CM-2804：BE 7a5f37a06、FE 4bd9e6b1（feature/FR-141）。匯出守門＝參與者（同 A1 讀）。首腦以雛形亞航資料餵 ApDocxGenerator→LibreOffice pdf 逐頁看：標題帶稽核次、一～六段、三段「由…協助辦理。」＋稽核人員、日期格式、橫式附件表合併格、方法「方法：指引」皆對。通過、待複測。

• 決策者裁 A4×B1 衝突甲案（docx 匯入只寫計畫概要與稽核人員、不再呼叫 set_tasks），開 A5 CM-2810。B2 卡更正：移除舊 /tasks 與 set_tasks 須等 A5 commit；不做「保護」。
• 決策者：FR-140 仍在測，B4 用不同資料即可。首腦查 DEV 今日輪次：專案 1547「CMMC 內外稽流程測試專案」（輪次 1198，唯一 internal 稽核次）為 FR-140 測試資料；1321 為覆核輪範例。B4 卡註記避開、自建測試專案。

• CM-2810：BE 2faa44d86、套件 6949a246、FE 53a4756d（feature/FR-141）。confirm 只剩 add_ap_party＋put_overview；ensure_single_plan_task 就地更新、合併 associated_activities、不刪 activity → 整條 confirm 不再清逐 AO 資料。132 passed；runner 突變測試 3 紅。通過、待複測。
• 打折：真 DB 端到端沒跑。首腦試 rollback 交易直呼 service，撞 RLS（無 user context 看不到輪次）與 DI Factory 各自實例化守門，不硬做，留畫面複測。
• 查過：party_type: organization 自 CM-1492 起就在，對應的是稽核單位而非個人，正確，非新問題。

• CM-2809：BE f45a622a0、套件 9b0e2290。pass_scope_rule 只排除明確 satisfied，AO 無判定時退回控制層判定（runner 發現：現行 AR 矩陣是控制層判定，不退回會整批帶入）。首腦自做突變（改回只收 not-satisfied）4 紅；169 passed。
• runner 補了卡上沒寫的：第 2 次內稽重凍 SSP、AP metadata 重複製 → 人員與受評對象 uuid 全換，承襲需 remap（先用 clone 回報的對照，對不到才同名）。
• runner 改了 FR-140 STATE 一行（函式改名），首腦接受、知會 FR-140。
• 決策者裁「現場觀察」甲；選單一小段待 runner 補。

• CM-2807：FE 28f9c727、BE 4fa93a2c9。FR-140 AR 頁只改兩行註解。移除的五個函式 grep 無呼叫者；clone 用的是套件的 set_tasks（保留 uuid）。8001 舊 /tasks 回 404。182 passed、build 過。通過、待複測。
• 🔴 踩坑（首腦自己）：B4 驗收時的突變測試，突變與還原在同一秒內完成，.pyc 沒失效，B2 驗收時 4 條紅；清 pycache 後全綠，8001 保險起見重啟。已寫進 closing-and-handoff 首腦驗收側紀律。
• runner 留待決策者裁：受評人員「當場新增」要加在 living SSP 還是 AP 名單。

• 「現場觀察」甲案：seed 48718534a（條件含 key='檢視'，不覆蓋管理員改過的）、詞庫 56b95932、i18n c02dbd96。DEV 已套。
• runner 漏登記 manifest，check 跑出 FAIL；首腦在 worktree 補一行 11995aee2，check 通過。整張轉待複測。

• 決策者問 FR-140 的「第 N 次內部／外部」UI 有沒有做進來。查 FR-140.10（6af14483）：它在被 FR-141 刪掉的舊頁加過稽核次 Tag 與 passQuery。FR-141 A2 已沿用 useAuditPasses（同一個網址 query pass、唯讀橫幅、/ap?pass_uid），overview／objectives／export 都用那次 AP 的 apUid，功能沒漏。
• 不一致：A2 自寫 usePassTitle，與 FR-140 passLabel 同功能兩份、文案不同（「第 1 次 內部稽核」vs「第 1 次內部」）。補進 B3 卡順手收。
• 決策者指示：全部做完後把 worktree 合回 feature/FR-139，跟 FR-140 流程一起測。STATE 加收口合併段（衝突點、pyproject、migration、8000／8001）。

• CM-2808：BE 5b311e072、FE ab171ca1（只在 FR-141）。沿用 ap_docx_parse_jobs（source_type varchar(20) 無 CHECK），無 migration。passTitle 重複已收。
• mirror_parity 紅燈：首腦開臨時 detached worktree 在 5b311e072^ 跑，同樣紅，證實舊債。
• 首腦純函式跑 Excel 來回：四頁＋A 欄隱藏；overview end 變更、「現場觀察」自動對 EXAMINE、「文件檢視」與「許春富」列未知、假列 out_of_scope、對應後歸零、指引保留第二個冒號。通過、待複測。
• 監控誤報兩次（FR-140.14／.15 卡號落在 FR-141 的 grep 範圍；改規則後監控沒重啟，bash 不會重讀 while 迴圈）→ 規則收窄到 FR-141 自己的卡號並重啟。

• 決策者裁受評人員當場新增照建議：存 AP 自己 metadata parties、role=assessed，不加進 SSP（凍結快照＋稽核中資源庫鎖寫）。開 CM-2814。
• 開卡核對發現：B1 ap_objectives_app_service.py:70-71（options.auditors）與 :85（put 驗證）取 AP metadata 全部 person 不看角色；A1 計畫概要只取 role=assessor。B5 加 assessed 後會混進稽核人員 → 本卡一併改成只取 assessor，共用 _role_of。

• CM-2814：BE 1555d66ff、FE a39c8ac8（只在 FR-141）。角色判斷單一份 ap_party_roles；add_ap_party 延伸 reuse_names，預設路徑仍 409（只放寬受評與稽核同名）。186 passed。通過、待複測。
• 推翻首腦卡上判斷：卡上寫「B4 承襲依同名就涵蓋本計畫新增的人」，runner 實查不涵蓋（受評對象 uuid 只用 SSP 對照換），補 subject_map = {**party_map, **ssp_map} 並加測試。教訓：開卡時寫「應該已涵蓋」的推測要標成待驗證，不能寫成結論。
• 收口小遺留：list_ap_parties 不分角色，docx 匯入比對稽核單位用全量名單。

• 決策者問「還有什麼沒做」，回查才發現 STATE 收口清單只剩一行。原因：11:03 改 worktree 時整段重寫「環境」節，先前附在那裡的收口待辦一起被蓋掉；之後幾次用「- 收口待改：」當錨點的 str.replace 找不到錨點，Python 不報錯，靜默沒寫進去（PartyRepoImpl、套件註解、mirror_parity、list_ap_parties、B4 改 FR-140 規則五項）。
• 已從 LOG 與卡片復核段逐項撈回，重寫成「收口時」整節。教訓：用 str.replace 改 living 文件時，先 assert 錨點存在，或改完 grep 確認新內容真的在。

• FR-140 首腦提醒三點，逐項核：
  1. 「STATE 停在 10:48」：實查主工作樹（FR-139）的 STATE 是新的（含 B5）；過期的是 feature/FR-141 分支上那份——worktree 開出後 runner 只 commit 程式，首腦的文件都 commit 在主工作樹。合併時 FR-141 分支沒動過 FR-141 文件，git 保留 FR-139 新版，舊 STATE 不會合回來；worktree 移除後就不見。
  2. 套件發版名單加 jedi-oscal-v2：FR-140 原有 compliance-audit、flow-engine、task-platform 三支收口前不可發版；FR-141 的 A1（terms）、B1（逐 AO）改了 jedi-oscal-v2，A1 runner 回寫已指出未發版時 pin 狀態 BE 打計畫概要會 500。收口時四支同發，主專案四支一起還原 pin。
  3. Notion 子卡狀態：見下方核對。
• 修正首腦先前判斷：STATE 原寫「合併後要在主 pyproject 加 jedi-oscal-v2 path」，FR-140 首腦指出主 venv 已是 editable 指主套件目錄。首腦實查 .venv/.../jedi_oscal_v2.pth 確認，改寫為「pyproject 不用動，但字面仍 pin 2.6.0，有人跑 poetry install 會被換回 Nexus 版」。
• 合併由 FR-140 首腦做；套件 audit_round_app_service.py 兩邊都動，合併後兩邊首腦各核一次。

commits: 合併 BE 75d3af54d、FE c4b0a359、套件 e3be08aa；撞號修正 BE 11a2ff884、FE 9b1527f2（皆未 push） Notion: 十張實作子卡＋雛形卡維持「修正待驗證」；母卡 CM-2799 加合併前現況、複測清單、收口事項 做了什麼:

• 依決策者令把 feature/FR-141 三 repo 合回 feature/FR-139：先 dry-run（merge-tree），套件與 FE 乾淨、BE 只有 manifest.tsv 衝突（兩邊列都留，check 過）。
• dry-run 時抓到錯誤碼撞號：FR-140.17（77e9ee2c3）與 FR-141.B3 各自新增 GRC_412062，意思不同，git 自動合併不報衝突。合併前在臨時 worktree 把 FR-141 改 GRC_412063（BE 列舉＋凍結表、FE 三語），再掃全 common/code 與套件確認合併結果無重複碼。
• 合併後核 audit_round_app_service.py：B4 的 clone_ap_for_next_pass／承襲 pass_no 與 FR-140.17 的跨稽核次退回都在；舊名 clone_ap_narrowed_to_not_met 無殘留；FE 無舊頁、usePassTitle、舊 /tasks 引用。
• 測試：309 passed／1 failed（flow_engine_route 能力點附錄，合併前 FR-139 HEAD 就紅，屬 FR-140.14）；FE build 過。重啟 8000（worker 57461 沒動），FR-141 端點 401、舊 /tasks 404。
• STATE 依模板重寫成測試棒冷接版。 決策: 撞號由 FR-141 讓號。理由：FR-140 先用、其 FE 文案與測試已依賴 412062；被排除的：FR-140 改號（動到別人已驗收的卡）。 教訓:
• 兩條平行分支各自新增錯誤碼，git 不會報衝突（不同行、或同 key 不同值時 JSON 才衝突），合併前必須把兩邊新增碼取交集比對。
• zsh 的小寫 path 綁定 PATH，迴圈變數取名 path 會讓 curl／ps 全部 command not found。 推翻了什麼: FR-140 首腦說「141 STATE 停在 10:48」——實為主工作樹那份是新的，過期的是 feature/FR-141 分支上那份（runner 只 commit 程式），合併時 git 保留新版。 留給下一棒: 決策者照母卡複測清單在 8000 測；主 pyproject 仍 pin oscal-v2 2.6.0，別跑 poetry install。

commits（全在 feature/FR-139，未 push）：FE 27 筆 10502f61…89dd55cc；BE 9 筆 d130ea370、986c97764、3af2c51fd、b4048bd5e、299a69b0d、a8aca0983、75a0c8a1e（另兩筆為他人 FR-142／FR-140 文件） Notion：CM-2803、2804、2807、2808、2814、2758 各補複測修正段，狀態維持「修正待驗證」 做了什麼（決策者複測清單第 1～3 項期間逐點修）：

• 版面：頁籤內容區白底面板；計畫概要稽核單位與日期各一列；評估目標左樹下到 AO 三層、點 AO 只放那一條＋上一項／下一項、點控制項看預設與 AO 一覽；字級對齊 SSP 適用控制項頁；控制項預設與 AO 卡改單欄；方法下拉與指引框同高；篩選只留「全部／未完成」並撐滿寬；左樹加全部展開／收合。
• 行為：控制項預設的稽核人員拿掉勾選框，預帶概要名單、改了才套；離頁提醒（換頁、切稽核次、關分頁）；拿掉全部說明小字、用語改正式（已完成／未完成、已指定、稽核計畫書、稽核計畫工作表）；總覽表格字放大。
• 唯讀：計畫概要唯讀照 Word 正文排版（標題由 GET /ap/<uid>/report-title 取，其餘前端依 _sections 同規則組）；評估目標唯讀為紀錄版（ApObjectiveRecord，決策者說這頁不動）。
• 匯出：稽核計畫書對話框加「預覽」（取 PDF blob 放 iframe）——決策者回報壞掉，未查，見 STATE §4。
• Excel：匯入全形半形都吃（NFKC、頓號／全形逗號／U+2028 分隔、中文字間空白忽略）；名稱內換行壓成單行（DEV 1,313 筆組織名稱夾換行）。
• 越界修 FR-139（決策者裁「那邊已結束，直接改」）：專案規劃頁兩條唯讀提示合成一條（CM-2758）。 決策：
• 受評對象維持兩欄（受評人員／受評系統元件／資產），D3 不改。依據：OSCAL v1.2.2 assessment-subject type 為 component／inventory-item／location／party／user，party 不分人與組織；亞航範例 Word 與附件 Excel 都沒有受評對象欄。被排除：拆三欄、受評人員只列 person（曾做，986c97764，決策者確認 Crowd strike 是單位後撤回）。
• Excel 可選清單不做聯動下拉（一格多值無法用 Excel 下拉），維持參考頁＋匯入預覽對應。決策者同意。
• 計畫概要唯讀要「跟 Word 排版一樣」，不自創文件版（b951379f 的摘要框、副標被否決）。 教訓：
• 新端點只驗未登入 401 不算驗過：299a69b0d 少帶 return_response 的 status，決策者打開就 500。要用登入狀態實打。
• commit 前測試紅了要先讀再 commit（986c97764 先 commit 才看紅燈，結果是替身少 id）。
• 決策者說「改得專業」「要有唯讀模式」時，先出雛形或先問清楚要對齊哪個既有物件（Word、SSP 頁），猜了兩版才對到。
• 本棒瀏覽器工具（claude-in-chrome）整晚 classifier 不可用，所有畫面都沒自驗；下一棒先確認瀏覽器可用。 推翻了什麼：STATE §6 寫的 FR-140 測試資料 1547 已於 10/16 15:50 被歸檔軟刪，不能再用。 留給下一棒：先修預覽；「評估目標」改名「查核規劃」等決策者拍板；複測清單第 4～7 項未測完。

commits（feature/FR-139，未 push）：FE a927edd4（預覽）、75f72090（頁籤改名）；BE 70be6a8cc（附件表稽核人員）、229a79b2e（Excel 頁名＋舊檔相容） Notion：CM-2804、2807、2808 各補「測試棒第 2 棒修正」段，狀態維持「修正待驗證」 做了什麼：

• 預覽「無法載入 PDF 文件」：useApExportDownload.fetchPdfUrl 少帶 meta.withHeaders。攔截器沒這旗標時直接回 body（Blob），程式卻 { data: blob } 解構得 undefined，new Blob([undefined]) 是九個字的假 PDF。STATE 列的假設②命中。
• 附件表稽核人員空白：objective_display_values 把 null（沿用）壓成 []，_objective 遇 null 改回退概要名單；存檔時 [] 本來就被寫成 null，沒有「刻意清空」第三態。
• 頁籤改名：只改頁籤與 Excel 第三頁名，指 AO 本身的「評估目標」不動；reader 新名優先、找不到認舊名「評估目標」。 驗證：以 test client＋正式簽發的 token（add_token_to_db 登記，DEV login_tokens 多一列）實打 GET /ap/7cd12add…/export：docx 附件表 7/7 有值、PDF 回 %PDF-、「王阿財」8 次。既有測試 149 passed、FE build 過。畫面沒用瀏覽器看（本棒沒開瀏覽器工具）。 教訓：
• 登入狀態實打的做法：create_app(enable_socketio=False, enable_scheduler=False)＋手動 register_blueprint（create_app() 預設不掛 REST blueprint，且預設會起排程與 8000 雙跑）；token 要經 LoginTokenDomainService.add_token_to_db 登記，否則 jti 查不到一律當撤銷；腳本要 source .env，否則連到預設庫 compliance_manager。
• 主工作樹另有 session 同時在改 project_service 等檔並重啟 8000（19:34），只 add 自己的檔。 推翻了什麼：STATE §6 寫的測試專案 1547 已軟刪，現在是 1548。 留給下一棒：決策者畫面複測預覽與附件表；續測複測清單第 4～7 項。

commits：BE 76420890e（稽核人員匯入可新增）；FE d0edd306（下拉新增選項）、c43946da（預覽篩選固定全部）。「尚未開始」文案改動（{label}{page}尚未建立）已隨 FR-140 的 785a6db4 一起進版。 Notion：CM-2807、CM-2808 補續段，維持「修正待驗證」 做了什麼：

• 稽核人員 __new：ensure_ap_auditor 同名非受評人員就沿用並設 assessor，否則 add_ap_party。confirm 先建拿 uuid → 重建 differ → put_overview → 再補一次角色 → put_objectives。
• 預覽篩選：進場一律「全部」。 驗證：test client 在 1548 第 1 次外部 AP 走完整匯出→改→上傳→confirm 流程，名單出現新人；測試 party（oscal.parties 10892）已刪。 教訓：
• 自動切篩選要看「待處理的東西在不在這一頁」：待對應只在計畫概要時，切「待處理」讓查核項目規劃整頁空白，決策者以為匯入失敗。
• 別的 session 的未 commit 檔案裡就地改字可行，但不要自己 commit；對方 commit 時會一起帶走（這次 FR-140 785a6db4 正是如此）。 留給下一棒：決策者複測本棒四項＋續測複測清單第 4～7 項。

commits：FE 877de5d9（對不到的人預設新增＋橫幅「將新增 N 位人員」）；BE c1d0b33bf（Excel 整個控制項列） Notion：CM-2808 補兩段，維持「修正待驗證」 決策：Excel 控制項層走做法 A——匯入時展開，不存。被排除：B 存控制項層（套件資料結構＋畫面「控制項預設」改存檔＋報告稿都要動；OSCAL 一個 activity 對一條 AO，控制項層沒有落點）。先給決策者一份用真實資料改的範本看，看完才動手。 做了什麼：展開放在新模組 ap_workbook_control_rows.py，WorkbookDiff 建構時呼叫；被刪 AO 的補列用 keep_current 讓 _incoming_ao 沿用現值。 教訓：

• 「補一列」最容易出錯的是沒填的欄位：給空值等於清空那條 AO，必須沿用現值。
• heredoc 裡寫 Python 字串的 \\n 會被轉成真換行，產出 SyntaxError；腳本內容改用 <<'EOF' 或寫完再修。 留給下一棒：決策者複測本棒全部項目＋複測清單第 4～7 項。

commits：BE 4af4f886e（diff.control_rows）；FE 8683646f（ApControlRowPreview、總覽控制項列） 做了什麼：預覽時控制項畫面顯示 Excel 控制項列內容與套用數；總覽照 Excel 版面每控制項加一列控制項列，預覽時顯示控制項列內容、已變更 AO 列橘底。 教訓：Excel 加了「控制項層」後，畫面上三個看 AO 的地方（左樹、控制項畫面、總覽）都要一起想——只做匯入邏輯，決策者在預覽看不到差異會以為沒生效。

commits：BE revert b0140999e、b9645e8e1；FE revert 2f076ab5、拿掉控制項預設 ba0aa033 推翻了什麼：續 2、續 3 的 Excel 控制項列、預覽／總覽控制項列全部撤回（c1d0b33bf、4af4f886e、8683646f）。決策者裁示一併拿掉畫面「控制項預設」。 原因：決策者以為系統存了控制項層的設定（因為畫面有「控制項預設」可填），一路要求 Excel→預覽→總覽→Word 都要有控制項列；到 Word 時首腦說明「控制項層沒存」，決策者才發現誤會。 教訓：

• 決策者要求「某處也要有 X」時，先確認 X 在系統裡存不存在、是什麼性質，再動手。這次連做三處才在第四處（Word）講清楚「控制項預設不存檔」——應在第一次（Excel）就講白：「控制項列匯出永遠空白，因為系統不存控制項層」，並問這是不是他要的。
• 會讓人誤以為「有存」的 UI（可填、有標題、像設定區塊，但不存檔）本身就是誤導，拿掉比加說明好。

push：BE 30b0f8363、FE ba0aa033、套件 3b94ad67（套件分支本機原無追蹤，遠端已有同名分支、可快轉，已 push -u）。BE 未 commit 的 pyproject.toml（FR-140 套件 path 設定）未推。 Notion：母卡 CM-2799 補收口五段＋待辦後轉 Done；子卡 CM-2800、2802～2810、2814 共 11 張轉 Done。 決策：決策者裁示「當我都驗過」、收卡；問進版時改裁只 push、不發套件、不進版。理由：四支套件 FR-140 也在用，發版要等 FR-140 收口；套件不發，主專案 pin 還指 Nexus 舊版，進版等於出一個 poetry install 就壞的版本。 留給收口那棒：STATE §3 清單，第 1 項（套件發版）是其他項的前提。

commits：115c8e3e1 design.md v2（「實作後改判」節） Notion：開 CM-2835（SPEC 頁、使用手冊、README、需求站 HTML），母卡追加連結。 決策：決策者裁「派給下一棒」。design.md 首腦自己改（今天定案的規則首腦最清楚）；其餘量大的交新 session。design.md 原文定位是「設計決策不回頭改寫」，所以改判集中寫成一節、內文舊規則加刪除線指過去，不改寫原決策。

commits：runner 54a600127（SPEC 頁、使用手冊 audit-plan-guide.md、README、需求站 HTML） Notion：CM-2835 首腦復核通過 → Done。 核對：SPEC 無舊頁與控制項預設殘留、規則與今晚定案一致、與 FR-140.C1 同頁合併無衝突；「Excel 三欄留白會清掉」首腦實跑匯入比對確認；mkdocs --strict 重跑過。打折：畫面未照手冊實走，列手測。