v1.1.0

v1.1.0 — Prebuilt-image install, passkeys, rolling sessions, and staged restore

This release changes how JARVIS is installed and hardens the account, session, and
backup paths. A default install now pulls prebuilt, multi-architecture container images
instead of building them locally, which removes the multi-gigabyte PyTorch/CUDA build
that could exhaust disk on a first install. It also adds passkey sign-in, rolling
sessions, and a browser-driven recovery flow for rebuilding a lost host. Public API
behavior and the local-first defaults are unchanged.

Added

• Passkey sign-in. Register and sign in with a platform or roaming authenticator and
  manage device credentials from the web UI. Passkeys are bound to the exact origin the
  instance is served from and require a secure context; a raw-IP LAN install keeps the
  magic-link flow, and magic-link recovery always remains available if a device is lost.
• Browser-based recovery. A fresh host can be rebuilt from off-site archives entirely
  from the web UI: upload the archive set and one-time key, trigger the restore from the
  Backups panel, and the stack reconciles its secrets, database role, and services with no
  terminal steps after ./setup.sh. A command-line runbook remains for headless hosts.
• Retention and reclaim reporting. Individual restore points can be deleted behind a
  typed confirmation, and a keep-last-N / maximum-age retention policy is configurable. An
  admin storage-usage card and per-model reclaimable-space estimates are shown in the UI.
• GPU detection. GPU vendor and VRAM are detected across NVIDIA, AMD, and Intel and
  surfaced in the setup wizard and status API. Experimental ROCm and Vulkan overlays are
  available for AMD and Intel hosts.
• Version reporting. The running application version is reported by the API and health
  endpoints, shown in the UI, and recorded in backup manifests, so a redeployed server is
  distinguishable from a stale browser tab.

Changed

• Install from prebuilt images. ./setup.sh pulls the application images from the
  project registry and starts the stack without building, selecting a CPU or CUDA image
  from the detected GPU. A disk preflight measured at the Docker data root fails a first
  install that would run out of space rather than exhausting it mid-build. Contributors,
  forks, and air-gapped hosts build from source with --build-local; a failed pull stops
  with a clear message instead of silently building.
• Staged, atomic restore. A restore loads into a separate staging database and swaps in
  atomically, so a failure before the swap leaves the live data untouched and served again
  automatically. The live database is no longer dropped first, scheduled backups stand down
  during a restore, the progress poll stays authorized while the database is swapped out,
  and older backups migrate forward on their own.
• Rolling sessions. A signed-in session lasts 30 days and rolls forward on use, at most
  once per day, across both the cookie and the database. Revoked and deleted sessions always
  hard-fail. Session minting is unified across all entry points.
• Model settings and status. The model settings page keeps only the per-role selectors;
  detected hardware, the serving backend, and the recommended model move to a runtime summary
  on the System Health page.
• Access-mode selection. The setup chooser presents localhost, LAN, Cloudflare Tunnel,
  and Let's Encrypt, states the capability consequences of each, and derives a canonical
  application URL.
• Release CI. CI publishes multi-architecture images on release tags, enforces a measured
  disk budget, runs a release-blocking cold-install check against the published images, and
  promotes the mocked end-to-end suite to a required check.

Fixed

• Provider endpoint validation. Custom OpenAI-compatible model endpoints are validated
  against private and reserved address ranges before use.
• Scan and provider responses. Consensus and contradiction scans explain empty results,
  cross-references again include shared-corpus papers, and an unknown model provider returns
  HTTP 400 rather than 500.
• Sign-in feedback. The sign-in page explains the magic-link cooldown and reports an
  unreachable email relay instead of failing silently.
• Error logging. Unhandled server errors are recorded in the event log and deduplicated.
• Dependency advisory. soupsieve was updated to address two advisories.

Removed

• Tunnel acknowledgement hand-edit. The JARVIS_TUNNEL_ACK_ZT_CONFIGURED environment
  variable is gone; Cloudflare Tunnel is acknowledged in the setup flow, or with
  --tunnel-ack. Pre-1.1 .env files that still carry it are ignored harmlessly.

Upgrading

Run ./update.sh — it pulls the new application images (use --build-local to rebuild from
source). An upgrading NVIDIA host is moved to the CUDA image automatically. To roll back to a
previously published release, pin JARVIS_VERSION to that tag and pull it.

Model and backend defaults

No model, backend, reranker, or embedding default changes in this release. Local-first
defaults remain unchanged.

Validation

Release validation included the full Python test suite, the database-backed contract suite
against a live PostgreSQL, frontend type checks and production build, shell coverage for the
installer, backup, restore, and prune paths, a strict documentation build, Docker Compose
configuration validation, and a release-blocking anonymous cold-install from the published
multi-architecture images.

Full details in CHANGELOG.md.