docs/features/README.md · FR 編號 single source of truth
所有需求的編號登記，含尚未建站的。建有文件站的需求另見需求中心。
開發過程中的設計探討、實作計畫、前端規格等歷史文件。
API 模組文件（SA/SD）已搬至
docs/api/，本目錄只保留功能開發過程的紀錄。
要用看的？ 建有文件站的需求都掛在 需求中心
index.html（總入口， 掃資料夾自動生成）。本頁是 FR 編號登記表（single source of truth），涵蓋所有需求 含尚未建站的；總入口只列有README.md的。
資料夾一律用 FR-<序號>-<YYMM>-<功能名> 格式：
FR-016-2604-google-drive-sync
│ │ │ └── kebab-case 功能名
│ │ └────── 提出年月（2604 = 2026-04）
│ └─────────── 流水序號（提出先後，補零到 3 位）
└─────────────── Feature Requirement 前綴.N（如 FR-011 → FR-011.2 → FR-011.3），不佔整數號、不疊三層。
2026-05-29 一次性導入此規範，既有 33 個資料夾全數重編（見
docs/changelog/2026-05-29-tweak-feature-folder-fr-numbering.md）。
docs/features/FR-<序號>-<YYMM>-<功能名>/
├── design.md ← 設計探討 / 需求分析
├── implementation-plan.md ← 實作計畫（步驟、時程）
├── frontend-spec.md ← 前端整合規格
├── README.md ← 跨 phase tracker（選填）
└── handoff/ ← 跨 session 交接 prompt / phase 收口 SUMMARY排序依 FR 號（子題緊接母題）；實際提出時間看「提出」欄。
| FR | 提出 | 功能 | arc 關聯 |
|---|---|---|---|
| FR-001 | ≈2026-02 | 稽核生命週期整體分析 | 稽核生命週期母題 |
| FR-002 | ≈2026-02 | 稽核員儀表板 | — |
| FR-003 | ≈2026-03 | 多重 AP 支援 | 生命週期 Stage 1 |
| FR-004 | ≈2026-03 | 外部稽核 | 生命週期 Stage 2 |
| FR-005 | ≈2026-03 | POA&M 改善追蹤 | 生命週期 Stage 3 |
| FR-006 | ≈2026-03 | 多輪稽核 | 生命週期 Stage 4 |
| FR-007 | ≈2026-03 | 啟用專案 | 生命週期 Stage 5 |
| FR-008 | ≈2026-03 | 前端 API 遷移 | — |
| FR-009 | ≈2026-03 | SSP 控制項現況 | — |
| FR-010 | ≈2026-03 | SSP 程序書池 | — |
| FR-011 | ≈2026-03 | SSP 控制項批次匯入匯出 | SSP 匯入匯出 arc 母題 |
| FR-011.2 | 2026-05-18 | SSP 匯入匯出 Phase 2（全領域匯入 + 6 格式匯出） | ↳ FR-011 子（Phase 2） |
| FR-011.3 | 2026-05-22 | 專案內直接編輯 SSP | ↳ FR-011 子（Phase 2 Track C 補強） |
| FR-012 | ≈2026-03 | 任務批次匯入匯出 | — |
| FR-013 | ≈2026-03 | 批次完成任務 | — |
| FR-014 | 2026-04-06 | 稽核模組歷史開發規格 | 合併自 grc-project / job-comment / job-evidence / job-revert |
| FR-015 | 2026-04-24 | GitLab CI 自動 code review | — |
| FR-016 | 2026-04-24 | Google Drive 整合 | — |
| FR-017 | 2026-04-25 | 稽核範圍合併 | — |
| FR-018 | 2026-04-25 | ModuleFrame 範本預設 | MF defaults arc 母題 |
| FR-018.2 | 2026-05-26 | MF 範本預設 Phase 2 | ↳ FR-018 子（Phase 2） |
| FR-019 | 2026-04-26 | SSP 版本控制 | — |
| FR-020 | 2026-04-27 | 通知設定 | — |
| FR-021 | 2026-04-28 | 問卷答案去重 | — |
| FR-022 | 2026-04-30 | SSP 程序書 docx parser | — |
| FR-023 | 2026-04-30 | 問卷答案 checkpoint 最佳化 | — |
| FR-024 | 2026-05-04 | 合規框架 PDF 匯入 v2 | — |
| FR-025 | 2026-05-06 | SSP 更新 diff | — |
| FR-026 | 2026-05-12 | 專案流程引擎整合 | — |
| FR-027 | 2026-05-23 | docx 匯入一致性 | relates to FR-022 / FR-011.2 |
| FR-028 | 2026-05-24 | SSP OSCAL 對齊 | — |
| FR-029 | 2026-05-26 | 選單群組 | — |
| FR-030 | 2026-05-27 | 證據自動分類 | 證據分類 arc 母題 |
| FR-030.2 | 2026-05-29 | 證據分類支援圖片 / PDF 內容辨識（Claude Vision） | ↳ FR-030 子（多模態能力補強，流程不變） |
| FR-030.3 | 2026-05-29 | 證據分類支援 .xlsx / .pptx（本地抽文字） | ↳ FR-030 子（補檔型，sibling of FR-030.2） |
| FR-031 | 2026-05-31 | 證據分類分析結果報表（驗證報表 + 各 AO 誰對誰錯）+ run 結果入 DB | relates to FR-030（分類結果可視化） |
| FR-032 | 2026-06-04 | 系統資產盤點（資訊系統作為資產納入 SSP inventory，hybrid soft-ref） | relates to FR-018（MF 範本預設） |
| FR-033 | 2026-06-04 | 專案進度稽核事件埋點（任務完成/指派/退回 + 問卷狀態變更寫 system_logs）+ 查詢 runbook | relates to FR-013 / FR-021 |
| FR-034 | 2026-06-08 | jedi-flow-engine vs BE WorkflowExecutionService 收斂評估 — feasibility done，採方案 c 文件化結案（無第二稽核產品、BE 版架構合規；未來有第二產品改走抽 jedi-audit-workflow 層） | relates to FR-026（flow-engine 整合） |
| FR-035 | 2026-06-10 | SSP table 改名（system_security_plans* → ssp(s)_*，表名 only）— 跨 BE + jedi-oscal + 4 DB 環境，in-place ALTER RENAME |
relates to FR-028（SSP OSCAL 對齊） |
| FR-036 | 2026-06-10 | module_frame ↔︎ SSP 整併（樣板 SSP 模型）— *_defaults 折進「一份 is_template=True 的 SSP」，啟動專案 clone 樣板 SSP → 專案 SSP；消除 MF defaults 與 SSP 子表雙套 schema 維護 |
relates to FR-018（MF 範本預設）/ FR-019（SSP 版本控制）/ FR-035（SSP 改名） |
| FR-037 | 2026-06-10 | 🗄️ ARCHIVED（2026-06-14） — OSCAL 5 模型 × DB schema required 欄位盤點，後續演變成「全 OSCAL 關聯式 schema 重新設計」（45→42 表），方向已偏離原盤點原意，user 決定整個重來、不續作。成果（v2 schema + 審查報告）保留供未來重啟參考，見資料夾 SUMMARY。新一輪將另開 FR | relates to FR-028（SSP OSCAL 對齊）/ FR-036（SSP 表族整併同期動表） |
| FR-038 | 2026-06-14 | OSCAL 重新設計（接替 FR-037 ARCHIVED，整個重來） | relates to FR-037（前一輪盤點，已封存） |
| FR-039 | 2026-06-17 | 分散式檔案 Agent（證據檔案落地客戶端，雲端不託管 binary，依客戶分流到各自 agent）— demo 階段 | relates to FR-016（檔案儲存抽象）/ FR-030（證據檔案來源） |
| FR-040 | 2026-06-20 | 稽核計畫填寫（ap-authoring）優化 — 查核方法改 system_menu 可擴充 + 行程(task)鉤稽控制項/受評對象/參與人員（OSCAL task→activity 模型，related-controls / subjects / responsible-roles） | relates to FR-038（OSCAL 重新設計） |
| FR-041 | 2026-06-21 | 稽核結果（AR）填寫優化 — A 繼承 AP 查核指引進判定頁 / B 缺失→風險→矯正(POA&M)串接 / C 觀察照規劃方法引導化（順 OSCAL Observation→Finding→Risk→POA&M 四段，漸進增強既有面板） | relates to FR-040（承接 AP 規劃） |
| FR-042 | 2026-06-28 | 合規框架與客戶儲存空間脫鉤，改由系統部門集中管理 — 框架 PDF 改存「最高層 tenant」系統儲存；upload_files 加 storage_scope（system/customer），下載依「檔案 scope」解析後端（繞呼叫者 RLS）；既有檔 migration 一次性搬遷；下載端補 auth、登入即可讀（全 tenant 共享） |
relates to FR-039（檔案儲存抽象 / RemoteAgent）/ FR-024（框架 PDF 匯入 v2） |
| FR-043 | 2026-07-02 | 稽核計畫 docx 匯入 — ap-authoring 上傳顧問稽核報告 docx → 解析預填行程 → 預覽修改 → 確認寫入（走既有 set_tasks/add_ap_party，零 AP schema 新欄位）；parser adapter registry 支援多版本格式，v1=亞航 CMMC L1 格式 | relates to FR-040（ap-authoring 行程模型） |
| FR-044 | 2026-07-03 | 稽核紀錄 xlsx 匯入 — 稽核執行頁上傳顧問逐條檢查紀錄 → AO 判定＋observation＋佐證分級自動配對 → 批次寫入；FindingState 加 not_applicable（jedi_oscal_v2）；NOT MET 自動建中風險；三層 adapter 架構（template×framework×共用 core，FR-043 registry 泛化） | relates to FR-043（匯入管線同族）/ FR-041（AR 填寫） |
| FR-045 | 2026-07-03 | CMMC 2.0 v2.13 (2024) PDF parser 相容性修正 — jedi-oscal-v2 CMMC adapter 單一 parser 雙格式：L1 FAR 式編號（AC.L1-b.1.i）regex alternation + [FCI/CUI Data] 標題尾綴剝除；行抽取字型分流（Cambria-Bold 標題 vs 內文）解 v2.13 疊字造成的 AO 遺失 / methods 分桶全毀；L1/L2 新舊四份 guide 都要可解析 | relates to FR-024（框架 PDF 匯入 v2） |
| FR-046 | 2026-07-04 | 客戶交付文件套件（架構顧問評估版）— 6 份正式 Word 文件（GAI-SD-01~06：架構 / API 全量規格 / DB / 權限安全 / jedi-* 套件 / 授權清單）；Markdown 內容源 + 共用 python-docx renderer 管線；內容從 code / DB 程式化產生並對帳；產出 docs/交付文件/v1.8.0/ |
— |
| FR-047 | 2026-07-05 | 功能 SPEC 手冊（新人工程師導向）— docs/specs/ 兩層結構（功能群 _overview + 頁面 spec 13 節模板：UC / 權限矩陣 / 狀態機 / 前後端檔案地圖 / API / DB / 頁面邏輯資料對應 / 已知坑 / 開發驗證）；md 為主 + FR-046 renderer 轉 docx 雙軌；pilot = 專案規劃頁 |
relates to FR-046（renderer 共用、GAI-SD-02/03/07 內容引用） |
| FR-048-2607-unified-auth-guard | 2026-07-07 | 全站統一授權守門機制 — 收斂 4 套散落守門 helper 至 common/authz/（platform-admin / super-admin / project-role / capability / signed-token 五軸）；補 B 族（系統設定僅 JWT）+ C 族（GRC 專案寫入裸奔）守門；瀏覽器原生 GET 免 bearer 端點走簽章短期 token。設計拍板前見 docs/analysis/2026-07-07-unified-auth-guard-design.md |
relates to FR-047（SEC 桶產出）/ FR-038 2B（flow_engine 守門復活） |
| FR-049 | 2026-07-18 | 問卷流程規則（跳題）補回 + 子題 Designer 接線 — 復刻 v1 goto 跳題語意（同題組跳題 + 跳一~多個題組，混合情境原生支援）、v2 flowRules 資料形狀、填答端可見性計算引擎；順手收 D-3a 子題兩處 FE 接線。四段完成 commit 未部署；來源側模型經 user 手測拍板推翻 → 由 FR-049.1 目標側重構取代（引擎/快照/子題接線保留） | relates to site-regression bug 批次（D-3） |
| FR-049.1 | 2026-07-18 | 問卷顯示條件（目標側重構）— 跳題規則從「來源選項宣告目的地（goto_*）」翻轉為「目標題目/題組自宣告顯示條件（display_condition）」，解來源側四瑕疵（隱式副作用/漏網坑/零全局視圖/心智模型錯位）；子題定為純排版附屬 + 母題卡直建入口。六決策全拍板見 design §2 | FR-049 母案續作 |
| FR-050 | 2026-07-18 | 稽核輪次階段回退（Stage Rollback）— 流程推進後可有條件返回上一步：僅相鄰上一步 / closed 不可退 / AR 已填保留+標記 / manager only + reason 必填 / UI 可見階段歷程時間軸（新表 round_stage_transitions，advance 也落）。副作用一律作廢標記不物理刪；BPMN 反向支援度為 plan 前提查證第一項。五決策見 design §2 | relates to FR-038（round 狀態機 / stage_advance） |
| FR-051 | 2026-07-21 | 規劃階段推進前置檢核 — 規劃→下一階段（launch_audit）前跑兩項軟提醒（confirm 放行，非硬擋）：A 本輪證據蒐集 job 未完成（reuse get_ap_dashboard 統計）/ B 流程模板 userTask main_role 未在專案參與人員指派（BpmnUtils 列角色 vs participant role）。復用既有 handler-warning→needsConfirmation→force 機制，聚合單一彌窗；兩頁（規劃/總覽）嵌 Banner 自動涵蓋。五決策見 design §1.1 | relates to FR-038（stage_advance）/ FR-050（Banner）；來源 Notion 母題 80ed + 子項 8020 |
| FR-053-2607-round-scoped-jobs | 2026-07-22 | 輪次隔離任務執行（覆核輪 job 實例化）— 根治「第二輪操作污染第一輪歷史」：job 全專案僅一批（project_start 生成一次），任務狀態/證據/聊天/問卷全掛 job 上被跨輪共用覆寫。三刀：① workflow_execution_control_mapping 加 round_id（接線 truth 從 catalog AO props 轉移至 wecm，props 保留相容）② launch_reverify 對 narrowed scope（母輪 not_met）復用 _generate_prep_jobs 核心生成新輪 execution+job ③ 讀取端（control-tree/dashboard/匯出）按輪過濾＋凍結輪範圍改讀本輪 AP reviewed_controls（拆 profile 共用潛伏雷）。AR/凍結 SSP/程序書已健康不動；資源庫（範本工廠層）不動；歷史資料不遷移（user 拍板後續全刪）。調查全文見 Notion case |
relates to FR-038（engagement 模型）/ FR-050（輪次）；影響面僅專案執行層 |
| FR-053.1-2607-reverify-clone-and-context | 2026-07-23 | 覆核輪承襲與脈絡（FR-053 續作，user 手測後拍板）— ①task-execution/progress 統計補輪次（第 3 刀漏網 bug）②覆核輪任務 clone 上輪配置：指派/問卷綁定/設備綁定＋證據 clone（新 row 同檔案帶「承襲自第 N 輪」標記）＋問卷含填答 clone（同帶承襲標記），狀態一律 TODO 起手 ③控制樹「上輪未通過」badge＋控制項卡上輪判定/缺失參照（規劃頁+稽核頁，讀母輪 AR）④查證覆核輪 job PROCESSING 起手根因（應 TODO）。設計原則：第一輪資料零觸碰（clone 只讀），承襲標記讓稽核員分清沿用 vs 新補 | FR-053 母案續作 |
| FR-051.2-2607-stage-advance-prechecks-expansion | 2026-07-22 | 階段推進前置檢核擴展（FR-051 續作）— 軟提醒＋log 備查模式擴到三個推進點：稽核計畫填寫（≥1 筆行程與方法）/ 稽核（所有稽核項目已回報，接 AO/task 完成度）/ 缺失改善（檢核待定義）。全軟阻擋 confirm 放行；比照 PlanningReadinessChecker 掛 stage_advance handler，考慮抽通用 checker 介面。尚未開工——等 FR-051 STG 驗收體感後走 brainstorm→design→plan。來源 Notion case 3a5346da-…-89f5 | FR-051 母案續作；relates to FR-038（stage_advance） |
| FR-052 | 2026-07-21 | 雲端整合 Tab 顯示 gate — 專案規劃頁「雲端整合」tab（index 5）只在 tenant drive status==CONNECTED 時顯示，未連接直接隱藏（fail-closed）。FE v-if gate 末 tab（不影響前 index）；狀態源 tenant get_status。BE 選項：reuse 既有 GET /integrations/google-drive（建議，零改）或新 /connected 端點（待 Step 0 拍板）。三決策見 design §1.1 |
relates to FR-016（Drive 整合）/ FR-042（storage scope）；來源 Notion 80fd |
| FR-055-2607-survey-export | 2026-07-23 | 問卷匯出（既有問卷內容匯出成 Excel 供再匯入）— 把已建立的問卷（題目/題型/選項/顯示條件等設定）匯出成與既有批次匯入樣板相容的 Excel，讓 user 匯出→修改→再匯入複製問卷。範圍待釐清：匯出欄位覆蓋度（FR-049.1 顯示條件等新結構能否被樣板格式承載）、跨租戶搬運情境、要不要含作答資料（傾向不含）。現況：只有空白匯入樣板下載（藏在批次匯入 Dialog 內）。尚未開工——等 user 下令走 brainstorm→design→plan | relates to FR-049/FR-049.1（問卷結構）；來源 Notion case 3a6346da-…-8026 |
| FR-056 | 2026-07-26 | 檢測工具整合平台 — 租戶設定自家檢測工具（首接 OpenVAS，未來 Nessus/SonarQube）→ 任務設「檢測工具執行」+ 掃描參數 → 按開始 → 客戶端 Agent（FR-039 evidence-agent 擴充 executor）觸發掃描 → 報告自動回收成 job_evidences（source=DETECTION_TOOL，沿用 DRIVE_SYNC 模板）→ 發信通知 → 依完成模式 flag 自動完成/人工覆核。新 config schema 三表（detection_tools 目錄 / tenant_detection_tool_configs 加密憑證 / detection_tool_param_schemas 版更參數）；派工走心跳夾帶待辦（D3）；第一版只存報告不 parse findings（D4）。D1–D8 全拍板見 design.md §3。4 子需求 × 15 子任務分階段：.1 工具管理 config schema（地基）/ .2 任務類型+參數 / .3 Agent 派工+executor / .4 執行編排+證據+通知。討論稿 discussion.html |
relates to FR-039（Agent 認證鏈/心跳）/ FR-043·044（三層 adapter registry）/ FR-051（軟提醒）；來源本 session brainstorm |
| FR-057 | 2026-07-28 | OpenSCAP 掃描工具接入（SSH 連線型態）— FR-056 續作，新增第二個檢測工具 OpenSCAP（CIS/STIG 組態合規稽核）並開出 connector 第三種連線型態 SSH（oscap-ssh 官方遠端模式：Agent 維持 Docker 作發起端，SSH 登入目標主機在其上原生執行 oscap、報告拉回）。目標主機前提＝一次性裝 openscap-scanner+scap-security-guide+稽核帳號（Tenable 同款「同名專用掃描帳號」業界標準）。憑證＝租戶層一組共用帳號（金鑰/密碼二擇一推薦金鑰 + sudo 提權），沿用既有加密鏈與 D9 派工下發。證據＝每台一份 HTML 原樣上傳（多目標逐台掃），牽動 result 回收鏈單檔→多檔擴充（result_ref.upload_uids，向下相容）。D1–D7 全拍板見 design.md §2。3 子需求 × 8 子任務：.1 BE 地基（SSH 型態+seed+FE 欄位型態）/ .2 Agent connector / .3 多檔回收鏈（.2/.3 可並行）。討論稿 discussion.html |
relates to FR-056（檢測工具平台/connector 架構）/ FR-039（Agent）；來源本 session brainstorm |
| FR-058 | 2026-07-30 | 檢測工具擴充（四工具接入）— FR-056/057 續作，一次接入 ZAP / InSpec·CINC / GCB / Nmap 四個工具，並補上平台唯一結構性缺口 任務層敏感參數（param_schema 支援 secret: true：BE 存 tool_params 前 Fernet 加密、派工時解密下發、FE 執行紀錄與稽核 log 一律剝除；D1）。ZAP 走 API/daemon 客戶自備（D3），三種 scan_mode 預設被動加攻擊流量警語（D2），PDF 上傳 + JSON 僅記憶體解析雙格式（D4），對齊 zaproxy 0.6.0 與 2.17.0 警報去重語意，舊碼參考前同事 auto-pentest（可搬 API 序列 + 12 報告模板矩陣 + 四種登入認證；必丟 DDD 分層/自起容器/報告落地；必修硬編憑證/無取消無 timeout/Nashorn）。InSpec 選 CINC Auditor（Apache 2.0，非官方商業 binary；D5）、SSH+WinRM 雙 transport 一次到位（D6），吸收並結案 Notion CM-953（異質 OS 檢測；OpenSCAP 官方棄 Windows 已證實不可行）。GCB 不另立引擎複用 .2 connector，content 格式統一 InSpec profile（D8），本案只做引擎 + 一份 Windows 最小 Demo profile，驗收＝鏈路可運作非規則覆蓋量，content 產製/後台更新機制/macOS 15 全排除，但 content 外部載入接口本案就要留（D7）。Nmap 為 CLI 型態首個使用者，NPSL 授權不 bundle 進 image，需先放寬 start_execution 零憑證誤擋（detection_tools 加「是否需要憑證」宣告欄位；D9）。橫向項 _TOOL_ID_TO_CODE 解耦（派工 payload 夾帶 tool code，消除三環境 seed id 錯一位就靜默跑錯工具；D11）最先做完。D1–D11 全拍板見 design.md §2（D10 隨 SonarQube 移出本案，編號保留不重排）。1 橫向項 + 5 子需求 × 20 子任務（Notion CM-957~983，27 張卡連號）。排程＝分批出貨（2026-07-30 改版，ZAP 優先上線）：第一批 ID 解耦＋.0 敏感參數＋.1 ZAP（CM-958~970，切平台側／agent 側兩 session 並行）→ 第二批 .2 InSpec→.3 GCB → 第三批 .4 Nmap；端到端測試留到各批結束才做一次（重建 agent image＋部署三台＋等 300 秒心跳才是真成本）。2026-07-31 追加 SonarQube 兩棒（同一個工具、兩種模式，非兩個工具）：.5 拉取快照（D13–D16，§4.6）——SonarQube Server 沒有任何觸發掃描的 Web API，故為平台首個 pull-snapshot 型工具，任務執行＝拉最近一次分析結果組自包含 HTML（Community Build 無報告匯出，自組是必做非 fallback；issue 明細取前 200 條防 api/issues/search 一萬筆硬上限，統計走 facets/measures 全量）、憑證 base_url+user token（squ_；sqp_/sqa_ analysis token 不能讀）、issue 解析 impacts[] 優先 fallback 舊 type+severity 相容 9.9 LTS~2026.x LTA、probe 陷阱＝authentication/validate 匿名呼叫也回 valid:true 必須帶 header、seed 是 UPDATE 既有 id=3 佔位列非 INSERT（照 ON CONFLICT DO NOTHING 會靜默跳過）；T-5.1~5.3（CM-995+）程式碼已完成 commit，UI 端到端驗收未做（detection_executions 內 sonarqube 仍 0 筆）。.6 主動掃描（雛形）（D17–D24，§4.7）——決策者看到 .5 畫面後指出「要的是平台真的發動掃描」，是新需求不是 bug（D13 排除 agent 自跑 scanner 的前提是「沒有源碼」，本案補上該前提 + 收斂語言解掉「備不齊 build 環境」）；D17 ZAP 式共存（同一張卡 + scan_mode 分流，非另立 tool code——GCB 式唯一優勢「憑證各自乾淨」不存在，實查兩模式共用同一組 config_field_schema 一字不改）、D18 只做 A 類純源碼 7 語言（Py/JS/TS/Go/PHP/Ruby/Kotlin；Java 送進來是硬失敗、C# 是靜默淺掃＝零發現誤讀成很乾淨，故三件配套必做）、D19 公開 Git repo（0 新層；檔案上傳要動 FE 元件+upload 中繼+派工鏈路三層且 RemoteAgentAdapter 在 MINIO 租戶不存在）、D20 scanner 打進 image（zip 自帶 JRE 不裝 JDK；agent 無 docker CLI/socket，poetry.lock 的 docker 7.2.0 是 testcontainers 測試相依洩漏易誤判）、D21 一律加 Guidant-AI- 前綴、D22 只做逾時 + 磁碟型 tmp 掃完即刪（不可用 /dev/shm，那是 tmpfs 記憶體型）、D23 coverage 紅燈照實顯示、D24 scan_mode 預設 scan（與 ZAP D2 預設被動方向相反是刻意的——代價量級不同：D2 是對外部系統送攻擊流量、本案是在客戶自有系統留一筆可刪紀錄；但預設指向不可回復側故事前告知升級為必做）。兩個官方文件確認的坑：①沒有 dry-run（每次掃描都是對客戶 server 寫入、專案不存在會自動建立）②掃完≠能讀（EXECUTION SUCCESS 只代表上傳完成，須解析 report-task.txt 取 ceTaskId 輪詢 ce/task 脫離 IN_PROGRESS，否則拉到舊資料且不報錯；CE 顯示的處理時間不含排隊不能當 timeout 依據）。FE 硬編陷阱 JobExecutionDrawer.vue:308 _PRIMARY_PARAM_KEYS 需一併改（scan 模式下 Git URL 才是主要識別）；模式值非法明確 raise 不靜默降級（照 zap.py:164-171）。拆 T-6.1 BE seed（param_schema v2 + setup_guide 改寫）/ T-6.2 agent（Dockerfile + scan 分支 + 輪詢 + tmp 清理）/ T-6.3 FE + 驗收，.5 的 UI 驗收併入 T-6.3 一起做（決策者：「那版基本不能用了，先不測試，要等這版」）。討論稿 discussion.html（四工具母案）、discussion-sonarqube-scan-mode.html（.6 主動掃描） |
relates to FR-056（檢測工具平台/三表 schema）/ FR-057（connector 架構·SSH 型態·多檔回收·setup_guide）/ FR-039（Agent 心跳派工）；吸收 Notion CM-953；來源本 session brainstorm |
| FR-059 | 2026-08-01 | 檢測工具 Profile / Content 庫（掃描設定檔後台管理）— 把掃描依據（profile / content）從「BE repo 版控＋人工 rsync＋migration seed 選項」四步人工鏈搬進後台管理：上傳（file）/ 登記（url）雙軌（P5，URL 憑證一概不管）、SYSTEM 公用版＋TENANT 租戶自有雙軌（Category C 模式照抄 flow_templates）、version+is_current 單現行版（P4）、任務下拉動態化（param_schema 加 options_source: "profile_library" 宣告，FE 零改即可為未來工具接庫）、agent 動態拉檔＋cache（/data/content/cache/<uid>/v<version>/，sha256 對帳）。即 Notion CM-992 範圍③「後台 content 管理機制」的立案，做完同時消掉封閉網路投放與私有版本庫憑證兩限制。第一期只做形態 A（inspec+gcb，P1）；新表 config.detection_tool_profiles（D1，config schema RLS 有 tenant_detection_tool_configs 前例非首例）；庫參照下發格式 profile:<uid> 顯式前綴、派工展開 _profile（D2）；上傳收 zip / tar / tar.gz / tgz 四格式、50MB、tarfile+zipfile streaming 防 slip/bomb、agent 端統一解壓成目錄餵 cinc-auditor（D4 決策者修訂版）；只驗結構＋檔案安全、正確性由掃描結果反映（D8）；8 支 TWGCB（file 型）＋dev-sec 2 條（url 型）搬遷 seed 上線第一天下拉零回歸（P3/D7）；舊路（bind mount＋靜態 options）過渡一版退役（D5）；agent 取檔復用 FR-058.7 通道、授權 resolver 分流 source_file / profile_ref 兩 claim（P2/D6，resolver 可插拔介面須在 058.7 開工前談定寫進其 T-7.1）。P1–P7 + D1–D10 共 17 項全拍板見 design.md §3。4 子需求 × 12 子任務：.1 BE 地基（表+RLS / API+守門 / 上傳驗證管線 / 搬遷 seed）→ .2 下發整合（宣告升版 / 派工展開 / profile_ref resolver）∥ .4 FE（管理頁 / 下拉動態化）→ .3 Agent 端（cache+拉檔+sha256 / 目錄交付 / 封閉網路驗證，硬依賴 058.7 通道）。Notion 開卡待 058.7 開卡完成後接續（避免 Case No 跳號）。討論稿 discussion.html |
relates to FR-058（母脈絡）/ FR-058.7（agent 取檔通道依賴，先行）/ FR-039（agent 安全基建與 sha256 信任根不變式）；承接 Notion CM-992 範圍③ |
| FR-060 | 2026-08-03 | 檢測基準內容管理（Detection Profile Content Management）— 設計定案，待實作。FR-059 把 profile 檔搬進後台，但平台仍把它當不透明二進位檔，使用者在下拉只看得到一個名字：實跑 TWGCB-01-014 抽取得 234 條控制項，其中 199 條是 impact 0.0 人工待判項（執行時直接 skip）、真正自動檢查只有 35 條、覆蓋率 15%——使用者要等報告出來才知道，等於白等一輪掃描。三個需求：①瀏覽 profile 檢驗內容（核心，選擇「之前」就看得到要驗什麼）②修改基本資料含改名（現況改不動，名稱參與唯一索引，唯一改名途徑是 fork 複製）③分類體系（CINC 不只 OS 連瀏覽器都有，profile 一多下拉會選錯）。核心是主從拆表：detection_profiles 主檔（名稱/描述/分類三軸/scope/工具/is_active）＋ detection_profile_versions 從檔（來源檔/sha256/version/is_current/supports/extraction_status）＋ detection_profile_controls 控制項（一條一列，FR-061 豁免要能以外鍵綁單條控制項，這是最不可逆的決定）。現在是最便宜的時機——DEV 僅 13 筆（10 SYSTEM/3 TENANT）、FR-059 上線才兩天。D1–D19 全拍板見 design.md §3；D5 於 2026-08-03 二度裁示定案：分類 enum 存 DB 由 root 維護（推翻原「FE 寫死」建議），但多語不落庫——DB 只存 key、顯示由前端 i18n 翻譯不另開翻譯表，代價是新 key 未補前端翻譯前以原始 slug 顯示（優雅降級，須寫進 spec 免被誤認為 bug）。四項不可逆決策：D4 uid 由從檔逐列沿用（10 筆凍結契約 soft-ref 零轉換）/ D12+D19 controls 表跨格式形狀（正規欄最小集合＋attributes jsonb＋extraction_format·origin 雙標記，嚴重度欄不叫 impact 免第二個工具進來要改上線表）/ D2 is_current 布林＋partial unique index（不用 FK 當唯一性保證，oscal.frameworks 走過該路且官方已認錯廢棄）/ D3 從檔自掛 RLS 冗餘欄（PostgreSQL 不沿外鍵繼承，file_id 洩漏搭 FR-058.7 取檔通道＝實質檔案越權路徑；本專案首例主從雙表 RLS 無前例可抄）。🔴 兩處派工鏈破口（原以為零影響，實 grep 推翻）：_load_profile() 的 is_active 守門拆表後在主檔，從檔 entity 有屬性但預設 None 則 None is False 為假 → 守門靜默失效、已停用 profile 照樣派得出去（無聲授權漏洞，比 500 更糟）；_humanize_profile_param() 的 getattr(profile,"name",None) 有 default 不報錯，只讓通知信「掃描設定」靜默退化成 profile:<uuid> 且無任何測試會抓到——解法為 domain service 新增 get_version_with_profile(uid) 合成 entity。抽取落點＝BE 主機裝 CINC Auditor（⚖️ 授權紅線 Apache 2.0，絕不可換官方 InSpec 6+ 商業 binary 或 inspec-core gem，均受 Chef EULA；275MB／三台部署機＋每台開發機都要裝／路徑走 CINC_AUDITOR_CMD 比照 LibreOffice 慣例不硬編）；抽取必非同步（234 條 28–29 秒／708 條 117 秒，遠超任何 HTTP 逾時），走 D19 抽取器註冊表骨架（依 profile_format 取 extractor，本期只實作 InSpec）；失敗判定 exit != 0 或 controls == []——第七種錯誤形狀是 Ruby 語法錯導致 exit 0／stderr 全空／JSON 合法但零控制項，只看 exit code 會變無人察覺的資料缺漏。3 子需求：.1 資料模型（拆表＋13 筆三段式搬遷＋RLS 兩表八段＋派工鏈破口修補，地基必先行）→ .2 分類與編輯（含 D5 改存 DB 新增的 enum 表／刪除保護／root 維護介面）∥ .3 抽取與瀏覽。🔴 遷移三大陷阱：搬遷 JOIN 必 (tool_id, tenant_id, name) 三欄（少一欄 id 32/33 會 cross join）／app_tenant_allowed_for_session(integer) 只接 integer 而 tenant_id 是 bigint → 八處都要 tenant_id::integer／id 33 搬遷後是 current_version_id IS NULL 的合法狀態（驗證預期 12 筆非 13）。環境紀律：開發期只套 DEV；STG 已服役（10 筆全 SYSTEM 無 TENANT）→ 🔴「STG 跑得順」不能當驗收依據（測不到租戶 RLS 路徑／32·33 三欄 JOIN 陷阱／孤兒主檔），驗收必須在 DEV；POC 等同 production，STG/POC 均需決策者當次明示放行。舊表只 rename 為 _deprecated_20260803 不 DROP（觀察期後另案）。討論稿 discussion.md |
relates to FR-059（profile 庫母脈絡，直接續作）/ FR-058（檢測工具平台·param_schema 宣告機制）/ FR-058.7（agent 取檔通道，RLS 越權路徑相關）/ FR-039（sha256 信任根）；後續 FR-061（選用範圍／豁免／人工判定／自訂項，本案只定模型契約見 design.md §6） |
| FR-062 | 2026-08-08 | License 控管機制 — 設計定稿，待實作。Guidant AI 上線銷售前的授權地基：公司內部自建簽發端（獨立極簡 Flask 應用＋CLI 共用同一 Ed25519 簽章引擎、獨立 repo 獨立 DB、部署內部不對外；不採 Keygen 等外部 license server）、產品端驗章執法（公鑰列表 kid 查表編譯進後端、時鐘回撥防護）、按功能模組授權（沿用 capability.resource_type，基礎包 21 模組＋4 加值包，Plan 與分層皆為簽發端 plans 表資料非寫死）、可組態到期管線（notify 30 → grace 14 → readonly 終態、lockout 預設關，整組 expiry_policy 簽進照內、產品端零天數設定）、序號開通（離線先行／線上後續兩張 case）與機器指紋綁定、補發換綁、kid 金鑰輪替。照型態只有 formal / trial / extension（過渡照機制刪除，上線 migration 直接為既有租戶發正常照、執法第一天全量生效無特例分支）；升級 Plan＝換發新照立即生效；子租戶上限預設 5。執法走 common/authz 第六軸＋唯讀 gate（全域攔寫入、登入/上傳照豁免）＋任務型態與選單過濾＋環境總開關；順帶補 api/grc/api/project 零守門技術債、退役 TENANT_ADMIN_EXCLUDED_RESOURCE_TYPES。D1–D15 全定案見 design.md §2；8 子需求（FR-062.1–.8）× 28 子任務見 design.md §5。2026-08-10 驗收回饋追加 FR-062.8：角色權限矩陣缺 license 維度（ui-routes 無授權標記／roles 寫入端零檢查／provisioning 未扣未授權模組），未購買模組的能力點看得到也勾得下去且真的入庫，採業界 show-and-disable（反灰＋原因）、存量走 evaluate-time 抑制不刪權限資料（存量項最終定案為反灰空框、差異只留 tooltip，不用假勾勾表達），另含選單結構調整（/license/manage 改由 is_platform capability 表達平台專屬、取代 BE 與 FE 兩份硬編 url 清單；License 兩頁獨立為「授權管理」群組 sort=45；關閉未完成的自定義儀表板入口），× 5 子任務（T-8.1～T-8.5，Notion CM-1166～1171）。討論稿 discussion.md |
relates to FR-048（authz 五軸→六軸）/ FR-054（租戶生命週期·子租戶額度） |
| FR-054-2607-tenant-lifecycle-delegation | 2026-07-23 | 租戶生命週期與管理權下放（經銷商模式）— 五決策已拍板：①租戶 CRUD 全下放子樹管理員（限自己子樹；建 root 仍限 platform admin）②守門沿用 tenant.create/update/delete capability（拔 route 層 @require_platform_admin_route 硬門檻；DB RLS 已支援子樹判定不用動）③刪除改軟刪除（tenants 加 deleted_at；擋登入/選單過濾；空租戶保留硬刪；保留期清除排程後做）④同名策略＝唯一性只算活租戶（partial unique：name WHERE deleted_at IS NULL；恢復時重新查重）⑤復原機制＝獨立「已刪除」清單顯式 restore（絕不同名自動接舊資料，防跨客戶資料洩漏）＋新增時善意提示；另含一條龍最後一哩：建租戶表單選填管理員 email → 自動 add_user 綁 System Manager 角色（寄密碼信）。涉 jedi-auth 套件異動（delete/查重/軟刪在套件內）。設計輸入補充（2026-07-24）：①CM-860 遺留的硬刪 RLS+cascade 500 併入本 FR（軟刪上線即繞過，不另深查）②一條龍 provisioning 必 seed 部門+角色 × tenants FK RESTRICT → 每個正常租戶天生不可硬刪，「刪除」形同虛設——加重軟刪除優先度。尚未開工——等 user 下令走 brainstorm→design→plan；第一段緊急修（POST /tenant 下放）已由 Notion bug-loop 先行處理，見 Notion case 3a6346da-…-8056 | relates to FR-048（authz 五軸）；來源 Notion case 3a6346da-4cd0-8056 |
| FR-063-2608-nuitka-packaging | 2026-08-14 | 落地版程式碼保護：Nuitka 編譯打包（Linux 容器版）— 三階段戰線第一段（FR-063 編譯 → FR-064 防竄改 → FR-065 Installer）。採 Nuitka standalone 編譯為機器碼 binary 包成 Linux Docker image 交付（取代 .pyc 方案），本階段只做 Linux 容器版、另開 production Dockerfile（現有 Dockerfile 為 E2E 專用不可疊改）。2026-08-13 STG 實測：冷 build 1h27m / 產物 808MB，import 期炸 dependency_injector（Cython 與 Nuitka 靜態環境不相容）。清障項：私房 wheel（CYTHON_PEP489_MULTI_PHASE_INIT=0）、DI auto-scan 改 build 期靜態模組清單、eventlet/WeasyPrint 逐雷排除。Notion CM-1187。設計定案 2026-08-14，見 design.md |
relates to FR-062（License Center） |
| FR-064-2608-tamper-detection | 2026-08-14 | 落地版程式碼保護：防竄改偵測與授權鎖定 — 三階段第二段，依賴 FR-063 產物。Build 期逐檔 SHA-256 manifest 以原廠私鑰簽章（復用 FR-062 License Center 簽發體系，不另建 PKI）；啟動驗章＋逐檔比對與 license 驗證共用同一 code path；runtime APScheduler 低頻抽查；偵測竄改 → tamper 雙落點 + exit + 之後啟動一律拒絕，唯一解鎖路徑＝原廠一次性 unlock token。已知限制已對齊：目標是拉高成本 + 留蓄意痕跡，B2B 法律層是真實防線。Notion CM-1188。設計定案 2026-08-15，見 design.md |
relates to FR-062（License Center）/ FR-063（編譯產物） |
| FR-065-2608-onprem-installer | 2026-08-14 | 落地版 Installer（安裝器與交付流程）— 三階段第三段，依賴 FR-063（image 產物）與 FR-064（簽章/license 機制）。目標：客戶端落地安裝標準化，不依賴原廠工程師手動部署。2026-08-16 設計定案（D1–D12，餘 D11.3/D11.5/D13 開放）：full-stack compose（PG/Redis 全包＋FE production image nginx 同源反代）、docker save bundle＋digest 驗證、分段 SQL＋one-shot init 容器建庫、純 bash install.sh＋Web 設定精靈（setup token＋建 admin＋指紋展示＋license 匯入）、--upgrade 四步與回滾、PROD 簽章鑰、K8s 預留；Windows 僅出評估文件。見 design.md。Notion CM-1189 |
relates to FR-063（image 產物）/ FR-064（簽章機制） |
| FR-066 | 2026-08-18 | 檢測 Agent 原生安裝包 — 把檢測 Agent（evidence-agent）從 docker 三容器出貨改為 Nuitka 編譯＋外部工具全包的一顆 tarball，install.sh 一鍵安裝為 Linux systemd 服務。動機：agent 本職是量測宿主機，指紋（product_uuid / machine-id / MAC）容器內讀不到或會漂移，業界同類（Nessus/Qualys/Wazuh）皆原生交付。D1–D9 全拍板：D1 Nuitka standalone→tarball→systemd（排除 onefile）；D2 agent-db（postgres:16）退役換 SQLite（僅 jedi-file-upload 一張表）；D3 外部工具全包一顆（CINC ~275MB／sonar-scanner＋JRE／LibreOffice＋fonts-noto-cjk／xsltproc／git，~1GB+ 已接受，封閉網路完全自足；ZAP/OpenVAS/OpenSCAP/Nmap 引擎不 bundle）；D4 agent 自起 TLS 8443 砍 nginx sidecar；D5 systemd EnvironmentFile＋互動問答三題、客戶側 mTLS 全自動零 openssl；D6 build 期 manifest 簽章＋啟動驗章（複用 FR-064 泛用層加 agent_manifest type，不做 runtime 全家桶）；D7 升級回滾＝versions/ 目錄＋symlink 切換（無 pg_dump 備份模型）；D8 Windows 只出評估文件；D9 指紋 Linux 原生直讀、廢 collect-host-id.sh、不預抽 OS 抽象層。開放查證 Q1–Q4（LibreOffice 離線化形式／PG 方言掃描／EXCLUDE 名單重評／openscap-utils 殘留）。4 子需求 × 11 子任務串行：.1 Nuitka build 管線與程式改造（SQLite 化／version bake／resource_path／指紋直讀）→ .2 tarball 打包＋工具 bundle＋簽章 → .3 install.sh 七步＋systemd＋upgrade/rollback＋維運子命令 → .4 乾淨機真機＋封閉網路驗收＋客戶手冊＋Windows 評估。標的 repo：evidence-agent。見 design.md、討論稿 discussion.html |
relates to FR-063（Nuitka build 管線）/ FR-064（簽章泛用層）/ FR-065（install.sh 結構）/ FR-039（evidence-agent 本體） |
| FR-067 | 2026-08-23 | 檢測多 Agent 分派（Detection Multi-Agent Dispatch）— 設計定案，待拆卡。檢測任務可設定多組「哪台 agent 掃哪些目標」（assignment），一次執行展開 N 張工單同時派給多台、各掃自己的網段，全部回報完才算完成，報告與通知彙總呈現。動機：現況 _pick_agent 挑機無序且不驗在線（挑中離線機工單永遠 pending 卡死），客戶多網段環境（辦公網/機房網/DMZ 各一台 agent）無處指定「這批目標給哪台」。D1–D9 全拍板（2026-08-23）：D1 模型 B（展開 N 筆 detection_executions 維持與 agent_tasks 1:1，上加 detection_execution_groups 彙總層——1:1 是回報鏈/報告反查/FE 渲染的大量隱含依賴，原地保留）；D2 assignment 存新子表 job_execution_detection_tool_agents（每列有 uid 可單列 CRUD/按列稽核/兩入口併發不互蓋，支撐未來中心 UI 與我的任務頁調整兩場景；排除 tool_params JSONB 內陣列——無列身分且會整份快照進 agent_tasks.params 漏到執行紀錄）；D3 執行前逐台驗證（存在/enabled/未 revoke/有能力/在線）任一不過整次 400 列全部不合格機；D4 彙總＝全成 succeeded/任一敗無跑 partial_failed/全敗 failed/cancelled 比照 failed；D5 auto 完成＝group 全 succeeded 才 complete_job（partial 留人工），順修「多筆各觸發撞 409→agent 收 5xx」地雷（收口 group 列鎖）；D6 通知改 group 收口一封彙總（每 assignment 一列）；D7 整組啟動＋單組重跑＋單組/整組取消（user 修訂比討論稿多單組操作；重跑＝同 group 追加新 execution、彙總以每 assignment 最新一筆計；單組首次啟動第一版不做）；D8 不做存量 backfill（開發階段資料會重置；無 assignment 時 fallback 自動挑一台健康的保留）；D9 四項地基併入（remote-agents 補 capabilities+在線+過濾/執行紀錄 enrich agent 名/test_connection 對齊/_pick_agent 濾離線）。Agent 端（evidence-agent）零改動。6 子需求 × 14 子任務：.1 地基 ∥ .2 資料層 → .3 綁定設置 / .4 展開收口 → .5 彙總呈現與通知 → .6 收尾。見 design.md、討論稿 discussion.md |
relates to FR-056（檢測工具平台）/ FR-058（檢測執行/工單模型）/ FR-039（evidence-agent 心跳領單） |
| FR-068 | 2026-08-25 | 系統 Log 轉發（Log Forwarding）— 已上線（v1.17.0）。系統 log 可於 UI 設定轉發到客戶自有 log server（ELK／Graylog／rsyslog）。D1–D6 拍板（2026-08-25）：D1 協定 Syslog（RFC 5424，UDP/TCP）＋GELF 兩種（三家最大公約數；排除各家專屬 API）；D2 範圍＝應用 log＋稽核事件兩流分開勾選（合規客戶接 SIEM 要的是稽核事件）；D3 系統層全域一份、表帶可空 tenant_id 預留租戶層；D4 轉發失敗不拖垮主服務（QueueHandler 旁路＋靜默降級）；D5 第一版不過濾敏感內容、預留遮罩 pipeline 掛點與 UI 開關位；D6 熱生效＋測試按鈕。agent log 轉發本案不做（未來另案）。3 子任務：T-1 BE（表＋CRUD＋handler 鏈）→ T-2 FE 設定頁 → T-3 手冊三家對接範例，另 T-4/T-5 出版與 188/189 升級、四筆修正（syslog 不合 RFC 5424／license 誤標未授權／遮罩開關隱藏）皆已 Done。見 站台索引、design.md |
relates to 稽核事件埋點（reference_audit_event_logging_pattern）/ FR-065（落地版場景） |
前 13 個（FR-001 ~ FR-013）的提出月份為推估值：它們同屬 2026-04-01 一次性
docs/目錄重組 commit（a098cfa5）遷入，無精確日期，月份依文件內部日期 + 邏輯分組推得。