samagotchi 0.152.0 → 0.154.0

data/docs/configuration.md

@@ -64,11 +64,9 @@ model_aliases:
   small: your-small-model-id
   tiny: small-box:your-small-model-id  # alias may be bare or host:model (hybrid)
 
-# Plain chi runs its session in a background worker and attaches to it, so the
-# web UI can share it (default true; env SAMAGOTCHI_SESSION_SHARED). false keeps
-# the in-process REPL; --no-shared does for one run.
+# A session runs in a background worker; chi attaches to it, and the web UI
+# shares it.
 session:
-  shared: true
   # idle_exit_minutes: 30   # an unused worker exits after this (0 = never)
   # project_env: mise      # a worker's tools get its folder's `mise env` (off: the starter's env)
   # keep_empty: false       # true keeps sessions nothing happened in (default: deleted when left)
@@ -172,7 +170,6 @@ or `chi web` restart.
 | `system_one.host`, `system_one.model`, `system_one.timeout_ms`, `system_one.runs`, `system_one.judgments` | Next tool call or approval | Each ask reads them. |
 | `hooks`, `bundles` | Worker start | Hooks, plugins and their bundle settings load with the engine. |
 | `recap.*` | Worker start | The engine builds its recap job at start, and again when it binds a session with its own `recap.enabled` or `recap.sentences` (`--set`, see "Per-session settings") and when `/recap on\|off\|default` changes the session's own value. |
-| `session.shared` | Next `chi` invocation | It selects attached-worker or in-process mode for that invocation. |
 | `session.idle_exit_minutes`, `session.project_env`, `session.carry_last_answer`, `session.keep_empty`, `session.max_children`, `session.delegate_reports`, `session.task_wakes`, `session.max_wakes` | Worker start or next matching lifecycle decision | Existing workers keep their idle-exit timer and project env; the other values are read for the next corresponding decision. |
 | `session.retention_*`, `session.max_count`, `session.keep_status`, `session.sweep_interval_hours` | Next retention sweep | `chi web` sweeps on its configured schedule and on `GET /api/sessions`; `chi sessions prune` uses the values for that invocation. The sweep interval is checked on the next hub tick. |
 | `web.*` except `web.participants.*` | `chi web` start | Restart `chi web` to change its bind address, port or page settings. |
@@ -355,10 +352,8 @@ For models on that host, chi uses the chat loop (its own OpenAI chat adapter): i
 takes the OpenAI base (`url:`, else `http://HOST:PORT/v1`) and streams messages plus
 function schemas from `/v1/chat/completions`; the model's reasoning (`reasoning_content`)
 shows as thinking. This works with Splash and with llama.cpp servers that
-expose the OpenAI-compatible chat endpoint. In verbose mode (`-v`), chi prints the loop the
-starting model uses (`[verbose] backend=chat` or `backend=native`); request
-bodies are not logged. The interactive REPL, `--prompt`,
-workers, and resumed sessions all use the loop of the model's host. Hosts without
+expose the OpenAI-compatible chat endpoint. Workers, `--non-interactive` one-shots and resumed
+sessions all use the loop of the model's host. Hosts without
 a chat `api:` keep using llama.cpp's native `/completion`.
 
 ### API keys from the Keychain
