weekly health-gated auto-update of the cc-ci host; skills rewritten for the combined host

nix/modules/auto-update.nix (own module, no notplants-nix dependency): Tuesday
03:00 UTC, busy-gated (CI run, weekly upgrader, report, sweep, running Drone
builds → skip), `nix flake update` → build → switch-to-configuration test →
cc-ci health checks (sshd, 0 failed units, core units, every swarm service at
replica count, sops decrypted, dashboard/reports/drone 200, opencode UI 401)
→ profile + bootloader → flake.lock committed and pushed to main → /etc/cc-ci
fast-forwarded; revert + lock restore on failure; one-line state file for
/cc-ci-status.

Skills (.opencode canonical, .claude pointers' descriptions synced):
- cc-ci-orchestrator-update: THE host update — drives the auto-update unit by
  hand; --cc-ci-only for a cc-ci-main-only move; failure playbook.
- cc-ci-server-update: delegates to it and explains why the old procedure
  (rebuilding the cc-ci repo's standalone #cc-ci) must not be run on this host.
- cc-ci-update: chains orchestrator-update then tests-update.
- cc-ci-status: §5/§6 for one host — auto-update state, generation vs boot
  generation, front doors (oc.ci = 401), sops, fail2ban, timers, orchestrator
  agent session, secrets inventory; verdict updated.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FqkQq3CDmFWcQ7u1LzoyRz

.opencode/skills/cc-ci-update/SKILL.md

@@ -1,12 +1,11 @@
 ---
 name: cc-ci-update
-description: Run both cc-ci maintenance updates in one pass — first /cc-ci-server-update (bump the cc-ci server host's nixpkgs/sops-nix flake inputs, rebuild + verify the live server), then /cc-ci-tests-update (sweep all maintained recipes for stale cc-ci tests, update the stale ones, verify each via the standard PR + !testme -> CI flow). The combined "keep cc-ci itself current" skill: host deps + test suite, both done end-to-end with PRs opened for visibility and merged directly once verified (the skill invocation is the authorization), a healthy server at the end, and a report listing every merged PR link + a summary of what changed in each. Invoke as /cc-ci-update.
+description: Run both cc-ci maintenance updates in one pass — first /cc-ci-orchestrator-update (the cc-ci host: nixpkgs, sops-nix and the cc-ci input, test → health check → switch, lock committed to main), then /cc-ci-tests-update (sweep all maintained recipes for stale cc-ci tests, update the stale ones, verify each via the standard PR + !testme -> CI flow). The combined "keep cc-ci itself current" skill: host deps + test suite, both done end-to-end with PRs opened for visibility and merged directly once verified (the skill invocation is the authorization), a healthy server at the end, and a report listing every merged PR link + a summary of what changed in each. Invoke as /cc-ci-update.
 ---
 
 # cc-ci-update
 
-The combined **keep cc-ci itself current** pass: run `/cc-ci-server-update` (host dependency bump +
-rebuild) **then** `/cc-ci-tests-update` (stale-test sweep + fixes), in that order, end-to-end. This
+The combined **keep cc-ci itself current** pass: run `/cc-ci-orchestrator-update` (host dependency bump + health-checked rebuild) **then** `/cc-ci-tests-update` (stale-test sweep + fixes), in that order, end-to-end. This
 is just sequencing the two skills — it doesn't add or change any behavior. Read each sub-skill's
 SKILL.md for the full procedure; this file is the orchestration + the why-of-the-order.
 
@@ -21,7 +20,7 @@ SKILL.md for the full procedure; this file is the orchestration + the why-of-the
 ## Arguments
 
 None. (If you only want one of the two updates, invoke the sub-skill directly:
-`/cc-ci-server-update` or `/cc-ci-tests-update`.)
+`/cc-ci-orchestrator-update` or `/cc-ci-tests-update`.)
 
 ## Preconditions
 
@@ -34,12 +33,12 @@ Both sub-skills' preconditions hold:
 
 ## Procedure
 
-### 1. Run `/cc-ci-server-update` (host first)
+### 1. Run `/cc-ci-orchestrator-update` (host first)
 
-Run the full `/cc-ci-server-update` procedure: snapshot baseline → bump flake inputs (nixpkgs +
+Run the full `/cc-ci-orchestrator-update` procedure: snapshot baseline → bump flake inputs (nixpkgs +
 sops-nix) → commit + open cc-ci PR → stage on host → build → `nixos-rebuild switch` → **health
 gate** (no failed units, infra up, endpoints 200, disk free). See
-`.claude/skills/cc-ci-server-update/SKILL.md`.
+`.claude/skills/cc-ci-orchestrator-update/SKILL.md`.
 
 **Gate on the result before continuing:**
 - `SUCCESS` → the server is on the new nixpkgs, healthy. Proceed to step 2.
@@ -90,7 +89,7 @@ operator review.
 Inherited from both sub-skills (read their Guardrails sections). The combined-specific ones:
 - **Server-first, gated.** Don't run the tests sweep on a sick/rolled-back host. The server-update
   health gate is a hard go/no-go for step 2.
-- **No-CI window for the rebuild** (the server half) — same as `/cc-ci-server-update`.
+- **No-CI window for the rebuild** (the server half) — same as `/cc-ci-orchestrator-update`.
 - **Serialize the tests half on the shared Swarm** — same as `/cc-ci-tests-update`; don't run it
   concurrent with `/upgrade-all` or active build loops.
 - **Never merge anything** — server PR, test PRs, paired recipe upgrade PRs all operator-merged.