samagotchi 0.96.0 → 0.98.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 919ca9857f9debe0c23587e3061cc7d7723966067a236054d06acc68bb811b35
-  data.tar.gz: 3b5588e7c7de075d1dc7a7d84d57a39222ddd63342931aef4764a5422cc1959b
+  metadata.gz: d683d11a3567996b7eb36801581dfa374309207bda22d8bc7d7e4e7f94d1cf2f
+  data.tar.gz: 850af6daff806f5c56e4c5b9cd2294452360c891fca2690367111ff960c721fd
 SHA512:
-  metadata.gz: 2928c6af604c2e9e33728949ae701d814ca61c510bec264004c56b00986c46ec6b2a23dfc449e832eed18246b33c57bc04b3d422e02dc3fe21667fd890b29fce
-  data.tar.gz: 4171544e495614b7f7ff23ef92b484d67dc9aa34c3624b2ac7459d8bf1e9fd93b36fc7ca329ca11e1dead80da44a032146c617900484b934fc11f2d3c4fbf159
+  metadata.gz: c2272a6357f9fe281f36078facc23678c044b1942213bd4e881881c67fbd1ad2332aaf7f55d82cbe354ab558661b6e2fa4883044d7e07897508d6518f51b3a36
+  data.tar.gz: d4e99b1672e12be69e3c36b1b5e29b9a6b3ed1e68d17a7f308e8a33d6e7a41d5790c5b2ea552c796d335e0fba94ff540d3788389b91b252d81b141ba5e38b869

data/CHANGELOG.md

@@ -8,6 +8,58 @@ and commands may change between minor versions. How releases are made:
 
 ## [Unreleased]
 
+## [0.98.0] - 2026-10-21
+
+### Added
+
+- A long question from the model gets room in the web stage: when its reply doesn't fit, the stage grows (up to 85%
+  of the panel) for the turn, the reply reads from its start in one scroll, and an "Answer ↓" pill leads to the card
+  while it is out of view. Approvals, the step limit and hooks' questions keep their layout.
+- A new hook event, `:question_asked`, lets a plugin attach refs to the reply that asks a question or an approval
+  (display only, never in the prompt); the web pairs them in the asking text, on the card and in the history step.
+  A bundle manifest's hook can list `events: [...]` to run one hook for several events. See
+  [docs/hooks.md](docs/hooks.md).
+- source-links 0.6.0 links the issue keys and paths in a waiting question's reply too, not only in answers.
+
+### Changed
+
+- The web's rename ✎ moved from the info bar to the session's title: on the active card and next to the title in
+  the top bar, with the input over the title.
+- A model server's 404 that lists its models puts `did you mean …?` ahead of the (cut) list, and names up to three
+  ids: every nearest typo on a tie, or the listed ids that contain the name asked for (`Qwen3.6-35B` →
+  `mlx-community--Qwen3.6-35B-A3B-4bit` or `…-8bit`).
+
+### Fixed
+
+- A Gemma 4 step on the native loop no longer shows its tool call's body (`call:ask_user_question{…}`) as text in
+  the web history after a reload.
+
+Update with `chi update` (the system bundle 0.98.0, source-links 0.6.0, the dev profile 0.7.1), then restart `chi web`.
+
+## [0.97.0] - 2026-10-21
+
+### Added
+
+- The terminal's status row (the REPL's and an attached one's) shows the session's title first when it has one, and
+  follows `/title` from any client without a restart. See [docs/cli.md](docs/cli.md#status-line).
+- A model server's 404 that lists the models it serves (oMLX's "Model 'X' not found. Available models: …") ends with
+  `did you mean '<id>'?` when one listed id is close to the one asked for: the same name under a prefix
+  (`mlx-community--…`, `vendor/…`), another case, or a typo. The listed ids are read past the message's cut.
+- `chi memory ls` lists the memories of both scopes (or `--scope project|system`; `--format json`) with their size,
+  date, bundle, description and model overlays, and `chi memory rm NAME [--scope …]` removes one as `memory_write`
+  `remove: true` does: the file and its overlays go to the bundle trash, the index line is dropped, a bundle's memory
+  is refused. A profile's "kept your own" line now points at `chi memory rm`. See
+  [docs/memory.md](docs/memory.md#listing-and-removing-from-the-shell).
+
+### Fixed
+
+- `chi bundle try` exits 130 for a Ctrl-C in the child chi's first moments too (while its Ruby was still booting it
+  exited 1).
+- `chi bundle upgrade core --dry-run` (or `dev`) names the memory files of a member it would install that you already
+  have, which the install keeps as yours (`model-notes: kept your own …`), as the real run does; it named none.
+
+Update with `chi update` (the system bundle 0.97.0), then restart `chi web`.
+
 ## [0.96.0] - 2026-10-21
 
 ### Added
@@ -3703,7 +3755,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.96.0...HEAD
+[Unreleased]: https://github.com/dm1try/samagotchi/compare/v0.98.0...HEAD
+[0.98.0]: https://github.com/dm1try/samagotchi/compare/v0.97.0...v0.98.0
+[0.97.0]: https://github.com/dm1try/samagotchi/compare/v0.96.0...v0.97.0
 [0.96.0]: https://github.com/dm1try/samagotchi/compare/v0.95.0...v0.96.0
 [0.95.0]: https://github.com/dm1try/samagotchi/compare/v0.94.0...v0.95.0
 [0.94.0]: https://github.com/dm1try/samagotchi/compare/v0.93.0...v0.94.0

data/bin/chi

@@ -61,6 +61,8 @@ SUBCOMMANDS = {
   "models" => ["samagotchi/models_command", "ModelsCommand"],
   # the native "Send to chi" helper
   "desktop" => ["samagotchi/desktop_command", "DesktopCommand"],
+  # list and remove memories (ls, rm; --scope, --format)
+  "memory" => ["samagotchi/memory_command", "MemoryCommand"],
   # install, upgrade, uninstall, status, diff, list, build (--scope, --force, …)
   "bundle" => ["samagotchi/bundle_command", "BundleCommand"]
 }.freeze
@@ -106,6 +108,7 @@ parser = OptionParser.new do |opts|
            chi context <add|push|ls|show|refresh|rm|mute|unmute>   live external text attached to sessions
            chi send [-m TEXT] ID...|--new   a message into sessions, as if typed there
            chi answer ID --question QID --option N   answer a question a session waits on
