FR-069 主專案功能模組化——jedi-* 套件抽取計畫 — 設計文件

狀態：第一階段執行中（P0 進行中）｜建立日期：2026-08-29 討論脈絡：本案無獨立討論稿——盤點（三棒平行探勘）與拍板均在對話中完成，決策脈絡完整收錄於本文件 §3 決策定案表。

主專案（compliance-manager-be）歷經多輪功能開發，累積約 40 個註冊模組、1500+ 個 py 檔，多數功能未模組化——所有能力都長在主專案內，未來其他產品要複用相同功能（遠端 agent、授權驗證、防篡改、log 轉發…）時無法直接轉移套用。本案目標：把可通用的功能抽成 jedi- 外部套件*，放進既有 monorepo（~/Projects/Jedicogy/module/jedi-python-package/，已有 20 個套件），未來新產品以 poetry 依賴直接安裝複用。

盤點關鍵事實（2026-08-29 三棒平行探勘結論）

• 核心不可分割環：participant ↔︎ flow_engine ↔︎ grc ↔︎ associations ↔︎ oscal ↔︎ module_frame 六模組互相雙向引用、直接穿透 ORM model，合計約 760 檔（超過全專案一半）——這一團是產品本體，第一階段不切片。
• 外圍有一圈乾淨的葉節點：約 8 個模組零跨模組依賴、只吃 common/ + jedi_common，是低風險抽取候選。
• common/ 不能整包搬：需三分——真橫切的進 jedi-common、授權語意的進 jedi-auth、業務語意的歸位回各模組。且 common/ 現有 9 條反向 import 上層（違反分層方向），是搬遷前的硬前置。
• 抽取先例已存在：jedi-information-system（FR-032 G）是從主專案抽出的成功範本——import 名不變、IUserLookup 窄介面解耦、套件不含 api 層、守衛測試防回歸。本案全程沿用該配方。
• 依賴方向的關鍵洞見：模組能不能抽，看的是它「往外依賴多少」（out-degree），不是「被多少人依賴」（in-degree）——import 名不變，消費端不用改任何一行。此洞見決定了凍結路線圖中 participant 的定位（最大 hub 卻最先能抽）。

整案一句話：先清理地基（P0），再把六支零耦合的基礎設施模組抽成新 jedi 套件（P1–P5），最後把 common/ 的橫切能力上移進 jedi-common 與 jedi-auth（P7–P8）；核心業務模組的抽取凍結成路線圖，等這一輪做完拿實際成本數據再議。

依賴一句：P0 是 P7/P8 的硬前置；P1–P5 彼此獨立可平行派工；每支套件抽完都要等發版上 Nexus 才能 commit 主專案的目錄移除。決策者功課：每階段收口時做上表「檢查法」欄的手測。

插件契約補充：身分脈絡標準件（D8 併入 D6 契約）

• 規則：凡套件 API 會吐 created_user / updated_user / tenant_id / org_unit_id 或業務性 user 參照（如 matched_user_id）者，套件必須內建對應名冊 port 並在 app 層批次 enrich（*_user_name、租戶名、單位名）；純引擎型無此輸出者免做——標準是「有吐才要補」，不是每支硬裝。
• 名冊 port 一族（皆同構：批次 id→名稱、選填、不注入優雅降級不炸）：
  • IUserNameResolver——帳號批→顯示名稱。P3 jedi-log-forwarding 已有樣板（批次防 N+1、選填、降級顯示帳號），為本標準件的參考實作。
  • ITenantResolver——tenant_id 批→租戶名稱。
  • IOrgUnitResolver——org_unit_id 批→單位名稱。
• 收斂設計：第二階段在 jedi-common 定義共通「身分脈絡包」（identity context）——套件宣告需要哪幾張名冊、宿主接線時一次注入一組，避免 20 支套件各自定義微妙不同的簽名再度發散。
• 多租戶欄位規則（引用 P4 先例）：tenant / org_unit 欄位在 001 腳本建 nullable、002（需宿主 RLS 生態）才收緊 NOT NULL——套件必須在多租戶與單租戶宿主都能活。
• 禁止：套件 JOIN 宿主 user / tenant / org 表、認得宿主身分模型——一律透過名冊 port 問。
• 現況註記：P1 / P2 / P4 / P5 未內建名冊（其管理面不吐稽核欄位，當時無需求）——不回補，第三階段統一過一輪時順手做；主專案現有 28 處 app 層自行補名屬歷史重工，隨第三階段各套件升級逐步刪除。

