↑ 需求首頁 ⌂ 需求中心

FR-080 交接現況（STATE）

這份是 living 檔：每棒就地 Edit，只描述「此刻」。歷史脈絡看同資料夾的 fr080-LOG.md。

項目 值
最後更新 2026-09-09（第 1 棒：分析，決策者裁定本棒結論不採用，下一棒重新分析）
branch BE feature/FR-075（本 arc 文件目前落在這條 branch，決策者未指示另開）
母案卡 未建（決策者 2026-09-09 指示「Notion 先不建立」；派工前依鐵律必須先開母卡＋子卡）
本棒對應卡 無
卡片狀態 —
Notion 回寫規範 docs/claude/notion-issue-tracker.md；派工卡格式 docs/claude/notion-card-templates.md
接手前必讀 §0 讀序
預估時間 下一棒：重新分析一輪，先讀完內容再給答案

🧭 原始需求 / WHY

這節寫一次，之後各棒不動。

  • 決策者原話（2026-09-09）：「目前我們的 jedi-* 之前在 FR-069 做過一次重構分類，有些已經合併了。我們未來這個產品會希望是朝向微服務的模式，你再幫我重新分類一下，應該可以再合併一些套件。」後續補充：「我需要是插件跟微服務的模式，要可以在其他專案隨插即用，目前有很多的粒度還是太細。」
  • 兩件事：① 先分類，合併一些套件；② 朝微服務方向設計。第 1 棒只做了①的定案與②的路線圖，還沒動任何程式碼。
  • 需求的演變：分析中途曾把 asset 合併撤回（理由「欄位不重疊」），決策者駁回：「asset 這幾乎是確定一定要合併的東西了，幾乎是相同性質」。教訓已入 LOG：不要把「內容證據」推到連決策者明確要的東西都撤。
  • 本棒在大圖的位置：第 1 棒做了一輪分析，決策者 2026-09-09 裁定「今天討論的都沒用」，結論不採用。design 裡的 25→21 與七階只是第 1 棒的產出，不是定案。下一棒要重新分析，不是接手執行。

::: 🔴 決策者對第 1 棒的評價（原話） 「你已經亂套了」「你從早上就開始反反覆覆，全部沒有認真思考過」「我覺得今天討論的都沒屁用」。 原因：第 1 棒每輪換一把判準、用行數與 grep 先給答案再修、七次改版、連決策者明確要的 asset 合併都撤過。 :::

§0 接手讀序

0.1 🔒 先懂需求 gate

  1. 本檔 🧭 WHY 節（含決策者對第 1 棒的評價）
  2. fr080-LOG.md 第 1 棒 block——重點讀「教訓」欄，那是第 1 棒失敗的原因，別重蹈
  3. docs/features/FR-069-2608-jedi-module-extraction/design.md §3 決策表 D1–D18（FR-069 已拍板的裁示，重新分析時不可違反的邊界）
  4. docs/features/architecture-handbook/package-taxonomy.md（十族分類與「同類型≠同疆界」判準）

0.1b 第 1 棒產出——只當參考材料，不當結論

  • design.md 附錄 A（實查數據：行數／表／FK／pyproject／執行期事實）與附錄 B「內容級盤點」節（兩個 subagent 讀完 25 支的 7 題盤點結果、9 條洩漏、4 組 port 重複宣告）——這些是原始證據，可重用
  • design.md 正文的定案分類、七階——第 1 棒的判斷，決策者不採用，重新分析時不要被它框住

0.2 現況與待辦

  1. 本檔 §1、§4

0.3 需要細節才開

  • design 附錄 A（實查數據）、附錄 B（內容級盤點抓到的債與洩漏清單）
  • docs/features/architecture-handbook/（FR-069 手冊，插件契約與退役 SOP）
  • docs/features/FR-069-2608-jedi-module-extraction/extraction-sop.md（合併／退役的機械步驟範本）

§1 當前狀態（2026-09-09）

