samagotchi 0.170.0 → 0.171.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: a13b61890c6a215efb8f13715a30637a12324d560eec91f1f827a849156453c9
-  data.tar.gz: d839197f63a218e01cd48ee326f17f25c7b9027c906ccdf5cd78b855e31b05f8
+  metadata.gz: e45a5742b8855d69057bb153ca6cf956fa351408b583ae278564443cb7952f73
+  data.tar.gz: fa6dec2db1397d60c023f3bd939b5a36795c5482f59a42f768a99455829ee533
 SHA512:
-  metadata.gz: fcef2226618d6d543b180c536a24cb8b2e669a1c5a309a424b7c64acede977ade18593a36af9da5cf0e15a1e5781502f8dae3b2f7c78d61b7193905dc4538c86
-  data.tar.gz: f66ae46d4079588380f56a7fe6ffd7f222fc7eea442545f1200ce5598a8897681a9e3924ad3933189320870f6cf0e9ad18e389b763cf5f55db863c625a7433ab
+  metadata.gz: 37dac3cb11eed26b34929ba153e25294ece85fcb88fe12f3e3a4b3e4cce2d2ac881983cfb200c0c13febae830d6ca1ce74e7afffa61eb4a9cb7f2d0daf836633
+  data.tar.gz: 28e81c566c62bcee5da8fcbc234c08b4486a8d2bbf6d320f3c28dd85d9e28ab4a1f7ac961a2a00333700db345b206b24cb4e5f3901fb7306b35942c159d8fd3c

data/CHANGELOG.md

@@ -8,6 +8,33 @@ and commands may change between minor versions. How releases are made:
 
 ## [Unreleased]
 
