FR-142 交接紀錄（LOG，append-only）

每棒收工追加一個 block，既有 block 不改；更正寫在新 block 的「推翻了什麼」。現況看 FR-142-STATE.md。

commits（主工作樹 BE feature/FR-139，未 push）: fe2872638 開案 → 7dea2cfa4 討論稿＋雛形 v1 → de0a48276 討論稿定版 → 851d1f2cc design.md＋開卡 → d3c3e1bf9 worktree＋Excel 命名 → c3b933e32 worktree 環境備妥 → 7cc01e006 1a 復核＋專用庫 → 1b2e4a3d3（規範：首腦自做文件）→ 1b2082610（規範：UI 禁左粗框）。worktree 套件 feature/FR-142：acdb197b（1a）、c69dd601（conftest）、4a310d97（1b，runner）；worktree BE：38f90c51a（1a 讀模型）。 Notion: CM-2818 母卡；CM-2819 Done；CM-2823～2829 一次建完；2823 修正待驗證（首腦復核過）；2824 修正待驗證（runner 回寫，首腦未復核）。 做了什麼: 探脈（亞航報告／附件、舊判定頁、jedi-oscal-v2 三處匯出不合規）→ 討論稿 D1～D12 全裁 → 雛形六輪（Playwright node 腳本驗）→ design.md → 七張卡 → 建 worktree 三 repo＋專用庫 guidant_ai_fr142（pg_dump 複製 DEV）→ 1a 復核（兩支 SQL 讀模型跟著對齊）→ 派 1b。查完「我的稽核」清單頁現況（見 STATE §4）。 決策:

• 決定判定以評估目標為單位、未判定＝不建 finding、不適用走 implementation-status。理由：OSCAL status.state 封閉值域；被排除：塞自訂字串（匯出不合規）、建 pending finding（1a 前的作法，匯出帶假值）。
• 決定控制項結論不存、由 aggregate_verdict 一支即時推。理由：OSCAL 無控制項層判定欄，三處各算一次必漏「掛風險」條件；被排除：存欄位（要維護一致性）。
• 決定佐證一張平清單不分任務、任務討論不採用（決策者裁）。
• 決定 FR-142 走 worktree＋專用庫。理由：8000 主工作樹在測 FR-140、1a 的 migration 會動 DEV 判定資料；被排除：共用 DEV（決策者否決）、TEMPLATE 複製（DEV 有連線鎖）。
• 決定首腦自做討論稿／雛形／design／開卡，不派 subagent（決策者裁，已入 CLAUDE.md）。被排除：原「文件一律外包」規則——每次 subagent 做到斷線浪費。
• 決定 UI 禁左粗框卡片（決策者裁，已入 CLAUDE.md 與設計系統 skill）。 教訓:
• Playwright MCP 的瀏覽器 profile 會被鎖，雛形驗證改用 test repo 的 node_modules 跑 node 腳本。
• 套件 conftest 寫死主工作樹 .env，worktree 跑測試會打到 DEV；改成讀 JEDI_TEST_ENV。
• pg CREATE DATABASE … TEMPLATE 在來源有連線時失敗，直接 pg_dump -Fc + pg_restore -j4。
• 8002 是 socketio 預設埠，worktree BE 要用 8003。 推翻了什麼: 開卡時卡上「DB 共用本機 DEV、埠 8002」先後被「8003」「專用庫」兩段取代（卡上已 append 更正）。 留給下一棒: 先復核 1b；「我的稽核」清單頁改版（STATE §4 第一條）等決策者裁要不要開 FR-142.7。

commits（主工作樹 BE feature/FR-139，未 push）: 本 block 對應的文件 commit 見下一棒或 git log（STATE／README／LOG 更新＋CM-2833 開卡）。 Notion: 新開 CM-2833（FR-142.7「我的稽核」清單與首頁小卡改讀評估目標層）；母卡 CM-2818 追加子卡一列。其餘卡狀態未動（2823／2824 修正待驗證，2825～2829 Not started）。 做了什麼: 照 STATE §0 冷接、pre-flight 唯讀盤點（主工作樹 HEAD 已被 FR-141 測試棒推到 1061e1d20，與本案無關）；決策者裁「我的稽核」要開 .7 → 探脈 auditor_dashboard_query.py／MyAuditsView.vue／DashboardView.vue／1b 的 summarize、objective_ids_of 簽章、專用庫 reviewed_controls 兩種形狀 → 開卡、更新 STATE §1／§3／§4、README 總進度、features README。 決策:

• 決定 .7 獨立一張（BE 讀模型＋FE 兩頁），不併入棒 2／3。理由：兩張卡已夠重，且本卡跨 DashboardView.vue，獨立較好驗；與 2／4／6 不碰同檔可平行派。
• 決定統計在 app 層算（呼叫 1b 的 summarize）、infra 只撈原料；回傳鍵維持相容再加新鍵（total_objectives／judged_objectives／control_summary／scope_level），舊稽核次退回 finding 計數法。ap_title 直接拿掉不留死欄。 教訓: notion_case.py append 要 --file；notion_create_case.py 一次建一張時 Case No 仍連號（2833 緊接 2832）。 留給下一棒: 1b 復核仍未做（決策者這棒改派優先）；四張可平行派：CM-2825／2827／2829／2833；棒 2 復核後派 3、5。

commits（主工作樹 BE feature/FR-139，未 push）: e32420c2f（開 .7）→ 本 block 文件 commit。worktree：套件 7c9840a6（6）、bd73429b（7 serializer）；BE e243300f1（6 seed）、aa2ba2214（7）；FE 1c86875e（7）。 Notion: 2824／2829／2833 各 append「✅ 首腦復核」；2825 append 守門注意；2825／2827 runner 進行中。 做了什麼: 決策者派出 2／4／6／7 四棒；首腦復核 1b（開三支新檔＋app service diff、專用庫跑兩套件測試、突變 has_risk 4 紅、專用庫核 AP 1237 評估目標 2＋3＋2＝7）、棒 6（diff、seed 六列實查、突變 1 紅）、棒 7（三 repo diff、border-left 自檢、突變 2＋1 紅、用 e2e 帳號登入 8003 實打 my/list 驗舊稽核次相容）。 決策:

• finalize_assessment 的 stats["pending"] 守門對新稽核次失效，判定歸棒 2 範圍（守門改版本來就在卡上），不回頭改 1b；被排除：在套件 list_findings 內補算 pending（它拿不到 AO 清單，得多傳參數動到 824 行檔）。
• 棒 7 runner 自行小改套件 serializer（卡寫「套件不動」）判為合理：serializer 是端點契約，不改新鍵出不去。
• memory reference_dev_login.md 改成只指路不存密碼（明文已過期且本來就不該存）。 教訓:
• 「未判定＝沒有 finding」這種存法改變，會讓所有「數 finding 算 pending」的讀取者靜默失效——1b 復核時 grep stats["pending"] 才抓到結案守門，開卡時沒列。下次改存法先 grep 所有讀取者（memory feedback_scope_fix_grep_all_writers_and_readers）。
• runner 起的 8003 沒關會留孤兒進程（ppid 1）；平行棒在跑時先別殺，等全部回寫再清。 推翻了什麼: 無。 留給下一棒: 等 2／4 回寫復核；棒 2 復核要實打並開一個新稽核次把 1b／6／7 新路徑一次看完；之後派 3、5。

commits（主工作樹 BE feature/FR-139，未 push）: 9f272a19c（1b／6／7 復核文件）→ 本 block 文件 commit。worktree BE：51101df83（2）、d00fecb1f（4）；FE c597bbe4（4 error-code）。 Notion: 2825／2827 append「✅ 首腦復核」；2826／2828 append 派前補充（實際接點、error code、選單 i18n、驗證用 round）。 做了什麼: 開檔核棒 2（app service／writer／close／route／DI 新容器／守門測試）與棒 4（import service／diff／reader／route）；守衛＋新測試 145 passed；突變（拿掉第 7 章檢查）3 紅；殺掉棒 7 留的舊碼 8003 重起到 HEAD；用 round 1199 從 planning force 推兩站到 audit，走完 PUT 四情境→close 412→Excel 匯出改格匯入預覽 confirm→draft→第 7 章→close 200（凍結 4 筆有雜湊、POA&M 283 兩筆、推進 poam）→結案後 PUT／匯入／close 全 409；DB 驗 finding 不適用形狀、risk facets。匯出 xlsx 用 openpyxl 開驗四頁 K～Q。 決策:

• 棒 2 結案不直接呼叫 finalize_assessment 改走 stage advance——接受，理由（流程引擎沒推進、第二份 POA&M）成立。
• 棒 7 runner 改套件 serializer、棒 4 runner 清掉自己夾進棒 2 commit 的重複鍵——都接受，不回頭重做。
• 棒 3／5 可平行（不同 repo）；之後同 repo 平行棒要各開 worktree 或序列派（棒 2／4 撞 index 實踩）。 教訓:
• 同一 worktree 派兩棒＝共用 git index，git add 會互相覆蓋 staged 內容（棒 4 夾進棒 2 commit 13 行）。環境設計問題，派工時就要分 worktree。
• runner 說「好了」不等於已 commit＋回寫（棒 4 第一次口頭說好了，卡還是 Not started）——首腦先 notion get 狀態與 git log 再動手復核。
• 用 shell 位置參數跨子 shell 傳值會丟（PUT C 第一次假失敗）；實打腳本裡的變數要用具名變數。
• audit_scope 不在 ProjectParticipantEntity 上，推進站進站通知噴錯（非本案，記 STATE §4）。 推翻了什麼: 無。 留給下一棒: 派 3／5（卡尾已補接點）；3／5 復核後全案收口。

commits（主工作樹 BE feature/FR-139，未 push）: 0deaf52c3（2／4 復核文件）→ 本 block。worktree BE：0145d2f25、ac17ad2d3（5）。 Notion: 2828 append「✅ 首腦復核」；2826 runner 進行中。 做了什麼: 開檔核棒 5 三支新檔＋接線＋report_head() 重構；守衛 130 passed；8003 被棒 3 佔用且跑舊碼，自起 8006 到 HEAD 實打五格式＋with_findings=0＋壞格式；python-docx 開 docx 驗兩節方向／8 vs 7 欄／不符合底色／表頭重印／第 7 章；pdfinfo 驗 pdf 頁方向；AP 稽核計畫匯出三格式回歸。 決策:

• 報告標題印「第 2 次」判定正確——round 1199 有兩個 pass，序號來自 pass 不是 round_no；不是 bug。
• report_head() 抽共用接受（AP 匯出回歸過）。 教訓:
• 同一個 worktree 平行棒時，8003 上跑的永遠是「最早起的那棒」的程式碼；復核任何棒都要先看 8003 的啟動時間 vs 該棒 commit 時間，不對就自起另一個埠。
• round 的 round_no 與 pass 的 nature_seq 是兩套序號；看到「第 N 次」與輪次對不上先查 audit_round_passes 再喊 bug。 推翻了什麼: 無。 留給下一棒: 等棒 3 回寫復核；之後全案收口。

commits（主工作樹 BE feature/FR-139，未 push）: fc2d4785e（5 復核文件）→ 本 block。worktree FE：a7a64fe3（3）。 Notion: 2826 append「✅ 首腦復核」。 做了什麼: 核棒 3 commit（檔案體積、八個 error code、選單 i18n、路由、border-left）；起 8003（HEAD）＋5181 用 Playwright 登入實開 round 1117a766 深淺色、評估目標頁、報告頁籤、預覽、匯出選單；console 0 errors。決策者裁合回主線 → 三 repo git merge-tree 乾跑：BE 衝突 2 檔、FE 衝突 2 檔（含舊頁改／刪）、套件無衝突；盤點寫進 STATE §3。 決策:

• 左樹 2px 選取左緣判為樹節點指示器（同 FR-141 樹），不違反 3px 卡片禁令。
• 合併時 RoundAuditReviewView.vue 選刪，但主線 T6 的「稽核次尚未開始」處理要搬進新頁；ApPassBreadcrumb 兩個 prop（closedLabel／here）都留。
• 合併順序套件 → BE → FE；合併本身等決策者發令。 教訓:
• 派前補充寫「同專案 round f00c5dc3」是首腦沒查專案軟刪狀態就寫，runner 白繞一圈——測試資料座標寫進卡前要先 SELECT deleted_at。
• 主線在「本案要刪的檔」上又加功能（T6 改舊頁），merge-tree 才看得到；合併前乾跑是必要步驟。 推翻了什麼: 無。 留給下一棒: 等決策者發令合併；步驟與補做事項在 STATE §3 表。

