style: drop em-dashes from the text added in c2114615

House style, and these land in the changelog. Only the sentences added in the
previous commit are touched; the em-dashes in contributor text and in the
pre-existing COD-54/COD-115 comments are left alone.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

.changeset/7ab53c88.md

@@ -14,7 +14,7 @@ check would let exactly the keystroke this exists to catch through.
 
 This is defence in depth rather than a fix for the steady state: an agent CLI holds its tty in
 raw mode with ISIG off, where ^Z is already inert. It covers the moments that are not the
-steady state — the window before the CLI takes the tty at startup, and any point where it hands
+steady state: the window before the CLI takes the tty at startup, and any point where it hands
 the tty back. Two input paths are deliberately not covered and still reach the PTY: the mobile
 keyboard accessory bar's one-shot Ctrl, and the CJK composition textarea when `cjkInputEnabled`
 is on. Both are separate choke points to the PTY, and both are worth covering if this ever

.changeset/fix-claude-truecolor-in-panes.md

@@ -13,10 +13,10 @@ already do, and the block renders in the color the theme actually names.
 
 How bad the quantization was depends on `TERM`, which is why this looks different on different
 machines. On tmux 3.2 and newer, whose `default-terminal` defaults to `tmux-256color`,
-supports-color reports 256 colors and `rgb(55, 55, 55)` lands on `ESC[48;5;237m` — visible, but
-not the color the theme asked for. Where `TERM` resolves to a 16-color entry instead — tmux
+supports-color reports 256 colors and `rgb(55, 55, 55)` lands on `ESC[48;5;237m`: visible, but
+not the color the theme asked for. Where `TERM` resolves to a 16-color entry instead (tmux
 older than 3.2, or a `~/.tmux.conf` setting `default-terminal screen`, which Codeman's tmux
-server does read — every dark background collapses to `ESC[40m`, the terminal's own black, and
+server does read), every dark background collapses to `ESC[40m`, the terminal's own black, and
 the block disappears entirely. That is the case this was reported from, and a custom Claude
 theme could change the color there with nothing on screen moving.
 
@@ -28,8 +28,8 @@ reads it as a signal that it is running nested inside itself.
 registry entry as the tmux pane and its attach client instead of deleting `COLORTERM` from a
 hand-maintained list of its own. It applies that entry before assigning Codeman's own
 variables, mirroring `buildEnvExports()`, so a `clis.json` override naming one of them cannot
-strip it on this path while the tmux pane keeps it. A remote pane still exports nothing —
-`buildRemoteLaunchCommand()` never carried these declarations — so an SSH-remote Claude
+strip it on this path while the tmux pane keeps it. A remote pane still exports nothing,
+because `buildRemoteLaunchCommand()` never carried these declarations, so an SSH-remote Claude
 session keeps the old rendering.
 
 PR #3 introduced the `unset COLORTERM` in February, citing xterm.js#484 for the claim that

docs/architecture-invariants.md

@@ -18,7 +18,7 @@ Implementation detail extracted from `CLAUDE.md` so that file stays small enough
 
 ## Session launch modes
 
