samagotchi 0.123.0 → 0.125.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 8b284b838ef7182e859040f2955be576abe43fda373a9a96c094bd701ef8837c
-  data.tar.gz: d776a399ac831dd9a62405f58f5eb9c9843b83b021f82a52361fe32d4f49aba9
+  metadata.gz: 8d36716e229ef5ccac918c840a3b55d878257811aeffdf594d2588c3bf067533
+  data.tar.gz: fb632ff225b0a9f5dfbbc869ce8df2842df811b6858caa3d714362879a3e4287
 SHA512:
-  metadata.gz: 1a590e517591c610712641c7496a916afad37502d3784669bbb58a582a5e8522246dc9c6a2bdcaad8b5fc9ad4d8c7b7bab95e52eeea012bf075af9d481e52680
-  data.tar.gz: 4e7917cc27174b89e870f6f6d768001de752b35f332f942f7c9223fab22a0614c2bb32839e79c6038282ed5a86f994e038a4cd8b2a1a3a83b3c2f52320309827
+  metadata.gz: d16837760eae98a5f26bef1349f70d6fecf80b2400858d2fab12d0a39b11cb5ed125901b21e99bede021585cd9ad60c44adb6a3dad0416a7c4302ebaed459950
+  data.tar.gz: 8210416816fda4da83f18801d6e2b991335c41054cfd5459361c9b478d5c633a02ac58855d9f77520d05269c2f64e004cd600c7e56b36ac12d71efe612965430

data/CHANGELOG.md

@@ -7,6 +7,51 @@ and commands may change between minor versions. How releases are made:
 [docs/releasing.md](docs/releasing.md).
 ## [Unreleased]
 
+## [0.125.0] - 2026-10-27
+
+### Added
+
+- chi web links to a claim: selecting text in a turn shows **Copy link**, a link for a participant's browser that
+  opens their page on that turn, scrolled to the quote and highlighted (no token: it opens where their review link
+  was opened, one link per browser); with no one invited, a link on your own page, which takes the same anchor.
+- A built-in **Verify** annotate preset on both pages, after `web.annotate_presets`: it quotes the selection and asks
+  to verify the claim against the code, ending on `Verdict: confirmed|refuted|unclear — <reason>`.
+
+### Changed
+
+- `chi sessions restart` (and chi web's restart, its update's worker restarts) keeps a session's reminders: the
+  leaving worker hands them to the new one, with their ids and schedules (one that came due meanwhile fires once),
+  instead of refusing the restart. A stop, an idle exit, a crash and the TERM fallback for a worker that can't be
+  asked still drop them; a worker from an older chi still refuses.
+
+### Fixed
+
+- `chi sessions stop` (and the web's stop, delete and archive, which stop the same way) stops a stopped (SIGSTOPped,
+  Ctrl-Z) worker at once, instead of waiting out the stop's 10 s and leaving it running; a command or background task
+  chi stops while it is stopped ends with its TERM, not the KILL after the grace.
+
+Update from chi web's Update button (or `chi update`, then restart `chi web` and the session workers with
+`chi sessions restart`). Workers on 0.124.0 still refuse a restart while they hold reminders: stop and resume those
+once; from 0.125.0 on a restart keeps them.
+
+## [0.124.0] - 2026-10-27
+
+### Added
+
+- The desktop helper's panel lists and sends to the sessions of the remotes `chi remote add` keeps: a section per
+  remote ("on studio") after this Mac's rows, each row tagged with its machine, "→ studio" in the hint while one is
+  ticked, one call per machine at once; a remote that doesn't answer within 4 s or refuses shows one line, and this
+  Mac's rows don't wait for it. A remote with a session also gets a "New session on studio in <folder>" row, in its
+  newest session's folder, on that remote's default model. The Everyone row, the model chooser and agents stay on
+  this Mac.
+- chi web updates chi from its page: the notice's **Update** installs the release it names in a progress sheet
+  that lists kept edits, then offers **Restart workers** (each worker on an older chi; a busy one says what holds
+  it) and **Restart chi web** (in place: same port, token, flags and Tailscale Serve). `chi update --to VERSION`
+  installs an exact release; `--json` prints its rows as JSON.
+
+Update with `chi update` (it rebuilds the desktop helper), then restart `chi web` and the session workers
+(`chi sessions restart`). From the next release on, chi web's Update button does this from its page.
+
 ## [0.123.0] - 2026-10-27
 
 ### Added
@@ -4695,7 +4740,9 @@ and long-lived sessions.
 - A macOS desktop helper (`chi desktop install`): a "Send to chi" Service and a
   hotkey panel that send selected text or the clipboard to your sessions.
 
-[Unreleased]: https://github.com/dm1try/samagotchi/compare/v0.123.0...HEAD
+[Unreleased]: https://github.com/dm1try/samagotchi/compare/v0.125.0...HEAD
+[0.125.0]: https://github.com/dm1try/samagotchi/compare/v0.124.0...v0.125.0
+[0.124.0]: https://github.com/dm1try/samagotchi/compare/v0.123.0...v0.124.0
 [0.123.0]: https://github.com/dm1try/samagotchi/compare/v0.122.0...v0.123.0
 [0.122.0]: https://github.com/dm1try/samagotchi/compare/v0.121.1...v0.122.0
 [0.121.1]: https://github.com/dm1try/samagotchi/compare/v0.121.0...v0.121.1

data/bin/chi

@@ -18,6 +18,15 @@ rescue Samagotchi::ConfigFile::RemovedApi => e
 end
 require "samagotchi"
 
+# A web self-restart re-enters through the installed wrapper: its marker and
+# the worker starters to adopt leave ENV before anything spawns with it
+# (Server.take_restart_env!); a restarted chi web skips the first-run hint.
+web_restarted = false
+if ENV.key?("SAMAGOTCHI_WEB_RESTARTED") || ENV.key?("SAMAGOTCHI_WEB_ADOPT_PIDS")
+  require "samagotchi/web/server"
+  web_restarted = Samagotchi::Web::Server.take_restart_env!
+end
+
 # `chi self`: print version, source dir, config/memory/session paths, model and
 # bundles (read-only, offline) — lets the agent find its own code and state.
 if ARGV[0] == "self"
@@ -221,7 +230,7 @@ chi_update_hint = lambda do
 end
 
 if options[:web]
-  chi_update_hint.call
+  chi_update_hint.call unless web_restarted
   require "samagotchi/web/server"
   port = options[:web_port] || Samagotchi::Config.get("web.port")
   markdown = options[:web_markdown]
@@ -233,7 +242,9 @@ if options[:web]
                                       annotate_presets: Samagotchi::Config.get("web.annotate_presets"),
                                       editor: Samagotchi::Config.get("web.editor"),
                                       start_dir: options[:start_dir] || Samagotchi::Config.get("web.start_dir"),
