samagotchi 0.6.0 → 0.8.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 220ee751308788beff6b5185350bafe29023706f2e63daf45c8bffab023e173e
-  data.tar.gz: 184c4bc6f92476939901813d8a9b20353a73bb64eb5725d3564ca302bf27559e
+  metadata.gz: 4db526cc3c79a4e5aa8061f124ff09e65e289415074fcb51c71c25ccee1ab0c9
+  data.tar.gz: c30c2094cb357df9fe4e5618956e0c1a559ea0a2765709605488d03c5febbb87
 SHA512:
-  metadata.gz: 7349948ddc41e8ccce71e742d4fc81f51f52290b56a2943efc690adc6e73e4c41fe37fa94dee41c50e20a0c910b3c66a55176955048bf3efa2003e9520c36642
-  data.tar.gz: a2059d2df83be31064bfb05f311c7088e777d2901fa00695f4f52208af3b21038471d7180ad26761b6f3f280a7b2f347f560ca39517e0bfcd52715247ba88477
+  metadata.gz: 2ad7fd71ecfee430c9dec6d9b51971b1e7fdc38c099c5f4a868ad07add50a21ac293f6c686e5f8aca9b0d3bd919ee49e1d79336ac1fe1ac4926d6ace2de24adb
+  data.tar.gz: 5856a9fe2fcb23b4802626ee918e7015cc718d74b4d17828265377a606cb76fdf80badb3f5d0e314c76bcd3ceb4629fc3f79ab735275fd102c1a2895b54b4f3d

data/CHANGELOG.md

@@ -8,6 +8,75 @@ and commands may change between minor versions. How releases are made:
 
 ## [Unreleased]
 
