# cc-ci-autonomous-orchestrator — AGENTS.md

This folder is the **orchestrator** workspace for building the **cc-ci** Co-op Cloud recipe CI
server. It holds the plan, the launch/supervision tooling, and the two loop prompts. The actual CI
project (NixOS config, test runner, recipe tests) lives in a **separate** repo the loops create at
`git.autonomic.zone/recipe-maintainers/cc-ci` — do not confuse the two.

## Three roles (don't conflate them)

1. **Orchestrator** — *this* session/role. Supervises: checks in on the two loops, reads their
   logs/STATUS, makes changes to the plan/prompts, restarts loops, and owns the VM-level fallback.
   It is **separate** from the loops and is the only role that should power-cycle/recreate the VM.
2. **Builder loop** — builds the CI server (`cc-ci-plan/prompts/builder.md`).
3. **Adversary loop** — independently disbelieves/verifies (`cc-ci-plan/prompts/adversary.md`).

The two loops coordinate **only** through the cc-ci git repo (see `plan.md` §6.1). The orchestrator
watches from outside.

## Keep the orchestrator open, under remote-control

Run this session as a long-lived **interactive** session with `--remote-control` so the operator can
check in on the loops and steer/restart things from **claude.ai/code** (or the Claude mobile app)
without being at the terminal.

- **Already in the session?** Just run `/remote-control` — it attaches claude.ai/code to the live
  conversation (no exit, no resume needed).
- **Starting fresh:** `claude --remote-control 'autonomous-orchestrator' --dangerously-skip-permissions`
- **Resuming this orchestrator later (history preserved):**
  ```bash
  claude --resume autonomous-orchestrator --remote-control "autonomous-orchestrator" --dangerously-skip-permissions
  ```
  Note the two names are different: `--resume <name|id>` restores *this conversation* (the name set
  via `-n/--name`, shown in the `/resume` picker); the `--remote-control [name]` value is only the
  web display label and resumes nothing. The conversation persists on disk across exits; remote
  control itself only stays "connected" while the local process is alive (resume + re-enable to get
  it back after a full exit).

Use it to: tail loop logs (`cc-ci-plan/launch.sh logs builder|adversary|watchdog`), inspect
`STATUS.md`/`REVIEW.md` in the cc-ci repo, edit the plan or prompts, restart a stuck loop, or
power-cycle/recreate the cc-ci VM (see `cc-ci-plan/kickoff.md` → "Fallback: restart/recreate the
cc-ci VM"). The orchestrator is the human's steering wheel; the loops are the engine.

## Launch & supervise the loops

- **Source of truth for the loops:** `cc-ci-plan/plan.md` (mission, Definition of Done, §1.5
  credential map, §6 two-agent protocol, §7 loop discipline).
- **Launch/supervision guide:** `cc-ci-plan/kickoff.md`.
- `cc-ci-plan/launch.sh start` → both loops (interactive `--remote-control` in tmux) + a watchdog.
  tmux is installed; `launch.sh` defaults now point at `/srv/cc-ci/...`.

## Access & credentials (pointers only — values are gitignored)

- `.testenv` (**NOT committed**): Tailscale auth key + Gitea bot creds. Load with
  `set -a; . .testenv; set +a` (never echo the values).
- **cc-ci:** `ssh cc-ci` (root) tunnels through the persistent userspace-tailscaled SOCKS proxy on
  `127.0.0.1:1055` (`cc-ci-tailscaled.service`). If down: `sudo systemctl restart cc-ci-tailscaled`.
- **Incus/VM fallback:** mTLS certs at `/srv/incus-terraform-nix-vm-creator/terraform-secrets/`;
  b1 is on the same tailnet (reach via the same proxy). See kickoff "Fallback".
- **Full credential map + how to use each:** `plan.md` §1.5.

## Hard rule

Never commit secret values. `.testenv`, `*.tfstate`, `*.key`/`*.pem`, and the loop runtime/clone
dirs are gitignored. Reference secret *locations*, never their contents (`plan.md` §9).