+           chi memory <ls|rm> [--scope project|system]   the memories; rm moves one to the bundle trash
            chi bundle <install|upgrade|uninstall|status|diff|list|build|trash|new|test|check|try>
            chi desktop <install|upgrade|uninstall|status>   macOS "Send to chi" helper
            chi models [--format json] [TEXT]   the models --model takes, from every host

data/docs/architecture.md

@@ -339,6 +339,8 @@ process that already owns the `Engine`); every worker starts it, and it exposes:
   deletes it, and the Bridge announces `:turn_dequeued`. `200 {status: "removed", enqueued_id, prompt}`, `409 already_started`
   (a turn took it), `409 not_queued` (a next-step message: a drain may merge it any moment), `404
   unknown_enqueued_id`. It never wakes the worker. The worker names it in its sidecar features (`unqueue`).
+  A worker's start prunes the `input/removed/` and `input/settled/` tombstones older than a week
+  (`SessionInbox::TOMBSTONE_MAX_AGE`, log `tombstones_pruned`); otherwise they go with the session dir.
 - `POST /session/:id/relay` — the approval relay, on a delegated child's worker
   (`{action, relay_id, question_id}`): `opened` / `closed` (with a `reason`) set or clear the
   pending question's `relayed_to` mark (`QuestionDesk#annotate`, `:question_relay`); `answered`
@@ -419,7 +421,14 @@ The page's frequent reads of `GET /api/sessions/:id` stay light too:
   finishes the ended turn's own line by its `turn_id` (sent as `&turn_id=`, which also picks that
   turn's answer). A tail read's timing is always the newest turn's; `recent=1` is accepted and not needed.
   The page binds an answer's `display_refs` to its bubble (`answer_refs.js`: on a reload's render and on this
-  read's re-render) and pairs them with the bubble's links and text before the `path:line` scan. A file ref outside the
+  read's re-render) and pairs them with the bubble's links and text before the `path:line` scan. A question's
+  refs (`pending_question.refs`, `:question_asked`) pair the same way (`markdown_place.js` `linkRefsIn`/`pairRefsIn`):
+  `question_requested` (or a snapshot's pending question) keeps them on the asking step's gen
+  (`turn_model.js` `questionRefs`) before the card draws, so the stage's asking slot (`stage_slots.js`
+  `drawAsking(text, refs)`) pairs them on its raw draw and again after its markdown swap; the card pairs its
+  question text and its kept reply (`question_cards.js`); the step's closed `.gen-text` takes them
+  (`turn_view.js`; on a reload its `data-answer-at`, the message's `display_refs`) and `linkTextRefs` pairs it at
+  the turn's end and after a reload. A file ref outside the
   session's folder is dropped, as a reload drops it: the folder `/tail` names, else (an older worker) the hub's
   session list entry's, else (refs to check, no hub entry) the session file's; with no folder known at all, every
   file ref is dropped rather than shown unchecked.
@@ -505,7 +514,8 @@ Bridge's stream above): the chat loop's thinking is the
 server's `reasoning_content`; the raw-prompt loop splits each generation's
 stream with a fresh `ThoughtStreamSplitter`, seeded with the prompt's prefill (Qwen's `<think>` and Gemma's
 `<|channel>thought … <channel|>` are thinking, tool-call bodies are dropped
-from `text:`). The chat loop's model turns keep their `tool_calls` and tool results their `tool_call_id`,
+from `text:`; a saved step's text, as the web history and the attached terminal's join show it,
+drops both too: `OutputFormatter.strip_markup`). The chat loop's model turns keep their `tool_calls` and tool results their `tool_call_id`,
 so later requests and resumed sessions pair them, and their reasoning (`thinking:`), which goes back as
 `reasoning_content` on the running turn's replies (`reasoning_history`; a step-limit Continue's
 turn goes on from the run it resumes, `reasoning_since:`). It has its own system prompt

data/docs/bundle-authoring.md

@@ -51,7 +51,8 @@ plugin:
   sha256: sha256:<hex>       # `chi bundle check --fix` fills it; never compute it by hand
 # files:                     # memories it installs (top-level *.md); without files: every *.md but README & co.
 #   my_notes.md: sha256:<hex>
