samagotchi 0.111.1 → 0.112.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 2153d4c9c7afa58d9d06d330d1839a021032df3502f515d4a093bad7f9dde347
-  data.tar.gz: 9ac11fddf172afa0eb4c5ea520d3e64471c0b2502753539fafcce28aa4e99294
+  metadata.gz: bd818cf8fcf56a7040bdf84299d75a547b2031eb7bea13a1fdb087d12ed051d0
+  data.tar.gz: 27890e5a3913053d11b5240c66f335ac66e0c5b4e55a9c0410b7a885ec9319d3
 SHA512:
-  metadata.gz: cc73ef6cdd220a1dfb83b4e1b6f51ba4e42c80eff05ae661363b06d4d53b9bf4c0c2c954173997475571518ed98e7f589afe0eb9251787e3a894eab8dd1fec00
-  data.tar.gz: 9105631a20fcfe1e6889dbc904e146c4fcc68c75e5879111e589efe515ecaaecd4e03b6e7a3f389eb674bd1b0c0bb6a1420dca439b01cdefe04ed508d0830c9a
+  metadata.gz: 44e69d35e152608b949071ca95d22367115c8524c284378a1e854ab98636e40f8f53bd5644bd816bfa903a2f3125e3c09a2f297999d4c251ee1bed6bf7a10e52
+  data.tar.gz: d47e33d2b044590f507f3f551b179c60aa848e11ca79c9543d3f1af2a4b199f9ffee9bfa590488f66a0b439c65e7600a05c4c2caa335b4c26534782929d6c89e

data/CHANGELOG.md

@@ -8,6 +8,33 @@ and commands may change between minor versions. How releases are made:
 
 ## [Unreleased]
 
+## [0.112.0] - 2026-10-25
+
+### Added
+
+- chi web: the phone's push notifications now come for everything the tab notifies for: a step-limit question, a card
+  that asks (check-in's Nudge / Keep going / Stop) and a failed turn, beside approvals and questions. Done turns are
+  off by default, per device (the switch comes with the devices list).
+- chi web: no push while a chi web page is in front and was touched in the last 2 minutes (you are looking); at most
+  30 pushes an hour; a busy push service is tried once more; an approval asked while chi web was restarting is pushed
+  once when it starts.
+
+### Changed
+
+- chi web: an untitled session's card, top bar and browser tab read its recap's first sentence (what the session is
+  doing) instead of its first message, so long-lived sessions started the same way no longer look alike; the card
+  then leaves out its recap line, and a session with no recap yet still reads its first message.
+
+### Fixed
+
+- chi web: tapping the composer (or any other text field) on an iPhone or iPad no longer zooms the page in. Text
+  fields are 16px on phones and touch devices, the size under which iOS Safari zooms on focus (and the Home Screen
+  app never zooms back); a mouse desktop keeps its sizes.
+- chi web: the sessions list's cards on an iPhone show their whole preview, title and recap again instead of cutting
+  them through the middle.
+
+Update with `chi update` (the system bundle 0.112.0), then restart `chi web`.
+
 ## [0.111.1] - 2026-10-25
 
 ### Fixed
@@ -4264,7 +4291,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.111.1...HEAD
+[Unreleased]: https://github.com/dm1try/samagotchi/compare/v0.112.0...HEAD
+[0.112.0]: https://github.com/dm1try/samagotchi/compare/v0.111.1...v0.112.0
 [0.111.1]: https://github.com/dm1try/samagotchi/compare/v0.111.0...v0.111.1
 [0.111.0]: https://github.com/dm1try/samagotchi/compare/v0.110.0...v0.111.0
 [0.110.0]: https://github.com/dm1try/samagotchi/compare/v0.109.0...v0.110.0

data/docs/architecture.md

@@ -701,8 +701,8 @@ A map of the parts the overview above doesn't name (paths under `lib/samagotchi/
 | 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)). |