4.1 全模組四分類

4.2 耦合分析重點

• P1–P5 候選全部是葉節點：零跨模組 outgoing（license 僅 1 條對 notification 的細線），且除 DI 註冊行外無任何模組 import 它們。
• hub 排行：participant（in-degree 10、被 import 60+ 次，但 out-degree 僅 8——凍結路線圖的鑰匙）、flow_engine（in 9）、notification（in 8 但廣而淺）、system_config（in 7）、grc（in 7 + out 11，雙向樞紐）。
• di_containers/containers.py 是隱形 hub（401 行、43 個 import）：每次抽取都要同步改註冊，是每支套件的固定成本，各 arc 驗收條件都含這一項。

4.3 必須先修的架構債

4.4 common/ 三分法（P7/P8 的搬遷清單基礎）

P0 前置清理（不抽東西，先還債）

驗收：上述 grep 為 0；BE 啟動正常；檔案上傳、任一稽核頁面手測正常；flow_control 改名三判準（import 殘留 0 / 字串值未動 / 主流程手測）全過。

P1 jedi-ai-bot（SOP 練手＋插件契約首例）

• 內容物（D6 升級後）：api/ai/（blueprint / route）與 app/ai/（AiBotService，Anthropic Claude + Redis 對話）一併進套件——套件自帶 api 層 + 預設 DI container + register(app, adapters) 註冊入口（本模組無 migration，migration 隨包機制的首例落在 P2–P5 中第一支有表的套件）。6 檔，最小案例。
• 契約定義責任：P1 是 D6 插件契約的第一個實作——register() 簽名、blueprint 掛載方式、container wiring 慣例、拔掉測試步驟，全部在本 arc 定案並寫進 SOP checklist，P2–P5 照抄。
• port：無——只依賴 jedi_common 與 Redis client（隨包或注入均可，傾向注入 redis client）。
• D7 責任：harness ＋接入 README 由 P1 首做並寫進 SOP checklist——dev_app.py ＋ compose（本模組吃 Redis，compose 起獨立 Redis）＋套件測試獨立跑；接入 README 含 port 清單 / 註冊行 / quickstart。
• 驗收：套件上 Nexus、主專案 pin、AI 聊天手測正常、守衛測試綠、拔掉測試通過（註解 app_modules.py 註冊行 → BE 正常啟動、AI 聊天路由消失、其餘功能不受影響）、harness 起得來且套件測試在 harness 內全綠（D7）、接入 README 完成且照它 10 分鐘能在 harness 重現 quickstart（D7）。本 arc 同時產出「抽取 SOP checklist」文件（供 P2–P5 復用，必含拔插驗證與 harness/README 步驟）。

P2 jedi-integrity

• 內容物：app/infra/di 的 integrity 模組 + common/integrity/ 全包（lockdown / startup_gate / runtime_check / tamper_marker / forensic / lc_report / unlock）。
• 注意：startup gate 在 main.py 啟動鏈上被呼叫——套件需提供清楚的公開入口函式；與 FR-064 的 manifest/簽章產線（scripts/build/）的檔案座標約定要在套件 README 寫明。
• port：無跨模組線。config.config 的讀取改為初始化參數傳入。
• 驗收追加（D6）：拔掉測試通過；插件契約形式照 P1 定案的 SOP（自帶 api 層如適用 / container / register 入口 / migration 隨包）。
• 驗收追加（D7）：standalone harness ＋接入 README 齊備，形式照 P1 SOP。

P3 jedi-log-forwarding

