samagotchi 0.90.0 → 0.92.0

data/docs/internals/engine.md

@@ -97,11 +97,14 @@ StandardError in run_turn:
 Interrupt (Ctrl-C; the REPL only: a worker traps INT, see the signal row below):
   → if turn.ended: re-raised only
   → turn.controller.cancel!(:ctrl_c)
-  → end_turn(turn, "canceled"): ctrl_c_messages keeps turn.messages with TurnNote.cancelled(:ctrl_c)
-     # Both loops work on their own copy of the conversation, and Interrupt is not a
-     # StandardError, so nothing attaches the loop's conversation: only what the Engine
-     # built before the loop (system head, history, reminders, the prompt) survives.
-     # Tasks the turn started are missed in the cancel note for the same reason.
+  → end_turn(turn, "canceled"): ctrl_c_messages keeps the loop's conversation, else turn.messages
+     # (it came before the loop), with TurnNote.cancelled(:ctrl_c) at the tail.
+     # Both loops attach their conversation to the Interrupt as to a failure
+     # (LLM::FailedTurn.attach), so the turn's finished iterations stay, as after a Stop,
+     # and the cancel note names the tasks the turn started. One mid-tool is answered:
+     # ToolResponse.run_batch gives every call left an interrupted result (the native
+     # loop's batch entry joins them after the finished ones), so no call is kept without
+     # its result. A half-streamed reply is not kept (a Stop keeps it, [interrupted]).
   → :turn_canceled {cancellation_reason: :ctrl_c, duration_ms}
   → re-raised (the caller decides whether to exit)
 
@@ -191,7 +194,8 @@ KernelLoop#run(messages, max_iterations:, on_stream_event:, cancel_controller:,
 ```
 
 `turn.conversation` is the loop's own copy, not the Engine's `turn.messages`. A failure attaches it to the error
-(`LLM::FailedTurn.attach`), so `Engine#failed_messages` can keep it; a Ctrl-C does not (see Error paths).
+(`LLM::FailedTurn.attach`), so `Engine#failed_messages` can keep it; an Interrupt (Ctrl-C) too, for
+`Engine#ctrl_c_messages` (see Error paths).
 
 ### ChatLoop (the chat APIs)
 
@@ -468,7 +472,9 @@ TUI. Errors in the sink or an observer are caught; they never break the turn.
 
 `Engine#announce` puts an event that belongs to no turn (`ANNOUNCEABLE_EVENTS`: `turn_enqueued`, `turn_dequeued`
 (a queued message taken back before it ran, `{enqueued_id, client_id}`: the remover's), `card`,
-`hook_notice`, `guardrail_warning`, `plugin_init_started`, and more) to the observers only.
+`hook_notice`, `guardrail_warning`, `plugin_init_started`, and more) to the observers only. `:side_usage`
+(`{kind, side}`: a side request's usage, the recap's, `/btw`'s or `ask_model`'s, and the session's side sums) goes
+to the observers the same way from `Engine#note_side_usage` (any thread), without being announceable.
 
 Turn events (the main ones; `Events` in `events.rb` keeps the shared sets):
 
@@ -491,6 +497,8 @@ Turn events (the main ones; `Events` in `events.rb` keeps the shared sets):
 | `:tool_dispatch_started` / `:tool_dispatch_completed` | around a batch | `{iteration, call_count}` |
 | `:tool_call_started` | before a call runs | Engine event includes `call` (see ToolRunner); the Bridge's SSE frame omits it |
 | `:tool_call_completed` | after a call ran | see ToolRunner |
+| `:question_requested` / `:question_answered` / `:question_cancelled` | `QuestionDesk`: a question is asked (an approval, `ask_user_question`, a hook's or plugin's `ask_user`, the step-limit Continue), answered, or withdrawn | `{pending_question}` / `{id, answer}` / `{id, reason}` |
+| `:plugin_init_wait` | a turn waits for plugin init tasks that provide tools (`PluginTasks`) | `{tasks: [{bundle, id, label}]}` |
 | `:used_memories_updated` | a memory was read, and after the loop | `{used_memory_names, read_names?}` |
 | `:hook_notice` | a hook's or plugin's notify during a turn | `{hook, text, level}` (announced with `between_turns: true` outside a turn) |
 | `:guardrail_warning` | a guardrails line during a turn | `{message}` |
@@ -681,7 +689,7 @@ prompt starts with what the server has cached).
    and config.yml hooks survive.
 3. **Each loop works on its own copy of the conversation.** The Engine's `turn.messages` is what it sent. After
    a normal end or a Stop it keeps `result.conversation`; after a failure, the copy attached with
