diff --git a/CHANGELOG.md b/CHANGELOG.md
index 1a3e2d6..89d29e4 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -9,6 +9,42 @@ one of them changed. An entry says which artefact and which version, so `web 0.1
 Every version published to a channel appears here. Nothing is written from memory afterwards: a build
 cannot be published without its entry.
 
+## 2026-09-12 — The dock stayed on one computer, and its menu offered to add a conversation that was already there `api 0.111.0` `web 0.133.0`
+
+Two complaints about the same rail, a day apart. They turn out to be the same mistake made twice:
+the dock was described as a place things get put into and taken out of, when by the time you can see
+a conversation's menu the conversation is already in it.
+
+**The overflow menu no longer offers to add what is already there.** It read "Pin to the dock" above
+"Remove from the dock" — a matched pair, one the opposite of the other, and neither true. Opening a
+conversation files it in the dock on its own; there was nothing left to add. The menu now has a
+heading that says the conversation is **In the dock**, a **Pinned** line you switch on and off that
+shows you which it currently is, and a separate **Close** underneath. Closing takes the conversation
+off the rail. It does not delete it, and it is not the opposite of pinning — the two were never a
+pair, and now they do not look like one.
+
+**The same is true of the rail and the panel**: the button at the end of a row is called _Pinned_ and
+reports its own state, rather than naming an action whose effect you could not see. Screen readers
+announce it as a switch, with its position.
+
+**Closing the conversation you are reading now works.** It appeared to do nothing: the dock put the
+open conversation straight back on the rail, so the row you had just closed was redrawn before you
+could see it go. It stays closed, and comes back the moment you open that conversation again.
+
+**Your dock follows you between computers.** Pins and recents were kept in the browser, so a
+conversation pinned on the desk machine was not pinned on the laptop, and signing in somewhere new
+gave you an empty rail with no way to tell whether that was right. They are now held on the server,
+per account and per organization, and every window you have open moves together: pin something on one
+machine and the other machine's rail reorders within the second. Pins already on a device are taken
+up once, the first time that browser talks to this release, so nothing you pinned before the upgrade
+is lost.
+
+**Self-hosters:** one new table, applied on start-up like every other schema change. It only adds —
+nothing is dropped or narrowed — so the destructive-change guard does not trip and
+`SCHEMA_ACCEPT_DATA_LOSS` stays off. No configuration, and no action on the browsers: the adoption of
+existing pins happens by itself. The dock rides the same websocket the console already holds open, so
+there is no new port and no new outbound connection.
+
 ## 2026-09-11 — The assistant was reading the first and last pages of a file and nothing in between `api 0.110.0`
 
 Anything the assistant read — a document in a conversation's workspace, a config file on one of your