一句話：把主專案 api/＋app/＋domain/＋infra/ 四層共 636 檔 / 62,442 行，以模組為單位（約 25 個）盤一遍，每個模組回答「它現在是什麼狀態」。只給現況，不排優先序、不給建議。唯讀，不動任何檔。

這一棒在做什麼（白話）

主專案這幾年經過三輪模組化（把功能搬進 jedi-* 套件），搬完之後主專案剩下什麼、每一塊是什麼狀態，沒有人有完整的圖。有的模組功能全搬走了只剩空殼、有的做了但沒人用、有的本來就該留在主專案。

這一棒產出那張圖。決策者要開發新功能了，需要先知道地貌——哪塊是實的、哪塊是空的、哪塊是死的。

🔴 只回答「是什麼狀態」，不回答「該怎麼辦」。決策者 2026-09-16 明確要求：只給現況，不給建議。不要排優先序、不要寫「建議先清 X」、不要判斷輕重緩急。

範圍（首腦已精算，2026-09-16）

api/     174 檔 / 12,765 行   （18 個模組目錄）
app/     202 檔 / 32,636 行   （20 個模組目錄）
domain/  123 檔 /  6,995 行
infra/   137 檔 / 10,046 行
────────────────────────────
合計     636 檔 / 62,442 行

route 註冊約 202 條（含已註解者，需逐一確認實際生效數）

以模組為單位（一個模組＝跨四層的同名目錄，例如 api/oscal＋app/oscal＋domain/oscal＋infra/oscal 算一個）。不逐檔查依賴——深度到模組為止。若某模組需要逐檔深挖，寫進「需要另開卡深挖」欄，不要自己挖。

每個模組要回答什麼（表格欄位）

• 模組名
• 四層規模：api / app / domain / infra 各幾檔幾行（缺哪層就標「無」）
• 對外 route：實際註冊幾條（排除註解掉的），路徑前綴是什麼
• 前端有沒有在用：見下方「怎麼判斷前端在不在用」——這欄必須有證據
• 與套件的關係：① 實體在主專案（真業務）② 主專案是殼、實體在套件（漏網型）③ 接線殼（route 在套件、主專案只組 adapters）④ 與套件無關
• 狀態分類：見下方五類
• 證據：支持上述判斷的具體事實（import 了什麼、grep 結果、ui_routes 有無）
• 需要另開卡深挖嗎：是／否＋一句理由

五種狀態分類（只用這五類，不要自創）

• 🟢 實的——真業務實作，本來就該留在主專案
• 🟡 殼——主專案這份大半在轉呼叫套件，實體已在套件裡（feedback 搬遷前就是這型）