v1.2.5

v1.2.5 — one research loop across clients, documents on processor-only machines, and a bot that can reach its deployment

A patch release that makes the research loop behave the same way in the Web interface, in Telegram, on a fresh installation and after an upgrade, and that moves several unchecked or duplicated control paths onto smaller, independently tested owners. It also repairs two failures that appeared only at runtime on published images: document processing on machines without a graphics accelerator, and the Telegram bot's ability to reach the rest of the deployment.
This release includes two automatic migrations (0112, 0113); they apply on startup and need no operator action.
This release changes application code, so the :1.2.5 images differ from :1.2.4.

Added

• One focus session across Web and Telegram. A focus session started in either client drives the same durable timer. It survives client restarts, records completed time once, and pauses scheduled Telegram digests, reminders, alerts and warnings until focus ends.
• Cross-client job visibility. Work started from Telegram or another browser appears in the Web job indicator and refreshes the affected view when it finishes, including short Pulse jobs that complete between polls.
• A sync schedule anyone can set. The Zotero library sync schedule is chosen from named options — hourly, every few hours, daily at a time, weekly on a day — instead of typed as a five-field expression. The expression field stays under Advanced for schedules the options cannot express, and a schedule more frequent than every fifteen minutes is refused.
• Stored provider credentials can be removed. A saved key or endpoint can be cleared from the interface rather than only overwritten. Removal is refused while a model route still depends on that provider, and it is recorded in the audit log distinctly from a replacement.
• A checked Telegram command reference. Bot registration, Telegram's command menu, /help and the manual all derive from one command catalog, and the pairing artifact is called a code everywhere it appears.
• A local security scan. make security-scan reproduces the local dependency and secret-scanning subset of the hosted Security workflow. Downloaded scanner artifacts stay outside the repository and are hash-verified on every use.

Fixed

• Documents can be processed on processor-only installations. The published images for machines without a graphics accelerator paired the document reader with a build of its companion library that could not load beside it, so the first document a researcher opened failed while every service still reported healthy. Both now come from the same source, and no image may be released until it has loaded that stack, converted a real document and refused a corrupt one, inside the exact image being published and with no network access at all.
• The Telegram bot can reach the rest of the deployment. The outbound address policy introduced in this release did not list the deployment's own service names, so every command and every scheduled message failed before a connection was opened. Those names are now permitted, a name that merely resembles one is still refused, and a first-run check makes one real call between containers so this cannot pass unnoticed again.
• Document models ship inside the image. The reader previously downloaded several hundred megabytes the first time a researcher opened a document, which stalled that first document and could not complete at all without internet access. The models are now built in.
• A setting that fails to save says so. Eighteen controls across the author, topic, extraction-template, automation, source, model and Telegram panels changed the screen and then stayed silent when the server rejected the change, leaving the old value on display as though it had been stored. Every panel now reports a rejected save the same way.
• Ask behaves predictably with reasoning-capable models. Thinking is off unless explicitly enabled, one answer budget governs both prompt fitting and the model request, and known response-hygiene failures produce actionable retry and administrator guidance instead of a generic error.
• Zotero exports stay with their research projects. Sending a paper creates or reuses a collection for each linked project, including when an existing item is matched by DOI, and the interface follows the queued export through to completion. A failed collection or DOI lookup can no longer be reported as an unfiled or duplicate success. Switching between personal and group libraries clears only the previous library's remote identifiers; local papers and analysis history remain intact.
• Outbound connections stay bound to the address that policy checked. PDF downloads, custom model providers, Better BibTeX, SMTP and LiteLLM custom-provider traffic connect to the address that was validated, so a name cannot resolve to one address for the check and another for the request. Certificate and hostname verification are unchanged.
• Telegram Pulse reports what it is showing. Telegram labels current, older, reduced-signal, empty and unverified results, and shows the first five cards from the same ranked deck as the Web interface. Backend ranking is unchanged.
• Saving metadata-only papers no longer creates failed analysis jobs. Web, batch and Pulse saves schedule analysis only when the paper has a remote or local PDF; a paper with only bibliographic metadata still enters the library.
• The in-app PDF reader works under the production security policy, and Ask routing metadata is decoded without producing misleading malformed-stream warnings.
• Upgrade diagnosis is read-only. Lifecycle commands distinguish a stale access-service target from custom or shared state and print a targeted, operator-confirmed repair command instead of changing that state themselves.
• Historical migrations run in ordinary pull-request checks from one shared fixture that proves the complete path, and smaller corrections landed for blank SMTP identities, benchmark scoring of ordinary prose, warnings about unset optional certificate settings, and fallback model-route parsing.