-| chi web's routes | `web/app.rb` (`Web::App`: the gate, `ROUTES`, the shared helpers), `web/message_display.rb` (`Web::MessageDisplay`: saved messages and cards as display items, `POST /api/render`), `web/session_show.rb` (`Web::SessionShow`: `GET /api/sessions/:id` with its `cards`, `tail` and `timing` re-reads, `GET …/output`, the timing payload), `web/session_create.rb` (`Web::SessionCreate`: `POST /api/sessions`, a continue, a review fork), `web/session_control.rb` (`Web::SessionControl`: answer, command, turn and images, cancel, stop, restart, archive, delete), `web/push_routes.rb` (`Web::PushRoutes`: `/api/push`, its subscriptions and test) | The handlers `App`'s `ROUTES` name, in the file that holds their kind; each mixin is included in `App` and reads its helpers and ivars, so `app.send(:handle_show, …)` and the specs that stub `App` methods work as before. |
-| Web Push | `web/push.rb` (`Web::Push`: `Runtime`, `preflight!`, the `web.push.*` settings), `web/push/crypto.rb` (`Push::Crypto`: RFC 8291 aes128gcm, RFC 8292 VAPID), `web/push/store.rb` (`Push::Store`, `Store::Sub`: `web-push/vapid.pem`, `subscriptions.json`), `web/push/client.rb` (`Push::Client`, `Client::Result`), `web/push/attention.rb` (`Push::Attention`: notify.js's rules in Ruby), `web/push/notifier.rb` (`Push::Notifier`, a hub subscriber with a sender thread), `web/push_routes.rb` (`Web::PushRoutes`), `web/private_files.rb` (`Web::PrivateFiles`, shared with the grants), `public/sw.js`, `public/push.js`, `public/manifest.webmanifest` | chi web pushes approvals and questions to the owner's Home Screen app over an https public URL: the Notifier turns the hub's new approvals and questions into show pushes after a hold (each carries the keys still open, and the badge; no close push: every push shows a notification); the bell (`notifications.js`) subscribes the device, and the service worker and the page close the answered ones. See [internals/web-push.md](internals/web-push.md). |
+| chi web's routes | `web/app.rb` (`Web::App`: the gate, `ROUTES`, the shared helpers), `web/message_display.rb` (`Web::MessageDisplay`: saved messages and cards as display items, `POST /api/render`), `web/session_show.rb` (`Web::SessionShow`: `GET /api/sessions/:id` with its `cards`, `tail` and `timing` re-reads, `GET …/output`, the timing payload), `web/session_create.rb` (`Web::SessionCreate`: `POST /api/sessions`, a continue, a review fork), `web/session_control.rb` (`Web::SessionControl`: answer, command, turn and images, cancel, stop, restart, archive, delete), `web/push_routes.rb` (`Web::PushRoutes`: `/api/push`, its subscriptions, prefs, test and presence) | The handlers `App`'s `ROUTES` name, in the file that holds their kind; each mixin is included in `App` and reads its helpers and ivars, so `app.send(:handle_show, …)` and the specs that stub `App` methods work as before. |
+| Web Push | `web/push.rb` (`Web::Push`: `Runtime`, `preflight!`, the `web.push.*` settings), `web/push/crypto.rb` (`Push::Crypto`: RFC 8291 aes128gcm, RFC 8292 VAPID), `web/push/store.rb` (`Push::Store`, `Store::Sub`: `web-push/vapid.pem`, `subscriptions.json`), `web/push/client.rb` (`Push::Client`, `Client::Result`), `web/push/attention.rb` (`Push::Attention`: notify.js's rules in Ruby, shared cases in `spec/fixtures/attention_cases.json`), `web/push/presence.rb` (`Push::Presence`: the pages' "in front" reports), `web/push/notifier.rb` (`Push::Notifier`, a hub subscriber with a sender thread), `web/push_routes.rb` (`Web::PushRoutes`), `web/private_files.rb` (`Web::PrivateFiles`, shared with the grants), `public/sw.js`, `public/push.js`, `public/manifest.webmanifest` | chi web pushes what the tab notifies for (approvals, questions, step-limit questions, cards, failed turns; done turns to a device that asks) to the owner's Home Screen app over an https public URL: the Notifier turns the hub's new attentions into show pushes after a hold, unless a chi web page is in front, at most 30 an hour, with one retry and a restart catch-up (`sent.json`) (each carries the keys still open, and the badge; no close push: every push shows a notification); the bell (`notifications.js`) subscribes the device, and the service worker and the page close the answered ones. See [internals/web-push.md](internals/web-push.md). |
 | Behind an auth proxy | `web/public_url.rb` (`Web::PublicUrl`: `web.public_url`, `web.proxy.identity_header`, `web.proxy.owner`), `web/proxy_gate.rb` (`Web::ProxyGate`, mixed into App; `RawHeaderNames`, prepended to WEBrick's request by `Web::Server`), `web/link_codes.rb` (`Web::LinkCodes`: the links' one-time codes), `proxy_trace.rb` (`ProxyTrace`), `web/public/token_fragment.js`, `web/public/auth_lost.js`, `web/tunnel.rb` + `web/tunnel/tailscale.rb` (`Web::Tunnel`, `Web::Tunnel::Tailscale`: `chi web --tunnel tailscale`, Tailscale Serve set for one run and the PublicUrl it makes) | Experimental: chi web behind an auth proxy. Every request needs the token; a proxied one's owner also needs the identity header (one clean value under one name); the `__Host-` cookie, an absolute `Location` from the public URL, https links with a one-time code in the fragment; the page's lost-sign-in banner. Bridges refuse proxy traces ([configuration.md](configuration.md#behind-an-auth-proxy)). |
 | Participants | `participants.rb` (`Participants`, the `participants.json` sidecar), `share_command.rb` (`ShareCommand`, `chi share`), `session_participants.rb`, `participants_watch.rb`, `web/grants.rb` (`Web::Grants`), `web/principal.rb` (`Web::Principal`), `web/participant_access.rb` (`Web::ParticipantAccess`: the participant's gate and routes), `web/participants_admin.rb` (`Web::ParticipantsAdmin`: the owner's invite, list, revoke, cap and Apply routes), `web/participant_review.rb` + `web/participant_view.rb` (`Web::ParticipantReview`, `Web::ParticipantView`), `web/participant_stream_filter.rb`, `guardrails/review_boundary.rb` + `guardrails/review_paths.rb` | The people or agents an owner invites to review one session through chi web: their grants and gate, what they read, their read-only review turns ([internals/participants.md](internals/participants.md), [guardrails.md](guardrails.md)). |
 | Analytics | `analytics_file.rb` (`AnalyticsFile`), `session_metrics/totals.rb` (`SessionMetrics::Totals`), `session_metrics/model_segment.rb` (`SessionMetrics::ModelSegment`) | A session's `analytics.json` (`SessionMetrics#persist`); the sums over its turn records (`Totals`: tokens, cost, speeds, kept as running counters) and their split per model after a `/model` switch (`ModelSegment`: a run of turns on one model, the `model_segments` rows); `session_metrics/cost.rb` (`SessionMetrics::Cost`): the spend `ctx.cost` reads; `session_metrics/usage.rb` (`SessionMetrics::Usage`): the work `ctx.usage` reads. `session_metrics/side_totals.rb` (`SessionMetrics::SideTotals`) and `side_usage.rb` (`SideUsage`): the side requests' sums, apart from the turns'. |

data/docs/configuration.md

@@ -1770,10 +1770,11 @@ Tailnet Lock is off: a device Tailscale's servers add to your tailnet could reac
 
 ### Phone notifications (Web Push)
 
-chi web as an app on your iPhone's Home Screen that buzzes (the Watch too) when a session waits on an **approval** or
-a **question**, also while the app is closed. A tap opens that session; once it is answered anywhere (the Mac, the
-phone, `chi answer`), its notification goes when you open the app (or swipe it away). Every
-push shows a notification: iOS turns off an app's pushes after a few that show none.
+chi web as an app on your iPhone's Home Screen that buzzes (the Watch too) when a session needs you: an
+**approval**, a **question**, a **step-limit** question, a **card** that asks (check-in's Nudge / Keep going / Stop),
+or a **failed turn**, also while the app is closed. A tap opens that session; once it is answered anywhere (the Mac,
+the phone, `chi answer`), its notification goes when you open the app (or swipe it away; a failed turn's stays until
+you do). Every push shows a notification: iOS turns off an app's pushes after a few that show none.
 
 What it needs:
 
@@ -1787,18 +1788,26 @@ app → tap the **bell** at the top → Allow. A test notification arrives at on
 bell again to turn it off on that phone. In a browser tab the bell stays the tab's own notifications (while the tab
 is in the background), as before.
 
-- **What is sent**: the session's name and the reason ("needs approval", "needs an answer"), never the question or
-  the command, as the tab's notification on the Mac. The session's name shows on the lock screen and the Watch.
+- **What is sent**: the session's name and the reason ("needs approval", "needs an answer", "hit its step limit",
+  "needs you", "turn failed", "done in N s"), never the question or the command, as the tab's notification on the
+  Mac. The session's name shows on the lock screen and the Watch.
 - **What Apple sees**: the push is end-to-end encrypted to the phone; Apple's push service sees that this machine
   pushes to that device, and when. A subscription holds no device name and no personal data (an opaque address on
   `web.push.apple.com` and two keys); chi names it itself ("iPhone · 2026-10-24", from the User-Agent's device class
   and the date).
-- **When**: an approval or a question that is still open 3 s after it was asked (3.5 s for a delegated child's
-  approval, which its parent may relay instead); one push per question; a step-limit question, a failed or a long
-  turn don't push yet. A push arrives even while you look at the page (the phone can't tell chi web that it is in
-  front yet).
-- **The files**: `$XDG_STATE_HOME/samagotchi/web-push/` (next to `web-token`): `vapid.pem` (chi web's key) and
-  `subscriptions.json` (the devices), 0600 in a 0700 folder; chi web refuses to start when others can read them.
+- **When**: the same things the tab notifies for, still open 3 s after they came (3.5 s for a delegated child's
+  approval, which its parent may relay instead); one push each. A delegated child's failed or finished turn is its
+  parent's to report. **Done turns** (10 s or longer, or one nobody started: a delegate's report, a context change, a
+  finished task) are **off** by default, per device; the switch comes with the devices list (for now:
+  `PATCH /api/push/subscriptions/ID {"prefs": {"done": true}}`, the id from `GET /api/push`'s `devices`).
+- **Quiet while you look**: nothing is pushed while any chi web page (a tab on the Mac, or the app) is in front and
+  was touched in the last 2 minutes; what came meanwhile is never pushed later (the page has it). A page left in
+  front untouched stops quieting the phone after about 2 minutes.
+- **Limits**: at most 30 pushes an hour (the rest are dropped, with one warning on chi web's terminal); a busy push service is tried once more. An approval or question asked while chi web was stopped or
+  restarting (under an hour ago, still open) is pushed once when it starts; the first restart after updating may
+  push one you already saw, once.
+- **The files**: `$XDG_STATE_HOME/samagotchi/web-push/` (next to `web-token`): `vapid.pem` (chi web's key),
+  `subscriptions.json` (the devices) and `sent.json` (what was pushed in the last day), 0600 in a 0700 folder; chi web refuses to start when others can read them.
   Subscriptions belong to the public URL they were made on: after renaming the machine or the tailnet, turn the bell
   on again on the phone (the old ones are never sent to). iOS can drop a subscription without telling chi web; if
   notifications stop arriving, turn the bell off and on again: the new subscription replaces the dead one.
@@ -1940,7 +1949,7 @@ column says so, a `--kebab-name` flag. The maps (`hosts:`, `models:`,
 | `web.public_url` | | | Experimental. The https origin people open `chi web` at through an auth proxy (`https://host` or `https://host:port`, no path); set, every request needs the access token, this machine's too, and links use it. A value that isn't an https origin stops `chi web` from starting. See [Behind an auth proxy](#behind-an-auth-proxy). |
 | `web.proxy.identity_header` | | | Experimental. The request header the proxy puts the signed-in user's email in (`X-Forwarded-Email` for oauth2-proxy), checked next to the token: only one the proxy sets *and* replaces. Unset or `none`: the token alone decides. See [Behind an auth proxy](#behind-an-auth-proxy). |
 | `web.proxy.owner` | | | Experimental. Your email as the identity header carries it (any case): a proxied request is the owner only with this identity and the token. Unset: nobody is the owner by identity. Needs `web.proxy.identity_header`. |
-| `web.push.enabled` | `true` | | Push notifications to a phone's Home Screen app (approvals and questions) when the bell there is on. Does anything only with an https public URL (`web.public_url`, or `chi web --tunnel tailscale`'s) and once a device subscribed; `false` turns the pushes and the routes off. See [Phone notifications](#phone-notifications-web-push). |
+| `web.push.enabled` | `true` | | Push notifications to a phone's Home Screen app (approvals, questions, step-limit questions, cards, failed turns; done turns per device) when the bell there is on. Does anything only with an https public URL (`web.public_url`, or `chi web --tunnel tailscale`'s) and once a device subscribed; `false` turns the pushes and the routes off. See [Phone notifications](#phone-notifications-web-push). |
 | `web.push.contact` | the public URL | | The contact the push services see in chi web's VAPID token: a `mailto:` address or an `https://` URL. Anything else stops `chi web` from starting (Apple refuses it). |
 | `history.file` | state dir | | Prompt history path, shared by the TUI and the web composer. |
 | `no_interrupt` | `false` | `--no-interrupt` | Raise the step limit of a turn to 1000 (or `turn.max_iterations`, when larger); a top-level key. |

data/docs/internals/web-push.md

@@ -1,17 +1,19 @@
 # Web Push (internals)
 
-chi web pushes to the owner's phone when a session waits on an approval or a question: the phone runs chi web as a
-Home Screen app (iOS 16.4+), its bell subscribes the device, and chi web, the only sender, pushes through the
-device's push service (Apple's `web.push.apple.com`). The user side is in
-[configuration.md](../configuration.md#phone-notifications-web-push). This page is how it is built (P1 of the plan:
-approvals and questions; the step-limit question, cards, failed and done turns, presence and the device list come
-later).
+chi web pushes to the owner's phone when a session needs them, for what the tab notifies for: an approval, a
+question, a step-limit question, a card with actions, a failed turn, and (per device, off by default) a done one. The
+phone runs chi web as a Home Screen app (iOS 16.4+), its bell subscribes the device, and chi web, the only sender,
+pushes through the device's push service (Apple's `web.push.apple.com`). The user side is in
+[configuration.md](../configuration.md#phone-notifications-web-push). This page is how it is built (P1 and P2a of the
+plan; the devices list in the page and `chi web push` come later).
 
 ```
 SessionHub ──emit──▶ Notifier#call(event) ──Queue──▶ sender thread
-                         Attention rules               hold 3 s → still open?
+                         Attention rules               hold 3 s → still open? a page in front? the cap?
                                                        Crypto.encrypt + VAPID → Client#deliver(endpoint)
                                                        201 ok · 404/410 drop the device · 403 BadJwtToken stop + log
+                                                       429/5xx one retry · handled keys → sent.json
+                     page ──POST /api/push/presence──▶ Presence (in front, touched < 2 min)
 service worker ◀── Apple (web.push.apple.com) ◀──────── {v, kind: show, tag, title, body, url, badge, open?}
 ```
 
@@ -50,8 +52,14 @@ files, one per machine, never in config.yml:
   another key and makes a new one.
 - `subscriptions.json`: `{"version": 1, "subscriptions": [{id, endpoint, keys: {p256dh, auth}, origin, label,
   created_at, last_ok_at, last_error, prefs}]}`, read as `Store::Sub` values. `id` is the first 8 hex of the
-  endpoint's SHA-256: the only name of a device outside the store. `Sub#public_h` and `#inspect` never carry the
-  endpoint or the keys; neither do the log lines.
+  endpoint's SHA-256: the only name of a device outside the store. `Sub#public_h` (id, label, origin, the dates,
+  `last_error`, `prefs: {done:}`) and `#inspect` never carry the endpoint or the keys; neither do the log lines.
+  `prefs` is `{"done": false}` until `Store#set_prefs(id, done:, origin:)` (the PATCH route) sets it; `Sub#done?`.
+- `sent.json`: `{"version": 1, "keys": {KEY: iso time}}`, the attention keys already handled (a device took the
+  show, or it was skipped while a page was in front, or capped), written by `Store#mark_sent` under `store.lock`,
+  keys older than a day (`SENT_KEEP`) pruned on each write. `Store#sent_keys` reads it; one that doesn't read is
+  logged once (`push_sent_corrupt`) and read as none, and the next write replaces it (it only spares a restart's
+  repeat). It is in `check_permissions!`'s list.
 
 `Store#add` checks what `pushManager.subscribe` gave, one message per refusal (the route answers it as 400
 `invalid_subscription`): an endpoint and both keys; https on port 443 without userinfo, at most 2048 bytes; a host in
@@ -73,9 +81,11 @@ tailnet leaves the old ones stale (never sent to: a tap would open an origin tha
 ## The client (`web/push/client.rb`)
 
 `Client#deliver(sub, payload, ttl:, urgency:)` encrypts the payload's JSON, POSTs it over TLS (open 5 s, read 10 s,
-no redirects, no retry) with `Content-Encoding: aes128gcm`, `TTL`, `Urgency` and the VAPID header, and answers a
-`Client::Result`: `:ok` (200/201/202), `:gone` (404/410: the device dropped it), `:bad_jwt` (403 with
-`BadJwtToken`), `:failed` (anything else; a connection error as its class name or `timeout`, never its message). The
+no redirects, no retry of its own) with `Content-Encoding: aes128gcm`, `TTL`, `Urgency` and the VAPID header, and
+answers a `Client::Result`: `:ok` (200/201/202), `:gone` (404/410: the device dropped it), `:bad_jwt` (403 with
+`BadJwtToken`), `:failed` (anything else; a connection error as its class name or `timeout`, never its message).
+A 429 or 5xx also carries `retry_after`: its `Retry-After` delta-seconds up to `RETRY_MAX` 60, else (missing, an
+HTTP date) `RETRY_DEFAULT` 10; nil for anything else, a connection error too (it may have been delivered). The
 transport is injectable: `spec/web/push/client_spec.rb` runs a fake push service (WEBrick, plain http through the
 injected transport) that decrypts each body with the device's key and checks the headers and the JWT.
 
@@ -84,18 +94,20 @@ injected transport) that decrypts each body with the device's key and checks the
 The service worker is the only reader of the payload (JSON, at most `Notifier::OPEN_LIMIT`, 3000 bytes, with
 `open`; one aes128gcm record leaves 3993 bytes of plaintext under Web Push's 4096: 86 header, 1 delimiter, 16 tag):
 
-- `{"v":1,"kind":"show","tag":KEY,"title":…,"body":…,"url":"/#/s/<id>","badge":N,"open":[KEY…]}`: TTL 12 h,
-  `Urgency: high`. `open` only while the whole list fits the limit; the test push (`chi:test`) has neither `open`
-  nor `badge`.
+- `{"v":1,"kind":"show","tag":KEY,"title":…,"body":…,"url":"/#/s/<id>","badge":N,"open":[KEY…]}`: a waiting
+  reason's (approval, question, continue, card) TTL 12 h (`SHOW_TTL`), `Urgency: high`; a failed or done turn's
+  TTL 10 min (`EVENT_TTL`), `Urgency: normal`. `open` only while the whole list fits the limit; the test push
+  (`chi:test`) has neither `open` nor `badge`.
 
-`badge` and `open` are the keys still open in the Notifier's summaries (`Attention.open_keys`: a pending approval
-or question, a hook's too, not relayed), so an approval pushed by an earlier chi web run still counts after a
-restart. `public/sw.js` is a classic script (module service workers on iOS are unverified) at scope `/`. Every push
+`badge` and `open` are the waiting keys still open in the Notifier's summaries (`Attention.open_keys`: a pending
+question of any reason, a hook's and a continue's too, not relayed, and a card with actions; never a failed or done
+turn), so an approval pushed by an earlier chi web run still counts after a restart. `public/sw.js` is a classic script (module service workers on iOS are unverified) at scope `/`. Every push
 event ends in `showNotification`: a payload that isn't a readable v1 show (no data, bad JSON, another `v`, a stale
 `close` from an older chi web, any other kind) shows a fallback (`chi` / "open chi", tag `chi:other`, url `/`), and a
 show iOS refuses is shown once more without its icon and data. A show calls `showNotification(title, {body, tag,
-icon, data: {url}})` first; then, when `open` is an array, closes every `getNotifications()` whose tag is a
-question's `"<sid>:<qid>"` (never `chi:*`), isn't the new one and isn't in `open` (after the show: closing before it
+icon, data: {url}})` first; then, when `open` is an array, closes every `getNotifications()` whose tag is a waiting
+key (`WAITING_TAG`: a question's `"<sid>:<qid>"` or a card's `"<sid>:card:<cid>"`, never `chi:*` nor a failed or
+done turn's `"<sid>:<ended_at>"`, whose time has colons), isn't the new one and isn't in `open` (after the show: closing before it
 fails on iOS; errors are swallowed); then `setAppBadge(badge)` when `badge` is a number. A tap focuses the app's first window and navigates it to the url, else opens one (only a path of chi web's); `install`
 skips waiting, `activate` claims the clients. A Home Screen app can stay open for days, and the browser checks for
 a newer `sw.js` only on `register()` and on navigations: so when the page comes back in front (`backInFront` in
@@ -111,17 +123,30 @@ transparency with black).
 
 ## The Notifier (`web/push/notifier.rb`) and its rules (`web/push/attention.rb`)
 
-`Push::Attention` is the server's port of `web/public/notify.js` for what P1 pushes, so a push and the tab's
-notification ring for the same thing under the same key:
-
-- `Attention.for(prev, next)`: a new `pending_question` id that isn't `relayed_to` (absent when nil: the summary
-  compacts it), whose **reason** (notify.js `questionReason`: `approval`, `continue`, anything else incl. `hook` is
-  a question) is approval or question. Filtering on the reason, never on `kind == "question"`, keeps hook questions.
-  A delegated child's (`parent_id`) approval or hook question holds `RELAY_HOLD` 3.5 s (notify.js `RELAY_HOLD_MS`):
-  its parent may relay it. The key is `"<sid>:<qid>"`.
-- `Attention.closed_keys(prev, next)`: the question answered, replaced, newly relayed, or the session gone.
+`Push::Attention` is the server's port of `web/public/notify.js`, so a push and the tab's notification ring for the
+same thing under the same key. **One set of rules for both sides**: `spec/fixtures/attention_cases.json` holds the
+cases (`attention`: `{name, prev, next, attention: {reason, key, hold_ms}|null, closed}` in the summary's JSON;
+`open_keys`: `{name, by_id, open}`), and `spec/web/push/attention_cases_spec.rb` (the summary's key types: symbols at
+the top and in `pending_question` / `pending_card`, strings in `last_turn`), `notify.test.js` (`attentionFor`,
+`closedKeys`) and `push.test.js` (`openPushKeys`) run every row. A change to either side adds its row there.
+
+- `Attention.for(prev, next)`, in notify.js's order:
+  1. a new `pending_question` id: none if it is `relayed_to` already (absent when nil: the summary compacts it);
+     else its **reason** (notify.js `questionReason`: `approval`, `continue`, anything else incl. `hook` is a
+     question), key `"<sid>:<qid>"`. A delegated child's (`parent_id`) approval or hook question holds `RELAY_HOLD`
+     3.5 s (notify.js `RELAY_HOLD_MS`): its parent may relay it.
+  2. a new `pending_card` id: `card`, key `"<sid>:card:<cid>"`.
+  3. a top-level turn whose `last_turn["ended_at"]` changed (a delegated child's is its parent's to report):
+     `failed`, or `done` when `completed` and `seconds` ≥ `DONE_MIN_SECONDS` 10 or its origin is in
+     `UNWATCHED_ORIGINS` (`delegate_report`, `context`, `task`); key `"<sid>:<ended_at>"`. A reminder turn follows
+     the same rules (no reminder event of its own).
+- `WAITING` (approval, question, continue, card) are the reasons that stay open until answered: badged, in `open`,
+  cleaned up, and pushed only while still open. A failed or done turn has nothing to answer.
+- `Attention.closed_keys(prev, next)`: the question answered, replaced, newly relayed; the card resolved or
+  replaced; both when the session is gone.
 - `Attention.text(summary, reason)`: notify.js `attentionText`'s words: the session's title, first preview or last
-  prompt clipped to 61, and "needs approval" / "needs an answer". Never the question or the command.
+  prompt clipped to 61, and "needs approval" / "needs an answer" / "hit its step limit" / "needs you" / "turn
+  failed" / "done in N s" (`last_turn["seconds"]` rounded). Never the question or the command.
 
 `Notifier#call(event)` is a `SessionHub` sink. **The hub calls it under its Monitor**, from the tick thread and also
 from chi web's request threads (`SessionHub#touch`, from the stop/archive/delete routes), so it only enqueues: a push
