[lavaman131]

Summary

Follow-up to #792 (quiet machine status, plain machine-first copy, one offline notice) and #793 (quiet restarts). It does four things, in twenty-three small commits:

1. While the page's offline notice shows, the composer says nothing about replies being unavailable, draws no "Reconnecting" line for a /research the connection could not take, no "Message not sent" line for a send that failed (the connection's or a server's refusal), no machine state for a person with no machine button, and no word about a machine on a workflow run's card or in the page's live region for a screen reader, so a lost connection is one notice and not two. A refusal and a machine state come back, as they were, when the connection returns; the others are gone with it.
2. Every string a person reads that Quiet the machine status, and make a lost connection calm #792 listed as left alone now speaks plainly: Chopin where it said the Planner, the machine where it said attached, detached or held. Codes, wire formats, routes and stored data are unchanged.
3. Both of Restart the server without anyone noticing: ready and live checks, a quiet reconnect, and a reload after a deploy only when it is safe #793's loose ends: the idle dialog warm-up no longer raises a page error while the server is away, and a refusal ends a restart's quiet period cleanly.
4. The machine status no longer names another person's machine, nor another of the person's own that the document does not run on, nor a machine a newer word no longer supports, keeps the last known state through a restart however long the machine takes to return, says when an offline machine was last seen, and lives in one place; Chat no longer says that the machine disconnected or came back.

Decision and Decisions stay Chopin's word for its tab, its cards and its controls. That was decided by the user against the research this work did (below). The branch contains no Decision to Question rename.

Key screenshots

What changed

1. One offline state

A document whose agent is off (AGENT=off) drew its own info strip above the composer ("Chopin unavailable") beside the page's offline notice, so two strips about "unavailable" showed at once and the composer was a different size online and offline.

• While useOfflineNotice says the notice is up, the composer says nothing of availability. The strip comes back by itself with the connection, with nothing to say it did.
• Online, it is told plainly and without a system name: Replies are off on this server., and after a message addressed to Chopin, Replies are off on this server. Your message went to the people here only.
• A send the connection cut off used to draw "Message not sent. Check the connection and try again." with Retry above the composer, a second alert beside the offline notice that then stayed after the connection returned, until the person typed. The composer now keeps whether a failed send was the connection's, and draws no strip for one while the connection is down (the offline notice, and the moments before it shows, so a blip says nothing); the strip is also gone when the connection returns. The draft stays in the composer for the person to send again. How a message is sent, retried or refused, and its timing, are unchanged.
• A server's refusal of a send (and a validation error, and the refusal that a machine is still being connected to) is told by its strip while the connection is up, but gives way to the offline notice while it shows: no strip is drawn, the stored failure is kept, and the same strip with the same words is back when the connection returns, until the person sends again. How a send is refused, retried, cleared or timed is unchanged, and the refusal about a machine still being connected to keeps its words, its wait and its clearing (they belong to branch stage1-invisible-deploys); only whether a failure is drawn beside the notice changed. New specs on desktop and a 390 px phone.
• A person with no machine button (a teammate with no machine, or a phone whose top bar an open child has taken) reads the machine's state in a strip above the composer, which used to stay beside the offline notice, stale, since the page cannot hear the machine while it is offline. That strip is not drawn while the notice shows, and returns by itself, with the state then known, when the connection does. Online it stays: such a person has no other place to read the state (item 4). New specs on desktop and a 390 px phone.
• A workflow run whose machine had dropped keeps the server's last frame through a lost connection, so its card used to go on saying "disconnected", "Last reported running. It carries on when the machine reconnects." and "Pause when the machine reconnects" beside the offline notice, on desktop and on a phone. While the notice shows, the card says nothing of the machine: it reads as the run last reported ("running", "paused", "waiting on Decisions"), with a plain Pause, no note, a still neutral ring instead of the warning one, its clock where it was, and its place and controls as they were (a Pause where it had one, no Resume it cannot deliver, its way to Decisions). The status word is not announced as it changes. The words come back with the connection, as the run's state then is. New specs on desktop and a 390 px phone.
• The page's one live region for a machine's state (the sentence a screen reader hears as a state begins) kept the last sentence it had said beside the offline notice, and a state released after the socket had dropped (a list read started after a word, answering after the connection was lost, whose grace then ran out) was said beside it too. While the notice shows, the region is empty and says nothing new, whatever the state does meanwhile, so a screen reader hears the connection alone. It remembers what it last said, so a state that carried on through the loss is not said again when the connection returns, and a different one is said once. The run-card spec now also checks the region and the words "is offline", "Connecting", "Your work is kept" and "No machine" in the page's text, labels, titles and live regions, and two new specs cover a state that carried on through the loss and a state released after the socket dropped; all on desktop and a 390 px phone.
• A /research pressed while offline used to draw "Reconnecting… try again in a moment" with Retry above the composer, a second strip about the same connection. While the offline notice shows, that line is not drawn (the draft stays in the composer), and when the connection returns the stored block is cleared, so it neither comes back as a stale strip nor reappears in a later blip. A research request refused for any other reason is told as before. New specs on desktop and a 390 px phone.
• The two outage specs that compare the composer's size before and after ran against a server whose agent is off, and the always-present strip hid exactly this. They now turn the agent on. New specs show exactly one notice on desktop and on a 390 px phone.