-   `FailedTurn.attach`; after a Ctrl-C, only `turn.messages`.
+   `FailedTurn.attach` (a Ctrl-C's too); `turn.messages` only when it ended before the loop.
 4. **Events are the contract.** UIs read events, not internal state. `on_event` is per turn; observers are
    persistent.
 5. **A stable system prompt for the cache.** `SystemPrompt#build` caches the prompt per Engine, keyed by
@@ -749,3 +757,8 @@ Paths are under `lib/samagotchi/`.
 | `turn_checkpoint.rb` | `TurnCheckpoint`: a worker's running turn saved at the loop's iteration boundaries (`Session#turn_checkpoint`), so a killed worker loses at most `INTERVAL` of it |
 | `context_status.rb` | `ContextStatus`: one turn's context tracking (the status line's value, the `:context_status` event, the model's guidance line) ([context-telemetry.md](context-telemetry.md)) |
 | `session_manager.rb` | Background session processes (workers) and their IPC |
+| `worker_wakes.rb` | `WorkerWakes`: a worker's wake budget for the turns nobody typed (`session.max_wakes`) |
+| `task_watch.rb`, `task_finish_note.rb` | `TaskWatch`: the background tasks a worker's session started that the model hasn't seen finish; `TaskFinishNote`: the note one leaves when it does ([background-tasks.md](background-tasks.md#finish-wake)) |
+| `side_usage.rb` | `SideUsage`: one side request's usage (a recap, `ctx.ask_model`), folded into the session's side sums (`:side_usage`) |
+| `bridge/client_event.rb` | `Bridge::ClientEvent.project`: what an SSE client gets for an engine event ([architecture.md](../architecture.md)) |
+| `guardrails/parent_policy.rb` | `Guardrails::ParentPolicy`: which options of a question a parent agent may pick (`guardrails.parent_answers`) |

data/docs/internals/prompt-caching.md

@@ -83,6 +83,10 @@ right-hand column happens.
   finishes booting between load and the first turn changes search answers only, so two sessions on the same
   toolkit with the same MCP cache send the same bytes. Whether find_tools/call_tool are declared at all reads the
   same two things (`Registry#index_needed?`), never live groups.
+- A worker's `execute` and `task_create` descriptions carry the finish wake's sentence ("if you end your turn before
+  it finishes, chi tells you when it does"; `Engine.new(task_finish_notes:)`, set once as the worker builds its
+  Engine); the `--no-shared` REPL's, and a worker's under `session.task_wakes: off`, don't. A session that moves
+  between the two, or whose worker restarts after `task_wakes` changed, misses the cache once.
 - On remote Claude, `LLM::PromptCache.mark` sends the system message as two text parts. The stable part carries
   breakpoint #1, so a **new session** reads it from the cache. The last non-system message carries breakpoint
   #2, so the **next request in the session** reads everything up to it. Mid and tail system messages never take

data/docs/internals/tool-guardrails.md

@@ -27,6 +27,14 @@ Telemetry uses existing context estimation settings:
 - `SAMAGOTCHI_CONTEXT_WINDOW_TOKENS` (`context.window_tokens`)
 - `SAMAGOTCHI_CONTEXT_CHARS_PER_TOKEN` (`context.chars_per_token`)
 
+Line ranges (`read` and `edit`; env only, no config key):
+
+- `SAMAGOTCHI_READ_END_OPTIONAL` / `SAMAGOTCHI_EDIT_END_OPTIONAL` (default `true`): a `start_line` without
+  `end_line` means "to the end of the file"; `false` makes it an error.
+- `SAMAGOTCHI_READ_ALLOW_OOR_END` / `SAMAGOTCHI_EDIT_ALLOW_OOR_END` (default `true`): an `end_line` past the end is
+  clamped to the last line and the result says so; `false` makes it `Error: range out of bounds`. A `start_line`
+  past the end is always an error.
+
 ## Execute Tool Output Guardrails
 
 The `execute` tool applies the same guardrail model to command output:
@@ -64,8 +72,8 @@ built-in name; a tool with none gets `:head`):
 everything else the cap leaves, so a larger `max_tool_output_chars` keeps a longer tail. Both are snapped to whole
 lines when that keeps at least half of each. execute's stdout and stderr blocks are cut each on its own (stdout gets
 about two thirds of the room when both are long, a block that needs less gives the rest to the other); the `exit:`
-line is always kept. The whole stays within the cap; a cap too small for a tail of `ToolOutputCut::MIN_TAIL` (200)
-characters gets the `:head` cut, and so does one whose gap lines leave no room for that tail (checked with the
+line is always kept. The whole stays within the cap; a cap under three times `ToolOutputCut::MIN_TAIL` (200), so
+under 600 characters, gets the `:head` cut, and so does one whose gap lines leave no room for a 200-char tail (checked with the
 file's planned path before anything is written): nothing is saved then, and the event has no `output_file:`.
 
 The gap line says what was left out and where the whole output is:

data/docs/memory.md

@@ -308,6 +308,12 @@ for a file another bundle installed.
   with neither and no terminal it keeps your edits and says so. Kept edits
   exit 2; `chi bundle diff NAME FILE` shows the base, and `--force` takes
   the bundle's version.
+- **A dev install** (`chi bundle install --dev PATH`) links the hooks, rules,
+  plugin and scripts to `PATH` but still copies the memories at install, so
+  an edit to one of them in `PATH` isn't seen until the next install.
+- **The rest of the manifest** (`plugin:`, `requires_chi`, `session_settings:`,
+  `context_providers:`, `requires_chi_next`) is in
+  [Plugins](plugins.md) and [internals/bundles.md](internals/bundles.md).
 
 ## Bundle profiles: core and dev
 

data/docs/plugins.md

@@ -31,7 +31,8 @@ plugin:
 requires_chi: ">= 0.1.28"    # optional: a gem-style requirement (">= 0.1.28, < 0.2"); the bundle's hooks/ check it too
 # requires_chi_next: true    # shipped bundles only, ignored by chi: rake release:bump raises requires_chi
                              # to the chi being released (docs/releasing.md)
-session_settings: [cap]      # optional: the settings a session may set (chi --set my-bundle.cap=3)
+session_settings: [cap]      # optional: the settings a session may set (chi --set my-bundle.cap=3);
+                             # {cap: number} types them: number (or off), boolean, string or any
 needs: [gh]                  # optional: outside commands it relies on (see memory.md#bundles-that-need-outside-commands)
 ```
 
@@ -766,10 +767,13 @@ A bundle's settings are config.yml's, for every session. A setting a session may
 say) is one the manifest lists in `session_settings:`; `chi --set BUNDLE.KEY=VALUE` and `chi send --new --set …`
 then give it to a new session, saved with it (a respawn, a fork and a continued link keep it; a delegate child
 doesn't). chi refuses a bundle that isn't installed (or whose plugin doesn't load) and a key the manifest doesn't
-list, so a typo isn't saved. Values are typed simply: an integer (`3`, `-1`) or a decimal (`2.5`) is a number,
-`true` is true, `false` and `off` are false, and anything else stays the text as given (`010`, `0x10`, `3:30`,
-`No`, `null`); `POST /api/sessions` `bundle_settings` types its strings the same way and keeps JSON numbers and
-booleans. `ctx.settings` is the config's section with the session's values laid over it (one level: a session's
+list, so a typo isn't saved. A manifest that types a key (`session_settings: {cap: number}`: `number`, which
+takes off too, `boolean`, `string`, or `any`) gets only a value of that type: `--set my-bundle.cap=five` is refused,
+exit 2, as a key it doesn't list is (a mapping needs a chi newer than 0.91.0). Values are typed simply: an integer (`3`, `-1`) or a decimal (`2.5`, `.5`, `1e1`)
+is a number, `true`, `yes` and `on` are true, `false`, `no` and `off` are false (any case, as config.yml's YAML reads
+them), and anything else stays the text as given (`010`, `0x10`, `3:30`, `y`, `null`; YAML would read the first
+three as numbers and `null` as nothing); a key typed `string` keeps its text as given (`yes`, `5`, `1.10`); `POST /api/sessions` `bundle_settings` types its strings the same way and
+keeps JSON numbers and booleans. `ctx.settings` is the config's section with the session's values laid over it (one level: a session's
 `cap` replaces the config's `cap`). Read such a key from `ctx.settings` where it is used, not in
 `initialize(settings)`: that runs once at load, before any session, and gets the config only.
 
@@ -1195,7 +1199,8 @@ bundle.shutdown
   parts (`reported:`, `estimated:`, `side:`, `known:`; `total` is reported + estimated) or a callable giving either,
   called at each read (a counting lambda shows whether the bundle read it).
 - **`session_settings:`** (on `Bundle.load` and `bundle.set`) are the session's own `--set` values for the bundle,
-  keys its manifest lists in `session_settings:` (another raises `ArgumentError`, as chi refuses it). `ctx.settings`
+  keys its manifest lists in `session_settings:` (another key, or a value of another type than the manifest gives
+  it, raises `ArgumentError`, as chi refuses it). `ctx.settings`
   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.
@@ -1218,7 +1223,8 @@ docs/testing.md). **Minitest:** `require "samagotchi/testing/minitest"` and subc
 - **From the command line:** `chi bundle test [PATH]` runs a bundle's `test/**/*_test.rb` (or `spec/`) on the
   Ruby and lib chi runs on, and `chi bundle check [PATH] [--fix]` runs `Install` (and the manifest, sha and
   `requires_chi` checks) in a sandbox ([cli.md](cli.md#writing-a-bundle-new-test-check)). `chi bundle new NAME`
-  writes a test to start from.
+  writes a test to start from. `chi bundle try PATH -p TEXT` runs it against a real model for one turn
+  ([cli.md](cli.md#trying-a-bundle)), and `chi bundle install --dev PATH` links it into your own sessions.
 
 ## The btw bundle
 
@@ -1615,7 +1621,10 @@ bundles:
   a command, not an answer: a parent that sends it (`chi send ID -m '/cap 10'`) raises the cap under any strategy.
 - **The cap of a session:** the one `/cap` or a Continue set for it, else its own `cap:` (`chi --set
   cost-cap.cap=3`, `chi send --new --set cost-cap.cap=3`; `--set cost-cap.cap=off`, `0` or a negative number for none), else `child:` for a
-  delegate child, else `default:`. Delegates and continued links each have their own cap (a continued link keeps
+  delegate child, else `default:`. A cap is a number (`3`, `.5`, `1e1`; in config.yml and `/cap`, `"$2"` too, which `--set` refuses). `--set` refuses
+  another value (`cost-cap.cap=five`: exit 2); one in config.yml (or set before this check) that doesn't read
+  (`default: five`) gets one notice, `cost-cap: default: "five" isn't a number or off; no cap`, and a `cap:` or
+  `child:` that doesn't read gives way to the next key (`…; using default: ($5.00)`), never a silent no cap. Delegates and continued links each have their own cap (a continued link keeps
   the `--set` cap, not a `/cap` or Continue); there is no family cap.
 - **A host it can't watch:** a model that reports no cost and has no configured price (a local server, a free
   model that reports 0) reads unknown: one notice, `the $3.00 cap can't be enforced: <model> reports no cost and has
@@ -1626,7 +1635,7 @@ bundles:
 
 - `/cap`: `cost-cap: $1.20 spent of $3.00 (reported $1.10, estimated $0.10, side $0.02)`, or `cost-cap: no cap
   ($1.20 spent)`, with `(can't be enforced: no cost reported or priced)` when it can't be.
-- `/cap 5` or `/cap $5`: the cap (and what Continue adds) becomes $5.00 for this session. A cap at or under the
+- `/cap 5`, `/cap $5` or `/cap .5`: the cap (and what Continue adds) becomes $5.00 for this session. A cap at or under the
   spend is allowed: the next generation asks.
 - `/cap off` (or `/cap 0`): no cap for this session, over the config's `default:`.
 
@@ -2254,7 +2263,7 @@ crash, TERM), chi shuts the session's Engine down:
 Plugins load when a session starts (`Engine.new`, in the REPL or a
 worker), after the bundle hooks. The steps are:
 
-1. The file must match the sha256 recorded at install.
+1. The file must match the sha256 recorded at install (not checked for a bundle installed with `--dev`).
 2. chi must meet `requires_chi`.
 3. The file is `module_eval`'d into a new module in the bundle's namespace
    (`Samagotchi::Bundles::<bundle>`).
@@ -2280,9 +2289,11 @@ a bundle's hooks. **Installing a bundle means trusting it**, as you would a
 gem.
 
 - The sha256 is an integrity check, not proof of who wrote the file. A file
-  edited after install is not loaded until you reinstall the bundle.
-- Install only copies the file. The code first runs at the next session
-  start.
+  edited after install is not loaded until you reinstall the bundle. A
+  `--dev` install skips that check for its own bundle: its files are the
+  source directory's, and an edit loads at the next start.
+- Install only copies the file (`--dev` links it). The code first runs at the
+  next session start.
 - Guardrail rules keyed by a tool's name apply to plugin tools, as they do to
   chi's own tools; path and command rules see what `targets:` says.
 
@@ -2301,6 +2312,12 @@ gem.
   `requires_chi`, its `scripts/` and `context_providers:`) into the built
   bundle.
 - `chi bundle uninstall <name>`: removes the plugin with the bundle.