Changed

• Successful Web API responses are decoded at runtime. Named schemas guard every JSON domain before any state change, including job events and results; the generic unchecked response cast has been removed.
• Large PDF and backup workflows have smaller state owners. PDF preparation, persistence and cleanup keep their lock and transaction order, while restore recovery and retention editing move to independently tested controllers.
• Installation has one implementation. New installs use setup.sh; the former development command is a strict deprecated forwarder. Rollback now requires a complete setup-owned credential snapshot before it changes access services.
• First-use navigation teaches the real loop. Discover is present in the simple navigation, and milestone-based guidance covers Discover, Save, Analyze and Ask on wide and narrow layouts. A researcher's tour dismissal is respected across browsers.
• The model catalogue stays responsive as it grows. The picker renders a fixed number of matches and states how many of how many are shown, so typing costs the same on a catalogue of four hundred models as on one of a dozen.
• Settings behaves the same way throughout. Sliders commit once when released rather than on every step, every control carries a name a screen reader announces, clearing a topic's feedback asks first like the other irreversible actions, and the status page states what it actually checked.
• A severe, fixable vulnerability blocks a release. The published-image scan fails the verification run when it finds a critical problem a rebuild would fix, so such an image cannot reach a stable tag. Findings with no available fix stay out of the gate and remain in the report.
• Expired compatibility branches and inert configuration were removed. The browser keeps API-key exchange but no longer stores or sends raw keys, and the unused fixed Telegram chat setting and global Zotero schedule are gone.
• Dependency floors and locks include current security fixes for GitPython and the frontend's transitive identifier generator; local and hosted scans reject a return to their affected versions.
• Every service image is rebuilt on a patched distribution base. The Python service images and the dashboard image move to current Debian 12 and Alpine bases, clearing critical OpenSSL and GnuTLS advisories. The published-image scan described above is what keeps them current: it refuses to release an image carrying a critical problem a rebuild would fix.

Upgrading

An installation already on v1.2.4 upgrades in place:

jarvis-research update

An installation on v1.2.0, v1.2.1, v1.2.2, or v1.2.3 runs the one-time bootstrap from the installation directory:

(
  set -e
  bootstrap="$(mktemp)"
  trap 'rm -f "$bootstrap"' EXIT
  curl -fsSL -o "$bootstrap" \
    https://raw.githubusercontent.com/limitcycle-oss/jarvis-rd-assistant/v1.2.5/scripts/update-bootstrap.sh
  bash "$bootstrap" --repo "$PWD" --to v1.2.5
)

With this release v1.1.3 leaves the supported upgrade window. An installation on v1.1.3 or older completes the one-time step in the command-line reference and then follows the bootstrap path above; below that floor, a fresh install plus a backup restore is the supported route.

Either path validates the selected release, creates and authenticates a restore point, stages the new images, advances the checkout fast-forward only, and commits after services report healthy. Because this release migrates data, rolling back to an earlier version afterwards requires a matching database restore.

Full changelog: CHANGELOG.md

v1.2.4

v1.2.4 — a bot that starts, an upgrade that finishes, and the checks that prove both

A patch release that repairs two paths broken for people running the software rather than reading about it: the Telegram bot container could not start, and upgrades from older installations could not finish. Both had been shipping for several releases with no check that would have noticed, so each fix arrives with the check that was missing.
This release carries no database migrations and needs no operator action beyond the upgrade itself.
This release changes application code, so the :1.2.4 images differ from :1.2.3.

Fixed

• The Telegram bot container starts again. Deployments using the telegram profile have been unable to start it since v1.2.0: the published image was missing a dependency the bot imports at startup, so the container exited immediately and restarted forever. This affected v1.2.0, v1.2.1, v1.2.2 and v1.2.3, every release in that range. The dependency is now declared where it is used, and every published image that carries a Python interpreter imports its entry point with that interpreter before its digest may join a release manifest, so an image whose entry point cannot be imported is never released.
• Updates create the secret files they manage before touching anything. Since v1.1.3 the deployment has referenced an SMTP password secret file that no updater before this release created, so on installations first set up before v1.1.3 the update stopped part way through replacing containers. The update now creates the secret files it manages — the SMTP password file among them — before it pulls, builds or replaces anything, and an update that cannot create them stops with everything still running and names the command to run.
• Lists say when a query failed instead of showing the same empty state they show when there is genuinely nothing to display, and the automation settings controls stay inert until real values arrive rather than offering fabricated defaults that a stray blur could persist over real server state.
• A single paper reports where it came from, matching the origin already shown in list views.
• A missing-table error names the schema baseline to apply, so the message points at the fix rather than only reporting the failure.
• Dependency floors were raised to their patched releases for the HTTP/2 library, the frontend's YAML parser, and the web framework, so no declared version range admits a release carrying a known advisory.

