本卡屬 FR-095（母卡見本 arc README front matter），第 6 棒 P4：任務領域模型＋任務型別登記簿＋四張 job_execution_* 表（jedi 套件 repo）。只掃不修。

這一棒在做什麼（白話）

套件 task 那一半的「內層」：任務、留言、儀表板的領域模型（entity）與介面（port／repository interface）、任務型別登記簿（「系統有哪幾種任務、每種啟動時要跑什麼」的總開關），以及四張 job_execution_* 附屬表（留言、設備、部門、問卷）的模型與查詢。共 20 檔（task/domain/**、task/infra/** 其餘全是 0 行的 __init__.py，不硬湊）。只找問題、不修問題。

為什麼切這一塊

task/domain/task_type_registry.py 是「拔掉一行、某種任務型別就整個消失」的總開關，而且它自陳接錯線的症狀是「靜默失效、看起來像業務邏輯問題」。四張附屬表沒有一張有租戶欄、隔離全關（首腦 DEV 實查），這一棒把「表結構 × 查詢 × 領域模型」放一起看資料庫層有沒有任何兜底。

重點看什麼

這些是首腦讀過程式碼後認為最容易出事的地方，是思考起點不是檢查清單。每條後面的「首腦核對」是首腦親自開檔的結果——✅ 屬實的不必重做核對，直接當錨點追下去；標「待 runner 核對」的才要你自己開檔確認。工具沒答的自己開檔查了再寫，標明「（工具未報，人工查證）」：

• 任務型別登記簿的申報與執行（疑點 #13 根源）：task/domain/task_type_registry.py——register() 在申報當下擋不可呼叫的物件（:87 自陳），但要追：① 同一個 code 重複申報是覆蓋還是拒絕（覆蓋＝後掛的套件可以偷換前面的啟動掛鉤）；② on_tasks_activated 掛鉤收到的 job_ids／tenant_id 從哪來、掛鉤能不能拿到別租戶的任務 id。首腦核對：未開檔，工具未報時人工查證。
• 四張附屬表的查詢有沒有專案／任務範圍條件：task/infra/repository/device_reference_query.py、flow_control_job_comment_repo_impl.py——SQL 有沒有 join 回 job_executions 再限定專案，還是直接拿 job_uid 查。表無租戶欄（job_execution_comments 2,829／_devices 3,016／_org_units 3,019／_surveys 0 筆）。（工具未報時人工查證）
• 留言 entity 的內容欄有沒有上限與型別限制：task/domain/entities/flow_control_job_comment_entity.py、task/infra/model/job_execution_comment.py——內容是任意字串進 text 欄？有沒有長度上限？儲存型 XSS（就是「存進去的內容被前端當程式碼執行」）面本棒只記錄不追 FE。
• 儀表板 domain service 與 repo interface：flow_control_dashboard_domain_service.py、i_flow_control_dashboard_repo.py——儀表板統計的查詢介面有沒有強制帶專案／租戶參數，還是允許「不帶就全部」。
• task/domain/ports.py（137 行）：套件向宿主要的介面契約——哪些方法是 Optional、缺了會怎樣。與 P3 的守門殼對照，本棒只看 port 定義本身。
• 設備參照查詢：device_reference_query.py 跨到 jedi-asset 的表——join 條件有沒有租戶限制、job_execution_devices 指到的設備能不能是別租戶的。

已知背景（只是參照，不當本棒發現）

授權判定怎麼流（首腦 2026-09-14 開檔核對，行號可直接打開）：

• 守門函式（就是「檢查你有沒有資格做這件事」的那幾段程式）在宿主 BE repo common/authz/project.py（120 行）：assert_project_manager :16-30／assert_project_role_fallback :33-57／assert_project_role :60-98／assert_project_participant :101-120。守門函式本身沒有 fail-open（fail-open 就是「查不到就放行」的壞習慣）：查不到角色就 raise、沒有拿租戶代替專案、沒有 super_admin 短路。
• 角色查詢在套件 participant/app/service/participant_role_service.py:33-83，三層往上找：project_control_participants → control_group_participants → project_participants → 都沒有就回 None。
• 🔴 真正的 fail-open 不在守門函式，在呼叫端的條件包裝——「有注入守門服務才檢查、沒注入就跳過」這種寫法。本 arc 的疑點多數是這一型。
• 接線：宿主 core/plugins/participant.py:90-102 的 adapter → 套件 participant/common/guard.py:26-52 的 configure()；沒接線時 :45-49 直接 raise、不放行（這一段是好的）。task 那一半的三道守門（license／project_role／identity）在 core/plugins/task.py:89-98，與 jedi-compliance-audit 共用同一組 adapter。
• 套件 participant 那一半沒有能力點守門（能力點＝「這個帳號買了／被授權了哪些功能」）：participant/api/guards.py:10-12 的 CAPABILITIES 是空 tuple，入口只有宿主注入的 jwt_required（只驗「你有登入」）。