這個案子在做什麼（白話）
產品要開始賣「裝在客戶自己機器上」的落地版。程式碼是公司的核心資產，不能讓客戶一打開主機就看到原始碼，所以出貨前要先把程式「翻譯成只有機器看得懂的形式」——就像出貨的是壓好的唱片，而不是樂譜。整個程式碼保護工程分三步走：第一步把程式編譯成看不出原始碼的成品（本案 FR-063）、第二步防止成品被竄改（FR-064）、第三步做一鍵安裝程式（FR-065）。本案是第一步。
已拍板決策
- 採用 Nuitka 這套編譯工具，把整套 Python 程式編成機器碼執行檔（binary），再包成 Linux 容器（Docker image）交付。這取代了先前保護力不足的 .pyc 方案（.pyc 很容易被還原回原始碼）。
- 本階段只做 Linux 容器版；Windows 支援放下一階段（方向傾向讓 Windows 客戶用 Docker Desktop/WSL2 跑同一份成品，不另外重做一套，屆時再議）。
- 現有的 Docker 設定檔是內部測試專用（權限全開、跑的是開發用伺服器），不可拿來疊改；正式交付要另開一份 production 專用設定（子卡 .3）。
先行實測結果（2026-08-13 夜間，STG 測試機）
正式動工前先實際編譯了一次，確認可行性、也把雷區找出來：
- 編譯一次約 1 小時 27 分、成品約 808MB。時間偏長，之後改用核心數更多的專用編譯機來壓（子卡 .2a）。
- 編出來的成品一啟動就掛：有一個第三方零件（dependency-injector）與編譯工具天生不相容，必須自己重新製作一份相容版本（子卡 .2b，全案風險最高的一顆雷，要最優先驗）。
- 另外盤出一串「編譯之後才會壞、必須先改程式碼」的地雷清單——例如程式啟動時靠現場掃描檔案組零件清單、讀資料檔靠原始碼相對位置等，編譯後這些機制全數失效。這些整理成子卡 .1 系列逐一拆除。
完工的驗收標準
編譯後的成品放進正式容器（production image）能順利開起服務，而且：能登入、主要查詢功能正常、PDF 報告匯出正常（含中文字型）、Word 文件轉檔（LibreOffice）正常。
後續
設計討論稿 → design.md → 拆子卡，依 big-feature-workflow 流程進行。（已完成，子卡樹見下方。）
子卡樹（2026-08-14 拆卡）
執行順序：.1 程式整理 → .2 Build 管線 → .3 Production image → .4 socketio 驗證。⚠️ .2b 提前驗證要點：編譯機一到位，最優先單獨跑 wheel rebuild（CM-1202）——15 分鐘就能驗出「dependency-injector 那顆最底層的雷到底解不解得掉」，免得程式整理全做完才發現路不通。.1a／.1b 是編譯前必須完成的硬前置；.1f 獨立可平行；.2 的腳本撰寫可與 .1 平行進行。