-# hooks:                     # hooks/*.rb files (a plugin's chi.on is usually simpler)
+# hooks:                     # hooks/*.rb files (a plugin's chi.on is usually simpler), each with event: NAME
+#                            # or events: [a, b] (one instance for both; chi newer than 0.97.0)
 # needs: [gh]                # outside commands it relies on
 ```
 
@@ -64,7 +65,7 @@ time. `chi bundle check --set KEY=VALUE` gives the sandboxed load a setting.
 ## What a hook sees
 
 `chi.on(event) { |event, ctx| … }` gets a Hash. The events, in a turn's order: `session_start`, `before_turn`,
-`before_generation`, `generation_progress`, `after_generation`, `before_tool_call`, `after_tool_call`,
+`before_generation`, `generation_progress`, `after_generation`, `before_tool_call`, `question_asked`, `after_tool_call`,
 `after_turn`, `session_end` (the fields of each: [hooks.md, Hook Events](hooks.md#hook-events)). A symbol not in
 that list is never fired (`check` warns). The two a bundle wants most, for an `execute`:
 
@@ -116,7 +117,8 @@ end
 
 `bundle.tool_call` runs guarded hooks; `bundle.tool` calls a registered tool. `bundle.steers`, `cards`, `stops` and
 `questions` record effects; `bundle.answer` / `model_answers` provide `ask_user` / `ask_model` answers.
-`bundle.http.stub` stubs `ctx.http`; `sandbox.config`, `sandbox.fake_executable` and `bundle.install` cover setup.
+`bundle.http.stub` stubs `ctx.http`; `bundle.question_asked(text, question:)` fires `:question_asked` and returns
+the refs; `sandbox.config`, `sandbox.fake_executable` and `bundle.install` cover setup.
 The full list is in [plugins.md, Testing a bundle](plugins.md#testing-a-bundle-experimental). The kit is
 experimental (it may change before chi 1.0). If a test needs a fake of chi's own (a stub of a `Samagotchi::`
 class, a hand-built `ctx`), that is a gap in the kit: say so to the user rather than reaching into chi.
@@ -127,7 +129,8 @@ class, a hand-built `ctx`), that is a gap in the kit: say so to the user rather
   of a checksum mismatch, and a line with no sha installs unchecked. `chi bundle check --fix` rewrites them; run it
   after the last edit.
 - **requires_chi.** Use the chi the user runs (`chi --version`). `check` warns when the plugin calls something
-  newer than the floor (`ctx.http` needs 0.80.0, `ctx.cost` 0.83.0).
+  newer than the floor (`ctx.http` needs 0.80.0, `ctx.cost` 0.83.0, `ctx.sessions.children` 0.34.0). A keyword added
+  later it can't see: `ctx.ask_model(model:)` needs 0.80.0, `ctx.sessions.send(delivery:)` 0.64.0.
 - **trust_level.** Leave it out. `reviewed` / `trusted` are for someone who reviewed the bundle, not its author.
 - **Restart.** A session loads bundles when it starts: after an install or a settings change, the user starts a
   new session (or `chi sessions restart ID`).

data/docs/cli.md

@@ -20,6 +20,7 @@
 - `chi context <add|push|ls|show|refresh|rm|mute|unmute> …` — attach live external text to sessions (a command chi runs every so often, or text pushed in); the model gets a short note when it changes and reads it with `context_read`; `chi context add <URL>` attaches a GitHub PR with the github-pr bundle (see [Attached context](context.md))
 - `chi send [-m TEXT] [--image PATH]... [--cut | --queue] (ID|PREFIX)...` — send a message to sessions as if typed there: a turn starts (or a running one takes it at its next step; `--cut` asks it to cut long thinking for it; `--queue` runs it as a turn of its own after the running one, and `--queue --wait` waits for that turn's own answer); piped stdin goes above `-m` as quoted context, and `--image` attaches images (see [Sessions: Sending a message](sessions.md#sending-a-message)); `--new` starts a session with it instead (`--new --continues ID|last:ID` the next link of that session's chain, see [Session chains](sessions.md#session-chains)), and `--wait` prints the answer (`--wait ID` with no message waits for the next reply without sending — to an idle session whose last turn already ended, that ended turn's reply or end comes back; `--wait --turn T ID` with no message waits for exactly turn T, whether running, queued or last ended; `--format json` includes its `turn_id` when known, for waiting again after exit 3 or 4; exit 3 a question waits, its options on stderr; exit 4 `--timeout` passed with the turn still running; see [Starting a session](sessions.md#starting-a-session))
 - `chi answer ID --question QID (--option N|LABEL)... [--text T] [--timeout S] [--format json]` (or `--dismiss`) — answer the question a session waits on (the one `chi send --wait` exited 3 with), then wait and print what comes next as `chi send --wait` does: the reply (0), the next question (3), still running after `--timeout` (4). `--option` is 1-based or the label, repeated on a multi-select question; `--text` is free text, or a Deny's reason; `--dismiss` leaves it unanswered and the model finishes its reply. A question no longer open (the web answered first) isn't answered again: it waits for that turn's reply. An option the question doesn't offer exits 2; a worker that is gone exits 1 (`send the task again: chi send --wait -m "…" ID`). What a parent may pick follows `guardrails.parent_answers`, or the session's own `parent_answers` when stricter (`soft`, the default: a deny, a plain answer, Continue and "Allow once"; `standard`: no allow; `hard`: no Continue either), never a wider scope or an allow on chi's own config; a refused pick exits 1 with what to answer instead (a convention, not a security boundary; see [Guardrails](guardrails.md#answers-from-a-parent-agent))
+- `chi memory ls [--scope project|system] [--format text|json]` — the memories of both scopes (this folder's project first), one row each: scope, name, size, date, `from <bundle>`, the index description and its model overlays; `chi memory rm NAME [--scope project|system]` removes one as `memory_write` with `remove: true` does: its file and model overlays go to the bundle trash (the line names the dir; `chi bundle trash` lists and empties it) and its index line is dropped. NAME in both scopes without `--scope` exits 2 naming both; a missing NAME or a bundle's memory (`chi bundle uninstall` removes it) exits 1 (see [Memory: Listing and removing from the shell](memory.md#listing-and-removing-from-the-shell))
 - `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)
@@ -658,8 +659,8 @@ the first message: …)`); `/title TEXT` names the session (whitespace collapsed
 cut at 80 characters), `/title --clear` drops the name (anything after `--clear`
 is refused with the usage line). It is saved at once,
 mid-turn too, and the lists, cards, top bar and tab show it in place of the first
-message; a continue's next link keeps it. The web's info bar has `✎` for it. See
-[Session titles](sessions.md#session-titles).
+message; a continue's next link keeps it. In the web, `✎` next to the session's
+title (its strip card, or the top bar) does it. See [Session titles](sessions.md#session-titles).
 
 A `/thinking`, `/reasoning-history` or `/toolkit` change that restarts the prompt cache
 asks first: the reply says what it costs, changes nothing, and names the line
@@ -894,7 +895,12 @@ nudged the model") show ahead of those calls for about 4 s, as their rows
 wait in the closed block. A card that needs you (a question, an approval, check-in)
 sits in the stage too. While a question or approval waits, the stage shows
 the whole text of the reply that asked it (in place of its newest
-sentence) above the card, until you answer. Once answered, the model's
+sentence) above the card, until you answer. A long reply that asks the
+model's own question (one that doesn't fit that slot) gets more room: the
+stage grows to about 85% of the page for the rest of the turn (never above
+the session panel), the reply reads from its start in the stage's one
+scroll, and while the card is out of view a `❓ Answer ↓` pill at the
+stage's bottom edge takes you to it. Once answered, the model's
 question or its own approval keeps that reply (a delegate's relayed
 approval, a hook's question and the step limit don't): two muted lines
 under its `question → answer` line, the whole text when you open the card,
@@ -1132,10 +1138,13 @@ The REPL and attached mode show one status row under the prompt, drawn when what
 changes:
 
 ```
-status> model=Qwen3.6-35B | ↳ 3f2a1c9e | ctx=12.3% (under20) | mem: notes, cli_usage | muted: gh-helper
+status> Coordinator | model=Qwen3.6-35B | ↳ 3f2a1c9e | ctx=12.3% (under20) | mem: notes, cli_usage | muted: gh-helper
 status> model=Qwen3.6-35B | ⑂ 2 running · 1 waiting | ctx=8.1% (under20) | mem: skill_coordinator
 ```
 
+- The session's title first, when it has one (`/title`; not the first message a session without one is named by),
+  cut to 32 characters and to a third of a narrow row. It follows `/title` from any client (this terminal, another
+  one, the web's `✎`, `chi send`) without a restart: the worker's `command_ran` for it carries the new title.
 - `model=`: the model in use, `(default: …)` beside it when it isn't the config's default, and
   `model=<served> (served; asked <name>)` when the server said it served another model (not for one its host's
   `hosts.<name>.models.<id>.served` names; see [configuration](configuration.md#models-a-host-serves-but-doesnt-list)).

data/docs/configuration.md

@@ -187,6 +187,19 @@ An environment name used as a top-level key (`SAMAGOTCHI_DEFAULT_MODEL: my-model
 the old flat form) is not read: it warns as an unknown key with the nested one
 to use (`did you mean 'default.model'?`).
 
