VAF v0.1.0a17

Added

• VAF is published to PyPI with every release. Library users can install the
  framework with pip install --pre vaf (--pre is the recommended spelling while
  VAF is in alpha) and update it with pip install -U --pre vaf; the desktop/server installers
  keep working exactly as before. Publishing is tokenless (PyPI Trusted Publishing),
  and releases can be rehearsed against TestPyPI via a manual workflow first. The
  embedding guide gained a "Choosing a backend: local vs API" section, and the README
  now opens with a library quickstart.

Changed

• vaf update refuses to run outside a VAF source checkout. On a pip-installed
  VAF (or a folder that is not a VAF source tree) the git self-updater now points to
  pip install -U --pre vaf instead of offering a git conversion that could have
  damaged the Python environment.
• VAF's packaging moved to the modern Python standard (pyproject.toml). The
  install commands do not change (pip install -e ., extras like vaf[server] and
  vaf[all] stay exactly the same), the license is now declared in the standard
  machine-readable form, and the LICENSING.md terms file ships inside the package.
• Installing VAF with pip no longer runs platform setup scripts. A plain
  pip install -e . used to silently trigger macOS/Windows provisioning scripts in
  some legacy flows; a pip install is now strictly a Python-package install. The
  desktop installers (install.sh / install.ps1) are unaffected and keep doing the
  full provisioning.
• The vaf command now works on a minimal library install. With only the base
  dependencies installed, vaf --version, vaf prompt and other light commands run
  normally, and commands that need optional components (for example vaf run --web
  or the Discord bridge) explain which extra to install (such as
  pip install "vaf[server]") instead of crashing with an import error.

Fixed

• The document editor's page stays white in dark mode. The DOCX editor's sheet is a
  rendering of real paper, and Print and PDF show exactly what is on screen, so it keeps its
  light appearance while the app around it goes dark.
• A tool the local model tried to run no longer silently vanishes. With the built-in
  local model, some tool calls (for example adding a calendar event) came out in a format the
  app recognised only for one specific model family. For every other local model the call was
  left as plain text in the chat and simply never ran, so nothing happened and no error was
  shown. That format is now recognised for any local model.
• The app no longer runs its window on native Wayland, which could crash it on Linux.
  VAF has always meant to run its window through XWayland (native Wayland conflicts with the
  browser engine and, with the GPU shared in-process, could freeze and then kill the app).
  That safeguard silently never applied on KDE and GNOME Wayland desktops, because those
  sessions set the display server themselves and VAF only filled in a value when none was
  set. It now sets it deliberately. If your system has no XWayland, VAF leaves your session
  alone instead of starting with no display at all, and VAF_ALLOW_WAYLAND=1 keeps native
  Wayland if it works well for you. The choice is written to the startup log.
• A slow or unreachable speech provider can no longer freeze the whole app. The
  ElevenLabs voice/model catalog was fetched in a way that blocked the server's event loop,
  so opening Voice settings with a slow, unreachable or exhausted account could stall every
  request and the live connection for everyone until it timed out. It is now fetched without
  blocking, a failure is remembered briefly instead of being retried on every redraw, and two
  simultaneous requests share one lookup. The same blocking pattern was fixed in the email
  account verification and the Telegram dashboard.
• The local model is no longer unloaded while it is still working. When a longer task was
  running and you had not typed for a while, the app counted you as away and freed the model
  mid-task. The work then stalled behind failing retries and looked like a freeze, and two
  competing attempts to load the model again could collide. The app now keeps the model
  loaded whenever something is actually running, whether that is your message, a background
  helper or a live call. Loading is also serialized, so two parts of the app can no longer
  fight over it, a model that is merely still loading is waited for instead of killed, and
  stopped model processes are cleaned up instead of lingering.
• A finished workflow is no longer labelled FAILED when it succeeded. Workflows that run
  in their own process reported their outcome to the app, but the outcome itself was dropped
  on the way to the browser, so the panel fell back to showing a failure. Every step showed a
  green tick, the document was written, the chat said it worked, and the panel still said
  FAILED. The result now arrives intact, and so does the live output those runs stream.
• The workflow panel no longer gets stuck showing a run that has long finished. If the
  connection to the browser dropped while a workflow was running, everything that happened
  afterwards was lost, and the panel kept showing the last thing it had seen, with no way to
  close it. It now asks the app what the real state is when the connection returns, when you
  come back to the tab, and after a reload. If the run is over, the panel says so plainly and
  closes instead of inventing a result. It also has a close button now, which matters on
  phones where the panel covers the whole screen.
• Terminal windows opened for background work now close again on Linux. A window opened
  for a sub-agent or a workflow announced that it was closing and then stayed on a shell
  prompt forever, because a shell was started on top of the finished task. Windows now close
  when the work succeeded and stay open when it did not, so an error can still be read, and
  --no-auto-close keeps working as documented. On macOS this also depends on your Terminal
  profile setting for what happens when the shell exits.
• No stray terminal window when the browser connection drops. Work started from the app
  ran without a visible window only while a browser was connected. If the connection dropped
  during a long run, the next helper opened a terminal window on the desktop, and the app's
  Stop button could not reach it. The decision no longer depends on a browser being attached
  at that moment.
• A busy workflow no longer floods and kills its own connection to the browser. While a
  research step was running, its progress animation was forwarded to the browser frame by
  frame, hundreds of times per second. That was enough to drop the live connection in the
  middle of a run, after which the Workflow Runtime panel never advanced again and sat at
  the last state it had received. Progress output is now filtered and rate-limited before it
  is sent, in every place that forwards it, and the animation that produced it is no longer
  started when nobody is watching a real terminal. The separate workflow terminal keeps its
  colours and live display. Long, quiet steps are also no longer mistaken for stuck ones:
  the "no output" watchdog now allows a heavy step the time it is actually given.
• A workflow that hands work to a background helper is no longer reported as crashed.
  When a workflow step passes its work to a helper (writing a document, researching a
  topic), the workflow pauses and waits instead of finishing. Three of the places that read
  the result knew only "done" and "broken", so a perfectly healthy run was announced as
  failed while the work was still being produced, and the assistant apologized for a crash
  that never happened. A paused run is now recognized everywhere as still running, in chat,
  in the separate workflow terminal and in automation reports. Paused runs also remember
  which conversation they belong to, so switching conversations no longer discards them, and
  a run whose helper was the final step is now completed automatically in the app instead of
  only in the terminal client.
• Telegram stays responsive while a voice message or file is transferred. Sending or
  receiving audio, voice notes and documents held up the Telegram connection for as long as
  the transfer took, so other messages in the same chat had to wait behind it. Transfers now
  run out of the way of the message loop.