Files
cc-ci-orchestrator/memory/cfold-paused-pending-upgrade.md

35 lines
1.9 KiB
Markdown

---
name: cfold-paused-pending-upgrade
description: "Phase cfold (custom/ folder collapse) is PAUSED until the running /upgrade-all finishes — must serialize, they conflict on CI"
metadata:
node_type: memory
type: project
originSessionId: 85355980-5e4f-4f90-b1ca-d0e4fe82f04b
---
**ACTION REQUIRED on supervision wakes:** the `cfold` phase (collapse functional/ +
playwright/ → custom/, plan-phase-cfold-custom-folder.md) is **PAUSED** — its loops AND
the watchdog were stopped 2026-06-11 ~22:55. phase-idx is preserved at **9** (cfold), spec
is the 10-phase `…drone;cfold`.
**Why paused:** drone completed 22:31 and the watchdog fired the queued weekly `/upgrade-all`
(session `cc-ci-upgrader`) — exactly as the operator queued it. cfold was added ~20 min
later and auto-started, ending up **concurrent** with the upgrade. They CONFLICT: both drive
real CI/`!testme`, cfold edits the harness (`discovery.py` + moves test files) the upgrade's
`!testme` builds depend on, and the upgrade's version bumps would confound cfold's
"levels unchanged" baseline. Must run serially.
**Resume condition:** once the `/upgrade-all` run in `cc-ci-upgrader` is DONE (read its pane/
log/summary to confirm it finished surveying+PRing all recipes — do NOT trust mere idle; a
slow `!testme` build can idle the upgrader for a while), resume cfold by restarting the
watchdog:
```
python3 -c "import sys; sys.path.insert(0,'/srv/cc-ci/cc-ci-plan'); import launch; launch.start_watchdog()"
```
It reads phase-idx=9 + the 10-phase spec → restarts the cfold loops (builder opus? no —
cfold has no per-phase model override, so sonnet). Then delete this memory.
The `cc-ci-upgrader` session must stay UP meanwhile (it's the in-flight upgrade). Note: a
host reboot would auto-restart loops+watchdog (cc-ci-loops.service, RESUME_PHASE=1) and
un-pause cfold prematurely — if a reboot happens before the upgrade finishes, re-pause.