samagotchi 0.14.0 → 0.16.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 760138c7792d414a15c39e074c5a6dc0ad44dfd0937c12707c3e6428a3544d43
-  data.tar.gz: d347cc3e3d7433292c40484beb73b95e2e3a9efb48ecd5ba5168b3c562c8d7e2
+  metadata.gz: 0dd06759f4b1d8b5c2d799aed0a4a57940c34bfd663599fcd1dbbad4f4421c99
+  data.tar.gz: 040c8e4d3c4e3aee3f9605fded5676088c21a80b50426696a9cdee4a16f65d7a
 SHA512:
-  metadata.gz: ae3585c68672ad0b163448b92c83e9f2d60dbc5efd60c47090170d80750ad20a08a5eae97aebf0dbc57629909db228de565a6a3a00ccb40bff9757ea66c3aeff
-  data.tar.gz: 4330ef708fe3ebc22f30e4cf249f88fb68a870eb1afd3be9894822e8e819ca25d393b34ffbabf56ef23ee784016b7cdcae9014d709f42db31fac88f501048ddb
+  metadata.gz: 418ba106ef5c7f610fd831b93b3441ab1de00910b84a782d37bc3fe617dab833ce35073f4733dc2fe6bdca9d90dba5c7af6fba7b7df29edf60c72c08c99acff9
+  data.tar.gz: 8c78e649bbadc097d5cb9b3de7adaac3bcebeda06d04ea1a34f7cbfab531fcaf15e0bce7bbc25480eb28e18c47867cbd0226d57ac3cece9452e7912471aa55b5

data/CHANGELOG.md

@@ -8,6 +8,80 @@ and commands may change between minor versions. How releases are made:
 
 ## [Unreleased]
 
+## [0.16.0] - 2026-10-03
+
+### Added
+
+- A delegated child's guardrail approvals go to the parent session's user (the approval relay): while the parent
+  waits (`delegate`, `delegate_result`), the child's approval opens as the parent's own approval, in the parent's web
+  page and attached terminal, with the same facts and diff and a line naming the delegate (linked) and its task. The
+  user answers once there; the parent's model sees only an outcome line in the tool's result (`approval relayed to
+  your user: execute: git push → allowed once`). The child verifies each answer with the parent's own worker before
+  taking it, and holds a parent agent's answer to its own `guardrails.parent_approvals`. The child's card stays
+  answerable (first answer wins) and says it waits in the parent too; `chi sessions list` shows it as
+  `waiting (in parent ab12)` (json `relayed_to`), and the web's bell rings once, for the parent's card. The other
+  running children's approvals are relayed during a wait too, one card at a time (`+1 more delegate waiting`), and a
+  grandchild's hop by hop. The time a card is open doesn't count against the wait's timeout.
+- For other parents (`chi send --wait`, `chi answer`), an approval's question block also offers to leave it open for
+  the user: `chi send --wait --format json ID` waits until they answer it in chi.
+
+### Changed
+
+- A turn that ends with no answer (the empty-answer retries used up) saves the same shape from both loops: the hidden
+  turn note alone. The native loop no longer saves the empty thinking-only reply and a literal `[No response]` (the
+  next prompt had two assistant turns in a row), and the chat loop's `(the model returned an empty answer)` is no
+  longer the answer text (`chi send --wait` saw it as an answer). The note carries a marker the UIs draw from, never
+  sent to the model. Older sessions keep their `[No response]`.
+- A parent agent's answer (`chi answer`, a marked `chi --attach`) no longer brings an archived session back to the
+  lists; only a human's does.
+
+### Fixed
+
+- A turn with no answer shows one muted line in the attached TUI and the REPL,
+  `no answer: the model returned nothing (after 1 retry)`, like the retry row, and so does `chi --resume` when it was
+  the last turn (it showed `[No response]` or an earlier step's text as the answer, or nothing).
+- The web shows a turn with no answer as the same muted notice where the answer would go, before the timing line,
+  live and after a reload; the reload keeps the turn's steps (both thinkings, the retry row inside them). Live it
+  showed nothing (native hosts) or an answer bubble below the timing line (`api: openai`); a reload showed
+  `[No response]` as the answer with one step fewer, or lost the steps and turned the retry row into a bubble of
+  its own.
+- Attached `chi -p` from a script exits 1 with `chi: the model gave an empty answer` on stderr when its turn ends with
+  no answer, as `chi -p --non-interactive` does; it exited 0 with a blank line (native hosts) or the placeholder text
+  (`api: openai`) as the answer. `chi send --wait` reports such a turn as `no_answer` from both kinds of host (an
+  `api: openai` host's placeholder was reported as the answer).
+- `chi --resume` and `--attach` give the last exchange's replayed tool rows their durations, as the live rows show
+  them (`ok (1.3s)`), from the session's saved tool records; a session from before turn ids keeps them bare.
+- The web stage's status row reads `∅ no answer` (muted, with a warn edge) for a turn that ended with no answer; it
+  said `✓ answered`.
+
+Update with `chi update` (no bundle changes).
+
+## [0.15.0] - 2026-10-02
+
+### Added
+
+- The hidden session strip's pill counts the sessions that wait for you (`▾ 5 sessions · 1 live · 1 waiting`, in the
+  warn colour).
+- The all-sessions search finds the sessions that wait for you: `waiting`, `question`, `approval` or `needs you`.
+
+### Fixed
+
+- `chi --resume ID` (and `--attach`) shows the last exchange's tool calls as the live tool rows
+  (`tool> running command (execute command="true"): ok`) between the prompt and the answer, not the prompt and the
+  answer alone.
+- A `--no-shared` REPL keeps the session's `cards.json` as a worker does: its turns count, so the cards and notices an
+  earlier worker showed stay where they were in the web, and the REPL's own are saved too.
+- A deleted, discarded or retention-pruned session takes its plugins' state with it: a bundle's
+  `plugins/<bundle>/sessions/<id>.json` (or `<id>/`) under the state dir, such as check-in's `/checkin` settings, no
+  longer stays behind.
+- `chi self`'s context window row shows the current model's configured window: its `models.<key>.window_tokens`, else
+  its host's `hosts.<name>.window_tokens`, else `context.window_tokens` or the default, and says which.
+- The web pairs each prompt with its own turn's timing: a failed turn (its prompt went back to you) no longer shifts
+  the timing lines and turn numbers of the turns after it. chi saves a turn id on each prompt; prompts saved before
+  this still pair by their place.
+
+Update with `chi update` (no bundle changes).
+
 ## [0.14.0] - 2026-10-02
 
 ### Added
@@ -782,7 +856,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.14.0...HEAD
+[Unreleased]: https://github.com/dm1try/samagotchi/compare/v0.16.0...HEAD
+[0.16.0]: https://github.com/dm1try/samagotchi/compare/v0.15.0...v0.16.0
+[0.15.0]: https://github.com/dm1try/samagotchi/compare/v0.14.0...v0.15.0
 [0.14.0]: https://github.com/dm1try/samagotchi/compare/v0.13.0...v0.14.0
 [0.13.0]: https://github.com/dm1try/samagotchi/compare/v0.12.0...v0.13.0
 [0.12.0]: https://github.com/dm1try/samagotchi/compare/v0.11.0...v0.12.0

data/docs/architecture.md

@@ -228,6 +228,16 @@ process that already owns the `Engine`); every worker starts it, and it exposes:
   `guardrails.parent_approvals` is `403 parent_approval_refused`, the question still open.
 - `POST /session/:id/question/dismiss` — leave the question unanswered (an approval: denied);
   `200`, or `409` when it is no longer pending.
