samagotchi 0.141.0 → 0.143.0

data/docs/cli.md

@@ -16,12 +16,12 @@
 - `chi web --start-dir DIR` (config `web.start_dir`) — the folder chi web starts in, in place of the one you run it in (`~` and a relative path work; chi web never changes its own folder): its page opens on that folder's project (the printed link, a bare `/`, the LAN link and its QR code, the Home Screen app), and a new session from the all view starts there; the header's project chip switches projects. One that isn't a folder exits 1; `--start-dir` without `web` exits 2. A chi web already running in another folder keeps it (the second one says so: restart it to change it)
 - `chi web --tunnel tailscale` — the Web UI over https on your tailnet, for your phone anywhere: Tailscale Serve (never Funnel) on this machine's `<machine>.<tailnet>.ts.net` name for this run, the owner your Tailscale login, turned off on exit (see [Tailscale Serve](configuration.md#tailscale-serve-your-tailnet)); `--tunnel` without `web` exits 2
 - `chi web push ls [--format json]`, `chi web push rm ID`, `chi web push test [ID]` — the phones chi web pushes to (see [Phone notifications](configuration.md#phone-notifications-web-push)): list them (short id, label, origin, added, last delivery, done turns, last error; `stale` for one made on another public URL than chi web's now: never sent to), remove one, or send a test notification to ID or to every device not stale. chi web need not run; nothing printed holds a device's push address or keys. A usage error exits 2; a store others can read, a corrupt one, an unknown device or a failed test push exit 1. This machine only: `chi --remote X web push` exits 2
-- `chi web --web-markdown` — opt in to sanitized Markdown rendering for completed assistant messages, the stage's asking text and a resolved question card's reply
+- `chi web --web-markdown` / `--no-web-markdown` — opt in to, or opt out of, sanitized Markdown rendering for completed assistant messages, the stage's asking text and a resolved question card's reply (`web.markdown`, off by default; `--no-web-markdown` turns a config's `web.markdown: true` off for this run)
 - `chi web --no-web-working-set` — turns the stage view's working set off (on by default; `--web-working-set` turns a config's `web.working_set: false` back on): what each turn brought into the model's context, in the stage and under each finished turn; `?working_set=1|0` on the page URL overrides it (see [The working set](#the-working-set))
 - `chi sessions list|stop|restart|archive|unarchive|delete|prune|clean|stats` — manage persisted sessions; `list` shows this git project's, `list --scope=all` every one, a delegated session with `↳ <parent>`, `list --archived` the archived ones too (see [Sessions](sessions.md)). `stats ID` prints a session's cost, tokens and progress, and its own settings (`--set`; a `settings:` line), from a live worker's `GET stats`, else its saved `analytics.json` (`--format json` one object, with `settings`), without running a model turn. A usage error (an unknown subcommand or flag, a flag missing its value, `stop`, `restart` or `delete` with no ids, a bad `list --format` or `--scope`, a `--days`, `--keep` or `--limit` that isn't a whole number) exits 2; an unknown or refused session exits 1
 - `chi note [--source NAME] [-m TEXT] (ID|PREFIX)... | --all` — add a context note (TEXT or stdin) to sessions: background the model sees on its next turn; it starts no turn (see [Sessions: Context notes](sessions.md#context-notes))
 - `chi broadcast [-m TEXT] [--all] [--dry-run]`, `chi broadcast log [--last N] [--format json]`, `chi broadcast deliver BROADCAST_ID (ID|PREFIX)...` — share one piece of information (TEXT or stdin) with every session it may concern, as a context note from `broadcast` (see [Broadcast](broadcast.md))
-- `chi context <add|push|ls|show|refresh|rm|mute|unmute> …` — attach live external text to sessions (a command chi runs every so often, or text pushed in); the model gets a short note when it changes and reads it with `context_read`; `chi context add <URL>` attaches a GitHub PR with the github-pr bundle (see [Attached context](context.md))
+- `chi context <add|push|ls|show|refresh|rm|mute|unmute> …` — attach live external text to sessions (a command chi runs every so often, or text pushed in); the model gets a short note when it changes and reads it with `context_read`; `chi context add <URL>` attaches a GitHub PR with the github-pr bundle; `chi context push NAME -m TEXT` (the long form is `--message TEXT`) gives a `--push` source its new text, read from stdin when no `-m` is given (see [Attached context](context.md))
 - `chi context report [--days N]` — the candidate judge's counts from `context_candidates.jsonl`: candidates proposed, mentioned, attached or declined by you; the judge's asks; what it would attach per threshold, and how that agrees with what you did (this machine only; see [The log and the report](context.md#the-log-and-the-report))
 - `chi send [-m TEXT] [--image PATH]... [--cut | --queue] (ID|PREFIX)...` — send a message to sessions as if typed there: a turn starts (or a running one takes it at its next step; `--cut` asks it to cut long thinking for it; `--queue` runs it as a turn of its own after the running one, and `--queue --wait` waits for that turn's own answer); piped stdin goes above `-m` as quoted context, and `--image` attaches images (see [Sessions: Sending a message](sessions.md#sending-a-message)); `--new` starts a session with it instead (`--new --continues ID|last:ID` the next link of that session's chain, see [Session chains](sessions.md#session-chains)), and `--wait` prints the answer (`--wait ID` with no message waits for the next reply without sending — to an idle session whose last turn already ended, that ended turn's reply or end comes back; `--wait --turn T ID` with no message waits for exactly turn T, whether running, queued or last ended; `--format json` includes its `turn_id` when known, for waiting again after exit 3 or 4; exit 3 a question waits, its options on stderr; exit 4 `--timeout` passed with the turn still running; see [Starting a session](sessions.md#starting-a-session))
 - `chi answer ID --question QID (--option N|LABEL)... [--text T] [--timeout S] [--format json]` (or `--dismiss`) — answer the question a session waits on (the one `chi send --wait` exited 3 with), then wait and print what comes next as `chi send --wait` does: the reply (0), the next question (3), still running after `--timeout` (4). `--option` is 1-based or the label, repeated on a multi-select question; `--text` is free text, or a Deny's reason; `--dismiss` leaves it unanswered and the model finishes its reply. A question no longer open (the web answered first) isn't answered again: it waits for that turn's reply. An option the question doesn't offer exits 2; a worker that is gone exits 1 (`send the task again: chi send --wait -m "…" ID`). What a parent may pick follows `guardrails.parent_answers`, or the session's own `parent_answers` when stricter (`soft`, the default: a deny, a plain answer, Continue and "Allow once"; `standard`: no allow; `hard`: no Continue either), never a wider scope or an allow on chi's own config; a refused pick exits 1 with what to answer instead (a convention, not a security boundary; see [Guardrails](guardrails.md#answers-from-a-parent-agent))
@@ -33,12 +33,13 @@
 - `chi memory ls [--scope project|system] [--format text|json]` — the memories of both scopes (this folder's project first), one row each: scope, name, size, date, `from <bundle>`, the index description and its model overlays; `chi memory rm NAME [--scope project|system]` removes one as `memory_write` with `remove: true` does: its file and model overlays go to the bundle trash (the line names the dir; `chi bundle trash` lists and empties it) and its index line is dropped. NAME in both scopes without `--scope` exits 2 naming both; a missing NAME or a bundle's memory (`chi bundle uninstall` removes it) exits 1 (see [Memory: Listing and removing from the shell](memory.md#listing-and-removing-from-the-shell))
 - `chi desktop install|upgrade|uninstall|status` — the macOS "Send to chi" helper: a Service and a ⌃⌥⌘N hotkey that send text or images to a session (live, stopped or new) as a message (⏎, a turn runs) or a context note (⌘⏎) (see [Desktop helper](desktop.md))
 - `chi models [--format text|json] [--timeout S] [TEXT]` — list the models every configured host offers, as the names `--model` takes (see [Listing the models](#listing-the-models))
-- `chi self` — print version, source dir (checkout or installed gem), config/memory/session paths, model/host and bundles. Run by a session's `execute`, the `model` row (and host, loop, profile, thinking, served model) is **that session's** model, labelled `(this session <id8>; default …)`; elsewhere it is the default, `(default)`. `model key` is the memory overlay key (`<name>.<key>.md`), and `model notes` the model notes a prompt of that model loads (`model_notes_deepseek (system, 612 chars)`, `none`; inside a session its `--mute` list is left out). `chi self --model` prints only the model a new session starts on, an alias resolved to its target (the desktop helper's hint)
-- `chi update [--dry-run] [--to VERSION] [--json] [--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 self` — print version, source dir (checkout or installed gem), config/memory/session paths, model/host and bundles. Run by a session's `execute`, the `model` row (and host, loop, profile, thinking, served model) is **that session's** model, labelled `(this session <id8>; default …)`; elsewhere it is the default, `(default)`. `model key` is the memory overlay key (`<name>.<key>.md`), and `big memories` the memories over `memory.entry_warn_tokens` ([Memory](memory.md#a-memorys-size)), and `model notes` the model notes a prompt of that model loads (`model_notes_deepseek (system, 612 chars)`, `none`; inside a session its `--mute` list is left out). `chi self --model` prints only the model a new session starts on, an alias resolved to its target (the desktop helper's hint)
+- `chi update [--dry-run] [--to VERSION] [--json] [--no-gem] [--no-bundles] [--no-desktop]` — update an installed chi: the gem, the system bundle, the shipped bundles you installed and the desktop helper, and check the bundles from elsewhere, in one table (see [Updating](#updating))
 - `chi home`, `chi home set [--ruby PATH]`, `chi home doctor` — the chi home: the one Ruby (and its gem path) every chi launch boots, whoever launches it. `chi home` shows it (its Ruby, the newest chi in it, gem home and path, `mise`, when and by which chi it was set, and the chi you ran when that is another one; exit 1 with the problem when it can't boot chi), `set` records this chi's Ruby and gem path (or `--ruby PATH`'s own; it must have samagotchi), `doctor` checks it and what should follow it, one row each with `ok`, `warn` or `fail` and what to run (exit 1 on a `fail`; see [Checking it](configuration.md#checking-it-chi-home-doctor)). At a terminal, a chi on another Ruby than the home's says so in one dim line a day. This machine only (see [The chi home](configuration.md#the-chi-home))
-- `chi bundle install|upgrade|uninstall|status|diff|list|build|trash|new|test|check` — 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)). `trash` lists and empties the bundle trash (moved files from uninstalls/upgrades). A usage error (an unknown subcommand or flag, a missing argument, a bad `build --scope`) exits 2, as for the other subcommands. Plain `chi` and `chi web` exit 1 on an unknown flag, a flag missing its value or a stray argument. `new`, `test` and `check` are for writing one: see [Writing a bundle](#writing-a-bundle-new-test-check)
+- `chi bundle install|upgrade|uninstall|status|diff|list|build|trash|new|test|check` — 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), [Bundles](bundles.md#the-btw-bundle), [the mcp bundle](bundles.md#the-mcp-bundle) [the loop-guard bundle](bundles.md#the-loop-guard-bundle), [the check-in bundle](bundles.md#the-check-in-bundle) and [the skills bundle](bundles.md#the-skills-bundle)). `trash` lists and empties the bundle trash (moved files from uninstalls/upgrades). A usage error (an unknown subcommand or flag, a missing argument, a bad `build --scope`) exits 2, as for the other subcommands. Plain `chi` and `chi web` exit 1 on an unknown flag, a flag missing its value or a stray argument. `new`, `test` and `check` are for writing one: see [Writing a bundle](#writing-a-bundle-new-test-check)
 
 - `chi guardrails replay [--dry-run] [--threshold T] [--model M]` — seed System 1's record from the approvals this machine's sessions already answered: each ask is judged by the configured model and written to `guardrails/judgments.jsonl` with the answer the user gave, then a per-rule table prints (asks, allowed, denied, would-be auto-allows, false allows, asks with no judgment). A parent agent's answer is not the user's: only its deny is replayed, and only where the parent could have allowed. `--dry-run` judges without writing, `--threshold` overrides `guardrails.system_one.threshold` for the table, `--model` the configured model for this run. Exit 2 when `guardrails.system_one.mode` is off or no `host` is set; a usage error exits 2 (see [System 1](guardrails.md#system-1-experimental))
+- `chi judgments ls` / `chi judgments report NAME [--days N]` — what [System 1's saved runs](system-one.md) hold: each judgment's digests, runs, labels, failures, models and size; one judgment's counts, p histogram and labels by value. Reads only; local only; `--days` must be a positive whole number.
 - `chi toolkit report [--days N]` — grade toolkit suggestions: the kit on mode would have run (the suggested kit when it would have applied it, else the default; an on-mode line's `did` says what it ran) against the tools the session called from that turn on (only that turn when the toolkit was chosen since), `call_tool` targets included, for both the chat and the raw-prompt loop. Each is *covers*, *short of a tool* (naming the tools), *wider than needed* (a narrower kit offered in the same ask would also have covered) or *ungradable* (calls it can't read back); then a per-kit tally with what on mode would have done. Includes archived sessions and caps the report at 14 days and 500 sessions. Reads `toolkit_suggestions.jsonl` (each ask logs every offered kit's rules, expanded against the called tools here); it never runs the model or changes a session. Local only; `--days` must be a positive whole number.
 
 - `chi bundle try PATH -p TEXT [options]` — install a bundle in a temporary, filtered sandbox, run one real model turn,
@@ -152,7 +153,9 @@ The loop for a bundle you're writing (the whole path: [bundle-authoring.md](bund
   then forces), `install` (each Installer warning, a `needs` one as warn, and each plugin or hook load failure at
   the source `file:line`; skipped while a placeholder sha is unfilled), `registered` (info: each command, tool,
   hook with its priority, init, toolkit, tool source and peer source), `hook-event` (warn: a `chi.on` event chi
-  never fires), `boundary` (warn: a `Samagotchi::` name outside "Stable for bundles"; a shipped bundle's listed
+  never fires), `settings` (warn: a `--set` the manifest's `settings:` rules out, as config.yml's `bundles:` is told), `api` (warn: a `ctx.*` / `chi.*` call or a keyword this chi's API lacks, read from the source with
+  Prism against the API's own classes, on a path that never runs too; written on a local `ctx` / `chi` itself, so a
+  `s = ctx.sessions` variable isn't followed; a name the plugin guards with `respond_to?` is left), `boundary` (warn: a `Samagotchi::` name outside "Stable for bundles"; a shipped bundle's listed
   exceptions aside) and `tests` (info: how to run them, or "no tests"). `--set KEY=VALUE` (repeatable, typed as
   `chi --set`) goes to `bundles: <name>:` in the sandbox's config.yml.
 
@@ -228,8 +231,10 @@ 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)
+infra_tools                  warn api plugin.rb:3: ctx.old_name isn't in chi 0.3.0's plugin API (fix: docs/plugins.md has the API)
 Chi Helper     0.2.0         up to date (launch file refreshed)
 workers                      2 live on 0.2.0: they keep it until restarted (chi sessions restart 2ea8c1f0 91b0d2aa); or they idle out after 30 min with nothing attached
+Bundles not from chi are left as they are: their author's next version, or chi bundle upgrade NAME, is what changes them
 Also shipped, not installed: dev (mcp, skills, source-links) (chi bundle install NAME)
 done
 ```
@@ -238,8 +243,10 @@ done
   newest release. It must be newer than the running chi; an equal or older
   version is refused.
 - `--json` writes the component rows as one JSON array on stdout. Each row has
-  `component`, `from`, `to`, `status`, `failed` and `kept` fields; `kept` is an
-  array of edited filenames. Install progress is written to stderr.
+  `component`, `from`, `to`, `status`, `failed`, `kept` and `level` fields;
+  `kept` is an array of edited filenames, and `level` is `warn` or `error` on a
+  re-check's row (below), `null` on the others. Install progress is written to
+  stderr.
 
 - **chi web update notices.** By default, chi web checks RubyGems about 30
   seconds after it starts and every 24 hours after that. Once a stable release
@@ -301,6 +308,30 @@ 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.
+- **Bundles not from chi** are never changed, but the chi the update leaves
+  checks what is installed of them (the plugin, hooks and rules as they are,
+  not their source, which may be gone) with `chi bundle check`'s own checks,
+  and each warning or error is a row under the bundle's name: `requires_chi`
+  ruling this chi out, a plugin or hook that no longer loads, a hook on an event
+  chi no longer fires, a `ctx`/`chi` call the API lacks, a reference to chi's
+  internals, a name chi now ships, or a hook or plugin edited since it was installed (it
+  doesn't load). What only an author can act on (shas, unlisted files, tests, a
+  missing `requires_chi`, its floor, `trust_level`) is left out, and so are
+  profiles. A clean bundle gets no row beyond its `skipped (not from chi)`.
+  - **They fail nothing:** an error row too has `failed: false` and leaves the exit
+    status 0, chi web's **Update** and `update.auto` done. A warning repeats on
+    every run until the bundle changes, and a second run still says `everything is up to date`.
+  - **Each runs in a child process**, with your config.yml `bundles: <name>:`
+    settings in a sandbox: its code runs, as in any session. One that exits or
+    doesn't answer in 30 s is an `error check` row of its own; the rest go on.
+  - **Under the new chi:** the check runs in the update handed over to, so the new
+    API is what it's held against. When that hasn't happened, a row says
+    `external bundles … not checked (…)` instead of an answer about the old
+    API: `--dry-run` with a newer gem to install (without one, a dry run checks,
+    against this chi), and a gem installed with no way to hand over (run `chi
+    update` again). A failed gem install checks against this chi, since it stays.
+  - `--no-bundles` (`update.bundles: false`) leaves these out too: no check, no row
+    but `bundles skipped`.
 - **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
@@ -377,10 +408,12 @@ flag also works as `--kebab-case VALUE`, e.g. `--server-host`, `--server-port`,
 `--read-truncate-at-bytes`; an on/off setting is `--[no-]kebab-case` with no value
 (`--context-status`, `--no-context-status`). `chi --help` lists them all.
 
-**Which loop runs.** There is no backend flag: the model's host decides. A host with
-`api: openai` in config.yml is driven through the OpenAI chat API (streamed; a remote
-provider via `url:` and `api_key_env:`); every other host gets chi's own raw-prompt loop. `/model` and `--model host:model` switch hosts, and
-the loop with them. See [Configuration](configuration.md) (`hosts:` and `api:`).
+**Which loop runs.** There is no backend flag: the model's host's `api:` decides. A host whose `api:` has
+a chat adapter runs `LLM::ChatLoop` — `api: openai` through `LLM::OpenAIChat` (`/v1/chat/completions`,
+streamed; a remote provider via `url:` and `api_key_env:`) or `api: anthropic` through
+`LLM::AnthropicMessages` (`/v1/messages`). Every other host (no `api:`, or `api: llama_cpp`) runs chi's own
+raw-prompt loop, `KernelLoop`, on llama.cpp's native `/completion`. `/model` and `--model host:model` switch
+hosts, and the loop with them. See [Configuration](configuration.md) (`hosts:` and `api:`).
 `--backend`, `SAMAGOTCHI_BACKEND` and a `backend:` key were removed (`backend:` warns
 as an unknown key).
 
@@ -461,6 +494,11 @@ and `--shared` are refused. Its first line says it is a scratch session.
 
 ### Sharing a session
 
+Two different things share a session: `session.shared` is about UIs — several
+terminals and the Web UI attached to one worker — while `chi share` invites
+other people, participants with a link of their own (see
+[Participants](#participants)).
+
 Plain `chi` runs the session in a background worker and attaches the terminal
 to it (`session.shared`, default `true`). A worker's session can have any number
 of UIs at once: the Web UI and attached terminals (`chi`, `--resume`,
@@ -1492,7 +1530,7 @@ chi --remote work sessions list
 
 SSH can forward a Unix socket as well, which is how claude-peer's pairing makes
 a Claude session on this laptop reachable from chi on that machine
-(`pair --inbox-socket <path>`): see [plugins.md](plugins.md), "chi on another
+(`pair --inbox-socket <path>`): see [bundles.md](bundles.md#the-claude-peer-bundle), "chi on another
 machine".
 
 How it works inside (`SessionAccess`, chi web's routes, where each check runs):

data/docs/configuration.md

@@ -127,7 +127,7 @@ own subsystems: `hosts:` (below), `models:` (see "Prompt profile" and
 `guardrails:` (see [Guardrails](guardrails.md)), `bundles:` (a bundle's
 settings for its hooks, see [Hooks: Settings](hooks.md#settings); a session's own
 `--set BUNDLE.KEY=VALUE`, for a key the bundle's manifest lists in `session_settings:`, lays over them, see
-[Per-session settings](plugins.md#per-session-settings); `--set KEY=VALUE` does the same for a few core keys,
+[Per-session settings](plugins.md#per-session-settings); a name no installed bundle has, or a key its manifest's `settings:` rules out, warns at a session's start; `--set KEY=VALUE` does the same for a few core keys,
 see "Per-session settings" below),
 `memories:` and `append_system_prompt:` (see "Appended prompt files"). Their entry names (host names, model ids, aliases) are yours to
 choose. The `memories:` list is the persistent baseline for preloaded memory entries —
@@ -149,7 +149,7 @@ or `chi web` restart.
 |---|---|---|
 | `default.model` | New session | Existing sessions keep their saved model; change one with `/model`. |
 | `default.input`, `no_default_input`, `no_interrupt` | Next CLI run | These set up that run's first prompt or turn limit. |
-| `default.max_tokens`, `max_tool_output_chars`, `read.*`, `execute.*` except `execute.description`, `image.*` | Next matching request or tool use | An operation already in progress keeps its resolved limits. |
+| `default.max_tokens`, `max_tool_output_chars`, `memory.read_max_chars`, `read.*`, `execute.*` except `execute.description`, `image.*` | Next matching request or tool use | An operation already in progress keeps its resolved limits. |
 | `server.host`, `server.port`, `hosts.*` | Worker start | Includes host addresses, APIs, declared models and host-level settings. The web model picker refreshes `hosts:` on file change; a running worker does not. |
 | `server.open_timeout`, `server.read_timeout`, `server.first_token_timeout` | Worker start | The worker's clients retain the timeouts set when they were built. |
 | `model_aliases` | Next model lookup | A session keeps its resolved model unless it is explicitly switched. |
@@ -166,9 +166,10 @@ or `chi web` restart.
 | `toolkit.kits`, `execute.description`, `llm_context.policy` | Worker start | These are held by the engine's toolkit or tool registry. |
 | `toolkit.suggest.mode`, `toolkit.suggest.threshold`, `toolkit.suggest.defer_turns`, `toolkit.suggest.defer_tokens` | Worker start | Suggestion settings are config-only and are resolved when the worker runs its audit or on-mode ask. |
 | `skip_agents_md` | Prompt rebuild | A running engine caches its built prompt; a new worker or `/model` rebuild uses the changed value. |
-| `context.*` except `context.every_seconds`, `llm_context.*` except `llm_context.policy`, `steer.cut_after`, `memory.index_warn_tokens`, `status.line`, `web.participants.*` | Next matching turn, display, poll or write | Readers resolve these settings when they perform that operation. Session-specific LLM context and thinking values remain saved in the session. A participant's grant keeps the expiry and cap it was issued with; `web.participants.*` is what the next invite gets, and the cap and queue of a grant from before caps. |
+| `context.*` except `context.every_seconds`, `llm_context.*` except `llm_context.policy`, `steer.cut_after`, `memory.index_warn_tokens`, `memory.entry_warn_tokens`, `status.line`, `web.participants.*` | Next matching turn, display, poll or write | Readers resolve these settings when they perform that operation. Session-specific LLM context and thinking values remain saved in the session. A participant's grant keeps the expiry and cap it was issued with; `web.participants.*` is what the next invite gets, and the cap and queue of a grant from before caps. |
 | `context.every_seconds` | Next context poll | The poller checks it for each source that has no explicit interval. |
 | `guardrails.*` | Next tool call or approval | Guardrail rules and disable lists are reloaded when the config file changes; rule settings take effect on that evaluation. `guardrails.parent_answers` is checked when a parent answers a question. |
+| `system_one.host`, `system_one.model`, `system_one.timeout_ms`, `system_one.runs`, `system_one.judgments` | Next tool call or approval | Each ask reads them. |
 | `hooks`, `bundles` | Worker start | Hooks, plugins and their bundle settings load with the engine. |
 | `recap.*` | Worker start | The engine builds its recap job at start, and again when it binds a session with its own `recap.enabled` or `recap.sentences` (`--set`, see "Per-session settings") and when `/recap on\|off\|default` changes the session's own value. |
 | `session.shared` | Next `chi` invocation | It selects attached-worker or in-process mode for that invocation. |
@@ -185,7 +186,7 @@ or `chi web` restart.
 
 ### Per-session settings
 
-A few core keys can be set for one session: `chi --set KEY=VALUE` (or `chi send --new --set KEY=VALUE`, or
+A few core keys can be set for one session (the registry entries marked `session: true`, `Config::Entry#session?`): `chi --set KEY=VALUE` (or `chi send --new --set KEY=VALUE`, or
 `POST /api/sessions` `settings`) at its creation, and `recap.enabled` later too with `/recap on`, `/recap off` or `/recap default`
 (at once; `default` removes the session's own value, see [Session recap](cli.md#session-recap)). The value is saved in the session file (`config_settings`), so a
 worker respawn, a continue and a fork keep it; a delegate child starts without it, on config.yml's. It goes first:
@@ -1451,7 +1452,7 @@ To skip loading AGENTS.md (all of the chain), set `skip_agents_md: true` at the
 
 Nested `AGENTS.md` files (in directories the session doesn't run in) are
 steered into the conversation on first touch by the `agents-md` bundle
-([The agents-md bundle](plugins.md#the-agents-md-bundle)); `skip_agents_md`
+([The agents-md bundle](bundles.md#the-agents-md-bundle)); `skip_agents_md`
 disables that steering too.
 
 ## Appended prompt files
@@ -1526,14 +1527,14 @@ toolkit:
   `undecided` for greetings or check-ins. Only a default-origin session with at least two described candidates is
   asked; chosen or inherited toolkits, delegate children, review sessions and participant turns are skipped. After
   `undecided`, later owner prompts may be asked again within both defer limits. The default is `off`. System 1's
-  host, model and timeout come from `guardrails.system_one.*`; the suggestion threshold and defer limits are its own
+  host, model and timeout come from `system_one.*`; the suggestion threshold and defer limits are its own
   settings below. Suggestions are
   kept in `toolkit_suggestions.jsonl`; `chi toolkit report` grades them against the session's tool calls. One ask
   runs at a time (a turn that comes while one still runs goes unasked, with an info line), and a kit that doesn't
   resolve (a missing base, a cycle) is left out of the candidates. A worker that exits waits about a second for a
   running ask, so a one-shot `-p --non-interactive` run may end before its suggestion is logged.
 - **On mode.** `toolkit.suggest.mode: on` asks the same question on the same eligible turns, but the turn waits for
-  the answer before it declares any tool, for at most `guardrails.system_one.timeout_ms` from the ask's start (it
+  the answer before it declares any tool, for at most `system_one.timeout_ms` from the ask's start (it
   starts right after the turn does, so plugin and MCP start-up hide most of it). A described kit picked with
   confidence at or above `toolkit.suggest.threshold` becomes the session's toolkit, saved with `toolkit_origin:
   suggested`, and the turn's first request declares it; the notice reads
@@ -1541,14 +1542,12 @@ toolkit:
   pick, `undecided`, no answer, a failing System 1, which warns once as `[samagotchi:toolkit]`) keeps the default
   kit. No answer in time or none at all says so in a warn notice, `toolkit: full (no suggestion: System 1 took over
   5000 ms) · /toolkit to change` (or `System 1 gave no answer`), and a timeout logs a `toolkit_suggest_timeout`
-  warning: a slow System 1 host wants a larger `guardrails.system_one.timeout_ms`. A Stop during the wait (or before it, even with the answer in) ends the turn before its first request, and
+  warning: a slow System 1 host wants a larger `system_one.timeout_ms`. A Stop during the wait (or before it, even with the answer in) ends the turn before its first request, and
   nothing switches. After an `undecided`, a later prompt within the defer limits may switch the session; that notice
   says `from this turn`, and that request re-reads the whole prompt (system prompt, tools and conversation, which
   the defer limits keep small) without `/toolkit`'s cache confirmation. `/toolkit` or `ctx.use_toolkit` marks the
   toolkit chosen, and nothing is suggested after that; a `/toolkit` sent during a turn runs after it and replaces
-  that turn's suggestion. When System 1's host is the model's own local server (the same `hosts:` name or server
-  root, as audit checks), on mode asks only on a session's first turn, never on the deferred path, and sends no
-  warm-up (one info line). Otherwise an idle worker for an eligible session sends one warm-up ask with the real
+  that turn's suggestion. An idle worker for an eligible session sends one warm-up ask with the real
   question and a stand-in prompt so the server has its prefix cached; its answer is dropped and never logged, and
   the first real ask stops a warm-up still running. Each answered ask's line in `toolkit_suggestions.jsonl` adds
   `did`: `suggested`, `default`, `defer`, `chosen` (the toolkit was no longer the default), `unavailable` (the
@@ -1591,7 +1590,7 @@ toolkit:
 - **A new web chat: 🧰.** The start page's 🧰 (beside ⚙; a bottom sheet on a phone) picks the new session's toolkit.
   **Auto**, checked by default, sends nothing: the session is on `toolkit.default` with `toolkit_origin: default`, so
   with `toolkit.suggest.mode: on` its first message may switch it to a suggested kit. Auto is listed only when that
-  can happen as far as chi web can tell (on mode, a `guardrails.system_one.host`, two described config kits); bundle
+  can happen as far as chi web can tell (on mode, a `system_one.host`, two described config kits); bundle
   and memory kits can add candidates it doesn't see. A kit picked is sent as `POST /api/sessions`'s `toolkit` and
   saved as `chosen`: no suggestion, the default kit included (its row says `default`); without Auto, the default's
   row is the one checked and sends nothing. The list holds the built-ins and config kits a new session can start
@@ -1640,6 +1639,21 @@ toolkit:
   changes what saved sessions on it send after an upgrade: the next request reads the prompt again once, as a
   tool's schema change does. So can an edit to `toolkit.kits`: a session's worker reads the kits once when it starts, so a running session keeps its
   tools and the edit reaches it at its next worker start (after an idle exit, `chi sessions restart`).
+- **Why a session is on its kit: `toolkit_origin`.** The session file records `default` (the configured kit),
+  `chosen` (a user-selected kit, `/toolkit` and `ctx.use_toolkit` included), `inherited` (a continue or a fork) or
+  `suggested` (`toolkit.suggest.mode: on` switched it). A file from before the field reads as `chosen`, so an old
+  default session is never newly suggested a kit; only a `default` session is ever suggested one. A delegate child
+  gets the kit its `delegate` call names (`toolkit:`, any kit the parent knows), else `toolkit.child`; a kit its worker
+  can't resolve declares every tool.
+- **Loads saved in the conversation.** A `find_tools` result on a chat host saves the tools its hit loads as
+  `loaded: ["list_sessions", "mcp_fs_read"]` on its `tool_response` entry (wire names: a built-in's, an MCP tool's
+  `mcp_<server>_<tool>`), whatever the host: a later turn on `api: anthropic` (after a `/model` switch, a resume) sends
+  the load as references, any other host ignores it. A plugin's `ctx.load_tools` leaves a system entry
+  `{"role": "system", "kind": "tool_change", "content": "[tools loaded: delegate (bundle)]", "tool_change": {"add":
+  ["delegate"], "by": "bundle"}}` after the turn's user message, only on a host that takes tool changes
+  (`api: anthropic`; [wire details](internals/anthropic.md#tool-changes-ctxload_tools)). It is never the system head,
+  counts as conversation, is hidden in the web and TUI histories and goes to no other wire. Either way the names stay
+  deferred for the session's life, across respawns, `--resume` and forks.
 
 ## LLM context: the forget layer
 
@@ -1762,7 +1776,7 @@ its own). The first target is a long session such as a day-long coordinator, whe
 
 `context.candidates.mode: audit` asks System 1 whether a session's work is about each candidate a bundle proposed
 (see [The judge](context.md#the-judge)); `on` also acts on the answer: attaches at `threshold`, a card from
-`offer_threshold` ([On mode](context.md#on-mode)). It uses `guardrails.system_one.host` and `.model`, but its own mode: System
+`offer_threshold` ([On mode](context.md#on-mode)). It uses `system_one.host` and `.model`, but its own mode: System
 1's `mode` (approvals) can stay `off`. Jev, the hosted judgment model, is served through OpenRouter
 (`/api/v1/systemone`), so OpenRouter can be the System 1 host:
 
@@ -1772,18 +1786,37 @@ hosts:
     url: https://openrouter.ai/api/v1
     api: openai
     api_key_env: OPENROUTER_API_KEY
-guardrails:
-  system_one:
-    host: openrouter
-    model: typesafe/jev-1.14
+system_one:
+  host: openrouter
+  model: typesafe/jev-1.14
 context:
   candidates:
     mode: audit
 ```
 
-A remote host is asked beside the turn. A System 1 host that is the model's own local server is asked after the
-turn's last request, and the turn-end warm-up follows them, re-warming the prefix they evicted (see
-[prompt caching](internals/prompt-caching.md)).
+The asks run beside the turn, on any host: they cost the session's cached prompt nothing on the model's own Splash
+either (see [prompt caching](internals/prompt-caching.md)).
+
+
+## Bundles' judgments
+
+A bundle can declare its own cheap System 1 questions ([Judgments](plugins.md#judgments-chijudgment-and-ctxjudge)). Each is off until
+you set its mode under its full name, `<bundle>.<name>`, in `system_one.judgments`:
+
+```yaml
+system_one:
+  host: splash
+  judgments:
+    check-in.progress:
+      mode: audit            # off (the default) | audit | on
+      host: openrouter       # optional, this judgment alone; else system_one.host
+      model: typesafe/jev-1.14  # optional, this judgment alone; else system_one.model, or on a host of its own that host's first model
+```
+
+A name no loaded bundle declares gets a notice at the session's first turn. Core's judgments (`approvals.*`, `context.*`, `guardrails.*`,
+`toolkit.*`) take no settings here and warn if named: `SystemOne::Record` and `Similar` don't look at the model, so a
+model swapped for approvals alone would inherit a clean record and could auto-allow.
+A bundle's judgments on a hosted host aren't under any cost cap: they stay out of the session's spend, as all of System 1's do.
 
 ## Opening files from chi web
 
@@ -2114,17 +2147,19 @@ Both are read when chi web starts (restart it to apply a change). What it does,
    it pushes the failed row's reason and stays quiet until a newer release (or you, with the button) tries again.
 3. **Restarts** (`update.restart: idle`). Stale workers first, only those whose session is idle and untouched for
    10 minutes (so nobody who is about to type loses their worker), and each worker still refuses by itself when
-   something holds it ([sessions](sessions.md)); the ones left are tried again for a day, then wait for their own
-   idle exit or the session's **Restart**. Then chi web itself, once no turn runs anywhere: it first runs the
+   something holds it ([sessions](sessions.md)). Then chi web itself, once no turn runs anywhere: it first runs the
    restart's own command with `--version` (20 s at most) and restarts only if the newest chi answers with the
    release's version; otherwise chi web stays up and the phone hears "chi X is installed; chi web didn't restart".
    The restart is the **Restart chi web** one: same port, same token, same Tailscale Serve handler, the open page's
    streams reconnect in a few seconds and a Reload toast follows. It doesn't wait for a page in front: the page isn't
    reloaded by itself, so a draft in the composer stays. A **Send** or **Allow** pressed in those few seconds fails
    with its error and leaves the text in the composer: press it again.
+   The workers left are tried again every 5 minutes, by the same rule and from the restarted chi web too, for a day from
+   the install; after that they wait for their own idle exit or the session's **Restart**. A newer release in that day
+   installs as usual and takes them over.
 4. **Says so.** The restarted chi web pushes "chi updated to X" ("chi web and 3 sessions restarted; 1 restarts when
-   idle. Kept your edits in 2 files."). With `update.restart: never` the push is "chi X is installed" and chi web and
-   the workers move over when you restart them (the page's toast offers it). The push needs the phone set up
+   idle. Kept your edits in 2 files."); the later restarts of those sessions push nothing more. With
+   `update.restart: never` the push is "chi X is installed" and chi web and the workers move over when you restart them (the page's toast offers it). The push needs the phone set up
    ([Phone notifications](#phone-notifications-web-push)); without it the page's toasts and
    `$XDG_STATE_HOME/samagotchi/update_check.json` (`auto`) are the record.
 
@@ -2190,12 +2225,13 @@ column says so, a `--kebab-name` flag. The maps (`hosts:`, `models:`,
 | `guardrails.small_models` | `auto` | | Which models get the `models: small` rules: `auto` (32B or less by the size in the name, an MoE's active size), a list of globs, or `[]`. config.yml only. See [Guardrails](guardrails.md#rules-for-some-models). |
 | `guardrails.parent_answers` | `soft` | | Which options a parent agent (`chi answer`) may pick on a session's question, by their effect: `hard` (a deny, a Stop, a plain answer), `standard` (+ Continue and other spending options), `soft` (+ "Allow once"); never a wider scope or an allow on chi's own config. An invalid value warns and is `hard`. A session's own `parent_answers` (`chi --parent-answers`, `/parent-answers`) may only tighten it. Replaces `guardrails.parent_approvals` and `turn.parent_continue`. config.yml only: no environment variable (a parent can still pick the config dir with `XDG_CONFIG_HOME`). A convention for an honest parent, not a security boundary. See [Guardrails](guardrails.md#answers-from-a-parent-agent). |
 | `guardrails.system_one.mode` | `off` | | System 1, the cheap judgment that answers an ask before the user sees it: `off` (the default), `audit` (judge every ask, log it, never decide), `on` (also allowed to allow a call once, behind the gates in [System 1](guardrails.md#system-1-experimental)). An unknown value warns and is `off`. Experimental. config.yml only. See [Guardrails](guardrails.md#system-1-experimental). |
-| `guardrails.system_one.host` | none | | The `hosts:` entry serving `/v1/systemone` (a local Splash, or the hosted Jev API); unset: no judgment. config.yml only. |
-| `guardrails.system_one.model` | none | | The judgment model; unset uses the host's first model, and a host that names none has no judgment. config.yml only. |
 | `guardrails.system_one.rules` | none | | The rule ids System 1 may answer for in `on` mode: `"git-push|git-rebase"` or a YAML list, parsed like `guardrails.small_models`. Nothing is auto-allowed while it is unset; the `chi-answer-piped`, `chi-answer-http` and `chi-broadcast` rules never are, however they are listed. config.yml only. |
 | `guardrails.system_one.threshold` | `0.8` | | The probability an auto-allow needs. config.yml only. |
 | `guardrails.system_one.min_record` | `5` | | How many clean records a rule needs before System 1 is trusted for it: labelled asks of that rule at the threshold the user allowed. config.yml only. |
-| `guardrails.system_one.timeout_ms` | `2000` | | Milliseconds one judgment may take; a slower one is no judgment and the ask goes to the user. config.yml only. |
+| `system_one.host` | none | | The `hosts:` entry serving `/v1/systemone` (a local Splash, or the hosted Jev API); unset: no judgment, by any use of System 1, so nothing auto-allows and every ask goes to the user. Moved from `guardrails.system_one.host`: while any of host, model and timeout_ms is still under `guardrails.system_one`, chi warns and nothing is judged. config.yml only. |
+| `system_one.model` | none | | The judgment model; unset uses the host's first model, and a host that names none has no judgment. Moved from `guardrails.system_one.model`. config.yml only. |
+| `system_one.timeout_ms` | `2000` | | Milliseconds one judgment may take; a slower one is no judgment and the ask goes to the user. Moved from `guardrails.system_one.timeout_ms`. config.yml only. |
+| `system_one.runs` | `on` | | Save each System 1 ask and what came of it, under the state dir, as long as sessions last (see [System 1's saved runs](system-one.md)); `off` stops saving. config.yml only. |
 | `log.file` | state dir | yes | See "Debug Log File". |
 | `log.disable` | `false` | yes | No file logging. |
 | `log.level` | `info` | yes | `debug`, `info`, `warn`, `error`. |
@@ -2218,13 +2254,13 @@ column says so, a `--kebab-name` flag. The maps (`hosts:`, `models:`,
 | `context.every_seconds` | `300` | | How often an attached context source's command runs when it has no `--every` (seconds, at least 30). See [Attached context](context.md). |
 | `context.wake` | `true` | yes | A source whose update says `wake: true` may start a turn in a live, idle session (one per source per 10 minutes, a peer source up to `context.peer_turns` in a row, within `session.max_wakes`); so may a session's pushed source's first push. `false`: updates wait as notes for the next turn. See [Waking](context.md#waking). |
 | `context.peer_turns` | `3` | yes | Wake turns in a row a peer agent's answers may start (a peer bundle's outbox source, such as `codex-outbox`), with no message typed in the web or a TUI in between (`chi send` doesn't count); within `session.max_wakes`. Then answers wait as notes, and the UIs hear it once. An answer whose summary ends its verdicts with `VERDICT OK` wakes once to close the round, counted toward `session.max_wakes` only. `0`: a peer source wakes like any other. See [Waking](context.md#waking). |
-| `context.candidates.mode` | `off` | | The candidate judge: `off` (the default: no conversation text goes to a System 1 host), `audit` (asks System 1 whether the session's work is about each proposed candidate and logs it in `context_candidates.jsonl`; attaches nothing), `on` (the same asks, acted on: attached at `threshold`, a card from `offer_threshold`; see [On mode](context.md#on-mode)). Its host and model are `guardrails.system_one.host` / `.model`. config.yml only. See [The judge](context.md#the-judge). |
+| `context.candidates.mode` | `off` | | The candidate judge: `off` (the default: no conversation text goes to a System 1 host), `audit` (asks System 1 whether the session's work is about each proposed candidate and logs it in `context_candidates.jsonl`; attaches nothing), `on` (the same asks, acted on: attached at `threshold`, a card from `offer_threshold`; see [On mode](context.md#on-mode)). Its host and model are `system_one.host` / `.model`. config.yml only. See [The judge](context.md#the-judge). |
 | `context.candidates.threshold` | `0.8` | | The probability at which the judge attaches a candidate in on mode (a judged line's `would: attach`). config.yml only. |
 | `context.candidates.offer_threshold` | `0.6` | | The probability from which on mode shows the candidate's card, once (`would: offer`, below `threshold`). config.yml only. |
 | `context.candidates.reask_after_turns` | `3` | | Owner prompts after a judged ask before the judge's one re-ask of that candidate. config.yml only. |
 | `toolkit.default` | `full` | | The toolkit a new session is stored on: the tools its prompts declare (`full`, `lean`, `child`, one of `toolkit.kits` or a bundle's). `chi --toolkit` picks one per session. See "Toolkits". |
 | `toolkit.child` | `full` | | A delegate child's toolkit, unless its `delegate` call names one (`toolkit:`). See "Toolkits". |
-| `toolkit.suggest.mode` | `off` | | `audit` asks System 1 for a toolkit suggestion without changing the session; `on` waits for it (up to `guardrails.system_one.timeout_ms`) on an eligible turn and starts the session on a confidently suggested kit (Toolkits, On mode). The System 1 host, model and timeout come from `guardrails.system_one.*`. config.yml only. |
+| `toolkit.suggest.mode` | `off` | | `audit` asks System 1 for a toolkit suggestion without changing the session; `on` waits for it (up to `system_one.timeout_ms`) on an eligible turn and starts the session on a confidently suggested kit (Toolkits, On mode). The System 1 host, model and timeout come from `system_one.*`. config.yml only. |
 | `toolkit.suggest.threshold` | `0.5` | | Minimum confidence for a non-default toolkit suggestion. config.yml only. |
 | `toolkit.suggest.defer_turns` | `3` | | Maximum owner-prompt number for another ask after `undecided` (the owner's own prompts: not steers, notes, reminders or `!` command output). config.yml only. |
 | `toolkit.suggest.defer_tokens` | `5000` | | Maximum estimated conversation size for another ask after `undecided` (characters / 4). config.yml only. |
@@ -2235,7 +2271,9 @@ column says so, a `--kebab-name` flag. The maps (`hosts:`, `models:`,
 | `hosts.<name>.models.<id>.served` | none | | The models the host may answer that id with (exact ids, any case), or `any`: no served-model warning for those. See "Models a host serves but doesn't list". |
 | `hosts.<name>.models.<id>.price` | none | | The model's price on that host, USD per 1M tokens: `input`, `output`, optional `cache_read` and `cache_write`. Estimates the cost a provider doesn't report. See "Prices". |
 | `hosts.<name>.remote` | by address | | `true`/`false`: treat the host as a remote provider or a local server. See "Remote or local". |
-| `max_tool_output_chars` | `10000` | yes | Characters of each tool output kept in the conversation (both loops). A longer one is cut: an `execute` result keeps its first and last lines with a gap line between them and is saved whole in the session's folder (`sessions/<id>/tool_output/`; the gap line names the file, and the model reads it there instead of running the command again); any other tool's keeps its head and ends with `[cut: N of M chars; read it in parts]`. See [Tool output guardrails](internals/tool-guardrails.md#the-runners-cut-max_tool_output_chars). A top-level key (see below). |
+| `memory.entry_warn_tokens` | `5000` | yes | The tokens one memory may hold (every read of it pays them; about 20K characters at the default `context.chars_per_token`) before a `memory_write`, `write` or `edit` that takes it over gets a note, once per crossing, asking the model to tighten it; `0`: no note. A memory that did not exist counts as 0 tokens. Not for a description-only write, a remove, `index`, a model overlay or a `model_notes_*` memory. Independent of `memory.index_warn_tokens`. See [Memory](memory.md). |
+| `memory.read_max_chars` | `0` | yes | The most characters one `memory_read` result holds. `0`: no fixed cap, a memory is read whole (`max_tool_output_chars` does not apply to `memory_read`, in any form: one name, a comma list, a blank name). A positive value cuts a longer result and ends it with `[cut: N of M chars; the rest is in the memory's .md file in <dir>: read it with start_line]`. `memory:` is its own section. See [Memory](memory.md). |
+| `max_tool_output_chars` | `10000` | yes | Characters of each tool output kept in the conversation (both loops). A longer one is cut: an `execute` result keeps its first and last lines with a gap line between them and is saved whole in the session's folder (`sessions/<id>/tool_output/`; the gap line names the file, and the model reads it there instead of running the command again); any other tool's keeps its head and ends with `[cut: N of M chars; read it in parts]`. `memory_read` is the exception: `memory.read_max_chars` caps it. See [Tool output guardrails](internals/tool-output-limits.md#the-runners-cut-max_tool_output_chars). A top-level key (see below). |
 | `cache.warmup` | `auto` | | `auto`: after a turn, send the next turn's prompt (up to the next message) to a local llama.cpp host on the native loop, so the next turn prefills only its message; never a remote or `api: openai` host. `off`: never. See [prompt caching](internals/prompt-caching.md#the-turn-end-warm-up). |
 | `cache.ttl` | `5m` | | How long Anthropic keeps the prompt-cache breakpoints of a Claude model on a remote host: `5m` (Anthropic's default) or `1h`. A 1h cache write costs 2× the input price (5m: 1.25×), a read the same 0.1×. See "Remote or local". |
 | `cache.key` | `off` | | `session`: send the session id as `prompt_cache_key` to OpenAI's API and OpenRouter, which route and cache by it; no other host gets it. `off`: none. |

data/docs/context.md

@@ -126,10 +126,10 @@ pbpaste | chi context push clip --project
 ```
 
 A Claude Code session can be a pushed source too: the
-[claude-peer bundle](plugins.md#the-claude-peer-bundle)'s `pair` script attaches
+[claude-peer bundle](bundles.md#the-claude-peer-bundle)'s `pair` script attaches
 `claude-inbox` (Claude's inbox socket as the hint) and `claude-outbox`, where
 Claude pushes its answers as JSON with `wake: true`. The
-[codex-peer bundle](plugins.md#the-codex-peer-bundle)'s does the same for a
+[codex-peer bundle](bundles.md#the-codex-peer-bundle)'s does the same for a
 Codex session: `codex-inbox` (Codex's thread id as the hint) and
 `codex-outbox`.
 
@@ -273,7 +273,7 @@ back the same way, its note plain, and pauses wakes too.
 
 ### Peer sources: the peer loop
 
-The claude-peer and codex-peer bundles ([Plugins](plugins.md)) pair the
+The claude-peer and codex-peer bundles ([Bundles](bundles.md#the-claude-peer-bundle)) pair the
 session with a Claude Code or Codex session; the peer's answers come back as
 the `claude-outbox` / `codex-outbox` pushed source (the peer's `scripts/pair`
 attaches it). The bundle declares that source a peer's (`chi.peer_source`,
@@ -358,7 +358,7 @@ An archived session that nobody continued takes pushes as before.
 
 ### Peers and a continue
 
-A peer's pairing ([claude-peer, codex-peer](plugins.md#the-claude-peer-bundle):
+A peer's pairing ([claude-peer, codex-peer](bundles.md#the-claude-peer-bundle):
 `<peer>-inbox` and `<peer>-outbox`, both pushed) stays with the old session,
 and the peer pairs again with the new one. The continue keeps what stayed in
 the new session (`left.json` beside its sources: each name, its last pushed
@@ -432,8 +432,8 @@ about each proposed candidate — "Is this session's work about the
 candidate?" — and logs the answer, so you can see how it would do before
 anything depends on it; `audit` attaches nothing. With `on` the answer acts
 ([On mode](#on-mode)). The default is `off`: no conversation text goes to a System 1 host unless you
-turn this on, whatever `guardrails.system_one` says. The host and model are
-`guardrails.system_one.host` / `.model` (Jev through OpenRouter: see
+turn this on, whatever `guardrails.system_one.mode` says. The host and model are
+`system_one.host` / `.model` (Jev through OpenRouter: see
 [The candidate judge](configuration.md#the-candidate-judge)).
 
 ```yaml
@@ -462,11 +462,8 @@ What it asks, and when:
   (a first "hi" doesn't count against it).
 - **After a judged ask:** one re-ask once `reask_after_turns` more prompts of
   yours came, with the conversation grown; then it is done.
-- **Where it runs:** on a remote System 1 host (Jev) beside your turn; on the
-  model's own local server (System 1 on the same Splash) after your turn
-  ends, so it never competes with the turn's prefill; the turn-end warm-up
-  waits for those asks and restores the cached prompt they pushed out. One
-  session's asks run one batch at a time.
+- **Where it runs:** beside your turn, on any System 1 host. One session's
+  asks run one batch at a time.
 
 ### On mode
 
@@ -503,7 +500,10 @@ none at the thresholds then, with your prompts cut to 200 characters),
 `p`), `attached` / `declined` with `by: "command"` (`/context attach|decline`,
 the card's buttons), `attached` / `declined` / `detached` with `by: "user"`
 (what you did otherwise, seen at your next turn's start; removing a source
-declines it) and `withdrawn`.
+declines it) and `withdrawn`. `chi sessions delete` drops a session's lines
+from this log too, so the prompts it cut to 200 characters go with it; the
+log's own size cap (5 MB, keeping the newest half) is what ages everything
+else.
 
 `chi context report [--days N]` counts it, with no prompts in the output
 (this machine only):

data/docs/guardrails.md

@@ -11,7 +11,10 @@ are offered.
 Who votes, in order:
 
 1. `before_tool_call` hooks (Ruby; see [Hooks](hooks.md#guardrails-from-a-hook)).
-2. Core checks: a required guardrail that failed to load, then protected paths, then (a delegate child only)
+2. Core checks (`GuardrailWiring#checks`): a required guardrail that failed to load, then (a participant's turn only)
+   [the review boundary](#a-participants-review-boundary) or, for a pair turn,
+   [the pair boundary](#a-participants-pair-boundary), then protected paths, then (a `chi scratch` session only)
+   writes to the memories folder (rule `scratch-session`), then (a delegate child only)
    [the child boundary](#a-delegate-childs-boundary).
 3. YAML rules: `config.yml`'s `guardrails:` section, then installed bundles' rule files (by bundle name).
 
@@ -283,8 +286,9 @@ Built in, for `write`, `edit` and `memory_write` (symlinks resolved; see
 [How paths resolve](#how-paths-resolve)):
 
 - deny: the approval store's dir, installed bundles (`memories/.bundles/`),
-  and [attached context](context.md) sources (`<state dir>/context/`: a
-  source's command runs later, outside the gate; `chi context` changes them);
+  [attached context](context.md) sources (`<state dir>/context/`: a
+  source's command runs later, outside the gate; `chi context` changes them)
+  and [System 1's saved runs](system-one.md) (`<state dir>/system_one/`);
 - ask (once or for the session): `config.yml`, `home.json` (the [chi home](configuration.md#the-chi-home): the Ruby every chi launch boots), the chi shim (`$XDG_STATE_HOME/samagotchi/bin/chi`, the `chi` every tool runs: `chi-shim`) and the plain hooks dir.
 
 `execute` can still reach them; the guardrails bundle asks about shell
@@ -745,7 +749,7 @@ repo is in count as outside.
 
 `touches: chi_dirs` (shell tools) matches a command that names a path in chi's
 own folders: the config folder (`config.yml`, `memories/`), the hooks folder,
-the approval store, installed bundles (`memories/.bundles`), the session repo's
+the approval store, attached context, System 1's saved runs, installed bundles (`memories/.bundles`), the session repo's
 git hooks (`core.hooksPath` honoured) or any `.git/hooks` (a submodule's `.git/modules/<name>/hooks` too)
 outside a tmp folder.
 Each word is read as a path against the folder the command is in by then
@@ -1045,25 +1049,32 @@ reaching them — see [Answering for the user](#answering-for-the-user-on-mode).
 `Samagotchi::SystemOne` (lib/samagotchi/system_one/) speaks the TypeSafe
 "System One" judgment API: `POST <host>/v1/systemone` with
 `{model, state, questions}` and answers of type `noul` (a probability),
-`choice` or `score`. The host is a `hosts:` entry with `api: openai` — a
+`choice` or `score`. A `score` answer's number is not a level: it is the
+probability-weighted level index (Σ index × its probability), so a two-level
+question's score is exactly the probability of its second level. The response
+also sends `legend` (level index => name) and `probabilities` per index; chi
+keeps the score as sent and reads the level with the most probability as
+`answer.level`. A score that isn't a number, or is past the last level, is no
+answer. The host is a `hosts:` entry with `api: openai` — a
 local Splash server, or the hosted Jev API — and its key is that host's own
 `api_key_env:`.
 
 ```yaml
+system_one:                  # what every use of System 1 shares
+  host: splash               # the hosts: entry serving /v1/systemone
+  model: Qwen3.8-Flash-Next-GSQ-RCO-GGUF:Q2_0   # else the host's first model
+  timeout_ms: 2000           # a slower judgment is no judgment
 guardrails:
-  system_one:
+  system_one:                # approvals' own
     mode: off                # off (default) | audit (judge, log, never decide) | on
-    host: splash             # the hosts: entry serving /v1/systemone
-    model: Qwen3.8-Flash-Next-GSQ-RCO-GGUF:Q2_0   # else the host's first model
     rules: [git-push, git-rebase]                  # the rule ids it may answer for
     threshold: 0.8           # the probability an auto-allow needs
     min_record: 5            # clean records a rule needs before it is trusted
-    timeout_ms: 2000         # a slower judgment is no judgment
 ```
 
-`SystemOne::Client.from_config(host_registry: ...)` reads these on every
+`SystemOne::Client.from_config(host_registry:, mode:)` reads these on every
 call, so a config.yml change takes effect on the next ask. `mode: off` (the
-default) or no `host` means there is no client at all. Anything else is no
+default) or no `system_one.host` means there is no client at all. Anything else is no
 judgment and one `Log.warn(:guardrails, "system_one_failed", …)`: an
 unreachable host, a host that isn't `api: openai`, a status other than 200,
 a body that isn't JSON, a question with no answer, a request longer than
@@ -1078,12 +1089,8 @@ not `guardrails.system_one.mode`. Audit never changes the session's toolkit;
 on mode's turn waits for the answer (at most `timeout_ms`, cut by a Stop)
 and may start the session on the suggested kit (configuration.md, Toolkits).
 Its warnings use the `toolkit` tag and its records are written to
-`toolkit_suggestions.jsonl` beside the guardrail logs. To avoid competing
-with the session's model, audit skips (one info line) when
-the System 1 host is the model's local host: the same `hosts:` name, or
-another entry for the same server root (scheme, host and port). There is no
-reliable single-slot signal, so this host-identity check is the available
-contention guard. The session's own checks come first; the kits and the
+`toolkit_suggestions.jsonl` beside the guardrail logs. The session's own
+checks come first; the kits and the
 suggestion log are read only for a session that can be asked, the log only
 after an earlier `undecided`.
 
@@ -1093,8 +1100,7 @@ questions per proposed candidate, "Is this session's work about the
 candidate?" and "Has the user stated a task yet?", on the same host and
 model, gated by its own mode alone. It logs to `context_candidates.jsonl`
 with the `context` tag; in on mode `ContextCandidateChoice` acts on the
-answer (attach, card, or nothing). Unlike the toolkit's audit it doesn't skip a shared
-local host: it asks after the turn ends there. Both side judgments run
+answer (attach, card, or nothing). Both side judgments run
 through `SideJudgments` (one ask in flight per kind, a failure is one warn,
 shutdown waits up to a second).
 
@@ -1118,7 +1124,8 @@ offers no examples. A participant's turn (review or pair) is never judged:
 there is no user there to ask, and its asks go to the owner. The judgment runs before the card appears, so an ask is
 slower by up to `timeout_ms` (2000 ms by default).
 
-Each judgment is a line in `judgments.jsonl`, beside `approvals.json` in
+Each ask is also saved whole, with what the user answered, as a [run](system-one.md); the line's `id` is the
+run's. Each judgment is a line in `judgments.jsonl`, beside `approvals.json` in
 `$XDG_STATE_HOME/samagotchi/guardrails/` (`SystemOne::Log`): 0600, appended
 under an exclusive `flock` (several workers write it), and rewritten —
 keeping the newest half of its lines — once it passes 5 MB. A line is never