samagotchi 0.18.1 → 0.20.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 34f4c3e1960aa23902e27160bd1f325ba035731c283a93b2cd819676481c90a2
-  data.tar.gz: 708e58e5bfc26d10fe9f20bd1b696f6355e2a25749a36ca6503e82ca9077fa64
+  metadata.gz: c3b1a6860a8c22ed75259438c755633283385c12ffbc28a8fcb4c817f59114c5
+  data.tar.gz: 24f7c45ebe336077bc2d9a1e670d3313b364c48d5b28aef3624593705236f29e
 SHA512:
-  metadata.gz: 56c634e50c34f3fd027ca9ed7208d7edaab21a639050fe321c1d9fa5e8a0e818a31ae6c6351f8c21c0417984f3235a1a44b14aaa3d415b392a85d3bff2916aa1
-  data.tar.gz: 41862c98747027f791e4aa59b4c6d2eda092d818e3492212fbc79a24970c74734c3196c480511876aa97b95a8e1245c8bfd6fceccb73d47ade67d3f96ced89fa
+  metadata.gz: 9f1d9dec24344b223170728f80629a76d1db18697f752b2ce7135cf3569428a902f1cc18589a928184f7809bcbe3a20289281cd4cae6324bdd3f5bb1192cf860
+  data.tar.gz: 8bf9a7cf6dbaac98a7583987be61d98e06ddd3ab6a0b6f36423ae41a6aa530ef42479fa28139ad89b8253e61edce1a57013dd27d0a9bcbf5b31c080cea6f8801

data/CHANGELOG.md

@@ -8,6 +8,170 @@ and commands may change between minor versions. How releases are made:
 
 ## [Unreleased]
 