+- `chi bundle install --dev <dir>`: links the bundle's plugin, hooks, rules and scripts to `<dir>` instead of
+  copying them, with no sha256 check, so an edit applies at the next worker start
+  ([cli.md](cli.md#writing-a-bundle-new-test-check)).
+- `chi bundle new`, `test` and `check`: start a bundle, run its tests on chi's Ruby, check it as an install takes
+  it ([cli.md](cli.md#writing-a-bundle-new-test-check)); `chi bundle try PATH -p TEXT`: run it for one turn in a
+  sandbox and trace what it did ([cli.md](cli.md#trying-a-bundle)). The path: [bundle-authoring.md](bundle-authoring.md).
 
 ## Not yet
 

data/docs/releasing.md

@@ -61,6 +61,9 @@ as the GitHub release body.
 | `rake bundles:sha` | Recomputes the sha256 lines of every shipped bundle manifest (`files:`, `hooks:`, `plugin:`). |
 | `rake bundles:check` | Sha lines match; every top-level `*.md` of a bundle is listed in its `files:` (an install takes only the listed ones); a bundle changed since the last `v*` tag has a higher version (skipped, with a note, before the first tag). Warns (doesn't fail) when such a bundle's `requires_chi` still admits the tagged chi: mark it `requires_chi_next` if the change uses anything new. Notes a bundle marked `requires_chi_next`, and a profile (`core`, `dev`) whose `requires_chi` is below a member's. The release workflow and `release:check` run it in full. |
 | `rake 'bundles:check[ci]'` | The CI workflow's (every push and PR): the same, except the version check leaves out the system bundle, which is changed and unbumped between releases (`release:bump` moves its version with VERSION). A task argument, not `CI=1`: GitHub sets `CI` in the release workflow too. |
+| `rake bundles:specs` | The shipped bundles' own specs (`lib/samagotchi/bundles/*/spec`) on the bundle test kit alone (no `spec_helper`), as an external bundle's run. CI runs it as its own step. |
+| `rake lint` / `rake lint:fix` | RuboCop over the repo (must report no offenses; CI runs it) / its safe autocorrect (`rubocop -a`). |
+| `rake gem:validate`, `gem:build`, `gem:install`, `gem:clean` | Check the gemspec; build the gem into `pkg/`; build and install it locally; remove the built gems. |
 | `rake release:draft_changelog` | A draft Unreleased section from the commit subjects since the last tag, grouped. Stdout only. |
 | `rake release:bump[X.Y.Z]` | VERSION, the system manifest, Gemfile.lock, CHANGELOG, and `requires_chi: ">= X.Y.Z"` for each bundle marked `requires_chi_next` (the marker dropped). No commit. |
 | `rake release:check` | Clean tracked tree, VERSION == system bundle, a CHANGELOG section, no `requires_chi_next` left, `bundles:check`, `rake lint` (RuboCop), rspec (both roots: `spec` and the bundles' own `spec/`) + `rake bundles:specs` + npm test, `gem build`, then a clean install into a temp GEM_HOME that runs `chi --version`, `chi self` and `chi bundle list` with a temp HOME. Needs the network (gem dependencies). |

data/docs/sessions.md

@@ -2,7 +2,7 @@
 
 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`), and `tool_output/` once a long `execute` result was cut: its whole output, which the cut result names (`ToolOutputFiles`, the newest 50 kept; see [Tool output guardrails](internals/tool-guardrails.md#the-runners-cut-max_tool_output_chars)). 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, `prompt_notes`, the model notes the system prompt carried at its last build (`[{name, scope, chars, digest}]`, see [Memory](memory.md#model-notes)), `parent_id`, the session that delegated this one (see *Delegating*; `null` otherwise), and `continues`, the session this one continues (the previous link of a chain, see *Session chains*; `null` otherwise); files from before those keys read as empty lists, no parent and no previous link. `model_name` is the resolved model ref (an alias applied, `host:id` when it names a host), so a resumed session keeps its model when an alias is retargeted; `model_typed` is the name it was given as when that differs (an alias), for the `models:` lookup after a resume (`null` otherwise).
 
-**Input files:** a message for a session's worker waits in `input/<timestamp>.json` (`SessionInbox.write_input`: `prompt`, `client_id`, `enqueued_id`, and `images`, `no_interrupt` and `delivery` when they apply; `delivery` is written only for `"queue"`). While a turn runs, the worker merges them at each step boundary in name order, except a queued one or one with images: those wait for the turn's end and run one turn each, in name order, and a file after them still merges (`Worker#pending_input_drain`). A queue is sent only to a worker whose `bridge.json` names the `delivery` feature; an older one would steer it, so `SessionManager.deliver_turn` refuses it (409 `delivery_unavailable`), and any other 4xx the Bridge answers is a refusal too, never a fallback file (except a 413, a body over its size limit: that one still goes in as a file, its `delivery` kept). A session command recognized in a file runs without a turn; its completed outcome is kept at `input/settled/<enqueued_id>` so `chi send --wait` ends instead of waiting for a turn that will not run. **Reply files:** a turn that ends with visible text leaves its reply in `output/<timestamp>.txt`, or `output/<timestamp>-<enqueued_id>.txt` when the turn ran an input file with an id (`SessionInbox.write_output`), and the session's `last_turn` keeps that `enqueued_id`; so a wait for one queued message (`chi send --queue --wait`, `ReplyWait`'s `turn:`) finds its own turn's reply or end, never another turn's. The names still sort by time, and every reader takes `*.txt`.
+**Input files:** a message for a session's worker waits in `input/<timestamp>.json` (`SessionInbox.write_input`: `prompt`, `client_id`, `enqueued_id`, and `images`, `no_interrupt` and `delivery` when they apply; `delivery` is written only for `"queue"`). While a turn runs, the worker merges them at each step boundary in name order, except a queued one or one with images: those wait for the turn's end and run one turn each, in name order, and a file after them still merges (`Worker#pending_input_drain`). A queue is sent only to a worker whose `bridge.json` names the `delivery` feature; an older one would steer it, so `SessionManager.deliver_turn` refuses it (409 `delivery_unavailable`), and any other 4xx the Bridge answers is a refusal too, never a fallback file (except a 413, a body over its size limit: that one still goes in as a file, its `delivery` kept). A session command recognized in a file runs without a turn; its outcome is kept at `input/settled/<enqueued_id>` (`completed`, `failed` for a command error, `canceled` with `cancel_reason` `busy` or `dropped` for one refused mid-turn or dropped as the worker left; `origin: command`) so `chi send --wait` ends instead of waiting for a turn that will not run, its detail saying `the command failed` or `the command was refused (busy)` rather than a turn's words. **Reply files:** a turn that ends with visible text leaves its reply in `output/<timestamp>.txt`, or `output/<timestamp>-<enqueued_id>.txt` when the turn ran an input file with an id (`SessionInbox.write_output`), and the session's `last_turn` keeps that `enqueued_id`; so a wait for one queued message (`chi send --queue --wait`, `ReplyWait`'s `turn:`) finds its own turn's reply or end, never another turn's. The names still sort by time, and every reader takes `*.txt`.
 
 **Removing a queued message:** a message queued for after the running turn (`chi send --queue`, the web's Alt+Enter, `/queue TEXT` in a terminal), or one with images (it waits for the turn's end too), can be taken back while it still waits: the worker's Bridge (`POST /session/:id/turn/dequeue {enqueued_id}`, the `unqueue` feature) deletes its input file and every UI drops it (`:turn_dequeued`). It is a race with the turn's end, decided by the same rename the worker uses to take the file: once a turn took it the answer is `409 already_started` (it runs), and an id the worker no longer knows is `404 unknown_enqueued_id`. A plain message sent without `--queue` is not removable (`409 not_queued`): a running turn's next step may take it at any moment. A wait for its turn (`chi send --queue --wait`, a delegate follow-up's wait) ends at once with `removed` (the tombstone `input/removed/<enqueued_id>` says so), and a `chi -p` run whose queued prompt went ends with exit 1. The `200` carries the removed `prompt`: the web and the attached terminal put it back into the composer to edit (not its images). The images a removed message named stay in the session's `images/`. Not removable: a queued session command (`/queue /model x`: it waits in the worker, not in `input/`), a message in a stopped worker's inbox (the next worker runs it), and the plain REPL's (`--no-shared`) own queue.
 
@@ -17,7 +17,7 @@ Sessions are plain files — no DB. Each session is `~/.local/state/samagotchi/s
 
 A session is deleted if **expired by age OR overflow by count** (unless `keep_status` or the live-owner guard: a session a worker or `chi` still has open is never pruned). A session's `status` is its turn state (`idle`/`running`), not whether a worker is alive. Orphan dirs without a `*.json` are never deleted, except skeleton-only ones (see *Empty sessions*). Deletion removes both `*.json` and sidecar dir atomically. Set both `DAYS=0` and `MAX=0` to retain forever.
 
-**Worker idle exit:** a background worker (plain `chi`, Web UI sessions) exits after `SAMAGOTCHI_SESSION_IDLE_EXIT_MINUTES` (`session.idle_exit_minutes`, default `30`, `0`=never) with no turn running or queued, no client on its stream (an open web tab or attached terminal keeps it), no reminder registered and no continue offer (the step-limit question) waiting for an answer. It removes `bridge.json` and frees `owner.lock`; the next prompt or `--attach` wakes a new worker (`WorkerIdleExit`, `SessionManager.run_session_loop`). 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`. With `"restart": true` (a worker whose sidecar lists the `restart` feature) the worker hands the session to a new worker on the newest chi installed: it leaves, then starts its successor once its lock is free, keeping even an empty session and writing no recap. Clients' streams don't hold a restart (a web tab and an attached terminal reconnect to the new worker); what would be lost does: a turn running or queued, a continue offer, a question or approval waiting, reminders, a `/btw` (or another anytime command) still running, a delegate's approval relay open or settled in the last 10 minutes, and background tasks this conversation started that still run (`WorkerIdleExit#hold_for_restart`; 409 `held` with `reason`). What lives only in the worker's memory goes: the event history a late client replays, the kept `/btw` answers, a plugin's in-memory state.
+**Worker idle exit:** a background worker (plain `chi`, Web UI sessions) exits after `SAMAGOTCHI_SESSION_IDLE_EXIT_MINUTES` (`session.idle_exit_minutes`, default `30`, `0`=never) with no turn running or queued, no client on its stream (an open web tab or attached terminal keeps it), no reminder registered, no background task it watches for a [finish wake](internals/background-tasks.md#finish-wake) still running or waiting for its wake turn (with `session.task_wakes: wake`; not one whose turn you stopped) and no continue offer (the step-limit question) waiting for an answer. It removes `bridge.json` and frees `owner.lock`; the next prompt or `--attach` wakes a new worker (`WorkerIdleExit`, `SessionManager.run_session_loop`). A client can also ask the worker to exit right away (Bridge `POST /session/:id/exit`; `/exit` in an attached terminal does, `/detach` doesn't): the same rules apply without the timeout (even with `0`), and the asker's own stream doesn't count. The reply names what keeps it up (for background tasks, which ones and how to stop them). The session's status stays as it was, not `stopped`. With `"restart": true` (a worker whose sidecar lists the `restart` feature) the worker hands the session to a new worker on the newest chi installed: it leaves, then starts its successor once its lock is free, keeping even an empty session and writing no recap. Clients' streams don't hold a restart (a web tab and an attached terminal reconnect to the new worker); what would be lost does: a turn running or queued, a continue offer, a question or approval waiting, reminders, a `/btw` (or another anytime command) still running, a delegate's approval relay open or settled in the last 10 minutes, and background tasks this conversation started that still run (`WorkerIdleExit#hold_for_restart`; 409 `held` with `reason`). What lives only in the worker's memory goes: the event history a late client replays, the kept `/btw` answers, a plugin's in-memory state.
 
 **Empty sessions:** a session nothing happened in is deleted when it is left, so `chi` → `/exit` leaves no trace. Empty means: no messages, no turn tried (a failed turn leaves a `last_prompt` and keeps it), no memory used, no pending question, nothing in `input/`, `notes/` or `images/`, nothing in its dir beyond the worker's skeleton, mode `assist`, and the default model. A session on another model (`/model`, `--model`) counts as prepared and stays (`SessionManager.discardable?`). The worker checks as it idle-exits or leaves on a client's request and deletes it once its lock is free, checking again first. The attached `/exit` then says `Detached; the session is empty: it will be discarded if nothing arrives before its worker stops.` (a note or prompt landing first keeps it). The REPL (`--no-shared`) does the same at `/exit` or Ctrl-D. The retention sweep catches those killed first: empty sessions over an hour old with no live owner, whatever `DAYS`/`MAX`, and skeleton-only dirs with no `*.json`. `session.keep_empty: true` (env `SAMAGOTCHI_SESSION_KEEP_EMPTY`) turns all of it off.
 
@@ -143,7 +143,7 @@ system message marked `kind: turn_note` (the UIs don't show it; they showed the
   the user, who may send it again.]` in the REPL and attached mode, where the prompt is given back;
   `… The user's last message was not answered.]` after `-p`, where the prompt stays in the session;
   `… The wake turn for the change in attached context pr-7 was not answered; chi starts no other wake turn until
-  the user writes.]` after a wake turn chi started (a context source's change, a delegate's report), not the user
+  the user writes.]` after a wake turn chi started (a context source's change, a delegate's report, a background task that finished), not the user
   (for a delegate's report it adds `chi keeps the report and brings it again with the user's next message.`);
 - cancelled (Ctrl-C, the web's stop): `[SYSTEM: the previous turn was cancelled (ctrl-c) after 12s; the reply
   above ends where it was cut off.]` (an answer or only narration had streamed), or `…; no answer had been shown.]` when only thinking had streamed;
@@ -211,7 +211,7 @@ chi send --new --continues last:3fa2 -m "new day"      # the next link of 3fa2's
 - Exit codes with `--wait`: 0 answered; 3 the turn waits for an answer from you (a question, a hook's question, a guardrail approval, or the step-limit question: see [chi as a sub-agent](sub-agent.md#the-step-limit)), and the session keeps waiting: stderr gets the whole question (`waiting for an answer (approval): …`, its text, the numbered options, whether free text is allowed) and how to answer it (`chi answer ID --question QID --option N`, or `chi --attach ID`, the web); 4 `--timeout S` passed with the turn still running (it goes on; wait again); 1 the turn ended without a reply (canceled, failed or empty), the worker failed or vanished, or the session was stopped; 130 on Ctrl-C, which leaves the turn running (`still running: chi --attach ID`). There is no default timeout.
 - `--format json` (with `--wait`) prints one JSON object on stdout however the wait ends, for a script or a parent agent (see [chi as a sub-agent](sub-agent.md)): `{"status":"answered","session_id":…,"text":…}`; `{"status":"question",…,"question":{"id","kind","header","text","options","multi_select","allow_freeform","approval"},"answer_with":"chi answer ID --question QID --option N"}`, where `kind` is `question` (the model's), `hook` or `approval` (with the tool, command, cwd, rule, reason and offered scopes); `{"status":"running",…,"detail":…}` (exit 4, and on Ctrl-C); and `failed`, `canceled`, `removed` (a `--queue --wait` message taken back before it ran), `no_answer`, `error`, `worker_gone` or `stopped` with a `detail` line (exit 1); `failed` adds `error_kind` and `retryable`, `canceled` adds `cancel_reason` (`worker_stopped`: the turn waited for died with its worker and the next worker settled it) and `stopped_by`, when known. A failure before the wait (no such session, a busy one) is `error` too. A usage error (exit 2) prints no JSON.
 - `--wait ID` with no message (no `-m`, nothing piped) sends nothing: it waits for the session's next reply and prints and exits as above. With a turn running, that turn's reply (its `interrupted_turn` mark names it), not a turn's queued behind it; with the step-limit question standing, the reply of the turn its Continue runs; with an idle session whose last turn already ended, that ended turn is the answer: its reply, or its end when it left no reply — a turn that finished in the gap between waits is reported, not waited for. With none of those (or a worker whose `bridge.json` lacks `turn_ids`), the next reply of any turn. A running session is fine (that is the point), so after exit 3, 4 or 130 an agent waits again this way while the user answers in the web or `chi --attach`; the question pending when it starts doesn't count again. An idle session with no worker waits until something wakes one. With `--new`, or two ids, it is a usage error (exit 2).
-- `--set BUNDLE.KEY=VALUE` (with `--new`, repeatable) gives the new session a bundle setting of its own, as `chi --set` does (see *Bundle settings* below): `chi send --new --set cost-cap.cap=3 -m "…"` starts it with a $3 cap. A bundle or key the installed bundles don't offer is a usage error (exit 2), as is `--set` without `--new`.
+- `--set BUNDLE.KEY=VALUE` (with `--new`, repeatable) gives the new session a bundle setting of its own, as `chi --set` does (see *Bundle settings* below): `chi send --new --set cost-cap.cap=3 -m "…"` starts it with a $3 cap. A bundle or key the installed bundles don't offer, or a value of another type than the manifest gives the key (`cost-cap.cap=five`), is a usage error (exit 2), as is `--set` without `--new`.
 - `--parent-answers LEVEL` (with `--new`) gives the new session its own `guardrails.parent_answers` (`hard`, `standard`, `soft`), tighten-only: config.yml's applies when it is stricter, with `chi send: warning: --parent-answers soft is looser than config.yml's …`. See *Parent answers* below.
 - `--continues ID` (with `--new`) starts the next link of that session's chain instead (see *Session chains*): in its folder, on its model (or the one `--model` names), LLM context, thinking level, toolkit, bundle settings and parent answers, so `--dir`, `--llm-context*`, `--thinking`, `--toolkit`, `--tool`, `--no-tool`, `--set` and `--parent-answers` are refused beside it; `ID` may be a prefix or `last:ID`, the chain's latest link. Without a message the new link starts idle; `--wait` then has nothing to wait for (a usage error). It prints `<full id>  started (continues 3fa2c1d0)`, with `; 2 delegates moved` inside the parentheses when open delegates moved to it; a refusal (continued already, naming the next link; an open delegate that can't move; a turn running) is `chi send: refused: …`, exit 1, and a `--model` it can't start on is `chi send: could not start a session: …`, exit 1, nothing archived. A fallback to the default model (below) prints `chi send: warning: …`.
 - The 16 KiB cap applies: `git diff | chi send --new …` on a big diff is refused; name the branch in the message instead and let the session read it.

data/lib/samagotchi/bridge.rb

@@ -84,8 +84,8 @@ module Samagotchi
     # @param on_exit_request [#call, nil] a client asks the worker to exit
     #   now: takes the client_id and delete: (the exit is to delete the
     #   session, /exit --delete), returns nil when the worker will leave or
-    #   the Symbol that keeps it up (WorkerIdleExit#hold_for_request); called
-    #   with the event log held. Without one, POST /exit answers 501
+    #   what keeps it up (a WorkerIdleExit::Hold: #reason, #tasks, #hint);
+    #   called with the event log held. Without one, POST /exit answers 501
     # @param exit_discards [#call, nil] after an exit the worker agreed to:
     #   whether it will delete the session as empty (the 200 says
     #   +discard+); without one the reply leaves the field out
@@ -805,7 +805,8 @@ module Samagotchi
     # event log held, so no POST /turn lands between its check and its
     # answer; it leaves from its loop after this reply.
     # 200 {status: "exiting", discard?: the session is empty and goes} ({status: "restarting"} for a restart), or 409
-    # {status: "held", reason:} naming what keeps it up. A past +deadline+
+    # {status: "held", reason:} naming what keeps it up (with tasks: [{id:,
+    # command:}] and a hint: how to stop them, for background_tasks). A past +deadline+
     # (see #handle_post_turn), checked with the event log held: 408
     # deadline_passed, the worker not asked (its client said it didn't stop).
     # Returns [headers, status, body].
@@ -822,15 +823,15 @@ module Samagotchi
       deadline = fetched(parsed, "deadline")
       return BAD_DEADLINE unless deadline_valid?(deadline)
 
-      reason = @engine.synchronize_events do
+      hold = @engine.synchronize_events do
         raise IntakeClosed if stopped?
         next :expired if expired?("exit_expired", deadline, sid: session_id, client_id: client_id)
 
         @on_exit_request.call(client_id, **options)
       end
-      return deadline_passed("exit request") if reason == :expired
+      return deadline_passed("exit request") if hold == :expired
 
-      if reason.nil?
+      if hold.nil?
         return [{}, 200, { status: "restarting", session_id: @session_id }] if restart
 
         body = { status: "exiting", session_id: @session_id }
@@ -838,7 +839,10 @@ module Samagotchi
         return [{}, 200, body]
       end
 
-      [{}, 409, { status: "held", reason: reason.to_s, session_id: @session_id }]
+      # A hold may name what it waits for (tasks: the background tasks a
+      # finish wake watches).
+      [{}, 409, { status: "held", reason: hold.reason.to_s, tasks: hold.tasks, hint: hold.hint,
+                  session_id: @session_id }.compact]
     end
 
     # Queue a turn for this session through its file IPC (the worker polls

data/lib/samagotchi/bundle_command/check.rb

@@ -8,6 +8,7 @@ require_relative "../memory_bundle/shas"
 require_relative "../memory_bundle/memory_files"
 require_relative "../plugin/api"
 require_relative "../version"
+require_relative "../cli/flags"
 
 module Samagotchi
   class BundleCommand
@@ -23,6 +24,22 @@ module Samagotchi
     # sha256 lines (MemoryBundle::Shas). #run returns 0 without errors, 1
     # with any.
     class Check
+      HELP = <<~TEXT
+        Usage: chi bundle check [PATH] [--fix] [--set KEY=VALUE]
+
+          Check the bundle at PATH (default: .) as an install would take it, one finding per line:
+            error|warn|info CODE file[:line]: message (fix: hint)
+          It installs and loads the bundle in a sandbox (temp HOME, config and state), not in yours, but its plugin and
+          hooks run in this process as written: run it on code you'd install.
+          --fix            rewrite stale and placeholder sha256 lines in manifest.yml
+          --set KEY=VALUE  a setting for the load (config.yml bundles: <name>: KEY), repeatable
+          Exit status: 0 no errors, 1 errors, 2 usage.
+      TEXT
+      FLAGS = CLI::Flags.new(help: %w[--help], flag_pattern: /\A--/) do |f|
+        f.switch "--fix"
+        f.value "--set", key: :set, repeat: true
+      end
+
       Finding = Data.define(:level, :code, :file, :line, :message, :fix) do
         def error? = level == :error
 
@@ -234,13 +251,26 @@ module Samagotchi
         # A shipped bundle installed from any chi's copy is that bundle.
         return if shipped?
 
-        record = MemoryBundle::Provenance.new(name: name).record
-        return unless record && File.expand_path(record.source.to_s) != @dir
+        record = installed_record(name)
+        return unless record
+        return unreadable_clash(name, record.error) if record.error
+        return if File.expand_path(record.source.to_s) == @dir
 
         add(:warn, :clash, "manifest.yml", "a bundle named #{name} is installed from #{record.source}",
             line: manifest_line("name"), fix: "rename the bundle, or chi bundle upgrade #{display(@dir)} to replace it")
-      rescue StandardError
-        nil
+      end
+
+      # The installed same-named bundle's record; an unreadable one as
+      # InstalledBundle.unreadable.
+      def installed_record(name)
+        MemoryBundle::Provenance.new(name: name).record
+      rescue JSON::ParserError, SystemCallError => e
+        MemoryBundle::InstalledBundle.unreadable(name, "#{e.class}: #{e.message.lines.first&.strip}")
+      end
+
+      def unreadable_clash(name, error)
+        add(:warn, :clash, "manifest.yml", "a bundle named #{name} is installed, but its record can't be read (#{error})",
+            line: manifest_line("name"), fix: "rename the bundle, or chi bundle install --force #{display(@dir)} to replace it")
       end
 
       # An unfilled `sha256: sha256:` isn't YAML: the Installer can't read
@@ -303,19 +333,20 @@ module Samagotchi
 
       def report_registered(manifest, registered)
         plugin = manifest.plugin ? manifest.plugin[:file] : "manifest.yml"
-        registered[:commands].each { |name, _, _| add(:info, :registered, plugin, "command #{name}") }
-        registered[:tools].each { |name| add(:info, :registered, plugin, "tool #{name}") }
-        registered[:hooks].each do |event, hooks|
-          hooks.each do |_bundle, hook, priority|
-            file = manifest.hooks.key?(hook) ? "hooks/#{hook}" : plugin
-            next add(:info, :registered, file, "hook #{event} (priority #{priority})") if Hooks::EVENTS.include?(event)
+        registered.commands.each { |command| add(:info, :registered, plugin, "command #{command.name}") }
+        registered.tools.each { |name| add(:info, :registered, plugin, "tool #{name}") }
+        registered.hooks.each do |event, hooks|
+          hooks.each do |hook|
+            file = manifest.hooks.key?(hook.hook) ? "hooks/#{hook.hook}" : plugin
+            next add(:info, :registered, file, "hook #{event} (priority #{hook.priority})") if Hooks::EVENTS.include?(event)
 
             add(:warn, :"hook-event", file, "hook on #{event.inspect}, which chi never fires",
                 fix: "one of #{Hooks::EVENTS.join(", ")}")
           end
         end
-        { inits: "init", toolkits: "toolkit", tool_sources: "tool source", peer_sources: "peer source" }.each do |key, what|
-          registered[key].each { |name| add(:info, :registered, plugin, "#{what} #{name}") }
+        { "init" => registered.inits, "toolkit" => registered.toolkits, "tool source" => registered.tool_sources,
+          "peer source" => registered.peer_sources }.each do |what, names|
+          names.each { |name| add(:info, :registered, plugin, "#{what} #{name}") }
         end
       end
 

data/lib/samagotchi/bundle_command/scaffold.rb

@@ -3,6 +3,7 @@
 require "fileutils"
 require_relative "../memory_bundle/shas"
 require_relative "../version"
+require_relative "../cli/flags"
 
 module Samagotchi
   class BundleCommand
@@ -12,6 +13,17 @@ module Samagotchi
     # Minitest test on the kit that passes as written, and a README. The
     # test is the pattern to copy (docs/bundle-authoring.md).
     class Scaffold
+      HELP = <<~TEXT
+        Usage: chi bundle new NAME [--dir DIR]
+
+          Start a bundle in DIR/NAME (default ./NAME; refused when it exists): manifest.yml (shas filled,
+          requires_chi this chi), plugin.rb (a /NAME command and an after_tool_call hook), test/NAME_test.rb
+          (passes as written) and README.md. Then: chi bundle test, chi bundle check, chi bundle install.
+      TEXT
+      FLAGS = CLI::Flags.new(help: %w[--help], flag_pattern: /\A--/) do |f|
+        f.value "--dir"
+      end
+
       # A name that is also a slash command (Plugin::Api::COMMAND_NAME).
       NAME = /\A[a-z][a-z0-9_-]{0,31}\z/
 

data/lib/samagotchi/bundle_command/test_run.rb

@@ -1,6 +1,7 @@
 # frozen_string_literal: true
 
 require "rbconfig"
+require_relative "../cli/flags"
 
 module Samagotchi
   class BundleCommand
@@ -15,6 +16,17 @@ module Samagotchi
     # (a checkout or a vendored install: its gems in vendor/bundle), there.
     # The tests' exit status is #run's.
     class TestRun
+      HELP = <<~TEXT
+        Usage: chi bundle test [PATH] [-- ARGS]
+
+          Run the tests of the bundle at PATH (default: .) on the Ruby and the lib chi runs on, outside any Bundler env:
+          test/**/*_test.rb on Minitest (require "samagotchi/testing/minitest"), or else spec/ on RSpec with the kit
+          (-r samagotchi/testing/rspec). ARGS go to the test runner (-- -n /name/, -- -e "a name").
+          The tests run the bundle's code as written, with your HOME (the kit's sandbox is per test): run code you'd install.
+          Exit status: the tests'; 1 no tests; 2 usage, or minitest / rspec doesn't load.
+      TEXT
+      FLAGS = CLI::Flags.new(help: %w[--help], flag_pattern: /\A-/)
+
       LIB_DIR = File.expand_path("../..", __dir__)
 
       def initialize(dir, args: [], stdout: $stdout, stderr: $stderr)