---
title: FR-141 LOG
---

# FR-141 LOG（append-only）

## 2026-10-15～16　首腦（[R3]稽核計畫重構）

- 取號 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 一次建完。

## 2026-10-16　A1 驗收（首腦）

- 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。

## 2026-10-16　改 worktree 作業（首腦）

- 決策者要邊測 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 的說明。

## 2026-10-16　A4 驗收（首腦）

- 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 卡註記顯示前統一。

## 2026-10-16　A2 驗收（首腦）

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

## 2026-10-16　B1 驗收＋發現 A4×B1 衝突（首腦）

- 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 路徑。

## 2026-10-16　A3 驗收（首腦）

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

## 2026-10-16　A5 開卡、B2／A5／B4 同批派（首腦）

- 決策者裁 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 卡註記避開、自建測試專案。

## 2026-10-16　A5 驗收（首腦）

- 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 起就在，對應的是稽核單位而非個人，正確，非新問題。

## 2026-10-16　B4 驗收（範圍與承襲部分，首腦）

- 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 補。

## 2026-10-16　B2 驗收（首腦）

- 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 名單。

## 2026-10-16　B4 補完驗收（首腦）

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

## 2026-10-16　對齊 FR-140 稽核次 UI；記收口合併計畫（首腦）

- 決策者問 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）。

## 2026-10-16　B3 驗收；全部實作卡復核完（首腦）

- 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 自己的卡號並重啟。

## 2026-10-16　B5 開卡（首腦）

- 決策者裁受評人員當場新增照建議：存 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`。

## 2026-10-16　B5 驗收（首腦）

- 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 匯入比對稽核單位用全量名單。

## 2026-10-16　補回 STATE 遺失的收口事項（首腦）

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

## 2026-10-16　合併前準備（首腦，依 FR-140 首腦提醒）

- 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` 兩邊都動，合併後兩邊首腦各核一次。


## 首腦第 1 棒收工 — 2026-10-16 16:20 — 協調者（合併＋交接）

**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。

## 測試棒第 1 棒中繼交棒 — 2026-10-16 19:35 — 首腦（陪決策者複測）

**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 項未測完。

## 測試棒第 2 棒 — 2026-10-16 19:40 — 首腦（陪決策者複測）

**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 項。

## 測試棒第 2 棒（續）— 2026-10-16 21:15 — 首腦

**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 項。

## 測試棒第 2 棒（續 2）— 2026-10-16 21:30 — 首腦

**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 項。

## 測試棒第 2 棒（續 3）— 2026-10-16 21:35 — 首腦

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

## 測試棒第 2 棒（續 4）— 2026-10-16 21:50 — 首腦（撤回控制項層）

**commits**：BE revert `b0140999e`、`b9645e8e1`；FE revert `2f076ab5`、拿掉控制項預設 `ba0aa033`
**推翻了什麼**：續 2、續 3 的 Excel 控制項列、預覽／總覽控制項列全部撤回（`c1d0b33bf`、`4af4f886e`、`8683646f`）。決策者裁示一併拿掉畫面「控制項預設」。
**原因**：決策者以為系統存了控制項層的設定（因為畫面有「控制項預設」可填），一路要求 Excel→預覽→總覽→Word 都要有控制項列；到 Word 時首腦說明「控制項層沒存」，決策者才發現誤會。
**教訓**：
- 決策者要求「某處也要有 X」時，先確認 X 在系統裡**存不存在**、是什麼性質，再動手。這次連做三處才在第四處（Word）講清楚「控制項預設不存檔」——應在第一次（Excel）就講白：「控制項列匯出永遠空白，因為系統不存控制項層」，並問這是不是他要的。
- 會讓人誤以為「有存」的 UI（可填、有標題、像設定區塊，但不存檔）本身就是誤導，拿掉比加說明好。

## 收卡 — 2026-10-16 22:00 — 首腦

**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 項（套件發版）是其他項的前提。

## 文件開卡 — 2026-10-16 22:15 — 首腦

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

## CM-2835 驗收 — 2026-10-16 23:40 — 首腦

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