盤點 B.1：專案能力點清單定稿

唯讀盤點。把專案內每一個「看角色決定能不能做」的地方——後端守門、讀模型 SQL、通知收件人、流程站、前端按鈕——各對到一個 proj.* 能力點，作為 T-2.1 seed 與 T-3.x／T-4.x 改碼的對照表。 路徑縮寫：$S = .venv/lib/python3.11/site-packages；FE = compliance-manager-fe/src。 角色縮寫：M＝manager（負責人）、R＝reviewer（審核者）、A＝auditor（稽核員）、V＝viewer（瀏覽者）；「全員」＝四值任一的參與者。 查法：fb＝走 get_user_role 由 control → group → project 往上找第一筆指派；exact＝只看專案層 project_participants.role 一列。

• 所有「全員可讀」的守門一律對 proj.project.read。每個專案角色都必含它（D1），所以這類守門改完後行為等於「是不是參與者」，非參與者照舊 404。
• 查法欄是改碼時要保留的語意：fb 的守門改成「往上找第一筆指派 → 展開該角色能力點」（D5）；exact 的守門改成「專案層那一列的角色能力點」。兩種都不可互換——exact 換成 fb 會讓群組層的負責人突然能改專案層設定。
• 「指派人 ∪ 負責人」型守門（assert_job_operator、問卷 writer、偵測操作）保留「是不是被指派人」那條路，只把「負責人可代為操作」那半換成 proj.job.manage。任務被指派人在 DEV 有 148 筆是瀏覽者，指派人那條路若改成要能力點，這些人會全部失去自己任務的操作權。
• 流程站（main_role）改存能力點名後，可推進＝持有該站任一 main_caps，或持有 proj.stage.advance-any；force 只認 proj.stage.advance-any（D8）。
• 主專案 common/authz/project.py 的四支守門是所有守門的實作出口：套件端（jedi_task_platform／jedi_compliance_audit／jedi_survey／jedi_evidence_classification／jedi_detection）經 core/plugins/*.py adapter 轉進來，所以套件只改呼叫參數（D9），判定在主專案一處改。

A.1 判定層出口與換算（T-3.1）

A.2 專案、參與者、任務（T-3.1）

A.3 流程執行（T-3.1／T-3.3）

A.4 稽核：AP／AR／輪次／判定（T-3.1）

A.5 POA&M、結案報告、專案摘要、證據分類、偵測、問卷（T-3.1）

A.6 SSP 與檔案歸屬（T-3.1）

SSP 寫入全部經 common/authz/ssp.py 的 require_manager／require_write_access（→ proj.ssp.update），讀取經 require_participant／require_read_access（→ proj.project.read）；改 ssp.py 一處即全部生效，下表列呼叫端供核對。

A.7 字面值、enum、serializer（T-3.1）

A.8 讀模型 SQL（T-3.2）

全部直接比對 project_participants.role（exact）；改為 project_role_id = ANY(:role_ids)，role_ids 由「本租戶含能力點 X 的專案角色」helper 算出。

A.9 通知收件人與流程站（T-3.2／T-3.3）

A.10 前端：角色頁與參與者選擇（T-4.1／T-4.2）

A.11 前端：專案內按鈕（T-4.2）

A.12 前端：流程編輯器（T-4.3）

合併判斷：只在「沒有合理的自訂角色會把兩者拆開」時合併。表中只有負責人打勾的九個能力點在範例角色裡總是同時出現，但各自對應客戶常見的分工（例如只管 SSP 的顧問、只管證據分類的助理），因此不合併。唯一符合合併條件的是 proj.stage.advance 與 proj.job.execute——兩者都沒有實際接入點，處理方式見待裁 1、2，而非併入別的能力點。

定稿數量：設計稿 14 個＋新增 1 個（proj.round.manage）＝15 個；若待裁 1、2 都裁「刪」則為 13 個。

可當流程站：流程編輯器下拉建議只列打勾的三個（proj.review.approve／proj.audit.judge／proj.stage.advance-any），它們恰好是舊四值換算後會出現在站上的值；列全部 15 個會讓設計者選到「看專案」當主責，導致所有參與者都能推進。

每項格式：問題 → 建議 → 理由。

1. proj.stage.advance 沒有接入點
   • 問題：推進判定改成「持有站上 main_caps 任一」後，proj.stage.advance 沒有任何守門或畫面會讀它。
   • 建議：從清單拿掉。
   • 理由：留著會讓管理員以為勾了它就能推進，實際沒效果；能推進哪一站由站上指定的能力點決定。
2. proj.job.execute 怎麼用
   • 問題：現在「誰能操作某任務」看的是「是不是被指派人」，與角色無關；DEV 有 148 筆指派落在瀏覽者身上。若改成「被指派人且持 proj.job.execute」，這些人會失去自己任務的操作權；若不接，它就沒有接入點。
   • 建議：從清單拿掉，任務操作維持「被指派人 ∪ proj.job.manage」。
   • 理由：指派本身已是「這件事交給你」的授權，再疊能力點只會讓「指派了卻不能做」的組合出現。
3. 結案報告讀要不要獨立能力點
   • 問題：proj.report.read 在範例角色與 proj.audit.judge 同一組人。
   • 建議：保留獨立。
   • 理由：客戶常要讓高階主管只看結案報告、不碰稽核判定。
4. 刪專案要不要從 proj.project.update 拆出
   • 問題：現在刪專案與改設定同一批人（擁有者或負責人）；前端刪除鈕另掛租戶 GRC_PROJECT_DELETE。
   • 建議：不拆，專案層用 proj.project.update，刪除的額外門檻交給租戶 GRC_PROJECT_DELETE。
   • 理由：刪除已有租戶層把關，專案層再拆一個能力點只增加勾選負擔。
5. 輪次生命週期用新能力點還是併入 proj.stage.advance-any
   • 問題：建輪次、啟動稽核、結束輪次、各段退回目前只認負責人，設計稿 14 個裡沒有對應。
   • 建議：新增 proj.round.manage。
   • 理由：advance-any 是「流程站推進」，輪次是「稽核週期開關」，兩者在套件裡是不同的服務；併在一起會讓想給「流程推進員」權限的人順帶能結束整個稽核輪次。
6. 任務佐證新增／修改／刪除目前任一參與者都能做
   • 問題：job_evidence_service.py:98,165,191 只驗參與者，瀏覽者也能改別人任務的佐證；檔案刪除那條（file_upload.py:124）卻已是「被指派人 ∪ 負責人」。
   • 建議：統一成「被指派人 ∪ proj.job.manage」。
   • 理由：同一份佐證兩條路徑判準不同，是現存的權限破口，趁這次統一。
7. 指派審閱步驟歸哪個能力點
   • 問題：review_step_assign_service.py:95,110 現在是負責人。
   • 建議：proj.participant.manage。
   • 理由：動作本質是「把人放到某個位置」，與指派任務同類。
8. 手動寄到期提醒歸哪個能力點
   • 問題：manual_job_due_reminder_service.py:90 現在是負責人。
   • 建議：proj.job.manage。
   • 理由：催任務屬於任務管理，與排程提醒收件人一致。
9. 摘要報告「還原到某版」目前任一參與者都能做
   • 問題：project_summary_report_history_service.py:79 是寫入動作但只驗參與者。
   • 建議：改要 proj.report.manage。
   • 理由：唯讀成員不應能改報告內容；若要維持現狀則對 proj.project.read。
10. 不綁專案的標準答案匯入
    • 問題：evidence_classification_service.py:51 判「在任一專案當負責人」，沒有專案可展開專案能力點。
    • 建議：改用租戶層能力點（grc.* 下既有的證據分類管理權）。
    • 理由：D4 規定 proj.* 只在專案內有意義，跨專案判斷屬租戶層。
11. 「被指派人 ∪ 負責人」中負責人那半
    • 問題：任務操作、問卷填答、偵測操作都允許負責人代被指派人操作。
    • 建議：換成 proj.job.manage，被指派人那條路不動。
    • 理由：見通則第三點。
12. 稽核計畫列表 needs_assign 誰會看到「待指派」
    • 問題：audit_plan_list_service.py:30-33 現在只對負責人亮「需指派稽核員」。
    • 建議：proj.participant.manage。
    • 理由：提示的是「請去指派人」，能指派的人才需要看到。
13. get_reviewers_for_task 沒有呼叫端
    • 問題：participant_role_service.py:86 依 reviewer 找人，但整個 codebase 沒人呼叫。
    • 建議：T-3.1 刪除。
    • 理由：改成能力點版只是維護一支沒人用的函式。
14. 偵測通知要不要寄給審核者
    • 問題：偵測完成與失敗目前都寄負責人＋審核者＋被指派人。
    • 建議：維持，對 proj.review.approve ∪ proj.job.manage ∪ 被指派人。
    • 理由：維持現行收件範圍，避免升級後有人突然收不到。
15. 列表上「負責人／稽核員名字」欄跟哪個條件
    • 問題：這些欄位是顯示用，不是授權；改成「持 proj.participant.manage」會把自訂的「副負責人」也列進去。
    • 建議：負責人欄跟 is_default_owner 角色，稽核員欄跟 proj.audit.judge（排除預設負責人）。
    • 理由：顯示的是「這個專案誰掛名負責」，與預設負責人的概念一致。
16. 問卷歷史對審核者隱藏
    • 問題：SurveyPreview.vue:1297 審核者看不到填答歷史，其他角色都看得到；後端歷史讀取對全員開放。
    • 建議：移除這個前端特例，歷史跟 proj.project.read。
    • 理由：後端沒擋，前端藏只是爛體驗；若是刻意不讓審核者看到修改軌跡，需另開能力點並讓後端一起擋。
17. 租戶層 v-can 與專案層判斷並存
    • 問題：專案列表的編輯／刪除／同步、手動建輪次、流程設定編輯，前端同時掛租戶 v-can（GRC_PROJECT_UPDATE／GRC_PROJECT_DELETE／GRC_AUDIT_CREATE／requiredCap）與專案角色判斷。
    • 建議：兩層都保留，專案層換成 v-can-project。
    • 理由：租戶層管「這個功能你的公司給不給你用」，專案層管「這個專案你是什麼角色」，兩者語意不同，拿掉任一層都會放寬權限。