本卡屬 FR-114 資安修正（母卡 CM-2019），第 4 批「憑證殘留」卡 4-4，修 SUMMARY #74（出自 M23-3）。中。修法規格來自本批查證，計畫在 docs/features/FR-114-2609-security-fix-dispatch/batches/plan-b4.md「卡 4-4」段。

問題是什麼（白話）

Google 雲端硬碟的應用程式密鑰與加密金鑰散在多個進版控的檔案裡，而這組密鑰是 Google 後台唯一一組、所有客戶環境共用。本卡只做「清掉版控裡的殘留字串」這一半，金鑰本身重新發放與既有已存通行證的重新加密，另外開一張獨立的卡處理（見下方連帶段）。

首腦核對：

• 本項與批次其他項不同：這把金鑰確認「還沒有」被重新發放（模組頁狀態是「未修」，不在已撤銷換發的清單裡）
• 三個值：GOOGLE_DRIVE_OAUTH_CLIENT_SECRET（35 字元）→ 12 個檔；DRIVE_TOKEN_ENCRYPTION_KEY → 10 個檔；GOOGLE_DRIVE_OAUTH_CLIENT_ID（技術上是識別碼不是密鑰，但與密鑰成對出現，一併徹底清）→ 14 個檔
• secret 與 encryption key 兩者聯集 → 14 個檔（材料檔說 15，這次重算 14），全部在 docs/conversation-history/ 下；加上 client_id 聯集 → 17 個檔（多 3 個，runner 自己補 grep 列出）
• 套件側零命中，全部落在 BE
• ⚠️ 這把金鑰的值與現行 .env 完全一致——確認真的還沒被重新發放，與 M23 項目 3「未修」狀態一致

工作區

• BE 側：在 /Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-be/.claude/worktrees/wt-fix-security（branch fix/security-b1）改，不要碰主 checkout（掃描線正在讀它）。跑服務用 PORT=8001。

在哪裡

docs/conversation-history/2026-04-21-google-drive-integration/…-part-03-of-14.md
docs/conversation-history/2026-04-21-google-drive-integration/…-part-05-of-14.md
docs/conversation-history/2026-04-21-google-drive-integration/…-part-08-of-14.md
docs/conversation-history/2026-04-21-google-drive-integration/…-part-09-of-14.md
docs/conversation-history/2026-04-28-to-04-30-survey-answer-arc/part-verbatim-01-of-03.md
docs/conversation-history/2026-05-19/ssp-import-export-phase2-A0.1/e500cf61.md
docs/conversation-history/2026-05-22/ssp-import-export-phase2/7bed5ff9-session-docs-features-ssp-import-ex.md
docs/conversation-history/2026-05-27/participant-picker-framework-drive-fixes/0043-617066cd-session-projectplannin.md
docs/conversation-history/2026-05-29/conversation-history-housekeeping/1035-c5c2e417-5-28.md
docs/conversation-history/2026-05-31/evidence-classify-reports/1029-d0b63dd1-feature-ai-analysis-result-landing.md
docs/conversation-history/2026-06-02/db-erd-tooling-convergence/2024-d2a67903.md
docs/conversation-history/2026-06-14/fr038-oscal-redesign-wave1/2034-3fc2f2b1-oscal-v1-2-2-schema-c.md
docs/conversation-history/2026-06-14/fr038-oscal-redesign-wave1/2034-6219587d-oscal-v1-2-2-schema-c.md
（以上 13 個為 secret＋encryption key 聯集的代表位置，加 client_id 後還會多出 3 個檔，runner 動手前自己補 grep 列全）

怎麼修

• 🔴 先回寫本卡問決策者：plan-b4 開頭查到資料庫管理員密碼／系統管理員密碼／Google AI 金鑰與現行 .env 一致——是否已換發？沒換發則本卡清字串前要先換（換密碼屬環境異動、由決策者做）。回寫後停，狀態留 Not started，不要自己選。（本卡的 Google Drive 金鑰與上述問題中提到的「Google AI 金鑰」是不同的兩把——AI 金鑰在卡 4-1 的 #11 處理，本卡是 Drive 金鑰——但決策者若在該問題的回覆裡一併確認 Drive 金鑰也還沒換發，等於印證本卡「未修」的判斷，仍請先回寫等回覆再動手，避免清了字串卻掩蓋金鑰仍有效這件事的急迫性）
• ① 用三個 key 名稱各自 grep 找出實際檔案清單（GOOGLE_DRIVE_OAUTH_CLIENT_SECRET、DRIVE_TOKEN_ENCRYPTION_KEY、GOOGLE_DRIVE_OAUTH_CLIENT_ID），三者聯集約 17 個檔，全部只清版控字串，不動程式邏輯、不動 .env。
• ② 只做字串清理，不做金鑰重設與既有已存 token 的重新加密——這半屬 D-b4-3 已定案的另開卡範圍，見下方連帶段。

手測

• 本機：三個值各自 git grep -c -I -F -- '<值>' 零命中
• DEV：手動測一次「連接 Google Drive」（授權、上傳／讀取一個檔案）→ 期待正常，確認清字串沒有動到執行期讀取路徑