-                                      start_dir_from: options[:start_dir] ? :flag : :config)
+                                      start_dir_from: options[:start_dir] ? :flag : :config,
+                                      restarted: web_restarted,
+                                      restart_argv: Samagotchi::RunOptions.web_restart_argv(options))
 end
 
 # --resume and --attach take a unique id prefix too, like git.

data/docs/architecture.md

@@ -75,7 +75,7 @@ TerminalUI  ──  delegates  ──▶  Engine
   higher-level turn events, so any new UI can render without terminal coupling.
 - **`ComposerRoute`** (`lib/samagotchi/composer_route.rb`) decides where a line typed at
   either terminal's prompt goes (the REPL's `steer_line` / `run_input_line`, the attached
-  `AttachedLoop#submit`): `/cut TEXT` / `/queue TEXT`, a terminal's own word, a session
+  `AttachedLoop::Composer#submit`): `/cut TEXT` / `/queue TEXT`, a terminal's own word, a session
   command, a typo, a prompt. Each UI keeps what it does with the route. The web's
   `composer.js#routeComposerLine` decides the same; `spec/fixtures/composer_routes.json`
   holds the cases both answer (see [testing.md](testing.md)).
@@ -171,7 +171,9 @@ agent logic and can be used without any terminal rendering; the UI is a thin lay
   activity slot gets a second, dim row: the turn's tool tally (`TurnTally`, seeded from the
   snapshot's tool parts on a mid-turn join). Reline still reads the input,
   but `RelineSeam` (prepended to `Reline::LineEditor`) sends its drawing to the
-  `Screen`. Without a capable terminal it falls back to `PlainSurface` (append-only).
+  `Screen`. The saved history and cards in a join or resync are rendered by
+  `TerminalUI::JoinReplay` with the loop's screen, view, link, gap clock and renderer.
+  Without a capable terminal it falls back to `PlainSurface` (append-only).
 
 #### Using the core
 
@@ -551,6 +553,24 @@ version than the server itself still means restart chi web (its workers already
 web runs in) it names `start_dir`, the folder it starts in (`web.start_dir`, `--start-dir`;
 `Web::StartDir`), which a second `chi web` given another one mentions.
 
+The owner's update routes publish progress and results as `chi_update` events with an
+`operation` (`install` or `workers`), `state`, and `rows`; install events also name the target
+`version` and may include a progress line. The hub retains the latest event for a reconnecting
+tab's snapshot. `POST /api/update` decides itself whether this install can take a gem
+(`UpdateCheck.blocked_reason`: a checkout, Bundler, an unwritable gem dir → 409 `update_blocked`), so
+it holds with `update.notify: off`; a child that prints no rows fails with its own last line, and a
+done install refreshes the hub's installed version (`SessionHub#refresh_installed`) before its `done`.
+Worker restarts target every worker older than the version installed now (refreshed the same way)
+and publish per-session results. Only one of an install, a worker restart pass and a web restart runs
+at a time (409 `update_running`). `POST /api/update/restart_web` (409 `restart_unavailable` without a
+chi wrapper to exec) schedules WEBrick shutdown only after its response is sent; after the hub and
+listener stop, `Server` execs the RubyGems chi wrapper with every flag chi web was started with, as
+`RunOptions`' parser recorded them (`RunOptions.web_restart_argv`), but the one-shot `--open` and
+`--new-token`. The re-entry (`SAMAGOTCHI_WEB_RESTARTED`, taken out of ENV first by
+`Server.take_restart_env!`) skips the first-run update hint, adopts live worker-starter PIDs (workers
+themselves are detached), and adopts an exact Tailscale Serve handler. A failed exec, or a restarted
+chi web that doesn't start for any reason, turns off only that exact adopted handler.
+
 The page's scope is in its URL, and the server picks the default: `?dir=<folder>` is that folder's
 project (the list, the events stream and a new chat follow it), `?scope=all` every session, and a bare
 `/` the start folder's project when that folder is in a repo (`App#index_data_attributes` writes
@@ -786,4 +806,4 @@ A map of the parts the overview above doesn't name (paths under `lib/samagotchi/
 | Stores | `reminder_store.rb` (`ReminderStore`), `recap_store.rb` (`RecapStore`) | A session's reminders, and its idle recap (`recap.json`). |
 | Setup and update | `bootstrap_command.rb`, `bootstrap/`, `update_command.rb`, `gem_update.rb` | `chi bootstrap` (first config.yml, system bundle, core profile) and `chi update` (the gem, shipped bundles, the macOS helper). |
 | Process groups | `process_group.rb` (`ProcessGroup`) | A command in a process group of its own, stopped as a group (TERM, grace, KILL): execute, tasks, context fetches, the mcp bundle's servers. |
-| Desktop | `desktop.rb`, `desktop/macos.rb`, `desktop_command.rb`, `desktop/macos/*.swift` | `chi desktop`, the macOS "Send to chi" helper ([desktop.md](desktop.md)). The helper's Swift side: the panel (`Panel.swift`), the chi CLI runner (`ChiRunner.swift`), agent terminals behind `AgentTerminal` (`AgentTerminal.swift`, `Kitty.swift`, `Tmux.swift`; `ChiHelper --agents` is their CLI seam). |
+| Desktop | `desktop.rb`, `desktop/macos.rb`, `desktop_command.rb`, `desktop/macos/*.swift` | `chi desktop`, the macOS "Send to chi" helper ([desktop.md](desktop.md)). The helper's Swift side: the panel (`Panel.swift`), the chi CLI runner (`ChiRunner.swift`), the session rows and the chi calls a send makes (`Sessions.swift`: `SendPlan`; `ChiHelper --sessions` and `--send-plan` are their CLI seams), agent terminals behind `AgentTerminal` (`AgentTerminal.swift`, `Kitty.swift`, `Tmux.swift`; `ChiHelper --agents` is their CLI seam). |

data/docs/cli.md