+## [0.8.0] - 2026-10-01
+
+### Added
+
+- Bundle profiles: `core` (loop-guard, check-in, guardrails) and `dev` (known-names, mcp, btw, skills,
+  source-links) install a set of the shipped bundles, `chi bundle install core`. A bundle you uninstall stays
+  out when the profile is installed or upgraded again, and `chi update` installs a bundle a new chi adds to a
+  profile you have. `chi bundle uninstall core` removes its bundles, `chi bundle list` and `status` show them.
+- `chi bootstrap` installs the system bundle and the `core` bundles, and on a terminal offers `dev`. Existing
+  installs get neither by themselves.
+
+### Changed
+
+- Dismissing a question (Esc, an empty answer, or no one to answer in `-p`) now tells the model not to do what it
+  asked about, or anything else that changes files or state, and to wait, instead of "go on with your best
+  judgement".
+- The system bundle tells chi to stop and ask on anything unexpected while following a skill (a failing check,
+  output that differs from a step, a warning the skill doesn't mention) instead of improvising a fix.
+- `chi bundle list` and `chi update`'s footer list the shipped bundles that aren't installed under their
+  profile (`core (…)`, `dev (…)`).
+- `chi bundle status` without a name lists a bundle whose `manifest.json` doesn't parse as unreadable instead of
+  failing.
+- The web stage view flashes a plugin's nudge ("↪ check-in nudged the model") and a hook's info notice in its
+  trail for about 4 s, as it already did a warn notice, so they are seen while the turn runs with the block
+  closed. chi's own "asking again" row does not flash (the status line says it).
+- A turn a hook stops (loop-guard, check-in's Stop) tells the model which hook stopped it and why.
+- With custom `context.status_thresholds`, the context guidance follows them (the top bucket reads critical)
+  instead of calling every bucket healthy.
+
+### Removed
+
+- `POST /api/sessions/:id/answer` no longer takes the unused aliases `question_id`, `selection`, `other` or
+  a nested `answer` object: only `id`, `selected` and `freeform`, as the web page sends them.
+- Sessions no longer write plain-text input for a worker from before 2026-09-23 (one that advertises no input
+  format) or refuse images to one that predates them (`images_unsupported`), and a worker no longer reads
+  `input/*.txt`: every chi since then writes and reads JSON input. A worker that old never exits by itself;
+  restart it (`chi sessions stop ID`, then send to it) before upgrading.
+- A worker from before the owner lock (2026-09-22) no longer counts as a session's owner through its pid file:
+  only the lock holder does, so a stale pid file whose pid was reused no longer makes a session look busy.
+
+### Fixed
+
+- A hook or plugin that fails while watching the stream is logged once a minute instead of on every batch
+  (it printed to stderr on every fire).
+- The web stage view's headline skips lines inside a code fence.
+- A question left open when a session's worker died no longer stays pending: the web and the hub stop showing
+  it (and the "needs you" badge) at once, and the next worker drops it.
+
+### Security
+
+- Session ids from outside (the worker's Bridge, the web routes, `chi send` / `note` / `sessions`,
+  `--resume` / `--attach`, the delegate and send_note tools) are checked in one place, so an id such as
+  `../x` can no longer reach a path outside the sessions folder. The Bridge answers 400, the web 404.
+
+Update with `chi update`. New bundles: `core` 0.1.0 and `dev` 0.1.0 (install with `chi bundle install core`,
+`chi bundle install dev`); existing installs don't get them by themselves.
+
+## [0.7.0] - 2026-09-30
+
+### Added
+
+- The desktop helper also sends to agent CLIs (claude, codex, …) in kitty windows: with `kitty.listen_on` copied
+  from kitty.conf (and `chi desktop upgrade`), the panel lists them in a "kitty" group next to the sessions; ⏎
+  pastes the quote, message and image paths and presses Enter, the new ⌥⏎ only pastes (so several screenshots
+  can pile up), and one send can go to chi sessions and kitty windows together. ⌥⏎ no longer inserts a newline
+  in the panel (⇧⏎ does). See docs/desktop.md "Agents in kitty".
+
+Update with `chi update`. No bundle versions changed.
+
 ## [0.6.0] - 2026-09-30
 
 ### Added
@@ -393,7 +462,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.6.0...HEAD
+[Unreleased]: https://github.com/dm1try/samagotchi/compare/v0.8.0...HEAD
+[0.8.0]: https://github.com/dm1try/samagotchi/compare/v0.7.0...v0.8.0
+[0.7.0]: https://github.com/dm1try/samagotchi/compare/v0.6.0...v0.7.0
 [0.6.0]: https://github.com/dm1try/samagotchi/compare/v0.5.1...v0.6.0
 [0.5.1]: https://github.com/dm1try/samagotchi/compare/v0.5.0...v0.5.1
 [0.5.0]: https://github.com/dm1try/samagotchi/compare/v0.4.0...v0.5.0

data/README.md

@@ -67,8 +67,11 @@ chi bootstrap                            # look on this machine's usual ports
 It finds out whether the server is llama.cpp or OpenAI-compatible, picks the
 model (or asks, when there are several), sends one test request and writes
 the config. With a config already there, it adds a `hosts:` entry and keeps
-the rest of the file. Edit the file later as in [Configure](#configure);
-`chi bootstrap --help` has the options.
+the rest of the file. Then it installs the `core` bundles (loop-guard,
+check-in, guardrails: the safety set for a small local model) and, on a
+terminal, offers `dev` (known-names, mcp, btw, skills, source-links). Edit the
+file later as in [Configure](#configure); `chi bootstrap --help` has the
+options.
 
 ## Configure
 
@@ -154,7 +157,8 @@ Command Line Tools. See [Desktop helper](docs/desktop.md).
 
 Every tool call the model makes can be allowed, denied, or put to you first.
 Rules come from `config.yml` (`guardrails:`), installed bundles and hooks;
-`chi bundle install guardrails` adds a default set (asks before `git push`,
+the `guardrails` bundle (in `core`, which `chi bootstrap` installs; else
+`chi bundle install guardrails`) adds a default set (asks before `git push`,
 history rewrites, wide `rm -rf`, `curl | sh`, writes outside the repo; denies
 writes to `.git/hooks`). You answer in the REPL, the attached TUI or the web:
 once, for the session, for the repo, or for the whole rule in the repo.

data/docs/architecture.md

@@ -92,7 +92,7 @@ bin/chi ─▶ TerminalUI ─▶ Engine#run_turn ─▶ KernelLoop ──┬─
 | Tools | `lib/samagotchi/tools/*` | Execute, read, edit, write, memory, task_*, web_fetch, plus runtime/output-guardrails. |
 | Background | `Samagotchi::SessionManager` | Builds `Engine` directly (no terminal rendering) for workers. |
 | Web | `Samagotchi::Web::App`, `Samagotchi::Web::Server`, `Samagotchi::Web::SessionHub` | Rack+WEBrick single-port `127.0.0.1:4567` (index.html + `/api/*` + SSE). The hub is chi web's projection of the session list, pushed to every tab over `GET /api/events`. |
-| Sessions | `Samagotchi::Session`, `SessionManager` | File `sessions/<uuid>.json` + sidecar `input/`/`output/`/`pid`; retention 14d/500, `updated_at desc`, lazy sweep. |
+| Sessions | `Samagotchi::Session`, `SessionManager` | File `sessions/<uuid>.json` + sidecar `input/`/`output/`; retention 14d/500, `updated_at desc`, lazy sweep. |
 
 ## Entry points
 
@@ -110,12 +110,12 @@ bin/chi ─▶ TerminalUI ─▶ Engine#run_turn ─▶ KernelLoop ──┬─
   `dismiss_question`). The worker runs in the session's `working_directory`, so `!cmd` and
   the tools don't depend on where the terminal attached from.
 - `bin/chi web` → builds `Web::Server` (Rack+WEBrick on `127.0.0.1:4567`, `--port`/`SAMAGOTCHI_WEB_PORT`, `--open`).
-- `bin/chi sessions {list,stop,delete,prune,clean}` (`SessionsCommand`; not the REPL's `SessionCommands`) → retention & ordering (`Session.prune`, `updated_at desc`, dry-run, test-only); `stop` is `SessionManager.stop_session(wait:)`, which waits for the worker to release `owner.lock`; `delete` (`SessionDeleteCommand`) is `SessionManager.delete_session(stop:)`, which the TUI's `/exit --delete` and the web's `DELETE /api/sessions/:id` use too.
+- `bin/chi sessions {list,stop,delete,prune,clean}` (`SessionsCommand`; not the REPL's `SessionCommands`) → retention & ordering (`SessionRetention`, `updated_at desc`, dry-run, test-only); `stop` is `SessionManager.stop_session(wait:)`, which waits for the worker to release `owner.lock`; `delete` (`SessionDeleteCommand`) is `SessionManager.delete_session(stop:)`, which the TUI's `/exit --delete` and the web's `DELETE /api/sessions/:id` use too.
 - `--prompt`, `--non-interactive`, and `SessionManager` workers build `Engine` directly.
 
 ## Session retention & ordering
 
-- **Files:** `~/.local/state/samagotchi/sessions/<uuid>.json` + `<uuid>/input|output|pid|owner.lock|bridge.json` (XDG-aware).
+- **Files:** `~/.local/state/samagotchi/sessions/<uuid>.json` + `<uuid>/input|output|owner.lock|bridge.json` (XDG-aware).
 - **Single owner:** the process running a session's Engine (worker or in-process TUI) holds a flock on `owner.lock` (`OwnerLock`); a second owner backs off, and the web answers 409 for a TUI-owned session.
 - **Status:** `status` is turn state (`idle`/`running`); liveness is the lock.
 - **Retention:** 14 days / 500 cap (env `SAMAGOTCHI_SESSION_RETENTION_DAYS`/`MAX_COUNT`, optional `KEEP_STATUS`), live-owner guard, only when `*.json` present; lazy sweep ≤1/24h from the session hub's full-probe tick (and on `GET /api/sessions`, which the page no longer calls) & `Dashboard#render_list`, manual via `bin/chi sessions prune --dry-run`.
@@ -134,7 +134,7 @@ agent logic and can be used without any terminal rendering; the UI is a thin lay
 | Model loops and adapters | `KernelLoop`, `LLM::ChatLoop`, `Samagotchi::Client`, `LLM::OpenAIChat`, `LLM::HTTP` | The model↔tool loops and the HTTP adapters they talk through (see "Model loops and adapters"). |
 | Bridge (SSE/HTTP) | `Samagotchi::Bridge`, `SessionManager` | The **single live client transport**: an SSE read stream + HTTP POST turn/cancel/answer surface that attaches to a worker's existing `Engine` via `Engine#subscribe`. Every session worker starts it (bound `127.0.0.1`, no auth, localhost-only). |
 | Web (Rack) | `Samagotchi::Web::App`, `SessionManager` | Single-port `127.0.0.1:4567` control plane via `rack`+`webrick` (serve `index.html` + `/api/*`; `/stream` proxies each session's Bridge). `bin/chi web` entrypoint. |
-| Sessions | `Samagotchi::Session`, `SessionManager` | File-based `~/.local/state/samagotchi/sessions/<uuid>.json` + sidecar `input/`/`output/`/`pid`; retention (14d/500) + ordering (`updated_at desc`). |
+| Sessions | `Samagotchi::Session`, `SessionManager` | File-based `~/.local/state/samagotchi/sessions/<uuid>.json` + sidecar `input/`/`output/`; retention (14d/500) + ordering (`updated_at desc`). |
 
 - `bin/chi` in REPL mode (see `LaunchMode` above) builds `TerminalUI`. `TerminalUI#run` is the single
   dispatch for the REPL, `-p`/`--prompt`, `--non-interactive`, and `--resume`: it

data/docs/cli.md

@@ -21,7 +21,7 @@
 - `chi desktop install|upgrade|uninstall|status` — the macOS "Send to chi" helper: a Service and a ⌃⌥⌘N hotkey that send text to live sessions as context notes (see [Desktop helper](desktop.md))
 - `chi self` — print version, source dir (checkout or installed gem), config/memory/session paths, model/host and bundles; `chi self --model` prints only the model a new session starts on (the desktop helper's hint)
 - `chi update [--dry-run] [--no-gem] [--no-bundles] [--no-desktop]` — update an installed chi: the gem, the system bundle, the shipped bundles you installed and the desktop helper, in one table (see [Updating](#updating))
-- `chi bundle install|upgrade|uninstall|status|diff|list|build` — manage memory bundles (see [Bundle hooks](hooks.md#bundle-hooks-unified-workflow-bundle)); `list` shows the installed ones and the ones shipped with chi, which `install <name>` installs (see [Guardrails](guardrails.md), [Plugins](plugins.md#the-btw-bundle), [the mcp bundle](plugins.md#the-mcp-bundle) [the loop-guard bundle](plugins.md#the-loop-guard-bundle), [the check-in bundle](plugins.md#the-check-in-bundle) and [the skills bundle](plugins.md#the-skills-bundle))
+- `chi bundle install|upgrade|uninstall|status|diff|list|build` — manage memory bundles (see [Bundle hooks](hooks.md#bundle-hooks-unified-workflow-bundle)); `list` shows the installed ones and the ones shipped with chi, which `install <name>` installs; `core` and `dev` are profiles that install a set of them (see [Bundle profiles](memory.md#bundle-profiles-core-and-dev),  [Guardrails](guardrails.md), [Plugins](plugins.md#the-btw-bundle), [the mcp bundle](plugins.md#the-mcp-bundle) [the loop-guard bundle](plugins.md#the-loop-guard-bundle), [the check-in bundle](plugins.md#the-check-in-bundle) and [the skills bundle](plugins.md#the-skills-bundle))
 
 ### First setup
 
@@ -58,6 +58,13 @@ chi bootstrap                            # try localhost 8080, 11434, 1234, 8000
   none. A server already in the file writes nothing; a file in YAML flow style
   or with anchors gets the lines printed to paste instead. `--dry-run` shows
   what it would write.
+- **The bundles.** Unless writing the config failed, it installs the system
+  bundle and the `core` profile (loop-guard, check-in, guardrails), one line
+  each; on a terminal it then asks `Also install dev (known-names, mcp, btw,
+  skills, source-links)? [y/N]`. Run again, it installs nothing new: a bundle
+  you uninstalled stays out ([Bundle profiles](memory.md#bundle-profiles-core-and-dev)).
+  A bundle that fails to install makes the exit 1. `--dry-run` says what it
+  would install.
 
 ### Updating
 
@@ -69,10 +76,11 @@ chi (gem)      0.2.0  0.3.0  updated
 system bundle  0.2.0  0.3.0  updated (kept your edits in identity.md: chi bundle diff samagotchi-system identity.md)
 btw            0.1.1         up to date
 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
-Also shipped, not installed: check-in, skills, source-links (chi bundle install NAME)
+Also shipped, not installed: dev (mcp, skills, source-links) (chi bundle install NAME)
 done
 ```
 
@@ -97,6 +105,10 @@ done
   A bundle of the same name from elsewhere (a zip, git) is skipped ("not from
   chi"), a newer installed one is left, one whose new version needs a newer
   chi is skipped, and bundles you didn't install stay uninstalled.
+- **Profiles** (`core`, `dev`): an installed one installs the bundles a new
+  chi added to it (`updated (+ name)`), even at the same version, and retries
+  one that failed before; one you uninstalled stays out. See [Bundle
+  profiles](memory.md#bundle-profiles-core-and-dev).
 - **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).
@@ -206,7 +218,8 @@ of UIs at once: the Web UI and attached terminals (`chi`, `--resume`,
 `--attach`). They all see the same turns as they happen, and any of them can send
 a prompt, also while a turn runs (it merges into that turn as steering). The
 first answer to an `ask_user_question` wins; the other UIs close their widget.
-An empty answer dismisses the question in every UI.
+An empty answer dismisses the question in every UI. The model is then told
+not to go ahead with what it asked about, or change anything else, and to wait.
 
 In an attached terminal:
 
@@ -445,7 +458,9 @@ card, so it stays on screen without scrolling: a status row (what it is
 doing, the step, the elapsed time), your prompt on one line, the newest
 narration sentence (else the newest thinking one, in italics; click it for
 the step's reasoning), the running tool with what it does, and the last
-three calls. A card that needs you (a question, an approval, check-in)
+three calls. A plugin's or hook's notice and a plugin's nudge ("check-in
+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. The chip under it, `N steps · M tool calls` with one
 tick per call, opens the turn view's block in place (newest step first
 while it runs; a tick opens its step). `▾` folds the stage to its status

data/docs/configuration.md

@@ -687,6 +687,23 @@ hosts:
 `models:` wins over `hosts:`. On a native host, `vision: true` skips only the
 modalities check: without a media marker the prompt can't carry an image.
 
+## Desktop helper: agents in kitty
+
+The desktop helper (`chi desktop`) can also paste into agent CLIs (claude,
+codex, …) running in [kitty](https://sw.kovidgoyal.net/kitty/) windows. It
+lists them only with `kitty.listen_on` set: copy the value of `listen_on` from
+your `kitty.conf` as it is (kitty must also have `allow_remote_control` on).
+
+```yaml
+kitty:
+  listen_on: unix:/tmp/kitty.${KITTY_PID}   # as in kitty.conf; unset = no kitty targets
+  binary: /Applications/kitty.app/Contents/MacOS/kitty   # the default
+  agents: [claude, codex]   # the programs listed; "*" = every window
+```
+
+The helper reads these from its launch file: after editing them run
+`chi desktop upgrade` (or `chi update`). See [Desktop helper](desktop.md#agents-in-kitty).
+
 ## Project specific description
 
 If an AGENT.md file is present in the project root, samagotchi injects its
@@ -756,6 +773,9 @@ described in their own sections.
 | `update.gem` | `true` | | `false`: `chi update` never installs a newer gem (`--no-gem` for one run). See [CLI: Updating](cli.md#updating). |
 | `update.bundles` | `true` | | `false`: `chi update` leaves the shipped bundles to `chi bundle upgrade` (`--no-bundles`). |
 | `update.desktop` | `true` | | `false`: `chi update` leaves the desktop helper alone (`--no-desktop`). |
+| `kitty.listen_on` | none | | The desktop helper's kitty socket, copied from `kitty.conf`; unset = no kitty targets. See "Desktop helper: agents in kitty". |
+| `kitty.binary` | `/Applications/kitty.app/Contents/MacOS/kitty` | | The kitty the helper runs `kitty @` with. |
+| `kitty.agents` | `claude\|codex\|gemini\|aider\|opencode\|cursor-agent\|amp\|goose` | | Foreground programs whose kitty windows the helper lists, `\|`-separated (a YAML list works too); `*` lists every window. |
 | `read.truncate_at_bytes` | `65536` | yes | A `read` result larger than this is cut to a preview. |
 | `read.preview_bytes` | `12288` | yes | Size of that preview. |
 | `read.hard_max_bytes` | `2097152` | yes | Largest file `read` opens. |

data/docs/desktop.md

@@ -20,6 +20,8 @@ sessions. Keys:
 - **⏎** sends a message: `chi send -m <the line>` with the text as quoted context above it. With the line empty,
   the text is the message.
 - **⌘⏎** sends a note: `chi note`, the line (if any) then the text.
+- **⌥⏎** pastes into an agent in a kitty window without pressing Enter (see [Agents in kitty](#agents-in-kitty));
+  it is not a newline.
 - **⇧⏎** is a newline, in either field. Esc closes.
 
 The list shows the sessions a worker runs now, then, under a "recent" divider, up to 3 stopped ones (dimmed, with
@@ -64,6 +66,53 @@ thumbnails sit under the message line, 48 px high, the file name as a tooltip; h
   the panel closes; files from Finder are sent as they are, never touched. A send with images may take up to 30 s
   (converting, a worker starting) before the panel gives up.
 
+## Agents in kitty
+
+The panel can also send to agent CLIs (claude, codex, gemini, aider, …) running in
+[kitty](https://sw.kovidgoyal.net/kitty/) windows, next to chi sessions. kitty only, through its remote control;
+off until you set it up:
+
+1. In `kitty.conf`, remote control on and a socket: `allow_remote_control yes` and a `listen_on unix:…` line.
+2. Copy that `listen_on` value as it is into chi's config.yml:
+
+   ```yaml
+   kitty:
+     listen_on: unix:/tmp/kitty.${KITTY_PID}
+   ```
+
+   `kitty.agents` picks the programs listed (default `claude|codex|gemini|aider|opencode|cursor-agent|amp|goose`, a
+   YAML list works too; `"*"` lists every window, shells too), `kitty.binary` the kitty to run (default
+   `/Applications/kitty.app/Contents/MacOS/kitty`). See [Configuration](configuration.md#desktop-helper-agents-in-kitty).
+3. Run `chi desktop upgrade` (or `chi update`): the helper reads these from its launch file, so **after every edit of
+   `kitty:`** run it again. No rebuild when only the settings changed.
+
+The helper finds the sockets itself: kitty adds `-<pid>` to a `listen_on` path from kitty.conf (and fills in
+`{kitty_pid}`), `~` and variables the helper knows are expanded, others (`${KITTY_PID}`) stay as written, as kitty
+keeps them. Several kitty instances all count. Only `unix:` sockets work.
+
+The panel lists the windows whose foreground program is one of the agents under a **kitty** divider, between live
+and recent sessions: "claude · <its title>", the folder below, a terminal icon, and a ⌘ number like the sessions.
+With the settings on but no agent running, one dim line says "no agents in kitty". A window counts when a foreground
+process's program is an agent, also as the script of `node …/codex` (that match is untested for codex and gemini).
+
+- **⏎** pastes into every chosen window and presses Enter: the text as a `> ` quote, a blank line, your message, then
+  one image path per line. Chosen together with chi sessions, each gets the message and the panel shows one line
+  ("Sent. · sent to claude · samagotchi").
+- **⌥⏎** only pastes (no Enter), and only when every chosen target is a kitty window: build up several screenshots,
+  each with its own line, then press Enter in kitty. The footer shows **Paste ⌥⏎** instead of Note then.
+- **⌘⏎** with a kitty window chosen beeps: "Notes are for chi sessions". ⌥⏎ with a chi session: "Paste only is
+  for kitty windows".
+- **Images:** a screenshot or other image data is copied to `$TMPDIR/chi-helper-sent/<uuid>.png` (or `.tiff`) and
+  its path pasted; the agent reads it from there (claude attaches it as `[Image #1]`). These files are deleted a week
+  later, at the helper's next start. Finder files are pasted with their own path, `'…'`-quoted when they hold spaces.
+- The paste arrives as one bracketed paste, so the agent takes newlines as text (claude shows long ones as
+  `[Pasted text]`). With `agents: "*"` beware of a program that doesn't turn bracketed paste on: the newlines would
+  act as Enter.
+- No delivery confirmation: before pasting, the helper checks the window is still there ("window closed" if not);
+  it can't know whether the agent read it. The 16 KB cap is chi's; a kitty window takes more.
+- Focus goes back to the app you came from, as for sessions. The last choice (kitty windows too) is preselected
+  while listed; ⌘ numbers shift as windows come and go.
+
 ## Install
 
 ```sh

data/docs/guardrails.md

@@ -146,7 +146,7 @@ without it.
 ## The guardrails bundle
 
 ```sh
-chi bundle install guardrails
+chi bundle install guardrails    # chi bootstrap installs it, with the core profile
 ```
 
 installs a default rule set plus a short memory telling the model not to
@@ -164,7 +164,7 @@ denies every call until the bundle is reinstalled.
 ## The known-names bundle
 
 ```sh
-chi bundle install known-names
+chi bundle install known-names    # or chi bundle install dev
 ```
 
 installs one `before_tool_call` hook and a short memory. A local model that

data/docs/hooks.md

@@ -416,7 +416,7 @@ Notes:
 - Ordering: bundle hooks fire by `(priority, bundle_name, hook_name)` (lower priority first), then plain `config.yml` hooks in registration order.
 - Settings: a hook class with `initialize(settings = {})` gets the bundle's section of `config.yml` `bundles:` (see [Settings](#settings)).
 - A bundle can also ship a `plugin.rb` whose `chi.on(event)` blocks are bundle hooks too, next to commands and tools; see [Plugins](plugins.md).
-- Shipped bundles: `chi bundle install guardrails` (rules, see [Guardrails](guardrails.md#the-guardrails-bundle)) and `chi bundle install known-names` (a hook, see [Guardrails](guardrails.md#the-known-names-bundle)), `chi bundle install source-links` (a hook: announces source refs, see [The source-links bundle](#the-source-links-bundle)), `chi bundle install btw` (a plugin: `/btw`, see [Plugins](plugins.md#the-btw-bundle)), `chi bundle install mcp` (a plugin: tools from MCP servers, see [Plugins](plugins.md#the-mcp-bundle)) `chi bundle install loop-guard` (a plugin: breaks tool-call loops, see [Plugins](plugins.md#the-loop-guard-bundle)), `chi bundle install check-in` (a plugin: checks on a long turn, see [Plugins](plugins.md#the-check-in-bundle)) and `chi bundle install skills` (a plugin: `/skill`, versions of skills, see [Plugins](plugins.md#the-skills-bundle)).
+- Shipped bundles (each in a profile: `core` or `dev`, see [Bundle profiles](memory.md#bundle-profiles-core-and-dev)): `chi bundle install guardrails` (rules, see [Guardrails](guardrails.md#the-guardrails-bundle)) and `chi bundle install known-names` (a hook, see [Guardrails](guardrails.md#the-known-names-bundle)), `chi bundle install source-links` (a hook: announces source refs, see [The source-links bundle](#the-source-links-bundle)), `chi bundle install btw` (a plugin: `/btw`, see [Plugins](plugins.md#the-btw-bundle)), `chi bundle install mcp` (a plugin: tools from MCP servers, see [Plugins](plugins.md#the-mcp-bundle)) `chi bundle install loop-guard` (a plugin: breaks tool-call loops, see [Plugins](plugins.md#the-loop-guard-bundle)), `chi bundle install check-in` (a plugin: checks on a long turn, see [Plugins](plugins.md#the-check-in-bundle)) and `chi bundle install skills` (a plugin: `/skill`, versions of skills, see [Plugins](plugins.md#the-skills-bundle)).
 - Installing a bundle executes its hook code at `Engine` startup. Only install bundles you trust, as you would a gem. Hooks are **not** executed at install time (copy-only); they are `module_eval`'d at `Engine.new` inside per-bundle `Samagotchi::Bundles::<name>` namespaces (no top-level `require` collisions). Keep hook files side-effect-free at load time; do work in `#call` — top-level side effects (require, IO, `at_exit`, global assignment) run once per `Engine.new` (class redefinition is idempotent).
 
 Lifecycle:
@@ -428,7 +428,7 @@ Lifecycle:
 ## The source-links bundle
 
 ```sh
-chi bundle install source-links
+chi bundle install source-links    # or chi bundle install dev
 ```
 
 installs one `after_turn` hook and a short memory. When the model's answer

data/docs/internals/context-telemetry.md

@@ -25,7 +25,9 @@ Emission behavior:
   synthetic char-based estimate (`src=estimate`). The guidance text is dynamic
   and escalates with the bucket: healthy → proceed normally; moderate → prefer
   targeted/range reads; elevated → be concise, avoid large re-reads; critical →
-  summarize aggressively and delegate broad work to subagents.
+  summarize aggressively and delegate broad work to subagents. With custom
+  `context.status_thresholds` the top bucket reads critical, the one below it
+  elevated, the next moderate, and the first bucket (and the rest below) healthy.
 
 Configuration:
 

data/docs/memory.md

@@ -47,7 +47,9 @@ chi is told about skills by the system bundle (`identity.md`, every turn, and
   one ("I like how we did that") it may ask first.
 - **Following.** The skill's index line (the `description:` of its
   `memory_write`, "Release a new version of this repo: …") is in every
-  prompt, so next time chi reads the skill and follows it.
+  prompt, so next time chi reads the skill and follows it. When something
+  looks unexpected on the way (a failing check, a warning the skill doesn't
+  mention), chi stops, says what it saw and asks how to go on.
 - **Updating.** When a step turned out different (a renamed script, an extra
   step), chi fixes the skill in the same turn: those steps changed, the rest
   kept, a dated Changelog line added. No confirmation.
@@ -74,6 +76,51 @@ skills`, [docs/plugins.md](plugins.md#the-skills-bundle)) adds `/skill save`,
 one-line diff after each update, and nudges a model that skips a failing
 step instead of fixing the skill.
 
+## Bundle profiles: core and dev
+
+Every bundle chi ships (the system bundle aside) belongs to one of two
+profiles, meta bundles that install a set of them:
+
+| profile | bundles |
+|---|---|
+| `core` | loop-guard, check-in, guardrails: the recommended safety set |
+| `dev` | known-names, mcp, btw, skills, source-links |
+
+`chi bootstrap` installs `core` and, on a terminal, offers `dev`. An existing
+install gets neither by itself: `chi bundle install core` (or `dev`).
+
+A profile's `manifest.yml` has `includes:` (bundle names) and nothing else to
+install; its dir holds only that file. What installing it does follows one
+rule:
+
+    installed now = the profile's bundles − the ones it recorded − the ones installed
+
+- **First install:** each bundle that isn't installed is installed (from the
+  bundles chi ships, never a same-named dir in the cwd); one you installed by
+  hand is recorded without reinstalling it.
+- **Again, or `chi bundle upgrade core`:** only a bundle new to the profile
+  is installed. One you uninstalled (`chi bundle uninstall check-in`) was
+  recorded, so it stays out; re-running `chi bootstrap` changes nothing.
+- **A new chi adds a bundle to a profile:** `chi update` installs just that
+  one ("core … updated (+ name)"). A bundle dropped from a profile stays
+  installed.
+- **A bundle this chi is too old for** (its `requires_chi`) is skipped with a
+  note, and one that fails is reported (exit 1); neither is recorded, so the
+  next `chi update` or install tries again.
+- The profile never pins its bundles' versions: each one upgrades on its own,
+  as before (`chi update`, `chi bundle upgrade NAME`).
+- Only the profiles chi ships expand: `includes:` in a bundle from anywhere
+  else is ignored.
+
+`chi bundle uninstall core` uninstalls each bundle it recorded that is still
+installed (one you installed by hand before core too), then core. A bundle
+with an edited memory file is kept and named (`--force` removes it), the
+rest go, and core stays until it is gone (exit 1). `--scope project` is
+refused for a profile. `chi bundle list` shows an installed profile's
+bundles (`includes=`) and the ones you left out (`left out=`), a profile not
+installed with its bundles on its line, and `chi bundle status core` lists
+each one.
+
 ## Bundles that need outside commands
 
 A bundle's memory can rely on a command chi doesn't ship, such as a GitHub

data/docs/plugins.md

@@ -596,7 +596,7 @@ ctx.sessions.read(id)  # => {id:, title:, status:, parent_id:, running:, message
 
 ## The btw bundle
 
-`chi bundle install btw` installs the bundle shipped with chi. It is written
+`chi bundle install btw` (or the `dev` profile) installs the bundle shipped with chi. It is written
 only against this API (`lib/samagotchi/bundles/btw/plugin.rb`).
 
 - `/btw <question>` asks the session's model a side question about the
@@ -621,7 +621,7 @@ only against this API (`lib/samagotchi/bundles/btw/plugin.rb`).
 
 ## The mcp bundle
 
-`chi bundle install mcp` installs the bundle shipped with chi. It is written
+`chi bundle install mcp` (or the `dev` profile) installs the bundle shipped with chi. It is written
 only against this API (`lib/samagotchi/bundles/mcp/plugin.rb`), and adds
 tools from [MCP](https://modelcontextprotocol.io) servers. It has no memory
 file, so it costs the prompt nothing but its tools. Stdio servers only, for
@@ -733,7 +733,8 @@ bundles:
 
 ## The loop-guard bundle
 
-`chi bundle install loop-guard` installs the bundle shipped with chi. It is
+`chi bundle install loop-guard` installs the bundle shipped with chi (`chi
+bootstrap` installs it with the `core` profile). It is
 written only against this API (`lib/samagotchi/bundles/loop-guard/plugin.rb`),
 with `chi.on` hooks, and has no memory file. It guards two kinds of loop:
 repeated tool calls (below) and [thinking that repeats
@@ -853,7 +854,8 @@ Not caught (yet):
 
 ## The check-in bundle
 
-`chi bundle install check-in` installs the bundle shipped with chi. It is
+`chi bundle install check-in` installs the bundle shipped with chi (`chi
+bootstrap` installs it with the `core` profile). It is
 written only against this API (`lib/samagotchi/bundles/check-in/plugin.rb`):
 `chi.on` hooks, `ctx.card`, `ctx.steer`, `ctx.stop_turn` and one anytime
 command. It has no memory file.
@@ -911,7 +913,7 @@ with a line and carry on unchanged.
 
 ## The skills bundle
 
-`chi bundle install skills` installs the bundle shipped with chi
+`chi bundle install skills` (or the `dev` profile) installs the bundle shipped with chi
 (`lib/samagotchi/bundles/skills/plugin.rb`): one anytime command, `chi.on`
 hooks, `ctx.sessions.send`, `ctx.notify` and `event[:steer]`. It has no memory
 file; skills themselves work without it ([docs/memory.md](memory.md#skills)).

data/docs/releasing.md

@@ -13,13 +13,17 @@ can run the whole release; the user approves the notes before the tag and the
   and `rake release:check` enforce it). The system bundle upgrades itself when
   chi starts.
 - **Every other shipped bundle** (btw, check-in, guardrails, known-names,
-  loop-guard, mcp, skills, source-links) has its own semver in its
+  loop-guard, mcp, skills, source-links, and the profiles core and dev) has its own semver in its
   `manifest.yml` and, when it needs a newer chi, a `requires_chi:` line. They never upgrade by themselves: users run
   `chi update` (all of them, with the gem) or `chi bundle upgrade NAME`. So:
   - a change to a bundle's files bumps that bundle's `version:`
     (`rake bundles:check` fails otherwise, once there's a tag to compare with);
   - a bundle that uses something new in chi raises its `requires_chi` in the
     same change; `release:bump` never touches `requires_chi`;
+  - a new shipped bundle joins a profile (`includes:` in `core` or `dev`; a
+    spec checks every bundle is in exactly one), and that profile's version
+    goes up: `chi update` then installs only the new bundle for those who
+    have the profile;
   - the release notes say "run `chi update`" and name the bundles whose
     version moved (what changed in each), not per-bundle upgrade steps.
 - Pre-1.0: config and commands may change in a minor version (0.2 → 0.3); a

data/docs/sessions.md

@@ -1,6 +1,6 @@
 # Sessions
 
-Sessions are plain files — no DB. Each session is `~/.local/state/samagotchi/sessions/<uuid>.json` (XDG-aware via `XDG_STATE_HOME`) plus a sidecar dir `<uuid>/` with `input/`/`notes/`/`output/`/`pid`/`bridge.json` (`Session.session_dir`). Besides the messages and turn state, the JSON keeps `used_memory_names` (what the session read), `preloaded_memory_names` (`--memory`) and `muted_memory_names` (`--mute`), the last two written before the worker starts so a respawn builds the same prompt, and `parent_id`, the session that delegated this one (see *Delegating*; `null` otherwise); files from before those keys read as empty lists and no parent.
+Sessions are plain files — no DB. Each session is `~/.local/state/samagotchi/sessions/<uuid>.json` (XDG-aware via `XDG_STATE_HOME`) plus a sidecar dir `<uuid>/` with `input/`/`notes/`/`output/`/`owner.lock`/`bridge.json` (`Session.session_dir`). Besides the messages and turn state, the JSON keeps `used_memory_names` (what the session read), `preloaded_memory_names` (`--memory`) and `muted_memory_names` (`--mute`), the last two written before the worker starts so a respawn builds the same prompt, and `parent_id`, the session that delegated this one (see *Delegating*; `null` otherwise); files from before those keys read as empty lists and no parent.
 
 **Retention (file-based, opt-out via env):**
 
@@ -15,7 +15,7 @@ A session is deleted if **expired by age OR overflow by count** (unless `keep_st
 
 **Worker idle exit:** a background worker (plain `chi`, Web UI sessions) exits after `SAMAGOTCHI_SESSION_IDLE_EXIT_MINUTES` (`session.idle_exit_minutes`, default `30`, `0`=never) with no turn running or queued, no client on its stream (an open web tab or attached terminal keeps it), no reminder registered and no continue offer waiting for an answer. It removes `bridge.json` and frees `owner.lock`; the next prompt or `--attach` wakes a new worker (`WorkerIdleExit`, `SessionManager.run_session_loop`). A client can also ask the worker to exit right away (Bridge `POST /session/:id/exit`; `/exit` in an attached terminal does, `/detach` doesn't): the same rules apply without the timeout (even with `0`), and the asker's own stream doesn't count. The reply names what keeps it up. The session's status stays as it was, not `stopped`.
 
-**Empty sessions:** a session nothing happened in is deleted when it is left, so `chi` → `/exit` leaves no trace. Empty means: no messages, no turn tried (a failed turn leaves a `last_prompt` and keeps it), no memory used, no pending question, nothing in `input/`, `notes/` or `images/`, nothing in its dir beyond the worker's skeleton, mode `assist`, and the default model. A session on another model (`/model`, `--model`) counts as prepared and stays (`SessionManager.empty_session?`). The worker checks as it idle-exits or leaves on a client's request and deletes it once its lock is free, checking again first. The attached `/exit` then says `Detached; the session was empty, so it is discarded.` The REPL (`--no-shared`) does the same at `/exit` or Ctrl-D. The retention sweep catches those killed first: empty sessions over an hour old with no live owner, whatever `DAYS`/`MAX`, and skeleton-only dirs with no `*.json`. `session.keep_empty: true` (env `SAMAGOTCHI_SESSION_KEEP_EMPTY`) turns all of it off.
+**Empty sessions:** a session nothing happened in is deleted when it is left, so `chi` → `/exit` leaves no trace. Empty means: no messages, no turn tried (a failed turn leaves a `last_prompt` and keeps it), no memory used, no pending question, nothing in `input/`, `notes/` or `images/`, nothing in its dir beyond the worker's skeleton, mode `assist`, and the default model. A session on another model (`/model`, `--model`) counts as prepared and stays (`SessionManager.discardable?`). The worker checks as it idle-exits or leaves on a client's request and deletes it once its lock is free, checking again first. The attached `/exit` then says `Detached; the session was empty, so it is discarded.` The REPL (`--no-shared`) does the same at `/exit` or Ctrl-D. The retention sweep catches those killed first: empty sessions over an hour old with no live owner, whatever `DAYS`/`MAX`, and skeleton-only dirs with no `*.json`. `session.keep_empty: true` (env `SAMAGOTCHI_SESSION_KEEP_EMPTY`) turns all of it off.
 
 **Attached by default:** plain `chi` and `chi --resume ID` run their session in a background worker and attach to it (`session.shared`, default `true`; env `SAMAGOTCHI_SESSION_SHARED`). The worker runs in the session's `working_directory`, so `!commands` and tools see the directory the session was started in. `session.shared: false` keeps the in-process REPL, `--no-shared` does for one run; a session the REPL has open can't be attached ("close it there first"). See [CLI: Sharing a session](cli.md#sharing-a-session).
 

data/lib/samagotchi/archive_store.rb

@@ -3,6 +3,7 @@
 require "json"
 require "fileutils"
 require "time"
+require_relative "atomic_file"
 
 require_relative "session"
 
@@ -76,13 +77,12 @@ module Samagotchi
     end
 
     def self.write(session_id, record, state_dir:)
-      return false unless File.exist?(File.join(state_dir, "#{session_id}#{Session::FILE_EXT}"))
+      return false unless File.exist?(Session.session_file(session_id, state_dir: state_dir))
 
       dir = Session.session_dir(session_id, state_dir: state_dir)
       FileUtils.mkdir_p(dir)
       path = File.join(dir, FILE)
-      File.write("#{path}.tmp", JSON.generate(record))
-      File.rename("#{path}.tmp", path)
+      AtomicFile.write(path, JSON.generate(record))
       true
     end
     private_class_method :write

data/lib/samagotchi/atomic_file.rb

@@ -0,0 +1,34 @@
+# frozen_string_literal: true
+
+require "fileutils"
+require "securerandom"
+
+module Samagotchi
+  # Replace a file whole: the content goes to a temporary file next to it
+  # (<path>.<pid>.<random>.tmp, unique per process and call, so a worker and
+  # a CLI writing the same file never share one), which is then renamed over
+  # +path+. A reader sees the old file or the new one, never half of one, and
+  # two writers racing leave one of the two contents. The temporary name ends
+  # in .tmp, so globs for *.json or *.md never list it. On failure it is
+  # removed and the error raised; +path+ is left as it was.
+  module AtomicFile
+    module_function
+
+    # @param path [String] the file to replace (its folder must exist)
+    # @param content [String] written as-is, byte for byte
+    # @param perm [Integer, nil] the new file's mode; nil = a fresh file's
+    #   (0666 less the umask), like File.write
+    # @return [String] +path+
+    def write(path, content, perm: nil)
+      tmp = "#{path}.#{Process.pid}.#{SecureRandom.hex(4)}.tmp"
+      File.open(tmp, File::WRONLY | File::CREAT | File::EXCL | File::BINARY, perm || 0o666) do |io|
+        io.write(content)
+      end
+      File.chmod(perm, tmp) if perm
+      File.rename(tmp, path)
+      path
+    ensure
+      FileUtils.rm_f(tmp) if tmp && File.exist?(tmp)
+    end
+  end
+end

data/lib/samagotchi/bootstrap/bundles.rb

@@ -0,0 +1,37 @@
+# frozen_string_literal: true
+
+require_relative "../memory_bundle/manifest"
+require_relative "../memory_bundle/profile"
+require_relative "../memory_bundle/source"
+require_relative "../memory_bundle/system_bundle"
+
+module Samagotchi
+  module Bootstrap
+    # chi bootstrap's bundles step: the system bundle and the shipped
+    # profiles, into the config dir the process ENV names (Provenance and
+    # the Installer resolve their paths from it, not from bootstrap's env:).
+    # A seam: in-process specs pass their own.
+    class Bundles
+      def initialize(shipped_dir: MemoryBundle::SourceNormalizer::SHIPPED_DIR)
+        @shipped_dir = shipped_dir
+      end
+
+      # @return [MemoryBundle::SystemBundle::Result]
+      def sync_system(dry_run: false) = MemoryBundle::SystemBundle.sync(dry_run: dry_run)
+
+      # @return [MemoryBundle::Profile::InstallResult]
+      def install(profile, dry_run: false)
+        MemoryBundle::Profile.install(dir(profile), shipped_dir: @shipped_dir, dry_run: dry_run)
+      end
+
+      # The members installing +profile+ would install now.
+      def to_install(profile)
+        MemoryBundle::Profile.to_install(MemoryBundle::Manifest.read(dir: dir(profile)))
+      end
+
+      private
+
+      def dir(profile) = File.join(@shipped_dir, profile)
+    end
+  end
+end