文件首腦交接（第二棒 → 第三棒）

你是文件產出線的首腦。決策者（講者）下指令給你，你分析、判斷、派 subagent 執行、驗收 subagent 的產出。

另一條線是「內化首腦」——陪決策者逐塊讀懂報告、釐清問題、記錄他的判斷，產出是 Notion 卡。

分工：內化那條線產出「要改什麼」的卡片 → 你負責把卡片落實進文件、驗證事實、管格式與 build。

索引表的順序就是閱讀順序（按嚴重度）。已完成的九份不在待辦內，下一塊照索引表往下走。

第二棒處理過的卡（全部已 commit、已回寫 Notion、狀態「修正待驗證」）

未 push——全部等決策者明確指示。

1. 內化首腦跟決策者過完一塊 → 開一張 Notion 卡（含逐條更正、決策、施工清單）
2. 決策者把卡號轉給你
3. 你讀卡片全文：python3 scripts/notion_case.py get CM-XXXX
4. 自己先查證關鍵事實——特別是「報告寫錯了」這類，那是要寫進稽核報告的
5. 派 subagent 執行，驗收回報
6. 有需要決策者裁定的，先問，不要替他決定

一、不要只信文件，要回程式碼驗

決策者質疑過「應該不是整份從 feature 複製下來吧」。那之後改成每條發現都要回程式碼確認，結果抓到六處總表寫錯或過期：

• 一條已修的被記成未修（稽核輪次的簽核權限）
• 一個查不到出處的數字（原記「122 支入口零權限檢查」，重數 89）
• 一條實測數字已歸零（客戶資料隔離當年 39／213 筆，重測全 0）
• 一條總表記未修、實際已修（日誌保存期限）
• 一處持有者人數不符（原記 8 個、實查 9 個）
• M08 一句稽核方查得出來是錯的評級理由

二、curl 拿到 200 不代表頁面存在

文件站的 404 fallback 回的是首頁、狀態碼 200。我曾因此得出完全相反的結論（「密碼一頁都沒外洩」，實際是 33 頁全部外洩）。

正確驗法：curl -sL（跟隨轉址）＋ 加 cache-buster ＋ 比對 404 fallback 的 md5。

三、subagent 讀大檔會爆 context

有一棒因為整包讀大檔失敗（autocompact thrashing）。派工時要寫明：用 sed -n 分段讀，不要整包 cat。

四、工作樹有別人的未提交變更

派工單必寫：顯式 git add <檔名>，禁用 -am。

五、🔴 卡片本身會寫錯——關鍵數字一定要自己開程式碼驗（踩了三次）

內化那條線的卡片是人寫的，數字會錯。第二棒三次抓到：

判準：凡是會寫進報告、會被稽核抽查的數字（幾支端點、幾張表、幾個檔案、幾個角色），自己 grep 或開檔數一次，不要讓 subagent 照抄卡片。派工單要明寫「用這個實數，不要用卡片的數字」。

六、🔴 卡片會在你做完之後追加節次——讀卡要讀全文

CM-1985 做完後追加第七節、CM-1989 做完後追加第八、十節。只看「給文件首腦的施工清單」會漏掉。

做法：python3 scripts/notion_case.py get CM-XXXX 之後，先 grep 全文看有幾個 ## 節次，確認施工清單是不是最後一節。決策者轉卡號給你時說「處理第十節」，也要順手看看第八、九節是不是也是新的。

七、runner 紀律三件事，Notion 回寫最容易漏

做完卡片要做三件：① 顯式 git add ＋ commit ② Notion 子卡 append 白話補充（做了什麼／commit hash／驗證方式）③ 子卡狀態改「修正待驗證」。

第二棒前三張卡只做了 ①，後來補回寫。漏掉 ②③ 的後果：決策者看不到進度、平行 session 拿到過期世界觀。派工單沒寫這三件也要做，那是 runner 鐵律不是選配。

• 模組頁規格：docs/security-report/_module-page-spec.md（五段結構、七欄定義、十種分類、白話禁用詞表、自檢清單）
• 白話標準：讀者是 PM 與老闆。「白話」不是把句子講得口語，是讀者完全不需要技術背景就能懂
• 禁止寫：「已確認安全」「沒有漏洞」「全面檢視」——我們的方法不能宣稱這個
• 不要寫進實際值：帳號名、位址、埠號、私鑰——講類型即可（這份之後要收斂成對外版）
• build：python scripts/deliverables/render_index.py docs/security-report/ --site-root docs/security-report/

一、側欄順序與索引表不一致

索引表按嚴重度排，側欄按檔名編號（M01～M23）排——編號是當初派工分批給的，與嚴重度無關。