+## [0.171.0] - 2026-11-14
+
+### Added
+
+- chi web: see what chi has of a working-set item: a row's ▸ in the working set list peeks at its latest edit or read, and "Open the timeline" (also a tool row's "timeline" and a file ref's "What chi has") shows every read as merged line slices over a strip of the file, every edit as its diff, slices chi no longer has greyed, and for a memory that changed since chi read it, the diff to what it says now.
+- chi web: a participant can attach images to their own turn (paste, drop or the image button); they see their own thumbnails only, up to 40 images per invite, within their cap.
+- chi web: a participant can Revise the answer to their own message (when no one else's turn came after it); the earlier version folds into a stack on every page, and a participant's page now draws Revise stacks too.
+
+### Changed
+
+- chi web: the opt-in reload check (`web.reload_check`) now compares a turn's cards and answered questions, not just its rows: a card or question a reload places differently is a mismatch.
+- chi web: a participant's message sent while their own turn runs now goes into that turn at its next step, as the owner's does; during someone else's turn it still waits and runs as their own turn after it.
+- chi web: a participant's link now opens the main page: the same conversation, live turn box and composer as the owner's, with their name and link expiry at the top, their spending against the cap under the composer, Stop turn on their own turns, "waiting for the owner" (and for what kind of thing) when their turn needs you, and the composer giving way to one line at their limit, in a stopped session or once their link ended. Your messages read "owner" to them; they get none of your controls and no file panel.
+- chi web: pressing Enter twice while a message is still being sent sends it once.
+
+### Removed
+
+- chi web: the separate participant page (with its Plan view of a review's files) and the owner's "Participant view ↗" in the participants panel.
+
+### Fixed
+
+- A reply that is only a tool call written as text, closing with `</tool_call>`, is asked again instead of taken as the answer.
+- chi web: a memory in the working set is marked stale when its file, or the model overlay read with it, changed since chi read it.
+- chi web: a page opened while a turn runs shows the context percent at once, not `ctx ?`.
+- chi web: in the iPhone Home Screen app, the top bar no longer sits in iOS's blurred band under the clock.
+- chi web: a question card folded in the turn box stays folded after a reload or when the page reconnects mid-turn.
+
 ## [0.170.0] - 2026-11-13
 
 ### Fixed
@@ -6289,7 +6316,8 @@ 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.170.0...HEAD
+[Unreleased]: https://github.com/dm1try/samagotchi/compare/v0.171.0...HEAD
+[0.171.0]: https://github.com/dm1try/samagotchi/compare/v0.170.0...v0.171.0
 [0.170.0]: https://github.com/dm1try/samagotchi/compare/v0.169.0...v0.170.0
 [0.169.0]: https://github.com/dm1try/samagotchi/compare/v0.168.0...v0.169.0
 [0.168.0]: https://github.com/dm1try/samagotchi/compare/v0.167.0...v0.168.0

data/docs/architecture.md

@@ -240,8 +240,8 @@ agent logic and can be used without any terminal rendering; the UI is a thin lay
   run's own prompts until their turns end; `#run` distinguishes an empty answer from a
   prompt this terminal removed before it ran (both exit 1), as well as chi's other outcomes.
   Without a capable terminal it falls back to `PlainSurface` (append-only).
-- The browser's page (`lib/samagotchi/web/public/`: `app.js` for the owner, `participant.js` for a participant) is a
-  client of chi web: where its state lives, which redraw follows which write, its render idioms, stale-answer guards,
+- The browser's page (`lib/samagotchi/web/public/`: `app.js`, the owner's and a participant's alike, with
+  `participant_main.js` for what is a participant's) is a client of chi web: where its state lives, which redraw follows which write, its render idioms, stale-answer guards,
   storage keys and streams are in [internals/web-frontend.md](internals/web-frontend.md).
 
 #### Using the core

data/docs/cli.md

@@ -1223,7 +1223,7 @@ threshold; its folded row shows its first line as typed). A delegate
 report itself starts folded. Folding is this browser's choice, kept per session in
 localStorage (`chi_answer_fold:<session id>`, the last 200 folded answers and prompts;
 the keys of sessions gone from the list are dropped when the list loads);
-other viewers and the participant page are not affected. A jump into a
+other viewers (a participant's browser too) are not affected. A jump into a
 folded answer (a claim link, say) unfolds it for that page load.
 
 **Revise** rewrites an answer and stacks the versions. A finished turn's
@@ -1246,8 +1246,13 @@ version on view, and the chip names it, "v1 of 3"); › back to the newest. Swit
 page shows, and a reload shows the newest again. Revise
 again on the newest version adds to the stack. Stacks are session data (the
 stamp is on the Revise prompt, see [sessions.md](sessions.md), Revise
-stacks): every owner's page shows them, live and after a reload; the
-participant page doesn't draw them yet. A session whose worker predates
+stacks): every page shows them, live and after a reload, a participant's too.
+A participant (`chi share`) gets Revise on the answer to their own message
+only, while no one else's turn (the owner's, another participant's, a wake
+turn's) came after it; the owner's answers have no button on their page, and
+a closed composer shows none. A send that came too late is refused with
+"someone else's turn came after this answer: send a new message instead",
+the text and the chip kept. A session whose worker predates
 Revise (started by an older chi) disables the button and shows the chip as
 "Revise: restart this session to use Revise"; a message sent then is a plain
 one. A Revise turn that fails comes back into the composer with its chip.
