PromptFixer 0.4.0

Added

• A website: https://osman19702.github.io/PromptFixer/. What PromptFixer does, the latest
  installer with its size and SHA-256, and the notes of every release, newest first. The page is
  the site/ folder, published by a Pages workflow (.github/workflows/pages.yml) that runs when
  a release is published and when site/ changes on master. Before it uploads the page it runs
  npm run site:releases (scripts/site-releases.mjs), which writes the git-ignored
  site/releases.json from the GitHub Releases API — every published release with its installer,
  the installer's size, and its hash read from the release's own SHA256SUMS.txt — so the page
  cannot quote a number that is not on a release, and a fetch that fails keeps the previous
  deployment live rather than publishing an empty list. Once loaded, the page asks
  api.github.com once whether a newer release exists than the one it was built with, so a
  deployment that lagged behind a release still points at the newest one. It loads no fonts,
  scripts or analytics from anywhere else.
• What's new in the top bar opens that website in your own browser. GET /api/config gains
  homepage, read from package.json exactly as version is, and the interface shows the link
  only when it is an https:// address. It is a link, not an update check: the app never requests
  the site, there is still no update check, and scenario F11 (nothing leaves the machine) still
  runs on every push. In the desktop app the link takes the same road as any other external
  address — the window stays ours and the system browser opens it — which electron/handlers.js
  now holds as windowOpenGuard, with tests. Acceptance scenario H15 covers the link.

Changed

• package.json homepage is the website instead of the README.
• docs/PRIVACY.md names the link and says that clicking it is the only way the
  app's window reaches the site.

---

Download: PromptFixer-0.4.0-win-x64.exe (339 MiB). Windows 10/11, 64-bit. The model (2.5 GB, or the 1 GB "lite" tier) is downloaded on first run; installing over an earlier version keeps your library and the model.

Verify: installer SHA-256 a8748c36186d3b4ff0d16e81ab7e4044ab481caab1ada5ff547685893b1ff566 (SHA256SUMS.txt is attached). PowerShell: (Get-FileHash .\PromptFixer-0.4.0-win-x64.exe).Hash.ToLower() must equal it.

Not code-signed yet: Windows shows "Windows protected your PC" - More info, then Run anyway. Compare the hash first. Full guide: docs/INSTALL.md.

macOS (added 2026-10-16): PromptFixer-0.4.0-mac-arm64.dmg (138.9 MiB, Apple Silicon) and PromptFixer-0.4.0-mac-x64.dmg (144.1 MiB, Intel), macOS 13 or later, built by hand with npm run dist:mac from the 0.4.0 sources; SHA256SUMS.txt above lists them next to the installer. SHA-256 5950705c72d5e19e6b2abd7d8d334db50dabcee3c595b3248488303c814c17fa (Apple Silicon) and 6a5d3963ee807391be127626bee786bddf24a403a65de8546bf4feb4e7ea4b0c (Intel); Terminal: shasum -a 256 ~/Downloads/PromptFixer-0.4.0-mac-arm64.dmg. The app is ad-hoc signed and not notarized, so the first launch is refused: Done, then System Settings → Privacy & Security → Open Anyway, once. On Apple Silicon the model runs on the GPU through Metal; on an Intel Mac, on the CPU. Guide: docs/INSTALL.md.

Built by the Release workflow from commit eefc8ad.

PromptFixer 0.3.0

Added

• npm run visual -- --against <ref> compares the interface with a commit instead of with
  approved pictures: the ref is checked out into .elastishot/against/<sha>, built there and
  served by its own server, its screens become the pictures of that one run, and the working tree
  is compared with them. Nothing has to be approved or committed first, and your approved pictures
  are neither read nor written. A screen the ref cannot be driven to is reported as new; a ref no
  screen of which can be captured (v0.1.0, which predates the hooks the check drives the page by)
  is an error that says so.

• CI keeps its reports. A third job compares every screen of a pushed commit with the commit it
  was pushed onto (a pull request: its target branch) and keeps the Elastishot report as the
  elastishot-report artifact, with its table as the job's summary page; a difference does not
  fail that job, a comparison that could not be made does. The acceptance job keeps
  docs/ATDD-RESULTS.pdf as the run printed it (acceptance-report) and shows the traceability
  table as its summary page. Both are kept for 14 days whatever the run's outcome.

