/test-release

name: test-release
description: |
  Verify a released archon binary works end-to-end via a specific install path.
  Use when: cutting a new release, reproducing a user bug report on the released
  version, or validating that a hotfix binary actually works after a re-tag.
  Triggers: "test the release", "test 0.3.1 via brew", "verify the curl install",
            "smoke test the binary", "did the release binary work",
            "run /test-release", "verify the release".
  NOT for: testing dev work (use bun link directly), testing unreleased changes
  (build locally via scripts/build-binaries.sh first), or running the full
  validate suite (bun run validate is separate).
argument-hint: "[brew|curl-mac|curl-vps] [optional: version to verify] [optional: vps-target]"

Test Release

Automated smoke test for a released archon binary. Covers three install paths:

• `brew` — Homebrew tap on macOS (tests the formula and checksums)
• `curl-mac` — `curl install.sh` on macOS (tests the install script, sandboxed to a temp dir)
• `curl-vps` — `curl install.sh` on a remote Linux VPS (tests the Linux binary and full install path)

Every path installs the binary, runs a fixed smoke test suite, and cleans up. The dev `bun link` binary is never touched and remains the default `archon` on PATH throughout.

**When NOT to use this skill:**

• There is no release yet — build a local binary via `bash scripts/build-binaries.sh` and run it from `dist/binaries/` directly
• You want to test the dev clone — use `bun run validate` or invoke source directly via `bun packages/cli/src/cli.ts`
• You want to test the full server + web UI deploy flow — use the cloud-init from `deploy/cloud-init.yml` on a real VPS

Local build for pre-release QA

To build a binary locally with the exact same flags and constants that CI uses, invoke `scripts/build-binaries.sh` directly. The script supports two modes:

# Multi-target mode (builds all 4 local platforms into dist/binaries/)
VERSION=0.3.1 GIT_COMMIT=abc12345 bash scripts/build-binaries.sh

# Single-target mode (matches one CI matrix job)
VERSION=0.3.1 \
GIT_COMMIT=abc12345 \
TARGET=bun-darwin-arm64 \
OUTFILE=dist/test-archon-darwin-arm64 \
bash scripts/build-binaries.sh

# Verify the binary — use the path from the mode you built:
#   multi-target → ./dist/binaries/archon-darwin-arm64
#   single-target → the OUTFILE you passed above
./dist/test-archon-darwin-arm64 version
# Expected: Archon CLI v0.3.1, Build: binary, Git commit: abc12345

Run this **before tagging a release** to catch build-time-constant issues locally. The script is the canonical entry point — both local dev and the release workflow call it the same way, so a green local build means the CI build will exercise the same code path.

Phase 1 — Determine scope

Parse the arguments. The skill takes up to three:

1. **Install path** (`brew` | `curl-mac` | `curl-vps`): which install flow to exercise 2. **Expected version** (optional): the version tag the release should report, e.g. `0.3.1`. If not provided, fetch it:

gh release list --repo coleam00/Archon --limit 1 --json tagName --jq '.[0].tagName'

3. **VPS target** (only for `curl-vps`): SSH target in the form `user@host` or `host` (uses default SSH config)

If any argument is missing, ask the user for clarification BEFORE doing anything. Never guess the install path or the expected version.

Confirm the plan with the user before proceeding to Phase 2. Output should look like:

About to test:
  Path:     brew (Homebrew tap on macOS)
  Version:  0.3.1 (expected)
  Cleanup:  will uninstall after tests (brew uninstall + untap)
            If `archon-stable` symlink is detected in Phase 2, it will be
            restored at the end of Phase 5 by reinstalling the tap formula.

Proceed? (y/N)

Do not continue without explicit confirmation. Release testing touches install state and the user should be aware.

Phase 2 — Pre-flight

Before touching anything:

1. Capture the current dev binary state for reference:

which -a archon
archon version 2>&1 | head -5

Record the path and version of the dev binary so the final report can show "dev binary was untouched".

2. Verify prerequisites for the chosen path:

• **brew**: `brew --version` must succeed. If not, abort with "Homebrew not installed — see https://brew.sh/"
• **curl-mac**: `curl --version` must succeed (effectively always true on macOS)
• **curl-vps**: `ssh <target> 'uname -a'` must succeed. If not, abort with "Cannot SSH to <target>". Also verify `ssh <target> 'command -v curl'` returns a path.

3. Confirm the release exists on GitHub:

gh release view v<version> --repo coleam00/Archon --json tagName,assets --jq '{tag: .tagName, assetCount: (.assets | length)}'

If the release does not exist or has no assets, abort with a clear message. Do not proceed to install a non-existent release.

4. **Detect persistent `archon-stable` install (brew path only).** If the user has renamed a prior brew install to `archon-stable` (the dual-homebrew pattern — see `~/.config/fish/functions/brew-upgrade-archon.fish`), Phase 5's `brew uninstall` will wipe it. Capture the state so Phase 5b can restore it:

ARCHON_STABLE_WAS_INSTALLED=""
if [ -L /opt/homebrew/bin/archon-stable ] || [ -L /usr/local/bin/archon-stable ]; then
  ARCHON_STABLE_WAS_INSTALLED="yes"
  echo "Detected persistent archon-stable — will restore after Phase 5 uninstall."
fi

Export `ARCHON_STABLE_WAS_INSTALLED` into the environment used by Phase 5b. Only applies to the `brew` path — `curl-mac` and `curl-vps` don't go through brew and don't disturb `archon-stable`.

Phase 3 — Install

Path: brew

brew tap coleam00/archon
brew install coleam00/archon/archon
BINARY="$(brew --prefix coleam00/archon/archon)/bin/archon"

Capture `$BINARY` for Phase 4. Verify the file exists and is executable.

Path: curl-mac

Install to a dedicated tmp directory so the dev