commits: 套件 03fb197b（merge，無衝突）；FE d7cd50f1（merge＋T6 搬新頁）；BE c551f5df4（merge＋兩檔手解＋過期測試改新語意）。主工作樹文件 commit 見本 block 之後。 Notion: 未動（母卡收 Done 等收尾令）。 做了什麼: 決策者裁「等那個 session 一下」→ 監視 BE 主工作樹到乾淨（60b366dfc DI 拆檔落地）→ 依序合套件／FE／BE。BE 合前 stash 別人的 pyproject.toml，合完 pop 回。FE 解麵包屑與舊頁刪／改衝突，把 T6「稽核次尚未開始」搬進 useArResult.js＋新頁，build 過。BE 解報告服務與 reader 衝突，結果工作表加舊頁名 fallback，146 passed，import 檢查過。 決策:

• BE 合併等另一 session commit 完才做，不替它 stash（會讓它那邊檔案突然消失）。
• test_fr141_pass_scope_rule 那支紅判定是 1a 改語意後過期（'pending' token 已不存在），改測試不改規則。
• 013 刪 DEV 113 筆 pending finding 屬資料異動且決策者正用 8000 測 FR-140 → 不自動套，等放行。 教訓:
• 平行 session 在同一個主工作樹作業時，merge 前要先 git status 看有沒有「剛冒出來」的改動，merge-tree 乾跑只看 commit 不看工作樹。
• 主線拆 DI 容器檔時，只要把 provider 以原名重掛回容器，依賴它的新容器（DependenciesContainer）就不用改——合併前先 grep 名稱是否都在。 推翻了什麼: 無。 留給下一棒: 等決策者放行 DEV 補套 013＋seed，重啟 8000 複測；出貨基線 seed 清單首腦未核（STATE §3 第 4 點）。

commits（主工作樹 BE feature/FR-139，未 push）: 22373595e（合併文件）→ abbc33141（worktree 刪）→ 74337a3ec（專用庫刪）→ 本 block 文件 commit。 Notion: 未動；八張子卡停在「修正待驗證」，母卡 CM-2818 等收尾令。 做了什麼: 決策者放行後 DEV 套 013（DELETE 113 pending、UPDATE 90 finding、16 remediation）＋seed（6 列），兩支登記 schema_migrations（013 照套件慣例 packages/jedi_oscal_v2/…，SQL 本身不登記）；8000 重啟實打清單與新端點（舊稽核次 legacy: true）；刪三 repo worktree＋本地分支 feature/FR-142＋空父目錄（確認全併入、無行程佔用）；DROP guidant_ai_fr142（零連線、無設定指向）；重啟正式 8000／5180 到 HEAD；STATE 整檔改寫為「測試→修正」階段。 決策:

• 013 刪 DEV pending finding 屬資料異動，等決策者明令才套（已令）。
• 已併入 feature/FR-139 的其他本地分支（FR-134／135／141 等）不順手刪，只刪本案的。
• guidant_ai_d42 不是本案的庫，不動。 教訓:
• 套件 migration 檔不自帶 schema_migrations 登記，套完要手動 INSERT（第一棒在專用庫做過，DEV 這次差點漏）。
• 8000 重啟後 release hash 不是自己的 merge commit → 先 git log 看是不是別人又 commit 了，不要以為跑錯樹。
• 重啟 FE 由首腦做是決策者當次明令；平時 FE 決策者自理（memory feedback_user_starts_services）。 推翻了什麼: §2「實作在 worktree＋專用庫」裁示隨合併結束，STATE 已改。 留給下一棒: 等決策者 2026-10-17 在 DEV 手測回報；固定處理流程在 STATE §3；三個首腦沒實測的 FE 操作（匯入預覽、結案、現場上傳）最可能出問題。

