↑ 需求首頁 ⌂ 需求中心

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，非框架），釐清真因。