本卡屬 FR-098（母卡見子卡清單），第 1 棒：設備全鏈＋套件共用骨架（jedi-asset 套件）。只掃不修。

這一棒在做什麼（白話）

「設備」是客戶的機器清冊——有哪些伺服器、哪些電腦、歸誰管。稽核任務執行時會指向某台設備，所以這張清冊是稽核工作的對象之一。

這一棒掃設備那半的完整路徑（14 個檔案），外加套件的共用骨架與三支資料庫腳本（31 個檔案）——守門殼、插件契約、錯誤碼、資料存取底層，這些是設備與資訊系統兩半共用的。

要回答的核心問題：誰看得到、誰改得動別家客戶的設備清冊。

為什麼切這一塊

共用骨架放在第 1 棒，是因為它要先被讀過、第 2 棒才有對照基準。設備那半排第一是因為它的資料庫隔離刻意沒開「強制」模式（見下方重點③），風險比資訊系統那半高。

重點看什麼

這些是首腦 2026-09-16 開檔看過的，行號與內容屬實。不是要你重新確認，是要你從這裡往外追：

• 🔴 ① 本棒最重要：讀取類端點全部沒有權限檢查，寫入類每一個都有。 首腦開檔核對 jedi_asset/api/routes/device_route.py：清單（:37）、選單（:56）、明細（:68）、被引用查詢（:106）全部只掛 @auth_required（只驗有沒有登入）；而修改（:78）、刪除（:90）都多掛了 @capability_required。這與 FR-096 第 72 項是完全相同的形狀（讀取漏掉、寫入都有，該案已證實成立並列為高風險）。要追：這四支讀取端點實際回什麼、有沒有跨客戶、DeviceReferenceRoute（被引用查詢）會不會透露別家客戶的關聯資訊。
• ② 送空條件會不會回整張表。 清單端點的查詢條件放在請求內容裡（DevicePageQueryRequest）。要追：條件欄位是不是全部非必填、送空的會回什麼。⚠️ 若命中，請標明歸「共用底層送空條件回全表」那條線（跨 arc 總表 §3.1 第 70 項，源頭在 jedi-common 的資料存取底層），不要當獨立發現升級。
• ③ 設備表刻意只開一般隔離、沒開「強制」模式。 migrations/002-asset-rls-grants.sql 檔頭明寫：資訊系統那張開了 FORCE ROW LEVEL SECURITY（連表的擁有者都擋），設備這張刻意只 ENABLE 不 FORCE，理由是「設備的新增規則沒有管理員逃生門且要求部門相符，開了強制會擋掉沒有部門歸屬的使用者」。這是刻意取捨、不是疏漏。要追的是取捨的代價：在什麼情況下表的擁有者身分會被用到（開發環境的擁有者正好就是應用程式連線帳號本人，檔頭自陳在那種情況下「只開 ENABLE 等於沒開」——那句話是針對資訊系統寫的，但設備這張正是只開 ENABLE）。
• ④ 四條隔離規則的實際內容。 首腦實查：設備表有四條規則（查／增／改／刪各一）。要追：四條的條件是不是一致、有沒有哪一條的範圍比其他寬、新增那條要求部門相符會不會讓某些使用者永遠新增不了（檔頭自己提到這個風險）。
• ⑤ 共用骨架的守門殼。 jedi_asset/api/guards.py 與 plugin/contract.py、plugin/assembly.py 定義「宿主要填哪些插槽」。要追：必填插槽沒填會怎樣（是拒絕啟動，還是靜默放行）——這是本專案反覆出事的形狀（跨 arc 總表 §6 第 13 項就是「零件沒組裝進去就直接放行」那種寫法）。
• ⑥ 三支 SQL。 001-asset-tables.sql（建表）、002-asset-rls-grants.sql（隔離規則與授權）、003-asset-ui-routes.sql（選單與權限綁定）。要追：授權範圍會不會過寬、選單那支重複執行會不會覆蓋客戶改過的值、外鍵設定有沒有讓刪除行為出乎意料。

🔴 已經查證過的，掃到不要重報

這三件首腦在開卡前已開檔／連資料庫核對過，掃到請標「已知、非本棒新發現」：

• 兩張表的資料庫隔離都有開、都有客戶歸屬欄位。 開發環境實查：設備表開了隔離、四條規則、有客戶欄位（3 筆資料）；資訊系統表開了隔離且是強制模式、四條規則（91 筆資料）。這支的隔離做得比先前幾支好——不要沿用 FR-086／FR-095 那種「資料庫層全空」的預期。
• 八個權限點全部是客戶層級（device.* 與 information-system.* 各四個，平台層旗標都是 false）。這是正確的——資產清冊本來就該由客戶自己管，不要報成「權限層級標錯」。
• 資訊系統那半（15 檔）不在本棒範圍，屬第 2 棒。讀到不要當本棒發現報。