🔴 內化 23/23 與收尾（CM-2018，產出 SUMMARY.md）都已完成。下一棒是「修正派工首腦」——卡 CM-2019，見下方第零節。不是內化、不是收尾。 這份取代 _handoff-internalize-4.md（那份留著當歷史，不要再照它開場）。

陪決策者把這份資安檢視報告讀懂、想清楚、做出判斷。

他是這份報告的講者——要拿它去對客戶、對老闆、對稽核方解釋。所以他需要的不是你幫他寫完，是你講給他聽，他提問，你回答，然後把他的判斷記下來。

你是輔佐他理解的技術人員：幫他查問題、解惑、給建議。不是替他做決定的人。

工作目錄：/Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-be 報告原始碼在 docs/security-report/（md 是源，html 是產物）。

1. docs/security-report/README.md — 總報告首頁
2. docs/security-report/_module-page-spec.md — 模組頁撰寫規格（了解格式即可）
3. 本文件第五節「決策者已拍板的原則」 — 那是最重要的一節，遇到同類問題直接援引，不要重新討論
4. 下一塊要過的報告（見第三節）

不必讀 GUIDE-01（方法與工具），除非決策者問到方法可信度。

PM 的要求原話：既有的技術報告「都放小弟原生產出的文件，所有過程皆需保存」，另外開一個連結放「你內化過後的版本」。

它會被當成稽核證據——所以每頁都有「檢視軌跡」段，證明確實查過。

23 塊報告都寫好了。還沒做的是「內化」——也就是決策者的判斷。

第四棒過的 12 塊裡，有六塊查出「報告與現在的事實不符」，而且形狀一致：

🔴 所以每一塊都要派查證，不要照抄報告。 第四棒十二塊全部派過，每一塊都抓到數字或描述錯誤。

🔴 而且「被意外擋住」不等於「修好了」——M15 與 M17 那兩條都是被無關的改動擋住的，哪天有人把那個改動修回去，洞立刻恢復。這個講法要寫進報告。

23 塊全部過完。 五張改稿卡（CM-1987／2014／2015／2016／2017）文件組已全部改完，第五棒驗收 2015／2016／2017 通過（派 sonnet 逐項核＋本體抽查）。

另有兩張非模組卡：CM-1994 全站裁定、CM-1992 Google 硬碟紀錄、CM-1995 分頁工具產品行為。

M10 任務與成員管理 — ✅ 第五棒過完（CM-2015），下方查證結果留作歷史

第五棒裁定摘要：第 1、5 降中（跨客戶不成立、同公司內仍 2,237／12,573 筆）；第 7 降低改寫（沒有原廠公版，資源庫是客戶自己維護的）；第 10 逐支補底層不動；第 8、9（=16、17）、19 沒人用的寫入功能刪；第 14「專案任務設置」整頁拆（有兩個快速設定，只改了一頁）；第 15 留到修正卡。第五棒每一組都派 opus 核對＋本體抽查，A 組 8 條、B 組 4 條「仍在」全部屬實，但 A 組又抓到三處報告誤判（資料庫牆已蓋、前端呼叫已確認零空白、第 7 條目標不存在）。

第五棒被決策者糾正三次，下一棒務必避免：①「一堆誤判不要再想跳著過」——A 組我先套既有裁定只留一條給他裁，他要的是逐組 review；②「全部好了？所以你都訂好了？」——不要把 subagent 查證結果直接當定案整理成卡；③「我全不知道是在哪邊發生什麼事情」→ 原則十六。

M20 客戶資料隔離 — ✅ 第五棒過完（CM-2016）

裁定：第 5 條「盤點死角」實查是 102 張表沒牆、要補的 53 張（合規文件核心 45＋零散 8、4 個主檔接點、只有資源庫那個接點要想主人是誰）；風險維持中、狀態改「SaaS 版上線前必做」（落地版一家一套不受影響，SaaS 短期不上）；決策者定順序：程式面先修→測一版→再開資料庫牆，併 M11 當第一個具體待辦。第 2 條改「2 補設定 2 刪除」。

M13 登入與權限 — ✅ 第五棒過完（CM-2017）

