diff --git a/docs/release-notes/0.6.5.md b/docs/release-notes/0.6.5.md
new file mode 100644
index 0000000..3816ca1
--- /dev/null
+++ b/docs/release-notes/0.6.5.md
@@ -0,0 +1,88 @@
+**The dashboard now tells the truth about what is streaming. Two things it reported were simply
+wrong, and both were wrong in the same direction — saying nothing was happening when something
+was.**
+
+## A streaming seat said it was idle
+
+A seat with a Moonlight client attached reported its status as `Ready`, not `Streaming`. The stream
+worked; only the reporting was wrong. So the dashboard showed an active seat as idle, and anyone
+deciding whether a seat was safe to tear down got the wrong answer.
+
+The cause was narrow and easy to miss. MultiSeat watches a seat's Apollo log for client connect and
+disconnect, and that watcher opened by checking whether any launch-on-connect apps were configured.
+If none were — which is the default — it returned immediately, and the connect detection went with
+it. Nothing on a default installation ever noticed a client arriving.
+
+Detection now always runs. Launching apps is still optional; noticing a client is not.
+
+**Verified on real hardware**, not only in tests: `Ready` to `Streaming` in 6 seconds on connect,
+back to `Ready` in 3 on disconnect.
+
+## A streaming host said it was idle too
+
+The same class of error, one level up. MultiSeat asks a standalone Apollo whether it is streaming by
+reading its `serverinfo`, which reports the state of a launched **application**. Someone streaming
+the plain desktop — which is what a second Apollo is usually for — leaves that permanently reading
+"free".
+
+Measured here: a client streaming the desktop for 26 minutes, the GPU encoder busy the whole time,
+and `serverinfo` still insisting the host was idle.
+
+MultiSeat now decides this from the encoder itself — per process, so another remote-desktop tool on
+the same machine cannot be mistaken for Apollo. Verified in both directions: correctly idle when
+nothing is streaming, correctly busy during a live stream that the old check missed entirely.
+
+## Tearing down a seat now says when it will disturb someone
+
+Every seat is a remote desktop session, and ending one is a display change that any other Apollo on
+the machine notices — it rebuilds its encoder, and whoever is watching sees a brief hitch. This is
+not new and is not fixable: the session has to end for the seat to go away.
+
+What is new is that it no longer happens silently. Tear down a seat while a standalone Apollo is
+streaming and MultiSeat says so first, naming the consequence.
+
+**Measured at 266 ms, and the person streaming did not notice it.** An earlier measurement of 690 ms
+led to this being described as a second-long freeze; that was too strong and has been corrected
+everywhere it appeared.
+
+⚠️ One person on one network is not proof it is always imperceptible. A busier machine may feel it.
+But the warning now describes a few hundred milliseconds rather than a freeze.
+
+## Continuous integration no longer fails on someone else's outage
+
+The dependency audit added in 0.6.2 failed a build when the npm registry returned an error, because
+`npm` reports "found a problem" and "could not check" the same way. A real finding still fails
+immediately; an unreachable registry is now retried and then reported as a warning, saying plainly
+that nothing was audited in that run.
+
+This affects nobody running MultiSeat. It is here because a build that goes red for reasons unrelated
+to the code trains people to ignore it.
+
+## Install
+
+```powershell
+.\prerequisites\install-prerequisites.ps1     # drivers - needed either way
+.\scripts\install-service.ps1 -FromZip .
+```
+
+Your configuration is preserved, as of 0.6.4 — `appsettings.json` and `appsettings.local.json` are
+kept byte for byte, with a backup under `C:\ProgramData\MultiSeat\config-backups\`.
+
+Afterwards, confirm what landed:
+
+```powershell
+& 'C:\Program Files\MultiSeat\MultiSeat.Service.exe' --config
+```
+
+It should report `0.6.5`.
+
+## Known limitations
+
+- **Seats capture the remote desktop surface, not a dedicated virtual display.** A seat's display
+  reports a 1000 Hz refresh rate, which is the sign of it. A Windows constraint on where a virtual
+  display can attach, not a regression.
+- **Tearing a seat down still briefly disturbs a standalone Apollo.** Now announced rather than
+  silent, but unchanged.
+- Seat auto-discovery from another machine was fixed in MoonlightVibe 6.3.4 but has not been run by
+  anyone yet. If a seat does not appear on its own, add it by address and port — the first seat uses
+  48100, and each further seat is thirty higher.
diff --git a/version.txt b/version.txt
index d2b13eb..ef5e445 100644
--- a/version.txt
+++ b/version.txt
@@ -1 +1 @@
-0.6.4
+0.6.5