# Machine: Pluto (Claude-Builder)

**Hostname:** Pluto / Claude-Builder
**Last Updated:** 2026-05-24

---

## Identity

Pluto is the **Windows build VM** for GuruRMM. It is the only machine in the fleet
that produces Windows agent binaries and the WiX MSI installer. It is NOT a
general-purpose workstation — it has no Claude Code, no vault, no coord API access.
Its sole function is to run `cargo build` for Windows targets when `build-windows.sh`
SSHes in.

It also runs a **GuruRMM agent** (enrolled as hostname **PLUTO**, client "AZ Computer Guru"),
so it can be driven via `/rmm` (run PowerShell) when a workstation's SSH key isn't authorized —
e.g. to inspect the box or add a pubkey. As of 2026-05-29 it also builds the **GuruConnect**
Windows agent and hosts a Gitea Actions runner for guru-connect's native MSVC builds. There is
no dedicated `pluto` vault entry — the box is the Unraid VM named "Claude-Builder".

---

## Hardware & Location

| Spec | Value |
|------|-------|
| VM name | Claude-Builder (virsh domain on Jupiter) |
| Host | Jupiter — Unraid primary, IP 172.16.3.20 |
| VM IP | 172.16.3.36 |
| OS | Windows Server 2019 (Standard) |
| SSH user | Administrator |
| SSH port | 22 |
| SSH auth | Public key, from build server (172.16.3.30) |

Pluto is a virsh VM. If it is unreachable from 172.16.3.30 but was recently
building, check Jupiter first (`virsh list --all` on 172.16.3.20) before
assuming a crash. SSH from DESKTOP-0O8A1RL and SSH from 172.16.3.30 traverse
different network paths — one failing does not imply the other fails.

---

## Build Tools

| Tool | Path |
|------|------|
| cargo (Rust stable) | `C:\Users\Administrator\.cargo\bin\cargo.exe` |
| rustup | `C:\Users\Administrator\.cargo\bin\rustup.exe` |
| WiX 4 (MSI builder) | `C:\Users\Administrator\.dotnet\tools\wix.exe` |
| sccache | `C:\sccache\` (compiler cache, causes near-instant rebuilds when source unchanged) |
| Git | standard PATH |

**sccache note:** When agent/ has no code changes (only config bumps), sccache
makes the full 5-target cargo run complete in ~1s rather than 3–5 min. This is
expected and correct — do not interpret a fast build as a failed build.

---

## Repo

| Item | Value |
|------|-------|
| Clone path | `C:\gururmm` |
| Remote | Gitea: `https://azcomputerguru@git.azcomputerguru.com/azcomputerguru/gururmm.git` |
| Branch | main (build-windows.sh pulls latest before building) |

---

## Build Role in Pipeline

Pluto is invoked by `build-windows.sh` on the build server (172.16.3.30) via SSH.
It is called only when `agent/` has changed since the last Windows build
(`/opt/gururmm/last-built-commit-windows`).

### What Pluto does (in order):

```
1. git pull (build-windows.sh does this via SSH before cargo invocations)
2. cargo build --release --target x86_64-pc-windows-msvc     → stable x64
3. cargo build --features debug-agent --target x86_64-pc-windows-msvc  → debug x64
4. cargo build --release --target i686-pc-windows-msvc        → stable x86
5. cargo build --release --target x86_64-pc-windows-msvc (legacy profile) → legacy x64
6. cargo build --release --target i686-pc-windows-msvc (legacy profile)  → legacy x86
7. wix build (WiX 4) → GuruRMM-<version>-x64.msi
```

All five cargo invocations run sequentially on Pluto. The MSI is built after all
binaries complete.

### Output artifacts (on Pluto):

| Artifact | Pluto path |
|----------|-----------|
| Agent EXE (x64) | `C:\gururmm\target\x86_64-pc-windows-msvc\release\gururmm-agent.exe` |
| Agent EXE (x86) | `C:\gururmm\target\i686-pc-windows-msvc\release\gururmm-agent.exe` |
| Tray EXE | `C:\gururmm\target\x86_64-pc-windows-msvc\release\gururmm-tray.exe` |
| MSI | `C:\gururmm\target\wix\GuruRMM-<version>-x64.msi` |

`build-windows.sh` SCPs these from Pluto to the build server's distribution
directory (`/var/www/gururmm/downloads/`) after the build completes.

---

## Connection from Build Server

