FR-080 一頁看完

一支套件內部長什麼樣（plugin/ 五檔、guards.py、request 旅程）不在本站——那是 FR-089 插件解剖（工程師版）與 給 PM 的說明（不需技術背景）。長期分層判準在 架構手冊 · 套件分層。

1. 25 支收成 21 支，四組合併：資產（device＋information-system）、任務平台（task-platform 吞 participant）、系統核心（system-config＋system-menu）、日誌（jedi-log 吞 log-forwarding）。flow-engine 不併（決策者拍板）。其餘 17 支不動。三組看起來像但不併：oscal-v2 與 compliance-audit、integrity 與 license-runtime、detection 與 remote-agent。
2. 套件分五層，依賴只准往下：基座（jedi-common）→ 橫切（登入、存取紀錄、防篡改、授權）→ 平台服務（通知、檔案、設定、資產…）→ 平台骨架（任務平台、流程引擎）→ 業務（稽核、問卷、檢測…）。新產品的起手式是前兩層加通知、設定五支。
3. 五支「有殼沒肉」的套件已補實四支：bulletin、device、information-system、system-config 的功能已從主專案搬進套件。flow-engine 沒做——套件內 549 行死程式與主專案複製出去的 1,559 行執行服務都還在，等 CM-1478 流程疆界設計。
4. 套件之間直接抓對方程式的線要改成走接口，換到別的系統才不會斷。四個可量的數字當驗收：跨套件直接 import、沒人用的接口、主專案接線行數、能直接裝的套件數。
5. 對 PM 的三個詞：FR-069 做到「有邊界」（高內聚低耦合抽象化約六／五／四成），FR-080 做完到「邊界畫對、依賴走門、對外只露介面」（約九／八／七成）。抽象化的最後一段要靠第二個真實產品驗證，不是這次能補的。

正式設計：design.md。證據：inventory/ 七份原始盤點。第 1 棒的舊分析已刪除（決策者 2026-09-10 裁，留著會誤導；要查看 git 歷史 c2bf55d6 之前的 design.md）。

四個指標（基線 → 現在，2026-09-14 實跑 plugin_metrics.py）：跨套件直接 import 120 → 93（剩下 68 處是 compliance-audit → oscal-v2，刻意保留）｜沒人用的接口 16 → 4｜主專案接線行數 7,457 → 9,762（接口的另一半落主專案，預期內；DI 瘦身後會降）｜能直接裝的套件 17 → 17（套件 25 → 21，六支殼在 archive/）。完整表見 FINAL-SPEC

每棒的驗收細節在 交接日誌 LOG 與 Notion 母卡 CM-1619。決策者驗收清單：fr080-ACCEPTANCE.md。

• 2026-09-09 決策者：asset（設備＋資訊系統）要合併，「幾乎是相同性質」；flow-engine 不併任務平台，「分開是對的」；notification 獨立因為會持續擴充；system-infra 的本意是「系統開起來一定要有的基本功能」。
• 2026-09-09 決策者：第 1 棒的分析「反反覆覆、沒有認真思考」，結論不採用，重新分析。
• 2026-09-09 決策者：log 與 log-forwarding 合併（第 2 棒原判不併，被問「為什麼堅持分開」後撤回：那是部署理由不是合併理由）。
• 2026-09-09 決策者：出發點是「一堆 API 模塊，新產品拿來就能復用」，這是插件不是微服務；短期只做插件，由插件組成不同微服務是以後的事。
• 2026-09-09 PM：「目前分法可以先這樣」；compliance-audit 掃資安時會跨太多套件；remote-agent 與 detection 之後再調整。
• 2026-09-09 決策者：照八棒開卡、一次派一棒（另一首腦在同機器跑資安掃描）、用 git worktree 隔離。
• 2026-09-10 決策者：所有回報一律白話文，工程師與 PM 要看得懂。
• 2026-09-10 決策者：第 1 棒舊 design 刪除，留著會誤導；FR-080 文件與進度只在 worktree 做，做完整個 arc 再合回。
• 2026-09-10 決策者：每個 FR 站首頁固定三段：結論、總進度、需求討論紀錄。
• 2026-09-10 決策者：合併不是搬進子目錄，system-core 要按層壓成一層；log 與 task-platform 改成子功能平行、頂層不放任一子功能的分層。review 抓到的 Critical 等第 5 棒回來一起開修正卡。
• 2026-09-10 決策者：被合併的六支舊套件先 archive（搬 archive/ 目錄、不刪不發版），過陣子再處理退役。等第 6 棒改完 import 才動。
• 2026-09-10 決策者（第 6 棒停點）：授權套件的子租戶額度守門，接口未注入時讀取回 0 不擋、寫入擋下。理由：安靜失效等於授權可繞過。
• 2026-09-10 決策者：FE 錯誤碼 patch 等 arc 收口再套；六支轉發殼併第 8 棒搬 archive（participant 那支先改 survey／compliance-audit 的 import 名）。
• 待決：②層叫「橫切」還是「中介層」（先放著）；compliance-audit 收回主專案還是留套件償債（決策者傾向「核心不需要拆」）；integrity 是否併 license-runtime。

這是 FR-069 的續作。 FR-069 把主專案 40 個模組抽成 25 支 jedi-* 套件後，於 2026-09-01 收官；決策者接著提出三個要求：朝微服務模式走、套件要能在其他專案裝上就用、現在切得太細。本 FR 回答「要合成幾支、今天離『裝上就能用』還有多遠、要補什麼」。

兩個詞先講清楚：插件是把功能包成一個個可裝可拆的零件，裝上一支、註冊一行、API 就長出來；微服務是把這些零件分散到不同機器上各自跑。這一輪只做插件，微服務是以後的路線圖。

現況（2026-09-10）：PM 已同意分法，決策者裁照八棒開卡、一次派一棒執行。進度看 交接現況 STATE 與 Notion 母卡 CM-1619 末段的逐棒驗收。執行在獨立工作目錄 compliance-manager-be-fr080（branch feature/FR-080），這個站要看 worktree 那份才是最新。

• design.md — 正式設計（第 2 棒）：五層分類、判準、25→21 逐支結論、五支有殼沒肉的補實順序、要改成接口的線、起手式、微服務路線圖、PM 三詞對照與四個指標
• inventory/ — 七份原始盤點證據（25 支逐支、主專案接線與部署、五支空殼細查、判準檔）
• handoff/fr080-STATE.md — 交接現況（每棒驗收後更新）；handoff/fr080-LOG.md — 逐棒紀錄

不掛成 FR-069.N：FR-069 已經正式收官（交接檔標記五個階段全數收完），再往下掛會讓收官紀錄失真。本 FR 承接它的終局形狀（25 支套件、五層分類、插座模型，以及三條通則：套件對基礎能力的依賴一律走接口、資料關聯三律、設定申報制），並修正三處沒兌現的：獨立測試環境進 CI 這件事沒做到、「套件只准依賴 jedi-common」這條在第四階段之後已經不成立、資料庫腳本隨套件出貨只有 7 支真的做了。

以下全部由 build 掃資料夾產生，新增檔案重 build 即自動出現。標題連結指向渲染後的 HTML，md 連向源檔。

定版交付

設計

inventory/（7 份）

證據與盤點

review/（2 份）

證據與盤點

交接與收口時間軸（handoff/，7 份）

由新到舊。每份是某一棒次交接當下的完整現況快照，看某個時間點「當時知道什麼」請從這裡進。

相關需求：

• FR-069 — jedi-module-extraction