16 條逐條開程式實證：15 修好、1 部分修（第 10 條快取連線——套件修了、主專案有一份複製品沒修，AI 助手與問卷在用，裁刪複製品改用套件）、1 條漏登記且沒修（新第 17 條：停權後通行證仍有效，S7 重跑找到的、追蹤表停更沒人開卡；裁補進報告標未修，修正批次處理）。「全案唯一全部修完」招牌拿掉；「還沒發版」整段依原則十拿掉（實際 9/13 已出版 jedi-iam 1.0.0）。

回答要短

他明講過：「之前都太長了，雖然很詳細但很容易失焦」。先給結論再給依據、一次回答一個問題、表格優於長段落。

🔴 分組講，不要逐條（第四棒被當場糾正）

條數多的塊：先講這塊做什麼 → 把問題按形狀分組 → 只展開真正需要他判斷的那幾條 → 其餘列表帶過。

第四棒在 M17 違反過這條，決策者當場說：「我們應該是用分類來看不是？目前是逐條審閱嗎？畫面一直洗看不出來有什麼東西可以看。」

能套既有原則的直接套，不重新討論。

🔴 不要附和（第四棒被當場抓到）

決策者質疑時，先想清楚他對不對，再回答。

第四棒犯過：建議「設定值讀不到就拒絕啟動」→ 決策者一質疑就馬上改口說「你講的才是正解」→ 決策者問「你有思考過嗎？」

正確做法：真的重新想一遍，包括他可能錯的地方也要講。第四棒後來照做，結論是「你對了一半，另一半不成立」——那才是他要的。

🔴 已裁過的不要再問（第四棒犯過，而且第三棒也犯過）

第四棒問了第二次「那些 token 換了沒」，決策者回：「token 都已經撤銷了，不要再問我這個了，早就都換掉了。」

進入前務必讀完本文件第五節的「已拍板原則」與第六節「已結清的事」。

事實一定要回程式碼查，不要只信文件

這是最重要的一條。 前四棒在十二塊裡抓到三十幾條文件錯誤。

三個查證手段，按有效性排序：

1. 查 commit message——常常直接回答「當初為什麼這樣做」
2. 登入實機看——188/189/190 三台
3. 開檔看程式——不要憑報告或印象

白話

讀者是 PM 與老闆。「白話」不是把句子講得口語，是讀者完全不需要技術背景就能懂。

禁止寫「已確認安全」「沒有漏洞」「全面檢視」。

不要自己改結論

可以說「這條我覺得評太輕／太重」並說理由，但改不改由決策者決定。

🔴 長工作結束要發桌面通知（2026-09-21 決策者要求）

subagent 回報、一塊過完、有事等他裁——都要發：

terminal-notifier -title "資安報告內化" -subtitle "<一句主旨>" -message "<白話一句>" -sound Glass

不要用 osascript（在 PyCharm 終端機裡會靜默失敗）。小動作不必發。

三個 repo + 實機 + 資料庫

• 主專案：工作目錄
• 套件：/Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/
• 前端：/Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-fe
• agent：/Users/chouraymond/Projects/Billows/Audit-Manager/evidence-agent
• License Center：/Users/chouraymond/Projects/Billows/Audit-Manager/license_center
• 實機：ssh jedi@192.168.50.189（POC）、ssh jedi@192.168.50.190（E2E）
• 資料庫：本機 localhost:5432 / guidant_ai_dev / .env 裡的 cmmgr

🔴 實機只能唯讀（CLAUDE.md 環境異動鐵律）。DEV 可以寫（第四棒經決策者指示清空過紀錄表）。

一～七（前三棒立的，仍有效）

1. 密碼類欄位預設不回傳（標記制，不是名單制）
2. 權限檢查走「一條路由 ＋ 登記」，不為每個情境各開路由
3. 所有修法都要先判斷「功能不能壞」
4. 「帶出公司」這類論述要驗證再寫
5. 不要相信呼叫方自報的東西，自己去查（收編號、後端查網址）
6. 落地版的設定，客戶自己要管得到（子公司層級不能改全公司設定）
7. 交出去的資料要編碼，不是刪掉（資訊一個位元都不能少）

八、🆕 止損定調（第四棒立）