• Every saved result records the build that produced it. A library entry gains appVersion,
  and GET /api/library/export gains one for the file as a whole, beside the unchanged format
  version. The scoring rules change between releases, so a score that has moved since you saved
  it is either a rule change or a defect — and this is what tells them apart.
  It is never guessed. A save is written by this build and gets this version; an import keeps
  whatever the exporting build wrote, because that entry's provenance is not ours to restate; and
  an entry carrying no version — saved before the field existed, or imported from a build that did
  not write one — stays unknown, and the library drawer shows it as "version unknown" rather than
  claiming a build that never saw it. Re-saving an entry stamps it with the build that rewrote it,
  the same write updatedAt already describes.

• server/version.js is the single import for the running version. server/index.js and
  server/store.js both read it from there instead of parsing package.json themselves, so the
  version is still written down in exactly one place.

• The running version is shown in the interface, beside the app name, so a bug report can name
  the build it came from without going looking for it. GET /api/config gains version, read
  from package.json exactly as GET /api/health reads it, so the two cannot disagree and the
  version is still written down in only one place.

• The rewrite appears as it is written. POST /api/fix streams its progress when the request
  asks for it (Accept: application/x-ndjson): one JSON object per line, reporting each attempt,
  the rewrite as the model produces it, and finally the same result body the route returned before.
  A request without that header gets exactly the JSON object it always did. The rewrite is the
  first field the grammar emits, so it can be read out of a reply that is still arriving; the Fixed
  tab shows it as plain text while the fix runs, because the scores, the diff and the marks all
  need the finished result.

• The spinner says which wait this is. A line beside the Fix button names it: waiting for the
  job in front of it (only one model job runs at a time), loading the model, writing the rewrite,
  or the second attempt after a rewrite failed the quality check. That last one used to double the
  wait with nothing on screen to explain it.

• The editor warns about an over-long prompt while you type. GET /api/local/status reports
  inputBudgetTokens, the room the prompt has once the reply is reserved, so a prompt too big for
  the local model is flagged under the editor in under a second instead of being refused half a
  minute later, once the model has loaded and counted it. A warning, never a block: the estimate is
  four characters to the token and the real budget follows the context the model managed to load.

• Real numbers on the load and the download. Loading the model shows a progress bar instead of
  a bare spinner for about fifteen seconds, and the download shows its speed and how long is left
  next to the percentage.

• The model is released when nobody is using it. After fifteen minutes with nothing to do it is
  unloaded and the memory goes back, so the app can sit open next to a browser and a test runner on
  an 8 GB laptop; the next fix loads it again. Release model does it at once. Set
  PROMPTFIXER_IDLE_UNLOAD_MS=0 to keep it loaded for ever.

• A stalled local fix is stopped. A generation that produces nothing for five minutes is ended
  rather than holding the single model queue for the rest of the session. It is a stall limit, not
  a stopwatch on the whole run: every chunk the model emits resets it, so a slow machine is never
  cut off mid-answer. Measured on a CPU-only machine, a first fix takes about 100 s and a "fix
  again" — which sends the whole previous rewrite back, and may be retried once — comfortably
  exceeds five minutes while working perfectly. PROMPTFIXER_FIX_TIMEOUT_MS changes the limit,
  0 removes it.

• Disk is checked before a download, and can be reclaimed from inside the app. A 2.5 GB
  download that will not fit is refused in under a second, naming both numbers, instead of failing
  an hour in; free space that cannot be read never blocks a download. DELETE /api/local/model/:tier deletes a model and any part-finished download of it, and the row under
  the provider selectors shows what each tier occupies and offers to delete it — so trying all
  three tiers no longer means clearing 8.2 GB by hand from a hidden folder.

• "Nothing leaves your machine" is now a test, not a claim. Acceptance scenario F11 was the
  project's only manual charter: a person unplugging a network cable. It now runs on every push.
  The server is started under acceptance/support/netwatch.mjs, which intercepts outbound TCP
  (and so TLS, HTTP, HTTPS and fetch), UDP, and the whole dns resolution family, and records
  every destination that is not this machine. A full session — score, fix, save, list, export,
  import, and the same session again in a real browser — has to leave that record empty. The test
  proves the watcher works before trusting it, by making a deliberate call off the machine and
  asserting it was caught, and it fails if the session starts a child process, because a child's
  traffic is the one thing the watcher cannot see through. The browser half asserts the page
  requests nothing beyond its own origin, from the first request of the document load onwards,
  and blocks service workers outright.