Changed

• Documentation that contradicted the code was corrected, covering configuration precedence, ownership rules, route behaviour, and the conditions under which strict mode and extraction failures raise.
• The installer, upgrade, backup and restore scripts are now covered by shell linting, alongside the entry points that were already checked.
• Model-catalog freshness is checked in the repository, not at runtime. The bundled model catalog was re-verified against its providers for this release, a scheduled repository check now fails when any entry goes unreviewed too long, and the application no longer logs catalog-age warnings at startup. The top-tier local entry advances to the current generation, qwen3.6:35b-a3b, whose 24 GB footprint leaves room for long-context work on 48 GB hardware.
• The release guide states what each image check proves and how far upgrades reach back, naming the in-image import check, the window of supported upgrade sources, and the documented path for installations older than every supported source.

Upgrading

An installation already on v1.2.3 upgrades in place:

jarvis-research update

An installation on v1.1.3, v1.2.0, v1.2.1, or v1.2.2 runs the one-time bootstrap from the installation directory:

(
  set -e
  bootstrap="$(mktemp)"
  trap 'rm -f "$bootstrap"' EXIT
  curl -fsSL -o "$bootstrap" \
    https://raw.githubusercontent.com/limitcycle-oss/jarvis-rd-assistant/v1.2.4/scripts/update-bootstrap.sh
  bash "$bootstrap" --repo "$PWD" --to v1.2.4
)

An installation first set up before v1.1.3 needs one extra one-time step before either path, because the SMTP password secret file it never created must exist before Compose can start; the command-line reference gives the exact commands.

Either path validates the selected release, creates and authenticates a restore point, stages the new images, advances the checkout fast-forward only, and commits after services report healthy.

Full changelog: CHANGELOG.md

v1.2.3

v1.2.3 — Runnable recovery procedures, a hardened outbound boundary, and a quick start

A patch release that closes the gap between what the product says and what it does: every documented recovery procedure is now a command that runs as written, provider model lists and background jobs report what actually happened, and the outbound address policy applies on every path. It also adds a one-screen quick start alongside the full deployment guide.
This release includes one automatic migration (0111); it applies on startup and needs no operator action.
This release changes application code, so the :1.2.3 images differ from :1.2.2.

Added

• Documented recovery procedures are commands you can run. Restoring an older unsigned backup on the same host, checking a restore's progress, and preparing an off-site restore request no longer require assembling container commands by hand, and accepting a backup whose database version cannot be checked is a flag on the same-host command (restore legacy … --allow-unknown-schema). Accepting an unverified backup still requires typing the acceptance phrase at a prompt, and an off-site set is refused outright. Checking progress and preparing a request work while the stack is stopped; restoring replays into a running database and says so instead of failing part way through.
• The models each provider actually offers. Provider configuration lists the models the provider reports, with an indication of how fresh that list is, rather than only a fixed built-in set. Vendor-namespaced identifiers from routers and self-hosted endpoints are accepted, and a provider that fails to answer is retried at a paced interval rather than on every request.
• A one-screen quick-start guide — clone, run setup, and analyze a first paper — alongside the full deployment guide for anything non-standard.
• The citation graph opens what it shows. Selecting a paper opens it; selecting a reference the library does not hold shows what is known about it.
• A durable second copy of the signed-restore requirement, so an update cannot silently return an installation to accepting unauthenticated backups.

Fixed

• Backup and restore integrity. A backup is refused when its encryption key is absent, when its manifest cannot gate a restore, and when a database dump is incomplete. Retention can no longer delete every restore point, a sweep reports what it really did, restoring a backup whose database version cannot be checked requires an explicit acknowledgement, and vector and off-site capture are reported honestly without blocking recovery.
• Background job outcomes. Jobs abandoned by an interrupted worker are marked failed with an instruction to start them again rather than sitting as running forever, and a failure to record that outcome is reported distinctly instead of being discarded. Advisory waits and batch sizes are bounded, duplicate scheduling is prevented, and periodic work stays on schedule across restarts.
• Account deletion and impersonation scope. Deleting an account revokes that user's sessions without disturbing anyone else's, a departed user's stored vectors and rows are verified to agree after a purge, and service impersonation is scoped to the address that may use it.
• Uninstall and setup. Uninstall shows every removal it will perform, including a directory outside the installation folder, keeps the backup offer when removing everything, and reports whether the final removal succeeded. Setup verifies the installed command can be found, and an interrupted install's staging folder — which can hold credential copies — is moved aside rather than deleted, and only when its owner is provably gone.
• A failed update always explains how to roll back, even when it cannot record its own progress.
• Local uploads are identified by their full content, so distinct documents are no longer treated as the same paper; migration 0111 derives the new identifier where the short form is unambiguous.
• Automation settings report partial saves honestly, and a skipped download is no longer shown as a failed step.

Changed

• The outbound address policy applies on every path. The Better BibTeX (Zotero) connection now refuses carrier-grade-NAT, reserved, multicast and unspecified destinations like every other outbound path, and re-checks the host on each request rather than trusting one indefinitely. A provider whose host resolves to a private address can be allowed deliberately, through a setting listing the hostnames permitted, rather than by disabling the protection.
• Git is no longer part of the supported operations path. The manual describes product commands throughout, repair-only fallbacks are labelled as such, and misuse of a command now names the correct invocation.
• Dependencies updated within their supported ranges, including the machine learning stack, and the hosted checks now run on a supported Node release. Dependency floors were raised to their patched releases, two expired exceptions in the Python dependency scan were removed so that scan runs with no exceptions at all, and the frontend scan carries one routing-library advisory with a dated removal trigger that does not affect a running instance.
• The upload area states the size limit it enforces. Single-file uploads accept up to 50 MB; whole-folder imports are unchanged.
• Documentation corrected where it described behavior inaccurately: cloud provider support, the knowledge graph controls, and how the scheduler treats a catch-up run that coincides with an interval run. The first-run tour no longer offers the topic step to signed-in users who cannot act on it.

Upgrading

An installation already on v1.2.2 upgrades in place:

jarvis-research update

An installation on v1.1.3, v1.2.0, or v1.2.1 runs the one-time bootstrap from the installation directory:

(
  set -e
  bootstrap="$(mktemp)"
  trap 'rm -f "$bootstrap"' EXIT
  curl -fsSL -o "$bootstrap" \
    https://raw.githubusercontent.com/limitcycle-oss/jarvis-rd-assistant/v1.2.3/scripts/update-bootstrap.sh
  bash "$bootstrap" --repo "$PWD" --to v1.2.3
)

Either path validates the selected release, creates and authenticates a restore point, stages the new images, advances the checkout fast-forward only, and commits after services report healthy. Because this release migrates data, rolling back to an earlier version afterwards requires a matching database restore.

Full changelog: CHANGELOG.md

v1.2.2

v1.2.2 — Derived-data integrity, honest job outcomes, and a hardened update path

A patch release that makes content derived from a replaced source document follow that replacement everywhere, keeps each account's analysis results private, makes long-running jobs report what actually happened, and rebuilds the update path so installations on every supported release upgrade safely.
This release includes four automatic migrations (0107 through 0110); they apply on startup and need no operator action.
This release changes application code, so the :1.2.2 images differ from :1.2.1.

Fixed

• Content derived from a replaced source document. Promoting a paper to shared visibility discards the processed content of the source it replaces and reclaims its stored files and vectors. Excerpts, PDFs and page images are served only while a current stored record backs them, and summaries, extractions and other machine-generated evidence from an earlier source no longer appear as current. User notes, spatial highlights and flashcards are retained but visibly marked stale, and are excluded from study, Anki export and Zotero export until regenerated.
• Contradiction and consensus privacy. Holding the same papers as another user no longer reveals that user's contradiction results or their consensus assessment. Each account's scan records and returns its own rows; migration 0110 preserves all existing records.
• Requester-scoped processing. Flashcard generation reads only the requesting user's own summary, rebuilding a shared paper's derived content requires holding that paper, and background-generated related papers draw only from shared papers — a private paper may therefore show fewer automatic suggestions.
• Zotero sync. Attachments, notes and annotations no longer create placeholder papers, an import without a PDF no longer queues analysis that cannot run, and each sync reports parse failures, temporary failures, exhausted retries and deferred work. An incomplete poll reports a partial outcome rather than unqualified success.
• Honest batch outcomes. A cancelled batch reports its cancellation with completed, skipped, failed and remaining counts, a batch with skipped or failed work reports a partial outcome, and a failure part-way through saving search results identifies what was saved. A consensus view built from a truncated evidence set says so, and claim topics written in any script cluster by their actual text.
• Answers across your library. Papers whose stored content is no longer available are set aside before an answer chooses its sources, so they no longer take a place from a relevant paper. Similar-paper suggestions, discovery results and citation graphs apply their visibility and stored-content checks before result limits.
• Pulse relevance. A thumbs-down now hides that paper from future decks for 60 days at the deck sizes people actually use. Decks may therefore look different for anyone with recent thumbs-down history.
• Scheduled discovery. Each topic is searched with its configured query terms rather than its name alone.
• Startup and input validation. Database credentials containing special characters connect correctly, database hosts and ports are validated before a connection is attempted, request fields are bounded to the width of the column that stores them, and an instance starting while another holds the migration lock verifies the resulting schema before serving.
• The update path. Installations on v1.1.3, v1.2.0 or v1.2.1 load the v1.2.2 lifecycle command with a one-time bootstrap, so the target command recognizes the current backup and recovery state before the checkout advances. Before a data-changing migration the updater creates and authenticates a complete restore point covering both databases, uploaded PDFs and data-coupled secrets, and an interrupted update leaves a durable transaction record it resumes from when re-run. Setup and updates wait through a service's recoverable starting states for the stated timeout, and an update records its new application version only after every required service reaches an acceptable state.

Changed

• Corrected operator and user documentation to match current behavior: the headless restore request in the recovery runbook now carries the identity fields the restore entrypoint requires, and install guidance derives its default models and 27-54 GB disk range from the same selectors and calculator used by setup.

Upgrading

Every installation upgrading to this release runs the one-time bootstrap from the installation directory:

(
  set -e
  bootstrap="$(mktemp)"
  trap 'rm -f "$bootstrap"' EXIT
  curl -fsSL -o "$bootstrap" \
    https://raw.githubusercontent.com/limitcycle-oss/jarvis-rd-assistant/v1.2.2/scripts/update-bootstrap.sh
  bash "$bootstrap" --repo "$PWD" --to v1.2.2
)

The bootstrap validates the selected release, creates and authenticates a restore point, stages the new images, advances the checkout fast-forward only, and commits after services report healthy. Because this release migrates data, rolling back to an earlier version afterwards requires a matching database restore.

Full changelog: CHANGELOG.md

v1.2.1

v1.2.1 — Tenancy, background-job, and lifecycle hardening

A patch release that closes cross-tenant access gaps around the shared paper corpus, makes background jobs report their outcomes honestly, and tightens the installer and lifecycle scripts.
There is no database migration; existing deployments upgrade with jarvis-research update.
This release changes application code, so the :1.2.1 images differ from :1.2.0.

Fixed

• Access-control hardening. Saving a paper by identifier, and de-duplicating a synced Zotero item by DOI, no longer attach another user's private paper, and citation and metadata refreshes no longer promote or overwrite an existing paper.
  A batch save can no longer claim an identifier in a namespace reserved for local uploads or Zotero sync, so it cannot pre-seed a row that a later genuine import would attach.
  Single-paper question-answering, summary generation, tracked-author updates, and the knowledge-graph views now consistently scope to the requesting user.
• Scheduled discovery on a fresh install. Automatic paper discovery again runs on an install that has no configured topics.
• Background job reliability. Batch jobs report a sanitized error code instead of a raw exception message, Zotero sync advances past a permanently malformed item instead of stalling, a fractional auto-fetch interval is honored, and a users-table read failure is reported distinctly from a genuinely empty active-user set.
  A Zotero sync whose cursor fails to persist now reports that instead of implying a durable advance.
• Installer and lifecycle scripts. Secret and registry writes are atomic across filesystems, the off-host upload grant is written with race-safe permissions, and the wrapper install derives its per-service network addresses.

Changed

• Consolidated shared configuration loading, secret-file resolution, safe-path handling, and background-task registration across services, with no change in behavior.
• Updated bundled frontend and documentation dependencies to their latest available minor and patch releases.

Upgrading

Run jarvis-research update (or ./update.sh); it stages the new applicatio images (use --build-local to rebuild from source),
takes a fresh checksum-verified backup, advances the checkout fast-forward only, and commits
after services report healthy. There is no schema migration in this release.
To roll back to a previously published release, pin JARVIS_VERSION to that tag and pull it.

Full changelog: CHANGELOG.md

v1.2.0

v1.2.0 — Source-aware visibility, whole-library processing, and safer lifecycle operations

A minor release that makes the shared research corpus private by default, adds whole-library
processing and scheduled discovery, and hardens the backup, restore, update, and uninstall
lifecycle. A paper is public only when a trusted server adapter promoted it, and every read path —
feed, knowledge graph, citation, summary, vector search, and Ask — resolves access through one
persisted rule. This release changes application code, so the :1.2.0 images differ from :1.1.3.

Migrations 0104, 0105, and 0106 apply automatically and idempotently at startup and move the
corpus to the source-aware visibility model; verified scholarly rows are backfilled as public and
all other existing rows become private-unless-shelved. Migrations are forward-only — take a restore
point before upgrading.

Added

• Whole-library processing. An admin can queue eligible papers for download,
  analysis, and summary generation in one job, with per-paper progress and a
  partial result when some papers fail or are skipped.
• Paper knowledge export. A paper can be exported as Markdown with its
  summary, notes, cards, structured extractions, and BibTeX citation.
• Scheduled discovery. Each enabled source checks a rolling seven-day
  window for every configured topic, and administrators can opt in to automatic
  summaries for discovered papers.
• Ranking-model status. Pulse reports whether its learned ranking model is
  active instead of leaving the operator to infer it from results.
• Explicit instance ownership. Upgrades with one live administrator assign
  that account automatically; ambiguous multi-admin upgrades provide a host
  repair command, and database-managed owners can transfer safely in Admin.

Changed

• Safer lifecycle operations. Backup manifests bind every archive in a
  restore point; update transactions resume after interruption; uninstall is
  scoped to the registered Compose project; and recovery points are verified
  before a data-changing update proceeds.
• Clearer family access. Remote setup and sign-in require a verified named
  HTTPS address. Plain LAN HTTP exposes only /health/jarvis. Guided Tailscale
  setup can install the client with explicit consent on supported Linux hosts;
  private HTTPS, Cloudflare Tunnel, and Let's Encrypt paths report only what
  their checks prove. Cloudflare also has a non-interactive token-file path, so
  its credential never needs to appear in shell arguments. Multi-user installs
  can use privately shared one-time links when SMTP is not configured. A failed
  access-route change now restores and verifies the previous live dashboard and
  JARVIS-owned edge, not only its configuration file.
• Hardware-aware defaults. NVIDIA acceleration is selected when its runtime
  is ready, AMD uses ROCm only when the required device is available, and other
  AMD or Intel hosts stay on the supported CPU path unless Vulkan is selected
  explicitly.
• Complete disaster-recovery sets. Current restore points include the PDF
  object store and exactly the three keys coupled to restored data. Restores
  revoke transient sign-in state, preserve durable identities, rotate vector
  visibility state, and quarantine off-host integration credentials until an
  authenticated operator reviews them.
• Source-aware paper visibility. Only papers promoted by trusted server
  adapters are public. Local uploads, client-supplied batches, personal or group
  Zotero imports, unknown provenance, and ambiguous legacy Zotero rows remain
  private unless explicitly added to a user's library. Feed, graph, citation,
  summary, vector-search, and Ask paths use the same persisted rule.
• Audited frontend toolchain. Transitive YAML and glob parsers are locked to
  patched releases, and the existing Security workflow rejects future
  high-severity npm audit findings.

Fixed

• Shared papers survive user deletion. Removing a paper from one person's
  library no longer removes canonical data or another person's work.
• Embedding repair covers stale and missing vectors. Existing chunks are
  reconciled without downloading and parsing the PDF again.
• Partial jobs no longer read as complete. The Jobs panel labels partial
  outcomes separately and keeps their completed and failed counts visible.
• Cross-reference visibility matches Ask. Summaries and cross-paper
  retrieval now use the same persisted public-or-caller-library rule.

Upgrading

Run jarvis-research update (or ./update.sh); it stages the new application images (use
--build-local to rebuild from source), takes a fresh checksum-verified backup before the schema
migrations, advances the checkout fast-forward only, and commits after services report healthy. The
visibility migrations (0104–0106) are forward-only, so keep that restore point. To roll back to a
previously published release, pin JARVIS_VERSION to that tag and pull it.

Full changelog: CHANGELOG.md

v1.1.3

v1.1.3 — Safer installs, accurate access modes, and an operations CLI

A patch release that hardens the install, deployment, and update lifecycle. Re-running setup no
longer loses configuration or data, access-mode behaviour and documentation match the deployed
configuration, and a new jarvis-research CLI manages updates and uninstalls transactionally.
This release changes application code, so the :1.1.3 images differ from :1.1.2.

Security

• Credential exchange is refused over plaintext off loopback. The API-key exchange and
  magic-link verification endpoints reject requests from non-loopback hosts over plain HTTP, so a
  bearer exchange cannot cross the network unencrypted.
