稽核報告頁籤按「帶入不符合事項」，後端 ar_objective_view.conclusion_draft() 只對每條不符合的評估目標組一行：
AC.L1-3.1.1 授權存取控制 [a]：（稽核發現）；風險（高）：（風險說明）；改善建議：（建議）三樣東西：稽核發現、風險、改善建議。這是「結果」，PM 開檢討會或跟老闆報告時要的是「過程」——誰做的、誰看過、什麼時候、為什麼會不符合、是不是第二次了。這些資料系統裡都有，只是沒拼起來。
從一條評估目標往外抓，資料分五圈。每圈標「對檢討的用處」與「資料來源」。
| 資料 | 檢討用處 | 來源 |
|---|---|---|
| 稽核發現 | 不符合的事實 | finding.description |
| 風險等級／風險說明／改善建議 | 影響與對策 | risk |
| 判定人、判定時間 | 誰下的結論、什麼時候 | finding.updated_user／updated_at（畫面已有，草稿沒帶） |
| 查核方法（檢視／訪談／測試） | 稽核人員是怎麼查的——文件看過就判不符合，和實際測過才判，可信度不同 | objective.methods（計畫階段設的） |
| 評估目標原文 | 老闆沒背 CMMC，看代碼不知道在講什麼 | objective.text |
| 資料 | 檢討用處 | 來源 |
|---|---|---|
| SSP 實作狀態（已實施／部分／未實施） | 自評與稽核結果的落差——客戶自認「已全面實施」卻被判不符合，是檢討會最常追的點 | 本次稽核凍結的 SSP，get_control_ssp() 已有讀法（ap.import_ssp_id） |
| SSP 現況說明（評估目標層） | 客戶當初聲稱怎麼做的 | 同上 |
| 資料 | 檢討用處 | 來源 |
|---|---|---|
| 採用的佐證名稱、件數、來源（任務／專案／現場） | 判定依據的材料是什麼；0 件採用卻判不符合＝根本沒交東西 | objective.evidence（已組好） |
| 每件佐證的上傳人、上傳時間 | 誰負責交、交得多晚 | evidence.created_user／created_at |
這一圈是你要的「任務的執行資訊」，資料全在 compliance.job_executions 與周邊表，目前草稿完全沒碰。
| 資料 | 檢討用處 | 來源 |
|---|---|---|
| 任務名稱、所屬部門 | 歸屬 | job_executions.name；job_execution_org_units |
| 執行人（第 1 關指派人） | 誰負責做 | task_assignees（user_id、role） |
| 開始時間、完成時間、期限、有沒有逾期 | 做得及不及時——逾期交的東西品質差是檢討常見結論 | start_time／end_time／due_at |
| 重做次數 | 被退回幾次、重開幾次 | attempt_no（重開會 +1） |
| 任務狀態 | 不符合的任務是不是根本沒做完 | status（TODO／PROCESSING／COMPLETED） |
| 關卡設定（FR-148）：幾關、每關誰 | 審核鏈長什麼樣 | job_review_steps＋job_review_step_assignees（第 1 關＝task_assignees） |
| 關卡紀錄（FR-148）：每次送審／核可／退回的人、時間、退回理由 | 主管退回過幾次、退回理由是什麼、顧問核可卻還是不符合——這是「檢查的人有沒有把關」的證據 | job_review_step_logs（review_step_service.get_overview() 已組成 steps＋logs 形狀，可直接複用） |
| 資料 | 檢討用處 | 來源 |
|---|---|---|
| 同一條評估目標在前幾次稽核（第 1 次內稽、第 2 次內稽…）的判定 | 重複不符合＝改善沒落實，報告給老闆時最該標紅的 | audit_round_passes 每次的 ar_result_id → findings；pass 順序已有 |
| 前次的稽核發現摘要 | 對照「上次說什麼、這次還是什麼」 | 同上 |
survey_discussions 只有問卷有，一般任務沒有）——沒有統一來源，先不碰。原本一行塞三樣，再加十樣會變一坨。改成每條不符合一個區塊，標題行＋固定順序的子行，子行沒資料就不印（不印「無」）。輸出改成 HTML（既有 toEditorHtml 會原樣接進編輯器；報告 Word 第 7 章走 rich_to_plain 轉純文字，格式自動變成逐行）。
範例（真資料拼出來會長這樣；人名用暱稱）：
AC.L1-3.1.1 授權存取控制 [a] 限制系統存取僅授權使用者 稽核發現：系統使用者清單中有 3 位已離職人員帳號仍為啟用狀態，未見停用紀錄。 風險（高）：離職人員可憑舊帳號登入內部系統。改善建議：建立離職當日停用帳號的流程並留存紀錄。 判定：潘稽核（稽核人員）2026-10-18 14:20；查核方法：檢視、訪談 客戶自述：已全面實施——「人資每季提供離職名單，IT 依名單停用」（與稽核發現不符） 佐證：採用 2 件——系統使用者清單.xlsx（王小明，10-16 上傳）、帳號盤點紀錄.pdf（王小明，10-18 上傳） 任務：上傳系統使用者清單｜資訊部｜執行 王小明｜10-16 開始、10-18 完成（期限 10-19，準時）｜重做 1 次 審核： 10-17 主管審核 李主管 退回（清單缺離職人員） 10-18 交證據 王小明 重交 10-18 顧問審核 陳顧問 核可 前次：第 1 次內部稽核同項不符合（「未提供使用者清單」）——重複發生
再舉一條沒關卡、沒前次、任務逾期的：
IA.L1-3.5.2 身分驗證 [b] 在允許存取前驗證使用者身分 稽核發現：未提供雙因子驗證設定畫面，無法確認已啟用。 風險（中）：帳密外洩即可直接登入。 判定：潘稽核（稽核人員）2026-10-18 15:02；查核方法：檢視 客戶自述：部分實施 佐證：採用 0 件 任務：上傳雙因子驗證設定｜資訊部｜執行 張工程師｜10-18 開始、未完成（期限 10-19，已逾期 3 天）
審核紀錄一筆一行（日期、關卡、人、動作，退回帶理由），不用箭頭串成一行——理由一長就讀不了、關卡一多就看不出順序。
標題行之外只有一個粗體：「重複發生」與「已逾期」。檢討會上眼睛要先掉到這兩個。
不做「精簡／完整」兩種。理由：原本那行的三樣東西都還在（第 2、3 行），稽核人員要短版就把後面的行刪掉——刪比補快得多。
第 7 章就是報告正文，帶進去的所有行都會進 Word／PDF。這是刻意的：決策者要的是給 PM 開會、給老闆看，報告本來就是那份。稽核人員若覺得某些行不該給客戶看（例如「主管退回理由」），編輯器裡自己刪。不另做「只給內部看」的版本——那是另一份報告，不在本卡。
get_conclusion_draft 已呼叫 build_view 拿到整棵樹（含判定、風險、佐證、methods）。多抓的只有四樣，而且只對不符合的評估目標抓（符合的不浪費查詢）：
get_control_ssp 的核心讀法（read_control_implementation_by_ssp_id），按控制項批次。mapping_by_round 已有「評估目標→workflow_execution」；每個 workflow 取最新一次各站（PoamJobQuery.stations 同規則）＋ task_assignees、job_execution_org_units、due_at／attempt_no。review_step_domain_service.list_steps／list_step_assignees／list_logs 按任務批次。audit_round_passes 依 pass_no 排，取前面每一次的 findings（findings.get_by_ar_result），對同 part_id 比對。人名一律走 enrich_audit_nicknames／resolve_user_names 轉暱稱，不印帳號。
app/flow_control/service/ar_review_context.py：抓第 ②④⑤ 圈資料，回每個 part_id 一個 dict。app/flow_control/service/ar_conclusion_draft.py：把樹＋context 渲染成 HTML。原 ar_objective_view.conclusion_draft() 改成呼叫這支（保留函式名，呼叫端不動）。infra/readmodel/audit/ar_task_context_query.py（不往 poam_job_query.py 塞——那支是改善計畫頁的）。