本卡為 FR-084 母案。掃 jedi-integrity 套件（防竄改與離線解鎖機制）21 檔，一棒完成，宿主接線太小併入卡片背景。只掃不修。 子卡清單在末段。

這系列在做什麼（白話）

落地版產品是編譯成一支程式、裝在客戶自己的機器上。客戶（或客戶機器上的任何人）可以直接改檔案。jedi-integrity 是防這件事的機制：開機時逐檔核對「原廠簽過名的檔案清單」，被改就拒絕啟動、留下紀錄、把畫面換成「系統已鎖定」；只有原廠簽發的一次性解鎖檔能解。這個 arc 要回答的是：這套保護能不能被繞過、被關掉、或被拿來搗亂。

為什麼要做

• 風險形狀與前七個 arc 不同：前面掃的是「誰能看到不該看的資料」，這支被攻破的後果是「保護失效」——產品被改了但沒人知道、或客戶機器被鎖但解不開。
• FR-076 曾在它身上順手撞到一條 HIGH（CM-1572 無界解壓縮，已修），那次是掃 License 鏈時越界撈到的，這支從來沒被專門掃過。
• 不在 FR-080 整併名單裡（design 標「不動」），掃完的結果永久有效。

首腦讀完後的重點

• 整套保護只有一個開關：is_packaged()（宿主 common/util/resource_path.py:26）。它回 False 就跳過全部檔案核對，只剩「有沒有鎖定標記」這一道。
• 啟動時只看檔案系統，不看資料庫。README 說「DB 與檔案標記任一存在即拒啟」，但程式碼裡啟動閘門從不查 DB（TamperEventRepo.exists 零呼叫者）——刪掉一個標記檔就能重啟。
• 鎖定標記、解鎖檔、已用 nonce 帳三樣放同一個可寫目錄（/opt/guidant/pki），而 nonce 帳毀損時刻意取寬鬆側。
• 驗簽章用的 cryptography 函式庫可能落在啟動時不核對的第三方層——如果是，換掉它就能讓任何簽章都通過。這件事要對照 build 腳本查證。

怎麼拆

• 只切一棒：套件 21 檔（20 支 Python 加 1 支 SQL）。宿主接線只有 common/integrity/adapters.py（357 行）加 5 個呼叫點，不值得單獨跑一棒，首腦已全文讀完寫進子卡背景（比照 FR-082 的做法）。

共同設定

• runner 主 session Opus 5 (1M context)、effort low、focus attack-surface。理由見首腦手冊第一節。
• 一次只跑一棒、不與其他掃描並行（FR-081 換來的：面板撞額度的主因是額度競爭不是檔數）。

共同紀律

• 只掃不修、不自派 subagent 做主工作、不自己啟動掃描（指令由決策者親手打）、做完 commit＋回寫不等令、push 等令、branch 不切。
• 報告與回報一律白話（首腦手冊第十節，硬規則）。