• 內容物：log_forwarding 模組全層 + common/log_forwarding/（forwarder / gelf_handler / settings_reader）。
• 要斷的線：1 條 jedi_auth 細線（設定 CRUD 的權限判斷）——本來就該走主專案 route 層守門，套件內移除。
• 注意：QueueHandler 掛載點在 logger 初始化鏈，同 P2 提供公開入口函式；「轉發失敗不拖垮主服務」的靜默降級行為要有套件內測試。
• 驗收追加（D6）：拔掉測試通過；插件契約形式照 P1 定案的 SOP。
• 驗收追加（D7）：standalone harness ＋接入 README 齊備，形式照 P1 SOP。

P4 jedi-remote-agent

• 內容物：remote_agent（註冊/enroll token/心跳）+ agent_task（派工/查詢）+ common/util/agent_auth/（ca/tls/jwt/heartbeat mTLS）。約 87 檔，第一階段最大宗。
• 要斷的線：remote_agent → jedi_file_upload（agent 上傳結果檔）保留——jedi 套件依賴 jedi 套件是合法邊（比照 jedi-issue → jedi-file-upload 先例）。
• port：IAgentTaskPayloadProvider 之類的派工內容組裝介面——檢測派工的 params 組裝屬產品知識，留主專案實作注入；套件只管「派工信封」的生命週期（pending/領取/回報/逾時）。
• 注意：憑證與 CA 檔案路徑全部參數化；detection_tools 對 agent_task 的消費照舊（import 套件）。
• 驗收追加（D6）：拔掉測試通過；插件契約形式照 P1 定案的 SOP。
• 驗收追加（D7）：standalone harness ＋接入 README 齊備，形式照 P1 SOP。

P5 jedi-license-runtime

• 內容物：license 模組全層 + common/license/（engine / machine_fingerprint / public_keys / schema）。
• 要斷的線：1 條 → notification（到期通知）。套件內定義 INotifier（notify(recipients, subject, body) 級別的窄介面），主專案 adapter 包 jedi_notification。
• 注意：PUBLIC_KEYS 常數的更新流程（多環境簽發鑰四步一組）要寫進套件 README；common/integrity 若有交叉引用，依 P2 先行的套件邊界處理（license-runtime 依賴 jedi-integrity 是合法 jedi 間邊）。
• 驗收追加（D6）：拔掉測試通過；插件契約形式照 P1 定案的 SOP。
• 驗收追加（D7）：standalone harness ＋接入 README 齊備，形式照 P1 SOP。

P7 jedi-common 擴充

• 內容物：§4.4 第一列清單上移。分兩批 commit：①response_util（影響 124 檔的解析位置，單獨一批全量回歸）②其餘 util + error code 基底 + 通用 enum。
• 硬要求：全量回歸——既有 pytest 全跑 + 主要頁面手測清單（因 jedi-common 被 42 個模組、20 個套件依賴，此 arc 是全案風險最高點之一）。
• 注意：jedi-common 版本 bump 後，monorepo 其他套件的 >= 約束不需動；主專案 poetry update jedi-common 一次收攏。

P8 authz 主體域併 jedi-auth

• 前置：P0-② 完成（反向邊已斷）、P7 完成（decorators 若引用通用 util，先等它們就位）。
• 內容物：common/authz/ 的 platform / admin / capability / decorators / signed_token 進 jedi-auth 新子包 jedi_auth/authz/；資源域四支留原地。
• 相容策略：common/authz/__init__.py 保留 re-export shim（主體域符號轉 import jedi_auth.authz），消費端 32 個模組零改動；shim 標 deprecated，後續新 code 直接 import jedi_auth。
• 驗收：admin / manager / auditor / 一般使用者四種角色的權限行為全數與改前一致（比對主要守門點清單逐項手測）。

每個 arc 共同的固定項目：di_containers/containers.py 註冊同步、config/app_modules.py 同步（如適用）、jedi-packages.md 補該套件一段、Notion 子卡回寫、extract→publish→pin 順序紀律。

2026-08-30 D8 拍板：原「凍結路線圖」全解凍，「等第二消費者」原則廢除——整併本身即目標。各階段先後與交錯於第一階段（P0–P8）總結時排定；下表順序為建議序。

第二階段：ext 表收斂＋JSONB 擴充容器

