FR-100 · 需求索引 · 本頁由 build 掃資料夾生成
🟢 兩棒完成（2026-09-16）。記錄卡 CM-1820；CM-1821 translate 退役、CM-1822 flow-engine 重複檔加警語，皆已驗收通過。report 查證後改判為活的（外部工具鏈）不可刪。user_auth_provider 搬遷與 cruising 退役 POC 後再排。
user_auth_provider——與 FR-099 同型的漏網（套件 jedi-iam 已有全鏈、主專案 285 行是殼）。translate 已退役（CM-1821）；report 查證後改判為活的、不可刪（見下）。flow_engine 有兩件事，別混為一談：① 套件裡一支 548 行的重複檔（已加警語，CM-1822）；② 主專案 app/flow_engine（3,041 行／6 支 service）與 19 條 route 的歸屬未定，那與 flow_control 的分家是同一個決策。226 檔與 9,183 行都是 2026-08-31 舊設計稿的數字，兩者皆已失效——之後兩筆 commit（561922d4 退役 camunda 死碼、83a5c47e BPMN 工具改接套件）砍掉六成，重新分析見 FR-101（CM-1823）。api.js 常數／FE 路由／DB ui_routes）。第三方登入綁定。套件 jedi-iam 已有完整全鏈（entity／query entity／repo／domain service／app service／LDAP adapter／auth_provider port），主專案三條 route 中兩條是一行轉呼叫。
前端實查：活的。FE src/views/user-manage/UserProfileForm.vue:267 POST 綁定、:297 DELETE 解綁。ui_routes 無獨立選單是正常的——它是掛在使用者資料頁裡的功能，不是頁面。
🔴 app/user_auth_provider/service/ldap_service.py（88 行）不可無腦搬，兩條踩過坑補上的資安防護，且是主專案的多租戶規則，必須走 port：
| 卡號 | 防的是什麼 | 沒防會怎樣 |
|---|---|---|
| CM-1283 | LDAP 設定落 ROOT(1) 列，業務租戶受 RLS 讀不到，故走繞 RLS 的 root reader | 「沒帶密碼就沿用舊的」拿不到舊密碼，把 LDAP 綁定密碼清空，而畫面顯示儲存成功 |
| CM-1564 | 目標主機（server／port）變更時不可沿用舊密碼 | 把服務帳號密碼送去呼叫端指定的任意主機 |
該檔的 _LdapOnlyPolicyProvider 另有註解說明「它組的設定來源與另外三處不同，故刻意不收斂」——搬遷時要保住這個差異。
POST /api/1.0/schedule-report/preview，讀 SCHEDULE_REPORT_DIR（預設 /reports/）下的檔案。
它服務的是外部工具鏈，不是前端。 bin/report_downloader/report_downloader.py 是一支 Selenium 程式，會去 Wazuh 登入、下載 11 種 Windows 資安報表 PDF（使用者重設密碼／檔案刪除／檔案稽核／安全群組變更／帳號建立刪除鎖定／登入成功失敗等），寫進 SCHEDULE_REPORT_DIR；這支 API 負責讓人預覽下載那些檔。
不經前端選單是正常的。這也解釋了那段 path traversal 防護（_safe_report_path）——端點讀的是外部程式寫進來的目錄、檔名來自 query 參數，必須擋 ..。
順帶抓到（未處理）：common/middleware/license_readonly_mw.py:110 白名單有 /schedule-report/file-list，但那條路徑根本沒註冊（只掛了 /preview）。白名單在保護一支不存在的端點，不影響功能，但代表這塊可能還有沒查清的地方。
POST /api/1.0/translate，呼叫 OpenAI 翻譯。四方查證（FE api.js 無常數、FE 全 repo 零命中、ui_routes 零命中、e2e 零呼叫）確認無呼叫者，已刪除。
🔴 openai 相依與 OPENAI_API_KEY 保留未動——AI Dashboard 也在用（jedi-ai-dashboard/infra/ai_client/openai_client.py、jedi-common/utils/gen_comment.py），拔掉會弄壞 AI 儀表板。
套件 jedi-flow-engine/app/service/workflow_execution_service.py 主專案零處使用，但檔案裡原本沒有任何一個字說它不該用（第 1 行直接是 import json）。
兩份已長歪：complete_job 本檔 6 個參數、主專案版 7 個；revert_job 6 vs 9；主專案版另有 12 個本檔沒有的方法（稽核輪次凍結、專案參與者權限、通知派工、問卷屬性處理）。
不能把主專案那份搬回來——它已長進稽核業務，搬回去等於通用套件依賴特定產品。也不宜直接刪——那支不是孤立死檔，plugin/wiring.py、plugin/__init__.py、app/wiring/、守衛測試 test_repo_wiring.py:92 與三支測試檔圍著它，要刪得動契約層。
故採加警語（檔頭 21 行說明是舊的／參數差異／為何不搬回／去向指設計稿），零行為變更。
FE 意見回饋有兩組頁面：
| 組 | 路徑 | 選單 | 下拉來源 |
|---|---|---|---|
| 新 | views/feedback/system/（3 檔） |
開啟 | API.LABELS_MENU |
| 舊 | views/feedback/cruising/（3 檔） |
關閉（ui_routes id=14，enable=0） |
API.SYSTEM_MENU |
舊那組選單雖關，路由仍掛著（src/config/router/index.js:76-102），網址打得進去，且打同一組 feedback API。是 FR-092 廢碼清理沒掃到的同型殘留。是否退役屬本案待決事項。
| 順位 | 做什麼 | 為什麼是這個順序 |
|---|---|---|
| 1 | user_auth_provider 搬遷 |
唯一「現在不做、以後更難做」的——jedi-iam 是最底層套件之一，動它的人多，殼留越久越容易長出新依賴。且與 FR-099 同型，趁做法剛驗證過接著做成本最低。主要工作量在 ldap_service.py 那 88 行的兩條資安防護要設計 port |
| 2 | cruising 舊頁退役 |
選單關了但路由還在，等於沒人維護卻打得進去的後門。要等 FR-099 全收完才知道現況 |
| 3 | license_readonly_mw 白名單清查 |
白名單保護著一支不存在的端點（/schedule-report/file-list）。不影響功能，但代表這塊可能還有沒查清的地方 |
| 待重新分析 | flow_engine ＋ flow_control 歸屬（現況 114 檔／14,350 行） |
舊設計稿數字全失效，FR-101（CM-1823）重做判定後才知道要動什麼 |
🔴 判斷「前端有沒有在用」不能只 grep 原始碼（決策者 2026-09-16 要求）。grep 只能證明原始碼裡有沒有這串字，證明不了使用者在畫面上進不進得去。三層都要查：
src/config/api/api.js 有沒有對應常數（沒有＝幾乎確定沒人用）src/config/router/index.js 有沒有掛（掛著就打得進去，即使選單關了）public.ui_routes——使用者實際看得到什麼的真相來源。欄位是 name／url／enable（不是 path）。DEV 現況 43 開啟／12 關閉⚠️ 三層可能互相矛盾，矛盾本身就是線索：cruising feedback 就是「選單關了但路由還在」才被抓出來的。
🔴 但三層還不夠——要加第四層。那三層查的都是「前端」，而端點的使用者未必是前端。report 三層全綠，第四層才發現它是活的：
bin/、scripts/、排程設定、中介層白名單（license_readonly_mw.py 那類）判準是**「有沒有非瀏覽器的呼叫者」**。report 服務的是一支 Selenium 程式，跟畫面完全無關。
cloud_integration 不動。report 與 translate 的結論據此重驗。flow_engine 的處置，每次都問出一個錯誤——① 「要處理吧」→ 查出該債只有一支 548 行重複檔，不是整支套件廢棄；② 「flow-engine 的呢」→ 查出 226 檔是 flow_control 的數字，不是 flow_engine 的；③ 「他要怎麼處理，你知道嗎」→ 承認未讀設計稿正文，讀完才發現歸屬與四步計畫早已寫明。教訓：設計稿正文有的東西不要憑卡片摘要轉述，連原始卡片的數字都被設計稿更正過（卡片寫 6,375 行實查 9,183、卡片寫 19 條 route 實查 16 條還在用）。