一句話：本卡為 FR-156 母案，把 FR-134 做好的第三方元件掃描從主系統沙箱搬到客戶機房的 Agent 上跑，並把弱點資料更新改成全自動。12 棒、5 批、跨 4 repo。子卡清單在末段。
這系列在做什麼（白話）
FR-134 做出來的「第三方元件風險」是顧問把客戶的原始碼壓縮檔上傳到我們主系統，由主系統裡的沙箱跑掃描工具。PM 判定：掃客戶程式碼的東西不能放我們主系統。本案把掃描搬到客戶機房那台 Agent 上，原始碼從瀏覽器直接傳到 Agent，不經主系統；回主系統的只有「用了哪些套件」和「哪些有弱點」的結果，不含任何程式碼。
同時，比對弱點用的資料庫現在要人手更新（裝機帶一份、管理員上傳、或按檢查更新）。PM 判定弱點更新太快不能靠人。本案改成：我們這邊每天凌晨自動產一包、蓋章、放到 Cloudflare；客戶的主系統每天自己抓；每台 Agent 透過既有的心跳得知有新資料後自己來拿。封閉網路的客戶維持管理員上傳一次，Agent 一樣自動跟上。
為什麼要做
- PM 2026-10-21 三個意見：①掃程式碼的工具不能預設放主系統；②弱點資料不能靠人更新；③工具帳密想搬 Agent 端（第③點獨立成 FR-157，本案不做）。
- FR-134 尚未進版、沒有客戶裝到伺服器端掃描版，現在改執行位置成本最低。
- FR-134 當初排除「做成 Agent 執行器」的唯一理由是「每台 Agent 要帶 4.7GB 弱點資料且要更新」，這正是意見②要解的，解掉就沒有障礙。
- FR-039 原始不變式就是「雲端不得把客戶 binary 寫進雲端磁碟」，PM 的意見與原始架構一致。
關鍵設計決策（D1～D12，細節看 design.md §3）
- D1 SBOM（套件清單）與弱點結果留雲端；D2 主系統沙箱掃描整個拔掉；D3 Agent 弱點資料由主系統中繼、Agent 不出網；D4 不做 Agent 程式自動升級、也不做過舊提示。
- D6 188 的 GitLab runner 每日排程產包、License Center 蓋章、Cloudflare R2 發布（決策者已建好 bucket
guidant-vulndb、網域 vulndb.jedicotech.com、CI 變數 R2_ACCESS_KEY_ID／R2_SECRET_ACCESS_KEY／R2_ENDPOINT／R2_BUCKET、排程「弱點資料每日發布」未啟用）。
- D8 瀏覽器直傳 Agent：主系統簽五分鐘上傳票（JWT），Agent 另開 8444 單向 TLS 門收
PUT /scan-input；8443 維持 mTLS 不動。D9 自簽憑證警告第一版接受。D10 更新站預設 https://vulndb.jedicotech.com。D11 Agent 拉不推。D12 FR-058.7 SonarQube 源碼上傳一起改直傳。
怎麼拆（5 批 12 棒）
- 第 1 批（可平行、互不改同檔）：A1 每日發布 pipeline（BE CI）、D1 Agent 帶四支工具＋能力宣告（evidence-agent 打包）、D2 Agent 掃描執行器（evidence-agent connector）。
- 第 2 批：B1 主系統自動抓預設開＋刪舊（BE／jedi-source-scan／FE）、C1 心跳帶弱點資料＋控制面下載端點＋清單欄位（jedi-remote-agent／jedi-source-scan／FE）、C2 Agent 弱點資料同步模組（evidence-agent）。
- 第 3 批：E1 上傳票＋Agent 8444 瀏覽器門（jedi-remote-agent／evidence-agent）、E2 精靈選 Agent＋直傳＋掃描 job 拆分（FE／jedi-source-scan）。
- 第 4 批：F1 收掉伺服器端路徑（沙箱／jedi-detection／FE／migration）、F2 SonarQube 源碼上傳改直傳（FE／jedi-detection／evidence-agent）。
- 第 5 批：G1 SPEC／手冊／安裝文件、G2 出貨基線＋收尾紀錄。
共同設定