All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 10m14s
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>