• The watcher has its own regression suite, server/netwatch.test.js: seventeen checks, each one
  a way code reached the network past an earlier version of it. A port passed as a string rather
  than a number; dns.resolve*, which builds its socket in C++ and so never appears at the socket
  layer; an ESM import { lookup } from 'node:dns', which binds to the unpatched function because
  a builtin's named exports freeze when the facade is first instantiated; execSync, which does
  not call the spawnSync export; a worker created with execArgv: []; a connected UDP socket,
  whose send names no address; a TLS tunnel whose destination exists only as servername; and a
  Windows UNC path, which carries bytes to another host with no socket to it. All were found by
  trying to break the watcher on purpose and all are now closed. The watcher is installed through
  NODE_OPTIONS rather than a command-line flag, because a worker and a spawned node child
  inherit the environment but not the flag.

• F11 refuses to vouch for a machine with a proxy variable set: a proxy on loopback makes every
  destination look like this machine, so a clean result there would mean nothing. The harness
  blanks the proxy variables for every server under test and the watcher reports any that survive.

• docs/PRIVACY.md: one page naming every host the app can reach and when, where
  your prompts and library are stored, what F11 checks, and "What the test does not cover" —
  the page to hand to whoever approves software where you work.

Changed

• The app no longer builds its model engine from source. getLlama() was called with the
  default build: 'auto', which on a machine with no matching prebuilt binary resolves a release
  from GitHub, clones llama.cpp and may fetch a toolchain — real network traffic, unasked, from an
  app whose headline claim is that it makes none. It is now called with build: 'never' and
  skipDownload: true, so a missing binary is a clear error instead of a silent download. The
  installer ships the binary, so this only fires on a platform there is no build for.
• A fix is no longer a pure function of the prompt, and the documentation now says so. Up to two
  rewrites from your own library go to the model as examples, so the input changes as the library
  grows. "Repeatable runs" in the README says what to turn off before comparing or timing two runs.
• The error path of POST /api/fix finishes a streaming reply with an error event. The status
  line has already gone out as 200 by the time the model is called, so a failure that used to
  arrive as a status code now arrives as the last line of the stream.

---

Download: PromptFixer-0.3.0-win-x64.exe (339 MiB). Windows 10/11, 64-bit. The model (2.5 GB, or the 1 GB "lite" tier) is downloaded on first run; installing over an earlier version keeps your library and the model.