+A few environment variables are not settings (no config.yml key, no flag):
+
+- `SAMAGOTCHI_SKIP_SYSTEM_BUNDLE=1` (or `true`): don't install or upgrade the system bundle
+  (`samagotchi-system`) into the system memories; chi uses whatever is installed there. For isolated runs and
+  specs. `chi bundle try` drops it from its sandboxed child, so the sandbox gets the system bundle installed.
+- `SAMAGOTCHI_BOOT_FALLBACK`: internal. A worker's boot line sets it when the newest installed chi failed to
+  load and the worker fell back to its starter's version; the worker reads and unsets it, and logs
+  `boot_fallback` with the error. See [Sessions](sessions.md) (Which chi a worker runs).
+- `SAMAGOTCHI_DEFAULT_MODEL_FROM_CLI=1`: internal. Set beside `SAMAGOTCHI_DEFAULT_MODEL` for a worker a
+  `chi --model X` spawned: X is that run's model, which the chi its commands run must not inherit.
+- `SAMAGOTCHI_LOG_STRICT=1`: an unknown log tag or a malformed log event raises instead of being dropped. The spec
+  suite sets it, and a bundle's tests keep it (`Samagotchi::Testing::Sandbox`).
+
 ## Model Server API
 
 Chi talks to a model server over HTTP in one of two ways, set by the host's `api:`:

data/docs/hooks.md