2026-08-30 盤點定案（D15，phase2-ext-table-inventory.md）：掃 190 張實體表，真正的延伸表 9 張、純展示型 0 張——本系統的側掛表不是「客製欄位」長出來的，是「跨套件邊界」長出來的（主表在套件、產品欄位沒地方放才側掛）。故本階段實作重點由「JSONB 容器消化存量」調整為「跨套件側掛欄位收回主表正式欄位」；JSONB 容器定位改為預防性建設——今後新客製一律走容器、不再開側表（查詢能力已由 CM-1448 落地 jedi-common）。

• 盤點：✅ 已完成（CM-1447，2026-08-30）——9 張延伸表去向：收回主表 1（project_extensions）、留置 6、待查證 1（assessment_plan_extensions 孤兒表，另開 case）、結構異常另記 1（ssp_system_characteristics 缺唯一性約束）。
• 收斂實作（CM-1449）：首批對象＝compliance.project_extensions（D15；原「auth/user 優先」經盤點證實無收斂對象，已改）。「只加不破」五步搬遷（加欄位→回填→雙寫期→逐處切讀取→觀察後 drop）＋帶舊資料升級驗證；主要風險＝14 處手寫 SQL JOIN（散 9 檔，改漏不報錯只靜默少過濾軟刪除）＋主表屬 jedi-project 套件（加欄位走套件異動規範）。
• jedi-common 查詢層補能力：✅ 已完成（CM-1448，2026-08-30）——JSONB 擴充欄位查詢/排序（_ext_* 前綴族）、身分脈絡包三名冊、SessionMixin 正名皆落地，未發版。
• 判斷口訣：只是「多記幾個值」→ JSONB 容器；要「拿來運算/關聯/約束」→ 正式欄位（或客戶側開表）。

jedi-common 基底類正名案（2026-08-30 調查定案）

• 調查結論：session/database/ 頂層 base_repository.py（7 行 session property）不是舊代殘留——它是 lazy session 提供者（mixin），repository/base_repository_impl.py 的完整查詢基底自己就繼承它（class BaseRepositoryImpl(IBaseRepo[T, Q], BaseRepository, ...)）。兩者是「連線底座 vs 完整基底」的零件關係，不是新舊兩代。
• 合法用法認定：主專案 5 檔（cloud_integration 3 支 raw-SQL repo／bulletin link 表／upload_file HTTP adapter）與老套件 27 處直接繼承底座，多屬「特殊 repo 不適用完整基底、只需 session」的合法情境（同 CLAUDE.md「不能繼承 BaseRepositoryImpl 時自己寫 @property session」條）——不做汰換。
• 真問題＝命名混淆：底座與 repository/base_repository.py（查詢介面）同名不同角色，會誤導讀者當成待淘汰舊版——本案調查即因此差點誤發一輪假清理。
• 第二階段動作三條：
  1. 底座正名（如 SessionMixin；挪位與否屆時定），舊名留轉發（32+ 處引用零即刻改動）。
  2. 頂層 base_model.py 為真重複（與 model/base_model.py 內容漂移）且全生態 0 引用——直接刪。
  3. 第三階段各套件升級棒「順手看一眼」該套件對底座的繼承是否真屬特殊 repo（預期多數合法），不再列為汰換欠帳。
• 教訓註記：同名不同角色的基底類是「假清理」誘因——收斂靠正名，不靠強制遷移。

第 2.5 階段：jedi-iam 身分套件合併（D9）

插在第二階段（表收斂）之後、第三階段（補殼）之前——先合併再補殼＝補 1 次；先補殼再合併＝補 5 次扔 4 次。完整決策內容與數據支撐見 §3 D9。

疆界盤點案（FR-069.9，第四階段前置，與第二階段平行）

純分析案不動碼。第四階段的開工門檻——P6／P9–P13 各棒開工前必須先有疆界地圖定案。動機：以前按技術功能切太碎，26 支裡不少是「同一個能力被切成幾半」（jedi-iam 案已證實一組）；先畫清疆界再動工，避免抽完又要合。

方法（照 jedi-iam 案的同一套判準與分析深度）：①實際耦合數據（跨套件 import 具體到符號、穿透層級）②發版歷史（獨立生命有無兌現）③主專案膠水量化（A 產品特定／B 通用重寫／C 純重複三分類）④死碼盤點⑤pyproject 依賴健檢。

