Phase 5 §4: install weekly upgrade cron at completion+1h and verify first kickoff

Operator: when the final phase completes, install the weekly cron anchored to
actual completion — first run ~1h after the build finishes, weekly from then on
(supersedes the fixed "Sat 03:00 UTC" placeholder).

- plan-phase5 §4: orchestrator computes T0=now+1h, installs a weekly job at T0's
  DOW+HH:MM running launch-upgrader.sh start; cron env needs claude on PATH +
  tmux + claude.ai login (mirror cc-ci-loops.service). VERIFY the first kickoff:
  cheap --dry-run pre-check, then confirm the real T0 fire launched the
  cc-ci-upgrader agent (status RUNNING, ran /upgrade-all, summary produced);
  record schedule + verified kickoff in DECISIONS.md.
- upgrade-all skill Cron section + cron memory updated to the completion-anchored
  schedule + first-kickoff verification.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.claude/skills/upgrade-all/SKILL.md

@@ -116,14 +116,14 @@ Designed for a weekly Claude Code scheduled task that runs **`cc-ci-plan/launch-
 which spins up the `cc-ci-upgrader` remote-control agent to run this skill to completion (the agent
 then stays idle/viewable). The cron does NOT invoke `/upgrade-all` inline.
 
-**Agreed schedule:** **Saturday 03:00 UTC** (`0 3 * * 6`) — low-traffic weekend window, PRs waiting by
-Monday.
-
-**Activation trigger (operator, 2026-05-29):** do NOT activate while the build loops are still
-constructing cc-ci — it would contend with them for the shared host. **Activate this weekly cron only
-once the cc-ci build is complete (loops finished / cc-ci stable.)** Until then run it manually /
-on-demand via `launch-upgrader.sh start` (or `fresh`). When activating, create a scheduled task that
-runs `/srv/cc-ci/cc-ci-plan/launch-upgrader.sh start` at `0 3 * * 6` UTC.
+**Schedule (operator, 2026-05-29):** the weekly cron is installed as the **closing action of the final
+build phase (Phase 5)**, and its **first run is ~1 hour after the build completes, weekly from then on**
+— i.e. anchored to actual completion, not a fixed clock slot. Compute `T0 = completion + 1h` and
+install a weekly job at T0's day-of-week + `HH:MM` (`MM HH * * DOW`) running `launch-upgrader.sh
+start`. Then **verify the first kickoff** actually launches the `cc-ci-upgrader` agent. Do NOT install
+it earlier — while the loops are still building cc-ci it would contend for the shared host; until then
+run it manually via `launch-upgrader.sh start`/`fresh`. Full procedure: Phase 5 plan §4
+(`cc-ci-plan/plan-phase5-verify-upgrade-flow.md`).
 
 Re-running is idempotent: already-current recipes report `SKIPPED — up-to-date`; recipes with an open
 PR for the same branch report the existing PR rather than duplicating it.

cc-ci-plan/plan-phase5-verify-upgrade-flow.md

@@ -89,3 +89,28 @@ and **close every PR opened during verification afterward** — do not pollute r
   touch the loops' working clones; shared Swarm is stateful — serialize + tear down.
 - **Bounded:** this phase VERIFIES the flow; it does not redesign the skills. A real defect → fix the
   skill/helper (small) or file it; a bigger idea → `IDEAS.md`.
+
+## 4. On phase completion — install the weekly cron (+1h) and verify it fires
+
+Once V1–V9 pass (the upgrade flow + the `cc-ci-upgrader` agent are proven) AND this is the final phase
+(the whole cc-ci build is complete), the **orchestrator** installs the recurring weekly upgrade cron.
+This SUPERSEDES the earlier fixed "Sat 03:00 UTC" placeholder — the schedule is now anchored to actual
+completion ([[cc-ci-upgrade-all-cron]]).
+
+1. **Schedule = completion + 1 hour, weekly thereafter.** Compute `T0 = now + 1h`; install a **weekly**
+   job at T0's day-of-week + `HH:MM` (cron `MM HH * * DOW`) so the FIRST run fires ~1h after the build
+   finishes, then every 7 days at that same slot.
+2. **What it runs:** `/srv/cc-ci/cc-ci-plan/launch-upgrader.sh start` (→ spins up the `cc-ci-upgrader`
+   agent → `/upgrade-all` DEFAULT → stops idle/viewable). The cron environment must have the `claude`
+   CLI on `PATH`, `tmux` access, and the box logged into the claude.ai account (remote-control) — a
+   bare cron env is minimal, so set `PATH`/`HOME` explicitly (mirror how `cc-ci-loops.service`
+   launches). A user crontab / systemd timer / Claude scheduled task are all acceptable mechanisms;
+   pick one that gives that environment.
+3. **VERIFY the first kickoff (the point of this step).**
+   - Cheap pre-check first: `UPGRADER_ARGS=--dry-run cc-ci-plan/launch-upgrader.sh fresh` (or schedule
+     a one-off test fire a couple of minutes out) to confirm the launcher path works from the chosen
+     cron mechanism's environment.
+   - Then confirm the **real** first fire at T0 (~1h later) actually kicked it off:
+     `launch-upgrader.sh status` shows `cc-ci-upgrader RUNNING`, it ran `/upgrade-all`, and produced a
+     summary. If it did NOT fire/launch (PATH, login, mechanism), fix and re-verify.
+   - Record the installed schedule + the verified-kickoff result in `DECISIONS.md`.