samagotchi 0.139.1 → 0.141.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 1ef79d43ec1d5fc441ca8892ceb240a42fca4629295e71debc495df44b5efde8
-  data.tar.gz: 39b1d809ff216fcd1a1af146dc7858b45e80f94a8018e00841839573b753be0d
+  metadata.gz: 4d6c521351f86a38243b9757eff32df1745e88d2be1158684ba029e85f16b9e1
+  data.tar.gz: 99c0f5f7b2356a58a36f4d38330a17d95decdc64446e26ee55f38d3b5794b3ba
 SHA512:
-  metadata.gz: 228b7f233e3d6fd752ba0dbad22f4fed1e27910eb97a37190ec9172db94d1369dffe13f64389b3e1f77914bc845d2625c273c7569594fe76ffc4aa18edf749f6
-  data.tar.gz: f6439358124c6785a2ab54947e97928f725a817146bcd24e2263734e48bd2718b693e6573d4253fc64bbfe660a390125720f6a71662f31400bb7fbd39a4dd9da
+  metadata.gz: 7b735c84997b1a4c035c6d3c0f7baf6035f4f29bd400e6bce116ecaf5fe06c0d2b304fe19a8447a523833bf71cfe9829193d6c8fcb136f42e7a5f900e4f7a30f
+  data.tar.gz: 0705cdf1abb1716a40f38c396b020442b44c2d985911f4d945362f0d2a83bde088c0699f660c8dce791edd666b83529e7d991e642703ceb023558caaa128c394

data/CHANGELOG.md

@@ -7,6 +7,59 @@ and commands may change between minor versions. How releases are made:
 [docs/releasing.md](docs/releasing.md).
 ## [Unreleased]
 
+## [0.141.0] - 2026-10-31
+
+### Added
+
+- Movable context: a continue (`chi send --new --continues`, the web's Continue →) and a bundle's fork take the
+  session's attached context with them, with a note in the new session naming what moved and what stayed. A command
+  source moves, a pushed one stays; `chi context add --movable / --no-movable` (and `ctx.context.attach(movable:)`)
+  say it outright, and `chi context ls` marks one that stays. A push into a continued session is refused with the
+  next link's id. See docs/context.md (Movable context).
+- A paired Claude Code or Codex session follows a continue: the new session asks it once to pair again with the new
+  id (a `moved` message to the inbox the old session had), and a reply pushed to the old id is refused with the new
+  one, so the peer pairs again then (claude-peer 0.4.6, codex-peer 0.3.5: install the chi-peer skill again with
+  `/claude install-skill` or `/codex install-skill`). Bundles get `ctx.continues` and `ctx.context.left_behind`. See
+  docs/context.md (Peers and a continue).
+
+Update with `chi update` (claude-peer 0.4.6, codex-peer 0.3.5).
+
+## [0.140.0] - 2026-10-31
+
+### Added
+
+- Candidates for attached context: a bundle proposes a source (`ctx.context.propose`, `candidates`, `withdraw`),
+  and chi attaches it when the session's owner mentions it; `chi context ls` and `/context` list them with their
+  state (proposed, attached, declined). See docs/context.md (Candidates).
+- The candidate judge, audit only and opt-in (`context.candidates.mode: audit`; off by default): System 1 is asked
+  whether the session's work is about each proposed candidate, and the answers go to `context_candidates.jsonl`;
+  nothing is attached. `chi context report [--days N]` counts them against what you attached or declined. Jev
+  through OpenRouter works as the System 1 host. See docs/context.md (The judge).
+- The candidate judge's on mode (`context.candidates.mode: on`): a candidate judged at `threshold` (0.8) or above
+  is attached quietly (its note comes before your next turn, never mid-turn; removing it declines it), one from
+  `offer_threshold` (0.6) gets a card once (Attach / Not here), lower ones stay proposed. `/context attach NAME` and
+  `/context decline NAME` choose a candidate yourself; `chi context report` counts the judge's attaches you removed
+  later. See docs/context.md (On mode).
+
+### Changed
+
+- github-pr no longer attaches the branch's PR by itself: mention it (#N, the branch, the URL), or set
+  `auto_attach: attach` for the old behaviour. It proposes the PR as a candidate when the worker starts (a delegate
+  child too), and a prompt of yours that names it attaches it before that turn runs, its note in that turn.
+  `auto_attach: offer` (the card with Attach and Not here, `/pr-attach`, `/pr-decline`) is gone and reads as
+  `propose`, as does an unknown value. (github-pr 0.6.0)
+
+### Fixed
+
+- chi web's update check no longer holds up the page, the API or the automatic install while it fetches from
+  RubyGems (~10 s): reading and saving the auto-update record take their own lock.
+- Stopping chi web while the automatic update's preflight runs waits for it (up to 25 s) instead of abandoning it,
+  and a preflight that ends after the stop no longer restarts chi web.
+- An automatic install with `update.restart: idle` no longer offers the "installed" toast's Restart buttons (a
+  failed run, `restart: never` or a manual install still do).
+
+Update with `chi update` (the dev profile 0.7.4).
+
 ## [0.139.1] - 2026-10-31
 
 ### Fixed