• First-admin bootstrap is locked in production. The initial-admin setup path is gated in
  production, and the setup token is surfaced everywhere it is needed.
• Passkeys are not offered for IP-address origins. A raw-IP origin is not a valid WebAuthn
  relying party, so passkey enrolment is hidden there instead of failing mid-flow.
• The setup token stays out of server logs. The setup wizard reads its token from the URL
  fragment, and the setup link is always printed with a loopback host, so the token is never sent
  over the network.
• SMTP credentials are passed to the application as a Docker secret rather than an environment
  variable.

Added

• jarvis-research operations CLI. update, status, start, stop, restart, logs, doctor, repair,
  register, and uninstall, resolved from a registration file. Updates verify that the target
  release's images are published, classify new migrations read from the target tag, require a fresh
  checksum-verified backup before destructive migrations, stage all images before advancing the
  checkout (fast-forward only), and commit only after services report healthy. Rollback guidance
  distinguishes image rollback from schema rollback.
• Tiered uninstall. Four scoped tiers (stop, images, data, purge) with a complete dry-run
  enumeration, typed confirmations that flags cannot bypass, an offer to export the backup
  encryption key before a purge, and a refusal with a resource inventory when the Docker daemon is
  unavailable.
• --public-origin flag. Configures and probes a named private HTTPS origin end to end,
  reporting the edge as pending until the probe succeeds.

Fixed

• Re-running setup preserves configuration and data. The existing .env is kept byte-for-byte,
  including operator-added keys; template keys new to a release are appended; and only settings
  supplied to the current invocation are changed. A rolling snapshot is taken before any rebuild,
  with a restore command printed if setup fails before the stack starts. The certificate-repair path
  that removed the dashboard container together with its volumes has been deleted.
• GPU detection is more accurate on virtualized and non-Intel hosts, and Vulkan is opt-in. Render
  nodes are matched by PCI vendor ID, GPU overlays pass numeric group IDs that resolve inside the
  container, and Intel and AMD-without-KFD hosts default to CPU with a hint. A failed GPU start
  offers a CPU retry. This resolves an arm64 VM install that could not start Ollama.
• LAN access is reported as plain HTTP. The displayed URL, reachability probe, and CORS origins
  reflect HTTP, and the LAN address joins the accepted-host list.
• The local HTTPS profile no longer collides with the dashboard port — it runs on 3443 — and
  Let's Encrypt installs report success only after the certificate answers a bounded health poll.
• Email delivery reports its real result. Admin responses include a manual sign-in link when
  delivery did not occur, and account email verification is only marked sent on actual delivery.
• Preflight and readiness are more thorough and correctly ordered. Preflight now covers python3,
  the minimum Compose version the overlays require, the host ports the deployment will bind, WSL
  environments, and the NVIDIA container toolkit. The readiness script distinguishes warnings from
  failures in its exit code — warnings no longer abort production installs — and the completion
  banner prints only after the checks pass.
• The host-port pre-check honors exported overrides, matching how Compose itself resolves publish
  addresses.
• update.sh stages every image before recreating any service, reports services without
  healthchecks explicitly, gains a --yes flag for unattended runs, and installs the CLI after a
  successful update so existing installs pick it up.
• Pulse stage-1 scoring tolerates structured author IDs and applies topic dampening.
• Citations to nonexistent sources are marked unverified rather than treated as resolved.
• Flashcard generation receives the paper text verbatim.

Documentation

• The access-modes and deployment guides describe the shipped configuration: encryption and
  certificate claims that did not apply to plain-HTTP routes are removed, each supported ingress
  adapter has a documented trust contract, and a new test asserts the documented route table matches
  the installer's route registry.

Model and backend defaults

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

Upgrading

Run ./update.sh; it pulls the new application images (use --build-local to rebuild from source)
and installs the jarvis-research CLI. To roll back to a previously published release, pin
JARVIS_VERSION to that tag and pull it.

v1.1.2

v1.1.2 — Security hardening, safer restores, and truthful status reporting

A patch release closing a set of security, data-safety, and reliability issues found in a post-v1.1.1
audit. Unlike v1.1.1, this release changes application code, so the :1.1.2 images differ from
:1.1.1.

Security

• Owner-override is bound to a trusted proxy. Internal owner-override now requires a trusted numeric
  proxy, and the browser-facing proxy strips any client-supplied owner header, so a relayed browser
  request can no longer act as a different user.
• Telegram pairing is private-chat only. Pairing and authenticated bot actions are restricted to
  private chats, and stale group or supergroup pairings created before this change are purged — closing a
  path that could deliver a user's private content to a group chat.