@@ -56,6 +56,7 @@ The plugin class must respond to `#call(event)` — duck-typed, no base class re
 | `:after_generation` | After LLM returns (both loops); not after a generation a hook cut (`stop_generation`) | `{ type: :after_generation, iteration: N, response: "...", messages: [...] (the conversation as sent) }` |
 | `:generation_progress` | While the response streams, in batches (see [Watching the stream](#watching-the-stream)) | `{ type: :generation_progress, iteration: N, thinking: "..." (new since the last fire), text: "..." (new visible text), thinking_chars: N, text_chars: N (this generation so far), elapsed_ms: N, restarted: true (only on the first fire after a dropped stream was asked again) }` |
 | `:before_tool_call` | Before tool dispatch (and before `tool_call_started`) | `{ type: :before_tool_call, iteration: N, call: {...}, params: "...", guardrail: Verdict, context: {...}, targets: {...}, blocked: false, block_reason: nil }` |
+| `:question_asked` | A question of the model's own (`ask_user_question`) or an approval of its tool call is about to open, on the turn's thread (not a hook's or plugin's `ask_user`, a relayed delegate approval, the step-limit question, a `--non-interactive` run or a stored approval: none of those fire it) | `{ type: :question_asked, kind: "question" \| "approval", text: "..." (the reply that asks, as the asking slot shows it: no thoughts, no tool-call markup), question: {...} (the question's fields, frozen: question/options/header…, an approval's approval: facts too; no id yet), refs: (see [Refs on a question](#refs-on-a-question-display-only)) }` |
 | `:after_tool_call` | After tool execution | `{ type: :after_tool_call, iteration: N, tool: "read", output: "..." (the text the model gets: capped at max_tool_output_chars; a cut one has a [cut: …] line, at its end, or for an execute result between its head and its tail, the whole output saved in the session's tool_output/ folder), status: "ok" \| "error" \| "blocked" \| "stopped", call: {...} (the call that ran, as the gate left it), elapsed_ms: N (the tool's own run, without an approval wait; nil for a denied call), result: "..." (the tool's own text: no "[read]" lead, no "ran as:" line, never cut) }`; `stopped` is a `task_wait` the turn's Stop ended (the task runs on) or whose task was stopped. Match on `result:`, not `output:`: it is what the tool said (`Error: command timed out after 120s` for an execute killed at its limit in kill mode, `Samagotchi::Tools::Execute::TIMEOUT_PREFIX`; `Still running at the 120s limit: …` for one handed over as a task, `Samagotchi::Tools::Execute::HANDED_OVER`) |
 | `:session_end` | After each turn `:after_turn` fires for, after it (turn-level lifecycle) | `{ type: :session_end, session_id: "..." }` |
 
@@ -366,6 +367,58 @@ end
 
 A plugin gets the same from `chi.on(:after_turn) { |event, ctx| event[:refs].call(…) }`.
 
+## Refs on a question (display only)
+
+`:question_asked` carries `refs:` too, for the reply that asks the question: a
+ticket the model names while it asks is a ref while the question waits, when
+the user needs it.
+
+```ruby
+class JiraQuestionRefs
+  def call(event)
+    return unless event[:type] == :question_asked
+
+    event[:text].scan(/\b[A-Z][A-Z0-9]+-\d+\b/).uniq.each do |key|
+      event[:refs].call(match: key, kind: "issue", target: { id: key }, label: key,
+                        actions: [{ id: "open", label: "Open in Jira", url: "https://jira.example.com/browse/#{key}" }])
+    end
+  end
+end
+```
+
+- The call, its return values, the checks and the `refs_rejected` log are
+  [Refs on the answer](#refs-on-the-answer-display-only)'s, with lower caps:
+  50 refs and 32 KiB per step. `nil`: the turn has no model step to attach to,
+  or the call came after the hooks ran.
+- They are kept as `display_refs` on the step's model message (the one that
+  asks; in the session file after the turn, a cancelled one too) and go on the
+  pending question as its `refs` (the `question_requested` event, the session
+  file while it waits, the saved question card). A second question in the same
+  step adds to the step's list, and its pending question has the whole list.
+  The model never sees them.
+- The web checks them again wherever a saved one reaches it (the pending
+  question, a saved card, the history), as an answer's, and pairs them as an
+  answer's (the three passes above) in: the stage's asking slot while the
+  question waits (its raw text, then again once its markdown is in), the
+  card's question text, the answered card's kept reply (raw, then its
+  markdown when opened; never its one-line summary copy), and that step's
+  text in the history, live (at the turn's end) and after a reload. A ref
+  whose `match` is only in the question's text pairs there alone; the step's
+  text drops it. **Terminals** ignore them.
+- **Its time is the question's wait**: the hooks run before the question
+  opens, so a slow one delays it (and counts in `ask_user_question`'s
+  `elapsed_ms` and an approval's `waited_ms`). A hook that raises is logged and
+  the question opens with the other hooks' refs. With no hook on the event
+  nothing is built.
+- Don't ask from it: `event[:ask_user]` (and `ctx.ask_user` in a `chi.on`
+  block) returns nil at once here.
+- Needs chi newer than 0.97.0: set `requires_chi`.
+
+A plugin gets the same from `chi.on(:question_asked) { |event, ctx| event[:refs].call(…) }`. The bundle test
+kit fires it as chi does: `bundle.question_asked(text, kind:, question:)` returns the refs the step gets
+([plugins.md](plugins.md#testing-a-bundle-experimental)). The shipped source-links bundle subscribes (its
+sources' refs in the reply that asks, and in the question's text and options).
+
 ## Settings
 
 A hook class whose `initialize` takes an argument gets its settings: **one
@@ -599,6 +652,12 @@ Notes:
 
 - Hook key = basename (flat under `hooks/`). No subdirs in v1.
 - `event` is required for auto-registration; a hook with no event is skipped.
+- `events: [after_turn, question_asked]` (a list, in place of `event:`) registers the hook for each event it
+  names: **one** instance serves them all (its state is shared), and `#call` tells them apart by
+  `event[:type]`. `event:` and `events:` together, or an `events:` that isn't a non-empty list of event names,
+  is refused at install (`hooks: <file>: …`). `on_error: fail_closed` applies to its `before_tool_call`
+  registration only. Needs chi newer than 0.97.0 (an older chi installs the hook with no event and never loads
+  it): set `requires_chi`.
 - `sha256` is integrity (not authenticity). No signing in v1. Install records the sha256 of the copied file; at `Engine.new` a hook whose file differs is not loaded (reinstall the bundle after editing one by hand).
 - Hook code is the bundle author's source of truth: on upgrade, hooks are overwritten; if the installed file was locally modified, a warning is emitted (`was locally modified; overwriting`).
 - `on_error` defaults to `skip` for every event, `:before_tool_call` included: a raising hook is silent and the call goes ahead. `log` warns. `fail_closed` (only on `:before_tool_call`; on any other event it acts as `skip`) denies the call the hook raised on. Choose `fail_closed` for a hook that is a guardrail, whose failure should stop tool calls rather than let them through.

data/docs/internals/background-tasks.md

@@ -56,7 +56,7 @@ A task the model leaves running (it ends its turn: "I'll check when it's finishe
 - **The wake turn**: the first finished task runs a continue turn from client `task:<id>` (`last_turn.origin: "task"`, labelled `task <id8> finished` in the TUI and the web; the web's bell rings at its end however short), whose first message is the note (`turn_start`, `turn_id`, written before the turn's checkpoint so a restore keeps it). It counts toward `session.max_wakes` with the other wakes (`WorkerWakes#task_open?`: no continue offer, not paused, past the 2 s start grace). Several tasks finishing together: one wake turn, the others plain notes before it.
 - **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`; the 409 lists the tasks, `{id, command}`, 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. 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.
+- **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}`, 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. 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.
 
 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/bundles.md

@@ -37,9 +37,9 @@ user-facing side (what a bundle owns, profiles, needs) is in [memory.md](../memo
 | `AssetInstaller` | the parts that live in `.bundles/<name>/`: hooks, guardrail rules, plugin, scripts; returns `AssetInstaller::Installed` (the paths the record keeps) |
 | `Merger` | 3-way classification per file: `install`, `fast_forward`, `keep`, `noop`, `conflict` |
 | `Provenance` | the `.bundles/<name>/` dir: `#write` the record + bases, `#record` → `InstalledBundle`, `.each_installed`, `.claimants` (which bundles own a file) |
-| `InstalledBundle`, `BundleHook`, `PluginRef` | value objects for the record; tolerant of older records (missing keys read as empty) |
+| `InstalledBundle`, `BundleHook`, `PluginRef` | value objects for the record; tolerant of older records (missing keys read as empty). `BundleHook#events` is the manifest's `event:` or its `events:` list (written back as `event:` for one, as an older chi reads it); `Hooks::BundleLoader#load_hook_file` builds the hook once and registers it under each |
 | `Builder` | `chi bundle build`: memories (+ the installed bundle's hooks, rules, plugin, scripts) → zip/tar/dir |
-| `Profile` | meta bundles (`includes:`): install the members, record which; `InstallResult#kept_own` names a new member's memory files the user already had (`kept_own_line`, printed by `chi bundle`, `chi update` and `chi bootstrap`) |
+| `Profile` | meta bundles (`includes:`): install the members, record which; `InstallResult#kept_own` names a new member's memory files the user already had, with other bytes (`kept_own_line`, printed by `chi bundle`, `chi update` and `chi bootstrap`); a dry run runs each member's Installer as a dry run too, so it names them as well |
 | `SystemBundle`, `ShippedUpdate` | the built-in system bundle (`ensure!` at Engine start, `sync` in `chi update`) and `chi update`'s upgrade of shipped bundles; both drive the Installer with `upgrade: true` |
 | `Uninstaller`, `Trash`, `Status`, `Listing` | remove, keep removed files, `chi bundle status`, `chi bundle list` |
 | `IndexUpdater`, `IndexSync` | the managed `index.md` lines (Installer; and the write/edit tools for memories) |

data/docs/internals/engine.md

@@ -527,10 +527,12 @@ Engine initialization (in this order, among other things):
   @event_routes (EventRoutes: where a card or a notice goes: held while the plugins load, an anytime command's, an init task's, a turn event, else announced or held)
   @hook_routes (HookRoutes: notices (through @event_routes), hook questions, stop_turn/stop_generation, steer attribution)
   @guardrail_wiring, @question_desk, @relay_desk (RelayDesk: a delegate's approval relay)
+  @thinking_notices (ThinkingNotices)
+  build_tools_and_plugins:
   @extension_load = ExtensionLoad.new; @hooks = @extension_load.hooks (config.yml's, then the bundles')
   @tools = Tools::Builtins.registry; @command_registry (SessionCommands' built-ins); @plugin_tasks
   @toolkit_binding (ToolkitBinding: the kits, the plugins' among them, and the turn-start apply)
-  @thinking_notices (ThinkingNotices); @tool_index = Tools::ToolIndex.new; @peer_sources = PeerSources.new
+  @tool_index = Tools::ToolIndex.new; @peer_sources = PeerSources.new
   the bundles' plugins load (load_plugins → ExtensionLoad#load_plugins; each plugin's ctx is a
     Plugin::Context over plugin_host, whose ctx.sessions it builds itself: the test kit passes its own, sessions:),
     then (plugins or not) @tool_index.declare(@tools): find_tools + call_tool (source "index", not core),
@@ -592,6 +594,23 @@ logged). Both are display only: `AnswerDisplay::DISPLAY_ONLY` lists `display`, `
 after_generation), while `KernelLoop#sanitize_history` and `ChatLoop#plain` copy them so the stored conversation keeps
 them across turns. `Web::App#messages_for_display` sends `display_refs` re-validated (`AnswerRefs.for_display`).
 
+`:question_asked` (`QuestionAsked`, `question_asked.rb`) fires from the two Engine seams where a question of the
+model's opens, never from `QuestionDesk`: `Engine#request_question` (the kernel's `question_handler`, after
+`AskUserQuestion.validate`; not with `interface == :non_interactive`) and the guardrail wiring's `ask:` lambda
+(`GuardrailWiring#request_approval`, after a stored approval and the non-interactive deny). So `ask_for_hook`, a
+relayed approval (`EnginePeers#open_question` → `Engine#open_question`) and `post` (the step-limit question) never
+fire it. `QuestionAsked.fire` is a no-op without a subscriber (`Registry#any?`); else it finds the live
+conversation's last `role: "model"` entry (`Engine#live_conversation`, one lookup for both loops: a ChatLoop batch may
+end in a tool result), builds an `AnswerRefs` on that step alone with the question caps (50 / 32 KiB), fires with the
+step's text (`Engine#question_step_text`: the parser's thought and tool-call strip, then
+`OutputFormatter.strip_markup`), a frozen copy of the fields and a no-op `ask_user`, then sets `display_refs` on
+the step **in place** under the event lock (the loops and the forget layer hold entries by identity) and returns the
+fields with `refs:`. `QuestionDesk#request` forwards `refs` past its slice; `PendingQuestion#refs` carries them to
+`:question_requested`, the session file and the cards. `Web::App#with_question_refs` re-validates them (the pending
+question, `cards_for_display`) with the same caps; the page pairs them in the asking slot, on the card and on the
+step's text ([architecture.md](../architecture.md), the `display_refs` paragraph). The kit's
+`Testing::Bundle#question_asked` calls `QuestionAsked.fire` with a one-step conversation.
+
 ### Hook lifecycle
 
 - **Bundle hooks** (`Registry#register_bundle`) and **config hooks** (`register_persistent`, from config.yml)
@@ -754,6 +773,7 @@ Paths are under `lib/samagotchi/`.
 | `toolkit_binding.rb` | `ToolkitBinding`: the Engine's toolkit seam (the kits, `#explained`, `ctx.use_toolkit`, the turn-start `#apply!` behind `Engine#apply_toolkit!`) |
 | `hooks/registry.rb` | Hook registry, fire order, `Hooks::Runtime` |
 | `hook_routes.rb` | `HookRoutes`: the Engine's routes for a hook's or plugin's notice (`:hook_notice`, `fallback_for:`), question, stop and steer, and the guardrails' after-load line |
+| `question_asked.rb` | `QuestionAsked`: the `:question_asked` fire, the asking step's refs (`display_refs` in place, the pending question's `refs`) |
 | `question_desk.rb`, `pending_question.rb`, `question_answer.rb` | `QuestionDesk`: the one open question (ask, post, answer, cancel, relay mark); `PendingQuestion` and `QuestionAnswer`, its values (Hashes only in events, Bridge JSON, the session file and the hook/plugin `ask_user` result) |
 | `hook_question.rb` | `HookQuestion`: a hook's or plugin's `ask_user` question as one value, from the runtime/host edge to `QuestionDesk#ask_for_hook` |
 | `event_routes.rb` | `EventRoutes`: where a card (`Engine#show_card`), a notice (`HookRoutes#notify`) and a guardrails line (`#guardrail_notify`, turn or between turns only) go: held while the plugins load, an anytime command's, an init task's, a running turn's event, else announced or held for `holding_announcements` |

data/docs/memory.md

@@ -18,8 +18,46 @@ Tool behavior:
 - `memory_write`'s `description` is the managed `index.md` line's text: one line (whitespace and newlines collapse to single spaces), at most 200 characters (longer is refused, since every session's prompt for the repo carries it). A missing or blank one keeps the line's description.
 - `memory_write` with `name`, `scope` and `description` but no `content` changes only that entry's index line (its size and date are refreshed; the date becomes today) and leaves the file as it is: a skill that keeps its status in a memory's description changes it without resending the body. The memory must exist in that scope; the form is refused for `index` and with `current_model_only`.
 - `memory_write` with `name`, `scope` and `remove: true` (no content, description or `current_model_only`) removes a memory: its file and its model overlays (`<name>.<key>.md`, not a dotted memory with an index line of its own) move into one dir of the bundle trash, `memory-<name>-<time>` under `memories/.bundles/.trash/`, which `chi bundle trash` lists and empties, and its index line is dropped. When the file is already gone (deleted by hand), the dangling line is dropped alone. A memory a bundle owns (an installed bundle's record lists it, or its line says `· from <bundle>`) is refused: `chi bundle uninstall` removes it. `index` can't be removed. The guardrails bundle's `memory-remove` rule asks before every removal, once at a time (see [Guardrails](guardrails.md#the-guardrails-bundle)).
+- `chi memory ls` and `chi memory rm NAME` are the user's side of the same (see [Listing and removing from the shell](#listing-and-removing-from-the-shell)).
 - `write`/`edit` that change a `*.md` right in a scope dir refresh its managed `index.md` line (date, bytes; the description is kept), as `memory_write` does. A memory created with `write` gets a line with no description; any other `.md` written there gets a line too. Model overlays (`<name>.<key>.md` next to `<name>.md`), files in another project's folder and files changed by `execute` are left out.
 
+## Listing and removing from the shell
+
+`chi memory ls [--scope project|system] [--format text|json]` lists the
+memories of both scopes (this folder's project first, then system; `--scope`
+one), by name: scope, name, size in bytes (right-aligned), date, `from <bundle>` for a
+bundle's memory, and the index description (cut at 60 characters; `--format
+json` has it all, with `path`, `source`, `overlays`, `indexed` and `file`).
+It reads what `memory_read` does: each scope's `index.md` lines and its
+`*.md` files. A model overlay isn't a row of its own: its memory's row ends
+in `[overlays: <key>, …]`. A file with no index line says `[no index line]`
+(its date is the file's), a line whose file was deleted by hand `[no file]`.
+
+```
+project  handoff    812  2026-10-21                          Coordinator hand-off: where the work stands [overlays: qwen3-6-35b-a3b]
+system   identity  5120  2026-10-03  from samagotchi-system  Who chi is and how it works with you
+```
+
+`chi memory rm NAME [--scope project|system]` removes a memory exactly as
+`memory_write` with `remove: true` does, and prints that line (the trash dir
+it went to):
+
+- the file and its model overlays (`NAME.<key>.md`) move into one dir of the
+  bundle trash, `memory-NAME-<time>`, which `chi bundle trash` lists and
+  empties; its index line is dropped (a dangling line alone, when the file is
+  already gone);
+- without `--scope`, NAME must be in one scope: in both it exits 2 with
+  `chi memory rm: NAME is in both scopes: chi memory rm NAME --scope project, or --scope system`;
+  in neither, 1;
+- a bundle's memory is refused (exit 1, `memory 'NAME' came from bundle B;
+  chi bundle uninstall B removes it`), as for `memory_write`: the bundle
+  owns it, and an upgrade would bring it back or merge into nothing;
+- `NAME.<key>` removes that one model overlay and leaves its memory (a
+  bundle's overlay is refused like its memory);
+- `index` can't be removed.
+
+It isn't asked first: it is the user's command.
+
 ## Model-Specific Memory Overlays
 
 Each memory entry may have a companion file named `<name>.<model-key>.md` in the same scope directory. When the entry is read under a matching model, the overlay body is appended automatically, separated by the standard `---` separator with a `Model-specific guidance (<key>):` header.
@@ -118,10 +156,12 @@ Working habits for this model:
     (already exists; use --force to overwrite)`; through the `dev` profile
     (`chi bundle install dev`, `chi bundle upgrade dev`, `chi update`) it is
     `model-notes: kept your own model_notes_deepseek.md (not the bundle's; to
-    take the bundle's, remove yours with memory_write remove: true, then chi
-    bundle install model-notes)`.
+    take the bundle's, remove yours with chi memory rm model_notes_deepseek
+    --scope system, then chi bundle install model-notes)` (a dry run,
+    `chi bundle upgrade dev --dry-run`, names it too).
   - **To take the bundle's version instead,** remove your note
-    (`memory_write` with `remove: true` moves it to the trash) and run
+    (`chi memory rm model_notes_deepseek --scope system`, or `memory_write`
+    with `remove: true`, moves it to the trash) and run
     `chi bundle install model-notes` again: the install writes the missing
     file and owns it from then on. Don't use `--force`: it overwrites every
     file of the bundle with no trash copy.

data/docs/plugins.md

@@ -433,7 +433,9 @@ This is a bundle hook, the same as a `hooks/*.rb` file. See
 [hooks.md](hooks.md#hook-events) for the events; on `:after_turn`,
 `event[:present]` sets how the answer is shown in the web
 ([Presenting the answer](hooks.md#presenting-the-answer-display-only)) and `event[:refs]`
-attaches refs to it ([Refs on the answer](hooks.md#refs-on-the-answer-display-only)). Its label is
+attaches refs to it ([Refs on the answer](hooks.md#refs-on-the-answer-display-only)); on
+`:question_asked`, `event[:refs]` attaches refs to the reply that asks a question
+([Refs on a question](hooks.md#refs-on-a-question-display-only)). Its label is
 `plugin.rb (bundle my-bundle)`. The block may take only the event. If it
 raises, the error is logged and the hook is skipped.
 
@@ -1159,6 +1161,7 @@ require "samagotchi/testing"
 bundle = Samagotchi::Testing::Bundle.load("path/to/my-bundle", settings: { "every" => 3 },
                                           host: { session_id: "s1", cwd: Dir.pwd })
 bundle.fire(:after_turn, status: "completed")            # → the event, after the hooks
+bundle.question_asked("Fix JIRA-1?", question: { question: "Go?" })   # → the refs, as chi's seams fire it
 event = bundle.before_tool_call_event({ name: "read", path: "a.txt" }, params: "read a.txt")
 bundle.command("/mine stop")                             # → what the command returned
 bundle.tool("my_tool", path: "a.txt")                    # → the text the model reads
@@ -1212,6 +1215,10 @@ bundle.shutdown
   lays them over `settings:` through chi's own `Context#settings`; the plugin's `initialize(settings)` gets
   `settings:` only. `bundle.set(session_settings:)` moves the session to a new id (`test-session-2`, or the
   `session_id:` given beside it): chi never changes them within a session, and builds `ctx.settings` once per id.
+- **`question_asked(text, kind: "question", question: {}, cwd: nil)`** fires `:question_asked` through
+  `QuestionAsked.fire`, as chi's two seams do: a step whose text is `text` asks a question (or `kind: "approval"`)
+  with the `question` fields, and the refs the hooks attach come back checked (the question caps, a file ref under
+  `cwd:`, default the session's folder), as the step and its pending question keep them; `[]` for none.
 - **A hook that raises fails the call** (`Testing::HookFailed`, with the hook's error) where chi would log it and
   go on; `bundle.lenient { … }` collects them in `bundle.errors` instead.
 - **Sandbox.** A test runs with temp config, state, data and cache homes (config.yml, memories, `ctx.data_dir`, the

data/docs/sessions.md

@@ -219,9 +219,9 @@ chi send --new --continues last:3fa2 -m "new day"      # the next link of 3fa2's
 
 ## Session titles
 
-A session is named by its first message until you give it a title: `/title Coordinator` (in the REPL, an attached terminal, the web composer or `chi send ID "/title Coordinator"`; a parent agent may name its delegates the same way). The title is saved in the session file (`title`), whitespace collapsed and cut at 80 characters, and runs mid-turn too, at once. `/title` alone shows it (`title: none (shows the first message: hey chi …)` without one); `/title --clear` drops it, and the first message names the session again. A session whose first line was the command itself (`chi send --new "/title X"`) takes its preview from its first real message.
+A session is named by its first message until you give it a title: `/title Coordinator` (in the REPL, an attached terminal, the web composer or `chi send -m "/title Coordinator" ID`; a parent agent may name its delegates the same way). The title is saved in the session file (`title`), whitespace collapsed and cut at 80 characters, and runs mid-turn too, at once. `/title` alone shows it (`title: none (shows the first message: hey chi …)` without one); `/title --clear` drops it, and the first message names the session again. A session whose first line was the command itself (`chi send --new -m "/title X"`) takes its preview from its first real message.
 
-The title names the session wherever its first message did: `chi sessions list` (plain, `--live`, tsv and json's `desc`, before the recap; json has `title` too), `chi sessions delete`'s line, the `list_sessions` tool, `chi broadcast`, the desktop helper, a parent's children (the coordinator bundle's `/children` card, `ctx.sessions.children`; `ctx.sessions.read` too), and in the web the cards, the families and chain rows, the top bar and the browser tab, the notifications and the search. The web's info bar has `✎` (Rename this session): a small input prefilled with the title; Enter or a click elsewhere sends `/title TEXT` when it changed (empty: `/title --clear`), Esc closes it unsent. A session a chi REPL owns has no `✎`. A continue's new link keeps the title (see [Session chains](#session-chains)). An older `chi web` (or any chi from before the field) that saves a session drops its title: restart `chi web` after upgrading.
+The title names the session wherever its first message did: `chi sessions list` (plain, `--live`, tsv and json's `desc`, before the recap; json has `title` too), `chi sessions delete`'s line, the `list_sessions` tool, `chi broadcast`, the desktop helper, a parent's children (the coordinator bundle's `/children` card, `ctx.sessions.children`; `ctx.sessions.read` too), and in the web the cards, the families and chain rows, the top bar and the browser tab, the notifications and the search; the terminal's status row too (the REPL's and an attached one's, first, see [Status Line](cli.md#status-line)). In the web, `✎` (Rename this session) sits next to the session's title, on its active strip card or after the top bar's title: a small input over the title, prefilled with it; Enter or a click elsewhere sends `/title TEXT` when it changed (empty: `/title --clear`), Esc closes it unsent, and so does the title leaving the screen (All sessions opened, the card swiped out of a phone's strip). A session a chi REPL owns has no `✎`, nor one that shows no title yet (`/title` still works from the composer). A continue's new link keeps the title (see [Session chains](#session-chains)). An older `chi web` (or any chi from before the field) that saves a session drops its title: restart `chi web` after upgrading.
 
 ## Session chains
 

data/lib/samagotchi/answer_refs.rb

@@ -52,7 +52,9 @@ module Samagotchi
   #
   # The target is AnswerDisplay's: the stored conversation's last message
   # when it is the model's. The list starts from the refs it already has
-  # (re-validated), so a later hook run never loses them.
+  # (re-validated), so a later hook run never loses them. QuestionAsked
+  # uses it too, on the step that asks a question (+messages+ that one
+  # step, lower caps).
   class AnswerRefs
     KEY = :display_refs
     MAX_REFS = 200
@@ -63,12 +65,13 @@ module Samagotchi
     # rebuilt and checked again, the caps applied; what isn't valid any
     # more is dropped. Never raises: a reload must show the conversation.
     # A relative file path is dropped (it was stored absolute), and with
-    # +cwd+ (the session's folder) a file outside it.
+    # +cwd+ (the session's folder) a file outside it. +max_refs+ and
+    # +max_bytes+: the caps (a question's are lower, QuestionAsked).
     # @return [Array<Hash>] the refs to send ({match:, kind:, target:, …})
-    def self.for_display(raw, cwd: nil)
+    def self.for_display(raw, cwd: nil, max_refs: MAX_REFS, max_bytes: MAX_BYTES)
       return [] if raw.nil?
 
-      kept = new([{ role: "model", KEY => raw }], cwd: cwd).to_a
+      kept = new([{ role: "model", KEY => raw }], cwd: cwd, max_refs: max_refs, max_bytes: max_bytes).to_a
       dropped = raw.is_a?(Array) ? raw.length - kept.length : 1
       Log.debug(:web, "display_refs_dropped", count: dropped) if dropped.positive?
       kept
@@ -81,10 +84,14 @@ module Samagotchi
 
     # @param messages [Array<Hash>] the conversation the turn stored
     # @param cwd [String, nil] the session's folder, for relative file paths
-    def initialize(messages, cwd:)
+    # @param max_refs [Integer] the list's cap in refs
+    # @param max_bytes [Integer] the list's cap in JSON bytes
+    def initialize(messages, cwd:, max_refs: MAX_REFS, max_bytes: MAX_BYTES)
       last = Array(messages).last
       @target = last if last.is_a?(Hash) && (last[:role] || last["role"]).to_s == "model"
       @roots = RowRefs.roots(cwd)
+      @max_refs = max_refs
+      @max_bytes = max_bytes
       @refs = []
       @seen = {}
       @bytes = 2 # the list's []
@@ -143,10 +150,10 @@ module Samagotchi
 
       entry = AnswerRef.from(value, roots: @roots).to_h
       return true if @seen.key?(entry)
-      return over_cap(hook, "#{MAX_REFS} refs") if @refs.length >= MAX_REFS
+      return over_cap(hook, "#{@max_refs} refs") if @refs.length >= @max_refs
 
       size = JSON.generate(entry).bytesize + (@refs.empty? ? 0 : 1)
-      return over_cap(hook, "#{MAX_BYTES / 1024} KiB") if @bytes + size > MAX_BYTES
+      return over_cap(hook, "#{@max_bytes / 1024} KiB") if @bytes + size > @max_bytes
 
       push(entry, size)
       @added = true
@@ -160,10 +167,10 @@ module Samagotchi
     # @return [Boolean] kept
     def keep(raw)
       entry = AnswerRef.from(raw, roots: @roots, relative: false).to_h
-      return false if @seen.key?(entry) || @refs.length >= MAX_REFS
+      return false if @seen.key?(entry) || @refs.length >= @max_refs
 
       size = JSON.generate(entry).bytesize + (@refs.empty? ? 0 : 1)
-      return false if @bytes + size > MAX_BYTES
+      return false if @bytes + size > @max_bytes
 
       push(entry, size)
       true