chats 0.4.2 → 0.5.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: f2f76b973f012e2c86514932efaca3db25eaf8c70ed4709276d1f5f33d520de2
-  data.tar.gz: 2b88c68ad0d239a9ba87b5e907193924926a3926715ed39b62f844e2d899bf19
+  metadata.gz: 233373c7319647cf267ec239c0227e7751deae6ea9a4afd8d94c578994c85a22
+  data.tar.gz: 02b7e37be81c69063969d202094430b1657640ea707a1f63e78c06876eb6877d
 SHA512:
-  metadata.gz: be31c3ce5aad04e1c9d5d0ba141403514da0f547de42a4516ede78117025a12c7f3936060787a3935e477e4f2c03aa2fcfb7b7550c0fdca77a5c6d65a0c86db3
-  data.tar.gz: f22af91cf0ccb50bd933659d0fdc549306ecb2bfad09ee87cfb0193499a0839c2f468cd8e109ad7266ddba35200126b28d5f8958b065420fd828a065b9f40b80
+  metadata.gz: 9bd561feaae573165ce631dac3e669b892d5d70271435a475bc36d92dc532fcd6f55b0b908415141845b47105600088dd739ae7adfeb520baf4cb4bcc0096127
+  data.tar.gz: ecd69642c82c827c53b5d038b8dd60f5853f5b012368c5d4db846b4549befbd4fd8b153b45d0468228cd77746b77b6c60dadd26ab5d36f73f2a31a4ec84a2edd

data/CHANGELOG.md