@@ -655,7 +650,7 @@ models:
   it, a delegate child starts without it (it runs at its model's level). Set it with:
   - `/thinking LEVEL` in the session (`/thinking default` unsets it, `/thinking` alone shows the level and where it
     came from);
-  - `chi --thinking LEVEL` on a run that starts or resumes a session (the REPL, `-p`, `--resume`, an attached one);
+  - `chi --thinking LEVEL` on a run that starts or resumes a session (plain `chi`, `-p`, `--resume`, an attached one);
   - `chi send --new --thinking LEVEL`;
   - the web's ⚙ panel in the session bar (its Thinking row), and the start page's ⚙ panel (`POST /api/sessions` takes `"thinking": "low"`;
     anything that isn't a level answers `400 invalid_thinking`).
@@ -849,15 +844,15 @@ first: an unknown host or a bad alias is an error at once, not a question.
   a full-prefix change also says preserved thinking in replies is dropped from then on.
 - `Nothing changed yet: send /thinking low --yes to apply.` names the line that applies it.
 - `--yes` (or `-y`, anywhere after the command) applies it at once.
-- The terminal (the REPL and an attached TUI) puts the `--yes` line in the next input: Enter applies it.
+- The attached terminal puts the `--yes` line in the next input: Enter applies it.
 - The web's reply bubble has an **Apply (restarts the cache)** button. The session bar's ⚙ panel is already an
   explicit choice: a tap sends the `--yes` line, and its note says what a change costs. Command bubbles are page-only, so
   the button is gone after a reload.
 - Only a person at a web tab or a chi TUI is asked. `chi send ID "/thinking low"`,
-  `chi -p "/thinking low" --non-interactive`, lines piped into the REPL, a delegate, a plugin and a card's action
+  `chi -p "/thinking low" --non-interactive`, a delegate, a plugin and a card's action
   apply directly, since nobody would see the question; so do the start flags (`chi --thinking`, `--model` and
   `--llm-context` on a resumed or attached session send `/thinking LEVEL --yes`, `/model NAME --yes` and
-  `/llm-context … --yes`). A plain `chi -p` opens the REPL, which asks.
+  `/llm-context … --yes`).
 
 ## Llama HTTP Timeouts
 
@@ -1107,7 +1102,7 @@ retry:
 `retry.empty_answer` is a different thing: the request worked, but the model's answer had no visible text and no
 tool calls (thinking only, or nothing; a thinking loop cut by the provider's output cap looks like this). chi then
 asks again in the same turn with a hidden note ("your last reply had no visible answer…"), at `temperature: 0.6`
-unless `sampling:` sets one; the REPL prints `↻ empty answer, asking again (1/1)` and the web shows it as a row of
+unless `sampling:` sets one; the terminal prints `↻ empty answer, asking again (1/1)` and the web shows it as a row of
 the step. `retry.empty_answer` (default `1`, at most `3`, env `SAMAGOTCHI_RETRY_EMPTY_ANSWER`, no CLI flag) is how
 many times per turn; `0` ends the turn at the empty answer as before. An answer cut because the context is full
 (90 % or more) is not retried. When the retries run out the turn ends with no answer: every UI shows one muted line,
@@ -1209,8 +1204,8 @@ The turn's prompt and its completed tool calls stay in the session.
 
 ## Debug Log File
 
-Every `chi` process (the REPL, the attached terminal, the background
-workers, `chi web`) appends tagged records to one log file, so you can see
+Every `chi` process (the attached terminal, a `--non-interactive` one-shot,
+the background workers, `chi web`) appends tagged records to one log file, so you can see
 what happened in a session, what went over the wire and why something
 failed, without `--verbose`.
 
@@ -1248,9 +1243,10 @@ One record is one line, plus indented payload lines at debug level:
   space, quote or `=` is a JSON string, so a record never spans lines;
   control characters (terminal colours in tool output) are escaped.
 - Tags: `turn` (a session's event trail), `http` (model requests),
-  `worker`, `bridge`, `web`, `attached`, `repl`, `idle`, `recap`, `hooks`,
+  `worker`, `bridge`, `web`, `attached`, `idle`, `recap`, `hooks`,
   `plugins`, `guardrails`, `config`, `memory`, `model` (debug dumps), `context` (attached context fetches),
-  `broadcast` (chi broadcast's triage).
+  `broadcast` (chi broadcast's triage), `toolkit`, `system_one`, `prompt` (a system prompt section left out
+  after an error).
 - The format is parsed by `Samagotchi::LogLine` (`parse`, `each_record`);
   keep tools that read it on that parser.
 
@@ -1259,7 +1255,9 @@ What each level adds:
 - `error`: crashes (a worker, a bridge connection, the idle scheduler, a
   recap) with the first 20 backtrace frames; failed model requests.
 - `warn`: retries (429, 5xx, network), failed turns, hook and guardrail
-  problems, config warnings. Warnings `chi` prints on stderr are logged too,
+  problems, config warnings, and a fallback after an error (a prompt section or a
+  Bridge reply chi left out, `Degrade`): once per process for each kind, later ones
+  at `debug`. Warnings `chi` prints on stderr are logged too,
   with the same text as `msg=`; a worker's (its stderr goes nowhere) now
   only reach the file.
 - `info`: turns, generations and tool calls with sizes and times (never the
@@ -1270,8 +1268,12 @@ What each level adds:
   and results, context status), probes and model lists, every web API and
   bridge request.
 
-`-v`/`--verbose` (the plain REPL only) logs at `debug` and prints every
-record to stderr as well.
+`-v`/`--verbose` logs at `debug`, in this chi and in a worker it starts
+(a worker that was already running keeps its own level, and a one-line note
+says so: one `chi web` started may log to another file). The attached
+terminal shows the session's records (by `sid`) dim, above the prompt, as
+they come; a `--non-interactive` one-shot prints every record to stderr
+as well.
 
 ### Rotation and secrets
 
@@ -1476,8 +1478,8 @@ work tree top when inside it, else with `~`.
   every request`). The files are saved in the session (`appended_prompt_files`),
   so a respawned worker builds the same prompt, and a fork or a continue keeps
   them; a delegate child doesn't. With `--attach` or `--resume` the flag is
-  ignored with one line, as `--memory` is; a REPL `--resume` (`--no-shared`)
-  adds them for that run only.
+  ignored with one line, as `--memory` is; a `--resume ID --non-interactive`
+  one-shot adds them for that run only.
 - The files' text is read at each prompt build, as AGENTS.md's is: an edit is
   picked up by a new process or a rebuild (`/model`). `/stats` lists the files
   in the prompt on its `prompt files:` line.
@@ -1501,17 +1503,18 @@ toolkit:
 
 | toolkit | declares |
 |---|---|
-| `full` | every built-in; the default |
+| `full` | every built-in and every plugin tool (a bundle's `chi.tool`, such as `web_search`); the default |
 | `lean` | `execute`, `read`, `write`, `edit`, `memory_read`, `memory_write`, `task_create`, `task_wait`, `task_get`, `task_list`, `task_stop`, `ask_user_question`, `web_fetch`, `context_read` |
 | `child` | `lean` plus `send_note`, without `memory_write`, `delegate`, `delegate_result` |
 | `coordinator` | `lean` plus `delegate`, `delegate_result`, `list_sessions`, `objectives` (declared by the coordinator bundle) |
 | `coding` | `child`, with the prompt text `- Be concise in your responses` / `- Show file paths clearly when working with files` (declared by the coordinator bundle, for build and fix children) |
 | `review` | `read`, `memory_read` (not `forget_outputs`, even under the `forget` layer): what a [participant's](internals/participants.md#turns) turn may call, whatever the session declares (the review boundary, [guardrails](guardrails.md#a-participants-review-boundary)). Reserved: `toolkit.kits.review` is refused ("review is reserved for participants' turns"), and a bundle can't declare it. A session may run on it too, as any kit |
 
-- **Plugin tools** are declared in every toolkit unless its `remove:` names them, and so is `forget_outputs` under
-  the `forget` layer. A `kits:` entry takes `base:` (default `full`), `add:`, `remove:`, `prompt:`, `groups:` and
-  `description:`
-  (any other key, a typo or a `tools:` list, is ignored with a warning); it can't reuse a built-in's name
+- **Plugin tools** (a bundle's `chi.tool`, such as web-search's `web_search`) follow a kit's list as built-ins do:
+  `full` (and every kit on `base: full`, the `kits:` default) declares them, another kit leaves them **reachable**
+  (below) unless its `remove:` names them, and `add:` declares one (`search: { base: lean, add: [web_search] }`).
+  `forget_outputs` is declared in every toolkit under the `forget` layer, unless removed. A `kits:` entry takes
+  `base:` (default `full`), `add:`, `remove:`, `prompt:`, `groups:` and `description:` (any other key, a typo or a `tools:` list, is ignored with a warning); it can't reuse a built-in's name
   (`review`'s least of all: it is the participants' boundary). A bundle declares its own with `chi.toolkit`
   ([plugins](plugins.md#chitoolkitname-base-add--remove--prompt-nil-groups-nil-description-nil)).
   `description:` is optional classifier input, up to 300 characters; it is not included in the session prompt.
@@ -1565,7 +1568,7 @@ toolkit:
   reaches none. A kit whose base doesn't resolve (an unknown name, a cycle) falls back to `full`, which reaches
   every group.
   A selector that matches no group in that load-time snapshot warns once. `find_tools` and `call_tool` are
-  declared only when the toolkit reaches a source group or has a reachable built-in. Calls naming an unreached
+  declared only when the toolkit reaches a source group or has a reachable tool (a built-in or a plugin tool). Calls naming an unreached
   group are refused before guardrails and do not start its server. The first-run init wait is unchanged: it can
   still block the first turn even when its server's group is unreached; `start: eager` and stale-cache refreshes
   also still start. `/mcp` marks servers outside the current toolkit.
@@ -1599,17 +1602,21 @@ toolkit:
   them with `/toolkit`. The configured default is always listed. A pick closes the list and shows a `tools: lean`
   chip on the row (a dot on 🧰 on a phone); it is for that create only, never remembered. A review session is
   always `chosen`: with review files set the list says it starts on the default unless you pick a kit.
-- **Left out: reachable or removed.** A built-in missing from a kit's base list (`lean` has no `delegate`; a
-  `kits:` entry on `base: lean` or `child` inherits that) is left out softly: it is **reachable**. `find_tools` searches it as group `chi` (`chi/delegate`, with its inputSchema) beside
-  the MCP servers' tools, and `call_tool(tool: "chi/delegate", args: {…})` runs it as `delegate` itself, through the
-  usual guardrails, approvals and hooks ([plugins](plugins.md#chitool_sourcecall-acts_as-label-wait-prefix)). A
+- **Left out: reachable or removed.** A built-in or plugin tool missing from a kit's base list (`lean` has no
+  `delegate` and no `web_search`; a `kits:` entry on `base: lean` or `child` inherits that) is left out softly: it
+  is **reachable**. `find_tools` searches it as group `chi` (`chi/delegate`, `chi/web_search`, with its
+  inputSchema) beside the MCP servers' tools, and `call_tool(tool: "chi/delegate", args: {…})` runs it as `delegate`
+  itself, through the usual guardrails, approvals and hooks ([plugins](plugins.md#chitool_sourcecall-acts_as-label-wait-prefix)). A
   tool in a toolkit's `remove:`, a `--no-tool` or a `/toolkit remove` is **removed**: hard, also after an add, and
   call_tool can't reach it (`child` removes `memory_write`, `delegate` and `delegate_result`, so a child on it
-  starts no children). To keep a built-in away from the model, name it under `remove:`. `find_tools` and `call_tool`
-  are declared when a toolkit has a reachable built-in or reaches a source group; `full` with no reachable source
-  declares neither, and removing them there (`--no-tool call_tool`) leaves nothing out: no prompt line, no chip.
+  starts no children). To keep a tool away from the model, name it under `remove:`. `find_tools` and `call_tool`
+  are declared when a toolkit has a reachable tool or reaches a source group, as the tools stood when the
+  session's worker started; `full` with no reachable source declares neither, and removing them there
+  (`--no-tool call_tool`) leaves nothing out: no prompt line, no chip. A plugin tool that arrives later
+  (`chi.replace_tools`) on a kit that declared neither stays out of reach for that worker, with one warn notice
+  (`/toolkit add NAME` declares it).
 - **On `api: anthropic`, reachable tools are callable by name.** Every tool `call_tool` reaches (the reachable
-  built-ins, tools from reached MCP groups as `mcp_<server>_<tool>`) also goes in the request's tools deferred
+  built-ins and plugin tools, tools from reached MCP groups as `mcp_<server>_<tool>`) also goes in the request's tools deferred
   (`defer_loading`: Messages keeps them out of the model's view until something loads them, at a flat ~100 tokens).
   A direct call of one (`list_sessions`, `mcp_fs_read`) runs, under the same guardrails, approvals and rows as
   through `call_tool` (an MCP tool's call is `call_tool`'s). A `find_tools` hit **loads** its matches (up to 5):
@@ -2210,7 +2217,7 @@ column says so, a `--kebab-name` flag. The maps (`hosts:`, `models:`,
 | `recap.timeout` | `30` | yes | Seconds a recap request may take. |
 | `recap.min_user_turns` | `2` | yes | Prompts a session needs before it gets a recap. |
 | `recap.sentences` | `2-4` | yes | Recap length, `N` or `N-M` (1–10). Per session too: `--set recap.sentences=3`. |
-| `broadcast.active_hours` | `8` | | `chi broadcast` reaches a session a worker or a chi REPL runs, or whose last turn ended within this many hours. See [Broadcast](broadcast.md). |
+| `broadcast.active_hours` | `8` | | `chi broadcast` reaches a session a worker or a one-turn `--non-interactive` run has, or whose last turn ended within this many hours. See [Broadcast](broadcast.md). |
 | `broadcast.ticket_pattern` | `\b[A-Z][A-Z0-9]+-\d+\b` | | A Ruby regex for ticket ids; one in the note and in a session's branch (any case) or prompts delivers the broadcast there. See [Broadcast](broadcast.md). |
 | `broadcast.triage_model` | recap's | | The model that judges a recipient no tag matched (a model ref, as `recap.model`); unset: the recap's model, else `default.model`. A ~9B dense instruct model or larger; 4B-class ones say yes to nearly everything. See [Broadcast](broadcast.md#triage). |
 | `broadcast.triage_host_ref` | none | | A `hosts:` name for the triage model. |
@@ -2218,7 +2225,6 @@ column says so, a `--kebab-name` flag. The maps (`hosts:`, `models:`,
 | `broadcast.triage_parallel` | `4` | | Triage requests at a time. |
 | `broadcast.triage_deadline` | `20` | | Seconds triage may take in all; a recipient not judged by then gets the note unchecked. |
 | `broadcast.threshold` | `0.5` | | The P(yes) a recipient needs, when the triage host gives logprobs; a plain yes or no is 1 or 0. |
-| `session.shared` | `true` | | Plain `chi` runs its session in a worker and attaches; `--no-shared` per run. |
 | `session.idle_exit_minutes` | `30` | yes | An unused worker exits after this; `0` = never. |
 | `session.project_env` | `mise` | | The commands a session's worker runs follow its project: `mise` runs them in the session folder's `mise env`, read once at worker start (`chi sessions restart` picks up a mise.toml edit); `off` doesn't ask mise: the tools keep the env of whoever started the worker (with a chi home, the home's `chi` still goes first on their PATH). See [Project env](sessions.md#project-env). |
 | `session.carry_last_answer` | `true` | | A continue's carry note holds the previous session's last answer after its recap; `false`: the recap only. See [Session chains](sessions.md#session-chains). |
@@ -2250,7 +2256,7 @@ column says so, a `--kebab-name` flag. The maps (`hosts:`, `models:`,
 | `log.file` | state dir | yes | See "Debug Log File". |
 | `log.disable` | `false` | yes | No file logging. |
 | `log.level` | `info` | yes | `debug`, `info`, `warn`, `error`. |
-| `status.line` | `on` | yes | The status row under the prompt (the REPL's and attached mode's), `on` or `off`. |
+| `status.line` | `on` | yes | The status row under the attached terminal's prompt, `on` or `off`. |
 | `context.status` | `true` | yes | Context-usage telemetry for the model. See [context telemetry](internals/context-telemetry.md). |
 | `context.window_tokens` | server's, else 256000 | yes | Context window when the server doesn't report one. `models.<key>.window_tokens` and `hosts.<name>.window_tokens` come first; see "The context window". |
 | `models.<key>.window_tokens`, `hosts.<name>.window_tokens` | none | | A model's or host's context window when the server and its model list report none. |

data/docs/context.md

@@ -617,13 +617,13 @@ show the answer as it is.
   after a push links may be a few lines off until the next read. Without
   `gh` or its login, nothing is linked.
 - **Where it reads**: only in a session worker (the web, an attached chi),
-  whose answers the web shows while the session runs. The REPL and
-  `chi -p` read nothing (no `gh api` calls), so their answers have no links,
+  whose answers the web shows while the session runs. A
+  `chi -p … --non-interactive` run reads nothing (no `gh api` calls), so its answers have no links,
   in the web too; a scratch session never reads. The PR itself is still
   attached and its context still reaches the model everywhere.
 
 `line_links:` takes `false` (off), `true` (the default: a worker only) or
-`always` (the REPL and `chi -p` read too, so their answers are linked when
+`always` (a `chi -p … --non-interactive` run reads too, so its answers are linked when
 you open the session in the web later):
 
 ```yaml

data/docs/desktop.md

@@ -80,7 +80,7 @@ models and aliases (from [`chi models`](cli.md#listing-the-models)), at most nin
 The chooser needs a chi with `chi models`: an older helper works with a newer chi, not the reverse
 (`chi desktop upgrade` after updating chi).
 
-A session open in a `chi --no-shared` REPL isn't listed: it takes no notes or messages.
+A session a one-turn `chi -p … --non-interactive` run has isn't listed: it takes no notes or messages.
 
 ## Images
 

data/docs/guardrails.md

@@ -23,7 +23,7 @@ The UI shows the tool line first, then the approval under it.
 
 ## Ask
 
-The REPL, the attached TUI and the web show what would run, where and why:
+The attached TUI and the web show what would run, where and why:
 
 ```
 Approve tool call?
@@ -65,8 +65,7 @@ card comes back through `ApprovalFacts.from_h` (string or symbol keys, missing f
 
 Who answers:
 
-- REPL (`chi --no-shared`, with or without `-p`): at the `? ` prompt.
-- A shared session's worker (plain `chi` and `chi -p …` while `session.shared` is on, the default): any attached TUI or web page. With none attached,
+- A session's worker (plain `chi`, `chi -p …`, the web): any attached TUI or web page. With none attached,
   the approval waits (in the session file) and shows on attach.
 - `-p … --non-interactive`: nobody; the call is denied ("No one to approve it
   (non-interactive run)").
@@ -134,7 +133,7 @@ others come back to the parent's model with the block below. A dismissal
 always passes (the hook decides what no answer means): the strategy is a
 convention for an honest parent, not a barrier. This section is
 the path for other agents, and for a chi parent that can't host the relay (a
-`--no-shared` REPL, `--non-interactive`): there the model gets the question
+`--non-interactive` one-shot): there the model gets the question
 block and the rules below. With the relay, the same rules still hold for a
 parent model that answers its own relay card (a piped or marked `chi --attach`
 on the parent): that answer is a parent agent's, checked by the parent and
@@ -197,10 +196,10 @@ value that isn't a level reads as `hard`.
 config.yml's; `/parent-answers LEVEL` sets the session's own, `/parent-answers
 default` drops it (config.yml's applies). Anyone may tighten it, a parent too
 (`chi send ID -m "/parent-answers hard"`). Loosening it (toward `soft`, or
-`default`) is yours alone: the line must come from you at the REPL, an attached
+`default`) is yours alone: the line must come from you at an attached
 terminal or the web composer. chi refuses it (`loosening parent_answers is the
 user's: …`) from `chi send` (a parent's or yours: the worker can't tell them
-apart), from a piped or marked `chi --attach` or REPL, from `chi -p
+apart), from a piped or marked `chi --attach`, from `chi -p
 --non-interactive`, from a delegate's follow-up and from a plugin; `chi answer`
 has no command route. `--parent-answers` on `--attach`/`--resume` is ignored,
 never sent as the command.
@@ -277,7 +276,7 @@ no running turn, pending question or approval, queued prompt, or running
 background task; when one exists, stop it explicitly and then send a prompt.
 
 A parent may also type its answer into chi itself: a piped `chi --attach ID`
-or `printf '2\n' | chi --no-shared -p …`. So chi treats an answer as a
+or `printf '2\n' | chi -p …`. So chi treats an answer as a
 parent's, held to the same setting, when its input isn't a terminal or an
 agent marker is set: `CLAUDECODE` (Claude Code), `AI_AGENT`, `CODEX_THREAD_ID`
 (Codex CLI), or `SAMAGOTCHI_PARENT_SESSION`,
@@ -841,11 +840,13 @@ trade-off, when such a clash exists:
 - deny rules cover both, which is the point.
 
 A `call_tool` of one of chi's own tools (`chi/delegate`: a built-in the
-session's toolkit leaves out, [toolkits](configuration.md#toolkits)) is
-gated **as that tool**: it is turned into the `delegate` call before the
-guardrails run, so every rule on `delegate` (or `execute`'s `command:`, the
-`rm` check, a delegate child's boundary) gives the same verdict as for a
-direct call, and an approval is keyed `delegate:…` either way. `tool:
+session's toolkit leaves out, [toolkits](configuration.md#toolkits)), or of
+a bundle's `chi.tool` it leaves out (`chi/web_search`), is gated **as that
+tool**: it is turned into the `delegate` call before the guardrails run, so
+every rule on `delegate` (or `execute`'s `command:`, the `rm` check, a
+delegate child's boundary, a plugin tool's `targets:`) gives the same
+verdict as for a direct call, and an approval is keyed `delegate:…` either
+way. `tool:
 call_tool` rules no longer see such calls, only MCP calls and misses. A
 `chi/` name the toolkit removes is refused before the gate, with no card.
 
@@ -1325,9 +1326,8 @@ allows), and how many got no judgment. `--threshold` overrides
 for this run; `--dry-run` judges and prints without writing a line. Without a
 client (`mode: off`, or no `host`) it exits 2 saying what to set.
 
-Two limits on what the replay can see: `CardStore` keeps only the last 20
-questions per session, and a `--no-shared` REPL session never writes a
-`cards.json` at all, so its asks are not replayable.
+A limit on what the replay can see: `CardStore` keeps only the last 20
+questions per session, so older asks are not replayable.
 
 ## The guardrails bundle
 

data/docs/hooks.md

@@ -97,14 +97,14 @@ class Watchful
   def call(event)
     case event[:type]
     when :after_generation
-      # One line in the REPL, the attached TUI and the web ("<bundle>> text",
+      # One line in the attached TUI and the web ("<bundle>> text",
       # or "hook> text" for a config hook); level: :warn colours it.
       # fallback_for: :display marks a line a UI that renders the answer's
       # display may leave out (below).
       event[:notify].call("the model repeated itself", level: :warn)
     when :before_tool_call
-      # A single-select question through the question flow (REPL, attached
-      # TUI, web); returns {selected: [...], freeform:, selected_indices:}
+      # A single-select question through the question flow (the attached
+      # TUI, the web); returns {selected: [...], freeform:, selected_indices:}
       # or nil when there is no one to ask (--non-interactive), the
       # question was dismissed, or the options (or effects) were invalid.
       # effects: says what an option does for a parent agent's answer (see
@@ -156,7 +156,7 @@ that a UI that already shows it can leave the line out. The main value is
 links), for a UI that doesn't render that display. The hook never names a UI;
 each decides by what it renders. The web with markdown on (`web.markdown` and
 the commonmarker gem) leaves such a line out, live and after a reload; with
-markdown off it shows, as it does in the REPL, the attached TUI and
+markdown off it shows, as it does in the attached TUI and
 `chi -p`, which print the answer as text (in the web its http(s) URLs are
 links, as in any hook's notice line). The log keeps the line with
 `fallback_for=display`. `:editor` marks a line that names a file the viewer
@@ -304,8 +304,8 @@ end
   kept), on a live turn and after a reload. Its copy button copies the
   display text. The page learns about it from an `answer_display` event
   that comes after `turn_completed` (the hooks run after the turn ended).
-- **Terminals** (the REPL, the attached TUI) have printed the answer by then
-  and do not change it; use `event[:notify]` for something they should show.
+- **The terminal** (the attached TUI, a `--non-interactive` one-shot) has printed the answer by then
+  and does not change it; use `event[:notify]` for something it should show.
 
 A plugin gets the same from `chi.on(:after_turn) { |event, ctx| event[:present].call { … } }`.
 
@@ -569,7 +569,7 @@ the voter's own (a guard that wants the model to retry a corrected call:
 `Retry with "…".`).
 
 `event[:context]` is `{cwd:, repo_root:, branch:, session_id:, interface:, origin:}`
-(`interface` is `:repl`, `:worker` or `:non_interactive`). `event[:targets]` is
+(`interface` is `:worker` or `:non_interactive`). `event[:targets]` is
 what the call acts on, resolved as the tools resolve it:
 `{command:, paths:, cwd:, repo_root:, outside_repo:, git_dirs:}`. `outside_repo`
 is measured from the session's repo, not the call's `cwd:`; `git_dirs` lists where
@@ -644,8 +644,9 @@ A `write`'s `content:` is the file text; an `edit` carries `old_text:` and
 arguments whole on `args:` (string keys) instead, and its `content:` is those
 arguments as JSON. An MCP tool's call is chi's `call_tool` (its tool index's, which the mcp
 bundle runs): `tool: "call_tool"`, with `args: {"tool" => "<server>/<tool>", "args" => {…}}`.
-A built-in reached through `call_tool` (`chi/delegate`, a tool the session's toolkit doesn't
-declare) fires as that built-in, its call built as a direct call's, with `call[:via] == "call_tool"`.
+A built-in or plugin tool reached through `call_tool` (`chi/delegate`, `chi/web_search`: a tool the
+session's toolkit doesn't declare) fires as that tool, its call built as a direct call's, with
+`call[:via] == "call_tool"`.
 A hook that drops `via:` or rewrites the call to a tool the toolkit removes gets the call refused
 by its name.
 On a Messages host (`api: anthropic`), the model may call those tools by their own names (they
@@ -710,7 +711,7 @@ Notes:
 - Ordering: bundle hooks fire by `(priority, bundle_name, hook_name)` (lower priority first), then plain `config.yml` hooks in registration order.
 - Settings: a hook class with `initialize(settings = {})` gets the bundle's section of `config.yml` `bundles:` (see [Settings](#settings)).
 - A bundle can also ship a `plugin.rb` whose `chi.on(event)` blocks are bundle hooks too, next to commands and tools; see [Plugins](plugins.md). There `ctx.notify`, `ctx.steer` and the other `ctx` helpers act as this page's `event[:notify]`… do for the event the block runs for.
-- Shipped bundles (each in a profile: `core` or `dev`, see [Bundle profiles](memory.md#bundle-profiles-core-and-dev)): `chi bundle install guardrails` (rules, see [Guardrails](guardrails.md#the-guardrails-bundle)) and `chi bundle install known-names` (a hook, see [Guardrails](guardrails.md#the-known-names-bundle)), `chi bundle install source-links` (a hook: announces source refs, see [The source-links bundle](#the-source-links-bundle)), `chi bundle install btw` (a plugin: `/btw`, see [Bundles](bundles.md#the-btw-bundle)), `chi bundle install mcp` (a plugin: tools from MCP servers, see [Bundles](bundles.md#the-mcp-bundle)) `chi bundle install loop-guard` (a plugin: breaks tool-call loops, see [Bundles](bundles.md#the-loop-guard-bundle)), `chi bundle install check-in` (a plugin: checks on a long turn, see [Bundles](bundles.md#the-check-in-bundle)), `chi bundle install slow-commands` (a plugin: commands that ran past the execute limit are run as tasks next time, see [Bundles](bundles.md#the-slow-commands-bundle)), `chi bundle install agents-md` (a plugin: a nested AGENTS.md is steered into the conversation on the first touch under its directory, see [Bundles](bundles.md#the-agents-md-bundle)), `chi bundle install cost-cap` (a plugin: a per-session $ cap, `/cap`, see [Bundles](bundles.md#the-cost-cap-bundle)), `chi bundle install work-cap` (a plugin: a per-session cap on tool calls and active minutes, `/workcap`, see [Bundles](bundles.md#the-work-cap-bundle)), `chi bundle install ruby` (a plugin: an RSpec run with no examples at all, a hint, see [Bundles](bundles.md#the-ruby-bundle)) `chi bundle install skills` (a plugin: `/skill`, versions of skills, see [Bundles](bundles.md#the-skills-bundle)), `chi bundle install github-pr` (attached context: the branch's open PR, see [Bundles](bundles.md#the-github-pr-bundle)), `chi bundle install coordinator` (a plugin: parallel work in worktrees and child sessions, see [Bundles](bundles.md#the-coordinator-bundle)), `chi bundle install claude-peer` / `codex-peer` (a plugin: talk to a Claude Code or Codex session, see [Bundles](bundles.md#the-claude-peer-bundle)) and `chi bundle install model-notes` (memories: reviewed model notes, see [Bundles](bundles.md#the-model-notes-bundle)).
+- Shipped bundles (each but web-search in a profile: `core` or `dev`, see [Bundle profiles](memory.md#bundle-profiles-core-and-dev)): `chi bundle install guardrails` (rules, see [Guardrails](guardrails.md#the-guardrails-bundle)) and `chi bundle install known-names` (a hook, see [Guardrails](guardrails.md#the-known-names-bundle)), `chi bundle install source-links` (a hook: announces source refs, see [The source-links bundle](#the-source-links-bundle)), `chi bundle install btw` (a plugin: `/btw`, see [Bundles](bundles.md#the-btw-bundle)), `chi bundle install mcp` (a plugin: tools from MCP servers, see [Bundles](bundles.md#the-mcp-bundle)) `chi bundle install loop-guard` (a plugin: breaks tool-call loops, see [Bundles](bundles.md#the-loop-guard-bundle)), `chi bundle install check-in` (a plugin: checks on a long turn, see [Bundles](bundles.md#the-check-in-bundle)), `chi bundle install slow-commands` (a plugin: commands that ran past the execute limit are run as tasks next time, see [Bundles](bundles.md#the-slow-commands-bundle)), `chi bundle install agents-md` (a plugin: a nested AGENTS.md is steered into the conversation on the first touch under its directory, see [Bundles](bundles.md#the-agents-md-bundle)), `chi bundle install cost-cap` (a plugin: a per-session $ cap, `/cap`, see [Bundles](bundles.md#the-cost-cap-bundle)), `chi bundle install work-cap` (a plugin: a per-session cap on tool calls and active minutes, `/workcap`, see [Bundles](bundles.md#the-work-cap-bundle)), `chi bundle install ruby` (a plugin: an RSpec run with no examples at all, a hint, see [Bundles](bundles.md#the-ruby-bundle)) `chi bundle install skills` (a plugin: `/skill`, versions of skills, see [Bundles](bundles.md#the-skills-bundle)), `chi bundle install github-pr` (attached context: the branch's open PR, see [Bundles](bundles.md#the-github-pr-bundle)), `chi bundle install coordinator` (a plugin: parallel work in worktrees and child sessions, see [Bundles](bundles.md#the-coordinator-bundle)), `chi bundle install claude-peer` / `codex-peer` (a plugin: talk to a Claude Code or Codex session, see [Bundles](bundles.md#the-claude-peer-bundle)), `chi bundle install model-notes` (memories: reviewed model notes, see [Bundles](bundles.md#the-model-notes-bundle)) and `chi bundle install web-search` (a plugin: a `web_search` tool through your SearXNG, in no profile, see [Bundles](bundles.md#the-web-search-bundle)).
 - Installing a bundle executes its hook code at `Engine` startup. Only install bundles you trust, as you would a gem. Hooks are **not** executed at install time (copy-only); they are `module_eval`'d at `Engine.new` inside per-bundle `Samagotchi::Bundles::<name>` namespaces (no top-level `require` collisions). Keep hook files side-effect-free at load time; do work in `#call` — top-level side effects (require, IO, `at_exit`, global assignment) run once per `Engine.new` (class redefinition is idempotent).
 
 Lifecycle:
@@ -854,8 +855,8 @@ qualified ref:
 
 **Where `{repo}` and `{host}` come from.** Without a named group that took
 part, they come from `git remote get-url <remote>` run in the session's
-working directory (the worker's; the in-process REPL's is the terminal's
-current directory). `remote:` picks the remote, default `origin` — a fork
+working directory (the worker's; a `--non-interactive` one-shot's is the
+terminal's current directory). `remote:` picks the remote, default `origin` — a fork
 sets `remote: upstream`. Git applies `insteadOf` rewrites and includes, and a
 worktree reports its main repo's remote. The URL forms understood are
 `https://`, `http://`, `ssh://`, `git://` (credentials and port dropped) and

data/docs/internals/anthropic.md

@@ -225,7 +225,7 @@ host refused it for that model.
 `ChatLoop#tool_definitions(conversation, model:)` appends them (`Tools::DeferredTools.list`) only on such an
 adapter, and only with at least one tool declared (Messages wants one). The list, per request:
 
-1. the built-ins the toolkit reaches (`Registry#reachable_names`), in registry order;
+1. the built-ins and plugin tools the toolkit reaches (`Registry#reachable_names`), in registry order;
 2. the tool index's source tools while `call_tool` is declared (`ToolIndex#deferrable`, via
    `Registry::Index#deferrable`): callable, the only tool with its acts_as, a name Messages takes, no registered
    tool's name; by acts_as (`mcp_<server>_<tool>`), sorted by name;
@@ -270,11 +270,11 @@ sets `:tool_changes` for the model: the retry and every later request drop the s
 
 A direct call of a deferred tool runs whether something loaded it or not (the API doesn't check): the Engine sets
 `TurnSettings#loads_tools` from the turn's final model (after the before_turn hooks), and then `ToolRunner#run` and
-`KernelLoop#dispatch` take a reachable built-in by its own name (`Registry#indexed`) through the normal gate, and wrap
+`KernelLoop#dispatch` take a reachable built-in or plugin tool by its own name (`Registry#indexed`) through the normal gate, and wrap
 an MCP tool's acts_as into the `call_tool` call it stands for (`ToolIndex#wrap`): `call_tool`'s row, rules and
 approvals. A reload rebuilds that wrapped call from the saved one (`BuiltinCalls.wrap_saved`). Each such call is
 logged (`tool_direct_deferred`, with `loaded:` whether the conversation had loaded it). On `api: openai` and the
-native loop nothing is deferred, and a direct call of a reachable built-in is refused with the `call_tool` route as
+native loop nothing is deferred, and a direct call of a reachable built-in or plugin tool is refused with the `call_tool` route as
 before.
 
 ## 400 fallbacks

data/docs/internals/attached-context.md

@@ -35,6 +35,9 @@ Three rules hold the shape:
   conversation already holds. Ids are deterministic: `ctx-<name>-<serial>-<revision[0,12]>` (the serial makes A, B, A
   three notes), `ctx-<name>-error-<error_since digits>`, `ctx-<name>-detached-<seen[0,12]>`.
 - **Polling is not activity.** The poller and the absorb never hold a worker up (`WorkerIdleExit`).
+- **The leave absorbs too.** A pass looks at the context and then checks whether it should leave; a change that
+  lands in that gap has no later pass (the poller stops with the worker), so `Worker#left` absorbs whatever is
+  pending as plain notes before the recap, as it does for a background task that finished in the same gap.
 
 ## ContextSources
 
@@ -122,11 +125,11 @@ name (or whose hint is its URL) is attached, *declined* while the declined marke
   "PR", branch names ≥ 6 chars with `/ - _`, exact URLs, fenced code blanked). Only `OwnerPrompt` texts count
   (`owner_texts`), so a participant's message, a steer, a note or a reminder never attaches anything; a review
   session skips all of it.
-- **Where it runs.** `before_turn` (from `Worker#run_prompt` before the absorb, and the REPL's turn start): attach
+- **Where it runs.** `before_turn` (from `Worker#run_prompt` before the absorb, and a `--non-interactive` one-shot's turn start, `TerminalUI`): attach
   each proposed candidate the owner's prompts so far mention (`attach` writes a session `Source` through
   `source_for`: a URL resolves through `ContextProviders`, else the candidate's own `cmd`), then `first_fetch` them
   together within `FIRST_FETCH_SECONDS` (10) so the note lands in this turn; cut short, the fetch records nothing and
-  the poller tries soon. `after_propose` does the same for a late proposal. The REPL has no absorber running, so
+  the poller tries soon. `after_propose` does the same for a late proposal. A one-shot has no absorber running, so
   `deliver_notes` runs one.
 - Forks and continues take no candidates.
 

data/docs/internals/background-tasks.md

@@ -36,8 +36,7 @@ Behavior:
   ends the wait when a person's message waits for the turn's next step (`Engine#input_waiting?`, run_turn's
   `input_waiting:` probe through the kernel's `PeerView`): in a worker an input file that the next boundary merges
   from the user, `chi send` or a delegating parent (`SessionInbox.steer_waiting?`; never a queued, image or
-  participant's one, never a plugin's steer or a child's report, never during a participant's turn), in the REPL
-  (`--no-shared`) a line in its steering queue. The probe only peeks: the drain still merges the message at the
+  participant's one, never a plugin's steer or a child's report, never during a participant's turn). The probe only peeks: the drain still merges the message at the
   next boundary. The result says `note: a message from the user is waiting; the task is STILL RUNNING.`, how to wait
   again or stop it (`TaskWait::MESSAGE_WAITING_NOTE`), and `waited: Ns`; the task keeps running and stays watched
   (below). A task that finished meanwhile gives its finished result, as after a Stop. A `chi -p` turn has no probe. The same probe ends a blocking `delegate_result` (and `delegate`'s wait) early; see [Sessions: Delegating](../sessions.md).
@@ -51,7 +50,7 @@ Behavior:
 
 A task the model leaves running (it ends its turn: "I'll check when it's finished") is reported when it ends, so the result doesn't wait for the user's next message. `session.task_wakes` (env `SAMAGOTCHI_SESSION_TASK_WAKES`): `wake` (default), `queue` or `off` (no watch, as before).
 
-- **The watch** (`TaskWatch`, `task_watch.rb`) is the Worker's (`WorkerTaskWakes`, `worker_task_wakes.rb`, which writes the notes; the Worker runs the wake turn), in memory: the in-process REPL (`--no-shared`) has none, and a crash loses it (those tasks behave as before). The Worker's Engine observer feeds it the raw `:tool_call_completed` events, the input `Bridge#own_task_ids` reads too. A `task_create` result and an `execute` hand-over add the task (`TaskRuntime.created_id`: a `task_id:` the command printed doesn't count), the hand-over's limit kept for the note. What shows the model the end removes it: a `task_wait` with a final status, or with `wait_result: pattern_matched` (the model chose its own "done" marker); a `task_get` with a final status; any `task_stop`. `task_list` and a `read` of `output.log` don't: a model that read the log still gets the wake once. Tasks a tool starts inside an anytime command (`/btw` and the like) reach the same observer, so they are watched too.
+- **The watch** (`TaskWatch`, `task_watch.rb`) is the Worker's (`WorkerTaskWakes`, `worker_task_wakes.rb`, which writes the notes; the Worker runs the wake turn), in memory: a `--non-interactive` one-shot has none, and a crash loses it (those tasks behave as before). The Worker's Engine observer feeds it the raw `:tool_call_completed` events, the input `Bridge#own_task_ids` reads too. A `task_create` result and an `execute` hand-over add the task (`TaskRuntime.created_id`: a `task_id:` the command printed doesn't count), the hand-over's limit kept for the note. What shows the model the end removes it: a `task_wait` with a final status, or with `wait_result: pattern_matched` (the model chose its own "done" marker); a `task_get` with a final status; any `task_stop`. `task_list` and a `read` of `output.log` don't: a model that read the log still gets the wake once. Tasks a tool starts inside an anytime command (`/btw` and the like) reach the same observer, so they are watched too.
 - **The idle tick**: with something watched, each idle pass (after delegate reports, before due reminders) refreshes the watched records (`TaskRuntime.get_record`, one `ps` per running task) and takes the finished ones, keeping only the ids the conversation still holds (`TaskRuntime.created_ids_in`: a `!rollback` or a restored turn may have dropped the result that started one; an LLM context strategy can't, since its stale and forget stubs are drawn in the request, never written over the saved result). A note that can't be written puts its task back for the next pass. An empty watch costs nothing. A task that finishes during a turn and is still unseen when the turn ends wakes on the next idle pass. One the user stopped with the web's stop-task button is dropped without a note.
 - **The note** is a context note under its own header (`ContextNote::TASK_HEADER`; `TaskFinishNote`), `note_id: task-<id>`, `source: task <id8>`:
 
@@ -70,6 +69,6 @@ A task the model leaves running (it ends its turn: "I'll check when it's finishe
 - **A plain note instead** (the same text without the last two lines, no turn start), written at once, with `queue`, the budget spent (the UIs hear `N finished background tasks noted; the model reads them with your next message` once per human input, the flag shared with the other wakes), wakes paused, a continue offer waiting, input queued, an exit asked for, or a **note-only** task: one started or waited on in a turn the user stopped (reasons `user`, `manual`, `ctrl_c`), since a wake telling the model to carry on would undo that Stop. A prompt's turn takes the finished ones as plain notes first.
 - **Failure**: a wake turn that fails and kept nothing, or is stopped and restored, turns its note back into the plain one (`WorkerInbound#unmark_wake`, as for a context wake) and pauses wakes until the user writes.
 - **Idle exit**: with `wake`, a watched task holds the worker's idle exit (`WorkerIdleExit`'s `:background_tasks`) until its wake is taken: while it runs, and once it finished until the next idle pass takes it (`TaskWatch#holding`, in memory, no `ps`), so one that ends between the pass's look and the exit's check still wakes the session. A still-running one holds `/exit` too (`TaskWatch#running`, read once per request by `WorkerIdleExit#request_hold`; the 409 lists the tasks, `{id, command, age_seconds}`, with a `hint` on stopping them, and the attached terminal names them and says to use the web's stop-task button or ask for `task_stop`), as reminders do. When the only holds are ones the user can stop, the 409 carries `holds` too and the terminal asks whether to stop them all (`HoldStop`, which stops these tasks the same way `task_stop` does). A note-only task holds neither (no wake would come for it), nor does one whose note, or the look for it (the conversation's task ids unreadable), failed 3 times (`TaskWatch::MAX_FAILURES`: it is still tried at each look, but can't keep the worker up for good). With `queue` nothing holds: nothing would wake for the end, so keeping the worker up isn't worth it. As the worker leaves (any exit but a stop, a signal or an `/exit --delete`), the tasks that finished since the last look are written as plain notes; a task that ends after the worker left gets no note (the model sees its end at its next look, as before). A forgotten dev server keeps the worker up until it is stopped; a crash of that server wakes the session.
-- **The tool descriptions**: a worker's `execute` and `task_create` say "if you end your turn before it finishes, chi tells you when it does" (left out under `off` and in the REPL), fixed when the worker builds its Engine.
+- **The tool descriptions**: a worker's `execute` and `task_create` say "if you end your turn before it finishes, chi tells you when it does" (left out under `off` and in a `--non-interactive` one-shot), fixed when the worker builds its Engine.
 
 Work that needs a model, not a shell command, goes to a child chi session instead: `delegate` / `delegate_result` have the same shape (start, then wait) and return only the child's final reply; see [Sessions: Delegating](../sessions.md#delegating).

data/docs/internals/block-renderers.md

@@ -30,6 +30,10 @@ model. The TUI is untouched: it shows a fence as source.
    clone arrives with both. On failure the `<pre>` stays, marked `data-block-failed`, with one muted line: an attribute CSS
    shows, never markup, and not in the bubble's `textContent`, which the page's dedupe and an annotation read (`copy.js`'s rule). CSS content can't be selected, so a click on the line copies its words.
    The toggle has an icon and an `aria-label`, no text (`copy.js`'s rule). A jump into the source shows it (`revealInHistory`).
+   For a screen reader: the hidden `<pre>` isn't read, so the `<img>`'s alt names the toggle that shows it ("mermaid
+   diagram, its source under the Show the source button"). The natural size, a click on the picture, is also a
+   `.block-zoom` button (icon, `aria-label`, `aria-pressed`) for the keyboard: before the toggle, shown on keyboard focus
+   only, and taking no pointer while hidden, so the mouse's view is as it was.
 6. Cache: a `Map` on `lang + theme + source`, about 200 entries, holding the `data:` URL; a later `bubble.innerHTML` wipes the
    figure and the observer redraws in the same pass. No `crypto.subtle`: it's undefined on a plain-http LAN address. A system
    theme change redraws through the figure (a hidden `<pre>` never intersects).

data/docs/internals/bridge.md

@@ -98,11 +98,11 @@ the "asking again" and steer-cut rows, ✂ rows and questions (with how they wer
   `chi guardrails replay` reads. A plain upgrade doesn't reach this: a worker already running seeded before and keeps its own version 1
   file, and a spawn runs the newest chi installed (`SessionManager.worker_command`), unless that activation raises LoadError: the boot
   line then falls back to the spawner's or the home's pinned version, which can be older. Otherwise it takes an older process starting
-  on a session a newer one wrote: a downgrade, a chi home whose newest chi is older (`home_older_than_spawner`), or a REPL or `bin/chi`
+  on a session a newer one wrote: a downgrade, a chi home whose newest chi is older (`home_older_than_spawner`), or a `bin/chi`
   from an older gem or checkout on the same state dir. Nothing on this side stops
   it: an older chi can't be changed, and having it read the file would mean writing fake `turns` counters into every file.
 - **A killed turn needs nothing special.** `TurnCheckpoint` keeps a running turn's prompt in the session file, with its id from
-  the start (`Worker#run_engine_turn` settles it first), so it counts as any opening. A REPL keeps no running turn in the
+  the start (`Worker#run_engine_turn` settles it first), so it counts as any opening. A `--non-interactive` one-shot keeps no running turn in the
   session, so a kill takes the prompt along and there's nothing to count.
 
 ## SSEWriter
@@ -401,7 +401,7 @@ for client discovery, with the Bridge's secret (see above).
 **Worker link.** Every client asks `WorkerLink` (`worker_link.rb`) whether a session's worker can be reached, never
 reading `bridge.json` or probing a port itself: `WorkerLink.resolve(session_dir, unlink:, owner:)` answers a typed
 outcome. The rule is the owner lock plus the sidecar's `pid`; there is no port probe (a port can be reused by another
-session's Bridge, a free lock is the kernel's proof the worker died). In order: no lock holder, or a chi REPL's: a
+session's Bridge, a free lock is the kernel's proof the worker died). In order: no lock holder, or a one-shot's (kind `"tui"`): a
 sidecar is `Stale(:lock_free)` (removed with `unlink: true`, only if it is still the file that was read and the lock,
 read again just before, is still free: a worker that took it meanwhile is resolved as that worker), else `None`;
 a holder with no kind yet: `Starting`; a leaving worker: `Leaving` (marked before its Bridge stops, on every way out:

data/docs/internals/context-telemetry.md

@@ -55,7 +55,7 @@ session's first counted turn. A
 hook's switch (`before_turn`) sends nothing: its turn's first request counts on the new model anyway.
 
 A process that loads the session on another model than its last turn ran on (`Engine#session=`:
-`SessionMetrics#last_model_ref` differs from `effective_model_ref`; a `--resume`'d REPL with `--model`, a worker woken
+`SessionMetrics#last_model_ref` differs from `effective_model_ref`; a `--resume`'d one-shot with `--model`, a worker woken
 after a `/model` with no turn since) drops the old window (`forget_model_reports!`) and calls
 `announce_switched_context!(configured_only: true)`: the configured window only
 (`EffectiveModel#configured_context_window`, no `/props` GET or model list, since a worker runs it before its Bridge