where_woof/openspec/changes/deploy-frontend/proposal.md

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

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.