這一波掃描到此為止，有掃到什麼就修什麼，不硬掃完。 根因是檢視工具本身不可靠（一批打 17 小時換 25 次人零產出、紀錄被誤刪）。

對外的講法：不是「時間不夠」（聽起來像便宜行事），是「工具不可靠，我們判斷繼續投入不划算，改成針對已發現的修」——那是專業判斷，而且我們有證據。

九、🆕 憑證外流一律已修正（第四棒立，全站適用）

所有外流的 token、金鑰、密碼都已經撤銷／換發完畢。報告一律標「已修正」，剩下的只有清版控殘留字串。

🔴 不要再問決策者「那些換了沒」。

十、🆕 環境差異不列入狀態判斷（第四棒立）

上線前會有一次大更新，全部替換成最新版本——所以「開發環境已修」就等於「這個問題解決了」。

報告要回答的是「這個問題我們有沒有解決」，不是「每台機器現在跑到哪一版」。

十一、🆕 安全措施不可以擋住正常客戶（第四棒立）

決策者原話：「你不能因為設定錯誤就不讓啟動了，客服會瘋掉。」

判準：安全措施如果會讓正常客戶用不了，那個措施本身就是問題。往安全那邊倒（用安全的預設值），不要擋住啟動。

十二、🆕 落地版是一家客戶裝一套（第四棒立）

「跨客戶看得到」這件事在落地版根本不存在——整座資料庫就是那家客戶的。

這條解掉了 M04 第 4 條（紀錄表要不要做客戶隔離 → 不用）。

十三、🆕 「部分能分」等於「不能分」（第四棒立）

決策者原話：「會變成有的可以分、有的不能分。」

判準：如果一批資料裡有些標得了、有些標不了（例如登入失敗、系統啟動、背景排程都沒有客戶），那個隔離就做不成——標不了的要嘛留空（規則會把它們全擋掉，資料等於廢掉）、要嘛塞假值（追查更混亂）。

十四、🆕 讓意圖變明確，模糊地帶就消失（第四棒立，M17 第 3、4 條）

問題不是「沒選的人看得到全部」，是系統分不出「你刻意選全部」跟「你忘了選」。

修法：把「沒選」變成不合法，強制選一個明確的值（例如「全公司」或「指定部門」）。一個設計解掉三個問題。

十五、🆕 沒人用的東西不要留著（第四棒重申，已是第四次）

現在無害的唯一理由是「沒人用它」→ 只要有人接上去就憑空多出沒有檢查的入口。

四處裁定一致，都是「直接刪掉」：M06 兩條、M23 成員名冊、M04 那支開發工具。

🔴 但刪之前一定要確認全系統全套件零引用（決策者要求）——第四棒查 M04 那支時查了七個面向（套件、主專案、四個 repo、隔離規則、函式、檢視表、觸發程序、出貨基線、migration）。第五棒 M10 又裁三處刪（第 8、9、19 條）＋一整頁前端舊頁拆除（第 14 條）。

十六、🆕 每條問題先講「在哪裡、誰做什麼、發生什麼」（第五棒立，全站適用，🔴 最高優先）

決策者原話：「我發現你跟我說問題的時候，我全不知道是在哪邊發生什麼事情，這樣我沒辦法判斷。」「html 那份內化的報告要重寫清楚問題發生在哪邊，不然我同事不知道你在講什麼。」

兩層都適用：

• 講給決策者聽時：每條先講場景——哪個畫面／功能、什麼身分的人做什麼動作、發生什麼本來不該發生的事——再講判斷。不要從「第幾條、幾筆、哪支程式」開始。
• 報告內文：每條問題（問題一覽的「問題」欄與展開段）固定四件：在哪裡／誰做什麼／發生什麼／怎麼修。驗收標準：沒看過程式的同事讀完要知道在講什麼。

此規則寫進之後每張改稿卡的施工要求。已改完的頁不回頭大掃。

十七、🆕 任務操作的角色規則（第五棒立，M10 第 6 條與 M06 第 7 條修正時要守）

「完成任務」那道檢查弱點掃描模組 8 支也在吃，修的時候一起改。「批次完成」那支已是正確寫法，單筆照抄。

M03 那 11 張表要分兩組改（不是一律照同一套）