@@ -4,6 +4,484 @@ All notable changes to this project are documented here.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.5.1] - 2026-10-18
+
+A page that missed a broadcast is never left stale: every live surface
+catches up on its own, without polling (fixes
+[#1](https://github.com/rameerez/chats/issues/1)). Also: the dock's unread
+count in every language's plural forms, one extension point for a
+conversation that must open although the inbox hides it
+(`conversation_lookup_scopes`), and real conversations told from
+system-only threads. **No migration, nothing to configure.**
+
+### Added
+- **Real conversations vs system-only threads.** `with_messages` asks whether
+  a conversation holds anything at all, system lines and tombstones
+  included; ops walls, moderation lists and analytics ask whether a messager
+  wrote something there that still stands. Four additive reads answer that:
+  `Chats::Message.human` (kind `text`, not deleted: written by a messager,
+  person or not, as opposed to posted by the app, so a bot's or a headless
+  desk's text message counts and a photo with no caption counts too), `Chats::Conversation.with_human_messages` and
+  `.without_human_messages` (one correlated `EXISTS` / `NOT EXISTS` built
+  from `Message.human`, so they compose with `alice.chats`, `inbox_for`,
+  `about`, `unread_by` and `with_messages` and never multiply rows),
+  `Conversation#last_human_message` (a query, not the `last_message`
+  pointer), and its batch twin `Chats::Message.last_human_in(conversations)`:
+  the newest human message of each conversation in ONE query, for a loaded
+  page, ids, a single record, or an unloaded relation, which is read as a
+  subquery and never loaded first. It returns a relation, so a `.select` can
+  narrow the columns. Viewer-facing lists start from `alice.chats`, which
+  applies blocks and `config.inbox_scope`; the bare `Chats::Conversation`
+  scopes see every conversation and belong behind staff authorization.
+  Nothing changes by default: system messages still bump `messages_count`
+  and `last_message`, and the inbox still lists system-only threads.
+- **`Chats::ApplicationController#conversation_lookup_scopes`, the one
+  extension point for a conversation that must open although the inbox
+  hides it.** Every engine endpoint (the thread, a dock window, sending,
+  editing, reacting, reading) finds a conversation through
+  `find_conversation(id)`, which now asks each relation
+  `conversation_lookup_scopes` returns, in order (`find_by(id:)`), and
+  raises `ActiveRecord::RecordNotFound` when none has it. By default that is
+  `[chats_current_messager.chats]`, exactly the old lookup. A product gem
+  (support_desk: a requester's own ticket, which the host's `inbox_scope`
+  keeps out of the inbox) prepends a module whose
+  `conversation_lookup_scopes` returns `super + [its own scope]`, instead of
+  re-implementing the lookup and recognising a miss by the exception's
+  details. Later scopes are asked only on a miss; each scope must hold only
+  conversations the viewer may open, so nothing outside them becomes
+  reachable; and an error a scope raises is not rescued into a 404.
+
+### Fixed
+- **The dock's window count used the right plural form only in two-form
+  languages.** `dock_controller.js` picked `one` for exactly 1 and `other`
+  for everything else, so Polish, Russian, Ukrainian, Croatian or Serbian
+  (one/few/many, with 21 read like 1 in the East Slavic ones) and
+  Arabic-style zero/two read wrong. The dock now renders every plural form
+  the locale provides for `chats.dock.window_unread` (`zero`, `one`, `two`,
+  `few`, `many`, `other`; new helper `chats_plural_forms`), and the
+  controller picks one with `Intl.PluralRules` in the page's language
+  (`<html lang>`, else the browser's), reading a missing form as `other`
+  and falling back to the old rule where `Intl` is unavailable. The gem's
+  `en` and `es` keep `one`/`other`; a host adds the forms its languages need
+  in its own locale files.
+- **Every live surface catches up on the broadcasts it missed.** Action
+  Cable has no replay, so a broadcast sent while a page's socket was down
+  (a laptop asleep, a backgrounded tab or Hotwire Native WebView, a network
+  blip) never reached it, and the inbox, a thread, the unread badge or the
+  dock could sit on old content until the next navigation. One shared
+  module, `chats/recovery` (pinned for importmap hosts, like the
+  controllers), now watches each surface's own
+  `<turbo-cable-stream-source>` and the page, and asks for what was missed
+  when the stream reconnects, when the page comes back after 10 seconds or
+  more hidden, when the network comes back online (it asks Action Cable to
+  check its socket at once instead of after its backoff, and catches up
+  anyway: after a short outage the socket can look open while what was
+  sent during it is gone) and when the page
+  is restored from the back/forward cache or from Turbo's snapshot cache (a
+  back navigation, a Hotwire Native stack pop). Never otherwise: a healthy,
+  visible page fetches nothing. A hidden page never fetches; what it missed
+  waits until it is seen. Triggers that arrive together make one catch-up,
+  and catch-ups are at least five seconds apart.
+- **A reconnect Action Cable never reported is seen.** When Action Cable
+  reopens a socket that went quiet (the half-open connection of a phone that
+  slept), it drops the old socket's handlers before its close event can
+  arrive: subscribers hear "connected" again and never "disconnected", and
+  the `reconnected: true` detail reaches only the first subscription
+  confirmed. Every confirmation after the first now counts.
+- **A page restored from Turbo's snapshot cache catches up.** It came back
+  as old as when it was left, with no request: a thread restored by a back
+  navigation missed every message sent since. Its stream sources are marked
+  as they go into the cache, and a restored one catches up once it is live.
+- **The inbox** reruns a refresh that arrived while another visit was
+  loading, which Turbo ignores (`Session#refresh` skips one while
+  `navigator.currentVisit` is set): a message landing mid-refresh was lost
+  with a healthy socket. A refresh no longer rewrites the field you're
+  typing in, no longer drops the search (see Changed), and a morph no longer
+  strips the stream source's `connected` attribute.
+- **The inbox refresh is durable.** `refresh_inbox_of` enqueues
+  `Chats::InboxRefreshJob` straight from the after_commit instead of calling
+  `broadcast_refresh_later_to`, which parked the refresh for half a second
+  in an in-process timer (`Turbo::Debouncer`) before enqueueing it, so a
+  deploy or a crash inside that window dropped it. At most one is queued
+  per recipient: while one is queued and hasn't started, it stands for
+  every write that commits before it runs (a short-lived marker in
+  `Rails.cache`, removed by the job as it starts, before it broadcasts), so
+  a burst is one job per recipient. A lost marker costs an extra job, never
+  a missed refresh, and the marker expires after two seconds. Only a
+  marker that is really there counts as "queued": a store that can't hold
+  it (RedisCacheStore answers nil when a write fails; any store may raise)
+  means the write queues its own refresh. Since another
+  write may count on a refresh whose enqueue is still in flight, a failed
+  enqueue is retried once, then the refresh is broadcast on the spot. Every
+  refusal goes to `Rails.error` (raised, `false`, or a job the adapter
+  declined), never up through the write that committed. The refresh
+  tag carries `method="morph" scroll="preserve"`, so the inbox morphs
+  whatever the host layout's refresh meta says, and no request id, since
+  it may stand for several requests' writes.
+- **The thread's catch-up asks on two cursors.** It sent only the newest
+  `updated_at` it had rendered and the server appended what was created
+  after it, so a message created at 10:15 and missed, while a bubble on
+  screen was edited at 10:20, never came. Now `after=` (the newest creation
+  on screen) decides what is appended and `changed=` (the newest change)
+  what is replaced, and both scopes split on the same creation cursor
+  (`created_after` / `created_through(…).updated_after(…)`). Each cursor is
+  a moment to the microsecond plus the ids on screen at it (`after_ids=`,
+  `changed_ids=`): a message missed in the very instant of one on screen,
+  or a change missed inside the same millisecond as one on screen (the old
+  cursor rounded up to the millisecond), is no longer lost. The cursors
+  are reconciled moments: a complete render sets them (the page, a window,
+  a history re-render), and so does a catch-up that arrived (its
+  `chats_caught_up` action); a live bubble never moves them, since it can
+  arrive after one that was missed (a message missed at 10:15, then one
+  live at 10:20). What arrived live is named instead, at most 200 ids
+  (`after_ids`, `changed_ids`, each id at most 64 characters); past that,
+  or with `full=1`, the history is re-rendered. Kept on the element
+  (`data-chats-reconciled`), so a dock window moved by a Turbo visit, or a
+  restored snapshot, keeps them. Each catch-up is bound to one render of
+  the thread (`render=`, echoed by the answer): an answer that arrives
+  after the page or a dock window rendered the conversation again is
+  dropped unrendered, and its cursors ignored — checked again by every
+  stream of it at the moment Turbo applies it, a repaint later, so a visit
+  or a window reload in between can't hand the old streams the new render.
+  A history re-render is followed by one more catch-up from its own
+  cursors once Turbo has actually applied it, however late that is, so a
+  message written while that page was being built isn't lost. Every
+  catch-up is bounded: a request with no answer after 15 seconds is
+  aborted (a fetch can hang across a network interruption, and would
+  otherwise stand in for every later one), a thread has at most one answer
+  waiting for Turbo (a newer one, or the thread going away, drops the
+  older one's leftover streams and stops watching for them — going away
+  for good: a dock window Turbo carries across a visit is off the page
+  until that render ends, which a host's asynchronous `turbo:before-render`
+  can make last many tasks, and keeps its answer, decided only once every
+  `turbo:before-render` has had its `turbo:render`, paired first in, first
+  out; a render that runs past 10 seconds stops holding things up but stays
+  paired until its own end, and one that never ends is forgotten after a
+  minute), and only the
+  answer's own streams are guarded (`data-chats-answer`), never a host's
+  stream rendered at the same moment. A thread whose catch-up didn't apply,
+  for any reason (its page rendered it away, the request failed, Turbo
+  never got to it), is marked behind (`data-chats-stale`, on the thread
+  element itself, so the mark travels with the dock and can't be
+  forgotten while the thread exists) and catches up again when it
+  connects, on its stream's confirmation and after every page render,
+  through the same coalescing and 5-second spacing as every other trigger;
+  only the answer of the newest catch-up clears it (they are numbered on
+  the element, `data-chats-catch-up`), so an older answer that applies
+  after a newer one failed leaves the thread marked; and nothing older
+  than the newest catch-up that has applied (`data-chats-applied`) may
+  apply after it, so an older answer arriving last can't put back older
+  bubbles, read state or cursors. A catch-up always gets an answer built
+  after it was asked: the same request asked in the same instant is made
+  once, but asked while it is already on its way, it is made once more as
+  soon as that one has its answer from the network (never waiting on
+  Turbo to apply it), for everyone who asked meanwhile, each keeping its
+  own `when` and its own outcome. An answer Turbo hasn't applied 10
+  seconds after it joined the page is cancelled (its callers settle, and a
+  thread stays marked behind), and neither a caller's hook that throws nor
+  a stream that fails to render can leave an answer half-applied or its
+  callers waiting. An empty
+  thread, which used to ask nothing, asks from the epoch: its first message
+  may be the one it missed.
+- **The thread's catch-up is complete.** `GET /:id/refresh` now also
+  replaces the read state (a read the stream missed left "Sent" where it
+  should say "Seen"), catches reactions (a reaction now moves its message's
+  `updated_at`, with `update_columns`, so the bubble is not broadcast twice),
+  and, under `deletion: :hard`, lists the messages that still exist from the
+  oldest rendered bubble on (`from=`), so the thread removes the ones that
+  are gone (the `chats_prune` stream action). Catching up still reads
+  nothing.
+- **The unread badge and the dock catch up.** The viewer's own
+  `chats_unread_badge` is wrapped in a `chats--unread-badge` controller (a
+  `span.chats-unread-badge-live`, `display: contents`, so it changes no
+  layout) that asks the new `GET /badge` for every unread badge on the page:
+  the nav badge and the dock's, with the count the badge streams send
+  (`unread_chats_count`). Someone else's badge stays live but doesn't catch
+  up. The dock fetches the same, and reloads its recent list; each open
+  window's thread catches up by itself. A message missed while offline
+  never pops a window open late.
+
+- **Both search forms are search landmarks.** `form_with … role: "search"`
+  rendered no `role` at all (`form_with` drops HTML attributes it doesn't
+  know unless they go through `html:`), on the inbox and in the dock.
+
+### Changed
+- A page now counts as having been away after 10 seconds hidden, not 60
+  (the inbox and the thread used 60).
+- A thread more than a page behind no longer gets a page refresh, which
+  cleared the composer's draft and, in a dock window, refreshed the host's
+  whole page: its history (`chats/conversations/_history`, inside
+  `#history_conversation_<id>`) is re-rendered at the latest page, the
+  composer untouched. An ejected thread whose scroller has no
+  `id="<%= dom_id(conversation, :history) %>"` keeps getting the page
+  refresh.
+- The inbox's search keeps its query in the URL (`data-turbo-action=
+  "replace"`, submitting to the inbox's own path), so a refresh re-renders
+  the same results instead of the unfiltered list. The dock's recent list
+  frame has `refresh="morph"`, so a reload keeps its scroll and its search.
+- New: the `GET /badge` collection route, the `chats--unread-badge`
+  controller, `Chats::InboxRefreshJob`, and `data-message-id`,
+  `data-created-at-us` and `data-updated-at-us` on every bubble, which no
+  longer carries `data-updated-at-ms`.
+- **If you wrapped the inbox in a reconciler of your own** (a
+  stream-reconciler controller around `turbo_stream_from … :chats_inbox`),
+  remove it: two on one page both fire, and the gem's covers what yours did.
+  **If you ejected the inbox**, keep the
+  `data-controller="chats--refresh-inbox"` element around its
+  `turbo_stream_from chats_current_messager, :chats_inbox` (an inbox without
+  it doesn't catch up), and add `turbo_action: "replace"` to the search
+  form's `data` and `url: request.original_fullpath.split("?").first`. An
+  ejected message partial (with only `data-updated-at-ms`) keeps the one
+  cursor it had (`since=`), and a hard delete missed while offline stays on
+  screen until the next load.
+
+## [0.5.0] - 2026-10-18
+
+The messaging dock. LinkedIn and Steam keep your conversations in small
+windows in the bottom-right corner while you go on using the app; one line
+in a layout, `<%= chats_dock %>`, now does that. **No migration.** The dock
+is opt-in, but a few things change without asking, all under Changed: a
+conversation with no messages is no longer listed, a direct thread the
+host's policy no longer allows says so up front, a hover prefetch no longer
+reads a thread, and the thread body moved into a partial.
+
+### Added
+- **`chats_dock`**, the messaging dock: `aside.chats-dock`, fixed to the
+  bottom-right corner, holding the floating windows (`#chats_dock_windows`,
+  newest nearest the panel) and the panel. The panel is a `<details>`: its
+  header is the bar (the viewer's avatar, "Messages", the unread badge),
+  and open it has the inbox's search, the viewer's most recent inbox rows
+  (stacks, verified badges, a bell-slash on muted ones, previews, unread
+  counts) and "See all messages". It opens without JavaScript, and its
+  rows, search and links are real links and forms. Options: `windows:` (3),
+  `recent:` (10), `launcher:` (true; false drops the phone's round button
+  for a host whose own nav opens the sheet) and `everywhere:` (see below).
+  Renders nothing for a signed-out visitor and nothing on the engine's own
+  pages.
+- **It survives Turbo visits, per viewer.** The element is
+  `data-turbo-permanent`, so its windows, drafts, scroll positions and
+  subscriptions ride along from page to page. Its id names the viewer
+  (`chats_dock_<messager key>`), so a visit that lands on another
+  account's page (a sign-out and sign-in, an account switcher) never
+  matches it, and every window carries its viewer and is dropped on connect
+  if it names someone else. Because the server can't remove a permanent
+  element from the next page, the dock also hides itself on any page with
+  `data-chats-dock-hide`; the engine's inbox and thread roots carry it.
+  `everywhere: true` renders the dock on the engine's pages and ignores the
+  attribute.
+- **Floating windows.** A window is a turbo frame
+  (`dom_id(conversation, :window)`) loading `GET /:id?window=1`, which,
+  from inside a frame, renders the same thread body as the page, rooted at
+  `.chats-thread.chats-thread--window` (never `.chats`, the full-page
+  shell), under a compact header: a title button (avatar, name, verified
+  badge, subject, the waiting count) that minimizes it, the
+  `conversation_header_actions` slot in a ⋯ menu with the page's locals
+  (`blockable:` included), ⤢ for the full page, – and ×. Until the thread
+  arrives, and if it can't, the window shows the same header over
+  "Loading…" or "Couldn't load this conversation." with "Try again"; a 404
+  (left, blocked) closes it, read from the response before Turbo acts on
+  it (an error page carrying `turbo-visit-control`, as Rails' own do, would
+  otherwise take the whole page with it), keeping what was typed in it; a
+  5xx shows the failed shell. An empty conversation's window says "Say
+  hello to …". The dock never opens a window for a conversation the page itself
+  shows (the streams address the thread's DOM ids, which must exist once).
+- **What fits.** `min(windows, floor((viewport − 312) / 344))` windows beside
+  the panel: two at 1280px, one at 768px, three from 1344px. Opening one
+  more closes the least recently used window that isn't in use. A window in
+  use (it has the focus, or unsent text) is never closed to make room: it
+  folds to a 104px header (avatar and ×, `--chats-dock-squeezed-width`)
+  beside the new one. Two limits are absolute: never more than `windows:`
+  windows, folded ones included, and never wider than the viewport beside
+  the panel. An open that can't fit even with every window in use folded is
+  declined, changing nothing, and the row's link (or the `dock: true`
+  button) opens the conversation's page instead; a pop-up just doesn't
+  happen. Unfolding a folded window (its title, a row, a repeated `dock:
+  true`) makes room exactly as an open does, and when it can't, the window
+  stays folded. Narrowing the viewport closes what isn't in use and folds
+  what is, the focused window last; when even a row of folded headers is
+  too wide, it closes the least recently used windows in use too, keeping
+  their unsent text, and announces nothing. A window the viewer closes
+  keeps its unsent text for when it comes back. Every way a window leaves
+  the dock (closed, evicted, declined, gone for the viewer, shown by the
+  page, another viewer's) goes through one path that keeps the draft and
+  resyncs the rows and the phone sheet.
+- **Reading waits for the viewer.** A window never reads on render. A
+  minimized window never marks anything read, and a window that popped
+  open, or came back after a reload, marks messages read only once the
+  viewer focuses it, presses in it or scrolls it: the dock sets
+  `data-chats-minimized` and `data-chats-active` on the window and the
+  thread controller obeys them, checking again when its delayed read fires
+  (state, not geometry: a folded window's scroller also loses its padding,
+  but a size check alone is never trusted). A window the viewer opened
+  is engaged from the start. The thread page has no gate and is unchanged.
+- **Live, server-driven.** A new per-messager stream,
+  **`[messager, :chats_dock]`**, gets one render per participant per event
+  (`chats/dock/_update`): the dock's badges (the nav badge's count) when
+  the count moves, and a signal template (`chats/dock/_signal`). The signal
+  reloads the recent list, debounced, for every participant, the sender and
+  edits and deletes included. For a message the participant would be
+  notified about (`Participant#notifiable_for?`: not theirs, not muted, not
+  a headless seat) it also names the conversation, the sender and the
+  unread count there. The dock then pops that conversation's window open,
+  waiting with the accent header and its count, and announces "New message
+  from …" in a polite live region (at most once per conversation every 30
+  seconds, never for the window you're typing in). The pop-up only happens
+  in dock mode, never moves the focus, never for a conversation the viewer
+  closed in the last five minutes, and never by closing a window someone is
+  using; with no room, there's no pop. **The signal names a conversation
+  only to a participant who can see it** (`messager.chats`, so blocks and
+  `inbox_scope` apply), because the dock's list and window refuse anything
+  else. The badges stay truthful either way. No polling.
+- **Memory.** Per viewer in `localStorage`: `chats:dock:v1:<messager key>`
+  (which windows, minimized or folded or not, when each was used, the
+  recently closed ones and the panel) and `chats:draft:<messager key>:
+  <conversation id>` (unsent text, saved as you type and whenever a window
+  goes, by any path, a refused or missing one included, and before a
+  failure (5xx, network) replaces the window's content; restored the moment
+  the window's composer appears, cleared on send, kept seven days). A saved
+  draft goes back only into an EMPTY composer: if something was already
+  typed there, it stays, and the saved draft is never replaced by anything
+  shorter, so neither text is lost. A reload restores the
+  saved arrangement as it was, folded windows included, up to the cap, then
+  fits it to the width there is now by the resize rules; none of them is
+  engaged. The panel comes back in dock mode only, and the phone's sheet
+  always starts closed. Every access is guarded,
+  so a browser that refuses storage only means forgetting.
+- **Phones.** Under 700px wide or 500px tall the closed bar is a 56px round
+  launcher, the open panel a full-screen sheet, and a conversation one
+  full-screen window with ← back to the list, sized to the visual viewport
+  so the composer sits on the keyboard. The list behind a window is `inert`
+  until Back, which returns the focus to it. The sheet makes the rest of the page
+  `inert` (the siblings of the dock and of each of its ancestors, so a
+  layout that wraps the dock never inerts the sheet) and stops it scrolling. Inputs are 16px, so iOS doesn't zoom.
+  Messages never pop a window on a phone. The layout is one media query, so
+  it applies before JavaScript connects and without it; the controller reads
+  the same query.
+- **Keyboard and screen readers.** Escape unwinds from the inside out: the
+  thread's popup or photo, an edit (the composer now cancels one on
+  Escape), the ⋯ menu, then the window (minimized, focus to its title), the
+  panel (closed, focus to the bar); on a phone, the window back to the list,
+  then the sheet closed. Focus goes into a window only when the viewer
+  opened it: its composer on a desktop, ← on a phone. Close returns the
+  focus to whatever opened the window. Focus rings are inset, the history
+  scroller is focusable, the badge is not a live region, and the bar reads
+  "Messages, 3 unread" from its own text.
+- **`chat_button_to(other, dock: true)`** posts `dock=1`, and
+  `ConversationsController#create` answers a Turbo Stream that appends the
+  conversation's window to `#chats_dock_windows`. When that conversation is
+  already in a window, the dock focuses it instead of letting the append
+  replace it, so nothing typed is lost. It belongs with `chats_dock`: on a
+  page without the dock the stream has no target and does nothing. Without
+  Turbo, and without `dock`, the redirect is unchanged.
+- **`chats_dock_opener(conversation)`** and **`chats_dock_toggle`**: data for
+  any link on the page to open that conversation's window, or the dock's
+  panel (the sheet on a phone). They stay plain links without a dock or
+  JavaScript. **`chats_muted?(conversation, viewer)`** reads the viewer's
+  seat.
+- **`GET /dock`** (`dock_conversations_path`), the panel's list:
+  `Chats::Inbox` with `?q=` and `?recent=` (1 to 50), rendered into the
+  `chats_dock_list` frame without a layout. The inbox answers a request from
+  that frame (the dock's search, which submits to the inbox so that it
+  lands on the full inbox's results without JavaScript) with the same list.
+- **`Chats::Inbox.for(viewer, limit:)`**: how many rows come back
+  (`config.inbox_limit` by default, never more). A smaller limit is a
+  smaller query; a search still looks through the whole `inbox_limit`
+  window.
+- **`Chats::Conversation.with_messages`**: conversations that have at least
+  one message, system messages and tombstones included (`last_message_id`
+  set, which the denormalized pointer already gives). It doesn't mean a
+  person wrote there: a thread holding only a system note is listed.
+- **The `dock_panel_footer` slot** (receives `viewer:`): your own link next
+  to "See all messages".
+- **Theming.** The dock's variables are declared on `:where(.chats-dock)`,
+  not `:root`, so a host re-pointing `--chats-bg` or `--chats-accent` on the
+  dock reaches them: `--chats-dock-z` (40), `-offset` (bottom clearance),
+  `-inset` (right edge), `-gap`, `-bar-height` (48px), `-panel-width`
+  (288px), `-panel-height`, `-window-width` (336px), `-window-height`
+  (480px), `-radius`, `-bg`, `-header-bg`, `-hover` (`#f9fafb`: muted text
+  at 4.63:1, where `--chats-surface` gives 4.39), `-edge`, `-shadow`,
+  `-unread-bg` / `-unread-text` (the accent pair), `-focus`,
+  `-title-font`, `-launcher-size`, `-duration`, `-ease`, plus
+  `--chats-safe-top/right/bottom/left` on `:root`. Nothing leaves a
+  transform, filter or `contain` on the dock or an expanded window, which
+  would trap the thread's fixed popup and photo preview inside it; entrance
+  animations end at `transform: none`, and `prefers-reduced-motion` turns
+  them all off. Strings under `chats.dock.*` in `en` and `es`. The
+  controller is pinned as `controllers/chats/dock_controller`, and
+  `rails generate chats:views` has a `dock` group (`app/views/chats/dock/`).
+
+### Changed
+- **A conversation with no messages is never listed.** Opening a
+  conversation (`chat_with`, the Message button) creates it, and until now
+  the inbox listed it straight away as a "No messages yet" row. Every list
+  now reads through `Chats::Conversation.with_messages`: the inbox rows,
+  a stack's rows and its `open_count` / `unread_count`, search, the
+  `?with=` view and the dock. **If your inbox showed rows for threads
+  that were opened and never used, it no longer does.** The conversation
+  still opens when addressed directly (the thread page and its dock
+  window work), because `Messager#chats`, the relation every engine lookup
+  authorizes through, is unchanged; use `chats.with_messages` for lists of
+  your own. `unread_chats_count` already agreed (an empty conversation has
+  nothing unread).
+- **A direct thread nobody may write in says so up front.** When the host's
+  `can_message` policy no longer allows the pair, or the other account is
+  gone, the thread (page and window) shows "You can't message this person."
+  in the composer's place, through the locked-composer box (same id; the
+  `locked_composer` slot gets it as `notice:`), instead of a composer whose
+  sends fail. `_locked_composer` takes an optional `notice:` local.
+- **A hover prefetch never reads a thread.** Turbo 8 prefetches a link when
+  the pointer rests on it, and `ConversationsController#show` used to read
+  the thread on that request, so hovering an inbox row cleared its unread
+  badge. A request with `X-Sec-Purpose: prefetch` no longer reads; the
+  visit does. The dock's list turns prefetch off altogether.
+- **The thread body moved into `chats/conversations/_thread.html.erb`.**
+  It holds the `chats--thread` element and everything inside it except the
+  header: the `turbo_stream_from`, the scroller with the older-pages frame
+  and the «new messages» line, read state, typing, the long-press popup,
+  the photo preview and the composer. It renders as a partial layout whose
+  `yield` is the header, with locals `conversation:`, `messages:`, `more:`,
+  `first_unread_id:`, `counterpart:` and `window:`. `show.html.erb` is now
+  its header wrapped in that partial. The page's DOM gains
+  `data-chats-dock-hide` and `data-chats--thread-read-pending-value="false"`
+  on its root and `tabindex="0"` on the scroller. **If you ejected
+  `show.html.erb`**, your copy keeps rendering the page as before; add
+  `data-chats-dock-hide` to its root if you render the dock everywhere.
+  Dock windows render the gem's `_thread` (or yours, if you eject it), so a
+  restyle that lives in your `show.html.erb` doesn't reach them: move it
+  into an ejected `_thread.html.erb` to style both.
+- **Grouped inbox rows cost two queries in all.** A stack's `open_count` and
+  `unread_count` were two aggregates per stack; they are now two grouped
+  queries for every stack the inbox shows, so an inbox (or a dock) with many
+  stacked counterparts stays constant-query.
+- The unread badge partial (`chats/shared/_unread_badge`) carries
+  `data-chats-unread-badge`, the mark every unread badge has, the dock's
+  included. Its broadcast still targets `#chats_unread_badge`, so a badge
+  ejected earlier keeps updating unchanged. Add the attribute if your own
+  CSS or JS wants to find every badge.
+- The inbox row partials (`_conversation_row`, `_group`) take an optional
+  `dock:` local that marks their link as a dock opener, and a direct or
+  group row shows the bell-slash when the viewer muted it. Rows ejected
+  earlier still work in the dock; they navigate instead of opening a
+  window.
+- **The composer's fields have per-conversation ids**
+  (`dom_id(conversation, :message_body)`, `:message_files`), instead of
+  `form_with`'s `message_body` / `message_files`. A page can now hold
+  several composers, and Turbo restores focus by id after rendering a
+  stream, so a shared id moved the cursor into another window's composer.
+  CSS or JS that selected `#message_body` should select `.chats-composer__input`.
+- The long-press Edit event (`chats:edit-message`) now carries its thread
+  element, and a composer only starts editing for a message of its own
+  thread, since a page can hold several threads now. The check lives in
+  the controller, so ejected composer views get it too; a host that pinned
+  its own `composer_controller` reacts to every thread's Edit, as before.
+- The dummy app has a real importmap setup (Turbo, Stimulus, the stock
+  eager loader) and a host home page with the dock, which is how the
+  screenshots were taken. `test/system` measures the dock's rendered layout
+  in a headless Chrome (capybara and selenium-webdriver join the test
+  bundle). Under CI (`CI=true`) Chrome is a prerequisite: the tests fail
+  when it can't start, and the workflow checks for it first; on a machine
+  without Chrome they skip. The suite prints how many ran.
+
 ## [0.4.2] - 2026-10-17
 
 ### Changed