2026-08-02 覆核輪受評範圍收斂（narrowed scope）— SUMMARY

現象：覆核輪的控制項導覽顯示母輪全部控制項，而不是只顯示本輪需複驗的那幾條 （母輪 not_met）。POC 實證（專案 659deb51 / round 8）：AP=15 條、AR=4 條、job=4 條 —— 三端只有 AP 錯。

同一個「範圍沒收斂」的表象，實際上由三個彼此獨立的成因造成，逐層剝開才修對：

③ 的 STG 實證（專案 b4491646）：04:08:04 建輪時 AP 455 為 1 條（正確），04:25:26 按 「啟動稽核」，04:25:37 被改寫成 2 條（母輪全集）—— 建輪後 11 秒被打回。job 端 wecm(round_id=2447) 始終正確。

OSCAL 語意依據（非僅顯示問題）

OSCAL v1.2.2 reviewed-controls.control-selections：AP 的是「本次計畫查哪些」、 AR result 的是「本次實際查哪些」。覆核輪＝partial reassessment，本就該有自己收斂的 reviewed-controls。

修正前 AP=15 / AR=4 的 diff 會被讀成「計畫查 15 條卻只查了 4 條」（像評估未完成）， 匯出 OSCAL AP 會把這個矛盾一併輸出。佐證：ar_results.reviewed_controls 在 schema 是 per-result required[1]，正因每輪範圍本可不同。

b283f1ab 是同 session 順手修的另一支獨立 bug（結案狀態同步），不屬於範圍收斂三層， 已由 Notion CM-1032 涵蓋，此處併列以完整交代 branch 上的六支 commit。

BE

測試碼（已 commit，未實跑，見 §6）

FE

零改動——導覽、規劃頁、AP 編輯頁、AR 矩陣、匯出全部自動一致（因為都讀同一顆 AP）。

非覆核情境零影響：clone_ap_for_round 未傳 narrowed_control_ids 時行為與修正前完全一致； _is_planning_stage_reverify 綁 round_type == "close-out"，初始輪 / surveillance 的 母體真相仍是 living profile。

6.1 測試未實跑 ⚠️

三個 code fix（167f578f / 1182034d / 9b2eae04）測試碼皆已補齊並 commit，但依 user 指示本次跳過實跑 pytest，未經執行驗證。實際驗證來自 user 在 STG 的手動端對端測試。 下次進版或 CI 接入前應補跑：

pytest test/test_audit_round_app_service.py test/test_ssp_control_tree_round_scope.py test/test_fr040_ap_task_linkage.py -v

6.2 文案統一未做（user 已拍板，延後執行）

「待複驗」→「待覆核」全站統一，以及覆核輪預設名稱調整。FE + BE 全改，兩個 commit 分開：

BE error code 文案改動須同步 FE error-code.json（含 en / zh-cn，見 memory feedback_be_error_code_fe_i18n_sync）。

6.3 STG 既有髒資料未清

本次 migration 只清了 POC。STG 上既有的 close-out 輪（activity 96 等）仍帶母輪全集， 需另寫一支 migration（兩張表，同 ea25fcd1 模式，值取自同輪 ar_results.reviewed_controls）。 依環境異動鐵律，套 STG 需決策者當次明確指示。

6.4 ea25fcd1 未 push

branch fix/1.13.0-bug 上其餘 commit 已在 origin，ea25fcd1 尚未 push（等 user 明示）。

6.5 POC 備份表待清

確認無需回退後可 DROP：

DROP TABLE IF EXISTS oscal.bak_20260802_ap_reviewed_controls;
DROP TABLE IF EXISTS oscal.bak_20260802_ap_activities;

migration 套用指令（供其他環境參考）

psql -h <host> -p 25432 -U cmmgr -d <db> --single-transaction -v ON_ERROR_STOP=1 \
  -f scripts/sql/2026-08-02-reverify-round-narrow-ap-reviewed-controls.sql

⚠️ 該檔 WHERE 明確鎖 POC 的 r.id = 8，不是通用 UPDATE。要套其他環境必須先盤點 該環境的 round / ap id 並改寫條件（見 6.3）。

migration 已知陷阱（重寫時必看）

兩張目標表的 JSONB 形狀不同，不可共用同一個賦值（2026-08-02 POC 唯讀實測）：

ar_results.reviewed_controls                = [{"include-controls":[...]}]      陣列
ap_reviewed_controls.control_selections     = [{"include-controls":[...]}]      陣列（同形）
ap_assessment_activities.related_controls   = {"control-selections":[{...}]}    物件，多一層

故 ap_reviewed_controls 整欄賦值、ap_assessment_activities 需 jsonb_build_object 包一層。