🔴 一頁看完

2026-09-09 決策者裁定：第 1 棒的分析結論不採用，下一棒重新分析。 下方「結論」是第 1 棒的產出，只當參考。已表態的已知輸入：asset 合併、flow-engine 分開、notification 獨立。

這是 FR-069 的續作。 FR-069 把主專案 40 個模組抽成 25 支 jedi-* 套件後於 2026-09-01 收官；決策者接著提出三個要求——朝微服務模式、套件可在其他專案隨插即用、現況粒度太細。本 FR 回答「要合成幾支、今天離服務有多遠、要補什麼」。

1. 25 支收成 21 支，四組合併：任務平台（task-platform 吞 participant）、系統字典（system-config＋system-menu）、日誌（jedi-log 收 common 的 system_logs，log-forwarding 為子模組）、資產（device＋information-system，決策者裁定）。flow-engine 不併（決策者拍板）。其餘 15 支不動。system-infra 五合一、detection 吞 remote-agent、ai 三合一三組在讀了表欄位與 port 後推翻。
2. 今天零支是服務。FR-069 做的是模組化不是服務化：同一進程、同一 DB、零 outbox；10 支有真獨立 harness 但沒進 CI。
3. 「可分開部署」是設計要求、「預設分開部署」是部署選擇。七階補完後 16 支都要能用 import 或 API gateway 模式跑、套件碼不改；今天只有 detection 與 evidence-classification 有分開跑的收益。iam、survey 技術上都能獨立，等觸發條件。
4. 前三階約 20 棒完成插件模式（harness 進 CI → 契約層 → 資料解耦＋宿主範本），達成「其他專案隨插即用」；第 3 階收完停下評估第二個產品是否出現，再決定後四階。
5. 下一步是第 0 階套件合併，順序 資產 → 系統字典 → 日誌 → 任務平台吞 participant，每組比照 FR-069 退役慣例。首棒 jedi-asset 決策者已指定。

• design.md — 判準、定案分類、現況差距、七階補法、終局形狀、反悔條件；附錄放實查數據、四輪推演、外部 AI 表對照、participant 循環相依的來歷
• 推理歸檔：docs/analysis/2026-09-09-jedi-consolidation-25-to-20.md（同內容快照）

不掛 FR-069.N：FR-069 已正式收官（STATE 標五階段全收），再往下掛會讓收官紀錄失真。本 FR 承接其終局（25 支、五層、插座模型、D16／D17／D18 通則），並修正三處：D7 的 harness 進 CI 未兌現、D16「只准依賴 common」在第四階段後已不成立、D6 的 migration 隨包只落實 7 支。

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

設計

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

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

相關需求：

• FR-069 — jedi-module-extraction