接手 Guidant AI 主專案（compliance-manager-be）的協調者工作。上一輪（2026-09-16）把「主專案殘留清理」整條線收口了，現在沒有任何進行中的工作，你這棒是等決策者開新功能。

## 先讀這四份，讀完停下來等我發令

1. docs/features/FR-102-2609-host-module-map/README.md
   26 個模組的地圖：每支是實的／接線殼／殘留、誰在用、幾條 route。檔頭有失效警示與 HEAD，引用前先重跑文末「怎麼重跑」的指令。

2. docs/features/FR-104-2609-flow-boundary-reanalysis/design.md
   flow_engine 加 flow_control 114 檔逐檔歸屬（引擎／平台／稽核／主程式編排），第五節立即可做、第六節要設計才能動、第七節已裁事項。

3. docs/features/FR-105-2609-oscal-module-frame-file-classification/README.md
   oscal（163 檔）與 module_frame（81 檔）逐檔分類：真業務／轉接殼／共用設施／死碼，結論段有決策者裁示四條。

4. docs/features/FR-106-2609-ssp-mapping-into-oscal/design.md
   SSP 對應層反轉設計稿，決策者裁先不動；檔頭「決策紀錄」段寫了理由與反悔時機。

補讀：docs/features/FR-103-2609-host-residue-cleanup/handoff/fr103-LOG.md 的 Block 1 與 Block 3「推翻了什麼」「教訓」。首腦在這條線上判斷錯了七次，形狀都是「我查到的範圍被當成全部的範圍」。

## 冷接自檢（答不出來就回頭讀，不要開工）

- module_frame 與 oscal 的依賴方向是哪邊依賴哪邊？為什麼裁不反轉？
- 判一支 repo 是不是純讀，只 grep INSERT/UPDATE/DELETE 會漏什麼？
- workflow_template_snapshot_service 裁歸哪邊、理由是什麼？
- 主專案現在還有幾條對外 route？為什麼 oscal 那 61 條不能進套件？

## 現況一句話

三 repo（BE／FE／jedi-python-package）都在 feature/review、已 push、工作區乾淨。jedi-iam 1.2.0 已發、pin 已升。主專案對外 route 189 條。

## 決策者已裁、不要再提的

- flow_template 歸引擎（22 檔進套件並發版）：等新功能碰到流程範本再看。
- 三支殼與業務混住的千行大檔（ssp_control_implementation、framework_parse_job、resource_library）：不拆，要等套件契約隨新功能定。
- FR-106 SSP 對應層反轉：先不動。
- 六支殼的空值哨兵：記債不動，只補了陷阱註解。
- FR-104 第六節四項（最大 workflow_execution_service 1,321 行）：等新功能。

這些都在 memory 的 Follow-ups 段，別當成待辦重新提。

## 派工紀律（這棒被點名過的）

- 派 subagent 前先判任務形狀：機械性用 Sonnet，要跨檔判斷才繼承大 model，prompt 第一行寫 model 與 effort。決策者原話「不然很浪費」。
- 派 runner 一律先開 Notion 卡，卡上要列完整的「要 add 的檔」含腳本產生物（三棒都漏了 docs/features/index.html）。
- 驗收不信 runner 自報：數字重跑、抽五筆開檔、可清的自己四層 grep。

## 讀完回報三件事就停

1. 自檢答案
2. 現況盤點（三 repo git 狀態、與交接文件不符之處明講）
3. 「已就緒，等你說新功能是什麼」

不要派 subagent、不要跑測試、不要改檔。