@@ -5326,7 +5379,9 @@ and long-lived sessions.
 - A macOS desktop helper (`chi desktop install`): a "Send to chi" Service and a
   hotkey panel that send selected text or the clipboard to your sessions.
 
-[Unreleased]: https://github.com/dm1try/samagotchi/compare/v0.139.1...HEAD
+[Unreleased]: https://github.com/dm1try/samagotchi/compare/v0.141.0...HEAD
+[0.141.0]: https://github.com/dm1try/samagotchi/compare/v0.140.0...v0.141.0
+[0.140.0]: https://github.com/dm1try/samagotchi/compare/v0.139.1...v0.140.0
 [0.139.1]: https://github.com/dm1try/samagotchi/compare/v0.139.0...v0.139.1
 [0.139.0]: https://github.com/dm1try/samagotchi/compare/v0.138.0...v0.139.0
 [0.138.0]: https://github.com/dm1try/samagotchi/compare/v0.137.0...v0.138.0

data/README.md

@@ -176,7 +176,8 @@ stopped on, which the agent answers with `chi answer`. See
 `chi context` attaches outside text that keeps changing to a session: a
 command chi runs every few minutes, text you push, or a URL. With the
 `github-pr` bundle (in `dev`; needs `gh`) a session on a branch with an open
-pull request gets it attached by itself. The agent gets a short note when it
+pull request gets it proposed, and attached once you mention it (#N, the branch
+or its URL). The agent gets a short note when it
 changes (a summary of what changed, never the comments' words) and reads the
 text with `context_read` when your request is about it; a review requesting
 changes, red checks or a merge can start a turn in a live, idle session that

data/docs/architecture.md

@@ -606,8 +606,9 @@ reload in a toast, since an open tab keeps its old JS across a `chi web` upgrade
 `installed`, the newest chi on this machine (`InstalledVersions`: the highest `samagotchi-<v>.gemspec`
 in RubyGems' specification dirs, or a checkout's `version.rb` on disk; looked at again on each full
 probe, every 10 s). A `chi` frame and the `GET /api/events` snapshot carry the full state
-`{version, installed, available, update_blocked, auto}` (`auto`: `update.auto`, `off` or `install`, which the page's
-"available" wording follows); `/api/info` and the session-command wake response carry the same fields. `SessionHub#update_available` publishes the checker result under the hub's
+`{version, installed, available, update_blocked, auto, restart}` (`auto`: `update.auto`, `off` or `install`, which the page's
+"available" wording follows; `restart`: `update.restart`, with which the page offers no Restart toast for the
+version an automatic install's frames name unless it is `never` or the run failed: that run restarts by itself); `/api/info` and the session-command wake response carry the same fields. `SessionHub#update_available` publishes the checker result under the hub's
 Monitor, but fetching never holds it.
 
 `Web::UpdateCheck` runs its own thread beside the hub. When `update.notify: on` (the default) or
@@ -663,7 +664,8 @@ the worker's own atomic refusal still applies), the left ones retried each step
 turn running, `Server.restart_preflight` (the restart's command with `--version`, 20 s, killed on a timeout; it must
 print a chi at least the release) and, if it passes, the record's `phase: web` is written **before**
 `UpdateOps#restart_web`. A failed preflight, or a refused restart, publishes `restart_failed` and ends the run
-(`failed`). The restarted chi web's AutoUpdate (first step after 5 s) finds `phase: web`, checks it runs the
+(`failed`). `AutoUpdate#stop` waits `STOP_WAIT` (25 s, longer than the preflight's timeout) for its thread, and a
+preflight that ends after a stop leads to nothing (no `web`, no exec): the next start takes the run up again. The restarted chi web's AutoUpdate (first step after 5 s) finds `phase: web`, checks it runs the
 release, counts the workers once more and publishes `updated`, then `done`. Results reach the phone as `chi_notice`
 hub events (`SessionHub#publish_notice`), see [internals/web-push.md](internals/web-push.md).
 
@@ -717,8 +719,8 @@ model: [internals/remote-sessions.md](internals/remote-sessions.md).
 | `POST /api/sessions/:id/wait/prepare` | owner | `question_id` (absent: the pending one; `null`: none), `turn`, `created`, `busy` (+ `queue`) | 200 `{session_id, cursor, baseline: {messages, question_id, last_turn}, own_turn, known_turn, running, live, settled, last_turn_id}` (`WaitStart`) | 409 `busy`, `waiting` (`SendCommand::Busy`'s words, and its fields: `question`, `parent_strategy`) |
 | `POST /api/sessions/:id/wait` | owner | `cursor`, `baseline`, `turn`, `queued`, `ended_before`, `owner_grace`, `timeout` (capped at 30 s) | 200: `ReplyWait::Result`'s fields (`status`: `done`, `waiting_for_answer`, `no_reply`, `error`, `stopped`, `worker_gone`, or `timeout`: ask again; `text`, `file`, `question` as `PendingQuestion#to_file`, `outcome`, `limit`, `error_kind`, `retryable`, `cancel_reason`, `stopped_by`, `kept_steps`, `turn_id`, `origin`; never the session) and `parent_strategy` `{name, allowed, origin}` (`ParentReport.strategy_for`, this server's config.yml) | 400 `invalid_wait`; 503 `server_stopping` |
 | `POST /api/sessions/:id/notes` | owner | `text`, `source` (default `cli`, never `broadcast`) | 200 `{status: queued \| waits, session_id, queued}` (`NoteDelivery`) | 409 `owned_by_tui` (`status: refused`); 400 `note_rejected`, `missing_fields`, `invalid_source` |
-| `POST /api/sessions/:id/context` (more bodies) | owner | `{name, push: true, why, hint}` or `{name, cmd, every, why, hint}` beside the page's `{url, why, hint}`; `added_by` `cli`/`agent` (else `web`) | 201 `{status: attached, name}` | 400 `invalid_source`; 409 `exists` |
-| `POST /api/sessions/:id/context/:name/push` | owner | `text`, `summary`, `wake`, `hint` (a source's JSON output, checked the same way) | 200 `{status: pushed, name, before, revision, changed}` | 404 `not_found`; 409 `not_push`; 400 `invalid_text` |
+| `POST /api/sessions/:id/context` (more bodies) | owner | `{name, push: true, why, hint}` or `{name, cmd, every, why, hint}` beside the page's `{url, why, hint}`; `added_by` `cli`/`agent` (else `web`); `movable` (any body) | 201 `{status: attached, name, movable}` | 400 `invalid_source`; 409 `exists` |
+| `POST /api/sessions/:id/context/:name/push` | owner | `text`, `summary`, `wake`, `hint` (a source's JSON output, checked the same way) | 200 `{status: pushed, name, before, revision, changed}` | 404 `not_found`; 409 `not_push`; 410 `context_continued` (`next_id`); 400 `invalid_text` |
 | `DELETE /api/sessions/:id/context/:name?own=1` | owner | | 200 `{status: detached}`: the session's own only | 409 `project_source` (chi context rm's words); 404 |
 | `POST /api/sessions/:id/stop` | owner | `wait?` (seconds, capped at `SessionManager::STOP_WAIT`, 10: `chi --remote NAME sessions stop` sends it) | 200 `{status: stopped, session_id, released}`: `released`, whether the worker let go within the wait (without one `STOP_WAIT_SECONDS`, 2 s: the page's Stop) | 409 `owned_by_tui` |
 | `DELETE /api/sessions/:id?force=` | owner | `force=true` stops a live worker first (the page sends it) | as before | 409 `worker_running` without it |
@@ -881,7 +883,7 @@ A map of the parts the overview above doesn't name (paths under `lib/samagotchi/
 | Worker link | `worker_link.rb` (`WorkerLink`: `Live`, `Starting`, `Leaving`, `Skew`, `Stale`, `None`), `worker_sidecar.rb` (`WorkerSidecar`) | Whether a session's worker can be reached and the client for it: every Bridge client asks `WorkerLink.resolve` / `.client` / `.await` (*Worker link* above); `WorkerSidecar` is the `bridge.json` it reads. |
 | Session access | `session_access.rb` (`SessionAccess`: `NewSession`, `SetupWords`, `WaitStart`, `SessionView`, `Created`, `ContextEntry`, `ContextPush`, the errors `RemoteFailed`, `RemoteTooOld`, `Refused`, `BadRequest`), `session_access/local.rb` (`SessionAccess::Local`), `session_access/remote.rb` (`SessionAccess::Remote`), `session_access/http_transport.rb`, `session_access/web_bridge_client.rb` (`SessionAccess::WebBridgeClient`, a remote attach's worker through chi web), `session_access/dispatch.rb` (`SessionAccess::Dispatch`), `session_access/contract.rb` (`SessionAccess::Contract`), `remotes.rb` (`Remotes`), `remote_command.rb` (`chi remote`), `web/session_access_routes.rb` (`Web::SessionAccessRoutes`) | The seam between the session commands and where the sessions live: `Local` is this machine's (the `SessionManager`, `ReplyWait`, `NoteDelivery`, `ContextSources` and Bridge calls the commands made); `Remote` is another machine's, the same methods as requests to its chi web's routes of the same name (Bearer token, `HTTPTransport`), results as Local's value objects and refusals as the classes Local's callees raise, built from the fields chi web sends; waits and prefixes run on the server, a wait asked again per 30 s slice. `Dispatch` is bin/chi's front for `--remote NAME` / `CHI_REMOTE` (taken off before the subcommand lookup): it refuses what the contract table lists `local_only` (exit 2, one message) and runs the command with a `Remote` on the `Remotes` entry (`$XDG_CONFIG_HOME/samagotchi/remotes.yml`, 0600). chi web's routes answer from `Local` (*chi web's routes for the session commands* above). Checks that read this machine's config or files (vision, parent answers, the cwd's project, `SAMAGOTCHI_PARENT_SESSION`) stay in the commands and are skipped under a `Remote`, where chi web's create, turn and wait routes run the vision, parent-answers and busy checks with the server's config and the worker checks a parent's answer. See [internals/remote-sessions.md](internals/remote-sessions.md). |
 | Idle work | `idle_scheduler.rb` (`IdleScheduler`), `idle_recap.rb` (`IdleRecap`), `idle_reminders.rb` | One poller for an idle session's recap and reminders. |
-| Attached context | `context_sources.rb` (`ContextSources`), `context_poller.rb`, `context_absorber.rb`, `peer_sources.rb` (`PeerSources`: the sources peer bundles declare) | External sources a session keeps fresh, and the peer loop's wakes ([context.md](context.md)). |
+| Attached context | `context_sources.rb` (`ContextSources`), `context_poller.rb`, `context_absorber.rb`, `context_candidates.rb` (`ContextCandidates`: proposed sources, attached on the owner's mention at a turn's start, before the worker's absorb, or in the REPL's turn; `owner_prompt.rb` decides whose words count), `peer_sources.rb` (`PeerSources`: the sources peer bundles declare) | External sources a session keeps fresh, and the peer loop's wakes ([context.md](context.md)). |
 | LLM context strategies | `llm_context_strategy.rb`, `llm_context_view.rb`, `llm_context_stale.rb`, `llm_context_forget.rb` | What a request sends of the history (none, stale, forget) ([internals/llm-context-forget.md](internals/llm-context-forget.md)). |
 | Session chains | `session_continue.rb` (`SessionContinue`), `session_chain.rb` (`SessionChain`) | A session that continues an earlier one. `SessionChain.opener_for` gives the text web `continue →` prefills in the new link: the previous link's own first typed message when that link continues one itself, else nil (the 201's `opener`; not saved) ([sessions.md](sessions.md)). |
 | Review sessions | `review_start.rb` (`ReviewStart`), `session_review.rb` (`SessionReview`, the session's `review` field), `review_command.rb` (`ReviewCommand`, `chi review`), `review_apply.rb` (`ReviewApply`) | A session made to be shared: idle, its subjects project files checked by `Guardrails::ReviewPaths`, a fork of a working session from its recap (`--from`); Apply quotes a participant's review turn into the owner's composer ([sessions.md](sessions.md#review-sessions), [internals/participants.md](internals/participants.md)). |

data/docs/cli.md

@@ -22,6 +22,7 @@
 - `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 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))
 - `chi remote add NAME URL [--token-file F | --token-stdin]`, `chi remote ls`, `chi remote rm NAME` — the other machines whose chi web the session commands reach with `--remote NAME` (see [Remote sessions](#remote-sessions))
@@ -901,7 +902,8 @@ REPL alike:
   `cutting in…`, then `steered`. A phone shows the short form (`↳ after this
   thinking · 0:42`) with `cut in` and `queue` chips.
 - Commands answer, wait or are refused, by what they do:
-  - At once, beside the turn: `/stats`, `/recap` (and `/recap on|off|default`), `/help`, `/context`, a
+  - At once, beside the turn: `/stats`, `/recap` (and `/recap on|off|default`), `/help`, `/context` (and
+    `/context attach|decline NAME`: a candidate's note still waits for the next turn), a
     plugin's anytime command (`/btw`), and the commands that only show
     something: `/models` (with a filter too), and `/model`, `/llm-context`,
     `/thinking`, `/reasoning-history` and `/guardrails` alone.

data/docs/configuration.md

@@ -1758,6 +1758,33 @@ its own). The first target is a long session such as a day-long coordinator, whe
   turn that runs a layer or whose session set its strategy) and the web's chip. A woken worker's status line counts
   its saved context against the session's budget.
 
+## The candidate judge
+
+`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
+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:
+
+```yaml
+hosts:
+  openrouter:
+    url: https://openrouter.ai/api/v1
+    api: openai
+    api_key_env: OPENROUTER_API_KEY
+guardrails:
+  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)).
+
 ## 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
@@ -2082,7 +2109,8 @@ Both are read when chi web starts (restart it to apply a change). What it does,
    the command to run). `chi update` also merges the shipped bundles that live sessions read, hence "no turn anywhere".
 2. **Installs** exactly the release the notice named, as the **Update** button does (the system bundle and shipped
    bundles are merged three ways; files you edited are kept and counted in the push). The page's sticky toast says
-   "Automatic chi update in progress" and its sheet shows the rows. A failed install is tried **once per version**:
+   "Automatic chi update in progress" and its sheet shows the rows; with `update.restart: idle` no "installed"
+   toast with **Restart** buttons follows (the run restarts by itself). A failed install is tried **once per version**:
    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
@@ -2190,6 +2218,10 @@ 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.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. |

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]
@@ -105,7 +105,9 @@ and `-`, up to 40 characters, starting with a letter or digit
 (`subscriptions` is taken).
 
 In a session, `/context` lists what is attached (as `context_read` does
-with no name).
+with no name), then the session's [candidates](#candidates). `chi context ls`
+lists them too (`--format json`: rows with `"candidate": true` and their
+`status`), from another machine's chi web as well.
 
 ## Recipes
 
@@ -311,6 +313,219 @@ 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
+([`ctx.context.propose`](plugins.md#attached-context-ctxcontext)): a
+candidate, with a title and the words that name it (its *mentions*). Nothing
+reaches the agent until you name it in one of your own prompts; then chi
+attaches it before that turn runs, gives it one first fetch (up to 10
+seconds), and the turn starts with its attached note, whose why names what
+you wrote ("Why: you mentioned #412"). A source whose first text takes longer
+gets its note with a later turn.
+
+How a mention counts:
+
+- whole words, any case;
+- `#N` only for N of 10 or more, or right after "PR" or "pull" ("PR #4");
+- a branch name only when it is at least 6 characters and holds a `/`, `-`
+  or `_` (`feat/login`, not `web`);
+- a URL exactly as proposed (`…/pull/42/files` is another URL);
+- nothing inside a fenced code block: a pasted log's `#412` isn't you asking.
+
+Only the session's owner counts: a participant's message, a steer, a note or
+a reminder never attaches anything, and a review session gets no candidates.
+A bundle usually proposes from an init task that finishes while your first
+turn runs; when it does, the prompts you already wrote count too, and a hit
+is attached at once (its note comes with your next turn).
+
+A candidate's state is never stored: it is *attached* while a source of its
+name (or its URL) is, *declined* once you removed that source from the
+session or answered its card "Not here" (it isn't proposed, judged or
+attached again), else *proposed*. `chi context ls` and `/context` list them
+under the sources:
+
+```
+$ chi context ls
+no attached context
+candidates (attached when the session's owner mentions one):
+  pr-412  proposed  #412 Fix the login redirect
+```
+
+You can also choose yourself: `/context attach NAME` attaches a proposed
+candidate (its why: "you attached it"), `/context decline NAME` declines it.
+Both are the session owner's (a participant can't send a `/` line, and a
+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 take no candidates: the bundle proposes again in the
+new session (see [Movable context](#movable-context) for the sources).
+
+### The judge
+
+A mention is the only thing that attaches a candidate by itself. With
+`context.candidates.mode: audit` chi also asks [System 1](guardrails.md#system-1-experimental)
+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
+[The candidate judge](configuration.md#the-candidate-judge)).
+
+```yaml
+context:
+  candidates:
+    mode: audit            # off (default) | audit | on
+    threshold: 0.8         # on: attach at or above this
+    offer_threshold: 0.6   # on: a card from this, below threshold
+    reask_after_turns: 3   # owner prompts before the one re-ask
+```
+
+What it asks, and when:
+
+- **One ask per candidate**, at the start of each of your own turns (never a
+  participant's, never in a review session or on a Continue), after the
+  toolkit suggestion. A candidate proposed while your turn runs (github-pr's
+  usual case) is asked about right then, on your prompts so far.
+- **What it sees:** the candidate's title (and description, when the bundle
+  gave one) and your own prompts: the first one with a task in it and the
+  latest, each cut at 1500 characters. Never the branch, the checkout or the
+  source's "why". For a delegate child, also the titles of what its parent
+  session has attached, and the question says the first message is the
+  parent's request.
+- **Has a task been stated yet?** The same ask has a second question; below
+  0.5 the candidate stays unjudged and is asked again at your next prompt
+  (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.
+
+### On mode
+
+With `context.candidates.mode: on` the judge's answer acts:
+
+- **p ≥ `threshold` (0.8): attached quietly.** The source goes into the
+  session's own folder, its why "it looks related to your task" (the agent
+  never sees a probability), and it shows as a chip like any attached source.
+  Its note reaches the agent only at the next between-turn delivery: an
+  answer that comes while your turn runs waits for that turn to end, so the
+  running turn's history, cached prompt and reasoning stay as they were.
+  Removing it — the chip's ×, or `chi context rm NAME` — declines it: it is
+  never proposed or judged again in that session.
+- **`offer_threshold` (0.6) ≤ p < `threshold`: one card**, from `context`,
+  with the candidate's title and two buttons: **Attach** (`/context attach
+  NAME`) and **Not here** (`/context decline NAME`). The card shows once per
+  candidate, also across a worker restart (a `carded` line in the log
+  remembers it), and never inside a running turn: an answer that comes
+  mid-turn shows its card when the turn ends. In the terminal the card lists
+  the two commands to type. Answering it replaces the card with what
+  happened; a later re-ask at or above the threshold attaches it and closes
+  the card.
+- **Below `offer_threshold`: nothing.** The candidate stays proposed (a
+  mention still attaches it).
+
+### The log and the report
+
+Everything about candidates goes to `context_candidates.jsonl` in the state
+folder (0600, local; written in every mode, `off` too, since nothing in it
+leaves the machine): `proposed`, `mentioned`, `judged` (the probability `p`,
+the task-stated probability `task_p`, `stated`, `would`: attach / offer /
+none at the thresholds then, with your prompts cut to 200 characters),
+`judge_attached` (on mode's attach, with `p`), `carded` (on mode's card, with
+`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`.
+
+`chi context report [--days N]` counts it, with no prompts in the output
+(this machine only):
+
+```
+$ chi context report
+chi context report: the last 14 days, 12 sessions (mode audit)
+  candidates: proposed 14 · mentioned 3 · attached by you 1 · declined 2 · detached 0 · withdrawn 0
+  on mode: judge attached 0 · you removed 0 of them later · carded 0 · /context attach 0 · /context decline 0 (the card's buttons)
+  judge: 19 asks · judged 15 · no task yet 4 · 11 candidates judged
+  would attach (each candidate's latest judged ask):
+    ≥ 0.5  5
+    ≥ 0.6  4  offer_threshold
+    ≥ 0.7  3
+    ≥ 0.8  3  threshold
+    ≥ 0.9  1
+  against your own choice (6 judged candidates you attached, mentioned or declined), at 0.8: agree 5 · would attach what you declined 0 · would miss what you attached 1
+```
+
+The on mode line's "you removed N of them later" is the judge's false
+positives: sources it attached that you then took off.
+
 ## GitHub PRs: the github-pr bundle
 
 ```sh
@@ -320,13 +535,19 @@ chi bundle install github-pr      # or the dev profile: chi bundle install dev
 It needs [`gh`](https://cli.github.com), logged in (`gh auth login`).
 
 - When a session's worker starts on a branch with an open pull request, the
-  bundle attaches it as `pr-<number>` (a session source: "branch feat/x has
-  open PR #42"). Not in a `chi scratch` session or a delegate child, and
-  quietly nothing without `gh`, a login, a repository or an open PR. Once
-  you remove it (`chi context rm`, the chip's detach) it stays removed:
-  the next start doesn't bring it back; `chi context add <PR URL>` does.
+  bundle proposes it as a [candidate](#candidates) `pr-<number>`, titled
+  "#42 <the PR's title>": nothing reaches the agent until you mention it
+  in a prompt (`#42`, the branch's name, or the PR's URL). Then it is
+  attached in that same turn ("Why: you mentioned #42"). Not in a `chi
+  scratch` session or a review session, and quietly nothing without `gh`, a
+  login, a repository or an open PR. A delegate child gets the proposal too
+  (its task may name the PR). At a turn's start more than 5 minutes after
+  its last look, the bundle looks again, beside the turn (a branch switched
+  mid-session). Once you remove an attached PR (`chi context rm`, the chip's
+  detach) it stays removed: it isn't proposed or attached again; `chi context
+  add <PR URL>` brings it back.
 - `chi context add <PR URL>` attaches any PR.
-- `auto_attach` (below) can make it ask first, or attach nothing.
+- `auto_attach` (below) can make it attach the PR at once, or do nothing.
 - The text: title, state, branch, description, reviews, comments (oldest
   first) and checks, every 5 minutes.
 - The summary says what changed in **counts, authors and states only**
@@ -336,50 +557,28 @@ It needs [`gh`](https://cli.github.com), logged in (`gh auth login`).
 - It wakes for a review requesting changes, checks turning red, and the PR
   merged or closed. Comments alone never wake.
 
-### Attach, offer or off
+### Propose, attach or off
 
 ```yaml
 bundles:
   github-pr:
-    auto_attach: offer   # attach (the default) | offer | off
+    auto_attach: propose   # propose (the default) | attach | off
 ```
 
-- `attach`: the branch's open PR is attached when the worker starts, as
-  above.
-- `offer`: nothing is attached; a card asks instead, once per session per
-  PR: **PR #42 for branch feat/x**, the PR's title and "Not attached: the
-  agent gets nothing until you attach it.", with **Attach** and **Not
-  here**. The terminal shows them as `→ /pr-attach 42` and
-  `→ /pr-decline 42`, to type. Attach attaches it as auto-attach would
-  (even after Not here: a click is your choice); Not here marks it removed
-  from the session, so `attach` mode won't attach it there either. Either
-  turns the card into a one-line notice. Not here on a PR that is attached
-  already changes nothing and says so: `chi context rm pr-42` removes it. A worker restart (idle exit,
-  resume) doesn't ask again; once the card has scrolled out of the last 20,
-  `/pr-attach 42` or `chi context add <PR URL>` still attaches it. `/pr-attach` and
-  `/pr-decline` act only on a PR offered in that session.
-- `off`: nothing is attached or offered. `chi context add <PR URL>` and line
-  links work as before.
+- `propose`: the branch's open PR is a candidate, attached when you mention
+  it, as above.
+- `attach`: it is attached when the worker starts, mention or not (the
+  default before candidates; not in a delegate child).
+- `off`: nothing is proposed or attached. `chi context add <PR URL>` and
+  line links work as before.
 
 `true` and `false` (YAML reads a bare `on`/`off` as those) mean `attach` and
-`off`; an unknown value is `attach`, with a warning in the log. The setting
-is read when a worker starts.
-
-A web chat is created with its first message, so in `offer` mode the card
-arrives while that first turn runs: the first answer comes without the PR,
-and Attach delivers it before the next turn. An offered PR that isn't
-attached gets no line links (unless your message names its URL).
-
-In `offer` mode the bundle keeps a local log,
-`$XDG_STATE_HOME/samagotchi/plugins/github-pr/offers.ndjson`, to find out
-later when an offer is wanted: one JSON line per event, `offered` (session,
-project root, working directory, branch, PR URL, main checkout or worktree,
-model), `attached` and `declined` (with the seconds since the offer), and
-`first_prompt` (the first 160 characters of every session's first message,
-offered or not; a fork's first after the conversation it started from, once;
-not scratch sessions or delegate children). Over 1 MiB it is
-renamed to `offers.ndjson.1` (one old file is kept). Only you can read it
-(0600), and nothing leaves your machine.
+`off`. `offer`, which once posted a card with Attach and Not here, now reads
+as `propose`, and so does an unknown value, each with a warning in the log.
+The setting is read when the bundle looks.
+
+A proposed PR that isn't attached gets no line links (unless your message
+names its URL).
 
 ### Line links
 
@@ -468,8 +667,12 @@ sessions/<id>/<name>.json, …snapshot.json     a session's own
 sessions/<id>/subscriptions.json              what the session has seen and read (its worker writes it)
 sessions/<id>/muted/<name>                    a project source this session mutes
 sessions/<id>/declined/<name>                 a source you removed (its hint inside): auto-attach skips it
-sessions/<id>/offered/<name>                  a source a plugin offered here ({hint, why, at}): it isn't offered again
+sessions/<id>/candidates/<name>.json          a source a plugin proposed here ({url or cmd, title, describe, mentions, proposed_by, at}; no status)
 ```
 
+The candidates' log, `context_candidates.jsonl`, sits one level up, beside
+the sessions folder (`$XDG_STATE_HOME/samagotchi/`; see
+[The log and the report](#the-log-and-the-report)).
+
 Deleting a session deletes its folder. A source and its snapshot go with
 `chi context rm`; its `.lock` stays (a fetch may still hold it).

data/docs/guardrails.md

@@ -1087,6 +1087,17 @@ contention guard. 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`.
 
+The candidate judge is a third use (`context.candidates.mode`, off by
+default; [context.md, The judge](context.md#the-judge)): two `noul`
+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
+through `SideJudgments` (one ask in flight per kind, a failure is one warn,
+shutdown waits up to a second).
+
 ### What the audit writes
 
 With a client, `GuardrailWiring#request_approval` asks System 1 one `noul`

data/docs/internals/engine.md

@@ -38,7 +38,7 @@ Engine#run_turn(session, prompt, on_event:, max_iterations:, cancel_controller:,
   │     #                      resumed: true (only on a step-limit Continue: resumed: given),
   │     #                      images (only when there are any), cut_after (the model's cut wait, s)}
   │     # start_toolkit_suggestion: ToolkitSuggest's ask on its own thread from a copied snapshot (audit and on
-  │     #   mode: one eligibility, one thread). Audit never blocks the turn or changes the session; on mode
+  │     #   mode: one eligibility; SideJudgments' :toolkit kind: one in flight, warn-not-raise). Audit never blocks the turn or changes the session; on mode
   │     #   returns a ToolkitSuggest::Pending the turn joins below. See configuration.md (Toolkits) and
   │     #   guardrails.md (System 1).
   │     # refresh_profile! (may ask the server's /props once)
@@ -50,6 +50,12 @@ Engine#run_turn(session, prompt, on_event:, max_iterations:, cancel_controller:,
   │     #   start, or a Stop (which wins over an answer already in, and cuts the ask's request through
   │     #   Pending#cancel_controller; a Stop after a timeout doesn't), and on a candidate picked ≥ threshold
   │     #   ToolkitBinding#suggest sets the session's toolkit, origin suggested, saved, with the notice;
+  │     #   then start_context_judge (owner turns only: ContextCandidatesLog#look, and unless
+  │     #   context.candidates.mode is off, ContextJudge's asks on SideJudgments' :context kind, each answer to
+  │     #   ContextCandidateChoice#after_judged (on mode: attach to the session's folder, or a card held while a
+  │     #   turn runs and shown from run_turn's ensure, show_context_cards_after_turn); on a shared
+  │     #   local System 1 host they wait for the turn's end: started before warm_up_next_turn, whose warm-up
+  │     #   waits for them, or from run_turn's ensure; docs/context.md, The judge);
   │     #   then the session's toolkit (apply_toolkit!: Registry#toolkit, ToolIndex#refresh! for find_tools'
   │     #   chi line, a prompt rebuild when it changed). A Stop during the probes or the waits returns false
   │     #   (the ask's line says canceled; an ensure marks one the turn never settled failed).