@@ -134,10 +159,30 @@ open already never pushes. The hub's projection is empty before its first scan,
 once after the `chi` line's subscribe and before `notifier.start(hub)`, then `hub.start`. Events that reach the sink
 before the seed is in (they are newer than the snapshot) are applied after it.
 
-The sender thread holds each show (`HOLD` 3 s, or the event's own), then pushes it only while its key is still in
-`Attention.open_keys` of the summaries (read under the sink's mutex at flush time), to every subscription on this
-run's origin, with that list as `open` and its size as `badge`. A close only drops a show still in its hold: it
-pushes nothing. Results: `:ok` stamps the device's
+The sender thread holds each show (`HOLD` 3 s, or the event's own); then a waiting one goes only while its key is
+still in `Attention.open_keys` of the summaries (read under the sink's mutex at flush time), a failed or done one as
+is. It goes to every subscription on this run's origin (a done turn only to those whose `prefs.done` is true), with
+that list as `open` and its size as `badge`, unless:
+
+- **a page is in front** (`Push::Presence#present?`, below): no send at all, `push_skipped reason: present` (no
+  device), and the key is handled (never pushed later: the tab's notification and badge have it);
+- **the cap**: `CAP` 30 shows in a rolling `CAP_WINDOW` hour, counted per show event (one to N devices is one; the
+  test push isn't the Notifier's): over it, not sent, handled, and one `push_capped` warning per hour (on chi web's
+  terminal too).
+
+A close only drops a show still in its hold: it pushes nothing. **Retry**: a result with `retry_after` (a 429 or
+5xx) puts that device's show in the sender's retry table (`Notifier::Retry`, per key and device, due like a hold:
+the sender never sleeps, other shows go out meanwhile; `push_retry` logs it); it goes once more to that device, still
+there, only while a waiting key is open (a failed or done one as is), with the open list of that moment, and isn't
+counted against the cap again. A second failure is final: `push_failed` and `last_error`, as any failure. A key a
+device took (first try or retry), or one skipped or capped, goes in `sent.json` (`Store#mark_sent`).
+
+**Restart catch-up**: `Session#waiting_question` carries the question's `created_at` (`PendingQuestion#created_at`,
+iso8601; the summary's `pending_question` has it, the page ignores it). `Notifier#seed` shows each seed summary's
+open, not relayed question asked under `CATCH_UP` (an hour) ago whose key isn't in `sent.json` (`push_catch_up`):
+asked while chi web was down or restarting, it gets the normal hold, presence and the cap. Everything else seeds as
+before (cards carry no time). The first restart after P2a may push a seen, still-open question once (no `sent.json`
+yet). Results: `:ok` stamps the device's
 `last_ok_at`; `:gone` removes it; `:failed` keeps its code in `last_error` and logs `push_failed`; `:bad_jwt` logs
 one `push_bad_jwt` warning (on chi web's terminal too) and stops all pushes until chi web restarts. Log lines carry
 `device:` (the short id), `code:`, `ms:`, `kind:`: never the endpoint, keys or text. `#stop` drops pending holds and
@@ -150,16 +195,37 @@ joins with a timeout; `Server.start`'s ensure calls it. Specs drive `#pump` with
 `Web::PushRoutes`; `@push` is the run's `Push::Runtime` (store, client, origin), nil when push is off (no https
 public URL, or `web.push.enabled: false`):
 
-- `GET /api/push[?endpoint=E]` → `{enabled, public_key, origin, this: {id, label}|null}`; off: `enabled: false` and
-  no key.
+- `GET /api/push[?endpoint=E]` → `{enabled, public_key, origin, this: {id, label}|null, devices, stale}`: `devices`
+  this origin's (`Sub#public_h` + `this: bool`), `stale` how many were made on another origin; off: `enabled:
+  false` and no key.
 - `POST /api/push/subscriptions {subscription: {endpoint, keys}, replaces?: id}` → 201 `{id, label}`; the label is
   chi's own ("iPhone · <date>", from the User-Agent's device class: iPhone, iPad, Mac, else Browser); `replaces`
   drops the device's earlier entry (`Store#add`).
 - `DELETE /api/push/subscriptions {endpoint}` → 204.
+- `PATCH /api/push/subscriptions/ID {prefs: {done: true|false}}` → 200 the device's `Sub#public_h`; 404
+  `unknown_device` (not this origin's, or not a short id: the id is a `([^/]+)` capture checked in the handler, as
+  `participant_gate_spec`'s `path_for` fills only those), 400 `invalid_prefs`; logs `push_prefs`. ROUTES' first
+  PATCH row.
+- `POST /api/push/presence {page, front}` → 204 (also with push off: a desk tab has nothing to be told), 400
+  `invalid_presence`.
 - `POST /api/push/test {endpoint?}` → a test push to that device or every one on this origin, answered per device
   (`{devices: [{id, label, status, code, ms}]}`); the bell sends one after subscribing.
 
-With push off the three writes answer 409 `push_off`.
+With push off the subscription writes and the test answer 409 `push_off`.
+
+## Presence (`web/push/presence.rb`)
+
+"Don't push while I'm looking" is decided here, as the iPhone's service worker can't see the app in front. Every
+chi web page, a desk tab or the Home Screen app (`notifications.js`, whether or not it gets pushes itself), reports
+`POST /api/push/presence {page, front}`: `page` a random id per page load, `front` = visible + `hasFocus()` +
+touched (pointerdown, keydown, touchstart) in the last 2 min (`TOUCH_FRESH_MS`; the load counts as a touch). It
+reports on visibilitychange, window focus and blur, the first touch that brings it to the front, every 30 s
+(`PRESENCE_EVERY_MS`) while front and once more when 2 min pass untouched; a hide or `pagehide` sends `front: false`
+as a beacon (`presenceSender`: `navigator.sendBeacon` with a JSON Blob, same origin so the cookie goes; else the
+api's fetch; errors swallowed). `Push::Presence` keeps each page's last report in memory (a Mutex; at most
+`MAX_PAGES` 64, the longest unheard dropped); `present?` is any `front: true` younger than `TTL` 45 s. It is part of
+`Push::Runtime` (`presence`), so the route writes and the Notifier (built in `Server.start` from the Runtime) reads
+the same one. A page left in front untouched quiets the phone at most ~2 min after the last touch.
 
 ## The page (`public/push.js`, `public/notifications.js`)
 
@@ -175,8 +241,8 @@ delete (revoked meanwhile): then the id stays for the next subscribe to replace.
 chi web not pushing, the bell is the in-tab one, unchanged (no duplicate desktop pushes).
 
 **The device's tidy-up** (`syncDevice`, the Home Screen app with the bell on): closes the shown notifications whose
-tag is a question's (`push.js isQuestionTag`, so `chi:test` stays) and isn't open in the page's `byId`
-(`push.js openPushKeys`: `Attention.open_keys`'s rule, with notify.js's `questionReason`), and sets or clears the app
+tag is a waiting key (`push.js isWaitingTag`, so `chi:test` and a failed or done turn's stay) and isn't open in the
+page's `byId` (`push.js openPushKeys`: `Attention.open_keys`'s rule), and sets or clears the app
 badge (`navigator.setAppBadge` / `clearAppBadge`); the bell turned off clears it. It runs once push is known, when
 the page comes back in front, and after each hub frame while visible (so answering on the Mac with the app open
 clears it at once), one at a time with one rerun. Never before the first snapshot (an empty `byId` would close
@@ -201,7 +267,7 @@ can land after the page's tidy-up and stay until the next one. Unverified on iOS
   handler before `showNotification` doesn't remove the older one. A separate close push that only closed
   `getNotifications({tag})` did, but it shows nothing (see the quota below), so the worker now closes after its show.
 - **The service worker can't see the app in front** (`clients.matchAll` gave 0 windows with the app open) and a
-  banner shows anyway: "don't push while I'm looking" has to be decided server-side, from the pages' presence (P2).
+  banner shows anyway: "don't push while I'm looking" has to be decided server-side, from the pages' presence (see Presence above).
 - **Silent pushes**: the spike's 4 close pushes in a row didn't revoke the subscription, but that was luck or lazy
   enforcement: the user check's 6 did (WebKit's quota is 3 pushes that show nothing; see the top of this page).
 - iOS sent the cookie with the manifest, `sw.js` and icon fetches, but Chrome fetches manifests without credentials:

data/docs/sessions.md

@@ -239,6 +239,8 @@ chi send --new --continues last:3fa2 -m "new day"      # the next link of 3fa2's
 
 A session is named by its first message until you give it a title: `/title Coordinator` (in the REPL, an attached terminal, the web composer or `chi send -m "/title Coordinator" ID`; a parent agent may name its delegates the same way). The title is saved in the session file (`title`), whitespace collapsed and cut at 80 characters, and runs mid-turn too, at once. `/title` alone shows it (`title: none (shows the first message: hey chi …)` without one); `/title --clear` drops it, and the first message names the session again. A session whose first line was the command itself (`chi send --new -m "/title X"`) takes its preview from its first real message.
 
+Without a title, the web names a session by its recap's first sentence once it has one (see [Session recap](cli.md#session-recap); its subject phrase stripped), else by its first message: on its card (which then leaves out its recap line, the same sentence), the families and chain rows, the top bar and the browser tab, the delete confirm and the search; `chi sessions list` already reads title, else recap, else the first message. The notifications keep the first message. A participant's page is unchanged (the title or the review's subjects).
+
 The title names the session wherever its first message did: `chi sessions list` (plain, `--live`, tsv and json's `desc`, before the recap; json has `title` too), `chi sessions delete`'s line, the `list_sessions` tool, `chi broadcast`, the desktop helper, a parent's children (the coordinator bundle's `/children` card, `ctx.sessions.children`; `ctx.sessions.read` too), and in the web the cards, the families and chain rows, the top bar and the browser tab, the notifications and the search; the terminal's status row too (the REPL's and an attached one's, first, see [Status Line](cli.md#status-line)). In the web, `✎` (Rename this session) sits next to the session's title, on its active strip card or after the top bar's title: a small input over the title, prefilled with it; Enter or a click elsewhere sends `/title TEXT` when it changed (empty: `/title --clear`), Esc closes it unsent, and so does the title leaving the screen (All sessions opened, the card swiped out of a phone's strip). A session a chi REPL owns has no `✎`, nor one that shows no title yet (`/title` still works from the composer). A continue's new link keeps the title (see [Session chains](#session-chains)). An older `chi web` (or any chi from before the field) that saves a session drops its title: restart `chi web` after upgrading.
 
 ## Session chains
@@ -255,7 +257,7 @@ A session can **continue** an earlier one: "the next run of the same routine" (a
 - **If the continue fails part-way:** a new link that fails to start gives its moved delegates back before it is deleted (each gets a note saying so; its worker is stopped first, if one started, and a worker that won't stop is reported, the link left), with any report one of them rang it with meanwhile; the previous link, back in the lists, is woken for reports waiting. A continue that dies in the middle leaves a `move.json` in the new link's folder: the new link's next worker finishes that move (only the delegates it names, and without a second note to one already told) as it starts. Until the new link's own worker holds it, a ring from a moved delegate doesn't start another (a `starting` marker in its folder, which that worker removes; a stale one, over 60 s old or from a process that is gone, is ignored). An open delegate below an archived delegate refuses the continue (`under archived …`): unarchive that one, or archive this one.
 - **Refused too:** a link that is continued already (naming the link that continues it; continue that one, or `last:<id>`), a previous link whose folder is gone, and one whose model's host can't run it when no default model is configured to fall back to. A refusal starts nothing and archives nothing; a new link that fails to start puts back what was archived. Every refusal that can be known up front (the archive's ones included) comes before the recap wait. One continue of a session runs at a time (a lock in its folder; other chains don't wait), so a double click finds the first one's link and is refused, while a `last:<id>` continue that waited follows the chain to its new end.
 - **Web:** `POST /api/sessions` takes `continues: "<id, prefix or last:id>"`, with `idle: true` (a new link waiting for its first message, previewed by the previous link's, or `preview`) or a `prompt`, and `model` (or `model_name`) for the new link's model, but not `dir`, `llm_context`, `thinking`, `settings`, `toolkit`, `tools`, `no_tools` or `parent_answers` (400 `invalid_continues`: the previous link's are taken). 201 is the new session's summary, `continues` set, with `moved`: the ids of the delegates that moved to it (`[]` for none), and `model_warning`: the default-model fallback's warning, then any about the model id, joined by `; ` (`null` for none), and `opener`: the previous link's first typed message, in full, when that link continues one itself (`null` otherwise: a chain's first link's first message is its task); 404 `not_found`; 400 `ambiguous_id` for a prefix of several sessions, `invalid_model` for a given model whose host config.yml doesn't have (or a fallback with no default model); 409 `continued` with `next_id` (the link that continues it already, which the page opens instead), `open_children` with `ids` (open delegates that can't move), `folder_gone`, `busy`, `scratch` or `owned_by_tui`. Every session summary carries `continues`.
-- **The page:** the info bar's `continue →` continues the open session (`continues: <id>, idle: true`; it reads `continuing…` through the recap wait) and opens the new link with an opener in the composer, not sent (a draft written in this session stays instead; one carried over from another session or the start page gives way to the opener, and the toast's **Restore draft** brings it back): the previous link's own first typed message when that link continues one (the 201's `opener`; a `!shell` line isn't taken), else `Continue where we left off.`. So whatever you sent on the last link comes back on the next one, and editing it once changes it for every later link; the previous link is archived, a toast says so (`Continued 3fa2c1d0 in 4b7e9a01; 3fa2c1d0 is archived; 1 open delegate moved`), and a moved delegate's card folds under the new link. When the previous link's model's host is gone the link starts on the default model and the toast carries the server's `model_warning` too, and then stays until closed. A fresh link (one with no turn yet, however it was made: `continue →`, `chi send --new --continues`, a reload) shows the model picker in its composer with the link's model, until its first turn starts (a failed or canceled first turn ends it too); a pick runs `/model <name>` in the link (a command bubble; the info bar follows) and changes neither the start page's remembered model nor its Recent list, and a Send right after it waits for the `/model` to be taken. A link a chi REPL owns, or one continued already, shows none. A link continued already has no `continue →`: its `→` link goes to the next link (a stale page's continue answered 409 `continued` opens `next_id`). A continue refused for open delegates that can't move shows a toast that names each one (its preview and what the server says to do: `older chi worker 0.46.1; restart it`, `open in a chi REPL; close it there`), each a link to its page; any other refusal shows the server's words. The info bar of a link carries `← 2026-10-08` (the previous link's day) and, on an earlier link, `2026-10-10 →`, each a link with its id, its full start (`2026-10-10 14:32`) and its preview in the tooltip; a neighbour that started on the open link's own day shows its time instead (`← 09:12`, `14:32 →`). A link made by `continue →` inherits the previous link's preview (and its title, if it has one) when it is created, so its card keeps its chain's title whatever opener it is sent, and its top bar and browser tab show its card's title. A link whose title is the opener and nothing else (a `chi send --new --continues` link whose first message is `Continue where we left off.`) shows its chain's first link's title instead, on its card, in the popover and in its info bar's title line, display only (its messages and data keep the opener; its own title when the first link is gone). The lists fold a chain into the card of its latest listed link, whatever the earlier links' archived state (typing in an archived link brings it back, folded there still), their delegates with them: the card's `↩ #N` chip (`#N of M` when later links aren't listed; its tooltip `Session chain: link N of M`) opens a popover of the other links, newest first (`#N`, its date, with its time (`2026-10-17 14:32`) when another link of the chain started the same day, its own title when it differs from the card's (a link inherits its chain's, so mostly it doesn't), else its recap's first sentence, else its preview, `archived`), a click opens one; the chip shows a live dot or `waiting` for a link that has a worker or waits on the user, and a waiting link puts its chain's card first. All sessions folds nothing while a search is typed or "include archived" is on: every link is a card of its own then, its chip `#N of M`, with its own delegates folded in, so a search finds an earlier link and its delegates.
+- **The page:** the info bar's `continue →` continues the open session (`continues: <id>, idle: true`; it reads `continuing…` through the recap wait) and opens the new link with an opener in the composer, not sent (a draft written in this session stays instead; one carried over from another session or the start page gives way to the opener, and the toast's **Restore draft** brings it back): the previous link's own first typed message when that link continues one (the 201's `opener`; a `!shell` line isn't taken), else `Continue where we left off.`. So whatever you sent on the last link comes back on the next one, and editing it once changes it for every later link; the previous link is archived, a toast says so (`Continued 3fa2c1d0 in 4b7e9a01; 3fa2c1d0 is archived; 1 open delegate moved`), and a moved delegate's card folds under the new link. When the previous link's model's host is gone the link starts on the default model and the toast carries the server's `model_warning` too, and then stays until closed. A fresh link (one with no turn yet, however it was made: `continue →`, `chi send --new --continues`, a reload) shows the model picker in its composer with the link's model, until its first turn starts (a failed or canceled first turn ends it too); a pick runs `/model <name>` in the link (a command bubble; the info bar follows) and changes neither the start page's remembered model nor its Recent list, and a Send right after it waits for the `/model` to be taken. A link a chi REPL owns, or one continued already, shows none. A link continued already has no `continue →`: its `→` link goes to the next link (a stale page's continue answered 409 `continued` opens `next_id`). A continue refused for open delegates that can't move shows a toast that names each one (its preview and what the server says to do: `older chi worker 0.46.1; restart it`, `open in a chi REPL; close it there`), each a link to its page; any other refusal shows the server's words. The info bar of a link carries `← 2026-10-08` (the previous link's day) and, on an earlier link, `2026-10-10 →`, each a link with its id, its full start (`2026-10-10 14:32`) and its preview in the tooltip; a neighbour that started on the open link's own day shows its time instead (`← 09:12`, `14:32 →`). A link made by `continue →` inherits the previous link's preview (and its title, if it has one) when it is created, so its card keeps its chain's title whatever opener it is sent, and its top bar and browser tab show its card's title. A link with a recap of its own reads its recap's first sentence instead (a link without one reads its chain's name, and a first link's recap names its chain). A link whose title is the opener and nothing else (a `chi send --new --continues` link whose first message is `Continue where we left off.`) shows its chain's first link's title instead, on its card, in the popover and in its info bar's title line, display only (its messages and data keep the opener; its own title when the first link is gone). The lists fold a chain into the card of its latest listed link, whatever the earlier links' archived state (typing in an archived link brings it back, folded there still), their delegates with them: the card's `↩ #N` chip (`#N of M` when later links aren't listed; its tooltip `Session chain: link N of M`) opens a popover of the other links, newest first (`#N`, its date, with its time (`2026-10-17 14:32`) when another link of the chain started the same day, its own title when it differs from the card's (a link inherits its chain's, so mostly it doesn't), else its recap's first sentence, else its preview, `archived`), a click opens one; the chip shows a live dot or `waiting` for a link that has a worker or waits on the user, and a waiting link puts its chain's card first. All sessions folds nothing while a search is typed or "include archived" is on: every link is a card of its own then, its chip `#N of M`, with its own delegates folded in, so a search finds an earlier link and its delegates.
 - **CLI:** `chi send --new --continues (ID|PREFIX|last:ID) [--model M] [-m TEXT]` (see *Starting a session*).
 - **Which link:** an id, a unique prefix, or `last:<id or prefix>`, the latest link of the chain that session is in. It walks the links that still exist: a deleted link in the middle (`chi sessions delete`, the retention sweep of an unarchived one) ends the walk before it, so `last:` of an earlier link then names that earlier link, and continuing it starts a second line beside the links after the gap; name a link after the gap instead. A trigger names the chain this way: `chi send` to an archived link would bring it back (a human's input), not continue the chain.
 

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

@@ -1,6 +1,6 @@
 ---
 name: samagotchi-system
-version: 0.111.1
+version: 0.112.0
 scope: system
 description: Default system memories — identity, self map, config modification protocol, memory guide and the delegated-session rules
 files:

data/lib/samagotchi/session.rb

@@ -378,7 +378,8 @@ module Samagotchi
 
     # The question this session waits on, as the lists show it: {id:, kind:}
     # with kind "question" (the model's), "approval", "hook" or "continue"
-    # (the step-limit question, asked between turns); nil with
+    # (the step-limit question, asked between turns), +relayed_to+ and
+    # +created_at+ (iso8601: chi web's push catch-up) when set; nil with
     # none. Only while a worker runs it (+live+): a question saved by a
     # worker that died waits for no one (the next worker drops it). The
     # web's summaries and `chi sessions list` both ask this.
@@ -391,7 +392,8 @@ module Samagotchi
       kind = pending.kind.to_s
       relayed = pending.relayed_to
       relayed_to = relayed.is_a?(Hash) ? (relayed[:parent_short] || relayed["parent_short"]) : nil
-      { id: pending.id, kind: %w[approval hook continue].include?(kind) ? kind : "question", relayed_to: relayed_to }.compact
+      { id: pending.id, kind: %w[approval hook continue].include?(kind) ? kind : "question", relayed_to: relayed_to,
+        created_at: pending.created_at }.compact
     end
 
     # A question saved by a process that no longer runs this session (the

data/lib/samagotchi/version.rb

@@ -1,7 +1,7 @@
 # frozen_string_literal: true
 
 module Samagotchi
-  VERSION = "0.111.1"
+  VERSION = "0.112.0"
   # Sent as the User-Agent of every HTTP request chi makes.
   USER_AGENT = "chi/#{VERSION}"
 end

data/lib/samagotchi/web/app.rb

@@ -271,7 +271,10 @@ module Samagotchi
         ["GET", %r{\A/api/push\z}, :handle_push_info, :owner],
         ["POST", %r{\A/api/push/subscriptions\z}, :handle_push_subscribe, :owner],
         ["DELETE", %r{\A/api/push/subscriptions\z}, :handle_push_unsubscribe, :owner],
+        # The id checked in the handler (participant_gate_spec fills ([^/]+) captures only).
+        ["PATCH", %r{\A/api/push/subscriptions/([^/]+)\z}, :handle_push_prefs, :owner],
         ["POST", %r{\A/api/push/test\z}, :handle_push_test, :owner],
+        ["POST", %r{\A/api/push/presence\z}, :handle_push_presence, :owner],
         ["GET", %r{\A/api/sessions/([^/]+)\z}, :handle_show, :participant, :session],
         ["DELETE", %r{\A/api/sessions/([^/]+)\z}, :handle_delete, :owner, :session]
       ].freeze

data/lib/samagotchi/web/public/chains.js

@@ -60,11 +60,12 @@ export function isOpener(text) {
 // reads its chain's first link's title instead, so the links of a chain
 // keep its name. Its own title when the first link isn't in +byId+ (id →
 // session; deleted, or a walk a missing link cut short) or is the opener too.
-// A link with a title of its own (/title; a new link inherits it) reads it,
-// and a titled first link names its chain.
+// A link with a title of its own (/title; a new link inherits it), an auto
+// title or a recap of its own reads it, and a first link with any of them
+// names its chain.
 export function chainTitle(s, byId) {
   const own = previewForCard(s);
-  if (s?.title || !s?.continues || !isOpener(s.first_preview || s.last_prompt)) return own;
+  if (s?.title || s?.auto_title || s?.recap || !s?.continues || !isOpener(s.first_preview || s.last_prompt)) return own;
   const seen = new Set([s.id]);
   let at = s;
   while (at.continues) {
@@ -73,7 +74,8 @@ export function chainTitle(s, byId) {
     seen.add(prev.id);
     at = prev;
   }
-  return !at.title && isOpener(at.first_preview || at.last_prompt) ? own : previewForCard(at);
+  const named = at.title || at.auto_title || at.recap;
+  return !named && isOpener(at.first_preview || at.last_prompt) ? own : previewForCard(at);
 }
 
 // The open session's title (app.js updateSessionTitle: the top bar and the
@@ -81,10 +83,11 @@ export function chainTitle(s, byId) {
 // (+shown+, its summary, has continues) reads +cardTitle+(shown) whatever
 // its first message: a web link inherits its chain's title, and its first
 // message is an opener (the constant or the user's own). Else +first+,
-// unless it is the opener. A titled session (/title) reads its card's too.
+// unless it is the opener. A titled session (/title), or one with an auto
+// title or a recap (its card's name then), reads its card's too.
 // +shown+ null: not listed yet, +first+.
 export function openTitle({ shown, first, cardTitle }) {
-  if (shown && (shown.title || shown.continues || isOpener(first))) return cardTitle(shown);
+  if (shown && (shown.title || shown.auto_title || shown.recap || shown.continues || isOpener(first))) return cardTitle(shown);
   return first;
 }
 

data/lib/samagotchi/web/public/format.js

@@ -57,11 +57,26 @@ export function firstPreview(text) {
   return clip(n, FIRST_PREVIEW_CHARS + 1);
 }
 
+// What names a session's card, first found: its title (/title), its auto
+// title (from the recap call), its recap's first sentence (+recap+), its
+// first message, its last prompt. Display only.
+function cardName(session) {
+  return session.title || session.auto_title || session.recap || session.first_preview || session.last_prompt || "";
+}
+
 export function previewForCard(session) {
-  // Unified card preview: its title (/title), else its first message (80),
-  // else its last prompt.
-  const raw = session.title || session.first_preview || session.last_prompt || "";
-  return firstPreview(raw) || "\u2014";
+  // Unified card preview: cardName, cut at 80.
+  return firstPreview(cardName(session)) || "\u2014";
+}
+
+// Where previewForCard's words came from: "title", "auto" (auto_title),
+// "recap" (the card then drops its recap line: the same sentence twice),
+// "preview" (the first message or last prompt, or none).
+export function cardTitleSource(session) {
+  if (session.title) return "title";
+  if (session.auto_title) return "auto";
+  if (session.recap) return "recap";
+  return "preview";
 }
 
 const DELETE_PREVIEW_CHARS = 40;
@@ -70,7 +85,7 @@ const DELETE_PREVIEW_CHARS = 40;
 // list's owner can be stale (a worker idle-exits), so a worker is only
 // "stopped if it's still running", never promised.
 export function deleteConfirmText(session) {
-  const n = normalize(session.title || session.first_preview || session.last_prompt || "");
+  const n = normalize(cardName(session));
   const preview = clip(n, DELETE_PREVIEW_CHARS + 1);
   const shortId = session.short_id || String(session.id).slice(0, 8);
   const lines = [