commits（BE feature/FR-139，未 push）: 729ade180（manifest 補登 seed）→ 本 block 文件 commit（雛形 prototype/my-audits.html＋STATE／LOG）。 Notion: 新開 CM-2836（棒 8，Not started）；母卡 CM-2818 append 追加子卡段。七棒子卡未動。 做了什麼: 接手盤點與 STATE 一致（FE 多一個別案 commit 1da66693 FR-140.C1）。決策者裁 §4 兩項。決策者要求「我的稽核」頁改表格 → 出雛形三輪（表格化 → 加稽核人員欄／搜尋涵蓋人員與性質／狀態可排序 → 風險分高中低方塊）。盤點時發現 FR-142 選單 seed 漏登主線 manifest，補登。開棒 8 實作卡。 決策:

• §4-1 舊端點 close-round 對新稽核次不擋：決策者「舊資料先不管，之後會清一次資料庫」。
• §4-4 進站通知 AttributeError：查證已由 FR-140.14 套件 58836164 修掉，不開卡。
• 「我的稽核」：待覆核列出來（第二個頁籤）；稽核性質顯示但不做篩選下拉、交給搜尋框；稽核人員以稽核計畫 assessor 名單為準（DEV 實查計畫 4 人 vs 專案參與人 2 人不同），空時退專案參與人 auditor；風險改高／中／低方塊不用條狀（風險個位數、條狀看不出比例且與判定色條搶）；逾期標記只標稽核中。
• 首頁 Dashboard「我的稽核」小表本卡不改版。 教訓:
• 雛形跟 proto.css 共用時 class 名會撞（.row 被定義成 flex 讓表格跑版）——新雛形用前綴或先 grep proto.css。
• 安全 hook 擋 innerHTML：雛形改用 DOM 建構小工具 h()，比逐個豁免省事。
• 驗證用的 chrome-devtools 隔離背景分頁決策者看不到，交雛形要另外 open -a "Google Chrome" <url>。
• 主線 manifest 漏登 seed 不會在任何測試紅（DEV 早已手動套過），只在 STG／POC 升級與新裝時靜默略過；收尾盤點要逐支對 scripts/sql/ 新檔是否都在 manifest。 推翻了什麼: STATE §3「出貨基線首腦未核」→ 已核並補登。 留給下一棒: CM-2836 等令派工，prompt：

model：opus／effort：high／理由：前後端＋套件 serializer 跨三 repo，規格已定但要判 fallback 與排序細節
接 Notion 卡 CM-2836 https://app.notion.com/p/FR-142-8-3fc346da4cd08138a714d412801f4a0e ，FR-142 棒 8：「我的稽核」頁改成表格。照卡上規格與雛形做，三個 repo 都在 feature/FR-139 不要切 branch，做完 commit＋回寫卡片不等令。

commits（BE，未 push）: 9f5a146d5／2a14dacb7（雛形改兩輪）→ 2380ff640（改名併入 CM-2836）→ 本 block 文件 commit。runner：BE eee4ac782、FE a4a86f0a、套件 cfe0ce4a。 Notion: CM-2836 卡尾 append 三段規格修正＋「✅ 首腦復核」；狀態維持「修正待驗證」。 做了什麼: 決策者兩度改雛形（進度條難讀→純文字；一格塞太多→一格一值、頂多一行小字，風險拆高中低三欄、稽核次與剩餘天數改小字），頁面改名「稽核作業」（Audit Work）。runner 實作完回寫後首腦復核：開檔核分層、實打端點對 DEV 直查、自寫 headless Playwright 腳本登入 5180 實測中英文、搜尋、排序、hover。 決策:

• 改名只動 FE i18n 值：側邊選單讀 lang.menu.<route name>，不讀 ui_routes；ui_routes.description 不動、不寫 migration。
• 淺色主題橘色貼近紅色屬全站主題 token，不在本卡修，列 STATE §4-9 待裁。 教訓:
• chrome-devtools 的 evaluate_script 讀不到 scratchpad 檔；要在真頁面登入又不讓密碼進對話，用 test repo 的 node_modules/playwright 寫腳本從 .env.e2e 讀帳密最省事。
• log 的 release hash 取的是啟動當下的 HEAD；runner 先改檔、重啟、才 commit 時，hash 會落後一個 commit，不代表跑錯程式——以實打端點有沒有新欄位為準。 推翻了什麼: 無。 留給下一棒: 決策者手測八棒；淺色主題配色待裁。

