Files
awoooi/apps
Your Name 2f5cab2e45
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 10m14s
feat(coverage_evaluator): Gap 3.3 LLM 升級 — 缺口分析 + 補覆蓋建議
Gap 3 進度: 4/9 service 升級 LLM (達到合理上限 — 其他 4 個純資料移動不需 LLM)

coverage_evaluator 原本 7 維升級 unknown→green/yellow/red 後無主動建議.
新增:

1. _fetch_red_summary: 撈最新 run 的 red 分布 + top 10 被標 red 的 asset
2. _llm_analyze_coverage_gaps (~50 行):
   有 >= 20 red 時才跑 LLM (避免 well-covered 集群浪費 token)
   LLM JSON 輸出:
     - worst_dimension: 最該優先補的維度
     - root_cause: red 集中的真因 (繁中)
     - top_remediation_actions[3]: priority/target/action/effort
     - estimated_weeks_to_close: 1-52
     - confidence: 0-1
3. _send_telegram_gaps: 推 coverage 缺口 Telegram 摘要
   總 red + 最嚴重維度 + 補齊週數 + top 3 補覆蓋動作

scan 完流程:
  評估 7 維 → 撈 red summary → LLM 分析 (if total_red >= 20) → Telegram

統帥鐵律對齊:
   不寫死補覆蓋優先 (LLM 根據實際 red 分布推)
   AI 建議 + 人工決策 (Telegram 末行: '人工評估補覆蓋排程')
   包含預估完成時間 + 信心 (可追蹤)

session 累計 35 commits, 9 新 scanner, 4 用 LLM:
  - Hermes (rule quality)
  - capacity_forecaster (容量預測)
  - compliance_scanner (合規態勢)
  - coverage_evaluator (覆蓋缺口)
剩 5 個純資料移動不適合 LLM (asset_scanner/rule_catalog_sync/
                           rule_stats_updater/asset_change_tracker/capacity_scanner)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-19 22:02:36 +08:00
..