Verify: installer SHA-256 39dde4aaf5e9ac4b059d256280002211d5e78a89ffc65dc375e7965c5d71b0d7 (...

PromptFixer 0.2.0

Added

• Fix again with your marks. On the Fixed tab, select any passage of the rewrite and press
  Keep it — I loved it or Change it — I didn't like it. Kept passages are highlighted
  green and passages to change red, in the Diff tab's colours, and the bar counts them. Fix
  again with my marks sends the marked rewrite back to the model, which revises it instead of
  starting over. The prompt you wrote stays the yardstick, so the before score, the Diff tab and
  the strength guard measure every attempt against the same original and the scores stay
  comparable. Click a highlight to remove it (from the keyboard, Tab to it and press Enter or
  Space), mark it the other way to change your mind, or press Clear marks. Up to 20 passages
  of each kind can be marked. Marks belong to the one rewrite they were made on: a new fix or a
  step through the fix history drops them.
• The guard checks your marks the way it checks the strength. Every kept passage has to come back
  word for word, and every passage marked for change has to occur fewer times than it did in the
  marked rewrite. A rewrite that misses a mark is retried once with the missed passages quoted;
  if the retry misses one too, you get the attempt that ignored fewer marks, under a yellow Did
  not follow all of your marks warning that says how many. The What changed line of a refined
  result ends "refined with your marks (1 kept, 1 changed)" and counts only the marks the model
  followed. The README's "Rewrite strength, and the guard behind it" has the rules in full.
• For scripts that call the API: POST /api/fix takes an optional
  feedback: { previous, keep, change } — the rewrite that was marked, and the passages of it to
  keep and to change — while prompt stays the original. The response gains meta.feedback
  (keep, change, missingKeep, unchangedChange), present only when marks were applied, and
  meta.warningKind gains a fourth value, feedback. Marks are coerced rather than refused:
  passages that are not in previous are dropped, duplicates collapse, each list stops at 20
  passages and each passage at 2,000 characters. Only a previous over the 60,000-character
  prompt limit is refused (413). A request without feedback, or with nothing usable in it, is
  the same fix as in 0.1.0.
• Visual checks for contributors, with Elastishot.
  npm run visual:approve stores pictures of seven screens, each at two window sizes, as the
  approved look; npm run visual captures them again and fails on any difference, naming the
  element behind it. Both start the scripted stub provider and a throwaway server, so no key, no
  model and no network are needed. The approved pictures are per machine and git-ignored
  (.elastishot/), because fonts and antialiasing differ from one machine to the next; for the
  same reason the check is not part of npm run test:all. The screens are listed in
  elastishot.config.mjs.
• Acceptance Groups M (marking a rewrite and fixing it again, through the API and the browser)
  and N (the visual check, run through the real Elastishot command line). The suite went from 95
  scenarios to 113, of which 102 are automated.
• scripts/capture-screenshot.mjs reads SHOT_PROMPT (the prompt typed into the editor) and
  SHOT_INTENT (the Task type chosen for it), so the app screenshot can show any prompt, not
  only the blog-post sample.
• This changelog, the release checklist in docs/RELEASING.md, and a Release
  workflow that builds the Windows installer when a v*.*.* tag is pushed and attaches it, with
  SHA256SUMS.txt, to a draft GitHub release. npm run check:release is the gate in front of
  it: package.json, package-lock.json and this file have to name the same version, and no
  source file may repeat it. Started by hand, the same workflow is a rehearsal: it builds
  everything on the runner and creates no release.
• A CI workflow. Every push to any branch, and every pull request from a fork, runs the release
  check, the typecheck, the build and the unit and component tests in one job and the acceptance
  suite with the traceability check in another, both on a Windows runner.
• scripts/capture-screenshot.mjs also reads SHOT_MARKS=1: the rewrite is marked before the
  picture is taken — one passage kept, one to change, chosen from what the model returned and
  still in view — so the app screenshot can show the marks. SHOT_KEEP and SHOT_CHANGE name
  the passages instead.

Changed

• npm run test:acceptance takes about four minutes instead of about eighty seconds: each of
  Group N's seven scenarios starts the Elastishot command line and a browser of its own.
• GET /api/health reports the version from package.json instead of a number written into the
  handler, so it cannot fall behind a release.
• When a fix fails, the error banner is scrolled into view. Pressed from the bottom of a long
  rewrite, a failure used to look like a dead button.
• The score panel, the issue list, the diff, the Library drawer and the date on a Library entry
  carry data-testid attributes, so the visual check can name them in a report and keep what
  varies between runs off the pictures.

Fixed

• Saving to the library on Windows failed when another program — an indexer, antivirus, a backup
  tool — had library.json open at that instant, because Windows refuses to rename over an open
  file (EPERM, EBUSY or EACCES). The save now tries the rename again for about a second,
  which outlasts such a reader, and a save that still fails removes its temporary file instead
  of leaving it next to the library.
• The acceptance harness cleans up after a server that fails to start: the child process is
  stopped and its two temp folders are removed. A start that timed out used to leave the server
  running and the folders behind.

---

Download: PromptFixer-0.2.0-win-x64.exe (339 MiB). Windows 10/11, 64-bit. The model (2.5 GB, or the 1 GB "lite" tier) is downloaded on first run; installing over an earlier version keeps your library and the model.

Verify: installer SHA-256 0388c49399efb895036f2f75e8a7b09803d613bb56850d9644ed17c7c0b9853e (SHA256SUMS.txt is attached). PowerShell: (Get-FileHash .\PromptFixer-0.2.0-win-x64.exe).Hash.ToLower() must equal it.

Not code-signed yet: Windows shows "Windows protected your PC" - More info, then Run anyway. Compare the hash first. Full guide: docs/INSTALL.md.

Built by the Release workflow from commit ee23dd0.

PromptFixer 0.1.0 (Windows x64)

PromptFixer 0.1.0 — Windows x64 installer

Lints, scores and rewrites LLM prompts with a built-in local model (Qwen3 4B); nothing you type leaves your machine. Cloud providers (Anthropic, OpenAI, Gemini, OpenRouter, Ollama) are optional.

Download: PromptFixer-0.1.0-win-x64.exe (~355 MB). Windows 10/11, 64-bit. The model (2.5 GB, or the 1 GB "lite" tier) is downloaded on first run into %USERPROFILE%\.promptfixer\models.

Verify: installer SHA-256 4f49a75fa3b01cbf98cee56100e2afdc14b42b56b1eef3853e47afc010194c2e (SHA256SUMS.txt is attached). PowerShell: (Get-FileHash .\PromptFixer-0.1.0-win-x64.exe).Hash.ToLower() must equal it.

Not code-signed yet: Windows shows "Windows protected your PC" → More info → Run anyway. Compare the hash first if in doubt. Full guide: docs/INSTALL.md.

Why ~355 MB: the installer ships prebuilt CPU, Vulkan and CUDA llama.cpp backends so the right one is picked at runtime. The .blockmap is only for future differential updates.