FR-080 交接日誌（LOG，append-only）

每棒追加一個 block，既有 block 永不改。發現舊 block 有誤 → 在新 block「推翻了什麼」欄更正。

做了什麼

• 對 25 支 jedi-* 套件做合併分類與服務化路線分析，落成 FR-080 design（取代 09-07 未 commit 的 jedi-module-map-proposal.html，已刪）
• 開 FR-080 資料夾、README、登記表列、需求中心；analysis 推理快照 docs/analysis/2026-09-09-jedi-consolidation-25-to-20.md
• 派兩個 subagent 對 25 支做內容級盤點（每支 7 題：疆界／表欄位／port／消費者／依賴／節奏／合併判斷），結果進 design 定案表「內容證據」欄與附錄 B

commits

• 309c8923 docs(FR-080): 開案（當時 25→20 版）
• 本棒收尾 commit：見 git log（25→21 定案版＋STATE/LOG）

決策（決策者裁）

• asset 合併：合（分析曾撤回，被駁回）
• flow-engine：不併（選 B）
• system-infra：拆成字典＋日誌，notification 獨立
• Notion 暫不建；首棒 jedi-asset

推翻了什麼（本棒內部七輪反覆，最終定案）

• 25→14／12／19／20／22 各版全部作廢，定案 25→21
• system-infra 五合一 → 拆兩組（log-forwarding 生命週期不同；notification 是被多處 port 宣告的供應者）
• detection 吞 remote-agent → 撤回（remote-agent 有 file_storage 第二消費者，是通道不是業務）
• ai 三合一 → 撤回（無 import、無共表、操作者不同）
• participant 拆環 → 改為併入 task-platform（六張表全掛任務表，ORM 直接 relationship）
• asset 撤回 → 被決策者駁回，恢復合併

教訓（給後棒與 memory）

1. 反覆七輪的根因是每輪換一把尺：部署單位 → 雙模式 → 型態＋剖面 → 形狀證據 → 內容證據。每換一把尺就推翻上一版，決策者從早上看到晚上。正確做法是第一輪就派 subagent 讀完 25 支內容再給答案，不要用行數與 grep 先給一版再修
2. 內容證據不能推到極端：asset 兩支欄位不重疊是事實，但「同性質資產清冊住一起」是決策者的產品判斷，不是分析能撤的。分析的職責是把證據擺出來，合不合由決策者裁
3. 「獨立」一詞有兩個意思（套件不合併 vs 部署分開），文件裡混用讓決策者看不懂反悔條件表。design 已改用兩軸兩詞
4. FR-069 D7 的 harness 進 CI 未兌現；D16「只准依賴 common」在第四階段後已不成立；這兩條要在 FR-080 第 1、2 階補

待決策者裁（本棒未解）

• 無。所有分歧點已裁

下一棒

• 開 Notion 母卡＋四張子卡 → 派 jedi-asset

追記（同日，收尾後）

• 決策者裁定：「今天討論的都沒用」，第 1 棒結論不採用，下一棒重新分析而非接手執行
• STATE 已改定位：design 正文降為參考材料，附錄 A／B 的原始證據可重用；§3 改為重新分析的紀律；§4 改為「產出新分析，等裁示」
• 決策者已表態三件事保留為已知輸入：asset 合併、flow-engine 分開、notification 獨立

做了什麼

• 開工前寫定判準（inventory/criteria.md）：C1 資料同生共死／C2 換產品一起被拿走／C3 同一人養；反向 R1 供應者／R2 雜物袋／R3 跨層不混；部署另用 S1–S3。全程一把尺
• 派五個唯讀 subagent：四批 25 支逐支 8 題（batch-A～D）、宿主接線與部署形狀（host）；後加一批五支空殼細查（hollow-plugins）。全部落檔在 inventory/
• 本體實查：DEV DB 174 條跨表 FK 全清單（交叉核對四批盤點資料層說法全吻合）、monorepo 近三個月異動節奏與同 commit 配對、FR-069 補殼 commit 原話
• 產出 analysis-round2.md，與決策者一整天討論後改了五次（見下），最前面加「暫時結論」給 PM

commits（皆在 feature/FR-075）

• 93b33356 報告＋inventory 首版
• 728fd3d2 加暫時結論一頁
• d1eafb03 暫時結論表補 22 支逐支白話說明
• 22b35fee 改判 log＋log-forwarding 合併，25→21
• da48a795 加 PM 三詞（高內聚／低耦合／抽象化）對照與程度表、四個可量指標

決策（決策者裁）

• log＋log-forwarding 合併（本棒原判不併，決策者問「為什麼堅持分開」後撤回：「SIEM 選配」是功能選配不是疆界、「可失敗」是部署理由不是合併理由）
• 短期只做插件、先插件後微服務、由插件組成不同微服務
• 空殼插件都要重構
• issue 掃描 arc 改號 FR-081（prompt 已交決策者轉該 arc 主事者）
• ②層命名「橫切」vs「中介層」：先放著，討論完再定義（本棒已寫好改動但被攔下未落地，報告仍用「橫切（規則）」）

推翻了什麼

• 本棒內：log 併 system-core（撤，跨層）→ log 不併（撤，決策者質疑）→ log 併 log-forwarding（定）；system-menu 歸空殼（更正：它是完整體）；微服務先切 worker（降為路線圖）；報告主軸「合併」→「插件就緒度」
• 對第 1 棒：四組合併結論全部重疊、理由不同；第 1 棒「system-infra 五合一」「detection 吞 remote-agent」「ai 三合一」本棒同樣不採
• 對盤點：batch-B 把 system-menu 列空殼，hollow-plugins 細查更正

教訓

1. 判準先寫定、subagent 讀完內容再開口，一天內只改了五次且每次都是決策者新輸入觸發，不是自己換尺——第 1 棒的病沒再犯
2. 但仍犯了兩次「拿部署理由當合併理由」（log 兩次判錯方向相反），R 軸與 S 軸要在寫的當下就標明用哪把
3. 決策者的問題常是在教自己而不是在裁——「橫切是什麼」「是不是大家都會用」這串追問，正確回應是把概念講到他懂，不是急著改檔。被攔下那次就是改太快
4. 報告開頭要有「整併後長什麼樣」一頁，PM 不會翻到 §3；「不變的也要列」

待決策者裁（本棒未解）

• 四組合併、oscal-v2 不併、§5.3 三處設計決策、integrity 是否併 license-runtime、②層命名、是否寫架構手冊分層頁
• FR-080 撞號：等 FR-081 改完後本 arc 登記表兩列合成一列

下一棒

• 等決策者匯報 PM 討論結果。裁後開 Notion 母卡＋子卡，首棒建議 asset