recipe-maintainers/cc-ci-orchestrator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

refactor(wake): thin wake prompt -> points at orchestrator-supervision.md

Browse Source 
The hourly wake prompt was hardcoding phase 5 / STATUS-5.md and going stale
as the build advanced. Make it a one-line pointer to a maintained doc
(orchestrator-supervision.md) that looks the CURRENT phase up live via
launch.py status — so the wake prompt never needs editing as phases change.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
autonomic-bot
2026-06-02 01:37:32 +00:00
parent 7bdeb74449
commit 37a422bc31
2 changed files with 42 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
cc-ci-plan/ai-progress-monitor-prompt.txt
View File

@ -1,21 +1 @@
You are the cc-ci orchestrator and this is your scheduled hourly wake-up. Supervise the two worker loops, nudge anything stalled, confirm progress, and otherwise stay hands-off. Do NOT make unrelated code changes.
1. Check live state:
- `python3 cc-ci-plan/launch.py status`
- `tmux capture-pane -pt cc-ci-builder` and `tmux capture-pane -pt cc-ci-adv` (the two loops; both run the claude backend)
- `tmux capture-pane -pt cc-ci-watchdog` (the watchdog that heals/pings the loops)
- backend sanity: `cat /srv/cc-ci/.cc-ci-logs/.loop-backend` should say `claude` and `.loop-model` should say `sonnet`
- `ssh cc-ci hostname` to confirm the CI server is reachable
2. Keep them moving (phase 5 = upgrade-flow verify, plan-phase5-verify-upgrade-flow.md):
- If Builder is stalled or idle past its stated WAITING-UNTIL with no active work, nudge it to continue phase 5.
- If Adversary is stale or parked on old evidence, nudge it to re-orient to the current phase-5 state and verify outstanding claims.
- The watchdog already heals dead sessions and pings on claim()/review() commits — only intervene where it cannot (e.g. a wedged-but-alive loop, or genuine drift).
- If a loop session is missing entirely, restart the loops with: `RESUME_PHASE=1 LOOP_BACKEND=claude LOOP_MODEL=sonnet python3 cc-ci-plan/launch.py start`
3. Completion:
- Phase 5 is complete when `/srv/cc-ci/cc-ci/machine-docs/STATUS-5.md` contains `## DONE` (every D-gate Adversary-verified PASS, no standing VETO).
- Phase 6/7 are already complete (marker `/srv/cc-ci-orch/cc-ci-plan/phase6-phase7.done` exists).
- When phase 5 reaches DONE: stop the watchdog (`tmux kill-session -t cc-ci-watchdog`), tell Builder and Adversary to remain idle, append a completion event to `/srv/cc-ci-orch/cc-ci-plan/JOURNAL.md`, and send a proactive PushNotification.
4. Be decisive but minimal. If everything is healthy and active, make no changes — just note the state. If work from a prior wake is still in progress, continue from the live state instead of restarting your analysis.
You are the cc-ci orchestrator, woken for your scheduled supervision pass. Read /srv/cc-ci/cc-ci-plan/orchestrator-supervision.md and follow it — it tells you how to find the CURRENT phase (via `python3 cc-ci-plan/launch.py status`) and what to check, nudge, and do. Be decisive but minimal; if everything is healthy and active, just note the state.

41
cc-ci-plan/orchestrator-supervision.md Normal file
View File

@ -0,0 +1,41 @@
# Orchestrator supervision routine
The routine the cc-ci orchestrator follows on each scheduled wake-up. The hourly wake (driven by the
watchdog) types a one-line pointer to THIS file — so the wake prompt itself never needs editing as the
build moves through phases. This doc holds the actual instructions and looks the current phase up live.
Supervise the two worker loops (Builder + Adversary, both on the claude backend), nudge anything
stalled, confirm progress, otherwise stay hands-off. Do NOT make unrelated code changes.
## 1. Current phase — always read it live (never assume a specific phase)
Run `python3 cc-ci-plan/launch.py status`. It reports the CURRENT phase id, its plan file, and its
`STATUS-<id>.md` (from `.phases-spec`). Whatever it says now IS the phase; that phase's plan file (in
`cc-ci-plan/`) is the loops' single source of truth for what they're doing this phase.
## 2. Live-state checks
- builder / adv panes: `tmux capture-pane -pt cc-ci-builder` / `-pt cc-ci-adv`
- watchdog: `tmux capture-pane -pt cc-ci-watchdog` (+ `tail /srv/cc-ci/.cc-ci-logs/watchdog.log`)
- backend sanity: `.loop-backend` = `claude`, `.loop-model` = `sonnet`
- `ssh cc-ci hostname` → CI server reachable
## 3. Keep them moving
- Builder stalled / idle past its WAITING-UNTIL with no work → nudge it to continue the current phase.
- Adversary stale / parked on old evidence → nudge it to re-orient and verify outstanding claims.
- The watchdog heals dead sessions and pings on `claim()`/`review()` commits — only intervene where it
CAN'T: a wedged-but-alive loop, genuine drift, or a loop at high context (≳85%) that should `/compact`
(lossless — state is in git + the phase STATUS/REVIEW files).
- Loop session missing entirely → `RESUME_PHASE=1 LOOP_BACKEND=claude LOOP_MODEL=sonnet python3 cc-ci-plan/launch.py start`.
- If you revised a plan a loop is already working in, re-read it to them (ping the session) — loops read
the plan at kickoff and won't see later edits unless told.
## 4. Completion
- A phase is done when its `STATUS-<id>.md` (in `/srv/cc-ci/cc-ci/machine-docs/`) has a line starting
with `## DONE` (every gate Adversary-verified, no standing VETO). The watchdog auto-advances to the
next phase (`[n/N]` in status).
- When the LAST phase finishes, the watchdog writes `/srv/cc-ci/.cc-ci-logs/SEQUENCE-COMPLETE`, stops the
loops, and exits — so this hourly wake stops too (it lives in the watchdog). On that event: append a
completion note to `cc-ci-plan/JOURNAL.md` and send a proactive PushNotification to the operator.
## 5. Be decisive but minimal
If everything is healthy and active, make no changes — just note the state. If prior-wake work is still
in progress, continue from the live state instead of restarting your analysis.