guardrail: upgrader never modifies cc-ci tests/harness unless --with-tests

Absolute, mode-gated rule reinforced in /recipe-upgrade (Guardrails + the new
step-2b direct-deploy loop where the upgrader has cc-ci host access) and noted as
the interim safeguard in IDEAS.md until the deploy loop moves to isolated infra.

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

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

@@ -152,6 +152,12 @@ ssh cc-ci 'export PATH=/run/current-system/sw/bin:$PATH; set -a; . /srv/cc-ci/.t
 - Caveats: shared swarm — keep to **ONE** `dev-<recipe>` instance at a time and tear it down before the
   next recipe; the `dev-<recipe>` domain is distinct from the harness's per-run domains and from the
   `warm-*` canonicals, so the sweep removes a leaked one without touching live services.
+- 🚫 **This loop deploys + inspects ONLY — it must NEVER modify the cc-ci tests or the harness.** You
+  have host access here, but the cc-ci `tests/**` and `runner/**` are the independent gate, not yours to
+  touch: do not edit a test/overlay to make a `dev-` deploy or a `!testme` go green. Editing cc-ci tests
+  is gated **exclusively** by `--with-tests` (step 5b); in DEFAULT mode a stale test gets a PR **comment**,
+  never an edit. Fix the *recipe*, never the gate. (Interim rule while the upgrader still runs on the
+  cc-ci host — see `cc-ci-plan/IDEAS.md`, "Move the upgrader's direct deploy onto separate infra".)
 
 ### 3. Open the recipe PR (never merge)
 ```
@@ -236,6 +242,11 @@ Always state explicitly that **nothing was merged** — the PR(s) await operator
 - **Tests are opt-in.** Default = recipe PR only, existing tests; a stale-test failure gets an
   explanatory PR **comment**, never a test edit. Only `--with-tests` opens a cc-ci test PR. The weekly
   `/upgrade-all` cron always runs the **default** — it never auto-updates tests.
+- 🚫 **NEVER modify the cc-ci tests or harness (`tests/**`, `runner/**`) unless explicitly invoked with
+  `--with-tests`.** This is absolute and mode-gated — it holds in every step, including the step-2b
+  direct-deploy loop where you have cc-ci host access. The tests are the independent gate; never edit
+  them to turn a `dev-` deploy or `!testme` green. In DEFAULT mode, fix the recipe or leave a PR comment
+  — never touch the gate. (Interim safeguard while the upgrader runs on the cc-ci host; see `IDEAS.md`.)
 - **Mirror reflects reality.** Each run force-syncs the `recipe-maintainers/<recipe>` mirror `main` to
   true upstream main and closes open PRs already merged upstream. It does NOT close superseded/unrelated
   open PRs. **An existing open upgrade PR is extended (new work pushed onto its branch + re-tested)

cc-ci-plan/IDEAS.md

@@ -157,5 +157,10 @@ item into the project `BACKLOG.md` as `[idea]` if/when it becomes relevant.
     deploy path may assume `--server default`/local, so the per-run CI deploys vs the upgrader's
     test-server deploys need a clear split. Until then, the local-swarm dev loop + the orphan-sweep are
     the interim posture (functional, but NOT isolation-safe against a malicious/compromised upgrader).
+  - *Interim safeguard (in force now, until this lands):* the upgrader **must NEVER modify the cc-ci
+    tests or harness (`tests/**`, `runner/**`) unless explicitly invoked with `--with-tests`** — encoded
+    as an absolute guardrail in `/recipe-upgrade` (and its step-2b direct-deploy loop). It is a written
+    rule, not an enforced boundary — which is exactly why the separate-infra isolation above is the real
+    fix.
   - *When to revisit:* before running the upgrader fully unattended/untrusted at scale, or alongside the
     "package cc-ci as a recipe" spike above (both hinge on a separate disposable test Swarm). *Added:* 2026-06-09.