本卡屬 FR-161（母卡見「母卡」欄），是 FR-161 開卡時順手查到的 FR-139 既有缺口，與本案主線無依賴。

問題是什麼（白話）

FR-139 定的規則是：資源庫綁的專案一旦送審、開始稽核，資源庫就不能再改，直到覆核輪回到「規劃中」才能再改。程式裡為這件事留了一個位置，但裡面是空的，所以現在資源庫在稽核中仍然可以修改。

稽核本身不受影響，因為稽核輪讀的是送審時另外複製出來的凍結版本。受影響的是：顧問以為資源庫已經鎖了，其實還能改；而且專案那邊直接看資源庫那一份（FR-139 一對一），所以專案頁看到的內容會在稽核中途變掉。FR-161 的同步服務也會因此連稽核中的資源庫一起更新。

在哪裡

common/authz/ssp.py  約 129～144 行  _guard_template_write：範本 SSP 寫入守門
                     （檢查 oscal.resource-library.update → verify_template_writable → before_template_write）
common/authz/ssp.py  約 157 行       before_template_write：「範本 SSP 寫入前的業務鎖掛點（例：綁定專案稽核中鎖寫）；目前無額外條件。」→ return None
domain/oscal/service/ssp_project_resolver.py 約 153 行  is_writable：專案 living SSP 的寫入判斷，規則是「當前輪 status == planning 才放行」——可參照

FR-139 design D19 原文：只有綁定專案最新一輪是 planning 可改；送審後到結案（含 remediation、closed）一律鎖。覆核子輪回到 planning 時可改。判斷用白名單（只放行 planning），新增輪次狀態時預設是鎖。

怎麼修

• 在 before_template_write 實作：由 module_frame 找綁定專案（一對一，compliance.projects.module_frame_id），沒綁專案 → 放行；有綁 → 取最新一輪（round_no 最大）；status == 'planning' 放行，其他一律拒絕。沒有輪次 → 放行。
• 錯誤碼：先 grep 既有「資源庫鎖住」類的 error code（FR-139 可能已定義但沒用到）；有就用，沒有在 flow_control_error_code.py 依規則新增 412 一碼，FE error-code.json 中英同步。
• 查詢走 domain service，不在 authz 層直接碰 ORM；需要的 domain service 照 DI 規範注入。
• ⚠️ 先盤點有哪些寫入入口會經過 _guard_template_write（grep require_manager、_guard_template_write 的呼叫端），確認 Excel 匯入、版本還原這些批次寫入也會被擋；還原舊版本身算不算「寫」要先回寫問決策者（FR-139 有「整份還原永遠可逆」的規則，可能需要例外）。

手測

• 找一個綁了專案、最新一輪是 planning 的資源庫：改一條控制項的現況，成功。
• 把該專案推到送審（launch_audit）：再改一次回 412；Excel 匯入回 412。
• 推到覆核子輪回到 planning：可以改。
• 沒綁專案的資源庫：照常可改。

紀律

• 本卡動 common/authz/，commit 前跑 ddd-compliance-reviewer。
• 三個 repo（BE、FE、jedi-python-package）目前都在 feature/FR-139。在當前 branch 工作，不切 branch；branch 不對就停下回報。