commits: FE bcaaa4f5（淺色主題配色）；BE 4ffd09f63（STATE §4-9）→ 本 block 交接 commit。三 repo 已 push 到 origin/feature/FR-139（決策者令）：BE c54f1621f..4ffd09f63（含其他 session 的 FR-140／141／143／144 docs 共 32 commits）、FE 1da66693..bcaaa4f5、套件 03fb197b..cfe0ce4a。 Notion: CM-2836 append 配色修正段。母卡 CM-2818 未動。 做了什麼: 決策者令「顏色你直接調」→ 並排比四組候選色後，淺色 --color-orange 改 amber-600、新增雙主題 --color-yellow／--color-blue，稽核作業頁低風險與矯正中改用新 token；headless 實開淺／深色確認。push 三 repo。STATE 整理成交接版（§1 重新盤點、§3 下一步只剩決策者手測、§0 讀序加稽核作業頁座標）。 決策:

• 選 amber-600（白底對比 3.19）不選 amber-700（5.02）：後者並排紅色仍看成紅棕，對比數字好看但沒解決「分不出來」。全站 38 處用法幾乎都是粗體狀態字或圖示，3:1 夠。
• 不改全站 --accent（品牌色），只讓狀態膠囊改用新的 --color-blue。
• 「開始做測試」解讀為決策者手測→修正循環；site-regression 自 10-09 起不是發版 gate，本階段不跑 e2e。 教訓:
• 選色要並排實看，不只看對比數字：對比過關的顏色擺在相鄰色旁邊仍可能分不出來。
• push 前 git rev-list --left-right --count @{u}...HEAD 確認只領先不落後；共用主工作樹 push 會把其他 session 的 commit 一起帶上去，回報時要講清楚。 推翻了什麼: 無。 留給下一棒: 決策者手測八棒→修正。STATE §9 的短 prompt 可直接用。

commits（BE feature/FR-139）: 本 block 文件 commit（雛形 prototype/my-audits-grouped.html＋STATE／LOG）。 Notion: 新開 CM-2850（棒 9，Not started，等令派）；母卡 CM-2818 append 追加段。九張既有子卡未動。 做了什麼: 接手盤點與 STATE 一致（FE 主工作樹有別 session 的 FR-144 未 commit 檔；8000 跑的 commit 之後只有 FR-143／144 文件改動，不需重啟）。決策者第一個調整：參考 FR-145 結案報告清單的「一專案一列、展開看子列」，問稽核作業頁能否同樣分組。首腦出分組版雛形（深淺色 headless 實開、無 console error），決策者裁「直接取代平列版」→ 開 CM-2850。 決策:

• 專案列數字取「目前這一次」（狀態最急、同狀態截止日最近）不取整案累計：風險與不符合是每次各自的，累計會把舊次已矯正的再算一次。
• 只有一次稽核的專案不展開、小字直接寫稽核次：否則專案列與子列一模一樣（首腦第一版實見，自己改掉）。
• 不做「依專案／依稽核次」兩種模式切換，直接取代：平列版多數列本就是同專案不同次，分組後筆數少一半以上。
• 分組在 FE 做，BE my/list 已回 project_uid，不動端點與套件。 教訓:
• 兩層列雛形先用單次專案的資料看一眼：「一專案一列＋展開」套在只有一筆子項的群組上會出現重複列，雛形第一版就踩到。
• 雛形驗證用 chrome-devtools 會撞上別 session 已開的 profile（browser is already running）；改用 test repo 的 playwright 寫 headless 腳本截圖最穩，與第三棒結論一致。 推翻了什麼: 無（棒 8 的平列版欄位規格全部保留，只改列的組織方式）。 留給下一棒: CM-2850 等令派工，prompt：