2. Plain words in the strings #792 left alone

The rule is the user's: no Planner, attach/attached/detach/detached, held or @chopin in what a person reads, except where the person types the mention themselves, and no Decisions inside text about a machine and its connection.

• Chat's system lines from the server: the lines that record a person's own action ("@mona stopped Chopin and paused its workflows.", "@mona asked Chopin to stop. Its machine is disconnected, so its workflows will pause when it reconnects."), and the turn failures that reach Chat ("Chopin's reply failed. Try again.", "Chopin's owner is unavailable", "The machine's connection dropped during this reply. Its workflows and open questions are kept; ask again once it has reconnected."). Chat has no line for the machine disconnecting or coming back (item 4).
• The agent connection's refusals and failures a person can see: "Connecting to this document needs push or administration access to ...", "mona is connected to this document. A document has one agent connected at a time.", "This document's connection was released, so mona is no longer connected. Connect again to resume.", the sign-in and paired-machine variants, and "The machine did not start the session." and its siblings. The sentence that ends the three "connected" variants says "one agent connected at a time", not "one connection": many people are connected to a document, and what is single is its agent. Error codes and close codes are unchanged.
• Run cards: "It carries on when the machine reconnects", "Pause when the machine reconnects", and for a disconnected run that was waiting on Decisions, "Last reported waiting for people. Answers reach it when the machine reconnects." (that note is text about a machine's connection).
• Composer hints and the empty Chat: "Sends to Chopin, which will reply", "Sent to people here. Type @ to ask Chopin", "Use @ to ask Chopin, or # to point at a document."
• Busy labels: "Chopin is working", "Chat, Chopin working", "Document, Chopin writing"; the agent's face and "Chopin suggested" in a card's evidence; "The background job could not be retried."
• The Machines page and Build plan's setup: "Can reply" and the sharing sentence ("... replies, builds and runs then happen here ..."); the setup popover says "Connect a machine", "Agent command" and "Open your agent and connect this document."
• Design audit captions, apps/web/DESIGN.md and the docs that quote any of these.

One pattern serves every test, in @chopin/protocol/plain-words. INTERNAL bans the Planner, attach and detach in every form, held and @chopin in anything a person reads. INTERNAL_IN_STATUS also bans Decisions and applies only to text about a machine and its connection. status-copy.test.tsx applies the strict one to every status, strip, notice, refusal and Build reason it already walked, and the general one to everything else this change touches. Its self-test shows that the general pattern flags "Planner" and not "Decisions", and the strict one flags both. The server tests use expectPlain, expectPlainStatus and their Lines variants on the lines and refusals they already assert exactly. There is no second checker.

3. #793's loose ends

• dialog-prefetch: the sidebar's idle warm-up of its lazy dialogs and the Search list was an uncaught dynamic import. While no server answers it failed with Failed to fetch dynamically imported module and nothing on the page showed it. It is caught where it is started, one promise covers the later chunks too, and the restart e2e no longer carves it out: both cases that read page errors now assert there are none.
• A refusal inside the restart's quiet period (a 403 Chopin marked as its own) set the status to denied, but the quiet timer still raised onOutage when it ran out and restarting stayed true. A refusal now clears both. New case in wire-quiet.test.ts, red first on the old code (restarting stayed true, and the outage arrived at 5 s).

4. Status defects measured on a hosted deployment after a restart

After a reconnect, the machine button and the composer's top edge named another person's machine for about a second and a half before the document's own, and said "no machine" for a moment first; and through a deploy that took the machine minutes to return, the page said "No machine is connected." after 1.5 s.

• The name comes from the document's own machine and no other: the one the machine button names (the person's choice, else the one Default machine uses now). A machine that is not the document's, a teammate's or another of the person's own, is never named, and a teammate's is told only as "@login's machine". While the person's machines are loading, or the two snapshots disagree, the status says nothing rather than guess. The machine list the page polls is also checked against the page's own connection: it names a machine for the account whose Planner it describes (its login, or the viewer's own where the machine is theirs), and that name is lent only to a word from the same account. A list read before another account's Planner took the document over used to lend its machine's name to that account's dropped, starting and failing Planner ("Box A is offline", "Connecting to Box A", "Can't connect to Box A", none of it true of them); and a list read before the person set the document to run on Box B, still describing their own Box A, did the same to their own Planner. Both now name nothing until the list agrees. The list is also never older than the word it names a machine for: the wire carries no machine id, so the page reads the list again on every word, and a word that is starting or has dropped names nothing, by name or by login, until a read that began after it has answered. Meanwhile the status says nothing of the machine, however long that takes: what it said of an older word does not stay, so a document set to run on Box C no longer reads "Connecting to Box B" from a list older than the word, and a read that fails or a hidden tab leaves it empty, never stale. What it had shown is remembered through that wait only so that the same state, naming the same machine, returning once the machine is named is drawn at once (it does not wait out its grace again). It is never drawn in place of a different state: any other state that arrives after the wait is drawn by its own rules, so a machine being connected to, or no machine yet, draws nothing until it has lasted its 1.5 s, and a machine that had dropped is not redrawn for that time (a document moved from Box B to Box C read "Runs on Box C. Box B is offline." for the length of the grace, then "Connecting to Box C"), while a state a person can act on, and every clearing, is drawn at once. A transition with no wait keeps the last state through the next one's grace, as before. The page's one live region falls silent in the gap and does not say that state again: it says a state once as it is entered, and again only after the Planner was healthy or gone, which is how a word that repeats a state with one more failed attempt is announced once, not twice. A list that agrees with itself is not enough, since it can have been read before the Planner moved. The machine is named by its id being the document's own, never by who owns it.
• The moment: "Connecting to ..." and "No machine is connected." are said only once they have lasted as long as a lost connection does before the page speaks (1.5 s). The last known state stays until then, so the states a restart passes through are never shown or announced. What a person can act on, and every clearing, goes at once, and nothing confirms recovery.
• Through a reconnect or a deploy the page keeps the last known state until it has a fresh one, however long the machine takes. A server that has just started tells none to everyone who connects until a machine returns, so the first none after the connection comes back is the new server's placeholder, not news of the machine. The page keeps what it showed (healthy, away, whatever it was) until another state arrives; a none told after any other state (a machine removed while the page is connected) and a page's very first none are still said. It uses the wire's existing signals (the reconnecting status and each Planner word) and changes no wire; only the status is held, and the Planner's real state is read as before. A restart's passing states and a six-second none show nothing new on desktop or a 390 px phone.
• Chat says nothing of the machine's connection. The lines "The machine disconnected. Its workflows and open questions are kept, ..." and "The machine reconnected and carries on." are gone, with the sentence about a Stop it had not confirmed that rode on the first: the machine button, its menu and the run cards carry that state, and nothing confirms it came back. What stays are the lines that record a person's own action (Stop, Pause, Resume), which say what will happen when the machine reconnects and so confirm nothing, and a reply's own failure. Run cards, sessions and open questions are published as before.
• Last seen: an offline machine says when it was last seen from the machine's own time: "Build box is offline. Last seen 10:31 AM." ("Your work is kept." remains where no time is known).
• Where it lives: the machine button and its menu carry every state. The composer's top edge carries machine state only for a person with no machine button: no machine paired or shared, a title bar that does not show one, or a phone whose top bar an open child has taken. Such a person has nowhere else to read it, so the strip is a fallback and draws the reason in full, except while the offline notice shows, when it says nothing (item 1). For everyone else it says nothing, so a state is told in one place, as a contact's is in a chat.
• Deliberately not done: the 30 s a message to a machine still being connected to waits before it is refused, and the red refusal strip ("Still connecting to @mona's machine. Try again in a moment.") staying after the machine connects. Both belong to the Stage 1 run on branch stage1-invisible-deploys, which removes that refusal and replaces it with queued messages that carry delivery marks. This change leaves the strip's words, its wait, its clearing and the send path unchanged (the strip is only not drawn while the offline notice shows, item 1), and changes no behaviour of how a refusal is handled, of how the transcript renders or of the wire's messages: only the words of some refusals and lines (item 2), and the browser's reconnect logic in item 3.

The messaging standard followed

The user's instruction: Chopin's Chat, machine status and connection handling should behave like WhatsApp and Slack. The machine that runs a document's agent is the other person in a chat; the person's own connection is WhatsApp Web's own connection. Applied here:

• Presence in one place, as WhatsApp's chat header carries it ("online", otherwise "last seen" with a time; https://faq.whatsapp.com/419827870318306): the machine button says nothing extra while connected, says "offline, last seen" with a time when away, and shows "connecting" only after a grace period.
• No flicker. Through a reconnect the page keeps the last known state until it has a fresh one, however long that takes, never flashing "No machine is connected" or another machine's name.
• The name comes from the document's own machine, the one the button names, and when it is not known yet, nothing is said.
• The person's own connection is one notice, like WhatsApp Web's "Computer not connected" (https://faq.whatsapp.com/852892549070029) or Slack's one grey banner (https://slack.com/help/articles/205138367). Nothing else repeats it.
• Anything tied to a state clears when the state clears, with no "Back online": Chat no longer says the machine reconnected, and a research request's "Reconnecting" line and a cut-off send's "Message not sent" line go with the connection that caused them, while a server's refusal of a send and a machine's state wait out the offline notice and come back as they were.
• The composer's top edge only for a person with no machine button, because without it they have nowhere else to read the state, and not beside the offline notice, since the page cannot hear the machine then.

Not in this change: the first rule of the standard, that a sent message is never refused because the other side is away but waits with a delivery mark (https://faq.whatsapp.com/5155925751185676). That is the queued-message work on branch stage1-invisible-deploys, which this change does not pre-empt.

The Decisions tab: kept, against the research

The brief asked for the tab to be named by what Linear, Notion, GitHub and Figma call open questions awaiting a person's answer. The research found Questions, and the tab and its cards were renamed to it. The user then ruled that Decision and Decisions stay Chopin's product noun (tab, cards, "Save decision", "Decision changed", counts, accessible names, docs, tests). The rename was undone, and this branch has no Decision to Question rename. The research stands here as a record, overruled:

• Figma Make, 30 Apr 2026: "Question cards: Choose between structured options in chat before Make moves forward, each with a short description of the tradeoff." (https://www.figma.com/release-notes/archive/), which is what a Chopin card is.
• Notion Plan Mode, 7 May 2026: the agent "asks clarifying questions and builds a detailed plan before acting" (https://www.notion.com/releases/2026-05-07).
• Linear's agent API calls a request for input an elicitation ("Requests clarification or confirmation from the user") and the session state awaitingInput, "visible to users" (https://linear.app/developers/agent-interaction).
• GitHub's Copilot app groups work waiting on a person under Needs input, described as "Decisions, reviews, and permission requests" (https://docs.github.com/en/copilot/how-tos/github-copilot-app/working-with-projects), so GitHub uses "decisions" as a plain word for one kind of item, not as a product term.

"Needs input" is a state, and Chopin's tab also holds answered cards, so "Questions" was the noun all four share. Chopin keeps Decision by choice. What follows from it is in the pattern: Decisions is banned only inside machine and connection status text, where it tells a person nothing about the machine ("open questions are kept", "waiting for people"), and is Chopin's word everywhere else.

Strings left alone, and why

• Tool names, error codes (planner-not-attached, ...), wire kinds and fields, routes, URLs, stored data, CSS classes, data-*, the dialect's Decision component, log lines.
• What the agent reads: prompts, tool descriptions and results, MCP tool text, job and decision follow-up instructions, the transcript it is shown, task instructions.
• Operator and CLI output: startup lines, HARNESS= messages, chopin connect flags and help, docs/chopin-cli*.md, the protocol-violation and state errors a client's own bug raises, the text told to a machine's connector when Chopin stops running a document there (printed in the owner's terminal), and the terminal setup guide behind "Setup guide".
• Background-job failure reasons, and "held for review" in the message-analysis overview, which only a development diagnostic (VITE_MESSAGE_ANALYSIS) shows.
• "Decision" as the product's word outside machine and connection text, including the investigation's own "Record decision" form, the device authorization's "Could not save your decision" and the sign-in page's plain-English "decision".
• The diagram gallery's wireframe sample (sample content in a development gallery) and e2e/source/*.native.ts (updated by search; no configuration here runs them).

Screenshots

Desktop and a 390 px phone for every changed surface, with each surface's shots opened and checked against apps/web/DESIGN.md (this round: the machine button after the move to Box C, the offline notice with the machine's state said before it, and the run card beside the offline notice, at both widths; the others at least for the files named first in each line, in the earlier commits). Not committed. Taken from the built client with CHOPIN_SHOTS, plus the design audit page. The empty Chat's, the busy labels' and the Machines page's "Can reply" shots come from temporary browser specs that are not part of this change, because no committed spec photographs those states; no defect was found.

• Offline notice alone, and the replies-off strip online: agent-off-desktop-offline.png, agent-off-desktop-online.png, agent-off-phone-offline.png, agent-off-phone-online.png.
• The machine button's states and menus: planner-starting-*, planner-connecting-after-grace-*, planner-names-own-machine-*, planner-names-no-machine-*, planner-failing-*, planner-none-button-*, planner-attached-*, each as -desktop.png and -phone.png, and for last seen machine-offline-last-seen-desktop.png and machine-offline-last-seen-phone.png.
• The composer's top edge for a person with no machine button: planner-starting-teammate-*, planner-failing-teammate-*, planner-none-*, link-drop-disconnected-desktop.png, link-drop-disconnected-chat-desktop.png, link-drop-disconnected-phone.png; and the same person's page while offline, with the one notice over a bare composer, and once the connection is back, for each state the strip tells: no-button-{connecting,failing,away}-{offline,online}-{desktop,phone}.png.
• A disconnected run card's note: the link-drop-disconnected-* files above; and the same run while the connection is lost (the one notice, the card reading as last reported with a plain Pause, no note) and once it is back (the words returned): run-card-offline-desktop.png, run-card-offline-phone.png, run-card-online-desktop.png, run-card-online-phone.png.
• The empty Chat's hint: empty-chat-hint-desktop.png, empty-chat-hint-phone.png.
• Busy labels: busy-labels-open-desktop.png, busy-labels-closed-desktop.png, busy-labels-document-phone.png (the Chat tab's spinner and its accessible name "Chat, Chopin working").
• Machines page: can-reply-machines-table.png ("Can reply" under an agent), can-reply-phone-machine-detail.png ("GitHub Copilot CLI, can reply" and the sharing sentence), add-server-settings.png (the sharing sentence in the add-machine page).
• The machine button through a long none, and with a stale list: planner-slow-return-desktop.png, planner-slow-return-phone.png (six seconds after a restart, nothing new on the page), planner-stale-list-desktop.png, planner-stale-list-phone.png, and with a list that still describes another of the person's own machines, planner-stale-own-machine-desktop.png, planner-stale-own-machine-phone.png, and with a list read before the socket's word, planner-slow-list-desktop.png, planner-slow-list-phone.png (the button reading only where the document runs while the newer read is held back, with no state), and after the document moved from Box B, where the Planner had dropped, to Box C: planner-after-move-grace-desktop.png, planner-after-move-grace-phone.png (the button reading only "Runs on Box C", with its own green dot, while the machine being connected to waits out its grace, taken by a temporary copy of the committed case with one added screenshot step) and planner-settled-after-move-desktop.png, planner-settled-after-move-phone.png (the spinner once it has lasted).
• Chat and the run card through a dropped connection, without the removed lines: link-drop-connected-desktop.png, link-drop-disconnected-desktop.png, link-drop-disconnected-chat-desktop.png, link-drop-disconnected-phone.png, link-drop-reconnected-desktop.png, link-drop-reconnected-chat-desktop.png, link-drop-reconnected-phone.png (the run card and the composer's strip say it, Chat does not, and nothing confirms the return).
• The page's one offline notice over a bare composer, with the machine's state said just before the connection was lost and nothing of it drawn now: planner-silent-offline-desktop.png, planner-silent-offline-phone.png.
• A /research draft while offline, with the page's one notice and a bare composer: research-offline-desktop-offline.png, research-offline-phone-offline.png.
• A send the connection cut off, with the page's one notice and a bare composer holding the draft, and the same once the connection is back: cut-send-desktop-offline.png, cut-send-desktop-online.png, cut-send-phone-offline.png, cut-send-phone-online.png; and a server's refusal strip, which gives way to the page's one notice during a loss and is back, unchanged, with the connection: refused-send-desktop-online.png, refused-send-desktop-offline.png, refused-send-phone-online.png, refused-send-phone-offline.png.
• Build plan's setup popover ("Connect a machine", "Open your agent and connect this document."): the production popover opened on the audit's build blockers plate, audit-build-blockers-setup-desktop.png and audit-build-blockers-setup-phone.png. The browser fixtures have no document that offers it, so there is no shot of it in the running app.
• Design audit plates (one file per viewport-sized step down each plate): audit-chat-*, audit-workflow-runs-*, audit-navigation-*, audit-tabs-*, audit-typography-*, audit-icons-*, audit-loading-* and audit-build-blockers-*, each -desktop-N.png and -phone-N.png.

Verification

On the final head (tree 07fef13ce254), with the client rebuilt from it. Every browser run cited for a claim that a change works was made on that head with CI=1, so a port clash fails instead of reusing a server of another checkout. The red-first observations, also made with CI=1 and --retries=0 but on a client built from the code before a change, show only that a case fails for the reason it describes; they are labeled as such and are not evidence that anything works.

• bun run fix: no changes. bun run types: passed. bun run ci: passed (dprint, oxlint with 72 warnings and 0 errors, as on the base, tokens, design contract with 330 exceptions, design record, Impeccable with no new findings).
• GIT_CONFIG_GLOBAL=/dev/null bun test apps/web packages scripts e2e/focus-color.test.ts apps/server: 6999 passed, 9 skipped, 0 failed.
• CI=1 GIT_CONFIG_GLOBAL=/dev/null bun run e2e connection chat-mentions chat-phone chat-composer planner-attachment planner-picker machines machine-choice restart responsive-activity setup-agents hosted smoke implementation-launcher decision-evidence chat-references on the rebuilt client, once: 228 passed, 1 skipped (the live coding-agent build, which needs a live agent), 0 failed and 2 flaky that passed on retry, machine-choice "populated sidebar Default machine fits ..." at 1862x1039 and at 1280x600, each on a 10 s timeout waiting for the new project's link in the sidebar while the suite ran on 128 workers. Re-run alone with --retries=0 on the same client, the 10 cases that title matches passed 10 of 10.
• bun run design:behavior (CI=1): 22 passed on the first run (no cold dev-server miss).
• Initial JavaScript, against apps/web/bundle-budget.ts: 258,951 B raw and 81,994 B gzip in a local build; in docker build --no-cache --target build (the Dockerfile's client stage, Linux gzip) 258,947 B raw and 82,779 B gzip, against limits of 259,500 B and 83,000 B (221 B of gzip headroom). The limit is unchanged, and the code of the last commits lands in the lazily loaded workspace chunk: the entry chunk is the same size as before them. The temporary image was removed.
• Red first, each seen failing for the reason it describes with CI=1 and --retries=0 on a client built from the code before the change (these are the observations of the failing case, not claims that the change works): the machine strip beside the offline notice (browser, desktop and 390 px phone: the composer's strip was drawn beside the notice, "Expected 0, Received 1"; the unit case received the strip where none was expected), a refusal beside the notice (browser: two alerts where one was expected; the unit case received the refusal while the notice showed), a stale list naming another of the person's own machines (browser: "Runs on Box B. Connecting to Box A" where "Runs on Box B" was expected; the unit case received "Box A" where null was expected), a list read before the socket's word (browser, desktop and 390 px phone: "Runs on Box B. Box B is offline. Your work is kept." where the status was not to name Box B from that list; the unit case received "Box B" where null was expected), a run card beside the offline notice (browser, desktop and 390 px phone: the card still read "disconnected" under the one alert, so "plan-review, running" was not found; the unit case found "disconnected" and the note on an offline card), and a status held for an older word (browser, desktop and 390 px phone: "Runs on Box B. Connecting to Box B" where "Runs on Box B" was expected after the document moved to Box C). Taking the hold away alone failed the existing case "a Planner its machine keeps failing to start ... is announced once" with "Connecting to studio" said twice, and a client that withheld the status but forgot what it had shown and kept the live region's text through the gap failed that case and the case for a list naming a teammate's machine, which is why the announcement rule, the remembered state and the silent gap exist. A status redrawn after the gap (browser, desktop and 390 px phone, on the client of the commit before: after the list named Box C the button read "Runs on Box C. Box B is offline. Your work is kept." for the 1.5 s of the grace, where nothing naming Box B was to be read; the unit cases, run against the earlier behaviour, received the disconnected state where nothing was to be drawn). The live region beside the offline notice (browser, desktop and phone, on the client of the commit before; all six cases failed: the region still said "@mona's machine is offline. Your work is kept." beside the notice in the run-card case and "Box B is offline. Your work is kept." in the case of a state that had dropped, and in the case of a state released after the socket dropped it said "Connecting to Box C" 1,550 ms after the read answered, beside the notice, with the machine button gone; the unit cases received the sentence in the region where it was to be empty).
• One finding about the tests themselves: an existing browser case for a reconnect said its states to a socket that had already closed, because its helper counted every earlier load of the page as a reconnection, so it could never have shown a flicker. The helper now waits for the new connection's greeting, and that case runs as a real reconnect. An existing case, "a disconnect rejects a pending send", asserted the very strip this change removes; it now asserts there is none, and its reduced-motion check moved to a case that refuses the send. And the last-seen case ended by stopping its route while a read was still in flight, which made it fail once in teardown with "Route is already handled"; it now waits for its routes, as the two cases before it do. The run-card case's list of words about the machine also left out "is offline", "Connecting", "Your work is kept" and "No machine", and it never read the live region, which is how a stale sentence there went unseen; one list now covers the page's text, labels, titles, tooltips and live regions.
• Not run: bun run design:browser (Linux visual baselines are not regenerated; captions this changes may be in the Conversation, Workflow runs, navigation and view-tabs baselines), the full runtime Docker image, bun run test:postgres (the shared attachment contract's expected texts are updated and pass against the memory adapter), the conversation-plan browser specs (their own Docker configuration), the rest of the browser suite, and GitHub's checks (nothing was pushed).

Residual risks and deferred

• The red refusal strip "Still connecting to @mona's machine. Try again in a moment." still appears after a message sent to a machine being connected to, and stays after the machine connects; the 30 s wait before it stays too. They belong to the Stage 1 run on branch stage1-invisible-deploys, which removes that refusal and replaces it with queued messages that carry delivery marks. This change leaves the strip's words, its wait, its clearing and the send path unchanged; it only does not draw the strip while the offline notice shows.
• A machine removed while the page was disconnected is told none first by the new server, which cannot be told from its placeholder, so the page keeps its last known state until another state arrives or it reloads. The machine list the page polls is not held across a restart: it is a fresh answer from the new server and reads as offline until the machine returns.
• "Last seen" is for a machine that is offline. A dropped agent on a machine that stays connected has no timestamp on the wire's disconnected state, so it still says "Your work is kept."; adding one is a protocol change this work does not make.
• The design audit's presence plate shows the offline specimen with "Your work is kept." and has no "Last seen" specimen of its own; the last-seen words are covered by the status tests and the browser specs.
• The link's own keptStop flag (a Stop the client had not confirmed when its link dropped) is now read only by its tests, since the Chat sentence that used it is gone.
• destinationCue hints are tested but rendered by no component today.
• A child document open beside its parent still draws its own offline notice (pre-existing, from Quiet the machine status, and make a lost connection calm #792).
• A document whose agent dropped while its machine is still connected says "Box A is offline. Your work is kept." of the machine, because the wire's disconnected state does not say which of the two dropped. Telling them apart is a protocol change this work does not make.
• The status names only the machine the button names, so a document whose Planner dropped from a machine the button does not name says nothing of it: its work kept on an earlier machine after the person chose another (the server keeps it there until it ends), or, with no choice, a dropped machine that is offline while Default machine names another or none. For the last the button reads "Runs on: no machine connected" and no "Last seen" is said until the machine is the one the button names again. The page cannot tell that from a stale list, because the wire carries no machine id (closing it needs the id on the wire), so it says nothing there. The same wait, one round trip to the machine list after each word, delays the machine's name on a word by that long, and the status says nothing of the machine until then, however long a failing read takes.
• A person with no machine button reads machine state above the composer while online, as the user ruled (they have no other place to read it); it is hidden while the offline notice shows and returns with the connection, so the strip is shown online and hidden offline, and a person with the button reads it on the button alone.
• A send the connection cut off is not sent again by itself: the draft stays in the composer and the person sends it again once the page is back. Sending it for them, with a delivery mark, is the queued-message work on branch stage1-invisible-deploys.

Assistant-model: Claude Sonnet 5.5
Assistant-workflow: goal (run e8affc11-a52c-4d2e-b034-52b742b22f77)
Assistant-verification: bun run fix made no changes, bun run types passed, and bun run ci passed on the final head: dprint, oxlint (72 warnings, 0 errors, as on the base), tokens, the design contract (330 exceptions), the design record and Impeccable show no new findings
Assistant-verification: GIT_CONFIG_GLOBAL=/dev/null bun test apps/web packages scripts e2e/focus-color.test.ts apps/server passed on the final head: 6999 pass, 9 skip, 0 fail
Assistant-verification: CI=1 GIT_CONFIG_GLOBAL=/dev/null bun run e2e connection chat-mentions chat-phone chat-composer planner-attachment planner-picker machines machine-choice restart responsive-activity setup-agents hosted smoke implementation-launcher decision-evidence chat-references on a client rebuilt from the final head, once: 228 passed, 1 skipped (the live coding-agent build), 0 failed, 2 flaky that passed on retry (machine-choice "populated sidebar Default machine fits ..." at 1862x1039 and 1280x600, each on a 10 s timeout under the suite's load); the 10 cases that title matches passed 10 of 10 with --retries=0 on that client
Assistant-verification: CI=1 bun run design:behavior passed 22 on the final head
Assistant-verification: initial JavaScript measured 258,951 B raw / 81,994 B gzip in a local build and 258,947 B raw / 82,779 B gzip in docker build --no-cache --target build on the final head, against limits of 259,500 B and 83,000 B
Assistant-verification: red first (CI=1, --retries=0, on a client built from the code before each change, showing only that a case fails for the reason it describes): the machine strip beside the offline notice, a refusal beside it, a stale list naming another of the person's own machines, a list read before the socket's word, a run card beside the offline notice, a status held for an older word, a status redrawn after the gap, and the live region beside the offline notice, each in the browser on desktop and a 390 px phone and in a unit case
Assistant-verification: screenshots of the machine button after the document moved to Box C, the offline notice with the machine's state said before it, and the run card with the offline notice and with the connection back, on desktop and a 390 px phone, were retaken on the final head, opened and checked against apps/web/DESIGN.md; no defect found. The earlier commits' shots were opened and checked when those commits were made
Assistant-verification: not run: bun run design:browser, the full runtime Docker image, bun run test:postgres, the conversation-plan browser specs, the rest of the browser suite, and GitHub's checks (nothing was pushed)
User-preference: Status UI stays quiet when things are healthy and calm when they aren't, like Notion
User-preference: For product behavior questions, use the industry standard for popular projects
User-preference: Behave like WhatsApp and Slack for messaging and status
Co-authored-by: Alex Lavaee lavaman131@github.com
Assistant-duration: unmeasured