本卡屬 FR-120(母卡待填)。這一棒是 DI(依賴注入)接線設定檔的專掃:「DI 專掃:di_containers/ 七支」(7 檔/996 行)。必須等「FR-120 前置實作卡:DI 組裝比對腳本」做完、拿到比對結果後才派這棒。只掃不修。

這一棒在做什麼(白話)

這批是「DI 專掃:di_containers/ 七支」——決定「系統啟動時,哪個功能該接上哪些零件(包含安全檢查零件)」的組裝設定檔(7 檔,約 996 行)。這批檔案從沒被任何一棒專門核對過,過去只是被其他棒順手放進範圍讓研究員追零件從哪來,不是真的核對「零件接齊了沒」。

為什麼切這一塊

🟡 這批含 di_containers/containers.py(397 行,總組裝表,每個容器登記一行——漏登記的容器整個功能都接不上)與 di_containers/license/license_containers.py(84 行,授權檢查的零件,U1 的 license.py 就是從這裡拿)。優先序最後,等 DI 腳本卡做完再派。

重點看什麼

這些是首腦讀過盤點檔後認為最容易出事的地方,是思考起點不是檢查清單:

已知背景

本範圍從未被任何一棒正式掃過(只被順帶放進其他棒的範圍讓研究員追零件來源,不算專門核對)。已知至少兩次真實案例(合規稽核套件、SSP 套件)證實「容器少接一個零件,服務完全不會報錯」的問題形狀,本棒找的是同型問題。

怎麼做

第一步:讀完本卡與母卡,再讀盤點檔 docs/features/FR-119-2609-security-scan-closeout/scan-inventory.md 第 5 節,並讀 DI 腳本卡輸出的 di-wiring-audit.md。

第二步:驗 scope 檔數,在 BE repo 跑下面指令,對上 7 檔/996 行 才往下;對不上停下回報。

cd /Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-be && git ls-files -- \
  di_containers/containers.py \
  di_containers/cloud_integration/cloud_integration_containers.py \
  di_containers/license/license_containers.py \
  di_containers/support/support_containers.py \
  di_containers/project/project_summary_report_containers.py \
  di_containers/setup/setup_containers.py \
  di_containers/identity/identity_containers.py | xargs wc -l | tail -1   # 7 檔、996 行

第三步:把啟動指令交給決策者(你不能自己啟動)。/claude-security 帶 disable-model-invocation: true,模型用 Skill tool 叫會被直接擋掉;也不可以自己叫 Workflow、不可以自己派研究員/verifier 拼報告。這是刻意設計,撞到不要 debug、不要找繞路。兩行要當同一則訊息送出,第二行不能省: