母案：FR-063 落地版程式碼保護：Nuitka 編譯打包（Linux 容器版）（CM-1187 FR-063 Nuitka 落地版打包·Linux 容器版）
依賴：無——全部子任務可在開發環境完成驗證，不需編譯機。
這個子需求在做什麼（白話）
在把程式「編譯成看不出原始碼的成品」之前，得先把程式本身整理到「編譯得動、編出來能用」的狀態。現在的程式有不少寫法是靠「現場有原始碼檔案」才成立的（例如啟動時去資料夾掃檔案、照原始碼相對位置找資料檔）——編譯後成品裡沒有原始碼，這些機制會整批失效。這個子需求就是把這些地雷逐一拆掉，同時順手做幾項程式體質改善。
重點是：這包整理本身就有獨立價值——統一啟動入口、正式伺服器承載方式、資源檔集中管理、修掉排程重複執行的問題，就算日後編譯路線意外中止，這些改善也不白費。
排序要點：.1a／.1b 是編譯前必須完成的硬前置（不先做好，編出來的成品必定不能用）；.1f 完全獨立可平行；.1g 排 .1b 之後、與 .1c 平行。
子任務 a–g（每張各有工作卡，這裡是一句話版）
- a DI 靜態清單機制（🔴 編譯硬前置）——程式啟動時靠現場掃描原始碼檔案來組「零件接線清單」；成品裡沒有原始碼可掃，清單會是空的——系統照樣開起來、不報錯，但使用者一點任何功能就壞。改成打包時先把清單做好一份帶著走；開發時照舊現掃，體驗不變。
- b 資源檔統一定位＋資料檔搬遷（🔴 編譯硬前置）——四個地方的資料檔（翻譯檔、SSP 匯出範本、兩份評估基準資料）現在都是「照原始碼的相對位置」去找的，編譯後全部找不到。改成統一透過一個定位入口找檔案，開發與成品兩種環境都通；順帶把放錯位置的資料檔搬到正確的家、清掉幾處壞掉或無用的舊設定。
- c 統一啟動入口＋模式裁剪——目前有三支不同的啟動程式（歷史因素），交付成品只能有一個入口。合併成一支，用一個環境開關切「API 服務」或「即時通知服務」兩種模式；順帶修掉背景排程在兩個服務裡重複執行的問題。
- d 正式伺服器承載內嵌——正式環境跑服務的方式（gunicorn，等於正式版的引擎）原本是用外部指令啟動，編譯後的成品不支援那種啟動法，改成寫進程式裡自己帶起來。與 .1c 同一批檔案，一起做。
- e 啟動失敗要大聲喊＋版本資訊改內建——現在某些功能模組載入失敗時，系統只默默記個警告、整組相關功能無聲消失；改成「缺東西就啟動失敗」，問題當場暴露而不是上線後才被客戶發現。另外「目前版本」的查詢現在是去讀一個成品裡不存在的檔案，改成打包時把版本號和程式碼識別碼直接烙進成品。
- f 文件轉檔工具路徑修正（獨立可平行）——內部共用套件裡找 LibreOffice（Word 轉 PDF 用的工具）的方式是寫死的，不吃我們的環境設定；在客戶機器上位置不可預期，會轉檔失敗。改成與主系統一致的找法。
- g 設定檔三層重整＋無用設定清理——編譯後「改一個設定＝重新編譯出貨」，所以要先把設定分好層：不會變的編進成品、每個客戶不同的用環境變數、營運中會調的放資料庫。順帶把累積多年的無用設定一次清掉。
收口驗收（總原則：開發模式行為零變化）
- 既有測試全綠；PyCharm 開發除錯體驗與現行完全相同
- 兩種啟動模式（API／即時通知）在開發環境都起得來
- 全程式碼檢查：不再有任何「照原始碼相對位置找資料檔」的寫法殘留
- 功能模組缺件時啟動立即失敗，而不是默默略過
參考