Write the release order down where it will be read

Enabling immutable releases, configuring the dependency-release
environment, which order the two dispatch runs go in, and which five
constants have to move together were all in the pull request
description, which is not a place anybody looks a year later.

The same file says what this costs: the pinned digest means a backend
update is a Dikte release, and the build is deterministic between two
runs of one builder rather than across time, because the apt metadata
behind the pinned packages is not pinned and LunarG drops superseded
ones. Both are worth knowing before the next version bump, not during
it.

The README keeps a clause instead of the paragraph it had grown.

README.md

@@ -163,10 +163,9 @@ running.
   the program and the model, verifies the sha256 and refuses a download published
   without one, then keeps a server alive while you dictate. The graphics card is
   reached through CUDA, ROCm or Vulkan where the build allows. No key, no
-  account, nothing leaving the machine. On x86_64 Linux, that same Download
+  account, nothing leaving the machine. On x86_64 Linux the same button fetches
-  button tries the reviewed Vulkan bundle when a loader is present, and falls
+  a Vulkan build of whisper-server that Dikte publishes itself, because
-  back to upstream's CPU build if it is unavailable. The bundle also carries CPU
+  upstream's Linux archive is processor-only.
-  backends for systems where a Vulkan device cannot start.
 - **Silence never reaches the API.** Handed near-silence, a transcription model
   invents a sentence instead of returning nothing ("Thanks for watching", or in
   Turkish "Altyazı M.K."). A recording is dropped when nothing rose 10 dB above

README.tr.md

@@ -160,9 +160,8 @@ olmasını ister.
   checksum'suz yayınlanmış bir indirmeyi reddeder, sen dikte ettikçe sunucuyu
   ayakta tutar. Derleme destekliyorsa ekran kartına CUDA, ROCm ya da Vulkan
   üzerinden ulaşılır. Anahtar yok, hesap yok, makineden çıkan bir şey yok.
-  x86_64 Linux'ta aynı İndir düğmesi, Vulkan yükleyicisi varsa incelenmiş Vulkan
+  x86_64 Linux'ta aynı düğme, whisper-server'ın Dikte'nin kendi yayınladığı
-  paketini dener; paket kullanılamıyorsa upstream'in işlemci derlemesine döner.
+  Vulkan derlemesini indirir; upstream'in Linux arşivi yalnızca işlemci için.
-  Vulkan aygıtı başlatılamadığında kullanılacak işlemci arka uçları da pakettedir.
 - **Sessizlik API'ye gitmez.** Sessize yakın bir ses verildiğinde model boş dize
   döndürmez, bir cümle uydurur ("Altyazı M.K.", "Thanks for watching"). *O
   kaydın kendi* gürültü tabanının 10 dB üstüne en az 0,3 saniye çıkan bir şey

packaging/whisper-vulkan/README.md

@@ -0,0 +1,49 @@
+# The Vulkan whisper-server bundle
+
+whisper.cpp publishes a CPU-only archive for Linux, so the graphics card on a
+Linux machine is out of reach through the Download button. This directory
+builds the archive upstream does not: `whisper-server` with a dynamic Vulkan
+backend next to the CPU ones, for x86_64, against the Ubuntu 22.04 runtime
+contract.
+
+It is published as a release of Dikte's own, `whisper.cpp-v<version>`, marked
+as a prerelease and kept off Latest so that neither the update check nor the
+download page picks it up. `dikte/ggml.py` fetches it by tag and installs it
+only when the archive's digest is the reviewed one; anything else falls back
+to upstream's CPU archive, and the settings window says when it did.
+
+## Publishing a new bundle
+
+1. Enable GitHub's immutable releases setting for the repository, and give the
+   `dependency-release` environment a required reviewer. Both are repository
+   settings, not something this workflow can do for itself.
+2. Run **whisper.cpp Vulkan bundle** on `master` with the new version and its
+   peeled commit, `expected_sha256` empty and `publish: false`. The run builds
+   the archive and reports its digest; without a reviewed digest it refuses to
+   publish, which is what the first run is for.
+3. Review that digest against a build of your own, then run the workflow again
+   with the same version and commit, `expected_sha256` set to it, and
+   `publish: true`. Approve the environment when it asks.
+4. Write the same version, tag and digest into `MANAGED_WHISPER_RELEASE`,
+   `MANAGED_WHISPER_VERSION` and `MANAGED_WHISPER_SHA256` in `dikte/ggml.py`,
+   and into `REVIEWED_WHISPER_VERSION` and `REVIEWED_WHISPER_SHA256` in the
+   workflow. `tests/test_packaging.py` holds the two sides together.
+5. Ship a Dikte release. Until one goes out, nobody's Dikte knows the new
+   bundle exists.
+
+## What this costs, and what it does not promise
+
+The digest lives in Dikte's source, so a backend update is a Dikte release.
+Linux x86_64 machines with a Vulkan loader stay on the pinned whisper.cpp
+version until step 5 happens, while every other platform follows upstream's
+newest release on its own. That is the deliberate trade: an executable Dikte
+downloads is not allowed to change without a reviewed digest behind it.
+
+The build is deterministic between two runs of the same builder, not across
+time. The base image, the CMake tarball, the LunarG packages and the direct
+apt packages are pinned by digest or version, but the Ubuntu and LunarG
+repository metadata behind them is not, and LunarG drops superseded packages.
+A rebuild months later can fail to resolve, or resolve to something that
+produces a different digest. Treat the published archive as the artifact, not
+as something reproducible on demand: a version bump means building,
+validating, reviewing the new digest and updating the pinned tuple together.