# 需求
現在要重新設計產品核心架構, 先前只有套用OSCAL"概念", 現在要將正式的使用模式以及流程, 資料架構, 引入系統, 成為正式專業的 OSCAL GRC 系統
這邊整個捨棄原本討論的FR-037, 請用全新的需求進行
目前有幾個項目需要整個大調整
- 外部套件
- 主專案後端
- 主專案前端
如下

## 外部套件
1. OSCAL 資料結構重新設計, jedi-oscal 整個砍掉重練, 進入v2.0, 符合OSCAL V1.2.2資料模型
   - 新版本的db schema 請參考 /Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-be/docs/features/FR-037-2606-oscal-schema-gap-audit/oscal-catalog-and-roots-schema-v2.sql
   - 存放方式要依據正式的oscal物件以及欄位存放, 目前舊版本很多自定義欄位, 要調整完全符合oscal 物件的使用方式存放
   - 幫我設計一個專業的第三方套件模式, 可以被我的主專案運用, 因應各種情境讀寫資料給主專案使用
   - 不在原本jedi-oscal 下開發, 請新開一個新的套件資料夾 jedi-oscal-v2, 整個重新設計開發
   - 需要建立全新的model, db schema name 一樣先採用 oscalv2 後續完工會rename替代回oscal, 
     或是你建議直接drop oscal 重新建立也行, 開發資料庫會備份以及任意使用


## 主專案邏輯
2. 調整合規框架, 合規資源庫資料存放方式
  ### 合規框架
  - 合規框架主檔: oscal.oscal_frameworks -> rename oscal.frameworks
  - 合規框架版本: oscal.oscal_framework_versions -> rename oscal.framework_versions
  - catalog主檔以及其關聯資料庫對應結構更新, 這邊請參考Outline:
    - catalog 主檔: catalogs(會對應一個framework_versions)
    - control group: catalog_groups
    - control: catalog_controls
    - assessment object(AO): catalog_parts 
    - 其他欄位使用方式,請參考sql schema
  - 匯入合規資源庫版本, 後面接的功能要調整成使用新的資料結構 

  ### 合規資源庫
  目前合規資源庫, 被設定為公版的稽核範本, 由專業的稽核顧問來制定以及維護自己的稽核範本, 會針對各種不同的稽核框架內容做設計, 
  當有客戶提出需求要協助做導入時, 就可以拿自有的合規資源庫, 來成立客戶專案, 輔導以及協助客戶完成整個稽核的流程

  合規資源庫的調整, 目前會由三個物件組成
  - catalog
  - profile
  - ssp(公用版本用)
  相關規則邏輯如下:
  1. 新增合規資源庫時, 會選擇一個framework_versions, 把該對應的catalog snapshot 一份起來, 給該合規資源庫用
  2. 會依據profile的設定, 決定有多少控制項, AO 要被納入這份合規資源庫
  3. 一樣要提供匯入ssp 功能, docx/excel 只是後面存放資料要改用新的資料庫架構
  4. 新增專案的模式會改變, 會使用最新版本以及發布的合規資源庫, snapshot定版複製一份給專案使用, 
     該專案後續都是用這份合規資源庫下的 catalog, profile, ssp, 來往後作業, 