@@ -1336,7 +1341,7 @@ made (up to 120 lines or 8 KB), live and after a reload (see
 `web.view`, `chi web --web-view`, `SAMAGOTCHI_WEB_VIEW` and `?view=` were removed with the turn view (the
 stage is the only view; a config.yml that still sets `web.view:` warns about an unknown key).
 
-**When things happened**, on the owner's page and on a participant's review page: where 10 minutes or
+**When things happened**, on the owner's page and on a participant's: where 10 minutes or
 more of quiet passed between the end of one activity and the start of the next (a turn, a context
 note, a reminder), the history has one dim centred line, `── 14:32 · 47 min later ──`; the date is
 added when the day changed or the turn wasn't today (`── Sat 24 Oct 09:10 · 13 h later ──`).
@@ -1402,6 +1407,12 @@ session bar shows the `mem N` chip again.
   forgotten row offers `refresh`, the same add of it. While a turn runs the
   stage's rail shows an add queued for its end as a dashed `+ name · next turn`
   line.
+- **What chi has of an item**: a row's `▸` in the list peeks at it (its latest edit's diff, else its newest
+  read's first lines); `Open the timeline` (also a tool row's `timeline` and a file ref's ▾ `What chi has`) puts
+  the item's timeline over the stage, newest first: reads merged into line slices over a strip of the file, edits
+  as diffs, what chi no longer has greyed (with `undrop` for your drop), a changed memory's `Now · diff`. `← Stage`
+  or Esc goes back to the same place, ↑↓ step through the set; on a phone it is full screen (`‹ Set`, `‹ ›`).
+  Yours only: a participant's list has no `▸`.
 
 Only `read`, `edit`, `write`, `memory_read`, `memory_write` and `web_fetch`
 calls that succeeded count; files an `execute` touched don't.
@@ -1442,13 +1453,11 @@ On a touch screen (a phone, a tablet) the bar sits just above the composer
 instead of next to the selection, where the system's own Copy menu and the
 selection handles would cover it; several pills wrap to a second row.
 
-A review's participants get the same on their page (a `chi share` / `chi
-review` link): selecting text in the Plan or the thread quotes it into
-their comment box, labelled `From docs/plan.md:` or `From Sam's comment:`,
-with the same presets. Not in the owner's participant view, and no plugin
-pills there (a review turn refuses `/` lines).
+Participants get the same on their page (a `chi share` / `chi review`
+link, the main page): a selection quotes into their composer with the same
+presets; no plugin pills and no Copy link there.
 
-After the presets, both pages have a built-in **Verify**: the quote, then
+After the presets comes a built-in **Verify**: the quote, then
 an ask to check the claim against the code and end on a line `Verdict:
 confirmed|refuted|unclear — <reason>`. Verify is offered only on text in a finished turn's final answer, the
 claim a verdict card can come from; elsewhere (an earlier reply, a step, a message, a line added mid-turn, a turn
@@ -1738,7 +1747,9 @@ chi share revoke --all          # every link to every session
   message is a turn of its own, queued behind the running one, that the model answers **read-only**. It may read the
   project (never its secret files or chi's own), and proposes changes as text or a diff for you to apply; it can't
   write, run, fetch, send notes or set reminders, and any approval or question is yours. A line starting `!` or `/`
-  and images are refused. One running and 3 waiting turns per participant (`web.participants.queue`). You pay: each
+  is refused. A participant can attach images to their own messages (paste, drop or the image button; png, jpeg, gif
+  or webp), up to 40 per invite and within their cap, when the session's model takes images; they see only their own
+  images, anyone else's as "N images". One running and 3 waiting turns per participant (`web.participants.queue`). You pay: each
   participant has a spending cap (`--cap DOLLARS`, default $2, `web.participants.cap`), counted from their turns'
   cost and the side requests they cause; at the cap their next comment is refused and you get a notice, and `chi
   share cap` raises it. `/stats` shows each participant's spend. Their turns go only to a worker with the review
@@ -1763,16 +1774,20 @@ chi share revoke --all          # every link to every session
   Apply (they acted already). This is an accident guard for a trusted team, not containment: a pair turn can still
   send what it reads out through `web_fetch` or your MCP tools. A link without `--identity` gets the same access:
   share it only with people you'd let type in your session.
-- **The participant page.** Their link opens a page of its own (never yours): the session's title and status, who
-  else takes part, and the conversation as a participant sees it: every prompt and reply with who wrote it, each
-  step's tools as one line (`read docs/plan.md`: the tool and a project file's path, never arguments or output), and
-  the reply streaming in while a turn runs. A "Comment or ask" box sends their comment (your composer's box, with its
-  grip to resize or fold it and ↑/↓ over their own earlier comments from that browser; no `/` list, no images yet);
-  their queued comments show with **Take back**; "waiting for the owner" shows while you answer a question or an approval of the turn; a refused
-  comment (a `!` or `/` line, too many waiting, their cap reached) says why. On a phone it is the thread first with
-  the box pinned, tool lines folded. They never see tool output or arguments, thinking, approvals or questions,
-  memories, context notes, plugin and delegate input, cards, command output, the working set, cost, timing or host
-  paths; secret-shaped text (API keys, tokens, private keys) is redacted too. An agent participant can wait on its
+- **Their page is the main page.** Their link opens the page you use, as theirs: the session's title, their name
+  ("Alex · invited") and when the link ends, the conversation with the same folded steps, answers and live turn box
+  (what chi says, which tools and files it touches, the working set's file names; never thinking, tool arguments or
+  output), and the composer. Your messages read "owner" to them. Under the composer: the turn's status, the context's
+  fill, the speed (the turn's time while one runs) and what they spent of the cap you set ("$0.42 of $2.00 used").
+  While their own turn runs they can **Stop turn**, and a message goes in at its next step (Alt+Enter keeps it for
+  after the turn); while yours or another participant's runs, it goes in as their own turn afterwards. When their
+  turn waits for you (an approval, a question, your Continue) they see that it waits and for what kind of thing,
+  never its content. At their cap, in a stopped session, or once their link ended the composer gives way to one line
+  and the conversation stays readable. They get none of your controls: no new session, list, rename, model, images
+  (yet), session menu, participants panel, cards or approvals, and no file panel (they ask chi to quote what they
+  need). They never see tool output or arguments, thinking, approvals or questions, memories, context notes,
+  plugin and delegate input, cards, command output, your cost or host paths; secret-shaped text (API keys, tokens,
+  private keys) is redacted too. An agent participant can wait on its
   turns' replies through the API, or with chi: its link's token in a remote, `chi --remote NAME send --wait -m "…" ID`,
   or `send -m`, which prints the turn id `--wait --turn T` takes; that wait exits 3 with `waiting_for_owner` while
   their turn waits on you (a question, an approval, your step-limit Continue) and 1 with `refused` (`cancel_reason`
@@ -1787,8 +1802,7 @@ chi share revoke --all          # every link to every session
   then `2 participants`, with a green dot while one is on their page) opens the panel: each participant's state, last visit,
   spend against their cap, turns and expiry, with **Cap** and **Revoke** (revoking ends their page and stream and
   drops their queued comments). **Invite** takes a name, person or agent, the expiry and a cap, and shows the link
-  once, with Copy, Share (a phone's share sheet) and its QR code. **Participant view ↗** opens their page for this
-  session in a new tab, read-only, through the same server filter: exactly what they see. A participant's prompt
+  once, with Copy, Share (a phone's share sheet) and its QR code. A participant's prompt
   shows their name in their colour, live and after a reload.
 - `chi --remote studio share …` invites on studio: the link names studio's LAN address. Locally, the link names
   this machine's running chi web, on the port it listens on (it records it in `$XDG_STATE_HOME/samagotchi/web.json`;

data/docs/configuration.md

@@ -2385,7 +2385,7 @@ column says so, a `--kebab-name` flag. The maps (`hosts:`, `models:`,
 | `web.host` | `127.0.0.1` | yes | `127.0.0.1`, `::1` or `localhost`; `lan` (this machine's private IPv4 address) or one of its IPv4 addresses also opens `chi web` to the network, with an access token, asked of this machine's 127.0.0.1 too (its `Local:` link carries a one-time code; `chi web --new-token` replaces the token; it is chi web's one access token, also used by `--tunnel` and `web.public_url`/a proxy). Anything else binds `127.0.0.1` with a warning. See [CLI: chi web on your phone](cli.md#chi-web-on-your-phone). |
 | `web.markdown` | `false` | yes | Render answers as Markdown in `chi web`. |
 | `web.working_set` | `true` | yes | The stage view's working set: the files, memories and URLs a turn brought into the model's context, in a rail in the stage, a footprint as each finished turn's block summary and a `set N` chip in place of the mem chip; `false` brings the mem chip back. `?working_set=1` or `?working_set=0` on the page URL overrides it for that page load. See [CLI: the working set](cli.md#the-working-set). |
-| `web.reload_check` | `false` | yes | Opt-in: once each finished turn has moved into the history, the page reads the session again (one full read per turn end), draws that turn as a reload would and compares the two, strictly: a known divergence counts as a mismatch too. `chi web` logs one `reload_checked` line per check and a `reload_mismatch` line naming the kinds that differed, `excused` (the known divergences, `history_shape.js` `ACCEPTED`, that would explain them) and `explained` (all of them had one), with `turn_id`, `drawn` (the turn came back from its drawing, so a mismatch with `drawn: true` is a drawing bug), `undrawn` (how many of the reload's rows came without their turn's drawing, the page's plain fallback: 0 unless chi web missed a turn) and the worker's version: counts only, never content. The count is `grep -c reload_mismatch` over `grep -c reload_checked` in chi web's log, split by `excused`. Cards and answered question cards are left out: a reload places them after the render, which the check doesn't run (the e2e reload checks compare them). Every open owner tab runs the check; `chi web` logs a turn's first report only, and starts over when it restarts. |
+| `web.reload_check` | `false` | yes | Opt-in: once each finished turn has moved into the history, the page reads the session again (one full read per turn end), draws that turn as a reload would and compares the two, strictly: a known divergence counts as a mismatch too. `chi web` logs one `reload_checked` line per check and a `reload_mismatch` line naming the kinds that differed, `excused` (the known divergences, `history_shape.js` `ACCEPTED`, that would explain them) and `explained` (all of them had one), with `turn_id`, `drawn` (the turn came back from its drawing, so a mismatch with `drawn: true` is a drawing bug), `undrawn` (how many of the reload's rows came without their turn's drawing, the page's plain fallback: 0 unless chi web missed a turn) and the worker's version: counts only, never content. The count is `grep -c reload_mismatch` over `grep -c reload_checked` in chi web's log, split by `excused`. The turn's own cards and answered questions are compared too: a drawn turn already renders its plugin cards, and the snapshot's questions (and an undrawn turn's entries) are placed into the offscreen render by the page's own placer with inert hooks (`cards_offscreen.js`). A card counts as the same when it has the same id and title in the same place, a question when its summary line and the kept reply's plain line do; bodies, buttons, folds and the tag a card is drawn in are ignored. Only entries CardStore attributes to this turn (`of_turn`) are compared: a card of another turn or between turns is dropped by id, and a question the read gives no turn and no opening stamp for (an older worker) is left out on both sides. Between-turn cards and notices stay with the e2e reload checks. Every open owner tab runs the check; `chi web` logs a turn's first report only, and starts over when it restarts. |
 | `web.annotate_presets` | `Agreed\|Could you please elaborate?` | yes | Quick replies next to Annotate in `chi web`, `\|`-separated (a YAML list works too); `""` in the file or on the CLI leaves only Annotate (an empty env value means the default). See [CLI](cli.md#web-annotate-presets). |
 | `web.editor` | `vscode` | yes | What a file ref in `chi web` (a file tool row's title, a diff line) opens, for a viewer on this machine: a preset (`vscode`, `vscode-insiders`, `cursor`, `zed`) or a URL template with `{path}` and an optional `{line}`; `none` turns refs off. See [Opening files from chi web](#opening-files-from-chi-web). |
 | `web.start_dir` | the folder `chi web` runs in | | The folder `chi web` starts in (`chi web --start-dir DIR` for one run): its page (the printed link, a bare `/`, the LAN link and QR code, the Home Screen app) opens on that folder's project, outside a project (no repository or marked folder) on every session, and a new session from the all view starts there; the header's project picker switches projects. `~` and a relative path (resolved from your home folder) work; one that isn't a folder stops `chi web` from starting. `chi web` never changes its own folder. See [CLI](cli.md). |

data/docs/internals/block-renderers.md

@@ -18,8 +18,8 @@ model. The TUI is untouched: it shows a fence as source.
    made), then `Provenance#script_failure` (the check a context provider's scripts get too); a file with no recorded sha, a missing one or a changed one is 409
    `renderer_changed`, each with its own reason. ETag + `no-cache`, as static files. A `block_renderers:` list that
    doesn't parse is logged once per bundle and problem (each list request and file fetch reads it).
-3. `block_watch.js` (`createBlockWatch`, made by `block_host.js`'s `createBlockHost`, wired in `app.js`; `participant.js`
-   isn't) finds and watches the blocks; `block_host.js` is its frame drawer (`createFrameDrawer`). The watcher asks an
+3. `block_watch.js` (`createBlockWatch`, made by `block_host.js`'s `createBlockHost`, wired in `app.js`; a participant's page
+   gets the core drawers only, no bundle's renderers: `block_renderers`) finds and watches the blocks; `block_host.js` is its frame drawer (`createFrameDrawer`). The watcher asks an
    ordered list of drawers, core ones first (`inline_widgets.js` for `chi-ui`: [inline-widgets.md](inline-widgets.md)), then the frame drawer, which waits for `/api/block_renderers`;
    the first that `claims` the block's language draws it, and a language none claims is left alone. The contract
    (`claims`, `needsDraw`, `draw`, its `reconsider`, `sessionChanged`) is in the module's header. The shared DOM

data/docs/internals/bridge.md

@@ -57,8 +57,10 @@ Three other users: `replay_events(turn)` turns a `current_turn` back into the li
 `command_queued` per waiting command), which chi web's `GET /api/sessions/:id` sends as `replay` from the worker's
 snapshot (`from_wire` symbolizes it), so any worker's snapshot gives the page the same events
 (`spec/shared/turn_snapshot.json` pins it); `messages_of` gives a
-plugin's `ctx.messages` the turn so far (`Engine#running_turn_messages`); `participant_turn?` tells `POST /turn` that
-a participant's review turn runs, so the owner's input queues behind it.
+plugin's `ctx.messages` the turn so far (`Engine#running_turn_messages`); `participant_author` (and
+`participant_turn?`) tell `POST /turn` whose turn runs: input goes into it only from its own author
+(`Bridge#same_author_steer?`), so the owner's input queues behind a participant's turn, and a participant's goes in at
+the next step of their own turn only.
 
 ## TurnDrawings
 
@@ -618,8 +620,7 @@ successor from the old worker); chi web's `App#worker_link` / `#await_worker_lin
 `bridge_error` / `bridge_secret` for a refused Bridge; 200 only after the Bridge answers; full history of any session
 is served by `GET /api/sessions/:id/output`). It opens the Bridge before answering and gives the one opened socket to
 `App#proxy_stream_body` / `ProxyStreamBody`, which closes it when the body or hijacked client ends. The owner's stream
-is a byte pipe; the body gives it the request's frame filter (`App#stream_filter`: nil for the owner; for a participant, and the owner's participant view
-`?as=participant`, a `Web::ParticipantStreamFilter`, which cuts the Bridge's chunks into frames and writes each again
+is a byte pipe; the body gives it the request's frame filter (`App#stream_filter`: nil for the owner; for a participant, a `Web::ParticipantStreamFilter`, which cuts the Bridge's chunks into frames and writes each again
 from `Web::ParticipantView.event`'s allowlist, dropping every other event; only `from_seq` and `snapshot` reach the
 Bridge; [internals/participants.md](participants.md#what-a-participant-sees)). Resume/ring-buffer state is **in-memory**, per worker: a cursor from
 an earlier worker gets the `reset` snapshot, not a replay.

data/docs/internals/context-telemetry.md

@@ -24,7 +24,10 @@ next turn's estimate before its first count uses it instead of
 Emission behavior:
 
 - The estimate is emitted on every request (both loops, before each request),
-  so the web and the attached TUI get a fresh number each time.
+  so the web and the attached TUI get a fresh number each time; the Engine also
+  keeps the last one it saw (`@last_context_status`, from the stream handler),
+  so a page or TUI that joins while a turn runs reads it from
+  `session_state_snapshot` at once instead of waiting for the turn to end.
 - The model's own `[CONTEXT: …]` line is still gated: it is left only on a rise
   into a guidance bucket (from the second threshold up), never on a fall, and
   not again for a bucket a resumed session's line already names.
@@ -54,6 +57,15 @@ plain `Context window unknown` after it, and for a session whose window lookup f
 session's first counted turn. A
 hook's switch (`before_turn`) sends nothing: its turn's first request counts on the new model anyway.
 
+The owner's show (`Web::SessionShow#shown_session_json`) passes the snapshot's
+`context_status` to the page as `session.context_status`, which
+`session_state.js#sessionStateFrom` reads as the ctx percent before any stream
+event (it wins over the saved fill). With a window known and no percent yet,
+`ctxBarTip` says `No context count yet: the next request counts it`; while the
+session's turn runs (`window.running`, the info bar's own flag) the tooltip's
+title is `Context in use (this turn so far)` rather than `Context used after
+the last turn`.
+
 A process that loads the session on another model than its last turn ran on (`Engine#session=`:
 `SessionMetrics#last_model_ref` differs from `effective_model_ref`; a `--resume`'d one-shot with `--model`, a worker woken
 after a `/model` with no turn since) drops the old window (`forget_model_reports!`) and calls

data/docs/internals/engine.md

@@ -688,10 +688,10 @@ announced at once, marked `anytime: true`, **never as the running turn's events*
 Both loops, unless marked:
 
 - <a id="a-reply-that-is-only-a-tool-call"></a>**A reply that is only a tool call** (`LLM::StrayToolCall`, chat loop
-  only): a reply with no tool calls whose whole text is one tool-call block closed by the tag that opened it
-  (`<function=` by `</function>`, `<parameter=` by `</parameter>` or `</function>`, `<tool_call>` by
-  `</tool_call>`; inner tags not needed) isn't an answer. Prose or a fence before it, or anything after the close,
-  keeps it an answer. Nothing is guessed from the block and it never enters the history (`:generation_completed` and
+  only): a reply with no tool calls whose whole text is one tool-call block closed by the tag that opened it, or by
+  the wrapper's `</tool_call>` (`<function=` by `</function>` or `</tool_call>`, `<parameter=` by `</parameter>`, `</function>`
+  or `</tool_call>`, `<tool_call>` by `</tool_call>`; inner tags not needed) isn't an answer. Prose or a fence before it, or anything
+  after the close, keeps it an answer. Nothing is guessed from the block and it never enters the history (`:generation_completed` and
   `:after_generation` have already seen the text): `:generation_retrying`
   with `restarted` voids the streamed text, `:empty_answer_retry` with `malformed` goes out, and a hidden
   `TurnNote.malformed_retry` asks again at the retry temperature. Its own budget (`retry.empty_answer: 0` doesn't turn

data/docs/internals/inline-widgets.md

@@ -136,7 +136,7 @@ same cleaned id (`rowId`, one rule for both), so what is drawn is what fills. A
 strings reach the page through `textContent` and attributes only, never `innerHTML`, so a step reading
 `<img src=x onerror=…>` shows as those characters.
 
-**What doesn't draw.** The participant page (`participant.js` wires no block host), `web.markdown` off (no
+**What doesn't draw.** `web.markdown` off (no
 `data-lang`), a live answer while it streams (its YAML shows until the turn's end re-renders it as markdown), and
 anything outside `TEXTS`: cards, question replies, a lead-in bubble, delegate reports. The terminal shows the YAML.
 

data/docs/internals/objectives.md

@@ -213,7 +213,7 @@ command), which absorbs the file. It no longer waits for the fallback tick.
   (completed, canceled, failed, in `turnEnded`), `data-participant` for a participant's turn (from `turn_started`'s
   author live, the prompt's author in `drawnGroupPieces`), and each row's `data-tool` (also `turn_html.js
   toolRowTemplate`, so live and reloaded rows stay the same markup). A pair turn's `objectives` call is always denied,
-  so without the participant stamp every pair turn that edits would get it. The participant page draws none of this.
+  so without the participant stamp every pair turn that edits would get it. A participant's page draws none of this (their show carries no objectives).
 - **The tracker** (`objectives_track.js`, a module of its own for the same reason): the list's row under an item it read
   says `tracker: no sign — nothing ran for it · 14:32` (`.obj-track`), with weight and the warn colour when it differs
   from the agent's last move's state (`trackDiffers`: a move to compare with, a reading other than no answer), faded when