待驗證的疆界候選五組（初步假設，以數據為準）：

另兩項退役查證：jedi-log（vs 新日誌體系的重疊度）、jedi-oscal v1（vs v2 的取代狀態）。

產出物：「最終疆界地圖」——26 支現有套件＋主專案候選模組的完整去向表（合併／獨立補殼／退役／下架），供 user 拍板後改寫第三、四階段的棒次表。

願景：套件庫從 26 支細粒度零件收斂為約 12–15 支輪廓清楚的疆界套件。

第三階段：既有老套件升級插件模式

身分族已於第 2.5 階段合併為 jedi-iam——本階段補殼時身分族僅 1 支。補殼對象清單已按疆界盤點結果（2026-08-30 拍板 D10–D14）更新如下——同疆界者先合併再補殼，避免補完又扔。

每支補齊 D6/D7/身分脈絡標準件（老套件缺的是「插件的殼」，最難的解耦已完成，工程量比新抽輕），並執行 D16 基礎依賴 port 化（把直接 import 其他套件之處換成標準 port 四張——這是每支補殼的必辦項）。主專案側同步把每支的接線收斂成「一個接線檔」，並隨升級逐步刪除 28 處 app 層自行補名的歷史重工。

隨棒必做（追蹤卡 CM-1461）：2.5 階段與本階段各棒動到某模組的 route 註冊時，順手拔除該模組的裸路徑死端點（62 支總帳見卡——同 Resource 雙路徑註冊缺 handler、打了必 500 但 FE 零裸打；CM-1454 Postman 掃描發現），拔前確認 e2e/agent 無呼叫，拔後回卡勾銷。

第四階段：核心抽取（原 P9–P13＋P6，全解凍）

形態分流準則（D7-③，每支候選啟動前先過這關）

每支候選開工前，先判「插件 vs 服務化」：

• 服務化（License Center 模式：獨立部署、網路 API、自有 DB）——適用於有獨立生命週期的能力：自己的發版節奏、自己的擴縮容需求、可能服務多個產品實例（如檢測平台）。邊界是網路協定，想耦合都耦合不了，是最強的解耦形態。
• 插件（D6 契約：隨包安裝、進程內掛載）——適用於與宿主同進退的能力：跟宿主同版本演進、共享宿主的 DB/auth/tenancy（如 authz、integrity、log-forwarding 這類）。
• 判準問句：「這個能力壞了，是宿主整個停，還是可以降級繼續跑？」「它需要自己的資料主權嗎？」「同一套實例會服務多個產品嗎？」——三題任一為是，傾向服務化。

棒次順序（2026-08-31 user 拍板定序，卡號 CM-1475–1483 九張連號）——每棒一句排序理由：

終局選項（範圍縮減：2026-08-30 user 指示 flow_control 升格第四階段議程）

flow_control 拆出——移入第四階段議程（user 2026-08-30 指示；已確認指的是稽核執行業務層那 37 支 service／236 檔，非 flow_engine 的範本管理）：不再等商業決策，Phase 4 規劃時與 P13 同席討論。拆法已定調（user 同日拍板）：「先單純拆出、切分後議」——照 jedi-iam 驗證過的「先搬家、後裝修」路徑：第一步整包搬成套件（import 名不變、稽核業務邏輯原樣帶走、機械比對證明零行為改動），第二步「通用流程骨架 vs 稽核專屬業務」的切分等真實第二種流程（問卷審核等）要掛入時拿真需求當設計輸入再做——無第二消費者硬切必畫錯線。技術耦合：D12 已定 oscal → flow_control 單向依賴，OSCAL 疆界設計必須知道 flow_control 自己也會成為套件，否則拆完返工；排序（P12/P13 之前或之後）屆時拿依賴數據定，初步傾向 P12 之後（先解最粗的 participant 邊、搬家包袱最小）。

終局選項（仍等商業決策）：project 平台化——產品本體抽套件、主專案變組裝殼。等第二個合規產品線出現再議。

