任務到期自己生下一期、掃描自己跑、掃到新的高風險多通知一個人

週期設定用「表單一行摘要＋Dialog」，不攤進表單（提案，等決策者看雛形確認）

• 表單在「任務類型」下方多一行：↻ 每月 · 第 2 期 · 下次到期 2026-11-01 · 自動執行 · 高風險額外通知 2 人　[設定]；沒設週期時顯示「不重複　[＋ 設定週期]」。
• Dialog 內：重複開關、頻率、間隔、下次到期；檢測工具多「自動執行」與「額外通知對象」；下方唯讀列出各期。
• 任務頁籤列上，有週期的任務加一個 ↻ 小標。

理由：週期設定一次很少改，各期列表是執行資訊、不是規劃欄位；攤進表單會讓已經很長的表單再長一截，各期列表還會被擠到最底下。Dialog 跟頁首「快速配置」的做法一致。檢查項目內容與任務表單其餘欄位都不動。

被排除：表單內整塊展開（太長）；另開一欄任務清單（現行沒有這一欄，要重排整頁）。

✅ D1 — 重開語意：每期生一筆新任務

定案：週期到了生一筆新任務，每期一筆、歷史各自獨立；不在同一筆退回重做。

理由：每期的證據、執行紀錄、問卷答案要分開查；退回路徑會把歷次結果疊在同一列。

✅ D2 — 新任務屬同一輪

定案：新任務掛在源任務的同一輪；任務多「期數」與「源自哪筆」兩欄，不另立「週期輪」概念。

理由：輪次是稽核範圍的單位，週期是任務層的節奏；混在一起會跟覆核輪的母輪關係打架。

✅ D3 — 週期設定存在任務層

定案：任務層新欄位（週期單位、間隔、下次到期、自動執行開關）；資源庫 module_frames.frequency 只在建專案時帶入預設，不影響既有專案。

理由：一個評估目標底下會有多筆任務、各自頻率不同；config_schema 只到租戶層且平台不讀。

✅ D4 — BE 排程直查，不動申報表

定案：排程每小時 tick 一支「到期掃描」直接查任務表；不在 jedi-task-platform 加到期／完成掛鉤。

理由：週期是產品業務規則，比照檢測派掃從平台搬出的原則（app/detection_tools/task_type_declaration.py:47-51）；也免一次套件異動。

⛔ D5 — 作廢

SBOM 重新執行本來就沿用上次上傳的源碼包（見探脈盤點 ⑤ 節），週期自動掃走同一條路：到期 → 建新任務 → 依型別自動派掃或通知人。不需另外決定源碼來源。

✅ D6 — 兩種掃描同一套排程機制

定案：到期判斷都在同一支每小時 tick；派掃時檢測工具沿用 agent_tasks.scheduled_at、SBOM 沿用 background_jobs 排單。

理由：兩條派掃路都已存在且可靠，排程只負責「何時生新任務」，不重做派工。

✅ D7 — 門檻等級第一版只做 SBOM

定案：門檻用 SBOM 標準六級，high（含）以上＝CRITICAL、HIGH；檢測工具結果沒有統一等級，第一版不做。

理由：檢測工具單次結果只有各工具不同鍵的 summary，要先正規化才談得上門檻。

✅ D8 — 只在「新出現」high 以上時發（決策者裁）

定案：與上一次掃描比 fingerprint 差集，差集裡有 high 以上才通知。

理由：同一批老弱點每期都寄等於沒寄，收件人很快就會無視；新出現的才是要動作的。SBOM 完成時已算過與上一次的差異（summary.delta），配對鍵 fingerprint 不含版本，升版仍受同一弱點影響不算新的。

✅ D9 — 通知紀錄第一版只記門檻通知

定案：紀錄表只記門檻通知（掃描 uid、等級、收件人、寄出時間、結果），放 BE 主專案，不動 jedi-notification。

理由：決策者要的是「哪次掃描、什麼等級、何時通知誰」可查；指派／完成信納入要改所有既有寄信點，不在本案。

✅ D10 — 語系時區第一版寫死

定案：信件 zh_Hant_TW、時區 Asia/Taipei，沿用現況。

理由：使用者與租戶都沒有語系／時區欄位，補上是獨立工程。

✅ D11 — 冪等靠唯一鍵

定案：新任務唯一鍵「源任務＋期數」；門檻通知唯一鍵「掃描 uid＋收件人」；第一版承諾單副本，多副本靠唯一鍵擋重複。

理由：現有 12 支排程 job 都靠冪等，沒有分散式鎖；唯一鍵是最小的保險。

✅ D12 — 頻率進 system_menus，閒置欄棄用

定案：頻率值進 system_menus（六個 key），FE 四處寫死改讀 menu；module_frames.last_execute_date／next_execute_date 棄用不啟用；TASK_TYPE 五 key 與申報三型別對不上一事只記錄，本案不處理。

理由：下拉選項不寫死是專案鐵則；閒置欄放在資源庫範本上，語意是「範本的」執行日，跟任務層週期是兩回事。

✅ D13 — 問卷週期重開空白重填（決策者裁）

定案：新一期問卷建全新空白快照；「填完問卷不自動完成任務」本案不處理。

理由：每期的回覆要反映當期狀況，帶上期答案容易被直接送出。

✅ 通知對象

定案：預設＝任務執行人員；掃描類多一個「掃到新出現 high（含）以上時額外通知誰」，可選專案參與者或 Party 角色（CRA 填通報聯絡人 vulnerability-contact，FR-135 已預建於 cra_2024.py:136-138）。

理由：執行人是做事的人；對外通報的責任人常常不是執行人。

✅ D14 — 動兩支套件

定案：jedi-flow-engine 的 job_executions 照 D3 直接加欄；SBOM 門檻判斷的觸發點在 jedi-source-scan 的 SBOM 完成轉回處（DetectionResultForwarder，pkg/jedi-source-scan/.../sbom_scan_job.py:74-79）加一個「掃完」回呼，由 BE 註冊。開發期走 path dependency，發版等決策者明示。

理由：週期是任務本身的資料，放套件不另開 sidecar 表；回呼只影響 SBOM，與 D7 一致，範圍比改 jedi-detection 的匯合點 _close_group_if_terminal 小。

被排除：BE 另開一對一任務週期表（sidecar）；改 jedi-detection 匯合點（會牽動檢測工具全部收口邏輯）。

✅ D15 — 支援期提醒併入通知紀錄表

定案：通知紀錄表第一版欄位照門檻通知設計；卡 ⑤ 開工時加 object_type／stage 兩欄，把支援期 90／30／7 天提醒記進同一張表，唯一鍵同步擴成含這兩欄。

理由：「寄過了沒」與「何時寄給誰」只有一處可查；不在版本列上另掛戳記欄。

被排除：版本列單欄戳記（三個階段要三欄，且查不到寄給誰）。

✅ D16 — 通報三階段期限提醒不做

定案：卡 ⑤ 只做支援期提醒；24 小時預警／72 小時通報／最終報告提醒不做。

理由：起算點是通報案件的「知悉時間」，通報案件頁籤已裁不做，系統裡沒有這筆資料。日後恢復通報案件時再接同一套排程與紀錄表。

✅ D17 — 首掃的 high 以上全算新出現

定案：沒有上一次可比的掃描（summary.delta 為空），high 以上全部當新出現、照寄。

理由：第一次掃描就是第一次知道它們存在。

✅ D18 — 頻率 menu group 名 task_frequency

定案：system_menus group＝task_frequency，任務與資源庫共用。

理由：與近期新增的小寫 group（ssp_party_role、risk_reference_standard）一致。