samagotchi 0.140.0 → 0.142.0

data/docs/configuration.md

@@ -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:
@@ -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,7 +1542,7 @@ 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
@@ -1591,7 +1592,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 +1641,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 +1778,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,10 +1788,9 @@ 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
@@ -1785,6 +1800,27 @@ A remote host is asked beside the turn. A System 1 host that is the model's own
 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)).
 
+
+## 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
 
 In `chi web`, a file tool's row (read, edit, write) and the lines of its diff are refs to that file. They look like
@@ -2190,12 +2226,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 +2255,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 +2272,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

@@ -89,8 +89,8 @@ web) without touching the other sessions.
 ## The commands
 
 ```
-chi context add NAME (--cmd CMD | --push) [--every SECONDS] [--why TEXT] [--hint TEXT] TARGET
-chi context add URL [--why TEXT] [--hint TEXT] TARGET   a URL an installed bundle's provider knows
+chi context add NAME (--cmd CMD | --push) [--every SECONDS] [--why TEXT] [--hint TEXT] [--[no-]movable] TARGET
+chi context add URL [--why TEXT] [--hint TEXT] [--[no-]movable] TARGET   a URL an installed bundle's provider knows
 chi context push NAME [-m TEXT] [TARGET]         new text for a --push source (stdin without -m)
 chi context ls [TARGET] [--format json]
 chi context show NAME [--json] [TARGET]
@@ -313,6 +313,68 @@ lower.) Every other source keeps the line above. `context.peer_turns: 0` turns
 the loop off: a peer source then wakes like any other. `context_read` names a
 peer source in its header (`Peer: your peer agent Codex's answers …`).
 
