Piskes Agent Desktop Gets an Engine-Download Manifest

Piskes Agent Desktop's local engine has a working "Download engine" button now — or rather, the plumbing behind it works. Until this release, the Electron app's main process would fetch GET /engine/manifest.json before a user ever logged in, and nothing on the server side had ever implemented that route. The request fell through the app's default-deny auth middleware, got redirected to the login page, and the client tried to parse that page's HTML as JSON. It failed every time, in production, against the live domain.

What shipped

A new route serves the engine manifest as a dumb pipe from the shared media bucket: it reads desktop-engine/manifest.json and returns it byte-for-byte, without re-validating or re-shaping it. Validation — pinned version, HTTPS-only URLs, a 64-character sha256 checksum per platform artifact, non-empty artifact list — stays where it already lived, in the Electron client's own manifest parser. The route doesn't duplicate that logic; it just stops standing in the way of it. It's also explicitly exempted from the login gate, the same way the app's /version endpoint is, since the desktop app checks for an engine update before any user session exists.

What this doesn't mean yet

This release wires up the pipe, not the water. Until an actual engine build is published to that bucket location, the endpoint answers a typed 503 Engine manifest not published yet rather than inventing a manifest that promises a download it can't serve. That's deliberate — a 503 is honest; a fabricated manifest pointing at a build that doesn't exist would just move the failure from "can't parse the response" to "can't download the file."

Why it matters

Once a build lands in the bucket, this is the last piece standing between Piskes Agent Desktop's users and a real, checksum-verified local engine download — the app already knew how to ask for one and how to verify what it got back; the server just didn't know how to answer.