另案追蹤（不屬本案範圍）：RLS 覆蓋缺口——user_roles / user_tenants / user_org_units 三張授權關聯表未啟用 RLS（live DEV 實查確認），現靠「讀取都經過受 RLS 的 users/roles」間接保護；任何直查這三張表的新程式即為跨租戶洩漏風險。已另開獨立 Notion case 追蹤（D9 身分族盤點的附帶發現），不混入 FR-069。

🔴 本圖描述 D1–D16 拍板後的「目標架構」，不是現況——現況到目標的路徑見 §7 各階段章節。每次新決策改變套件版圖（合併定形、退役期滿刪除、查證翻案），本圖與下方狀態表同步更新，並在變更紀錄註記。決策編號引用以 §3 決策表為 canonical。

維護慣例：狀態表是維護主體（好 diff、好逐列更新），mermaid 圖是給人看全貌的輔助——改表必改圖，改圖必改表。

8.1 三層架構（實線＝允許的直接依賴）

架構只有一條實線規則：疆界插件只准直接依賴 jedi-common（層 0）；插件彼此絕不直接相依，插件間的協作一律經宿主（層 2）的接線盤走 port 注入（見 8.2）。

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#E2F0F1','primaryTextColor':'#14201F','primaryBorderColor':'#0E7C86','secondaryColor':'#EEF2F3','secondaryTextColor':'#14201F','tertiaryColor':'#FBFCFC','tertiaryTextColor':'#14201F','lineColor':'#4A5A5C','textColor':'#14201F','mainBkg':'#E2F0F1','nodeBorder':'#0E7C86','nodeTextColor':'#14201F','edgeLabelBackground':'#FBFCFC','titleColor':'#14201F','clusterBkg':'#FBFCFC','clusterBorder':'#E4EAEB','actorBkg':'#E2F0F1','actorTextColor':'#14201F','actorBorder':'#0E7C86','actorLineColor':'#C7D1D2','signalColor':'#4A5A5C','signalTextColor':'#14201F','labelBoxBkgColor':'#EEF2F3','labelBoxBorderColor':'#C7D1D2','labelTextColor':'#14201F','loopTextColor':'#14201F','noteBkgColor':'#F6EBD5','noteTextColor':'#14201F','noteBorderColor':'#9C6B12','activationBkgColor':'#EEF2F3','activationBorderColor':'#C7D1D2','sequenceNumberColor':'#FFFFFF'}}}%%
flowchart TB
    subgraph L2["層 2　宿主／產品（接線盤）"]
        HOST["Guidant AI 主專案<br/>核心業務（flow_control／OSCAL 應用層）<br/>＋各插件 adapter 接線＋資源域授權"]
    end

    subgraph L1["層 1　疆界插件（彼此不直接相依）"]
        direction TB
        subgraph L1A["身分與基礎服務"]
            IDENTITY["jedi-iam<br/>（2.5 階段成形：auth＋login<br/>＋mfa＋captcha＋身分中介層）"]
            NOTIF["jedi-notification"]
            FILEUP["jedi-file-upload"]
        end
        subgraph L1B["第一階段五支（已發版）"]
            AIBOT["jedi-ai-bot"]
            INTEG["jedi-integrity"]
            LOGFWD["jedi-log-forwarding"]
            RAGENT["jedi-remote-agent"]
            LICRT["jedi-license-runtime"]
        end
        subgraph L1C["疆界重劃中（第四階段定形）"]
            SURVEY["jedi-survey-suite（暫名）<br/>survey＋作答層（D10）"]
            DETECT["jedi-detection<br/>不含 device（D11）"]
            OSCALV2["jedi-oscal-v2 系<br/>（D12 查證後定形）"]
        end
        subgraph L1D["獨立補殼者（第三階段）"]
            OTHERS["jedi-device／jedi-bulletin／jedi-issue<br/>jedi-system-config／jedi-system-menu<br/>jedi-information-system／jedi-project<br/>jedi-flow-engine／jedi-log（存活半）"]
        end
    end

    subgraph L0["層 0　地基（唯一允許被直接依賴）"]
        COMMON["jedi-common<br/>session／查詢基底（含 JSONB）／例外<br/>身分脈絡包介面／SessionMixin"]
    end

    HOST --> L1
    L1A --> COMMON
    L1B --> COMMON
    L1C --> COMMON
    L1D --> COMMON