• Logout is final. Signing out can no longer leave the session cookie re-issuable, and the session
  cookie now carries a correct absolute expiry.
• Passkey sign-in works again in same-origin and default localhost installs.

Added

• In-browser recovery upload. The staged restore flow gains an in-browser uploader that works across
  every access mode (localhost, LAN, tunnel, and domain).

Fixed

• Restore is safe by default. No destructive database swap proceeds unless the secrets archive and a
  fresh safety backup are both verified first, and every post-restore failure clearly flags that manual
  steps are required.
• Account email changes no longer deadlock the connection pool under load.
• Offline review replays can't rewind scheduling: recorded review history stays in chronological
  order.
• Failed loads show an error, not an empty page. Ask, Discover, and the flashcard views now surface
  a retryable error state instead of masquerading as empty or "not set up yet", and a valid session is
  restored on a new browser tab instead of forcing a re-login.
• Citations are verified against the cited paper, not merely any retrieved one.
• Truncated Telegram messages stay well-formed: a shortened message no longer fails to send because
  a formatting tag was left open.
• Cancelled background work cleans up. A cancelled job releases its resources and is no longer
  recorded as a failure, and one cancelled health check no longer disrupts concurrent ones.
• A pending email change no longer blocks the login link.
• Backups report honestly. A backup skipped during a maintenance window is reported as skipped
  rather than failed; the retention form no longer saves from an unloaded state; and the restore
  schema-compatibility floor, the upload size limit, and the version and proxy documentation are
  corrected.
• Clearer install and update diagnostics. update.sh lists only the rollback steps for the services
  that actually failed, and setup.sh rejects an option given without its value.

Model and backend defaults

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

Upgrading

Run ./update.sh, it pulls the new application images (use --build-local to rebuild from source). To
roll back to a previously published release, pin JARVIS_VERSION to that tag and pull it.

If you paired the Telegram bot from a group or supergroup chat, that pairing is removed on upgrade;
re-pair from a private 1:1 chat with the bot (Settings → Integrations) to keep receiving scheduled
updates.

Validation

Release validation included the full Python test suite, the database-backed contract suite against a
live PostgreSQL, frontend type checks and production build, the mocked Playwright end-to-end suite,
Ruff, complexity and test-shape gates, a strict documentation build, Docker Compose configuration
validation across the CPU/CUDA/ROCm/Vulkan overlays, and a release-blocking cold-install check against
the published :1.1.2 images.
Full changelog: https://github.com/limitcycle-oss/jarvis-rd-assistant/blob/main/CHANGELOG.md

v1.1.1

v1.1.1 — Install, update, and first-run reliability

A patch release that repairs install and update reliability on the prebuilt-image path and fixes the first-run smoke checks. The application and its container images are unchanged from v1.1.0 — only the installer, updater, and CI scripts changed, so the :1.1.1 images are functionally identical to :1.1.0.

Upgrading is optional for existing v1.1.0 installations that are running cleanly, and recommended for non-interactive installs, installs from a source tarball or a pinned tag, and AMD or ROCm hosts.

Fixed

• Non-interactive install no longer aborts at startup. The non-interactive bootstrap now generates the Langfuse key material before starting the stack, so a fresh install no longer fails at docker compose up with a missing-secret error.
• Disk preflight honours the selected accelerator. An explicit --gpu now drives the disk estimate, so a CUDA install no longer under-budgets (which risked running out of space mid-pull) and a CPU install on an NVIDIA host no longer over-budgets and blocks.
• Re-running against an existing .env regenerates missing secrets, so a second ./setup.sh on a partially provisioned host no longer dead-ends at startup.
• AMD (ROCm) Ollama updates correctly. The ROCm image is now pinned and update.sh compares against it, so AMD hosts are no longer reported as perpetually out of date.
• Shared directories stay readable on non-root hosts. When ownership cannot be handed to the container user, the directories keep world read-and-traverse permission so the container can still read them.
• Clearer install diagnostics. A flag passed without its value now reports which flag needs an argument instead of a raw shell error, and update.sh lists third-party and application services under the rollback command that applies to each.
• First-run smoke reports honestly. The clean-machine checks now read the installer's real exit code, which a pipeline had masked, so the restart-required check passes and a genuine failure can no longer be reported as success. The prerequisite check also accepts Docker Compose v2 and newer.

Install

git clone https://github.com/limitcycle-oss/jarvis-rd-assistant.git
cd jarvis-rd-assistant
./setup.sh

Full change list: CHANGELOG.md

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.