本卡屬 FR-114 資安修正（母卡 CM-2019），第 1 批「權限地基」卡 1-6，修 SUMMARY #43 權限資料半／#112（出自 M19-1／M19-2）。中。修法規格來自內化卡，計畫在 docs/features/FR-114-2609-security-fix-dispatch/batches/plan-b1.md「卡 1-6」段。🔴 本卡依賴卡 1-9（Group B）的權限資料 migration 先套到 DEV——七支讀取端點補上權限檢查後，若缺這個能力點的角色沒有先被授權，會讓對應的下拉選單畫面「靜默變空」而非報錯，1-9 的 migration 先補齊角色的能力點才不會出這個狀況。

問題是什麼（白話）

#43（權限資料半）：資產模組的七支讀取端點（設備、資訊系統）目前沒有做能力點檢查，任何登入帳號都能讀取。

#112：只給了修改權限、刻意不給刪除權限的操作人員，直接送一個「停用」欄位就能讓資訊系統從所有選單與清單裡消失，等於變相繞過了「不給刪除權限」的設計；另外更新資訊系統時如果沒帶 is_active 欄位，會被預設值重置成 True，造成「靜默重新啟用」的副作用。

首腦核對：

• capability_required 使用的能力名稱已凍結：device.read（contract.py:31）、information-system.read（contract.py:35），本卡直接用這兩個名字，不要另外取名
• AssetPluginConfig（contract.py:66-78）需要新增 2 個設定欄位＋對應 DEFAULT_* 常數，供這兩個能力點掛載使用
• 資產模組有 5 個下拉選單畫面會消費這些資料——如果缺這個能力點的角色沒有先被授權（卡 1-9 的權限資料 migration 要做的事），畫面會「靜默變空」而不是報錯，很難察覺，這是 1-9 必須排在本卡之前的原因
• information_system_entity.py:27 的 is_active 欄位有預設值 True，這是造成「更新時沒帶欄位就被重置成啟用」的直接原因

工作區

套件側：在 /Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/.claude/worktrees/jedi-wt-fix-security/jedi-asset（branch fix/security-b1）改，只動自己那支套件的子目錄、只 git add 該子目錄下的檔。

跨 repo：BE 工作區 pyproject.toml 把 jedi-asset 的 pin 改成 path 形式指向上面那個套件 worktree，poetry update jedi-asset。這個 path 改動不 commit（git add 時跳過 pyproject.toml）。

在哪裡

device_route.py:37-38                補 capability_required("device.read")
device_route.py:56-57                同上
device_route.py:68-69                同上
device_route.py:106-107              同上
information_system_route.py:42-43    補 capability_required("information-system.read")
information_system_route.py:59-60    同上
information_system_route.py:102-103  同上
contract.py:31   device.read 能力名稱定義處（凍結，直接引用不改名）
contract.py:35   information-system.read 能力名稱定義處（凍結，直接引用不改名）
contract.py:66-78  AssetPluginConfig，新增 2 個設定欄位＋DEFAULT_* 常數
information_system_entity.py:27  is_active 預設值 True，造成靜默重新啟用的根因

怎麼修

• ① 七支讀取端點（device_route.py 四處、information_system_route.py 三處）各補上對應的 capability_required 裝飾，名稱固定用 device.read／information-system.read
• ② AssetPluginConfig（contract.py:66-78）新增 2 個設定欄位與 DEFAULT_* 常數，讓這兩個能力點能被掛載設定
• ③ #112 兩個方向都要修：一是 is_active 欄位從「更新」schema 移除、改成需要另外的刪除權限才能操作停用；二是修正「更新時未帶 is_active 就被預設值 True 重置」的靜默重新啟用副作用——更新時若未帶該欄位，維持原值，不套用 entity 預設值
• ④ 具體選哪個方向（拿掉欄位 vs 要求刪除權限）：兩個都做——移除 update schema 的 is_active、同時修正預設值重置的副作用，一次把「繞過刪除權限」跟「靜默重新啟用」兩個洞都堵上

手測