+## [0.20.0] - 2026-10-03
+
+### Added
+
+- `guardrails.mode` (config.yml only): `auto`, the new default, or `strict`. Rules can be tagged `modes: [strict]`
+  to vote only in strict mode; a rule without `modes:` (every rule you wrote in config.yml) votes in both.
+  `/guardrails` shows the mode and marks the rules it leaves out `(strict only)`. See docs/guardrails.md#modes.
+- New guardrail rule keys: `skip_read_only: true` (a shell command that only reads, such as `ls`, `cat`, `rg`,
+  `sed -n` or `git log`, doesn't match), `touches: chi_dirs` (a shell command names a path in chi's real config,
+  hooks, approvals or bundles dir, or a `.git/hooks`) and `rm: outside_tmp` (an `rm -rf` reaches outside the tmp
+  dirs). A config.yml rule that uses one fails closed on an older chi.
+- Model speed and token stats. `/stats` has a speed line (the last generation's decode speed and the
+  session's average: exact from llama.cpp, estimated and marked `~` elsewhere), cached and reasoning
+  tokens, and the cost when the provider reports it (OpenRouter). The web's info bar shows the speed
+  next to `ctx`, updated after each generation, and the `ctx` tooltip there and on session cards lists
+  tokens in / cached / out (+ reasoning) and the cost, for that session only.
+
+### Changed
+
+- [BEHAVIOUR] Guardrails ask less by default (auto mode). The guardrails bundle (0.5.0) no longer asks before
+  `git rebase`, writes outside the session's repo (`write-outside-repo`) or git in another checkout
+  (`git-outside-repo`); `guardrails: { mode: strict }` in config.yml brings those back. Everything else still asks
+  in both modes, as do the small-model rules and chi's own protected paths.
+- [BEHAVIOUR] `shell-touches-chi` matches chi's real folders instead of text, and lets read-only commands through:
+  `ls ~/.config/samagotchi`, `rg samagotchi/hooks lib` and a scratch copy under `/tmp` no longer ask; `echo x >>
+  <config dir>/config.yml` and `cp hook .git/hooks/pre-commit` still do. A word it can't resolve falls back to the
+  old text match.
+- [BEHAVIOUR] `rm-rf-wide` no longer asks when every `rm -rf` target is inside a tmp dir (`rm -rf /tmp/x`);
+  `/tmp` itself, `/tmp/*`, a `$VAR` and a link out of tmp still ask.
+- [BEHAVIOUR] "Allow … in this repo" approvals hold for the whole repository, in every worktree of it, and the
+  ask names the repository (`in this repo (samagotchi)`) instead of the worktree folder. Approvals stored
+  before keep matching their exact folder.
+- `chi bundle status` shows a bundle whose recorded scope this chi doesn't know (one a newer chi wrote, or a hand
+  edit) as `scope=team (unknown)`, counted as one issue, instead of checking its files in the system memories;
+  the shipped-bundle update skips it (upgrade chi or reinstall), and `chi bundle diff` refuses it with a one-line
+  error instead of a stack trace.
+- The web model picker shows a model's configured sampling (`temperature=0.6 (hosts.work)`) as its row's tooltip;
+  `GET /api/models` has it as `sampling` on the models that have some.
+- The web shows a plugin card that is only a notice (info level, no buttons, one short line, such as check-in's
+  "Nudged the model at 105 tool calls.") as a one-line row, `▸ check-in: Nudged …`, that opens on a click, like the
+  tool rows and resolved questions; warn cards, cards with buttons and longer ones stay framed cards.
+- On a phone (a window under 900 px wide) the sessions strip's `hide` is in the top bar, where the `▾ N sessions`
+  pill comes back, with a finger-sized target, instead of the last column of the sideways-scrolling strip.
+- On a phone the web info bar shows `mem N` (the memories the session used; their names in the tooltip) after the
+  session's status, since the `mem: …` line is hidden there.
+- The web info bar's chips (model, ctx, speed, session time) are tinted over the card's glass instead of solid, and
+  the empty-history cover is see-through like the session panel.
+
+### Fixed
+
+- An MCP server that exits without a wait status no longer raises `NoMethodError`; its waiting calls fail with
+  "the server exited" instead of hanging.
+- A hook that raises is now logged (`hook_failed`) instead of being swallowed silently; the turn still goes on.
+- A hook's card (check-in, skills) now prints under its tool call's row: `tool_call_completed` is emitted before
+  `after_tool_call` fires.
+- When a hook corrects a tool call (known-names), the model is told what actually ran with a leading
+  `ran as: <tool> <args>` line.
+- MCP image content is described with a neutral `[image N: …]` line instead of claiming it was attached, which
+  was wrong for a model that can't see images.
+- An MCP `resource` block carrying an image `blob` is now attached like an `image` block instead of being
+  dropped to its URI text.
+- check-in's `nudge` mode no longer says "nudged" when the steer was dropped later; it says "nudge not sent" at
+  the turn's end.
+- A session started with an annotation (a web quote) is previewed by the note typed under the quote, not
+  `From your thinking: > …`; a quote with no note previews by its words.
+- A session that has only context notes so far (`chi note`, `send_note`) is previewed on its card and in the
+  lists as `note: …` instead of `—`, until a message is typed.
+- A web turn of images alone names each image once in the transcript a recap is written from, not twice.
+- `chi bootstrap` no longer says "loading the model?" for a slow test on a remote provider (OpenRouter and the
+  like); the hint is for a local server, where a slow answer is a model loading.
+- `chi bootstrap` says why it saved a host as `name-2` when the derived name is already taken (or a model id
+  starts with it), instead of silently picking another name.
+- `chi bundle upgrade` reports a hook or plugin file that is byte-identical to the installed one as "already up
+  to date" instead of "Updated".
+- `chi bundle upgrade --agent` from a git/zip/tar source no longer hands the agent an `incoming:` path that was
+  already deleted: the extracted source is kept until the agent step is done, then cleaned up.
+- `chi self` now checks a local `api: openai` host's reachability (a `GET <base>/models` with the same short
+  probe timeouts) and reports up/down with the ids it serves, instead of always saying "reported per turn".
+
+Update with `chi update`: guardrails moves to 0.5.0 (auto mode and the new rule keys; it needs chi 0.20.0), mcp to 0.4.1 (exit status, image lines, image blobs) and check-in to 0.2.1 (a dropped nudge says so). Restart `chi web` and running sessions afterwards (`chi sessions restart ID`).
+
+## [0.19.0] - 2026-10-03
+
+### Changed
+
+- A new or woken session worker runs the newest chi installed, whoever starts it: a `chi web`, `chi send` or
+  terminal left on an older chi no longer starts workers on its own version. A worker already running keeps its
+  version until it is restarted.
+
+### Added
+
+- `chi web` notices a newer chi installed (`chi update`, `gem update`, a `git pull` in a checkout) and says to
+  restart it, in its terminal and once in each open page.
+- The web's info bar marks a session whose worker runs an older chi than the newest installed, with a Restart button
+  (or, for a worker from before restarts, the `chi sessions stop ID` to run); the page and the draft in the
+  composer stay as they are and follow the new worker.
+- An attached terminal says in one line when the session's worker or the terminal itself runs an older chi than
+  the newest installed, and how to move each (`chi sessions restart ID`; `/detach`, then `chi --attach ID`). When
+  the worker restarts, the terminal stays attached and says so.
+- `chi sessions restart ID...` moves a running session to a new worker on the newest chi installed, keeping its
+  attached terminal and web tabs on it; it is refused, with the reason, while a turn, a question, reminders or
+  background tasks would be lost.
+- A bundle can ship per-model memory overlays (`tips.<model-key>.md` beside `tips.md`): they load only for that
+  model, as a `memory_write current_model_only` overlay does, and `chi bundle build tips.md` brings them along.
+
+### Fixed
+
+- `chi update` no longer says running sessions move to the new chi "at idle exit (30 min)": a worker keeps its chi
+  until restarted, and idles out only with nothing attached, after `session.idle_exit_minutes` (never with 0). The
+  workers row names `chi sessions restart ID` (or `stop` for a worker from before restarts).
+- `chi web` no longer leaves exited session workers behind as zombie processes.
+- The web's model picker lists a host added to (or changed in) `hosts:` while `chi web` runs, instead of the hosts
+  it started with.
+- A bundle's model overlay no longer gets an `index.md` line of its own after `chi bundle install`, which showed it
+  to every model as a memory to read; `chi bundle status` reads it `ok (model overlay)`, uninstall no longer re-adds
+  its line, and an overlay whose base is nowhere, or only among your installed memories, installs with a warning. A
+  line an earlier install wrote goes with the bundle's next upgrade.
+- source-links (0.3.2): a `case_insensitive: true` source no longer lists a ref in its `sources:` note when the ref
+  is a markdown link's label whose target names it in another case (`[jira-1](…/JIRA-1)`). Run `chi update` to get it.
+- An `@path` image in a prompt takes backslash escapes, as a Finder drag into the terminal types them:
+  `@my\ shot.png` and `@a\ \(1\).png` attach the file instead of stopping at the first space.
+- An `http` host named by a public name (`gpu.example.com`) counts as a remote provider (120-second first-token
+  limit, no llama.cpp `/props`), as a public IP address already did. Names without a dot and local suffixes
+  (`.local`, `.lan`, `.home.arpa`, `.internal`, `.ts.net`, `fritz.box`, …) stay local; `hosts.<name>.remote` decides
+  either way.
+- `chi web` no longer logs `ERROR HTTPRequest#fixup: WEBrick::HTTPStatus::LengthRequired occurred.` after a POST
+  without a body.
+- The web's delete confirm no longer promises a running worker from a stale list: it says the worker is stopped
+  first if it is still running.
+- The web's scope links (`all`, `← project`) keep the page's `?view=stage|turn`.
+- An approval card's verdict (`Allowed (scope)` / `Denied`) reads above the command it decided, so it no longer
+  looks like part of the tool call when the card's details are expanded.
+- Answering or dismissing a question no longer says "Session is not running" when the worker is live but failed the
+  request: the server answers 502 with the worker's detail and the card shows it. 503 stays for a session with no
+  live worker.
+- A turn that failed to send no longer leaves its prompt waiting to be restored into the composer later; and text
+  typed while a fast-failed turn's prompt was coming back is kept, with the restored prompt going under it.
+- A worker that dies between a turn's end and its after-turn display no longer leaves the turn's answer bubble
+  waiting: the page stops waiting when the worker goes away, or after 20 s.
+- A first web message the page answers itself (`/stats`, `/exit` …) or that is a typo of a command (`/modle`) no
+  longer leaves an empty session behind.
+- A question card reopened after a reload shows its result once, in the collapsed summary, not twice.
+- After a mid-turn reload, this tab's own prompt is still recognized as its own instead of being labelled `web`.
+- A `chi scratch` session no longer offers `send_note`, so it leaves no note behind in another session.
+- A `chi scratch` session's tool approvals offer only "Allow once" and "for the session", and keep a session
+  approval in memory: no "in this repo" or rule approval from it stays in the approvals store.
+- A message sent (web, `chi send`, a delegate) to a session whose worker is slow to start no longer starts a second
+  worker beside it.
+- The note a cancelled turn leaves for the model says "the reply above ends where it was cut off", not "the
+  answer", so narration cut off before a tool call isn't taken for an answer.
+- A session worker that wakes again shows the model the server last said it served (`/stats`, the status row,
+  the web's info bar) right away, instead of none until its first generation.
+- A tool call still running when its turn is cancelled (or fails) is saved in the session's analytics as
+  `canceled`, so the session's tool totals (`/stats`) count it as the turn did instead of dropping it.
+- A session's `analytics.json` `session_duration_ms` runs from the session's `started_at`, not from when its current
+  worker started.
+- A session started with `chi --model X` no longer hands X to the commands it runs as the default model: a `chi
+  self` (or other chi) run there reports and uses the configured default, with X as this session's model. A
+  `SAMAGOTCHI_DEFAULT_MODEL` you export yourself still passes.
+- A preloaded memory that can't be loaded is warned about once, not again each time the prompt is rebuilt (another
+  thinking level, a `/model` switch).
+
+Update with `chi update`: source-links moves to 0.3.2 (case-insensitive link targets). Restart `chi web` afterwards; from now on it tells you when a newer chi is installed.
+
 ## [0.18.1] - 2026-10-03
 
 ### Fixed