```bash
# From 172.16.3.30 (build server), as guru
ssh -o StrictHostKeyChecking=yes \
    -o UserKnownHostsFile=/opt/gururmm/pluto_known_hosts \
    Administrator@172.16.3.36
```

The known-hosts file at `/opt/gururmm/pluto_known_hosts` contains three pinned
keys (RSA, ECDSA, ED25519) for 172.16.3.36. **Never use StrictHostKeyChecking=no
for Pluto** — it would accept a MITM and inject malicious binaries into the
build artifacts.

To update the pinned keys (e.g., after OS reinstall):
```bash
ssh-keyscan 172.16.3.36 > /opt/gururmm/pluto_known_hosts
```

---

## Pipeline Context

| Script | Role |
|--------|------|
| `/opt/gururmm/webhook-handler.py` | Receives Gitea webhook on 172.16.3.30:9000, forks build threads |
| `/opt/gururmm/build-shared.sh` | Version bump + repo sync; runs once per trigger |
| `/opt/gururmm/build-linux.sh` | Linux cargo build; independent of Pluto |
| `/opt/gururmm/build-windows.sh` | Invokes Pluto via SSH; handles change gate + artifact copy |
| `/opt/gururmm/build-mac.sh` | Stub; no Mac build machine configured |

`build-linux.sh` and `build-windows.sh` run in parallel threads from
`webhook-handler.py` after `build-shared.sh` succeeds.

### Build logs on 172.16.3.30:

| Log | Content |
|-----|---------|
| `/var/log/gururmm-build-linux.log` | Linux build output |
| `/var/log/gururmm-build-windows.log` | Windows build + Pluto SSH output (prefixed `[PLUTO]`) |
| `/var/log/gururmm-build-mac.log` | Mac stub (minimal) |

### Change tracking:

| File | Tracks |
|------|--------|
| `/opt/gururmm/last-built-commit-linux` | Last SHA successfully built on Linux |
| `/opt/gururmm/last-built-commit-windows` | Last SHA successfully built on Windows (Pluto) |
| `/opt/gururmm/last-built-commit-mac` | Last SHA successfully built on Mac (stub) |

---

## Distribution Directory (on 172.16.3.30)

Active artifacts served via nginx:

```
/var/www/gururmm/downloads/
  windows/
    amd64/
      GuruRMM-<version>-x64.msi
      gururmm-agent-<version>.exe
      gururmm-tray-<version>.exe   (latest 2 versions kept)
    x86/
      gururmm-agent-<version>.exe
```

The legacy path `/opt/gururmm/updates/windows/amd64/` contains only old artifacts
from before the pipeline split (last modified ~Feb 2026). It is NOT the active
distribution path — do not check it to assess build freshness.

---

## Build Trigger Rules

A build to Pluto is only initiated when:
1. A push to `main` hits the Gitea webhook
2. `build-shared.sh` succeeds (version bump + git sync)
3. The diff between the new SHA and `last-built-commit-windows` includes changes
   under `agent/` (excluding `agent/Cargo.lock`)

If only `server/`, `dashboard/`, or docs changed, Pluto is NOT contacted.
The Windows lock file (`/var/run/gururmm-build-windows.lock`) prevents concurrent
builds if a previous run is still active.

---

## Capabilities

- [x] Windows cargo builds (stable x64, debug x64, stable x86, legacy x64, legacy x86)
- [x] WiX 4 MSI packaging
- [x] sccache (compiler-level cache, C:\sccache)
- [x] SSH access from 172.16.3.30 (key auth, pinned known-hosts)
- [x] Git (pulls gururmm repo from Gitea)
- [ ] Claude Code (not installed)
- [ ] SOPS vault (not installed)
- [ ] Coord API access (not installed)
- [ ] Mac cross-compilation (not configured)

---

## Notes

- **Do not SSH to Pluto manually to trigger builds.** All builds go through the
  Gitea webhook pipeline. Manual SSH is for diagnostics only.
- **If Pluto appears unreachable from DESKTOP:** Verify from 172.16.3.30 first.
  Different network paths. DESKTOP is not on the same LAN segment as Pluto.
- **sccache makes short work of rebuild-only pushes.** A 1-second Windows build
  is normal when agent/ source hasn't changed since the last successful build.
- **Build history:** Pluto has been building GuruRMM Windows agents since at least
  early 2026. The MSI + EXE artifacts in `/var/www/gururmm/downloads/` are
  authoritative freshness indicators — check their timestamps, not the legacy
  `/opt/gururmm/updates/` path.
