gh-ci-watch

<!-- 🔒 LOCKED — managed by clade · auto-generated by sync-to-codex; edit source in .claude/ then re-run sync --> # /gh-ci-watch — GitHub Actions 監看 / 查詢唯一入口 **核心 contract**：監看 CI = **機械輪詢**。用 `Bash(run_in_background=true)` 跑 `gh-ci-watch.sh`——腳本自己 poll 到 terminal state 才 exit，主線只在**完成時收到一次通知**。等待期間零 LLM turn、零 token、行為 100% 確定。 Script 位置： - Consumer 端（hub-core 投影）：`.codex/scripts/gh-ci-watch.sh` - Clade home：`plugins/hub-core/scripts/gh-ci-watch.sh` ## 機制選擇：為什麼是 background Bash + script，不是其他 > 這段是本 skill 存在的理由。**NEVER** 退回用 Agent subagent 監看 CI——那正是本 skill 要根治的事故根因。 **事故實證（2026-07-25，perno v0.99.7 發版）**：依當時規約派兩個 `Agent(run_in_background=true)` watcher subagent 監看 Deploy Staging / Production，實際發生四件事：(1) brief 明寫「completed 才回報」，agent 仍反覆中途回報「持續監看中…」，每次回報都是一次 LLM turn，累計 **235k+ tokens 且沒有產出最終結果**；(2) 監看的 staging run 被 concurrency `cancel-in-progress` 取消後，agent 繼續空等已死的 run；(3) SendMessage 改派新 run id，agent 口頭答應卻仍回報舊 run 結論；(4) 同一份 brief、同一個 model，兩個 watcher 行為不一致。 | 機制 | 判定 | 理由 | | --- | --- | --- | | **`Bash(run_in_background=true)` + 本 script** | ✅ **採用** | 官方定位就是「單次通知：告訴我 X 好了沒」。腳本達 terminal state 即 exit → 剛好一次通知；無 LLM 參與 → 零等待成本、行為確定。事故中需要「判斷力」的三件事（run 尚未建立、被 concurrency 取代、同 SHA 多條 run）其實都是**機��規則**，已全部編進 script（Phase 1 pending 重查、Phase 2 successor 追蹤、`--since`/`--commit` 過濾），不需要 LLM | | `Agent(run_in_background=true)` | ❌ 禁用 | 見上方事故四點。LLM「判斷力」在這個場景是負資產：不可預測 + 每個動作燒 token。唯一例外見下方「例外」節 | | `Monitor` | ❌ 不用 | 官方定位是「**每次發生**都要通知」的事件流（`tail -f` 型）。CI 監看要的是**恰好一次**完成通知—...