1.9 KiB
name, description, metadata
| name | description | metadata | ||||||
|---|---|---|---|---|---|---|---|---|
| cfold-paused-pending-upgrade | Phase cfold (custom/ folder collapse) is PAUSED until the running /upgrade-all finishes — must serialize, they conflict on CI |
|
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.