退役中（D13，標 deprecated 觀察一版後刪）：jedi-oscal（v1）、jedi-resource-store、jedi_system_log（jedi-log 的壞半）。已下架：jedi-department（org_units 重複概念）。這四支不入圖。

8.2 Port 接線（虛線＝介面宣告，宿主注入實作）

D16 通則的四張標準 port：插件宣告需要什麼形狀的服務，宿主接線時把提供方的實作（包成 adapter）注入——提供方與消費方互不知道對方存在。

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#E2F0F1','primaryTextColor':'#14201F','primaryBorderColor':'#0E7C86','secondaryColor':'#EEF2F3','secondaryTextColor':'#14201F','tertiaryColor':'#FBFCFC','tertiaryTextColor':'#14201F','lineColor':'#4A5A5C','textColor':'#14201F','mainBkg':'#E2F0F1','nodeBorder':'#0E7C86','nodeTextColor':'#14201F','edgeLabelBackground':'#FBFCFC','titleColor':'#14201F','clusterBkg':'#FBFCFC','clusterBorder':'#E4EAEB','actorBkg':'#E2F0F1','actorTextColor':'#14201F','actorBorder':'#0E7C86','actorLineColor':'#C7D1D2','signalColor':'#4A5A5C','signalTextColor':'#14201F','labelBoxBkgColor':'#EEF2F3','labelBoxBorderColor':'#C7D1D2','labelTextColor':'#14201F','loopTextColor':'#14201F','noteBkgColor':'#F6EBD5','noteTextColor':'#14201F','noteBorderColor':'#9C6B12','activationBkgColor':'#EEF2F3','activationBorderColor':'#C7D1D2','sequenceNumberColor':'#FFFFFF'}}}%%
flowchart LR
    PLUGINS["任一疆界插件<br/>（bulletin／license-runtime／<br/>log-forwarding／survey-suite …）"]
    HOST["宿主接線盤<br/>（register 時注入 adapters）"]
    IDENTITY["jedi-iam"]
    NOTIF["jedi-notification"]
    FILEUP["jedi-file-upload"]
    SYSCONF["jedi-system-config"]

    PLUGINS -. "①身分名冊 port<br/>（user／tenant／org 三名冊）" .-> HOST
    PLUGINS -. "②INotifier port" .-> HOST
    PLUGINS -. "③檔案存取 port" .-> HOST
    PLUGINS -. "④設定讀取 port" .-> HOST
    HOST -. 注入 adapter .-> IDENTITY
    HOST -. 注入 adapter .-> NOTIF
    HOST -. 注入 adapter .-> FILEUP
    HOST -. 注入 adapter .-> SYSCONF

8.3 逐套件狀態表（維護主體）

1. 六支新套件（ai-bot / integrity / log-forwarding / remote-agent / license-runtime）上 Nexus，主專案 pyproject.toml 以 == pin；jedi-common、jedi-auth 各完成一波擴充發版。
2. 主專案淨減約 220 檔；common/ 只剩資源域 authz、業務工具與真正的主專案膠水。
3. 守衛測試全綠：每支套件源碼 grep 0 處主專案 import；common/ 反向 import 0 條。
4. BE 全功能手測清單過（AI 聊天、防篡改 gate、log 轉發、agent 心跳派工、license 啟用、四角色權限、檔案上傳）。
5. 六支新套件全部通過拔掉測試（D6）：逐支註解 app_modules.py 註冊行 → BE 正常啟動、該模組路由/選單消失、其餘功能不受影響。 5b. 六支新套件 harness CI 全綠＋接入 README 齊備（D7）：每支套件 standalone harness 可獨立起、套件測試在 harness 內全綠並掛上 CI；接入 README（port 清單/註冊行/migration 套法/quickstart）齊備且 quickstart 實走過。
6. docs/claude/jedi-packages.md 補齊六支新套件段落（並順帶補上既有未登記的 13 支）。
7. monorepo 各套件 repo 側 commit 完成（push 與發版時點依鐵則等 user 明示）。