@@ -1035,7 +1199,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.18.1...HEAD
+[Unreleased]: https://github.com/dm1try/samagotchi/compare/v0.20.0...HEAD
+[0.20.0]: https://github.com/dm1try/samagotchi/compare/v0.19.0...v0.20.0
+[0.19.0]: https://github.com/dm1try/samagotchi/compare/v0.18.1...v0.19.0
 [0.18.1]: https://github.com/dm1try/samagotchi/compare/v0.18.0...v0.18.1
 [0.18.0]: https://github.com/dm1try/samagotchi/compare/v0.17.0...v0.18.0
 [0.17.0]: https://github.com/dm1try/samagotchi/compare/v0.16.0...v0.17.0

data/README.md

@@ -54,9 +54,10 @@ chi update              # the gem, then the bundles and the desktop helper
 stay installed: running sessions still use them), then brings the rest up to
 the new version: the system bundle, the bundles chi ships that you installed,
 and the macOS helper (rebuilt only when its sources changed). Memory files you
-edited are kept, and the table says which. Running sessions move to the new
-chi when their worker idles out (30 min) or on `chi sessions stop ID`; a
-running `chi web` needs a restart. From a checkout, `git pull` instead. See
+edited are kept, and the table says which. Running sessions keep their chi
+until restarted (`chi sessions restart ID`, or the Restart badge on the web);
+new and woken ones start on the new chi. A running `chi web` needs a restart,
+and its page says so. From a checkout, `git pull` instead. See
 [CLI: Updating](docs/cli.md#updating).
 
 ## Set up

data/docs/architecture.md

@@ -213,6 +213,10 @@ process that already owns the `Engine`); every worker starts it, and it exposes:
   too-old reconnects, and cursors from another worker's epoch, receive a `reset` marker carrying
   `session_state_snapshot`. `?snapshot=1` joins with a snapshot frame instead of a replay;
   `?client_id=` names whose stream it is (`Bridge#open_streams_except`, used by `POST /exit`).
+  An attached terminal's stream (`EventStream` with `rediscover:`) looks for the session's live
+  worker whenever it drops: a new one (a restart) is followed from its snapshot, and the terminal
+  sends its requests there (`worker_changed`); it gives up after ~12 s, or at once when the session
+  was stopped.
 - `POST /session/:id/turn` — fire-and-forget turn creation; returns `202` with an `enqueued_id`
   (delivery is at-least-once via the worker's file-IPC input path — it never calls `run_turn`
   across the HTTP boundary). Only the bridge's own session: another id, in the path or the body's
