# FR-038 框架維護 — 變更帳 + FE 不能用事件記錄（供 rollback 評估）

> 緣由：2026-06-16 user 回報「昨天套前端上去幾乎都不能用」，要求(1)記錄此討論 (2)完整交代我做了哪些事，以評估是否退回修改前重跑。
> 本檔誠實列出**我這條對話實際做的全部變更** + 驗證缺口 + 哪些不是我做的 + rollback 選項。

## 1. 我實際做了什麼（這條對話）

### A. 框架 FE 嘗試 → 已全數還原（淨零 FE 改動）
一開始試著改 FE 接框架 v2（api.js / ComplianceFrameworkManage.vue / 2 個 i18n / 加匯入 dialog），
後來 user 拍板「BE 接回舊 URL、FE 零改動」，**我用 `git restore` 把這 4 個 FE 檔全部還原**。
→ FE code 這條對話**淨改動為零**（除非後續被其他 session 動過）。

### B. 框架維護 2a/2b（主工作，BE + 套件 + migration）
**核心手法**：把 Wave 2A disable 的框架 route 重寫接 jedi_oscal_v2，**註冊回舊 URL**，宣稱 FE 零改動。

改動清單：
1. `config/di_modules.py`：從 `EXCLUDE_MODULES` **移除 3 個 route 模組**（`oscal_framework_version_route` / `framework_version_edit_route` / `framework_parse_job_route`）→ 讓 DI auto-scan 重新 wire 它們。
2. `api/oscal/__init__.py`：**註冊 13 條框架路由 blueprint**（framework CRUD/版本/catalog 編輯/parse-job，全用舊 URL）。
3. `api/oscal/routes/framework/oscal_framework_route.py`：框架 CRUD 改回舊 URL + 補 delete。
4. `app/oscal/service/framework_version_app_service.py`（新）、`framework_version_edit_service.py`（重寫接 v2）、`framework_parse_job_service.py`（重寫接 v2）。
5. `api/oscal/serializers/framework/oscal_framework.py`：version response 擴充。
6. `di_containers/oscal/oscal_containers.py`：加 version / edit / parse-job 的 DI provider。
7. **v2 套件 `jedi-oscal-v2`**（dev path-dep）：`FrameworkService` 加 delete/version CRUD、`framework_versions` 加 `release_date` 欄、delete_framework 改 CASCADE。
8. **2 支 DB migration（只套了 DEV）**：`framework_versions` 加 release_date、重建 `framework_parse_jobs` 表。

### C. 文件（無 code 風險）
API 清單盤點、audit-round FE 遷移計畫、驗收報告、決策紀錄。

## 2. ⚠️ 我的驗證缺口（誠實面對）

我宣稱「BOOT OK / 零新回歸 / FE 零改動」，但驗證方式有**重大缺口**：
- 只用 `create_app()` 驗 DI + **手動隔離註冊 blueprint**測路由 —— **沒有跑完整 `main_app.py`**（真實啟動會 wire 全部模組 + 註冊所有 blueprint）。
- 只跑 service 層 smoke + pytest —— **沒有對真實運行中的 FE 測過**。
- **關鍵風險**：把 route 從 EXCLUDE_MODULES 移除 = DI 重新 wire 那些模組。若任一模組在「完整 app 載入」時有 wiring/import 互動問題（我的隔離測試抓不到），可能影響 DI 全域 → 多個 endpoint 失效 → 「幾乎都不能用」。
- **這缺口是真的**：我不能排除「重新啟用框架路由」對完整 app 有副作用。

## 3. 哪些不是我做的（git log 顯示但本對話沒做）

git 歷史已被 rebase（我的原 commit hash 不見）。log 中下列 commit **不是這條對話做的**（疑似平行 session / SSP 匯入工作）：
- `742ba3f3` `/flow-engine/task/queue 暫時回空陣列止血` ← 指向 **My Jobs 任務佇列**，非框架維護
- `e5fac369` `修兩個害前端拉不到資料的問題` ← FE 拉不到資料的止血
- `bdfe780`(套件) / SSP 匯入相關 test commits（`dcaa6e6d` / `93df50b4`）/ `5d36e1b4` SSP 匯入收尾
→ 「FE 拉不到資料」的止血指向 **flow-engine / SSP 匯入**，**不是**我的框架維護路由。

## 4. log 現況（2026-06-16）
- 大量 `FR-038 2A: skip ... disabled until 2B` = 2A 既有 warning（非新、非錯）。
- `after_request api_log update failed: cannot adapt type 'dict'` = api_log middleware warning（logging 基礎設施，與框架維護無關）。
- `UniqueViolation frameworks_code_key` = 有人建重複 code 框架（疑測試殘留）。
- **未見**我的框架改動造成的 boot 崩潰 / NameError / 全站 500。

## 5. Rollback 選項（皆未 push，本地操作）

| 選項 | 作法 | 風險 |
|------|------|------|
| **(a) 外科式 disable 框架維護** | 把 3 個 route 模組加回 `EXCLUDE_MODULES` + 移除 blueprint 註冊（DI/service/套件 code 留著但不掛載）→ 框架路由回到 2A dark 狀態 | 低；只關我的東西，不動 SSP/止血/其他。可快速驗「是不是框架害的」|
| **(b) 完整 branch reset** | reset 到我過夜工作之前 | **高**；會一起丟掉平行 session 的 SSP/止血 commit（歷史已 rebase 交纏）|
| **(c) 先診斷再決定** | 找出「FE 拉不到資料」真正壞點（止血 commit 指向 flow-engine/SSP，未必是框架）後再針對性處理 | 最穩；避免盲退 |

## 6. 建議
先別盲退（選 (b) 風險高、會誤傷平行工作）。建議：
1. 若要快速排除「是不是框架維護害的」→ 選 **(a)** 外科式 disable，重啟 BE 看 FE 是否恢復。
2. 同時 **(c)** 看 `e5fac369` / `742ba3f3` 改了什麼（那是 FE 拉不到資料的真實止血點，指向 flow-engine task queue，非框架），釐清真因。