@@ -34,7 +34,7 @@
 - `chi desktop install|upgrade|uninstall|status` — the macOS "Send to chi" helper: a Service and a ⌃⌥⌘N hotkey that send text or images to a session (live, stopped or new) as a message (⏎, a turn runs) or a context note (⌘⏎) (see [Desktop helper](desktop.md))
 - `chi models [--format text|json] [--timeout S] [TEXT]` — list the models every configured host offers, as the names `--model` takes (see [Listing the models](#listing-the-models))
 - `chi self` — print version, source dir (checkout or installed gem), config/memory/session paths, model/host and bundles. Run by a session's `execute`, the `model` row (and host, loop, profile, thinking, served model) is **that session's** model, labelled `(this session <id8>; default …)`; elsewhere it is the default, `(default)`. `model key` is the memory overlay key (`<name>.<key>.md`), and `model notes` the model notes a prompt of that model loads (`model_notes_deepseek (system, 612 chars)`, `none`; inside a session its `--mute` list is left out). `chi self --model` prints only the model a new session starts on, an alias resolved to its target (the desktop helper's hint)
-- `chi update [--dry-run] [--no-gem] [--no-bundles] [--no-desktop]` — update an installed chi: the gem, the system bundle, the shipped bundles you installed and the desktop helper, in one table (see [Updating](#updating))
+- `chi update [--dry-run] [--to VERSION] [--json] [--no-gem] [--no-bundles] [--no-desktop]` — update an installed chi: the gem, the system bundle, the shipped bundles you installed and the desktop helper, in one table (see [Updating](#updating))
 - `chi bundle install|upgrade|uninstall|status|diff|list|build|trash|new|test|check` — manage memory bundles (see [Bundle hooks](hooks.md#bundle-hooks-unified-workflow-bundle)); `list` shows the installed ones and the ones shipped with chi, which `install <name>` installs; `core` and `dev` are profiles that install a set of them (see [Bundle profiles](memory.md#bundle-profiles-core-and-dev),  [Guardrails](guardrails.md), [Plugins](plugins.md#the-btw-bundle), [the mcp bundle](plugins.md#the-mcp-bundle) [the loop-guard bundle](plugins.md#the-loop-guard-bundle), [the check-in bundle](plugins.md#the-check-in-bundle) and [the skills bundle](plugins.md#the-skills-bundle)). `trash` lists and empties the bundle trash (moved files from uninstalls/upgrades). A usage error (an unknown subcommand or flag, a missing argument, a bad `build --scope`) exits 2, as for the other subcommands. Plain `chi` and `chi web` exit 1 on an unknown flag, a flag missing its value or a stray argument. `new`, `test` and `check` are for writing one: see [Writing a bundle](#writing-a-bundle-new-test-check)
 
 - `chi guardrails replay [--dry-run] [--threshold T] [--model M]` — seed System 1's record from the approvals this machine's sessions already answered: each ask is judged by the configured model and written to `guardrails/judgments.jsonl` with the answer the user gave, then a per-rule table prints (asks, allowed, denied, would-be auto-allows, false allows, asks with no judgment). A parent agent's answer is not the user's: only its deny is replayed, and only where the parent could have allowed. `--dry-run` judges without writing, `--threshold` overrides `guardrails.system_one.threshold` for the table, `--model` the configured model for this run. Exit 2 when `guardrails.system_one.mode` is off or no `host` is set; a usage error exits 2 (see [System 1](guardrails.md#system-1-experimental))
@@ -233,13 +233,26 @@ Also shipped, not installed: dev (mcp, skills, source-links) (chi bundle install
 done
 ```
 
+- `--to VERSION` installs exactly that gem version instead of checking for the
+  newest release. It must be newer than the running chi; an equal or older
+  version is refused.
+- `--json` writes the component rows as one JSON array on stdout. Each row has
+  `component`, `from`, `to`, `status`, `failed` and `kept` fields; `kept` is an
+  array of edited filenames. Install progress is written to stderr.
+
 - **chi web update notices.** By default, chi web checks RubyGems about 30
   seconds after it starts and every 24 hours after that. Once a stable release
   is at least 24 hours old and newer than both the running chi and the newest
-  installed one, the page shows its version, a link to that RubyGems release,
-  and a button to copy `chi update`. The notice is once per version per
-  browser: a reload or a chi web restart doesn't repeat it.
-  `update.notify: off` disables checking; `update.check_hours` and
+  installed one, the owner's page shows its version and a link to that
+  RubyGems release. When the install is unblocked, **Update** installs that
+  exact release and opens a progress sheet with component results and any
+  edited files kept. A blocked install instead shows the reason and a command
+  to copy. After installation, the notice and the sheet's footer offer
+  **Restart workers** and **Restart chi web**; the sheet reports worker results
+  (a busy worker's refusal says what holds it) and waits for chi web to
+  reconnect, and keeps the other restart in reach. The notice is once per version per browser: a reload or a chi
+  web restart doesn't repeat it. `update.notify: off` disables checking;
+  `update.check_hours` and
   `update.min_age_hours` tune the interval and release age (see
   [configuration](configuration.md#all-settings)). If the gem can't be updated
   in place, the notice gives the blocker and its command instead.
@@ -528,14 +541,15 @@ terminal and the Web UI say so, with that restart line.
 `chi sessions restart ID...` hands each session to a new worker on the newest
 chi installed, without stopping it: an attached terminal and the web's tabs
 move to the new worker. It is refused, with the reason, while something would
-be lost: a turn running or queued, a question or approval waiting, reminders,
-a `/btw` still running, an approval relayed from a delegate, or background
-tasks the session started. If the worker cannot be asked (a refused Bridge,
-protocol mismatch or stuck start), chi sends it TERM and resumes only when
-disk shows no running turn, pending question or approval, queued prompt, or
-running background task; otherwise it says to run `chi sessions stop ID`, then
-send any prompt. That fallback may lose reminders, a running `/btw`, and other
-in-memory state. A session with no running worker needs no restart (its next
+be lost: a turn running or queued, a question or approval waiting, a `/btw`
+still running, an approval relayed from a delegate, or background tasks the
+session started. Its reminders move to the new worker with their schedules
+(a worker from an older chi still refuses for them). If the worker cannot be
+asked (a refused Bridge, protocol mismatch or stuck start), chi sends it TERM
+and resumes only when disk shows no running turn, pending question or
+approval, queued prompt, or running background task; otherwise it says to run
+`chi sessions stop ID`, then send any prompt. That fallback drops reminders,
+and may lose a running `/btw` and other in-memory state. A session with no running worker needs no restart (its next
 prompt starts one on the newest chi), and an older worker without restart
 support needs `chi sessions stop ID`. The Web UI's
 `POST /api/sessions/:id/restart` does the same (409 with `reason` and `detail`
@@ -1194,6 +1208,17 @@ their comment box, labelled `From docs/plan.md:` or `From Sam's comment:`,
 with the same presets. Not in the owner's participant view, and no plugin
 pills there (a review turn refuses `/` lines).
 
+After the presets, both pages have a built-in **Verify**: the quote, then
+an ask to check the claim against the code and end on a line `Verdict:
+confirmed|refuted|unclear — <reason>`. On your page a selection in a turn
+also offers **Copy link**: a link to that turn and quote for a participant's
+browser (the one their review link was opened in), which opens their page
+scrolled to the quote and highlights it; with no one invited, a link to it
+on your own page. A secret in the selection goes into the link as
+`[redacted]`, as the participant's page shows it. One browser holds one participant link at a time, and
+opening a participant's invite link yourself swaps your own sign-in for it
+(see [participants.md](internals/participants.md#what-a-participant-sees)).
+
 The list is `web.annotate_presets`, `|`-separated (at most five; a preset
 can't contain `|`; a YAML list works too):
 
@@ -1325,6 +1350,8 @@ CHI_REMOTE=studio chi context push claude-outbox ab12 < answer.json
   studio (http://192.168.1.29:4567): connection refused`, exit 1; with
   `--format json` an `error` object).
 - Plain http, the same as the phone's: use it on your home network.
+- The macOS desktop helper's panel lists and sends to a remote's sessions too: see
+  [Desktop helper: Remote sessions](desktop.md#remote-sessions).
 
 A session there in this terminal (the attached TUI, through that machine's
 chi web; its worker stays there):

data/docs/desktop.md

@@ -41,7 +41,7 @@ alias as the model it names).
 
 ### Everyone it concerns
 
-The second row, **Everyone it concerns** (⌘B), shares a note with every session it may concern instead of the ones
+The second row, **Everyone it concerns (this Mac)** (⌘B), shares a note with every session it may concern instead of the ones
 you pick: ⌘⏎ (the **Broadcast** button) runs [`chi broadcast`](broadcast.md) with the line, then the text, on stdin.
 chi picks the sessions (a shared ticket, PR or link, else a small triage model), so the preselected session doesn't
 count: the row is ticked alone, like the new row. Write it the way you'd tell a colleague: a first line such as
@@ -51,6 +51,8 @@ count: the row is ticked alone, like the new row. Write it the way you'd tell a
   skipped 2 · 1 unchecked: triage deadline`), and **stays open**: Esc closes. Which sessions got it and why:
   `chi broadcast log` in a terminal.
 - A broadcast is a text note: ⏎ and images beep. The source field and Send are hidden (its source is `broadcast`).
+- It reaches this Mac's sessions only (`chi broadcast` runs on this machine only), never a
+  [remote's](#remote-sessions).
 - It may take `broadcast.triage_deadline` (20 s) and 10 s more before the helper stops it ("the note may be partly
   delivered"). The helper reads that from its launch file: after changing the deadline, run `chi update` (or
   `chi desktop upgrade`).
@@ -106,6 +108,46 @@ thumbnails sit under the message line, 48 px high, the file name as a tooltip; h
   the panel closes; files from Finder are sent as they are, never touched. A send with images may take up to 30 s
   (converting, a worker starting) before the panel gives up.
 
+## Remote sessions
+
+The panel also lists the sessions of the other machines `chi remote add` keeps (see
+[Remote sessions](cli.md#remote-sessions)), say the Studio's from a laptop: select text or take a screenshot here,
+and it lands in a session running there.
+
+- **Which:** every remote in `chi remote ls` that has a token, asked at each open (a remote you don't want in the
+  panel: `chi remote rm` it). No `chi update` or `chi desktop upgrade` after adding one.
+- **Where:** after this Mac's rows, one section per remote under an **on studio** divider: its live sessions, then up
+  to 3 recent ones, as for this Mac. Each row carries a grey **studio** tag and its whole folder path (that machine's
+  home may differ from this one's). ⌘1…⌘9 number this Mac's rows first, then the remotes' in order; past nine, a row
+  is clicked.
+- **Not twice:** a session shows once, where it is listed first (this Mac, then the remotes in `chi remote ls` order),
+  so two remotes for the same Studio (its LAN address and its ts.net name), or a remote that is this Mac, don't
+  list or send to it twice.
+- **Wrong machine:** both machines likely have the same paths. While a remote's row is ticked the message line's hint
+  ends in **→ studio**, and **→ studio** shows beside Send (it stays there while you type). The last choice is
+  preselected while it is still live, a remote's row too; the "only one live session" rule picks this Mac's only,
+  never a remote's. A remote that answers after this Mac's list never changes what is ticked: it is preselected only
+  when nothing is (so a remembered remote row is ticked when the remote answers first, or when this Mac has live
+  sessions but none was remembered).
+- **Keys:** ⏎ and ⌘⏎ work as for this Mac's sessions (`chi --remote studio send …`, `chi --remote studio note …`;
+  a note to a stopped session there waits for its next start). Images go along (`--image`: chi uploads them). With
+  rows of several machines ticked, the helper runs one call per machine at once and shows one line: `sent · studio:
+  sent`. ⌥⏎ (paste) beeps on a remote's row as on this Mac's.
+- **Down or refused:** this Mac's rows show as soon as they are in; each remote's fill in as it answers. A remote's
+  two lists run at once and get 4 s together: one that doesn't answer shows **studio: no answer within 4 s** under
+  its divider, one that chi gives up on by itself (connection refused, the token refused) the first line of chi's
+  error. The previous open's rows for it are never reused: a stale row could send to a stopped worker.
+- **New session there:** a remote with a session has its own new row under its divider, **New session on studio in
+  proj**: the folder is that remote's most recently updated session's (live first, then recent), whole and not
+  checked on this Mac. A remote with no session has no new row (never a guess at its home). It is ticked alone like
+  this Mac's new row (ticking it clears the sessions, and the reverse), is never preselected and has no ⌘ number (⌘0
+  stays this Mac's). ⏎ runs `chi --remote studio send --new --dir <that folder>` with the message and images, and
+  shows `studio: started 1a2b3c4d…` for 3 s. It starts on the remote's default model, never `--model`: its hint
+  says **remote default**, and ⌘M or a click on it beeps with "Model choice is for this Mac's sessions" (`chi models`
+  answers for this Mac's hosts).
+- **What stays on this Mac:** the model chooser, the **Everyone it concerns** row (`chi broadcast` is local only)
+  and the agents in kitty and tmux.
+
 ## Agents in kitty and tmux
 
 The panel can also send to agent CLIs (claude, codex, gemini, aider, …) running in
@@ -276,8 +318,14 @@ The helper uses only these commands, so it could ship on its own later:
   (`delivered N · skipped M…`); exit 0 when it ran, 1 when refused or a delivery failed.
 - `chi self --model` → the model a new session starts on (the panel's hint).
 - `chi models --format json` → the models the hosts offer (the new-session model picker).
-
-Each call is stopped after 10 s, a send with images after 30 s, a broadcast after the launch file's
+- `chi remote ls --format json` → `[{name, url, token}]` (never the token itself): the remotes whose sessions the
+  panel lists. A name goes on only when it has a token and passes chi's own rule (letters, digits, `_`, `-`, not
+  starting with `-`). An older chi without `chi remote` lists none.
+- `chi --remote NAME sessions list …`, `chi --remote NAME send …` and `chi --remote NAME note …`: the same calls on a
+  remote's sessions. `CHI_REMOTE` is taken out of the helper's environment, so this Mac's calls never go remote.
+
+Each call is stopped after 10 s, a remote's two lists after 4 s, a send of text to a remote after 15 s (waking a
+stopped worker there), a send with images after 30 s, a broadcast after the launch file's
 `broadcast_timeout` (`broadcast.triage_deadline` + 10 s; 30 s when it has none). A stopped `chi note` or `chi
 broadcast` says the note may be partly delivered.
 

data/docs/internals/participants.md

@@ -389,6 +389,31 @@ fields: a field added to an event later reaches nobody until it is named there.
   header, the Plan's truncation note. No plugin pills (a review turn refuses `/` lines), and none of it in the owner's
   participant view (no presets in its shell) or while `can_comment` is false. On a touch screen the bar docks above the
   composer. A re-read keeps unchanged thread nodes and the Plan's (redrawn only on change), so a selection survives it.
+  After the presets comes the built-in **Verify** (`verify_preset.js`, on the owner's page too): the quote, then
+  "Verify this claim against the code. If this session's context doesn't settle it, say so. End with a line
+  `Verdict: confirmed|refuted|unclear — <one-line reason>`." It fills the box like any preset and never sends.
+- **Deep links to a claim** (`claim_link.js`). The owner selects text in a turn's answer, step or own message and
+  Annotate's **Copy link** copies `<base>/#s=<id>&t=<turn8>&q=<quote>&p=<prefix>`: `base` the participants list's
+  `link_base` (`ParticipantsAdmin#participant_base`: `web.public_url`'s origin, else the LAN address, else the Host),
+  `t` the turn's id (its first 8 characters, the opening message's `data-turn-id`), `q` the selection's rendered
+  text (whitespace collapsed, at most 200 characters) and `p` up to 32 characters before it in the same bubble, both
+  URL-encoded by `URLSearchParams`. The text is read as the participant page shows it, by `Redact`'s own rules
+  mirrored in JS (`spec/fixtures/redact_cases.json` holds cases both sides must read the same): secret shapes
+  `[redacted]`, whole even when the selection cuts into one, so a link never carries a secret; on the owner's page
+  also the session's folder relative and the home folder `~` (the page's `data-home`). Not the owner's token (the
+  page doesn't hold it). With no person (`kind: human`) active in the session, Copy link gives the owner's own form,
+  `#/s/<id>?t=…&q=…&p=…`; the owner's page also opens the participant form. Opening one: the turn's bubbles
+  (`.p-msg > .p-bubble`; the owner's answers, own messages and steps) are searched for the prefix and quote, then
+  the quote alone; the match's bubble is ringed (`.claim-hit`), a closed `<details>` around it opened, and the quote
+  highlighted (the CSS Highlight API, `::highlight(chi-claim)`, where the browser has it). A quote not found (text
+  that reads differently) rings the turn's opening. A turn no opening carries (a non-person turn the page doesn't
+  stamp) is searched for in the whole page; neither found (one from before a continue) leaves the page at the top and
+  says so. The hash then drops the claim (`#s=<id>`, `#/s/<id>`), so the same link opened again shows it again. The
+  link holds no token, so it opens only in a browser that already redeemed a grant for that session; a link for
+  another session says this browser holds the link for this one. Its limits: **one grant per browser** (the grant
+  cookie is one name: a second participant link redeemed there replaces the first), and **the owner opening a
+  participant's invite link** in their own browser swaps their owner cookie for that grant (the page asks first). A
+  continue archives the session and revokes its grants: re-share, and links to the old session stay on it.
 - **The comment box** is the owner's composer (`composer_mount.js`, styled by the shared `composer.css`), mounted by
   `participant.js` with a subset on. It has: the height that grows with the text, the grip (drag to resize,
   double-click resets, click or drag down folds it; folded, the grip is the handle on the dock's edge and typing on the
@@ -468,7 +493,7 @@ gate and routes) answers these.
 
 | Route | Body / params | Answer | Refusals |
 |---|---|---|---|
-| `GET /api/sessions/:id/participants` | | 200 `{participants: [grant], warning, identity_header}`, every state; `warning`: the share warning for a session that isn't a review session (`ReviewStart.share_warning`, null for one), shown before the panel's Invite with Start a review of it; `identity_header`: the header this chi web's proxy names the user in (null without one), the Invite's email field | |
+| `GET /api/sessions/:id/participants` | | 200 `{participants: [grant], warning, identity_header, link_base}`, every state; `warning`: the share warning for a session that isn't a review session (`ReviewStart.share_warning`, null for one), shown before the panel's Invite with Start a review of it; `identity_header`: the header this chi web's proxy names the user in (null without one), the Invite's email field; `link_base`: where a participant's link opens, no token (a claim link's base) | |
 | `GET /api/participants` | | 200 `{participants: [grant]}`, every session's | |
 | `POST /api/sessions/:id/participants` | `name`, `kind` (`human`/`agent`), `ttl` (seconds), `cap`, `identity` (an email: a bound grant) | 201 `{participant: grant, token, link, lan, qr_svg, warning}`: the token and the link once; `warning` for a session that isn't a review session (`ReviewStart.share_warning`, null for one); `link` names this chi web's LAN address (`http://IP:PORT/?token=…#s=<id>`), `lan` false when it has none | 400 `invalid_participant` (name, kind, ttl, an identity that isn't one address or with no proxy to check it, an archived session); 404 |
 | `GET /api/sessions/:id/apply[?turn=T]` | `turn`: a turn id or a prefix (none: the latest review turn with a reply) | 200 `{text, turn_id, author, author_name}`: the Apply turn for the composer, never sent | 404 `not_found` (no such turn, no review turn), 400 `not_review_turn` (an owner's turn), 409 `no_reply` |

data/docs/internals/remote-sessions.md

@@ -268,6 +268,8 @@ with a "Machine-local" comment; the rest branch on `@access.remote?` (`SendComma
   `spec/terminal_ui/remote_connector_spec.rb`, `spec/remote_attach_command_spec.rb`,
   `spec/session_access/remote_attach_spec.rb` (wake, worker, feature check through `RackTransport`), and bin/chi's
   branch in `spec/session_access_dispatch_spec.rb`.
+  The saved-history rendering is the same `TerminalUI::JoinReplay` as local attaches; its saved-record reads use
+  the injected link.
 - By hand: the smoke-run skill (`.claude/skills/smoke-run`, kept in the checkout, not in git) covers chi web; its
   cli-tui recipe has remote attach on one machine (two isolated envs, `chi remote add self http://<LAN IP>:PORT`, the
   terminal's commands through chi web). The real lane is laptop → Studio over the LAN: `chi remote add`, `send --new --wait`,

data/docs/sessions.md

@@ -19,7 +19,7 @@ Sessions are plain files — no DB. Each session is `~/.local/state/samagotchi/s
 
 A session is deleted if **expired by age OR overflow by count** (unless `keep_status` or the live-owner guard: a session a worker or `chi` still has open is never pruned). A session's `status` is its turn state (`idle`/`running`), not whether a worker is alive. Orphan dirs without a `*.json` are never deleted, except skeleton-only ones (see *Empty sessions*). Deletion removes both `*.json` and sidecar dir atomically. Set both `DAYS=0` and `MAX=0` to retain forever.
 
-**Worker idle exit:** a background worker (plain `chi`, Web UI sessions) exits after `SAMAGOTCHI_SESSION_IDLE_EXIT_MINUTES` (`session.idle_exit_minutes`, default `30`, `0`=never) with no turn running or queued, no client on its stream (an open web tab or attached terminal keeps it), no reminder registered, no background task it watches for a [finish wake](internals/background-tasks.md#finish-wake) still running or waiting for its wake turn (with `session.task_wakes: wake`; not one whose turn you stopped) and no continue offer (the step-limit question) waiting for an answer. It removes `bridge.json` and frees `owner.lock`; the next prompt or `--attach` wakes a new worker (`WorkerIdleExit`, `SessionManager.run_session_loop`). As its Bridge stops, the worker marks the lock leaving (`OwnerLock#mark_leaving`: `leaving_at`, and `leave_wait`, its `recap.timeout`), since it keeps the lock while it writes the recap on leave: an `--attach` or `--resume` meanwhile (here, or a remote one through chi web's wake) prints `(waiting for the session to finish its recap…)` (`LaunchMode::RECAP_WAIT`) and waits for the release, up to that budget plus `OwnerLock::LEAVE_MARGIN` (5 s), before starting the new worker (`OwnerLock.await_release`). A lock held by a worker that isn't leaving (a live one, a stuck one) is left as before. A client can also ask the worker to exit right away (Bridge `POST /session/:id/exit`; `/exit` in an attached terminal does, `/detach` doesn't): the same rules apply without the timeout (even with `0`), and the asker's own stream doesn't count. The reply names what keeps it up (for background tasks, which ones and how to stop them). When every hold is one the user can stop — reminders, a watched task still running, a delegate with a live worker — the 409 also carries `holds: [{kind:, items: [{id:, label:, detail:}]}]` (a reminder's detail is its schedule, `every 20m`/`every 1h`, `, due now` when it is already due), and an attached terminal asks what to do with them; its "stop them and exit" posts `{"stop": "all"}`, which clears the reminders, stops those tasks (`TaskRuntime.stop_task`, as `task_stop`) and stops those children (`SessionManager.stop_session`) before leaving, re-checking first that nothing the user can't stop appeared meanwhile (`HoldStop`). A delegate counts only for that ask: it never holds the idle exit, and an exit that deletes or archives the session does not ask about it. The session's status stays as it was, not `stopped`. With `"restart": true` (a worker whose sidecar lists the `restart` feature) the worker hands the session to a new worker on the newest chi installed: it leaves, then starts its successor once its lock is free, keeping even an empty session and writing no recap. Clients' streams don't hold a restart (a web tab and an attached terminal reconnect to the new worker); what would be lost does: a turn running or queued, a continue offer, a question or approval waiting, reminders, a `/btw` (or another anytime command) still running, a delegate's approval relay open or settled in the last 10 minutes, and background tasks this conversation started that still run (`WorkerIdleExit#hold_for_restart`; 409 `held` with `reason`). What lives only in the worker's memory goes: the event history a late client replays, the kept `/btw` answers, a plugin's in-memory state.
+**Worker idle exit:** a background worker (plain `chi`, Web UI sessions) exits after `SAMAGOTCHI_SESSION_IDLE_EXIT_MINUTES` (`session.idle_exit_minutes`, default `30`, `0`=never) with no turn running or queued, no client on its stream (an open web tab or attached terminal keeps it), no reminder registered, no background task it watches for a [finish wake](internals/background-tasks.md#finish-wake) still running or waiting for its wake turn (with `session.task_wakes: wake`; not one whose turn you stopped) and no continue offer (the step-limit question) waiting for an answer. It removes `bridge.json` and frees `owner.lock`; the next prompt or `--attach` wakes a new worker (`WorkerIdleExit`, `SessionManager.run_session_loop`). As its Bridge stops, the worker marks the lock leaving (`OwnerLock#mark_leaving`: `leaving_at`, and `leave_wait`, its `recap.timeout`), since it keeps the lock while it writes the recap on leave: an `--attach` or `--resume` meanwhile (here, or a remote one through chi web's wake) prints `(waiting for the session to finish its recap…)` (`LaunchMode::RECAP_WAIT`) and waits for the release, up to that budget plus `OwnerLock::LEAVE_MARGIN` (5 s), before starting the new worker (`OwnerLock.await_release`). A lock held by a worker that isn't leaving (a live one, a stuck one) is left as before. A client can also ask the worker to exit right away (Bridge `POST /session/:id/exit`; `/exit` in an attached terminal does, `/detach` doesn't): the same rules apply without the timeout (even with `0`), and the asker's own stream doesn't count. The reply names what keeps it up (for background tasks, which ones and how to stop them). When every hold is one the user can stop — reminders, a watched task still running, a delegate with a live worker — the 409 also carries `holds: [{kind:, items: [{id:, label:, detail:}]}]` (a reminder's detail is its schedule, `every 20m`/`every 1h`, `, due now` when it is already due), and an attached terminal asks what to do with them; its "stop them and exit" posts `{"stop": "all"}`, which clears the reminders, stops those tasks (`TaskRuntime.stop_task`, as `task_stop`) and stops those children (`SessionManager.stop_session`) before leaving, re-checking first that nothing the user can't stop appeared meanwhile (`HoldStop`). A delegate counts only for that ask: it never holds the idle exit, and an exit that deletes or archives the session does not ask about it. The session's status stays as it was, not `stopped`. With `"restart": true` (a worker whose sidecar lists the `restart` feature) the worker hands the session to a new worker on the newest chi installed: it leaves, then starts its successor once its lock is free, keeping even an empty session and writing no recap. Clients' streams don't hold a restart (a web tab and an attached terminal reconnect to the new worker); what would be lost does: a turn running or queued, a continue offer, a question or approval waiting, a `/btw` (or another anytime command) still running, a delegate's approval relay open or settled in the last 10 minutes, and background tasks this conversation started that still run (`WorkerIdleExit#hold_for_restart`; 409 `held` with `reason`). Reminders go along: as it leaves, the worker writes them to `<id>/reminders.json` (0600: `session_id`, `written_at`, and each reminder's id, name, description, interval and next fire as wall-clock time; `ReminderCarry`), and its successor reads and deletes the file as it starts, before its idle scheduler runs. A restored reminder keeps its id and schedule; one that came due meanwhile fires once at once, and one further ahead than its interval (a clock that jumped) is due one interval from now. The file counts only for the same session within 2 minutes of `written_at`, and not once the session is stopped: otherwise it is deleted unread (log `reminders_carry_dropped`, at warn unless the session was stopped). A stop that lands while the worker leaves for a restart wins: the worker writes no file, and no successor starts (`SessionManager.run_session_loop`, log `restart_dropped`); an archive deletes the file of each session it archives. Once an exit or restart is taken, a later exit request (a stop-all from another terminal) is answered as that same exit: the first one decides how the worker leaves. A write that fails keeps the worker up with its reminders (log `reminders_carry_failed`), and the caller reports no new worker. A reminder already due when the restart is asked runs its turn first, so the restart's wait (10 s) may report no new worker yet though the hand-off follows. A worker from before this still refuses a restart for its reminders (409 `reminders`). Only an asked restart carries them: the fallback's TERM (a worker that can't be asked, below), a stop, an idle exit (which reminders hold anyway) and a crash drop them as before. What lives only in the worker's memory goes: the event history a late client replays, the kept `/btw` answers, a plugin's in-memory state.
 
 **Empty sessions:** a session nothing happened in is deleted when it is left, so `chi` → `/exit` leaves no trace. Empty means: no messages, no turn tried (a failed turn leaves a `last_prompt` and keeps it), no memory used, no pending question, nothing in `input/`, `notes/` or `images/`, nothing in its dir beyond the worker's skeleton, mode `assist`, and the default model. A session on another model (`/model`, `--model`) counts as prepared and stays (`SessionManager.discardable?`). The worker checks as it idle-exits or leaves on a client's request and deletes it once its lock is free, checking again first. The attached `/exit` then says `Detached; the session is empty: it will be discarded if nothing arrives before its worker stops.` (a note or prompt landing first keeps it). The REPL (`--no-shared`) does the same at `/exit` or Ctrl-D. The retention sweep catches those killed first: empty sessions over an hour old with no live owner, whatever `DAYS`/`MAX`, and skeleton-only dirs with no `*.json`. `session.keep_empty: true` (env `SAMAGOTCHI_SESSION_KEEP_EMPTY`) turns all of it off.
 
@@ -33,7 +33,7 @@ A session is deleted if **expired by age OR overflow by count** (unless `keep_st
 
 **A worker killed mid-turn:** while a turn runs, its worker keeps it on disk (`TurnCheckpoint`): the session file has the turn so far (the prompt from the turn's start, then the finished tool steps and lines merged into it) and `interrupted_turn: {id, started_at, at, iteration, enqueued_id}` (`enqueued_id`: the input the turn runs, so any process can tell which turn is running; a continue turn carries its offer turn's), written as the turn starts, at the loop's first iteration boundary and then at most every 10 s (`updated_at` moves with it). The turn's end saves the real messages without the mark. A worker that died without ending its turn (SIGKILL, a crash of the process) leaves the mark, and loses what came after its last written boundary: at most the last 10 s of steps, plus the step in flight. Each checkpoint write also saves the turn's metrics so far to `analytics.json` (tokens, speeds, timings, its finished tool calls), as the record a killed turn leaves: canceled, `cancellation_reason: worker_stopped`; the turn's own end writes over it. The next worker to start for the session (a `chi send`, `--resume`, `--attach`, the web), or a `--no-shared` REPL resuming it, settles the turn before anything else (`TurnCheckpoint.settle`, log `interrupted_turn_settled`): a note `the previous turn was cancelled (worker-stopped) after Ns` goes at the tail, the status goes idle and the mark goes; `last_turn` stays the previous turn's (a new one saved before the turn a `chi send --wait` woke the worker for would end that wait at once); the dead turn's end is recorded under its `enqueued_id` instead, in `<id>/input/settled/<enqueued_id>` (a `last_turn` record: canceled, `cancel_reason: worker_stopped`), which only a wait for that very turn reads (`chi send --queue --wait`, a `chi send --wait -m` to an idle session or `--new`, `chi send --wait ID --turn`, a continue's wait): it ends `canceled` with `cancel_reason: worker_stopped`, detail "its worker exited mid-turn", instead of timing out. A wait with no turn id that saw the turn running ends the same way when the settle comes (`chi send --wait ID` with no message on a turn with no id, such as a session's first prompt or a reminder turn; a message merged into the turn as a steer), unless an input still waits or was claimed since: an unmerged message runs as its own turn next, and that turn's end is the answer. A reply the turn wrote before its worker died is still its answer. The session shows the turn's prompt and steps with that note; the dead turn is not run again, and the model reads on its next turn that it was cut.
 
-**Stopping a worker:** `chi sessions stop ID` marks the session stopped (an empty `<id>/stopped` file, not a session.json field, which a worker saving at that moment would write over; a resume removes it), sends its worker TERM and waits (up to 10 s) until the worker has let go of `owner.lock`. A running turn is canceled over the Bridge first, with reason `session_stopped` (the turn's line ends "(session stopped)", its note says `cancelled (session-stopped)`, and a command it was running says "stopped as the session was stopped"; a bare signal to the worker makes it "stopped by a signal to chi"; an older worker takes the reason as `manual`); the TERM stops whatever still runs as a Stop with reason `signal` and saves it (a spawned worker traps TERM, HUP and INT: `WorkerSignals`; a turn not ended within 3 s, 0.5 s after a stop or a second signal, is cut and the session saved as it was), and a stopped worker still saves its kept turn, since the marker, not the saved status, says stopped. Any TERM, HUP or INT does the same to a worker outside a stop: it leaves (log `worker stop reason=signal`) and the next send wakes a new one, so a `chi --resume ID` right after spawns a fresh worker. That is also how to restart a worker still running an older chi, which the attached terminal reports when a command or a question dismiss gets a 404, and the web when an answer, a dismiss, a command or a cancel does (`501 not_supported`; `BridgeClient.stale_worker_message`). A command this chi has that the older worker doesn't (`/llm-context`, the web's `llm ctx` chip, against a 0.39.0 worker) says the same, not `not a session command` (`SessionCommands.builtin_name`); a typo keeps its `400 unknown_command`. The web's `POST /api/sessions/:id/stop` waits the same way, for 2 s (the page's Stop shows the stop at once), or for the body's `wait` up to the same 10 s (`SessionManager::STOP_WAIT`): `chi --remote NAME sessions stop` sends it, so it waits as long as here. Before that stop, the page's `stop session` button asks what the worker still has that the user can stop: `GET /api/sessions/:id/holds` (owner-only) answers the worker's `holds` — the same list the exit ask's 409 carries — always an array, empty when there is no live worker, one from before the route, or one that did not answer. With something, a sheet (a bottom sheet on a phone, a popover at the button otherwise — `stop_sheet.js`) lists them, at most three of a kind named and `+N more`, and offers **Stop all** (`POST /api/sessions/:id/holds/stop` → `HoldStop#stop_all`, then the stop), **Stop session only** (the stop exactly as it was) or **Cancel**. Nothing to ask about is the plain confirm, one tap as before. Both buttons stay because a stop only TERMs the worker: its reminders die with it, while a background task and a delegate are their own processes and keep running. A command sent during a turn that waits for its end (`/model X`, `!cmd`; see *Typing during a turn* in [cli.md](cli.md)) and hasn't run when the worker leaves (a stop, a crash) is answered `command_ran {status: "dropped"}`, so no UI keeps showing it waiting.
+**Stopping a worker:** `chi sessions stop ID` marks the session stopped (an empty `<id>/stopped` file, not a session.json field, which a worker saving at that moment would write over; a resume removes it), sends its worker TERM, then CONT (a stopped worker, SIGSTOP or Ctrl-Z, runs its TERM handler only once continued, so it leaves at once instead of outliving the wait), and waits (up to 10 s) until the worker has let go of `owner.lock`. A running turn is canceled over the Bridge first, with reason `session_stopped` (the turn's line ends "(session stopped)", its note says `cancelled (session-stopped)`, and a command it was running says "stopped as the session was stopped"; a bare signal to the worker makes it "stopped by a signal to chi"; an older worker takes the reason as `manual`); the TERM stops whatever still runs as a Stop with reason `signal` and saves it (a spawned worker traps TERM, HUP and INT: `WorkerSignals`; a turn not ended within 3 s, 0.5 s after a stop or a second signal, is cut and the session saved as it was), and a stopped worker still saves its kept turn, since the marker, not the saved status, says stopped. Any TERM, HUP or INT does the same to a worker outside a stop: it leaves (log `worker stop reason=signal`) and the next send wakes a new one, so a `chi --resume ID` right after spawns a fresh worker. That is also how to restart a worker still running an older chi, which the attached terminal reports when a command or a question dismiss gets a 404, and the web when an answer, a dismiss, a command or a cancel does (`501 not_supported`; `BridgeClient.stale_worker_message`). A command this chi has that the older worker doesn't (`/llm-context`, the web's `llm ctx` chip, against a 0.39.0 worker) says the same, not `not a session command` (`SessionCommands.builtin_name`); a typo keeps its `400 unknown_command`. The web's `POST /api/sessions/:id/stop` waits the same way, for 2 s (the page's Stop shows the stop at once), or for the body's `wait` up to the same 10 s (`SessionManager::STOP_WAIT`): `chi --remote NAME sessions stop` sends it, so it waits as long as here. Before that stop, the page's `stop session` button asks what the worker still has that the user can stop: `GET /api/sessions/:id/holds` (owner-only) answers the worker's `holds` — the same list the exit ask's 409 carries — always an array, empty when there is no live worker, one from before the route, or one that did not answer. With something, a sheet (a bottom sheet on a phone, a popover at the button otherwise — `stop_sheet.js`) lists them, at most three of a kind named and `+N more`, and offers **Stop all** (`POST /api/sessions/:id/holds/stop` → `HoldStop#stop_all`, then the stop), **Stop session only** (the stop exactly as it was) or **Cancel**. Nothing to ask about is the plain confirm, one tap as before. Both buttons stay because a stop only TERMs the worker: its reminders die with it (a stop also deletes a restart's `reminders.json` no successor took yet, so a later resume doesn't bring them back), while a background task and a delegate are their own processes and keep running. A command sent during a turn that waits for its end (`/model X`, `!cmd`; see *Typing during a turn* in [cli.md](cli.md)) and hasn't run when the worker leaves (a stop, a crash) is answered `command_ran {status: "dropped"}`, so no UI keeps showing it waiting.
 
 **Deleting a session:** `chi sessions delete ID...`, `/exit --delete` in a terminal and the Web UI's delete all go through `SessionManager.delete_session`: it resolves a unique prefix, removes `<id>.json` and the whole `<id>/` dir, and returns what it removed. A session a plain REPL has open (`owner.lock` kind `tui`) is always refused. One a worker runs is refused unless the caller asks to stop it: then it stops the worker as `chi sessions stop` does and deletes once `owner.lock` is free (`--force` on the CLI, 10 s; the web page always, 2 s; `/exit --delete` after the worker agreed to exit, 10 s). A worker that outlives the wait leaves the session in place. The web's route is `DELETE /api/sessions/:id?force=true` (the page sends `force`; without it a live worker's session is 409 `worker_running`, as the CLI without `--force`; 200 `{status: "deleted", session_id, stopped}`; 409 `owned_by_tui` or `still_stopping`; 404).
 

data/docs/testing.md

@@ -301,7 +301,8 @@ to install). It refuses when the folder or the branch already exists.
 
 `SAMAGOTCHI_MACOS_BUILD=1 bundle exec rspec spec/desktop` also compiles the macOS helper (`:macos_build`, needs the
 Command Line Tools) and runs `ChiHelper` against a fake kitty and, when a `tmux` is on PATH, a real one (private
-`-L` servers under a temp `TMUX_TMPDIR`, killed after). Without the variable they are filtered out (CI's runs), and
+`-L` servers under a temp `TMUX_TMPDIR`, killed after), and its `--sessions`, `--send-plan` and `--broadcast` seams
+against a fake chi (a `/bin/sh` script as the launch file's argv). Without the variable they are filtered out (CI's runs), and
 `script/affected-specs` doesn't pick them for a Swift change: run them by hand after editing
 `lib/samagotchi/desktop/macos/`.
 

data/lib/samagotchi/bundles/system/manifest.yml

@@ -1,6 +1,6 @@
 ---
 name: samagotchi-system
-version: 0.123.0
+version: 0.125.0
 scope: system
 description: Default system memories — identity, self map, config modification protocol, memory guide and the delegated-session rules
 files:

data/lib/samagotchi/desktop/macos/App.swift

@@ -5,7 +5,9 @@
 // directly by chi desktop) manages the login item and exits;
 // `ChiHelper --agents list|send` is the agent terminals' seam (AgentTerminal.swift),
 // `ChiHelper --model-pick` the model chooser's (Models.swift),
-// `ChiHelper --broadcast` the Everyone row's (Broadcast.swift).
+// `ChiHelper --broadcast` the Everyone row's (Broadcast.swift),
+// `ChiHelper --sessions` and `--send-plan` the session rows' and their
+// sends' (Sessions.swift).
 import AppKit
 import ServiceManagement
 
@@ -111,6 +113,12 @@ struct ChiHelperMain {
     if args.count >= 2, args[1] == "--broadcast" {
       exit(broadcastCommand(Array(args.dropFirst(2))))
     }
+    if args.count >= 2, args[1] == "--sessions" {
+      exit(sessionsCommand(Array(args.dropFirst(2))))
+    }
+    if args.count >= 2, args[1] == "--send-plan" {
+      exit(sendPlanCommand(Array(args.dropFirst(2))))
+    }
     let app = NSApplication.shared
     let delegate = AppDelegate()
     app.delegate = delegate