3. 調整專案流程
  ### 專案流程
  專案(project) -> 專案規劃(SSP) -> 稽核計畫(AP) -> 稽核(AS) -> 改善計劃(POA&M)

  專案將會由下面幾個物件組成
  - projects: 專案主檔, 會有專案的基本資料, 引用哪一個合規資源庫以及版本, 屬於哪一種稽核的導入
  - project_audit_rounds: 專案稽核輪次, 每一輪的專案稽核紀錄, 舊的版本是用AP來做, 這設計是不對的, 改由新的table來替代, schema 參考下面, 有需要增加可以討論
  ```
  id: int, auto_increse, pk
  name: varchar(255), NN, 輪次名稱
  round_no: int, 輪次編號
  start_at: datetime, 開始時間
  end_at: datetime, 結束時間
  status: enum(尚未開始, 專案規劃種, 稽核規劃中, 稽核進行中, 改善計劃中, 結案), 狀態, 這邊參數可以討論
  ssp_id: int, 關聯SSP, 可為null, 等到正式進入稽核階段SSP鎖定時,才會填入
  created_at: datetime, 建立時間
  updated_at: datetime, 最後更新時間
  created_user: int, 建立人員
  updated_user: int, 修改人員
  ```

  - ssp 系統安全計劃: 每個專案會有一個主要的SSP, 這會是專案的本體, 他會被持續的維護內容, 
    直到PM決定目前的內容已經足以進行稽核了, 會做啟動稽核的動作
    在還沒啟動稽核前, 都是對專案公版的SSP來做編輯, 
    啟動之後, 系統會將當前的SSP做定版的動作, 此時就不能夠再修改SSP的內容了, 
    也同樣會複製一份起來做定版, 填入該project_audit_rounds對應的SSP資料(例如ssp_id)
    - 原本UI上的一些資料, 請幫我依照OSCAL的規範, 寫入該對應的物件
      - 受評標的     → system-characteristics
      - 人員/單位    → parties + roles
      - 證據         → by-component.links → back-matter
      - 實施計劃     → props(planned 日期)
      - 實作狀態     → props(implementation-status)
      - 控制實作描述, SoA → implemented-requirement（一條控制一筆）
						  ├─ props
						  │    ├─ applicability          ← SoA(適用性)
						  │    ├─ inclusion-justification ← SoA(理由)
						  │    └─ implementation-status  ← 實作狀態
						  └─ statements[].by-components[]
						       ├─ description            ← 控制項實作描述
						       └─ links(evidence)        ← 證據綁定

  - ap 稽核計畫: 由稽核人員制定, 會提出他這次來稽核會要看什麼內容, 通常會在實際稽核前先給受檢單位, 讓他們提前準備
    例如:
  	- 要驗證控制項
	- 有哪些人, 設備, 服務, 地點要被稽核, 
	- 什麼時間點
	- 會怎麼檢驗
	- 會用什麼工具或方式
	目前的沒有這項流程, 要另外新增整個UI以及後端邏輯設計, 這邊請你建議做法, 請幫我參考外面專業產品或是OSCAL官方建議做法來做設計

  - as 稽核結果:
    - 稽核人員會依照稽核計畫的內容, 填寫檢查結果, 判定每一條的檢查狀況
    - 依照判定結果, 填寫系統風險,並且由哪幾條組成風險
    - 目前沒有填寫判定系統風險的設計, 需要另外製作要討論
    

  - poam 改善計劃:
    - PM會依據 AS 的 risk 來建立改善計劃, 設定milestone以及指派人員, 做限期改善
    - 等到確定都改善完畢後, 可以在啟動一個新的 audit_round, 但是是改善計劃用, 只會針對這次有缺失的項目做稽核
    - 這時候要進行公用版本的SSP維護, 將改善後的新證據, 以及提出說明補上, 再做一次稽核(覆核)
    - 結案判斷請幫我餐靠下面業務邏輯html教材

## 參考資料
### OSCAL官方參考資料
- 8大主要Object Outline: https://pages.nist.gov/OSCAL-Reference/models/v1.2.2/complete/json-outline/
- 各項Object JSON資料範例: https://github.com/usnistgov/oscal-content/tree/main/examples
- 完整schema 以及欄位說明: https://pages.nist.gov/OSCAL-Reference/models/v1.2.2/complete/json-reference/
- 物件介紹:
  - catalog: https://pages.nist.gov/OSCAL/learn/concepts/layer/control/catalog/
  - profile: https://pages.nist.gov/OSCAL/learn/concepts/layer/control/profile/
  - system-security-plan (SSP): https://pages.nist.gov/OSCAL/learn/concepts/layer/implementation/ssp/
  - assessment-plans (AP): https://pages.nist.gov/OSCAL/learn/concepts/layer/assessment/assessment-plan/
  - assessment-results (AR): https://pages.nist.gov/OSCAL/learn/concepts/layer/assessment/assessment-results/
  - plan-of-action-and-milestones (POA&M): https://pages.nist.gov/OSCAL/learn/concepts/layer/assessment/poam/
  - component-definition: https://pages.nist.gov/OSCAL/learn/concepts/layer/implementation/component-definition/
  - mapping-collection : https://pages.nist.gov/OSCAL/learn/concepts/layer/control/mapping/

### 業務邏輯
- docs/features/FR-038-2606-oscal-redesign/OSCAL_稽核生命週期_PM教材.html
  
## 開發模式
我想要用多個Agent的模式平行開發, 麻煩你規劃任務的時候, 規劃成可以平行開發的模式, 要加快開發速度, 規劃完告訴我你會怎麼安排

## 注意事項
- 先幫我分析這份整分需求, 開新的, ap, as, poam可能需要討論
- 後端: 不要被OSCAL舊的流程以及資料影響, 這次要整個大調整, 討論時可能要用新舊流程對照來做討論, 後端部分我自己初步分析基本上是要整個大改
- 前端:
  合規框架, 合規資源庫, 專案, 專案總覽, 專案規劃, 任務執行, 到這幾階段UI應該是不會大更動 
  會改的應該是 AP, AR, POA&M 這幾個, 

  AP的概念目前是完全沒有,  這邊應該是要另外做新的畫面
 
  AR的話只有一半, 目前是逐項填寫判定結果
  但是應該還會有一個總結的動作
  稽核人員應該會做總結, 列出你系統的風險, 然後是哪些項目造成這些風險的, 風險等級為何
  
  POA&M 應該是依照這些系統風險, 去設定改善計劃, 指派人員執行, 
  可以再從這邊發起新的一次稽核, 是針對改善用的, 只會針對要改善的項目來做稽核
  這邊應該是小改, 

  再麻煩你幫我分析跟判斷