本卡屬 FR-132（母卡 CM-2510），A.3 判定層第 5 張。依賴：T-3.3。建議 model：fable。

這張卡做什麼（白話）

角色不分部門，指派才分部門（user_roles.org_unit_id）。定案判法是「範圍套在資料上」：掛在部門 X 的指派，在使用者碰的資料列部門落在 X 子樹內時有效；使用者本人所屬部門不參與判定。

這張卡做兩件事：① 有效指派取回時帶上指派部門的 path；② 新增 require_capability_on(cap, org_unit_id) 給單筆寫入用——某人在 A 部門是編輯、在 B 部門是唯讀，route 層會因 A 那筆放行 update，只有比對「是哪一筆指派給的這個能力點」才擋得住他改 B 的資料。部門隔離開關（D12）關著時，它等同 require_capability，升級無感。

在哪裡

~/Projects/Jedicogy/module/jedi-python-package/jedi-iam/jedi_iam/infra/repository/active_role_conditions.py:19-39      有效指派條件
~/Projects/Jedicogy/module/jedi-python-package/jedi-iam/jedi_iam/infra/models/user_role.py:20-84      user_roles：org_unit_id、scope、starts_at、ends_at
~/Projects/Jedicogy/module/jedi-python-package/jedi-iam/jedi_iam/infra/models/org_unit.py:17,32      org_units.path（例 /10/12/）
~/Projects/Jedicogy/module/jedi-python-package/jedi-iam/jedi_iam/authz/capability.py      新增 require_capability_on
~/Projects/Billows/Audit-Manager/compliance-manager-be/common/authz/__init__.py      主專案 re-export（主體域實作在套件，shim 不補邏輯）

怎麼做

• 有效指派查詢回傳 (role_id, org_unit_path | None)；租戶指派為 None。
• require_capability(cap)：任一有效指派（租戶或部門）給了 cap 就放行——與今天相同。
• require_capability_on(cap, org_unit_id)：開關關時等同 require_capability；開關開時，要求「給了 cap 的那筆指派」是租戶指派，或其部門 path 是資料列部門 path 的前綴（上層涵蓋子部門，D4）。資料列 org_unit_id 為空時視同租戶資料，任一給了 cap 的指派即放行。
• 開關值讀 tenants.org_unit_isolation（T-2.3）；取得方式與 T-3.6 共用，避免兩處各讀一次。
• super_admin、系統管理員（is_system）一律放行。
• 從 common.authz re-export 新函式；不在 shim 內補邏輯（守衛測試會擋）。本卡不掛到任何 route（T-4.4 掛）。

要寫測試

• A 部門編輯＋B 部門唯讀的帳號：開關開時 require_capability_on('…update', B 部門資料) 擋、A 放行；開關關時兩邊放行。
• 上層部門指派涵蓋子部門資料。
• 突變：把前綴比對改成相等比對，子部門測試紅。

驗收條件

• A 部門編輯＋B 部門唯讀的帳號，開關開時改 B 部門資料被擋、改 A 放行；開關關時兩邊都放行。

手測