@@ -270,6 +274,12 @@ The metrics in `/state`, `/snapshot`, `/stats` and the SSE `snapshot`/`reset` fr
 newest turn the worker finished and any it hasn't saved yet (at most 20 turns), with their tool
 calls and the running turn's finished ones. The full history is the session's `analytics.json`,
 which `SessionMetrics#persist` rewrites after each turn; the web server merges the two by id.
+The totals' `tokens` block adds the cached and reasoning sums, the cost, the decode time and tokens
+behind the average speed (`avg_decode_tps`) and the last speeds (`last_decode_tps`,
+`last_prefill_tps`, `tps_source`: `server` or `estimate`). Each `generation_completed` event
+carries the generation's `speed` (`{decode_tps, source}`, null without one) and those running
+`tokens`: the Engine closes the generation in `SessionMetrics#finish_generation` before relaying
+it, so the web's info bar updates per generation without parsing chunk payloads.
 
 The page's frequent reads of `GET /api/sessions/:id` stay light too:
 - `?tail=1&recent=1` (each turn's end, a cancel, an answer display): `{tail, session: {id, status,
@@ -302,7 +312,13 @@ the server, no daemon) that keeps an in-memory projection of the session list an
 changes to every open tab over `GET /api/events` (SSE: a `snapshot` frame on every connect,
 then `session` for an upsert and `session_gone` for a removal, `: ping` while idle, no replay).
 The snapshot names chi's version: a tab served by another one (its `<body data-version>`) offers a
