本卡為 FR-098 母案。掃 jedi-asset 這支套件——它管兩種資產：客戶的設備清冊、以及客戶的資訊系統清冊。切兩棒共 60 個檔案，只掃不修。子卡清單在末段。

這系列在做什麼（白話）

這支套件管兩張清冊：設備（客戶有哪些機器、伺服器）與資訊系統（客戶有哪些系統，例如人事系統、財務系統）。這兩張清冊是稽核工作的對象——稽核任務執行時會指向某台設備、某個系統，合規文件裡也會引用它們。

這一系列要回答的問題是：誰看得到、誰改得動這兩張清冊，以及客戶之間有沒有真的隔開。

為什麼要做

這支套件從來沒有被掃過。而且它與其他支不同的地方在於：它存的是客戶自己的資產清單（機器名稱、系統名稱、負責人），屬於客戶的營運資訊；而且它被稽核流程、問卷、合規文件三個地方引用，是個交叉路口。

🔵 開卡前實查，這支的資料庫隔離做得比先前幾支好：兩張表都開了隔離、各有四條規則、都有客戶歸屬欄位（首腦 2026-09-16 對開發環境唯讀查證）。所以本系列的重點不在「隔離有沒有開」，而在「程式這一層的權限檢查夠不夠」——這與前幾支（FR-086／FR-095 那種資料庫層全空）的風險形狀不同，切棒與重點都照這個判斷來排。

首腦讀完後的重點

• 🔴 最大疑點：讀取類端點全部只檢查「有沒有登入」、沒有權限檢查，而寫入類每一個都有。 首腦開檔核對兩支路由檔：設備的清單、選單、明細、被引用查詢，以及資訊系統的選單、清單、明細——全部只掛「要登入」；而新增、修改、刪除每一個都多一道權限檢查。這與 2026-09-15 在 FR-096 查到的第 72 項是完全相同的形狀（讀取漏掉、寫入都有），該案已證實成立並登記為高風險。
• 八個權限點全部是客戶層級（首腦開發環境實查：device.* 與 information-system.* 各四個，平台層旗標都是 false）。這本身是正確的——資產清冊本來就該由客戶自己管。但要確認的是：客戶層級的權限，有沒有配上客戶層級的資料範圍。
• 兩張表的隔離設定刻意不一樣，理由寫在腳本檔頭。 資訊系統那張開了「強制隔離」（連表的擁有者都擋），設備那張刻意只開一般隔離、沒開強制——檔頭說明是因為設備的新增規則沒有留管理員逃生門、且要求部門相符，開了強制會擋掉沒有部門歸屬的使用者。這是刻意取捨、不是疏漏，但要查取捨的代價是什麼。
• 這支被三個地方引用，是交叉路口：稽核流程的任務執行（三支查詢直接 import 設備的資料模型）、問卷、合規文件的資源庫。跨模組引用時，原本的隔離與權限檢查會不會被繞過，是本系列要看的接縫。

怎麼拆

• 第 1 棒 A1 設備全鏈（45 檔）— 設備那半的完整路徑（14 檔）＋ 套件共用骨架與三支 SQL（31 檔）。共用骨架放這一棒是因為它要先被讀過，第 2 棒才有對照。風險較高（設備那張沒開強制隔離），先跑。
• 第 2 棒 A2 資訊系統全鏈（42 檔）— 資訊系統那半的完整路徑（15 檔）＋ 共用骨架重疊帶入（27 檔）。

檔數說明：兩棒相加是 87，但共用骨架 27 檔兩棒都算，去重後套件實際是 60 個檔案。兩份檔數都在開卡當下實跑 git ls-files 驗過。

建議順序：A1 → A2，一次只派一棒，每棒獨立驗收完才派下一棒。

⚠️ 共用骨架兩棒重疊是刻意的：套件的守門殼、插件契約、錯誤碼、資料存取底層是兩半共用的，切在接縫上會讓兩棒都看不到全貌。重複報由首腦驗收時挑掉——接縫沒人看才是真的損失。

⚠️ 主專案宿主接線 12 支兩棒都不含，會與 jedi-log 的根層 6 支合併成獨立一棒（共 18 檔，BE repo）。跨 repo 必須分棒，工具一次只吃一個掃描根目錄。那一棒等這兩棒跑完再開卡。

共同設定