model：opus／effort：high／理由：FE 單檔但要在 PrimeVue DataTable 與自寫表格間取捨、處理分組／排序／分頁／展開狀態的交互
接 Notion 卡 CM-2850 https://app.notion.com/p/FR-142-9-3fc346da4cd08103a7b5cce0d725a11f ，FR-142 棒 9：「稽核作業」頁改成依專案分組展開。只改 FE，主工作樹 feature/FR-139 不切 branch，FE 工作樹有別人未 commit 的 FR-144 檔只 add 自己的；做完 commit＋回寫卡片不等令。

commits: FE 72708440（runner，棒 9）、FE 88e5f5d5（首腦，enterAudit 帶 ?from=audit-manage）；BE 本 block 文件 commit。FE 未 push。 Notion: CM-2850 append「✅ 首腦復核」；狀態維持「修正待驗證」。 做了什麼: 核 runner commit 不夾帶別人的檔、開檔核分組／排序／展開邏輯、headless 登入 5180 用 DEV 真資料實開（切「全部」、展開、點子列）。決策者回報「從稽核作業點進去麵包屑跑去專案那邊」並令直接修 → 查到 AppBreadcrumb／AppMenuItem 早支援 ?from=、改善計畫清單已這樣帶，稽核作業頁補一行 query；實測麵包屑與高亮都接回。 決策:

• 麵包屑用既有 ?from= 機制不改路由 parent：結果頁從專案總覽與稽核作業兩處進，靜態 parent 只能指一邊。
• 「點舊的那一次子列卻開到該輪目前那次」不在本棒修：my/list 沒回 pass_uid，要動 BE，列待裁。 教訓:
• 用 playwright 進 5180 時，登入後不能馬上 goto 別的頁：token 還沒落地會被打回登入頁並報「無效的 Token」；要等 .layout-menu 出現再走 SPA 內導航。登入頁路徑是 /login 不是 /auth/login。
• 頁面預設頁籤「稽核中」在 DEV 沒資料時是空表，驗證腳本要先切「全部」；這同時也是一個要裁的 UX 問題。 推翻了什麼: 無。 留給下一棒: 等決策者複測 CM-2850 與裁三個待裁項。

commits: FE 60baaf42。 Notion: CM-2850 append 追加修正段。 做了什麼: 決策者裁兩個順帶發現直接修：statusFilter 預設 all、展開鈕 v-if=groupCount。headless 驗一進頁有列、搜不到時鈕消失。 決策: 子列帶稽核次識別那條不順手修——要 BE my/list 加欄位，另開卡等裁。 教訓: 無新教訓。 推翻了什麼: 棒 8 的預設頁籤「稽核中」。 留給下一棒: 同上一 block。

commits: 本 block 文件 commit。 做了什麼: 決策者問「子列開到目前那次」是不是資料問題 → DEV 實查該專案兩條子列是兩個 round，點哪條開哪輪正確；首腦前一則「同一筆資料」的說法撤回。 決策: 真正邊界是「一輪一列」，同輪多次只顯示目前那次；要不要改一次一列待裁。 教訓: 講「某行為有 bug」前先拿真資料點一次看 URL，不要只從「端點沒回某欄位」推。這次的推論鏈（my/list 沒 pass_uid → 子列開錯次）跳過了「子列是不是本來就各自一個 round」。 推翻了什麼: 續 1 block 待裁第 ③ 點。

commits: FE 73369176。 Notion: CM-2850 append 追加修正段。 做了什麼: 決策者質疑四個流程狀態頁籤會讓待辦失焦。首腦查 FR-140 設計確認：稽核人員只有稽核中有事做，矯正中（受稽單位改）、待覆核（等 PM 發起覆核輪，發起後是新的一筆稽核中）、已結案都沒事。改成三頁籤、預設待處理、空表文案指路。 決策:

• 頁籤照「稽核人員要不要動手」分，不照流程狀態；流程狀態留在列上的膠囊。
• 第二個頁籤叫「已判定」不叫「已完成」：矯正中／待覆核那輪稽核還沒結束。
• 預設回待處理，推翻續 2 的「預設全部」——那是被 DEV 沒資料帶偏，不該用測試資料定產品預設。 教訓:
• 決策者第一次說「三項就好」時，首腦先提了四項（多一個等待中），被退回「你要想過」。多拆的那一項沒有對應的使用者動作，就是多的；分類前先問「這一類的人要做什麼不同的事」。
• 「空表看起來像壞掉」要用空表文案解決，不是改預設頁籤。 推翻了什麼: 續 2 的預設頁籤「全部」。 留給下一棒: 改善計畫、稽核計畫清單頁也是照流程狀態分頁籤，要不要比照待決策者看過本頁效果再說（FR-143／144 首腦）。

