## Why

Phases 1–4 built and verified both apps on .27 (dev). The product has a real domain (`where-woof.com`, currently parked at InMotion) and a Caddy reverse proxy on .35 ready to serve it. Phase 7 puts the GOAT frontend **live on .13** behind the saved Caddy block, so the site is reachable on the real domain (DNS/redirect to follow).

## What Changes

- **Binary deploy**: build the Go frontend on .27 (`GOOS=linux GOARCH=amd64`) and rsync `where-woof` binary + `templates/` + `static/` → `.13:/var/www/where-woof` (the established pattern used by `sam-developer` etc.).
- **Systemd user service** on .13: `where-woof.service` (like `lan-mouse.service`), runs the binary on `:3020`, `Restart=on-failure`, env from an `EnvironmentFile` (secrets live on .13, never in the repo).
- **Caddy** on .35: the block is already saved by the user (`where-woof.com` / `where-woof.home.lab` → `.13:3020`); this change verifies it once the service is up.
- **DNS / InMotion redirect**: user action — point `where-woof.com` DNS at .35 (or InMotion redirect), out of scope for code but documented.
- The DB is already on .13 (`wherewoof-db` :5434) — the service connects to `localhost:5434`.

## Capabilities

### New Capabilities

- `deploy-service`: the frontend runs on .13:3020 as a managed systemd user service with secrets via EnvironmentFile.
- `deploy-artifacts`: build + rsync step reproduces the deployable (binary + templates + static + uploads writable).

### Modified Capabilities

<!-- none — deployment only -->

## Impact

- **On .13**: `/var/www/where-woof/{where-woof,templates,static}`, `~/.config/systemd/user/where-woof.service` + `EnvironmentFile` (DATABASE_URL, SESSION_SECRET, SMS creds), uploads dir writable.
- **On .27**: `make build` target already exists; rsync command added to a deploy script or Makefile target.
- **No code changes** to the Go app (cwd-relative templates/static already handled by running from /var/www/where-woof).
- Admin deploy (Laravel on .13:3030) is Phase 8 — the Caddy admin block is forward-looking.