一句話:本卡是 2026-09-16 決策者逐支 review 主專案剩餘 20 個 api/ 目錄的結論記錄,三支查出需要處理(user_auth_provider 同型漏網、report 與 translate 疑似死端點)。本卡只記錄不派工,POC 交付後由決策者決定是否開實作卡。
決策者 2026-09-16 問「為什麼還有很多 route 在主專案」,於是把主專案 api/ 底下 20 個目錄逐支查了一遍,看哪些是該搬進套件卻漏掉的、哪些是已經沒人用的、哪些本來就該留在主專案。
查完之後:一支確認是漏網(跟 FR-099 的意見回饋完全同型)、兩支確認前端沒有任何入口(疑似可以退役)、其餘都有正當理由留在主專案。
為什麼要開卡記下來:決策者原話「後面絕對會忘記這件事」。這些查證結果原本只存在一次對話裡,POC 交付後沒人會記得查過什麼、結論是什麼。這張卡就是那份記憶。
2026-09-16 當下是第一次 POC 給客戶的最後檢查階段。這三支的處理對 POC 客戶都是零可見價值(程式碼乾淨度、新產品複用性),交付前動它們是把風險往自己身上攬。決策者已裁 FR-099 照做(那支有「修掉會誤導所有人的錯誤文件」的即時價值),本卡三支則押後。
白話:第三方登入綁定(使用者把自己的帳號跟公司的 LDAP 綁在一起)。主專案有 285 行程式,但套件 jedi-iam 裡早就有完整的一整套(資料模型、資料存取、業務邏輯、LDAP 連線元件全都在),主專案那份大半是轉呼叫套件的殼。
首腦實查證據:api/user_auth_provider/routes/user_auth_provider_route.py 三條 route 中兩條是一行轉呼叫套件 service(get_user_auth_providers/delete_user_auth_provider),第三條轉呼叫 core/plugins/identity.py 的 register_user_auth_provider。套件側 jedi-iam/jedi_iam/ 底下已有 entity/query entity/repo/domain service/app service/LDAP adapter/auth_provider port 全鏈。
前端實際驗證(2026-09-16,決策者要求不只 grep 原始碼):這支是活的,FE src/views/user-manage/UserProfileForm.vue:267 POST 綁定、:297 DELETE 解綁。ui_routes 沒有它的獨立選單是正常的——它不是頁面,是掛在使用者資料頁裡的功能。
🔴 但有一支不能無腦搬:app/user_auth_provider/service/ldap_service.py(88 行)裡有兩條踩過坑補上的資安防護,而且是主專案的多租戶規則,不能跟著進通用套件,必須走 port:
另外該檔的 _LdapOnlyPolicyProvider 有一段註解說明「它組的設定來源與另外三處不同,故刻意不收斂成同一條路徑」——搬遷時要保住這個差異,不要順手「統一」掉。
建議處理方式:比照 FR-099 開卡(母卡+子卡),規模比 FR-099 小(285 行 vs 五個目錄)。但 ldap_service.py 那 88 行要單獨設計 port,是本支的主要工作量。
白話:一支呼叫 OpenAI 做翻譯的 API(POST /api/1.0/translate)。前端完全沒有任何地方在用它。
前端實際驗證(2026-09-16):① FE 的 src/config/api/api.js 連常數都沒有(不像 feedback 有 FEEDBACKS/FEEDBACK 等五個常數);② 全 FE repo 搜 translate 只命中 CSS 的 translateY、BPMN 套件自己的 translate 函式、以及一個孤兒錯誤碼字串 TRANSLATE_500001(在 zh-tw 與 en 兩份 error-code.json);③ DB public.ui_routes(真選單表,使用者實際看得到什麼的真相來源)零命中。
連帶影響:這支讓 openai 這支 Python 相依與 OPENAI_API_KEY 環境變數掛在專案上。api/translate/routes/translate_route.py 有段註解記著 M17 的坑(不可在 module 載入時裸讀 os.environ["OPENAI_API_KEY"],未設會讓整個 app 啟動失敗),現況是 lazy init。