本卡屬 FR-120（母卡待填）。這是一張實作卡（寫一支腳本），不是掃描卡。U13a／U13b 兩棒要帶著這支腳本的輸出結果去派。

問題是什麼（白話）

主專案用一套叫「依賴注入」（DI，Dependency Injection）的機制組裝程式：每個服務（service）在自己的程式裡宣告「我需要用到哪些零件」（例如需要一個「檢查權限」的零件），另外有一批「容器」設定檔負責在系統啟動時把這些零件實際接上去。如果容器設定檔忘記接某個零件，服務本身完全不會報錯——它只是拿到一個空的或錯的零件，然後在執行時默默地跳過該做的檢查。這種「少接一條線」的問題，過去已經抓到至少兩次真實案例（合規稽核套件與 SSP 套件都出現過），而且掃描工具找不到這種問題——工具擅長找「程式邏輯寫錯」，不擅長找「應該要有卻沒有出現的東西」。這張卡要寫一支腳本，把 75 支容器設定檔全部讀過一遍，自動列出「哪個服務缺了哪個零件」。

在哪裡

/Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-be/di_containers/          # 各模組的容器設定檔
/Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-be/core/plugins/             # 套件接線
/Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-be/config/di_modules.py     # 自動掃描要 wire 哪些模組
（共 75 支、11,062 行，扣除 0 行的 __init__.py）

怎麼修

• ① 寫 scripts/security/di_wiring_audit.py：用 Python 的 AST（抽象語法樹，程式碼結構化解析後的樹狀資料）解析每個 service 類別的 __init__ 建構子，列出它宣告需要哪些參數（含有沒有預設值）。
• ② 同一支腳本再解析 di_containers/ 與 core/plugins/ 裡所有 providers.Factory(...) / providers.Singleton(...) 呼叫，列出容器實際傳了哪些參數給每個 service。
• ③ 兩份清單比對，輸出「這個 service 宣告需要 X 個參數，容器只接了 Y 個，缺的是哪幾個」。特別標紅參數名稱裡含 guard／perm／checker／authz／role 的缺漏（這些通常是安全檢查零件，缺了影響最大）。

先查再寫：這支是全新腳本，scripts/security/ 目錄如果已有同類工具（AST 解析、DI 稽核）先確認沒有重複造輪子；dependency-injector 套件的 providers.Factory／providers.Singleton 用法可參考任一支既有容器檔（例如 di_containers/containers.py）。

要寫測試

• --self-test 旗標：腳本要能自我驗證——挑一個已知「刻意拿掉某個參數」的假案例（可以是腳本內建的假 service 類別＋假容器程式碼字串），跑 --self-test 時腳本要能正確抓出這個刻意製造的缺漏，抓不到就要讓腳本用非 0 狀態碼結束。這是本專案測試政策的例外（核心共用邏輯：資安掃描的比對邏輯本身），要寫。

手測

• 在 DEV 環境跑一次：python scripts/security/di_wiring_audit.py，把完整輸出存成 docs/features/FR-120-2609-host-residual-security-scan/di-wiring-audit.md。
• 人工瀏覽輸出，確認格式清楚（每個缺漏都寫明：哪個 service、缺哪個參數、在哪個容器檔沒接上）、沒有明顯的誤判（例如把有預設值的可選參數也標成缺漏）。

連帶

• U13a／U13b 兩張掃描卡的派工 prompt 與卡片內容，要附上這份 di-wiring-audit.md 的路徑，讓 runner 帶著這份比對結果去看最可疑的地方，不是空手掃。

紀律

• 只加不改既有程式碼：這是全新腳本，不動任何現有的 DI 容器檔或 service 檔。
• 做完就 commit＋回寫 Notion，不等令：顯式 git add scripts/security/di_wiring_audit.py 與輸出檔；append 白話補充（含 commit hash、--self-test 通過紀錄）到本卡；狀態改「修正待驗證」。push 等令。