一句話：本卡為 FR-105 母案，把主專案
oscal（163 檔／19,996 行）與module_frame（81 檔／10,942 行）兩個最大模組逐檔分類成「真業務／轉接殼／共用設施／死碼」，兩棒，只分析不動程式。子卡清單在末段。
主專案四層程式一共約 62,000 行，其中一半住在 oscal 與 module_frame 這兩個模組。這兩個模組裡同時有「本產品自己的業務」（解析 Word／Excel、比對文件差異、產 Excel 範本）與「轉接殼」（把前端請求轉給 jedi_oscal_v2 套件、換欄位名回傳），混在同一個目錄。看目錄分不出哪支是哪種，要開檔逐支看。
這系列要產出一張逐檔的分類表：每一支程式是哪一類、證據是什麼、哪些現在就能收、哪些要先設計。不動任何程式——決策者要的是「有正確的圖才動刀」。
決策者 2026-09-16 原話：「我要的就是乾淨的 code，因為我後面要去開發新功能了，不要再留一堆無意義的東西。」FR-103 已把確定的殘留（report 整條線、cruising 舊頁、user_auth_provider、12 個舊選單、survey 接線）清完；FR-102 全模組地圖盤到模組層級後明講這兩支「單一標籤蓋不住內部差異」需另開卡逐檔判（docs/features/FR-102-2609-host-module-map/README.md:139-140）。這不是「沒遷乾淨」，是內部邊界沒畫清，性質不同於 FR-103。
docs/features/FR-080-*/FINAL-SPEC.md「主專案怎麼接」段）。分類只標性質，不等於可刪。真正可收的是：死碼、兩模組各寫一份的重複對應表、與套件重複的 helper。ssp_*_app_service.py 五支同型，oscal 那邊檔頭自陳「欄位 mapping 與資源庫範本版完全相同」。這是最可能的「兩份真相」，兩棒要各標一半、第 2 棒對照。module_frame_template_import_service.py（1,008 行）檔頭自陳「格式對齊 app/oscal/service/ssp_control_impl_import_service.py」（431 行）。ssp_control_implementation_service.py 1,004 行 jedi=20、ssp_import_template_app_service.py 1,500 行 jedi=18——殼與業務混在同一支，要拆才能判，這類進「要設計才能動的」。api.js／FE 路由／ui_routes／非瀏覽器呼叫者）。FR-100、FR-102 都在第四層抓到「前三層全綠但活著」的。兩棒可平行（各自只動自己模組的分析檔），但 docs/features/README.md 登記表與 FR-105/README.md 會共用——第 1 棒建、第 2 棒更新，commit 前 git pull --rebase。建議一次只派一棒。
四類判準（依賴方向，不是檔名）：真業務＝主要邏輯自己寫、jedi 引用少或零、刪掉功能就消失；轉接殼＝主體是「開 transaction → 呼叫套件 service → 欄位對應／分頁」，商業規則在套件，另標「有沒有帶主專案獨有規則」；共用設施＝無 route 無業務語意、給別的模組用（resolver／DTO／error code／serializer）；死碼＝四層零引用；還看不準＝允許，但要寫卡在哪。
產出落點：docs/features/FR-105-2609-oscal-module-frame-file-classification/（README.md 三段式首頁＋ module-frame-classification.md ＋ oscal-classification.md），跑 scripts/deliverables/render_index.py 出 HTML。