重編號的對照表已算好，但沒做，因為：① 內化過程中嚴重度還在變（已有兩條改判）② 改名會撞到正在跑的修訂。建議內化全部完成後一次做。

二、收尾章節

23 塊都過完才寫得準：

• 一頁摘要（首頁最上面，給只看一頁的人）

• 問題總表重整（141 條按嚴重度重排，現版在 docs/features/security-scan-consolidated/risk-overview.md）

• 分析與結論——跨模組的問題型態，內化至今累積七組：

  • A 組「只驗登入、不檢查歸屬」（最大一組，M05 一塊就貢獻七條）
  • B 組「鑰匙掛在牆上」（密碼進版控、進公開文件站）
  • C 組「想到了，只做了一半」（M01 第 1 條、M02 第 5 條、M05 問卷、M08 第 2 條）
  • 「信任鏈的起點沒人守」（M08 第 1 條，驗證工具自己不在被驗證範圍內）
  • 「客戶層級的權限，改到的卻是全系統共用的那一份」（M22 第 1 條 ＋ M09 日誌，已裁定兩條套同一條規則）
  • 「宣告了權限，只有畫面在認」（M03 第 8 條、M19 第 1 條都已裁定後端補檢查；M23 意見回饋尚未裁）
  • 「東西寫對過，但被重做的時候沒跟上」（M06 套件有檢查、主系統重寫的漏了；M08 代理程式那頭三層、我們這頭零層）
  • 🆕 正面對照組（M19）：它的守門是「吵鬧拒絕」——少了必要零件直接拒絕啟動、錯誤訊息還寫明後果。與另一塊「零件沒接上就靜默放行」正好相反。收尾講「同樣的問題為什麼有的塊有、有的塊沒有」時，這是最好的對照

• 🔴 〈檢視方法與工具〉要補一段（CM-1994 第五節建議，第二棒未做——屬收尾範圍）：內化第四棒逐條開檔查證，抓到 18 處報告與事實不符（M05 4 處、M07 8 處、M03 6 處），每一塊都至少有一處會誤導施工或誤導判斷。這不是「報告寫得爛」，是工具產出的價值在「指出哪裡要看」，不在「結論可以直接用」——與止損裁定是同一個故事。在稽核場合是加分的：它證明我們不是把工具輸出照單全收，每一條都有人回去開檔核對過。

• 修正建議（只列優先順序，不寫日期——時程是決策者跟 PM 排的）

三、業界標準的兩項補強（不急）

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

一、報告定位改了：這是「出貨前的最後檢查」

產品從未出貨給任何真實客戶。 已寫進首頁最前面（CM-1988）。141 條問題全部沒有影響過任何一個真實客戶。

🔴 判準（最容易做錯，第二棒花最多篇幅在這件事）：這不是「把所有講到密碼外流的地方都改掉」。每遇到一句先問：

這個東西是「隨產品出給客戶的」，還是「我們自己在用的」？

• 隨產品走的 → 沒出貨就沒外流過 → 改
• 我方自有基礎設施（公開文件站、程式碼倉庫、我們自己的測試機／展示機、內部套件倉庫）→ 與出貨無關、曝光可能真的發生過 → 不改，嚴重性一字不動

目前保住未動的五條：M15 第 6 條、M17 第 8／10 條、M23 第 1 條、M16 第 7 條。M01 第 5 條另加了一句聲明「與產品出不出貨完全無關，嚴重性不降」防止被誤讀。

二、本輪掃描止損定調（CM-1994）

舊講法「是時間與資源的取捨」已全站清除（首頁、M10、M11、M12、GUIDE-01）。新講法是：

檢視工具本身不可靠，我們判斷繼續投入不划算，改成針對已經發現的修。

差別在於——舊講法聽起來像便宜行事，稽核方會追問「那為什麼不多給時間」；新講法是專業判斷，而且我們手上有證據（17 小時換 25 次人零產出、紀錄被誤刪、派三位回一位）。

接手後若看到任何一頁還寫著舊講法，那是殘留，要改。

三、程式行號已全站拿掉，只留檔名

決策者裁定（CM-1988）：讀者是 PM、老闆、稽核方，他們不會去對行號；要對行號的工程師看需求中心的原始技術報告就有。留著只會過期，稽核方拿著對不上的行號來問是扣分的。

• 資料庫密碼散在 249 個版控檔（66 個在會發佈的目錄，33 個網頁線上可見）——決策者裁：該站之後用存取限制擋住、密碼是內部開發用、會換密碼。已知問題，不用再提
• M08 第 4 項（行號失效）——已裁定並執行（CM-1988）：全站拿掉程式行號只留檔名。實際範圍遠小於預期，23 頁只有一處