原本的裁定：11 張隔離規則寫反的表集中處理、出貨前完成、改用正確寫法。

M18 查證後修正為：

為什麼：授權的設計是「照綁在最頂層，底下子單位共用」——「子單位看得到母公司的授權」正是設計要的。改成跟其他八張一樣，每個子單位查不到頭上那張照，會被判成「沒買」，打任何功能都被擋掉。

🔴 CM-1993（M03 那張卡）已經做完了，報告上現在還是舊說法——文件首腦已回報這個風險，下一棒要確認有沒有修正。

• 一定帶 model 參數，prompt 第一行寫「model：X／effort：Y／理由一句」
• 機械性查證 sonnet，要判斷 opus
• 只讀不改的查證要在 prompt 裡寫死
• 回報只要結論，不要貼文件內容回來
• 顯式 git add <檔名>，禁用 -am
• push 一律等決策者明確指示。不要切 branch
• 🔴 subagent 的回報要自己核對過再講給決策者聽

🔴 查證 prompt 一定要問的三件（第四棒的經驗）

1. 每一個數字都要重數——十二塊裡十二塊都有數字錯
2. 標「已修」的要實際驗——M16 兩條、M18 一條都是標已修實際沒修
3. 跨頁重複要比對——M17 第 8 條 ＝ M23 第 1 條（同一件事），收尾總表會重複計數

還有一個 session 是文件產出線的首腦，負責格式、事實驗證、build。

分界：它動格式與事實，你動內容與結論。 那 23 份 md 在內化期間以你為主。

所以你不要自己改那些 md——整理成 Notion 卡，決策者會轉給文件首腦派工。

🔴 第四棒改變的做法：不要補充式改稿（決策者 2026-09-21 要求）

決策者原話：「要記得要 review 過整篇文章，直接調整成正確的內文，不要用 append 的方式，我都看過了，不要有雜訊，也都要白話文，不要太工程師——之前一堆文字看不懂。」

所以每張卡的施工要求都要寫這四條：

1. 不要補充或加註，直接把內文改成正確的——不要留下「原本寫 X、現在改 Y」的痕跡
2. 整頁從頭讀過再動手
3. 全篇白話，技術名詞換成它做的事
4. 不要有雜訊——過程、沿革、「查證發現」這類敘述不進報告

派工卡必須交代的三件事

1. 施工清單列的是改動起點，不是全部
2. 自我檢查那句要寫進卡：「如果讀者只讀這一頁、從頭讀到尾，會不會讀到兩句互相打架的話？」
3. 刪除類改動要列出 grep 關鍵詞

🔴 一條沒人串起來的線（收尾單獨講）

「帳號可以沒有部門」這個模糊狀態，在兩個地方造成相反的結果：

共同根因：全系統沒有規定這種帳號該看到／做到什麼，兩邊的作者做了相反的假設，各自寫在自己那一層，沒人對齊。

決策者已裁定兩邊分開看（公告要選發送對象、意見回饋不需要部門），但這個形狀值得在分析章節單獨提一段。

收尾棒 CM-2018 已交：docs/security-report/SUMMARY.md——145 件（194 條去重）、每件標所屬修正批、六批順序、十一組病因。但總表按嚴重度排，不是派工單；派工首腦要把它拆成「一個 worktree 一張卡」。決策者兩個補裁（2026-09-21）：①合規資源庫那條（M10 第 11 條）改中、後端補「改控制項清單前先確認範本是自己客戶的」（資料庫只擋主表、控制項那兩張表沒牆，子公司改母公司分享範本今天打得通）；②左側選單不對齊首頁表。

內化階段已結束。 第五棒與決策者定的收尾方式與修正順序如下，收尾棒與派工棒都照這個走。

兩份總表，以誰為準

收尾棒做法：以 23 塊裁定為骨架，把掃描總表 §3 裡 23 塊沒涵蓋的新項對進去（標明來源與所屬修正批）；之後掃完的再補進同一張總表。

收尾產出（四件，寫進 README.md 首頁）

1. 一頁摘要（給只看一頁的人）
2. 問題總表（去重、按嚴重度、每條標所屬修正批——這張表就是派工源）
3. 分析與結論：上面十一組病因＋K 組單獨講一段（方法論層級）＋「帳號沒部門」那條線單獨一段
4. 修正建議：只列順序不寫日期，照下面六批