做了什麼: 決策者點名「講過很多次不要開視窗出來測試」。本棒交分組雛形時用了 open -a \"Google Chrome\"，照的是第三棒（續 0）教訓欄那句「交雛形要另外 open -a」。 推翻了什麼: 第三棒 block 教訓欄「驗證用的 chrome-devtools 隔離背景分頁決策者看不到，交雛形要另外 open -a \"Google Chrome\" <url>」——作廢。交雛形只給網址，決策者自己點；任何會在桌面開瀏覽器的指令一律不用。STATE §7 已改寫、memory feedback_runner_tests_headless_only 已補。 教訓: LOG 的教訓欄會被下一棒當規則照做；寫進去的「做法」若違反決策者既有規則，等於把錯誤制度化。寫教訓前先對一次 memory。

commits: FE 081ee5b5。 決策: 決策者裁第二個頁籤叫「已完成」。首腦原先擔心會被誤讀成「整輪稽核結束」而取名「已判定」，決策者看了覺得不直覺；頁面是稽核人員自己的待辦清單，「已完成」指的是自己的工作，語境夠清楚。 推翻了什麼: 續 4 的「不叫已完成」。

commits: FE aaf27484。 做了什麼: 決策者問「沒有分頁？」。棒 9 runner 照卡做了分頁但條件是「超過 10 個專案才顯示」，DEV 只有 2 個就藏了。改照改善計畫／稽核計畫清單：有資料就顯示，加每頁筆數下拉。 教訓: 卡上寫「分頁每頁 10 個專案」沒寫「何時顯示」，runner 自選「超過一頁才顯示」。同站的兄弟清單頁已有做法時，卡上要直接寫「照某頁」，不留給 runner 選。

commits: FE 2c79a437。 做了什麼: 決策者要求分頁跟待辦任務頁同一個樣子。全站盤點：20 支清單頁用 DataTable 內建 paginator（同一個 template、lang.pager.desc、10/25/50），外掛 Paginator 的只有 8 支（含本頁與 FR-143／144／145 三頁）。本頁表格已是 lazy，加 paginator 並 totalRecords＝專案數即可，子列不算。 推翻了什麼: 續 7 的外掛 Paginator。 教訓:

• 「對齊兄弟頁」要先問兄弟頁本身是不是對齊全站。續 7 照改善計畫頁抄，但改善計畫頁自己就不是全站標準；先 grep 全站多數寫法再抄。
• 看共用檔有沒有別人未提交的改動要用 git diff HEAD，不是 git diff（後者比的是 index；別的 session 已 add 的會被當成未提交）。本棒差點因此誤判已 commit 的版本有 bug。 留給下一棒: 改善計畫、稽核計畫、結案報告三頁也是外掛分頁，已寫在 CM-2850 卡尾，歸各自首腦。

做了什麼: 決策者令找出前後端並重啟。找到 BE API（8000）、BE worker（跑了一天多）、FE vite（5180），都在主工作樹；全部 kill -9 後背景重啟，健康檢查通過、log 無錯誤、release hash＝當時 HEAD。決策者預告 FR-145 完成後要全面測試，首腦判斷 context 已長，交接給新 session。 決策: 只管稽核作業頁（決策者裁：改善計畫／稽核計畫／結案報告三頁的分頁對齊已發給各自首腦做，本案不動）。 教訓:

• lsof -iTCP -sTCP:LISTEN | awk '/:(8000)\b/' 在 macOS 抓不到（awk 的 \b 不是字界）；查埠用 lsof -nP -iTCP:8000 -sTCP:LISTEN。第一次查誤以為服務都死了。
• 背景重啟用 nohup python main.py > <scratchpad>/x.out 2>&1 &，輸出別寫進 repo；worker 要另起一支 RUN_MODE=worker。 留給下一棒: 全面測試。§3 有稽核作業頁定案長相，以及「並排看分頁」一點。