項目 狀態
第 1 棒結論 design 寫 25→21 四組合併。決策者裁定不採用，下一棒重新分析
決策者已明確表態的（重新分析時當作已知輸入） asset（device＋information-system）要合併——「幾乎是確定一定要合併的東西，幾乎是相同性質」；flow-engine 要分開——「分開是對的」；system-infra 的本意是「系統開起來一定要有的基本功能」
程式碼 零改動。monorepo 與主專案都還是 25 支
文件 design／README／登記表／需求中心已改成 21 版並 build；本棒最後一次 commit 之後的變動未 push
Notion 未建任何卡
遺留 poetry.lock／pyproject.toml 有 CM-1575／CM-1580 開發期 path override，不屬本 arc，不要 commit

§2 決策者已表態的事（重新分析的已知輸入，不是分析結果）

裁示 決策者 日期
asset 合併（device＋information-system）——「幾乎是相同性質」 雷門 2026-09-09
flow-engine 不併進 task-platform（選 B） 雷門 2026-09-09
system-infra 命名本意「系統開起來一定要有的基本功能」（收多少支未定，第 1 棒的拆法未被採納） 雷門 2026-09-09
notification 應該是獨立模組，因為會持續擴充 雷門 2026-09-09
Notion 暫不建，先進需求中心 雷門 2026-09-09
09-07 未 commit 的 jedi-module-map-proposal.html 刪除 雷門 2026-09-09

§3 重新分析的紀律（第 1 棒失敗的反面）

  1. 先讀完內容再開口。25 支的 README 疆界、表欄位、port、消費者用途，全部讀完（第 1 棒附錄 B 的盤點可重用，但要自己驗過）才給第一版。不要用行數、表數、grep 計數、pyproject 宣告先給一版再修
  2. 一把尺用到底。開工前先寫下判準，整份分析只用那一組判準；中途發現判準不對，停下來報告，不要換尺重跑
  3. 一次給完整答案，不要分七輪。決策者要的是「分析過後給我答案」：哪些合併、為什麼、朝微服務怎麼走。給一份完整的，等裁示
  4. 決策者已表態的事是輸入不是問題（§2 表）。分析可以補理由，不可以推翻
  5. 「套件不合併」與「部署分開」是兩個詞，文件裡不要用「獨立」混稱
  6. 不要引 broker

§4 下一步（等決策者發令）

下一棒的任務是重新分析，不是執行。 產出一份新的分析回答決策者的兩件事：

  1. 先分類，要合併哪些套件——25 支逐支給結論（合併／不動），每支一句內容級理由，§2 的已知輸入直接採用
  2. 朝微服務方向怎麼設計——哪些該分開部署、為什麼、要補什麼

可重用的材料：design 附錄 A、附錄 B。可參考但不採納的：design 正文。

分析完成後停下等決策者裁示，裁示後才開 Notion 卡、才派工。

§5 冷接自檢題

  1. 第 1 棒為什麼失敗？（答：每輪換判準、用形狀證據先給答案再修、七次改版、撤回決策者明確要的合併）
  2. 決策者已表態哪三件事？（答：asset 要合併；flow-engine 要分開；notification 獨立會擴充）
  3. 你的第一版答案什麼時候給？（答：讀完 25 支內容之後，一次給完整的）

§6 pre-flight（唯讀）

cd ~/Projects/Billows/Audit-Manager/compliance-manager-be && git status --short docs/ && git log --oneline -3
ls ~/Projects/Jedicogy/module/jedi-python-package/ | grep -c "^jedi-"    # 應為 25
grep -c "jedi-" pyproject.toml                                            # pin 數對照

§7 給下一棒的 prompt

請讀 docs/features/FR-080-2609-jedi-consolidation-and-service-path/handoff/fr080-STATE.md 接手 FR-080。第 1 棒的分析我不採用，你要重新分析一次。讀完 §0 讀序、答完 §5 自檢後停下回報，等我發令再開始分析。