# FR-080 交接現況（STATE）

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

| 項目 | 值 |
|------|-----|
| 最後更新 | 2026-09-09（第 2 棒：重新分析完成，報告 `analysis-round2.md` 已 push；**決策者拿去與 PM 討論，等回報後決定下一步**） |
| 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 讀序 |
| 預估時間 | 下一棒：等決策者與 PM 討論結果，裁示後開卡派工 |

## 🧭 原始需求 / 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 第 2 棒產出——**現行分析稿，等裁示**
- `analysis-round2.md`（html 同名）：完整報告。最前面「暫時結論」一節是給 PM 的一頁版（25→21 逐支白話表、五層、起手式、短期順序、PM 三詞對照與程度表、四個可量指標）
- `inventory/`：七份原始盤點（batch-A～D 逐支 8 題、host 宿主接線與部署、hollow-plugins 五支空殼細查、criteria 判準檔）。這些是證據，可重用
- 第 2 棒的判準寫在 `inventory/criteria.md`，全程一把尺；被推翻的判斷記在報告 §9

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

### 0.2 現況與待辦
4. 本檔 §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）

| 項目 | 狀態 |
|------|------|
| 第 2 棒結論 | `analysis-round2.md`：**25→21 四組合併**（asset／task-platform＋participant／system-core＝config＋menu／log＋log-forwarding），三組像但不併（oscal-v2↔compliance-audit、integrity↔license-runtime、detection↔remote-agent），**短期只做插件、微服務降為路線圖**，五支空殼（bulletin／device／information-system／system-config／flow-engine）待補實。結論與第 1 棒四組全部重疊、理由不同（§10 已寫）。**等決策者與 PM 討論後裁示** |
| 第 1 棒結論 | design 寫 25→21。決策者裁定不採用，降為參考 |
| 決策者已明確表態的（重新分析時當作已知輸入） | asset（device＋information-system）**要合併**——「幾乎是確定一定要合併的東西，幾乎是相同性質」；flow-engine **要分開**——「分開是對的」；system-infra 的本意是「系統開起來一定要有的基本功能」 |
| 程式碼 | 零改動。monorepo 與主專案都還是 25 支 |
| 待決 | ②層命名（「橫切」vs「中介層」）決策者說「先放著、討論完再定義」，報告仍用「橫切（規則）」，**不要自行改**；integrity 是否併 license-runtime（決策者問過、本棒給兩選項未裁）；FR-080 撞號——issue 掃描 arc 改 FR-081 的 prompt 已交決策者轉給該 arc 主事者，本 arc 登記表兩列重複待那邊改完再合成一列 |
| 文件 | 報告與 inventory 已 build 並 push 到 `feature/FR-075`（最新 `da48a795`）。**公網需求站從 main 建，這條 branch 未進 main，PM 從公網看會是 404 假頁**，要嘛合 main 要嘛傳 html＋`_shared/`。README 狀態已改「第 2 棒分析稿已出等裁示」；登記表 FR-080 兩列仍是第 1 棒內容且重複，待撞號處理後一併改 |
| 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 |
| log＋log-forwarding 合併（本棒原判不併被質疑後撤回） | 雷門 | 2026-09-09 |
| 短期只以插件為目標，先插件後微服務，由插件組成不同微服務 | 雷門 | 2026-09-09 |
| 出發點是「一堆 API 模塊、新產品拿來復用」；報告主軸從合併改為插件就緒度 | 雷門 | 2026-09-09 |
| 空殼插件「應該都要重構」；integrity 不進 common、不進 system-core（本棒論證、決策者未反對） | 雷門 | 2026-09-09 |
| issue 掃描 arc 改號 FR-081 | 雷門 | 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 下一步（等決策者發令）

**決策者拿 `analysis-round2.md` 與 PM 討論中，回來會匯報再決定。** 可能的下一步（都要等令）：
- 裁 §3 四組合併、§3.2 oscal-v2 不併、§5.3 三處設計決策（device 引用計數 port 開哪／bulletin error code 歸屬／system-config 等 D18 還是先搬 CRUD）
- 裁要不要把 §1 四層寫成架構手冊一頁（決策者說「先放著」）
- 裁後開 Notion 母卡＋子卡；第一棒建議 asset（information-system＋device 補實＋合併）
- 順帶：§11 第 3 條（宿主 `_UserDirectoryAdapter` 只轉發 2/4 方法，survey 部門名走降級）可能是現行缺陷，建議手測

以下是第 1 棒交接時寫的原文，保留供對照：

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

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

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

## §5 冷接自檢題

1. 第 2 棒的報告在哪、最前面那節是給誰的？（答：`analysis-round2.md`；「暫時結論」給 PM 一頁看完）
2. 套件結論是幾支、哪四組合併、哪三組像但不併？（答：25→21；asset／task-platform＋participant／system-core／log＋log-forwarding；oscal-v2↔compliance-audit、integrity↔license-runtime、detection↔remote-agent）
3. 短期目標是什麼、微服務呢？（答：只做插件——register 一行 API 長出來；微服務降為路線圖）
4. 哪件事決策者說「先放著不要改」？（答：②層命名「橫切」vs「中介層」）
5. 接手後第一件事？（答：等決策者匯報 PM 討論結果，不自行開卡、不動碼）
6. 第 1 棒為什麼失敗？（答：每輪換判準、形狀證據先給答案再修、七次改版）

## §6 pre-flight（唯讀）

```bash
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 自檢後停下回報，等我發令再開始分析。