本卡為 FR-107 母案。把「證據自動分類」從 Google Drive 搬回系統自己的儲存空間，分完的檔直接搬進任務變成正式證據，而且不管哪個合規框架都能用。六棒、22 張子任務卡，實作案（會改程式、會加資料表）。子卡清單在末段。

這系列在做什麼（白話）

現在系統有一個「AI 幫你把證據檔分類」的功能：使用者把證據檔放進 Google 雲端硬碟，AI 讀完之後判斷「這份檔可以證明哪幾個檢查點」，結果也寫回 Google 雲端硬碟。

問題是：落地版的客戶沒有 Google 雲端硬碟。 我們賣給客戶裝在他們自己機房的版本（FR-063～FR-065 做的那套），整條分類線等於不存在。而且就算有 Drive，分類完的檔也只是被複製到 Drive 的另一個資料夾，系統裡的「任務證據」一筆都沒寫——稽核員在系統上看不到這些證據。

這系列要做三件事：

• ① 搬家：證據檔改成上傳到系統自己的儲存空間（主機硬碟／物件儲存／客戶內網的遠端代理，設定切一下就換），不再依賴 Google。
• ② 分完真的進系統：AI 分類完、人工審閱確認後，按一個「歸檔進任務」，檔案就直接掛到對應的稽核任務上，稽核員在「我的任務」裡就看得到。
• ③ 框架不寫死：現在程式裡寫死了「CMMC 2.0 Level 1」這個框架的 17 條檢查點；改成讀系統裡實際掛的合規框架，換 ISO 27001 也能用；AI 的角色設定與判斷指引改成可以在畫面上編輯。

為什麼要做

前作 FR-030 把自動分類做在 Google Drive 上：檔案從 Drive 來、結果寫回 Drive 的 _state.json、歸檔只是把檔複製到 Drive 的另一個資料夾，系統的任務證據表 job_evidences 一筆都沒寫。落地版客戶沒有 Drive，這條線等於不存在。

同時 FR-069 模組化之後，系統的檔案儲存已經統一走 jedi-file-upload 套件的 IUploadFileProvider（一個「存檔／取檔」的統一介面），分類線是唯一還直接綁 Google Drive 的功能。

四個結構性問題（詳見討論稿第 2 節）：

• 來源與終點都是 Drive——落地版完全不能用。
• 分類用的容器（一個獨立跑 AI 的 Docker 程式）自己連資料庫、自己解密 Drive 憑證、自己下載檔案——等於把資料庫密碼與 Drive 權限交給一個外部容器。
• 框架知識寫死在程式裡：CMMC L1 的 17 條檢查點、[a] 這種字母代號硬剝、套件裡放著 cmmc_l1_aos.json 靜態檔。
• upload_files（存所有上傳檔的表）沒有租戶欄位、沒有擁有者、沒有 RLS（資料列層級權限，資料庫自己擋跨租戶讀取）——暫存的孤兒檔沒人管，任何人拿到檔案編號就能讀。

關鍵設計決策 D1–D11（決策者 2026-09-16 一次裁完）

• D1 批次檔怎麼存：開新表 evidence_batch_files；upload_files 只補租戶／擁有者／RLS 三個「檔案自己的身分」欄。排除：upload_files 直接加 batch_id——那張表被十幾個模組共用，多一欄大家都看到。
• D2 容器怎麼拿到檔：宿主（主專案）先把整批檔拉到 job 工作目錄，再起容器；容器零網路（除了打 AI API）、零憑證。排除：容器透過內部 API 拉檔——要新增 HTTP client、內部端點與一次性 token，收益不成比例。
• D3 舊 Drive 分類線：並存一版、前端入口隱藏、下一版刪。舊 route 原樣保留。排除：一刀切——POC 上既有的分類結果與報表會立刻打不開。