ideas: isolate the upgrader's direct deploy onto separate infra (can't tamper with tests)

The step-2b direct deploy-and-inspect runs on the cc-ci server's own swarm today, so
the upgrader holds write access to the host that owns the tests + CI verdict — a
trust hole (could hack the tests). Parked idea: a dedicated throwaway test server
with scoped creds, so the upgrader can deploy+inspect but not modify the gate.

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

cc-ci-plan/IDEAS.md

@@ -130,3 +130,32 @@ item into the project `BACKLOG.md` as `[idea]` if/when it becomes relevant.
   - *When to revisit:* after the server regression canaries land (want self-tests before re-architecting
     the thing that runs them). Treat as a design spike — the runner's Swarm-access model (socket / DinD /
     separate Swarm) is the decision that drives everything else.
+
+- [ ] **Move the upgrader's direct deploy-and-inspect onto SEPARATE infra (isolate it from the cc-ci
+  server, so it can't tamper with the tests).** *(operator-flagged 2026-06-09)*
+  The upgrader now has a direct deploy-and-inspect dev loop (`/recipe-upgrade` step 2b): it deploys the
+  WIP recipe with `abra app deploy --chaos` and reads `docker service logs` to debug an upgrade before
+  the `!testme` CI gate. **Today that runs on the cc-ci server's own local swarm** — i.e. the autonomous
+  upgrader (and its subagents) hold `ssh cc-ci` + root + docker + abra on the **same host that owns the
+  harness, the recipe tests, and the CI verdict**. That's a trust-isolation hole: an agent with write
+  access to the box that gates it could — by accident, prompt-injection, or reward-hacking — **edit the
+  tests/harness to make a failing upgrade "pass"** ("hacking the tests"). We can't be fully sure the gate
+  is honest while the thing being gated can modify the gate.
+  - *Idea:* give the upgrader a **dedicated, throwaway test server** (a real `cctest`-style host, like
+    recipe-maintainer's `cctest.autonomic.zone`) for the step-2b deploy/inspect loop, reached with
+    **scoped, test-only credentials** (its own SSH key/abra context — blast radius limited to that host,
+    per recipe-maintainer's `test-ssh/` model). The upgrader gets all the live-log feedback there and has
+    **no write access to the cc-ci server**. The cc-ci `!testme` CI stays the independent, tamper-proof
+    gate — run by infra the upgrader cannot touch — so a GREEN verdict means the tests it can't edit
+    passed.
+  - *Pros:* the CI gate becomes trustworthy under an autonomous/untrusted upgrader (least-privilege:
+    the agent can deploy + inspect but not alter the harness/tests/verdict); cleaner separation of
+    "develop the upgrade" (test server) from "verify the upgrade" (cc-ci CI); matches recipe-maintainer's
+    limited-blast-radius `test-ssh/` posture.
+  - *Cons / crux:* new infra to provision + keep current (a second Co-op Cloud host or VM, abra
+    `server add`, scoped SSH creds, its own teardown/orphan-sweep); cost + maintenance; and the harness
+    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).
+  - *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.