+## Movable context
+
+A session's own sources go with it to the next session of its work: the next
+link of a [chain](sessions.md#session-chains) (`chi send --new --continues`,
+the web's Continue →) and a bundle's fork
+([`ctx.sessions.fork`](plugins.md#other-sessions-ctxsessions)). A topic switch goes
+to a fresh session with its own context, never through a continue.
+
+Each source says whether it moves:
+
+- **A command source moves** (`--cmd`, a URL's source): chi runs its command
+  itself, in the new session too.
+- **A pushed source stays** (`--push`): its writer (`pbpaste | chi context
+  push notes <id>`, a peer agent) holds the old session's id.
+- `chi context add … --movable` / `--no-movable` (either kind) says it
+  outright: `--movable` on a pushed source means its writer finds the new id
+  itself. A bundle passes `movable:` to `ctx.context.attach`.
+
+What moves is copied before the new session's worker starts: the source, its
+last text (so its first note quotes it without waiting for a fetch, and its
+interval holds), and the session's choices: every removed (declined) and
+muted marker. Candidates don't move. The new link gets the usual *Attached*
+note for each source; a fork starts where its seed's notes left off, so a
+source that changed since gets an *Updated* note. A second chi note, after
+the chain's, names what moved and what stayed:
+
+> Context moved with this session: pr-412, ci. Left with 3f2a9c1e: notes (pushed).
+
+`chi send --new --continues` and the web's Continue toast say the same in a
+few words, and `chi context ls` marks a session's source that stays
+(`· stays`; `--format json` has the derived `movable`). Project sources are
+shared already, and a review fork (`chi review --from`) and a delegate take none.
+
+A push into a continued session is refused, nothing written, with the next
+link's id (`chi context push` exits 1; chi web answers 410
+`context_continued`):
+
+```
+chi context push: 3f2a9c1e was continued as 7b1d…: notes stays with the session it was attached to; attach it to 7b1d… (or pair again with 7b1d…) and push there
+```
+
+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):
+`<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
+hint, the old id; `ctx.context.left_behind`), and the new session's worker
+posts the peer one `moved` message to the inbox left behind, once:
+`chi <old> · moved · continued as <new id>`. The peer's chi-peer skill pairs
+again with the new id, the same way it paired before. Without an inbox (an
+outbox-only pairing through a remote), or when the message didn't arrive, the
+peer's next push to the old id is refused with the new id, and the skill pairs
+again and pushes there. The second note says which, not whether it worked:
+
+> Left with 3f2a9c1e: claude-inbox, claude-outbox (Claude's pairing: chi asks Claude to pair again with this session).
+
+or, for an outbox alone, `codex-outbox (Codex pairs again when it next
+answers)`. A fork takes no pairing and posts nothing.
+
 ## Candidates
 
 A bundle can **propose** a source instead of attaching it
@@ -359,8 +421,8 @@ review session refuses them); an unknown name, or one attached or declined
 already, is an error that says so. They are what the judge's card's buttons
 run (see [On mode](#on-mode)).
 
-Forks and continues start without candidates: the bundle proposes again in
-the new session.
+Forks and continues take no candidates: the bundle proposes again in the
+new session (see [Movable context](#movable-context) for the sources).
 
 ### The judge
 
@@ -370,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

data/docs/guardrails.md

@@ -283,8 +283,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 +746,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 +1046,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
@@ -1118,7 +1126,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

data/docs/hooks.md

@@ -62,7 +62,7 @@ The plugin class must respond to `#call(event)` — duck-typed, no base class re
 | `:generation_progress` | While the response streams, in batches (see [Watching the stream](#watching-the-stream)) | `{ type: :generation_progress, iteration: N, thinking: "..." (new since the last fire), text: "..." (new visible text), thinking_chars: N, text_chars: N (this generation so far), elapsed_ms: N, restarted: true (only on the first fire after a dropped stream was asked again) }` |
 | `:before_tool_call` | Before tool dispatch (and before `tool_call_started`) | `{ type: :before_tool_call, iteration: N, call: {...}, params: "...", guardrail: Verdict, context: {...}, targets: {...}, blocked: false, block_reason: nil }` |
 | `:question_asked` | A question of the model's own (`ask_user_question`) or an approval of its tool call is about to open, on the turn's thread (not a hook's or plugin's `ask_user`, a relayed delegate approval, the step-limit question, a `--non-interactive` run or a stored approval: none of those fire it) | `{ type: :question_asked, kind: "question" \| "approval", text: "..." (the reply that asks, as the asking slot shows it: no thoughts, no tool-call markup), question: {...} (the question's fields, frozen: question/options/header…, an approval's approval: facts too; no id yet), refs: (see [Refs on a question](#refs-on-a-question-display-only)) }` |
-| `:after_tool_call` | After tool execution | `{ type: :after_tool_call, iteration: N, tool: "read", output: "..." (the text the model gets: capped at max_tool_output_chars; a cut one has a [cut: …] line, at its end, or for an execute result between its head and its tail, the whole output saved in the session's tool_output/ folder), status: "ok" \| "error" \| "blocked" \| "stopped", call: {...} (the call that ran, as the gate left it), elapsed_ms: N (the tool's own run, without an approval wait; nil for a denied call), result: "..." (the tool's own text: no "[read]" lead, no "ran as:" line, never cut) }`; `stopped` is a `task_wait` the turn's Stop ended (the task runs on) or whose task was stopped. Match on `result:`, not `output:`: it is what the tool said (`Error: command timed out after 120s` for an execute killed at its limit in kill mode, `Samagotchi::Tools::Execute::TIMEOUT_PREFIX`; `Still running at the 120s limit: …` for one handed over as a task, `Samagotchi::Tools::Execute::HANDED_OVER`) |
+| `:after_tool_call` | After tool execution | `{ type: :after_tool_call, iteration: N, tool: "read", output: "..." (the text the model gets: capped at max_tool_output_chars (a memory_read's cap is memory.read_max_chars, 0: none); a cut one has a [cut: …] line, at its end, or for an execute result between its head and its tail, the whole output saved in the session's tool_output/ folder), status: "ok" \| "error" \| "blocked" \| "stopped", call: {...} (the call that ran, as the gate left it), elapsed_ms: N (the tool's own run, without an approval wait; nil for a denied call), result: "..." (the tool's own text: no "[read]" lead, no "ran as:" line, never cut) }`; `stopped` is a `task_wait` the turn's Stop ended (the task runs on) or whose task was stopped. Match on `result:`, not `output:`: it is what the tool said (`Error: command timed out after 120s` for an execute killed at its limit in kill mode, `Samagotchi::Tools::Execute::TIMEOUT_PREFIX`; `Still running at the 120s limit: …` for one handed over as a task, `Samagotchi::Tools::Execute::HANDED_OVER`) |
 | `:session_end` | After each turn `:after_turn` fires for, after it (turn-level lifecycle) | `{ type: :session_end, session_id: "..." }` |
 
 Every event also carries the hook runtime (next section): `hook:` (the label
@@ -76,12 +76,14 @@ cheap).
 
 ## Participants' turns
 
-A [participant's](internals/participants.md#turns) review turn fires the same hooks, and every event of it carries
-`author: "p:<id>"` (the owner's carry no `author:` key, as before); a plugin reads the same as `ctx.turn_author`
-(nil for the owner's turns and between turns). **A hook runs with the owner's power whatever the author**: it may
-read, write and run what the owner's chi may, and `notify`, `ask_user` and `steer` reach the owner. A bundle that
-acts on a turn's text (a prompt rewrite, a fetch of what it names) should check `author:` first: the text may be a
-participant's. The review boundary checks a tool call after the hooks, on the call they leave.
+A [participant's](internals/participants.md#turns) turn — a review turn or a pair turn — fires the same hooks, and
+every event of it carries `author: "p:<id>"` (the owner's carry no `author:` key, as before); a plugin reads the
+same as `ctx.turn_author` (nil for the owner's turns and between turns). The mode does not change that: `author:`
+comes from who wrote the turn, not from `ParticipantMode`. **A hook runs with the owner's power whatever the
+author**: it may read, write and run what the owner's chi may, and `notify`, `ask_user` and `steer` reach the
+owner. A bundle that acts on a turn's text (a prompt rewrite, a fetch of what it names) should check `author:`
+first: the text may be a participant's. The participant's boundary (the review or pair one) checks a tool call
+after the hooks, on the call they leave.
 
 ## What a hook can do: the runtime