- `[2026-07-18]` **soong-lab auto-redeploy — DONE + VALIDATED** (was approved/queued; executed same day on fresh context — see AS-BUILT at the bottom).

Vuong approved wiring auto-redeploy for soong-lab (relayed via soong-dev, thread
`01KXT3A6C3908TA4V9THV3AMH7`): new images should go live on corviduo-dev without
the manual `docker compose pull && up -d`. Host-side implementation is infra-ops's
lane; mechanism is infra-ops's call per fleet conventions. Operator deferred
execution — "we'll do soong on fresh context."

**Chosen mechanism (recommended, agrees with soong-dev): Worldtree-style
CI-deploy step** — NOT watchtower polling.
- Add a deploy job/step to soong-lab's `.gitea/workflows/build-and-push.yml` that,
  after the build+push job succeeds, **SSHes from the pfi-fleet runner to
  corviduo-dev** and runs `cd /home/infra-ops/soong-lab-deploy && docker compose
  pull && docker compose up -d`, then a **health-gate** (`curl -fsS
  http://localhost:8443/api/version`).
- This is exactly how WT deploys the demo instance to the SAME host: see
  `~/development/Worldtree/.gitea/workflows/deploy.yml` — the "Deploy to demo VM +
  health-gate" step uses `secrets.DEMO_VM_SSH_KEY` / `DEMO_VM_HOST` / `DEMO_VM_USER`.
  Explicit-over-implicit (visible in the run log, fires exactly on build success),
  one less always-on service than watchtower.

**Constraints (from soong-dev):** deploy on CI success only; keep the trigger
gated to `v*` tags + `workflow_dispatch` (as today); preserve the one-command
rollback posture (`docker compose down` / pin a previous tag).

**BLOCKER — needs from vh (owner-only):** a **runner→corviduo-dev deploy SSH key**
as a repo secret (+ host/user), same class as WT's `DEMO_VM_SSH_KEY`. Likely
**reuse WT's existing demo-deploy key** (WT's runner already SSHes to 10.250.50.152
as its deploy user). Repo secrets are vh-owner-only (see
[[2026-07-18-fleet-gitea-runner-build-recipe]]).

**Next-session steps:** (1) confirm/obtain the deploy SSH-key secret from vh (reuse
WT's or mint fresh); (2) add the deploy job to build-and-push.yml (infra-ops has
push on vh/soong-lab); (3) dispatch a build to verify it deploys + health-gates;
(4) ping soong-dev so they sync DEPLOY.md's "open follow-up" note to the as-built
mechanism. Auto-pull (watchtower) explicitly NOT chosen. See
[[2026-07-18-soong-lab-containerize-cutover]].

## AS-BUILT (2026-07-18, same-day execution)

**Mechanism landed** exactly as planned: `build-and-push.yml` gained a `Deploy to
corviduo-dev + health-gate` step (after build+push) that SSHes the host as `deploy`
and runs `docker compose pull && up -d` from `/opt/soong-lab`, then polls
`http://localhost:8443/api/version` for 120s and fails the job loud if unhealthy. No
compose is shipped from CI (the in-repo `docker-compose.yml` is a BUILD compose; the
host pull-compose is infra-ops-managed). Kept the `v*`-tag/`workflow_dispatch` trigger.
Skipped WT's disk-watermark gate + health-gated-`:latest`-advance (low cadence, easy
rollback).

**Deploy identity = reuse WT's `deploy` account** (operator accepted the rec):
- `deploy` (uid 1001, docker-group → no sudo) already owns `/opt/worldtree`; relocated
  soong-lab's deploy dir `/home/infra-ops/soong-lab-deploy` → **`/opt/soong-lab`**
  (deploy-owned), copied compose + `.env`. Named volumes (`soong-lab_soong-library`,
  `soong-lab_soong-portraits`) are project-scoped by compose `name: soong-lab` → followed
  the move untouched (dry-run `up -d` ADOPTED the running container, no recreate). Old dir
  **retired → `.retired-20260718`** (recoverable). Also lingering: `soong-lab-deploy.sh` /
  `.log` (dead pre-container webhook artifacts) — harmless, left in place.
- **Dedicated soong-only ed25519 deploy key** minted (NOT literally WT's key — cleaner
  independent revocation), pubkey appended to `deploy`'s `authorized_keys`
  (fp `SHA256:MG7M3RiZJ176sLfblffb96V6W1qkRTgJ5dow1CpiY68`). Existing `deploy` key is
  plain/unrestricted, so parity held.

**The secret gate (the friction point):** repo Actions secrets are **vh-owner-only** —
claude-bot's token is `write:package,read:repository` (403 on secret-write), and the vh
package-scoped PAT also 403'd on `PUT …/actions/secrets/…`. So `DEPLOY_SSH_KEY` /
`DEPLOY_HOST` (10.250.50.152) / `DEPLOY_USER` (deploy) HAD to be set by the operator.
First operator attempt produced a **bad key paste** — the deploy step died with
`Load key … error in libcrypto` + `Permission denied (publickey)` (build+push were green;
live Soong never moved). Fix: operator re-set the secret; the minted key path was
pre-validated from nh3-dev (`ssh -i … deploy@… 'cd /opt/soong-lab && docker compose config
-q'` → OK, health 200) so the re-set was the only variable.

**Validation:** `workflow_dispatch` via claude-bot **basic auth** (its token lacks
`write:repository` for the dispatch API; the account password works). Run #5 (task 1886)
GREEN — live container recreated `sha256:…541f7730` → `…07526a08`, `StartedAt` fresh,
health 200. `/api/version` now reports **0.3.25** (run #5 shipped soong-dev's 1c2f831
STYLE_WORKFLOWS re-pin as validation cargo). soong-dev synced `docs/DEPLOY.md`
(commit `00b67c3`). NB: tag **v0.3.25 exists only locally** — pushing it would re-trigger
a redundant build+deploy of the same commit (operator's discretion).

**Ops now:** redeploy = tag `v*` or `workflow_dispatch` the CI (auto). Manual fallback =
`sudo -u deploy bash -c 'cd /opt/soong-lab && docker compose pull && docker compose up -d'`
(the `.env` is `deploy`-owned 600, so infra-ops needs `sudo -u deploy`, not a bare `cd`).