+- `POST /session/:id/relay` — the approval relay, on a delegated child's worker
+  (`{action, relay_id, question_id}`): `opened` / `closed` (with a `reason`) set or clear the
+  pending question's `relayed_to` mark (`QuestionDesk#annotate`, `:question_relay`); `answered`
+  makes the child ask its parent's Bridge for the answer (`RelayVerifier`) and take it only for
+  this child and the question pending now. `200`, `409` no longer pending, `403` a parent agent's
+  allow beyond the child's `guardrails.parent_approvals`, `422 relay_unverified` (the question
+  stays open).
+- `POST /session/:id/relay/status` — on a parent's worker, `{relay_id}`: what its `RelayDesk`
+  (memory only) holds for that relay (`child_id`, `child_question_id`, `state`, `answer`, `by`);
+  `404` for an unknown id. A POST with a body because routes match exact paths.
 - `POST /session/:id/command` — a session command (`/model`, `/models`, `!rollback`, `!cmd`,
   `/continue`) for the worker loop; `202` with a `command_id` its `:command_ran` names, `400` when
   the line isn't one.

data/docs/cli.md

@@ -211,8 +211,9 @@ Notes:
   ended, 3 a question or an approval waits for an answer (stderr gets the
   whole question as `chi send --wait` prints it, with the
   `chi answer ID --question QID --option N` command; the worker keeps it
-  open, and `chi answer` or the web answers it), 1 the turn failed or the
-  worker went away. For a
+  open, and `chi answer` or the web answers it), 1 the turn failed, ended
+  with no answer (stderr: `chi: the model gave an empty answer`, as with
+  `--non-interactive`) or the worker went away. For a
   script, `chi send --new --wait` is the better entry point: stdout holds the
   answer alone (see [Starting a session](sessions.md#starting-a-session)).
 - `-p` always feeds **and** runs the prompt; there is no feed-and-edit variant. To

data/docs/configuration.md

@@ -625,7 +625,9 @@ asks again in the same turn with a hidden note ("your last reply had no visible
 unless `sampling:` sets one; the REPL prints `↻ empty answer, asking again (1/1)` and the web shows it as a row of
 the step. `retry.empty_answer` (default `1`, at most `3`, env `SAMAGOTCHI_RETRY_EMPTY_ANSWER`, no CLI flag) is how
 many times per turn; `0` ends the turn at the empty answer as before. An answer cut because the context is full
-(90 % or more) is not retried. When the retries run out the turn ends with "(the model returned an empty answer)".
+(90 % or more) is not retried. When the retries run out the turn ends with no answer: every UI shows one muted line,
+`no answer: the model returned nothing (after 1 retry)`, and the model is told on its next turn with a hidden note;
+no made-up answer is saved.
 A generation a plugin cuts while it streams (loop-guard's thinking watch, or any `stop_generation`,
 [hooks.md](hooks.md#watching-the-stream)) uses the same budget: `↻ cut by loop-guard, asking again (1/1)`, and with
 none left the turn ends as cancelled (hook).

data/docs/guardrails.md

@@ -56,9 +56,14 @@ Who answers:
   the approval waits (in the session file) and shows on attach.
 - `-p … --non-interactive`: nobody; the call is denied ("No one to approve it
   (non-interactive run)").
+- A delegated child session (the `delegate` tool), while its parent waits:
+  the parent's user, on the parent's own card (the approval relay; see
+  [Sessions: Delegating](sessions.md#delegating)). The child's card stays
+  answerable too, the first answer wins. The parent's model sees only the
+  outcome.
 - A parent agent running chi as a sub-agent (`chi send --wait` exits 3 with
-  the approval): `chi answer` may deny it, never allow it by default. See
-  [Approvals from a parent agent](#approvals-from-a-parent-agent).
+  the approval): `chi answer` may deny it, never allow it by default, or leave
+  it for the user. See [Approvals from a parent agent](#approvals-from-a-parent-agent).
 
 The model gets one line on a deny. A rule's or hook's deny reads
 `[execute] Error: denied by guardrail (rule git-push, bundle guardrails): git push publishes commits. The user was not asked. Do not retry it or reach the same result another way; ask the user how to proceed.`
@@ -84,6 +89,15 @@ The file tools can't write the store.
 
 ### Approvals from a parent agent
 
+A chi parent's `delegate` children don't need any of this: their approvals go
+to the user on the parent's own card (the approval relay). This section is the
+path for other agents, and for a chi parent that can't host the relay (a
+`--no-shared` REPL, `--non-interactive`): there the model gets the approval
+block and the rules below. With the relay, the same rules still hold for a
+parent model that answers its own relay card (a piped or marked `chi --attach`
+on the parent): that answer is a parent agent's, checked by the parent and
+again by the child.
+
 When another agent (Claude Code, Codex, a script) runs chi with
 `chi send --wait`, an approval comes back to it as exit 3 with `kind:
 approval`, and `chi answer` answers it. A rule with `verdict: ask` means "ask

data/docs/plugins.md

@@ -479,7 +479,7 @@ full label, `plugin.rb (bundle my-bundle)`.
 | `ctx.cwd` | the session's working directory |
 | `ctx.repo_root` | the git checkout holding `cwd`, or nil |
 | `ctx.settings` | the bundle's settings, frozen |
-| `ctx.data_dir` | `$XDG_STATE_HOME/samagotchi/plugins/<bundle>/`, created on first use |
+| `ctx.data_dir` | `$XDG_STATE_HOME/samagotchi/plugins/<bundle>/`, created on first use. A session's own state goes in `sessions/<id>.json` or `sessions/<id>/` there: chi removes it when the session is deleted, discarded or pruned |
 | `ctx.log` | `ctx.log.info(:event, key: value)`: debug-log records tagged `plugins`, with `bundle=<bundle>` |
 | `ctx.messages` | the conversation, as a frozen copy, without the system prompt. While a turn runs, a session worker's (attached, web) adds that turn so far: its prompt, the model's text and the lines merged into it (no tool calls or thinking); the REPL's is the conversation before that turn |
 | `ctx.messages_partial?` | whether `ctx.messages` leaves out a running turn (the REPL mid-turn), so a plugin can say what its answer is about |
@@ -937,8 +937,8 @@ with a line and carry on unchanged.
 
 `/checkin` (anytime) for this session. What it changes (on/off, the mode,
 the threshold) is saved with the session, in the bundle's data dir
-(`plugins/check-in/sessions/<id>.json`), so it outlasts a worker's restart;
-another session starts from config.yml:
+(`plugins/check-in/sessions/<id>.json`), so it outlasts a worker's restart
+and goes with the session; another session starts from config.yml:
 
 | | |
 |---|---|

data/docs/sessions.md

@@ -40,7 +40,7 @@ chi sessions prune [--dry-run] [--days N] [--keep N] [--keep-status running,...]
 chi sessions clean [--dry-run] [--days N]             # test sessions: all, or older than N days
 ```
 
-A session whose worker waits for an answer (a question, a hook's question or a guardrail approval) reads `waiting` in the status column, and json has `waiting: "question"|"approval"|"hook"` and `waiting_id`, the question's id for `chi answer --question` (both null otherwise). Only while a worker runs it: a question a dead worker left in the file shows the saved status. Answer it with `chi answer`, the web or `chi --attach ID`; `chi sessions stop ID` frees the worker instead.
+A session whose worker waits for an answer (a question, a hook's question or a guardrail approval) reads `waiting` in the status column, and json has `waiting: "question"|"approval"|"hook"` and `waiting_id`, the question's id for `chi answer --question` (both null otherwise). A delegate's approval its parent relayed to its own card (see *Delegating*) reads `waiting (in parent ab12)`, json `relayed_to: "ab12…"` (the parent's short id, else null). Only while a worker runs it: a question a dead worker left in the file shows the saved status. Answer it with `chi answer`, the web or `chi --attach ID`; `chi sessions stop ID` frees the worker instead.
 
 Examples:
 
@@ -180,7 +180,12 @@ The `delegate` tool hands a task to a **child session**: an ordinary chi session
 
 - `delegate(task, model:, session:, wait:, timeout:)`: starts a child and, by default, waits for its reply (`wait: false` returns at once, so several children can run side by side; `timeout`, default 600 s, leaves a slow child running; 0 checks once without waiting). With `session:` (a child's id or prefix) the task goes to that child as a follow-up instead, delivered like `chi send` (client id `delegate:<parent short id>`, shown as `delegate>` in the child's UIs); only this session's children take one.
 - `delegate_result(session:, timeout:)`: waits for a child's next reply: the one named, or the newest running child (`timeout` as for `delegate`: 0 checks once and returns at once). The reply comes back once; a later call waits for the next one.
-- What a wait returns, `session: <id>` then `status:` and the text, with the status words `chi send --wait --format json` uses: `answered` with the reply after a `---` line; `question` as soon as the child opens a question or a guardrail approval, with the question's text, options and the `chi answer` command for it (nothing is answered for it: `chi answer`, attach or use the web, then wait again); `failed`, `canceled` or `no_answer` when the child's turn ended with nothing to say (its session shows what happened); `error` (its worker crashed) or `stopped` (`chi sessions stop`) at once; `worker_gone` when the child has had no worker for 15 seconds (it crashed without saying so, or idle-exited): `delegate` with `session:` starts it again; `running` on timeout, or when the parent's own turn is canceled (the child keeps running; the next turn can wait again). A reply saved before the child's worker idle-exited is returned at once.
+- What a wait returns, `session: <id>` then `status:` and the text, with the status words `chi send --wait --format json` uses: `answered` with the reply after a `---` line; `question` as soon as the child opens a question (the model's own, or a hook's), with the question's text, options and the `chi answer` command for it (nothing is answered for it: `chi answer`, attach or use the web, then wait again); `failed`, `canceled` or `no_answer` when the child's turn ended with nothing to say (its session shows what happened); `error` (its worker crashed) or `stopped` (`chi sessions stop`) at once; `worker_gone` when the child has had no worker for 15 seconds (it crashed without saying so, or idle-exited): `delegate` with `session:` starts it again; `running` on timeout, or when the parent's own turn is canceled (the child keeps running; the next turn can wait again). A reply saved before the child's worker idle-exited is returned at once.
+- **A child's approvals go to the parent's user** (the approval relay). While the parent waits (`delegate`, `delegate_result`), a guardrail approval the child opens reopens as the parent session's own approval: the same card in the parent's web page and attached terminal, with the same facts and diff, a line naming the delegate and its task (`delegate ab12 · fix the flaky spec…`, linked to its session) and the header `Approve delegate ab12's tool call?`. The options are the child's, by index; "for the session" says it is the delegate's session (the session scope keys on the child; repo and rule approvals are one shared store). The user answers once there; the parent's model never sees the approval, only one line per relayed approval in the tool's result, before the reply: `approval relayed to your user: execute: git push origin main → allowed once` (or `denied ("why")`, `dismissed (denied)`, `answered on the child`, `not delivered (the child's worker is gone)`, `refused by the child …`, `still open (your turn was stopped)`). The time the card is open doesn't count against `timeout`. While the parent waits on one child, its other running children's approvals are relayed too, oldest first, one card at a time (`+1 more delegate waiting`); each outcome comes in that child's next result.
+  - The child's own card stays answerable (the first answer wins: answered there, the parent's card closes as "answered in ab12"). While relayed it says `Waiting for approval in parent ab12: answering here works too`; `chi sessions list` shows the child as `waiting (in parent ab12)` (`--format json`: `relayed_to`), and the web's bell rings for the parent's card, not the child's.
+  - How the child trusts it: the parent's POST that says "answered" (Bridge `POST /session/<child>/relay`) carries no answer. The child asks its parent session's live Bridge (`POST /session/<parent>/relay/status`), which reports only what the parent's question flow took from a UI (`RelayDesk`, in memory only), and takes it only for this child, the question pending now, answered. A parent agent's answer on the relay card (a piped or marked `chi --attach PARENT`, `chi answer`) is held to `guardrails.parent_approvals` by the parent and again by the child.
+  - A Stop of the parent's turn closes its card; the child's approval stays open there. A child's worker that goes closes the card (`… worker is gone`); a parent's worker that goes clears the child's "waiting in parent" line within 2 s. A later `delegate_result` relays it again.
+  - No relay where the parent can't host one (a `--no-shared` REPL, `--non-interactive`) or isn't waiting (`wait: false` until the next `delegate_result`): the approval waits on the child, with the web's bell, and the result's question block says to deny it or leave it for the user. The model's own questions and hooks' questions come back to the model as before. A grandchild's (a plugin's `ctx.sessions.fork` can make one) is relayed hop by hop: `delegate ab12 → cd34 asks:`.
 - Every child starts with the shipped `delegated` system memory preloaded (`preloaded_memory_names: ["system/delegated"]`; `--mute delegated` would hide it): put everything in the final reply, don't delegate further, don't write memories or change config, stay in the folder. Its system prompt also says `Delegated by session <parent id>`. The parent's own `--mute` list does not carry over.
 - Limits: a child cannot `delegate` (depth 1; the tool refuses), and one session may have at most `session.max_children` (default `4`, env `SAMAGOTCHI_SESSION_MAX_CHILDREN`) children running at a time, counted from the session files (a finished or idle-exited child does not count; one whose worker is still starting does, for 15 s). A refused call creates no session. Nothing stops children with the parent: `chi sessions stop ID` does.
 - The link is the session's `parent_id`, written before the worker starts, so a respawn keeps it; `GET /api/sessions` and `/api/sessions/:id` carry it, and `SessionManager.children_of` lists a parent's children.

data/docs/sub-agent.md

@@ -53,12 +53,22 @@ command, folder, rule and reason.
 
 ## Approvals
 
+A chi parent (the `delegate` tool) doesn't go through any of this: its
+children's approvals go to its own user as its own approvals, and its model
+sees only how each was answered. See
+[Sessions: Delegating](sessions.md#delegating). What follows is for other
+parents (Claude Code, Codex, a script), and for a chi parent that can't host
+the relay (a `--no-shared` REPL, `--non-interactive`).
+
 An approval is a guardrail rule with `verdict: ask`: its user said "ask me". So
 a parent may deny it (`--option Deny --text "why"`, `--text` alone, or
 `--dismiss`) but not allow it: `chi answer` refuses an Allow with exit 1 and
 `allowing a tool call is up to the user: deny it (--option Deny --text WHY),
 and tell your user`. For an approval, the question block and `answer_with` give
-the deny command, not `--option N` or `chi --attach`. With
+the deny command, not `--option N` or `chi --attach`. The block also offers to
+leave it open: tell your user it waits in chi web (the bell and badge show
+it there), and `chi send --wait --format json ID` (no message) waits until
+they answer it. With
 `guardrails.parent_approvals: once` in chi's config.yml (it has no environment
 variable), "Allow once" goes through; the wider scopes never do,
 and neither does any allow on chi's own config, hooks or guardrail rules. See
@@ -113,8 +123,10 @@ Start a task: `chi send --new --wait --format json --timeout 500 -m "<task>"`
 - `question.kind: approval`: chi wants to run something its user's guardrails
   flagged, and allowing it is up to your user. Deny it (the `answer_with`
   command: `--option Deny --text "why"`), and tell your user what it wanted to
-  run and why. Never allow it yourself, through `chi answer`, a piped
-  `chi --attach` or chi's web API.
+  run and why. Or leave it open: tell your user it waits in chi web (the
+  session's short id), then `chi send --wait --format json --timeout 500 <session_id>`
+  waits until they answer it there. Never allow it yourself, through
+  `chi answer`, a piped `chi --attach` or chi's web API.
 - `status: running` (exit 4): still working. Wait again:
   `chi send --wait --format json --timeout 500 <session_id>`.
 - Anything else (exit 1): report `detail` to your user. `chi --attach <session_id>`

data/lib/samagotchi/answer_display.rb

@@ -23,10 +23,14 @@ module Samagotchi
 
     # A message as a model-facing reader may see it: without `display`.
     # The same object when it has none.
+    # An empty-answer note's marker (TurnNote::EMPTY_ANSWER) is display
+    # only too: it goes the same way.
+    DISPLAY_ONLY = [KEY.to_s, "empty_answer"].freeze
+
     def self.strip(message)
-      return message unless message.is_a?(Hash) && (message.key?(KEY) || message.key?(KEY.to_s))
+      return message unless message.is_a?(Hash) && DISPLAY_ONLY.any? { |key| message.key?(key.to_sym) || message.key?(key) }
 
-      message.reject { |key, _| key.to_s == KEY.to_s }
+      message.reject { |key, _| DISPLAY_ONLY.include?(key.to_s) }
     end
 
     def self.strip_all(messages)

data/lib/samagotchi/bridge/card_store.rb

@@ -51,7 +51,7 @@ module Samagotchi
       # The events after which the file is written again: the ones that
       # change an entry or the turn count.
       SAVED_ON = (%i[card hook_notice empty_answer_retry question_requested question_answered question_cancelled
-                     turn_failed] + Events::TURN_KEPT).freeze
+                     question_relay turn_failed] + Events::TURN_KEPT).freeze
 
       # What a session's saved file lists, as a store started from it lists
       # (no turn running): the web's cards for a session no worker runs.
@@ -171,6 +171,7 @@ module Samagotchi
           add_turn_row({ type: :question, pending_question: Marshal.load(Marshal.dump(event[:pending_question])) }) if @running
         when :question_answered then resolve_question(event[:id], answer: event[:answer])
         when :question_cancelled then resolve_question(event[:id], cancelled: true, reason: event[:reason])
+        when :question_relay then mark_relay(event[:id], event[:relayed_to])
         end
       end
 
@@ -219,6 +220,20 @@ module Samagotchi
         entry&.merge!(Marshal.load(Marshal.dump(outcome.compact)))
       end
 
+      # The open question was relayed to a parent's user, or no longer is.
+      def mark_relay(id, relayed_to)
+        entry = @entries.reverse_each.find do |e|
+          e[:type] == :question && e.dig(:pending_question, :id).to_s == id.to_s
+        end
+        return unless entry
+
+        if relayed_to
+          entry[:pending_question][:relayed_to] = Marshal.load(Marshal.dump(relayed_to))
+        else
+          entry[:pending_question].delete(:relayed_to)
+        end
+      end
+
       def push(entry)
         @entries << entry
         notice = notice?(entry)

data/lib/samagotchi/bridge/turn_accumulator.rb

@@ -268,6 +268,12 @@ module Samagotchi
           @turn[:pending_question] = event[:pending_question]&.dup
         when :question_answered, :question_cancelled
           @turn[:pending_question] = nil
+        when :question_relay
+          pending = @turn[:pending_question]
+          if pending && pending[:id].to_s == event[:id].to_s
+            relayed_to = event[:relayed_to]
+            @turn[:pending_question] = relayed_to ? pending.merge(relayed_to: relayed_to) : pending.except(:relayed_to)
+          end
         end
         parts << { kind: "notice", event: TurnNotice.slice(event) } if TurnNotice.notice?(event)
       end

data/lib/samagotchi/bridge.rb

@@ -24,6 +24,8 @@ require_relative "image_store"
 require_relative "log"
 require_relative "version"
 require_relative "worker_sidecar"
+require_relative "relay_verifier"
+require_relative "relay_watcher"
 
 module Samagotchi
   # Bridge is an optional HTTP transport that lets an external web / desktop
@@ -192,6 +194,7 @@ module Samagotchi
       await_answers(REQUEST_GRACE_SECONDS)
       @connection_threads.each { |t| t.kill rescue nil }
       @connection_threads.clear
+      @mutex.synchronize { @relay_watchers&.each { |t| t.kill rescue nil } }
       @accept_thread&.join(2)
       remove_sidecar
       nil
@@ -429,6 +432,8 @@ module Samagotchi
       %w[POST command] => :handle_command,
       %w[POST exit] => :handle_exit_request,
       %w[POST recap] => :handle_recap,
+      %w[POST relay] => :handle_relay,
+      %w[POST relay/status] => :handle_relay_status,
       %w[GET state] => :handle_state,
       %w[GET stats] => :handle_stats,
       %w[GET snapshot] => :handle_snapshot
@@ -525,6 +530,38 @@ module Samagotchi
       end
     end
 
+    # What a parent's relay may say about this session's approval
+    # (BridgeClient#relay): opened and closed only change how the question
+    # shows (QuestionDesk#annotate); answered makes this worker ask the
+    # parent for the answer (RelayVerifier). No auth: a poke at opened or
+    # closed can at most show a wrong banner.
+    RELAY_ACTIONS = %w[opened closed answered].freeze
+    # Why a relay closed, as a parent says it; anything else is "closed".
+    RELAY_CLOSE_REASONS = %w[stopped closed child_gone answered_on_child].freeze
+
+    # POST /session/:id/relay {action, relay_id, question_id}. 200, 409 (no
+    # longer pending, or another relay's), 403 refused (a parent agent's
+    # allow), 422 relay_unverified, 400 a bad request.
+    def handle_relay(session_id, body)
+      parsed = parse_json(body)
+      return [{ "Allow" => "POST" }, 400, { error: "invalid_json" }] unless parsed.is_a?(Hash)
+
+      action, relay_id, qid = %w[action relay_id question_id].map { |key| fetched(parsed, key).to_s }
+      unless RELAY_ACTIONS.include?(action) && !relay_id.empty? && !qid.empty?
+        return [{ "Allow" => "POST" }, 400, { error: "missing_fields", detail: "action (opened, closed, answered), relay_id and question_id required" }]
+      end
+
+      case action
+      when "opened" then relay_opened(qid, relay_id)
+      when "closed"
+        reason = fetched(parsed, "reason").to_s
+        relay_closed(qid, relay_id, RELAY_CLOSE_REASONS.include?(reason) ? reason : "closed")
+      else
+        RelayVerifier.new(engine: @engine, state_dir: @state_dir, session_id: session_id)
+                     .answer(relay_id: relay_id, question_id: qid)
+      end
+    end
+
     # Dismiss the pending question (an empty answer, as in the REPL): the
     # tool returns without an answer and every UI gets :question_cancelled.
     # Only the question the client saw, and only while nobody has answered
@@ -872,6 +909,53 @@ module Samagotchi
       headers["connection"].to_s.downcase == "close"
     end
 
+    # POST /session/:id/relay/status {relay_id}: what this (the parent's)
+    # worker's relay holds, for the child that verifies an answer
+    # (RelayVerifier). Read-only and no secret; 404 for an unknown id.
+    def handle_relay_status(_session_id, body)
+      parsed = parse_json(body)
+      return [{ "Allow" => "POST" }, 400, { error: "invalid_json" }] unless parsed.is_a?(Hash)
+
+      relay = @engine.relay_desk.status(fetched(parsed, "relay_id").to_s)
+      return [{}, 404, { error: "unknown_relay" }] unless relay
+
+      [{}, 200, relay]
+    end
+
+    # A parent's relay card for +qid+ opened: the question says so (the
+    # child's card and lists show where else it can be answered).
+    def relay_opened(qid, relay_id)
+      parent_id = begin
+        Session.load(@session_id, state_dir: @state_dir).parent_id
+      rescue ArgumentError
+        nil
+      end
+      return [{}, 422, { error: "relay_unverified", detail: "this session has no parent" }] unless parent_id
+
+      marker = { parent_id: parent_id, parent_short: parent_id[0, 8], relay_id: relay_id }
+      return [{}, 409, { error: "question_not_pending", detail: "no pending question #{qid}" }] unless @engine.annotate_question(qid, relayed_to: marker)
+
+      Log.info(:bridge, "relay_opened", sid: @session_id, id: qid, parent: parent_id[0, 8])
+      watch = RelayWatcher.start(engine: @engine, question_id: qid, relay_id: relay_id,
+                                 parent_dir: Session.session_dir(parent_id, state_dir: @state_dir))
+      @mutex.synchronize { @relay_watchers = (@relay_watchers || []).select(&:alive?) << watch }
+      [{}, 200, { status: "opened", question_id: qid }]
+    end
+
+    # The parent's relay card closed unanswered: the mark goes, if it is
+    # still that relay's.
+    def relay_closed(qid, relay_id, reason)
+      pending = @engine.pending_question
+      relay = pending && pending[:relayed_to]
+      unless pending && pending[:id].to_s == qid && relay && (relay[:relay_id] || relay["relay_id"]).to_s == relay_id
+        return [{}, 409, { error: "question_not_pending", detail: "no question #{qid} relayed by #{relay_id}" }]
+      end
+      return [{}, 409, { error: "question_not_pending", detail: "no pending question #{qid}" }] unless @engine.annotate_question(qid, relayed_to: nil, reason: reason)
+
+      Log.info(:bridge, "relay_closed", sid: @session_id, id: qid, reason: reason)
+      [{}, 200, { status: "closed", question_id: qid }]
+    end
+
     def write_sidecar
       # version: the chi this worker runs (chi update reports older ones).
       WorkerSidecar.new(port: @port, bind: @bind, session_id: @session_id, started_at: Time.now.iso8601(3),

data/lib/samagotchi/bridge_client.rb

@@ -180,6 +180,33 @@ module Samagotchi
       post("cancel", { reason: reason }, read_body: true)
     end
 
+    # How long the approval relay's calls wait for a reply: a parent's Stop
+    # isn't held for READ_TIMEOUT by a child that doesn't answer.
+    RELAY_TIMEOUT = 5
+    # How long a child waits for its parent's word on a relay (#relay_status).
+    RELAY_STATUS_TIMEOUT = 2
+
+    # POST /session/:id/relay on a child's worker: a parent's relay of the
+    # child's approval opened, closed or was answered (the child asks the
+    # parent which answer, #relay_status). 200 answered, 409 no longer
+    # pending, 403 refused (a parent agent's allow), 422 relay_unverified.
+    # @param action [String] "opened", "closed" or "answered"
+    # @return [Response]
+    # @raise [SystemCallError] the worker is gone or didn't answer in time
+    def relay(action:, relay_id:, question_id:, read_timeout: RELAY_TIMEOUT, **extra)
+      post("relay", { action: action, relay_id: relay_id, question_id: question_id, **extra },
+           read_body: true, read_timeout: read_timeout)
+    end
+
+    # POST /session/:id/relay/status on a parent's worker: what its relay
+    # +relay_id+ holds (child_id, child_question_id, state, answer, by); 404
+    # for one it doesn't know. A POST with a body: routes match exact paths.
+    # @return [Response]
+    # @raise [SystemCallError]
+    def relay_status(relay_id, read_timeout: RELAY_STATUS_TIMEOUT)
+      post("relay/status", { relay_id: relay_id }, read_body: true, read_timeout: read_timeout)
+    end
+
     # GET /session/:id/<path> as JSON.
     # @return [Hash, nil] the parsed body, or nil unless the Bridge answered 200
     def get_json(path)
@@ -283,11 +310,11 @@ module Samagotchi
     # the same one.
     def deadline = (Time.now.to_f + (@read_timeout * DEADLINE_SHARE)).round(3)
 
-    def post(path, payload, read_body:)
+    def post(path, payload, read_body:, read_timeout: @read_timeout)
       sock = TCPSocket.new(@host, @port)
       json_body = JSON.generate(payload)
       sock.write("POST /session/#{@session_id}/#{path} HTTP/1.1\r\nHost: #{@host}:#{@port}\r\nContent-Type: application/json\r\nContent-Length: #{json_body.bytesize}\r\nConnection: close\r\n\r\n#{json_body}")
-      reply = read_reply(sock, path, whole: read_body)
+      reply = read_reply(sock, path, whole: read_body, timeout: read_timeout)
       body = read_body ? reply.split("\r\n\r\n", 2)[1] : nil
       Response.new(status: reply[STATUS_LINE, 1].to_i, body: body)
     ensure
@@ -295,17 +322,17 @@ module Samagotchi
     end
 
     # The reply up to the Bridge's close (or its first line only), within
-    # @read_timeout in all.
+    # +timeout+ seconds in all (@read_timeout by default).
     # @raise [Errno::ETIMEDOUT]
-    def read_reply(sock, path, whole: true)
-      deadline = Process.clock_gettime(Process::CLOCK_MONOTONIC) + @read_timeout
+    def read_reply(sock, path, whole: true, timeout: @read_timeout)
+      deadline = Process.clock_gettime(Process::CLOCK_MONOTONIC) + timeout
       reply = +""
       loop do
         break if !whole && reply.include?("\n")
 
         left = deadline - Process.clock_gettime(Process::CLOCK_MONOTONIC)
         unless left.positive? && sock.wait_readable(left)
-          raise Errno::ETIMEDOUT, "bridge #{path}: no reply within #{@read_timeout}s"
+          raise Errno::ETIMEDOUT, "bridge #{path}: no reply within #{timeout}s"
         end
 
         reply << sock.readpartial(16_384)

data/lib/samagotchi/bundles/system/manifest.yml

@@ -1,11 +1,11 @@
 ---
 name: samagotchi-system
-version: 0.14.0
+version: 0.16.0
 scope: system
 description: Default system memories — identity, self map, config modification protocol, memory guide and the delegated-session rules
 files:
   identity.md: sha256:29c2f7df9f6c5acbc5ec17000a4490741e55e426af15ca0d81c8706edd9bd027
-  self_map.md: sha256:93c788fadaf98adeb8946b4a357d2372bd6ebb439042d7cef8dda8fb44187315
+  self_map.md: sha256:0410c2e62716e256a2a6aec73c7801def185cbae9c1db556efcedbbad22d908c
   config_modification_protocol.md: sha256:d0e9d4a84652bf54ec2fd664f61c536637af9decdd22fcd982f52195bf9f5fb4
   memory_guide.md: sha256:81b911b9a015f0924c48162b3dc4b6376309e743765074419a99fab46e480858
   delegated.md: sha256:0a71d5dfa7127df2d51cb5f0e7214240ed88777e36559430a8724c796d7ae561

data/lib/samagotchi/bundles/system/self_map.md

@@ -25,7 +25,8 @@
 - `delegate` hands a task to a child session that runs in parallel and returns only its final
   reply (`delegate_result` waits for it; `session:` sends a follow-up to a child). A child is a
   normal session: it shows in `chi sessions list` with `↳ <parent>`, and the user can steer it
-  with `chi --attach <id>`; see `docs/sessions.md` "Delegating".
+  with `chi --attach <id>`. While I wait for a child, its tool approvals go to my user as my own
+  approvals (I see only how each was answered); see `docs/sessions.md` "Delegating".
 - Bundles extend me: memories, `hooks/*.rb`, `guardrails/*.yml`, and a `plugin.rb` that adds slash
   commands (`anytime:` ones run mid-turn), model tools (they can return images I see), hooks,
   cards, side answers (`ask_model`),

data/lib/samagotchi/empty_answer_retry.rb

@@ -41,7 +41,8 @@ module Samagotchi
       used_tokens.to_f / window_tokens >= CONTEXT_FULL_RATIO
     end
 
-    attr_reader :limit
+    # @return [Integer] the budget, and the attempts spent this turn
+    attr_reader :limit, :attempts
 
     def initialize(limit: self.class.limit)
       @limit = limit