| name | 4x-audit |
| description | 掃描 4x pipeline 過去產出的 artifacts，找出未處理的問題並分類排優先級。 觸發：「4x audit」「audit 4x」「檢查過去問題」「跑 audit」「pipeline 健檢」。 掃描三類來源：discovered-feature-gaps、escalation/review reports、learnings 反覆模式。 產出分類報告（HTML artifact），可選擇批次建立 feature YAML 追蹤， 並以 reconcile 收尾步驟清理已解決項（回標 gaps、4x clean、learn remove）。
|
4x Audit
掃描 4x pipeline 累積的 artifacts，以旁觀者角度找出未處理的問題。
掃描範圍
三路並行（用 Agent tool 各派一個 researcher subagent）：
Source 1: Feature Gaps
檔案：docs/reference/discovered-feature-gaps.md（若不存在則跳過）
以下標記一律視為「已處理」（feature ID 前綴依專案而異，F 和 ws 都要吃）：
[已開 FXXX] / [已開 ws-XXX] — 已開 feature 追蹤[已直接修正] — 已直接修掉[不做] — 評估後決定不處理[延後] — 刻意延後；仍列出但歸入報告的獨立「延後」區塊，不算未處理缺口
對無標記項目，先對照 .4x/features/*.yaml 的 description 內容——若已有 feature
實質覆蓋該項（常見：audit 或人工開了 feature 但忘了回標），歸入 reconcile 清單
（Step 6 補標記），不要當成未處理缺口報出來。
剩下真正未處理的項目，對每筆分類：
- priority：P0（金流/安全）、P1（功能不完整/資料不正確）、P2（已知限制/工具改善）、P3（文件/低影響）
- category：金流安全 / 功能缺口 / 資料正確性 / 工具改善 / 部署設定 / 文件
Source 2: Escalations + Review Reports
先讀 .4x/features/*.yaml 的 status，只掃 status 非 done / abandoned 的
feature 的 run 目錄。done feature 的舊 report 是歷史紀錄不是待辦——功能已
合入，其中的 WARNING 多半早已收斂，全掃會把上線功能的舊 warning 每次重報一遍
（實測：kairos 92 個 done feature 累積 606 行 WARNING、4x repo 140 份含
WARNING 的舊 report，全是噪音）。
對入選 feature 掃描 .4x/run/{feature-id}/rounds/*/ 下的：
escalation.json — needed: true 且根因只是繞過（workaround）沒真正修的review-report.md / deep-review-report.md — WARNING / CONDITIONAL PASS 項目test-report.md — 標記為「已知限制」但應該修的
聚焦在：
- 跨 feature 重複出現的問題
- 從沒被修的 WARNING
同時回報「done/abandoned 但 run 目錄還在」的 feature 清單（4x clean --dry-run
可直接取得），交給 Step 6 詢問是否清理。
Source 3: Learnings 反覆模式
檔案：.4x/learnings.json + .4x/learnings-context.md（CLAUDE.md 內 inline 版亦可）
按主題分群（排除 status=stale 的條目），找出出現 3 次以上的同類問題。
注意樣本池只增不減：判定為 systemic issue 前，先對照 .4x/features/*.yaml
檢查該根因是否已被後續 feature 修掉——已修的不算 systemic issue。
產出兩份：
- systemic issues：主題名、出現次數、根因、建議工具/流程改善
- 過時 learnings 的 id 清單（根因已修、或一次性環境備忘且 used_count=0）——
交給 Step 6 詢問是否清理
執行步驟
Step 1: 前置檢查
確認在有 .4x/ 目錄的專案根目錄。沒有就提示使用者切到正確目錄。
Step 2: 派 3 個 researcher subagent 並行掃描
每個 agent 回傳 JSON array（結構化資料）。
prompt 中明確指定：
- 掃描的檔案路徑（用絕對路徑，基於 working directory）
- 回傳格式（JSON array）
- 分類標準
Step 3: 整合報告
等三路全部回來後：
- 合併去重（同一問題可能出現在 gaps 和 review 兩處）
- 按 priority 排序
- 計算統計：total / P0 / P1 / P2 / P3
- 分為三區塊：
- Systemic Issues（learnings 反覆模式）— 修一個根因消除多條 learnings
- Unactioned Feature Gaps（discovered-feature-gaps 未標已開）
- Unresolved Review Findings（review/escalation 中放過的）
Step 4: 產出 HTML Artifact
用 Artifact tool 產出互動式報告：
- 頂部統計列（total / P0~P3）
- 三區塊卡片式呈現
- 按 priority 可篩選
- 支援 light/dark theme
Step 5: 詢問後續動作
報告產出後問使用者：
要批次建 feature YAML 追蹤嗎？我會把相關項目合併成幾個 feature，不會開零散的。
使用者確認後：
- 讀
.4x/features/ 找最新編號（前綴依專案，F 或 ws）
- 把相關項目合併分群（按領域/repo 分，不超過 10 個 feature）
- 建立 feature YAML（status: not-started）
- 更新 discovered-feature-gaps.md 標記
[已開 FXXX]（或 [已開 ws-XXX]）
Step 6: Reconcile（清理已解決項，逐類確認後執行）
audit 當下已握有「哪些項目其實已解決」的判斷，順手收掉，別留給下次 audit
重報。彙整三類清理清單，逐類向使用者確認後執行：
- gaps 檔漏標（Source 1 找到的「已有 feature 覆蓋但無標記」項）
→ 補上
[已開 FXXX]；使用者當場決定不做/延後的項補 [不做] / [延後]
- done/abandoned 的 run 目錄（Source 2 回報的清單）
→
4x clean <feature-id>。提醒使用者：會刪 rounds/reports/state，
dashboard 看不到該 feature 歷史；不確定就先跳過
- 過時 learnings（Source 3 回報的 id 清單）
→
4x learn remove <id>；若 CLI 支援老化（4x learn prune 含
candidate 老化）優先用 prune
每類都可以整類跳過。全部處理完在報告尾部附 reconcile 摘要
（補標 N 筆 / clean N 個 / 移除 N 條 learnings）。
注意事項
- 不修改任何原始碼，純讀取分析；唯一的寫入動作在 Step 5（建 feature）與
Step 6（reconcile），且都需使用者確認
- Step 6 以外不改
.4x/run/ 下的任何 artifact
- feature YAML 只在使用者確認後才建立
- Systemic issues 通常需要在 4x CLI repo 修，不是當前專案的 feature