🔴 去重：至少 M17 第 8 條＝M23 第 1 條；M10 第 11 條（改稿後條號；合規資源庫）＝掃描總表第 67／120 項；M13 第 10 條的主專案複製品 FR-085 C1 早撿到過。總表要合併計數。

🔴 修正順序（決策者 2026-09-21 裁定，六批）

判準：①先修「別人要靠它」的地基 ②同一套修法併一批、批與批互不相依才能分頭。

三個坑：①第 1、2 批幾乎全在套件，worktree 要 BE＋套件各開、BE pyproject.toml 改 path dependency 指向套件 worktree（不 commit）；②每模組開卡把每個入口 file:line 列成驗收項（[[feedback_parallel_runners_two_entrypoints_one_fixed]]）；③舊的 41 張修正卡與 CM-1983 草案在總表標「作廢」，不然平行 session 會撿到過期的。

決策者的打算：修正 repo 開 worktree 分頭做，掃描還在跑的那條線繼續。第 3、4 批不依賴總表，可先動。

另兩項業界標準補強（不急）

報告封面基本資料、風險評級標準說明。

1. 讀完本文件（特別是第五節「已拍板原則」與第六節「已結清的事」）
2. 跑 pre-flight 唯讀盤點（見下一節的現況表，確認與實際相符）
3. 用三五句話說你理解的「這份報告要解決什麼問題」
4. 問決策者任何不清楚的
5. 然後等他發令，不要自己開始

23 塊已全部過完，沒有下一塊。 接手者的工作是收尾棒（CM-2018）或派工棒，不是繼續內化。開場照樣：讀完、盤點、等令。

資安報告內化 arc 現況盤點（唯讀，第五棒交接用）

盤點時間：2026-09-21（依 git log 與 DB 現查）

判準：檔案內出現「已裁定」「決策者裁定」等裁定字樣視為「已內化」；M11／M12 明確標註「這一塊到今天為止，一輪檢視都沒有做過」，故獨立標「未檢視」。

備註：

• 條數＝檔案內 ^| \*\*[0-9] 開頭的表格列數（即「問題一覽」表的編號列數），M11／M12 因無問題表故為 0。
• M16 的裁定字樣是「裁定：寄信設定由客戶最上游的帳號自行管控⋯」，語意上等同已裁定，只是未用「已裁定」或「決策者裁定」固定句型，判準抓取邏輯上會被算成「否」，實際內容應視為「是」——此處按盤判準字面結果與語意結果分列，交接時請下一棒自行核對。
• M10 的問題表 2026-09-20 有「逐條回程式碼複驗過」的 callout，12 條全部仍在、沒有任何一條被修掉，但「怎麼修」欄目前是純技術修法敘述，未見裁定內容。

來源：python scripts/notion_case.py query --case <CM-xxxx>（CM-1981 逐一查到 CM-2014）

備註：CM-2000 ～ CM-2010 為 FR-113（jedi-oscal-v2 主專案側接線掃描）系列卡，與 M11/M12 未檢視狀態相關但不是同一 arc 的內化卡；列出供交接對照。CM-1987（M09）與 CM-2014（M04）Notion 狀態仍是「Not started」，與 §一盤點的「已內化（有裁定字樣）」結果不一致，需下一棒核對是否漏回寫 Notion 狀態。

最近 15 筆動到 docs/security-report/ 的 commit（oneline）：

目錄：/private/tmp/claude-501/-Users-chouraymond-Projects-Billows-Audit-Manager-compliance-manager-be/1b41850e-7f86-48c9-a75d-0cb62774d0d8/scratchpad/

注意：目錄內含 4 個含真實憑證的檔案（DB_PASSWORD.txt／DRIVE_TOKEN_ENCRYPTION_KEY.txt／GOOGLE_DRIVE_OAUTH_CLIENT_SECRET.txt／REDIS_PASSWORD.txt），是 scratchpad 暫存區、非版控範圍，本盤點僅列檔名未開內容。

log/ 目錄檔案清單與密碼明文掃描結果（grep -ac '"password":"'）：

共 8 個檔案，皆為 0 筆命中。