# Proposal: fpagent-install-upgrade

## Why

The installer always took the newest release and left any running `fpagent`
daemon on the old binary, so there was no way to hold a known-good version and
an "upgrade" did not take effect until a reboot. Operators need a controlled
version and a rerun that actually upgrades.

## What Changes

- The installer accepts `--tag TAG` to install a specific release instead of
  `latest`, and the app proxies that tag's metadata through a same-origin route.
- The installed version is the git hash carried in the bundle's asset name. The
  installer passes it to the bundle installer, which records it beside the
  binary and reports `upgrading <old> -> <new>` on the next run.
- When the installer manages the systemd service and the service was already
  running, an upgrade restarts it so the new binary takes effect. The version
  stamp is removed on uninstall.

## Capabilities

### New Capabilities

(none)

### Modified Capabilities

- `fpagent-installer`: adds release pinning, a pinned-tag metadata endpoint,
  installed-version tracking with upgrade reporting, and restart of a managed
  service on upgrade.

## Impact

- `tools/server.js`: `/fpagent/releases/tags/:tag` route (shares the release
  metadata handler with `/fpagent/releases/latest`).
- `tools/public/fpagent/install.sh`: `--tag`, version parse from the asset name,
  and handoff of the version to the bundle installer.
- `fingerprint-agent` `deploy/install.sh` and `deploy/bundle.sh`: read/stamp the
  version and restart an already-running service; `bundle.sh` ships `VERSION`.
- Depends on the `fingerprint-agent` bundle naming, which already embeds the
  git hash (`fpagent-<hash>-<platform>.tar.gz`).