-reload in a toast, since an open tab keeps its old JS across a `chi web` upgrade.
+reload in a toast, since an open tab keeps its old JS across a `chi web` upgrade. It also names
+`installed`, the newest chi on this machine (`InstalledVersions`: the highest `samagotchi-<v>.gemspec`
+in RubyGems' specification dirs, or a checkout's `version.rb` on disk; looked at again on each full
+probe, every 10 s), and a change is a `chi` frame `{version, installed}`. A newer one than the
+server runs is said in chi web's terminal and on the page: restart chi web (its workers already
+run the newest chi, [Sessions](sessions.md)). `GET /api/info` carries `installed` too, and the
+feature `newest_workers`.
 Files stay the source of truth and workers don't know the hub. Its watcher is a 1 s tick that
 stats the sessions dir (every session writer goes tmp + rename, which bumps the dir's mtime) and
 each `<id>/` folder (recap.json, bridge.json, the stopped and archived markers), re-parsing only the files whose mtime or size
@@ -310,7 +326,10 @@ moved through `Session.summary_from_file`. Liveness is probed, since a killed ow
 file trace: the owner lock every tick for the sessions the projection believes owned, and every
 session every 10 s, so a `kill -9` shows within a second. The summary (`Web::SessionSummary`,
 shared with `/api/sessions` and the session view) carries `owner`, `project_root` and
-`bridge_up` (the sidecar is there *and* the lock is held: the page attaches its stream on it).
+`bridge_up` (the sidecar is there *and* the lock is held: the page attaches its stream on it), and
+from that sidecar `worker_version` (the chi the worker runs) and `worker_features`
+(`Bridge::FEATURES`, what a client may ask of it beyond the routes). A worker's Bridge snapshot
+names its `chi_version` too.
 `POST/DELETE /api/sessions` and `/stop` rescan the session before answering (`SessionHub#touch`).
 `GET /api/sessions` is the hub's projection too (its sort, paging and total). `Server` always builds
 a hub; an `App.new` without one answers both routes `503 no_hub`.

data/docs/cli.md

@@ -15,7 +15,7 @@
 - `chi web --web-host lan` — the Web UI on your home network too, for your phone: a link with an access token and its QR code (see [chi web on your phone](#chi-web-on-your-phone)); `chi web --new-token` replaces the token
 - `chi web --web-markdown` — opt in to sanitized Markdown rendering for completed assistant messages
 - `chi web --web-view turn` — draw turns with the turn view (each turn as one block of steps, the running one at the bottom of the history) instead of the default stage view (the running turn pinned above the composer); `?view=stage|turn` on the page URL overrides it (see [Web views](#web-views))
-- `chi sessions list|stop|archive|unarchive|delete|prune|clean` — manage persisted sessions; `list` shows this git project's, `list --scope=all` every one, a delegated session with `↳ <parent>`, `list --archived` the archived ones too (see [Sessions](sessions.md)). A usage error (an unknown subcommand or flag, a flag missing its value, `stop` or `delete` with no ids, a bad `list --format` or `--scope`) exits 2; an unknown or refused session exits 1
+- `chi sessions list|stop|restart|archive|unarchive|delete|prune|clean` — manage persisted sessions; `list` shows this git project's, `list --scope=all` every one, a delegated session with `↳ <parent>`, `list --archived` the archived ones too (see [Sessions](sessions.md)). A usage error (an unknown subcommand or flag, a flag missing its value, `stop`, `restart` or `delete` with no ids, a bad `list --format` or `--scope`) exits 2; an unknown or refused session exits 1
 - `chi note [--source NAME] [-m TEXT] (ID|PREFIX)... | --all` — add a context note (TEXT or stdin) to sessions: background the model sees on its next turn; it starts no turn (see [Sessions: Context notes](sessions.md#context-notes))
 - `chi send [-m TEXT] [--image PATH]... (ID|PREFIX)...` — send a message to sessions as if typed there: a turn starts (or a running one picks it up); 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, and `--wait` prints the answer (`--wait ID` with no message waits for the next reply without sending; `--format json` prints one JSON object instead; 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`). An approval can be denied, not allowed, unless `guardrails.parent_approvals: once` (a convention, not a security boundary; see [Guardrails](guardrails.md#approvals-from-a-parent-agent))
@@ -53,7 +53,9 @@ chi bootstrap                            # try localhost 8080, 11434, 1234, 8000
 - **The file.** With no config.yml it writes a small commented one:
   `default.model` as `<host>:<model>` and one `hosts:` entry named `local`
   (localhost), `lan` (an IP) or after the domain (`openrouter`); `--name`
-  sets it. An existing file is left as it is apart from the new entry, added
+  sets it. When that name is taken (or a model id starts with it), chi picks
+  `name-2` and says why, with `--name` to choose another. An existing file is
+  left as it is apart from the new entry, added
   at the end of its `hosts:` block (it gets a `hosts:` block, with a
   `default` entry for its `server:` first, when it has none), after a backup
   to `config.yml.bak-<time>`. `default.model` is set only when the file has
@@ -104,17 +106,19 @@ known-names    0.1.0  0.1.1  updated
 core           0.1.0  0.2.0  updated (+ new-bundle)
 infra_tools    1.0.0         skipped (not from chi)
 Chi Helper     0.2.0         up to date (launch file refreshed)
-workers                      2 live on 0.2.0: they move to 0.3.0 at idle exit (30 min) or chi sessions stop 2ea8c1f0 91b0d2aa
+workers                      2 live on 0.2.0: they keep it until restarted (chi sessions restart 2ea8c1f0 91b0d2aa); or they idle out after 30 min with nothing attached
 Also shipped, not installed: dev (mcp, skills, source-links) (chi bundle install NAME)
 done
 ```
 
 - **The gem.** It asks rubygems.org for the newest samagotchi (5 s timeout)
   and, when that's newer, runs `gem install samagotchi` with the gem command
-  of the Ruby chi runs on (the real one, not a mise/rbenv/asdf shim). Then it
+  of the Ruby chi runs on (the real one, not a mise/rbenv/asdf shim; a chi
+  installed under another Ruby is a separate install it doesn't touch). Then it
   hands over to the new chi, which does the rest and prints the table. Old
-  versions stay installed: running workers and an old `chi web` still use
-  them (so don't `gem cleanup` while they run). Offline, the row says
+  versions stay installed: running workers and an old `chi web` still load
+  files from them, so a `gem cleanup` while they run breaks them (a
+  `LoadError`, missing web assets); restart them first. Offline, the row says
   "couldn't check" and the rest still runs; a failed install fails the row
   and the rest runs on the current version. Under Bundler (`bundle exec`)
   the row says `bundle update samagotchi` instead.
@@ -137,9 +141,15 @@ done
 - **The desktop helper** (macOS) is rebuilt and restarted only when its Swift
   sources changed (or the Ruby it runs moved); otherwise only its launch file
   is refreshed. See [Desktop helper](desktop.md).
-- **Running processes** are reported, never stopped: live workers on another
-  version, and a `chi web` on `web.port` running an older chi (sessions it
-  starts run that version too: restart it).
+- **Running processes** are reported, never stopped. A live worker keeps its
+  chi until it is restarted: `chi sessions restart ID` (one from before
+  restarts: `chi sessions stop ID`, and the next prompt starts it on the new
+  chi); it exits on its own only when nothing is attached (no web tab, no
+  terminal, no reminder) and `session.idle_exit_minutes` pass (never with 0).
+  A new or woken worker always starts on the newest chi installed. A `chi web`
+  on `web.port` running an older chi needs a restart (Ctrl-C, then `chi web`):
+  its page says so too. One from before workers started on the newest chi
+  also starts its new sessions on its own version until then (the row says so).
 
 `--dry-run` shows the table with "would update" and changes nothing. It is
 this version's view: bundles that only a newer gem ships newer show up once
@@ -251,8 +261,12 @@ and `--shared` are refused. Its first line says it is a scratch session.
   answers "scratch session: nothing is saved", and `write`/`edit` into the
   memories folder are denied (a guardrail, rule `scratch-session`). `execute`
   can still write files anywhere, memories included.
+- An approval offers only "Allow once" and "for the session", and a session
+  approval is kept in memory, not in the approvals store; approvals stored
+  before still apply.
 - No child sessions: the `delegate` tools are not offered, and a plugin's
   `ctx.sessions.fork` (btw's side session) refuses, since they would outlive it.
+  Nor is `send_note`, whose note would stay in the other session.
 
 ### Sharing a session
 
@@ -320,6 +334,20 @@ a `chi --resume ID` after it starts a fresh one. A worker still running an
 older chi (from before an upgrade) takes turns but not commands; the attached
 terminal and the Web UI say so, with that restart line.
 
+`chi sessions restart ID...` hands each session to a new worker on the newest
+chi installed, without stopping it: an attached terminal and the web's tabs
+move to the new worker. It is refused, with the reason, while something would
+be lost: a turn running or queued, a question or approval waiting, reminders,
+a `/btw` still running, an approval relayed from a delegate, or background
+tasks the session started. A session with no running worker needs none (its
+next prompt starts one on the newest chi), and a worker from before restarts
+needs `chi sessions stop ID`. The Web UI's `POST /api/sessions/:id/restart`
+does the same (409 with `reason` and `detail` when it can't). An attached
+terminal says at the join, in one `chi>` line, when the worker or the terminal
+runs an older chi than the newest installed (the worker moves with `chi
+sessions restart ID`, the terminal with `/detach` and `chi --attach ID`), and
+`chi> the session's worker restarted on chi X` when its worker was replaced.
+
 `chi sessions archive ID...` hides sessions from every list (the terminal's,
 the web's, `list_sessions`) and keeps them for good: the retention sweep never
 deletes an archived session, nor counts it. Its delegates go with it. A live
@@ -387,8 +415,17 @@ file and index line stay as they are; only this session doesn't see it.
 `/help` lists the commands this session takes, the installed bundles' too, each
 with a line on what it does. `/stats` shows the session's numbers: turns, tool
 calls (by tool, with errors), iterations, tokens in/out summed over every
-request, generation latency, cancellations, retries, context used and window,
-the prompt profile and the model the server says it ran. `/recap` is in
+request (with the cached and reasoning tokens when the server reports them),
+the decode speed, generation latency, cancellations, retries, context used
+and window, the prompt profile and the model the server says it ran, and the
+cost when the provider reports one (OpenRouter's `usage.cost`; no prices are
+guessed). The speed line is the last generation's and the session's average
+(weighted by tokens): llama.cpp reports it exactly (`87 tok/s out, 1.9k tok/s
+prompt (last, server)`); for other servers it is estimated from the first
+streamed chunk to the end and marked `~` (`~64 tok/s out (last, estimate)`).
+Generations under 8 tokens or 100 ms get no speed of their own, nor does a
+reply without server token counts or a non-streamed one. A delegated child
+keeps its own numbers: a parent's tokens and cost leave them out. `/recap` is in
 [Session recap](#session-recap), `/model` and `/models` in [Runtime Model
 Switch](#runtime-model-switch-assist-mode).
 

data/docs/configuration.md

@@ -94,8 +94,9 @@ Behavior:
 - An edit to the file needs no restart of `chi web`: a new session's worker
   reads the file when it starts, and a running chi takes a changed value the
   next time it reads that setting (a worker keeps `hosts:` and what it set up
-  at its start until it is stopped). A worker gets the CLI flags of the chi
-  that started it through its environment.
+  at its start until it is stopped; the web's model picker lists a `hosts:`
+  edit at once). A worker gets the CLI flags of the chi that started it
+  through its environment.
 - Workers inherit hosts via `SAMAGOTCHI_HOSTS_JSON` propagated through `SessionManager.spawn_options`.
 
 This lets you run `chi` without repeating common defaults such as model
@@ -235,11 +236,16 @@ hosts:
 **Remote or local.** chi treats a host as a remote provider by its address, not
 by its key: an `https` url, or an `http` IP address outside the loopback,
 private (`10.*`, `172.16–31.*`, `192.168.*`, IPv6 `fc00::/7`), link-local and
-CGNAT/Tailscale (`100.64.0.0/10`) nets. An `http` host given by a name
-(`localhost`, `box`, `mac.local`) is local: chi doesn't look names up. A remote
+CGNAT/Tailscale (`100.64.0.0/10`) nets, or an `http` name with a dot that
+doesn't end in a local suffix (`gpu.example.com`). A name without a dot (`box`)
+or ending in `localhost`, `.local`, `.lan`, `.home`, `.home.arpa`, `.internal`,
+`.intranet`, `.localdomain`, `.private`, `.corp`, `.test`, `.box` (`fritz.box`)
+or `.ts.net` (Tailscale) is local: chi doesn't look names up. A remote
 host keeps its model list for 10 minutes, gets a 120-second first-token limit,
 and isn't asked for llama.cpp's `/props` (its context window and served model
-come from its model list and each turn). `remote: true` or `remote: false` on a
+come from its model list and each turn). A local `api: openai` host has no
+`/props`, so `chi self` GETs its `/models` with the same short probe timeouts
+and reports up/down with the ids it serves. `remote: true` or `remote: false` on a
 host decides it instead, e.g. for a llama.cpp behind an https proxy on the LAN:
 
 ```yaml
@@ -848,6 +854,7 @@ described in their own sections.
 | `image.max_bytes` | `3750000` | | See "Images". |
 | `image.max_per_request` | `20` | | See "Images". |
 | `guardrails.enabled` | `true` | | `false`: no rules, and hooks' asks are dropped (a deny still applies). config.yml only: a worker unsets any `SAMAGOTCHI_GUARDRAILS_*` it inherits. See [Guardrails](guardrails.md). |
+| `guardrails.mode` | `auto` | | Which rules vote: `auto` leaves out the rules tagged `modes: [strict]` (in the guardrails bundle: `git rebase`, writes and git outside the session's repo); `strict` runs them all. An unknown value warns and is `auto`. config.yml only. See [Guardrails](guardrails.md#modes). |
 | `guardrails.small_models` | `auto` | | Which models get the `models: small` rules: `auto` (32B or less by the size in the name, an MoE's active size), a list of globs, or `[]`. config.yml only. See [Guardrails](guardrails.md#rules-for-some-models). |
 | `guardrails.parent_approvals` | `off` | | What `chi answer` lets a parent agent allow on an approval: `off` (deny only) or `once` ("Allow once", never a wider scope). config.yml only: no environment variable (a parent can still pick the config dir with `XDG_CONFIG_HOME`). A convention for an honest parent, not a security boundary. See [Guardrails](guardrails.md#approvals-from-a-parent-agent). |
 | `log.file` | state dir | yes | See "Debug Log File". |

data/docs/guardrails.md

@@ -81,6 +81,13 @@ Allowing beyond "once" is stored in `$XDG_STATE_HOME/samagotchi/guardrails/appro
 | repo | this exact call in this repo (the cwd outside a repo), any session |
 | rule | anything this rule asks about in this repo |
 
+"This repo" is the git repository, not the folder: an approval given in one
+worktree holds in the main checkout and every other worktree of it (it is
+stored with the repository's common git dir as `repo`, and the worktree as
+`repo_root`). The ask names the repository (`Allow this call in this repo
+(samagotchi)`). An entry stored before chi 0.20 has no `repo` and still only
+matches its exact folder.
+
 A stored approval only relaxes an ask; a deny rule is never approvable.
 A file that doesn't parse is moved aside to `approvals.json.corrupt-<UTC time>`
 with one warning, and chi starts with no stored approvals (more asks, nothing lost).
@@ -137,7 +144,7 @@ grants no permission, so a parent may answer it either way by default.
 `turn.parent_continue: false` (config.yml only, like `parent_approvals`)
 makes parents stop-only. See [chi as a sub-agent](sub-agent.md#the-step-limit).
 
-The guardrails settings (`enabled`, `small_models`, `parent_approvals`) are
+The guardrails settings (`enabled`, `mode`, `small_models`, `parent_approvals`) are
 read from config.yml only: they have no environment variable, and a worker
 chi starts unsets every `SAMAGOTCHI_GUARDRAILS_*` it would inherit. What a
 parent's environment does choose is the config dir: `XDG_CONFIG_HOME` picks
@@ -182,6 +189,7 @@ commands that name them.
 ```yaml
 guardrails:
   enabled: true              # false: no rules, and hooks' asks are dropped (a deny still applies); config.yml only
+  mode: auto                 # or strict: also the rules tagged modes: [strict]; config.yml only
   rules:
     - id: git-push
       tool: shell            # execute + task_create; or a tool name, a glob, or a list
@@ -201,7 +209,41 @@ guardrails:
       scopes: [once, session, rule]
 ```
 
-A rule gives at least one of `tool`, `command`, `path` and `git`.
+A rule gives at least one of `tool`, `command`, `path`, `git`, `touches` and `rm`.
+
+`rm: outside_tmp` (shell tools) matches a command whose `rm -r -f` reaches
+outside the tmp folders (`$TMPDIR`, `/tmp`, `/var/tmp`): every such `rm` in a
+chain must name only paths inside one, resolved like `touches` (so
+`/tmp/../etc` and a link from `/tmp` to `/` are outside). The tmp folder
+itself, a glob (`/tmp/*`), a `$VAR` other than `$HOME`/`$TMPDIR`, an `rm`
+behind `sudo`/`xargs`/`sh -c` or in `$(…)`, and the tmp folder the session's
+repo is in count as outside.
+
+`touches: chi_dirs` (shell tools) matches a command that names a path in chi's
+own folders: the config folder (`config.yml`, `memories/`), the hooks folder,
+the approval store, installed bundles (`memories/.bundles`), the session repo's
+git hooks (`core.hooksPath` honoured) or any `.git/hooks` outside a tmp folder.
+Each word is read as a path against the folder the command is in by then
+(`cd`, `pushd`/`popd` and `( … )` followed), with `~`, `$HOME` and
+`$XDG_CONFIG_HOME`/`$XDG_STATE_HOME` expanded and symlinks resolved. So
+`/tmp/x/config/samagotchi/config.yml` and chi's own source
+(`lib/samagotchi/hooks/…`) don't match. A word it can't resolve (another
+`$VAR`, `$(…)`, a glob, a relative path after `cd $X`) or one that reads as a
+script (`sh -c '…'`, `ruby -e '…'`) is matched as text instead (`.config/samagotchi`,
+`samagotchi/config.yml`, `samagotchi/hooks`, `samagotchi/guardrails`,
+`memories/.bundles`, `.git/hooks`).
+
+`skip_read_only: true` lets a shell command through when it only reads:
+every command in it (split at `;`, `&&`, `||`, `|`) is `ls`, `cat`, `head`,
+`tail`, `wc`, `stat`, `du`, `grep`, `rg`, `find`, `tree`, `file`, `sort`,
+`uniq`, `cut`, `diff`, `echo`, `cd`, `sed`, `awk` or a reading `git`
+(`log`, `show`, `diff`, `status`, `branch` listing, …), with no option that
+writes or runs something (`sed -i`, `sed 's/a/b/w f'`, `find -delete`/`-exec`,
+`rg --pre`, `sort -o`, `awk` with `>`/`|`/`system(`, `git -c`, `git diff
+--ext-diff`, …) and no redirection other than to `/dev/null` or another fd.
+`$(…)`, backticks, `$VAR` (other than `$HOME`, `$XDG_*`, `$TMPDIR` and `$PWD`
+at a word's start), an env prefix, `sh -c`, `xargs`, `eval`, `sudo` and the
+like make a command not read-only. It errs towards asking.
 
 A tool name may be a glob, so one rule covers a plugin's tools (an MCP server's,
 say): `tool: "mcp_*"` or `tool: ["mcp_{git,gh}_*", web_fetch]` (`*`, `?`, `[…]` and
@@ -303,6 +345,38 @@ once per bundle version to restart the session (`chi sessions stop ID`, then
 older than the bundle) denies every tool call, as for a rule that doesn't
 parse, until chi is updated or the bundle uninstalled.
 
+### Modes
+
+`guardrails.mode` (config.yml only) picks how much is asked:
+
+- `auto`, the default: the rules tagged `modes: [strict]` don't vote. Asks
+  are kept for what is hard to undo or reaches chi itself.
+- `strict`: every rule votes.
+
+```yaml
+guardrails:
+  mode: strict
+  rules:
+    - id: no-docker
+      tool: shell
+      command: '\bdocker\b'
+      modes: [strict]        # or auto, or [auto, strict] (the same as leaving it out)
+      verdict: ask
+```
+
+A rule without `modes:` votes in every mode, so a rule you add to config.yml
+always applies unless you tag it. The core checks (protected paths, hooks)
+vote in both modes. In the guardrails bundle, `git-rebase`,
+`write-outside-repo` and `git-outside-repo` are strict only; its small-model
+rules (`models: small`) are untagged, so they ask a small model in both modes.
+`/guardrails` shows the mode on its first lines and marks the rules this mode
+leaves out `(strict only)`.
+
+A rule in config.yml that uses a key this chi doesn't know yet (`modes:`,
+`touches:`, `rm:`, `skip_read_only:` before 0.20) doesn't parse, and a rule
+that doesn't parse denies every tool call (see Failing closed). Bundles say
+which chi they need (`requires_chi`), so their rules don't hit this.
+
 ## The guardrails bundle
 
 ```sh
@@ -310,18 +384,22 @@ chi bundle install guardrails    # chi bootstrap installs it, with the core prof
 ```
 
 installs a default rule set plus a short memory telling the model not to
-route around a deny. It asks before `git push`, `reset --hard`, `clean -f`,
-`branch -D`, `rebase`, `filter-branch`/`filter-repo`; `rm -rf` on `/`, `~`,
-`$HOME` or `..` paths; `curl … | sh` and `base64 -d … | sh`; writes outside the
-session's repo (`write-outside-repo`) and git that changes another checkout
-(`git-outside-repo`: `cd ../main && git commit`, `git -C ../main add .`; it
-offers once, this session and "rule in this repo", the last stored for later
-sessions in that repo); shell commands that name chi's config, hooks or guardrails or
-`.git/hooks`; and answering chi's questions around `chi answer`: `chi --attach`
-or `chi -p` with stdin from a pipe, a here-string or a file
-(`chi-answer-piped`), and `curl`/`wget` to a session's `/answer` route
-(`chi-answer-http`), both once or for the session. `chi answer` itself isn't
-asked about. It denies writes into `.git/hooks`. The rules are in
+route around a deny. In both modes it asks before `git push`, `reset --hard`,
+`clean -f`, `branch -D`, `filter-branch`/`filter-repo`; `rm -rf` on `/`, `~`,
+`$HOME` or `..` paths, unless every target is inside a tmp folder; `curl … |
+sh` and `base64 -d … | sh`; shell commands that name a path in chi's config,
+hooks, approvals or bundles or a `.git/hooks` (`shell-touches-chi`, `touches:
+chi_dirs`), unless they only read (`skip_read_only`); and answering chi's
+questions around `chi answer`: `chi --attach` or `chi -p` with stdin from a
+pipe, a here-string or a file (`chi-answer-piped`), and `curl`/`wget` to a
+session's `/answer` route (`chi-answer-http`), both once or for the session.
+`chi answer` itself isn't asked about. It denies writes into `.git/hooks`.
+
+In strict mode (`guardrails: { mode: strict }`) it also asks before `git
+rebase`, writes outside the session's repo (`write-outside-repo`) and git that
+changes another checkout (`git-outside-repo`: `cd ../main && git commit`, `git
+-C ../main add .`; it offers once, this session and "rule in this repo", the
+last stored for later sessions in that repo). The rules are in
 `lib/samagotchi/bundles/guardrails/guardrails/rules.yml`.
 
 Small models (`models: small`, see above) get two more asks, in

data/docs/memory.md

@@ -27,6 +27,10 @@ Each memory entry may have a companion file named `<name>.<model-key>.md` in the
 - **In the system prompt**: the identity memory and the preloaded memories (`--memory`, config `memories:`) get their overlays too, as `memory_read` gives them; after `/model` the rebuilt prompt carries the new model's.
 - **Dormancy**: Overlays are only active under the matching model key; other models see the base entry only.
 - **Invariant**: The base entry is the contract. Overlays only add model-specific guidance and never contradict the base protocol.
+- **In a bundle**: ship `<name>.<key>.md` next to `<name>.md` (ship the base too; an overlay with no base anywhere installs with a warning and loads only once the base exists; one whose base is only among your installed memories is taken as an overlay of it, with a warning naming it). The overlay gets no `index.md` line, so other models don't see it, and `chi bundle status` reads it `ok (model overlay)`; `chi bundle build FILES...` brings a named memory's overlays along.
+  - The key is the `model key` row of `chi self` under that model. It follows the provider's model id: OpenRouter's `deepseek/deepseek-v4.1-flash` keys as `deepseek-deepseek-v4-1-flash`, while a local server names the same model differently, so one model may need one overlay per provider.
+  - Key an alias by its **target**, not the alias: the alias's own key is read only as a fallback, when the alias was typed and the target has no overlay.
+  - The overlay is read in the scope its base is found in: a project memory with the same name shadows a system-scope bundle's base and overlay.
 
 
 At startup, the agent reads both scope indexes with blank-name memory reads

data/docs/plugins.md

@@ -524,6 +524,11 @@ ctx.card(id: id, title: "Build finished", body: "no warnings left")  # replaces
   its line; the web shows a bubble only when the command answers with
   text or fails.
 - `level:` is `:info` or `:warn` (the warning colour).
+- An `:info` card with no actions and a body of one short line (up to 160
+  characters) is a notice: the web shows it as a one-line row,
+  `▸ check-in: Nudged the model at 105 tool calls.`, that opens on a click,
+  like a resolved question. A warn card, one with actions and one with more
+  to read stay framed cards.
 - `id:` names an earlier card to replace. Without one a new id is made. The
   web updates the card in place; the terminal prints it again, marked
   `(updated)`. A card that waits for something (a model's answer) shows