-**Terminal colour env** — the stock registry decides each CLI's colour vars. Claude, Codex, Gemini, Antigravity, Pi, Grok, DeepSeek and OMP export `COLORTERM=truecolor`; `shell` and `opencode` unset it. All of those except Claude also unset `NO_COLOR`, so a user who exports `NO_COLOR` globally keeps monochrome Claude panes. The variable matters because a CLI inheriting no `COLORTERM` quantizes every RGB color it draws down to whatever palette `TERM` alone implies, and the pane's `TERM` is not a constant. ⚠️ Codeman sets no `default-terminal` and passes tmux no `-f`, so it is tmux's default (`tmux-256color` since 3.2) unless the user's own `~/.tmux.conf` says otherwise — which Codeman's server DOES read. At `tmux-256color` supports-color reports 256 colors and `rgb(55, 55, 55)` lands on `ESC[48;5;237m`: visible, but not the color the theme named. Where `TERM` resolves to a 16-color entry instead (tmux older than 3.2, or a conf setting `default-terminal screen`) every dark background collapses to `ESC[40m`, the terminal's own black, and the block disappears entirely — which is why the same Claude theme looks different on two machines, and why a bug report here is worth pairing with the reporter's `tmux -V` and their pane's real `TERM`. ⚠️ These declarations reach the local tmux pane via `buildEnvExports()`, its attach client via `cliExportsTruecolor()`, and the direct-PTY fallback via `buildClaudeEnv()` — they do NOT reach a remote pane, which `buildRemoteLaunchCommand()` builds with no env exports at all. A Docker pane takes `COLORTERM=truecolor` from the hardcoded `envCreate`/`execEnv` in `tmux-manager.ts`, which apply to every mode including the two the registry says must unset it. A `~/.codeman/clis.json` override replaces these arrays wholesale (`deepMerge`), so a custom entry can drop either list — which is why both consumers apply the entry BEFORE Codeman's own variables rather than after: `buildEnvExports()` emits `...cliEnv` ahead of `export CODEMAN_MUX=1`, and `buildClaudeEnv()` assigns `PATH`/`TERM`/`CODEMAN_*` after its unset/export loop. Reversed, a config-supplied `unset` naming `CODEMAN_HOOK_SECRET_FILE` would strip it on one path and not the other.
+**Terminal colour env** — the stock registry decides each CLI's colour vars. Claude, Codex, Gemini, Antigravity, Pi, Grok, DeepSeek and OMP export `COLORTERM=truecolor`; `shell` and `opencode` unset it. All of those except Claude also unset `NO_COLOR`, so a user who exports `NO_COLOR` globally keeps monochrome Claude panes. The variable matters because a CLI inheriting no `COLORTERM` quantizes every RGB color it draws down to whatever palette `TERM` alone implies, and the pane's `TERM` is not a constant. ⚠️ Codeman sets no `default-terminal` and passes tmux no `-f`, so it is tmux's default (`tmux-256color` since 3.2) unless the user's own `~/.tmux.conf` says otherwise, which Codeman's server DOES read. At `tmux-256color` supports-color reports 256 colors and `rgb(55, 55, 55)` lands on `ESC[48;5;237m`: visible, but not the color the theme named. Where `TERM` resolves to a 16-color entry instead (tmux older than 3.2, or a conf setting `default-terminal screen`) every dark background collapses to `ESC[40m`, the terminal's own black, and the block disappears entirely. That is why the same Claude theme looks different on two machines, and why a bug report here is worth pairing with the reporter's `tmux -V` and their pane's real `TERM`. ⚠️ These declarations reach the local tmux pane via `buildEnvExports()`, its attach client via `cliExportsTruecolor()`, and the direct-PTY fallback via `buildClaudeEnv()` — they do NOT reach a remote pane, which `buildRemoteLaunchCommand()` builds with no env exports at all. A Docker pane takes `COLORTERM=truecolor` from the hardcoded `envCreate`/`execEnv` in `tmux-manager.ts`, which apply to every mode including the two the registry says must unset it. A `~/.codeman/clis.json` override replaces these arrays wholesale (`deepMerge`), so a custom entry can drop either list. That is why both consumers apply the entry BEFORE Codeman's own variables rather than after: `buildEnvExports()` emits `...cliEnv` ahead of `export CODEMAN_MUX=1`, and `buildClaudeEnv()` assigns `PATH`/`TERM`/`CODEMAN_*` after its unset/export loop. Reversed, a config-supplied `unset` naming `CODEMAN_HOOK_SECRET_FILE` would strip it on one path and not the other.
 
 ### External CLI modes (OpenCode, Codex, Gemini, Antigravity, Pi, Grok, DeepSeek, OMP)
 

src/web/public/keyboard-accessory.js

@@ -243,7 +243,7 @@ const PathPicker = {
    * ⚠️ This re-orders the listing the SERVER returned, and the server cuts at
    * FILESYSTEM_PICKER_ENTRY_LIMIT (500) after sorting by name. So in a folder past
    * that limit, "Newest first" is the newest of the first 500 BY NAME, not the newest
-   * in the folder — which is the one case this sort exists for. The status line says
+   * in the folder, which is the one case this sort exists for. The status line says
    * "(first 500 by name)" rather than "(first 500)" so the cut is legible; ordering
    * before the cut would have to happen server-side, and would cost a stat on every
    * entry in the directory rather than on the 500 that are returned.