@aitne-sh/aitne 0.1.9 → 0.1.11

package/agent-assets/docs/features/messaging/overview.md

@@ -29,7 +29,7 @@ ask_examples:
   - Can I send the agent a voice note?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - messaging
   - dm
@@ -53,9 +53,8 @@ related:
 ui_anchors:
   - /connections
   - /connections/messaging
-  - /settings/connections
   - /settings/commands
-  - /settings/schedule
+  - /settings/hours
 process_keys:
   - message.dm
   - message.mention
@@ -75,10 +74,10 @@ so you can talk to the agent the same way you'd type.
 ## What It Does
 
 - **Reactive DMs**: the agent answers every direct message you send.
-- **@-mentions (Slack only)**: @-mentioning the agent inside a shared
-  channel routes to the `message.mention` ProcessKey and is answered
-  the same way as a DM. Telegram, Discord, and WhatsApp drop all
-  non-DM traffic (no group support).
+- **@-mentions (Slack and Discord)**: @-mentioning the agent inside a
+  shared channel routes to the `message.mention` ProcessKey and is
+  answered the same way as a DM. Telegram and WhatsApp drop all non-DM
+  traffic (no group support).
 - **Outbound notifications**: routines and observations fire alerts
   back through the same channel.
 - **Voice attachments**: when the platform attaches audio (Telegram
@@ -101,8 +100,9 @@ the owner channel independently.
 
 ## When It Runs / How It Is Triggered
 
-- The messaging adapter for each connected platform polls / receives
-  webhooks for incoming messages.
+- The messaging adapter for each connected platform long-polls
+  (Telegram) or holds a persistent WebSocket connection (Slack,
+  Discord, WhatsApp) for incoming messages.
 - An incoming DM dispatches to the `message.dm` ProcessKey.
 - An incoming mention dispatches to `message.mention`.
 - Notifications fire as a side-effect of routines and observations
@@ -111,21 +111,24 @@ the owner channel independently.
 ## What It Outputs
 
 - Replies in the operator's chosen messaging app.
-- Notification messages, batched during quiet hours.
+- Notification messages — suppressed during quiet hours; a pending
+  batch is deferred and delivered when the window ends (see
+  [Quiet Hours](../operations/quiet-hours.md)).
 
 ## Where in the Dashboard
 
 - **Connections (`/connections`)** is the unified pairing page.
 - **Connections → Messaging (`/connections/messaging`)** lists each
-  app's status, owner channel, and rate limit settings.
+  app's status, owner pairing, and notification destinations.
 
 ## Configuration
 
 - Per-app: bot token / OAuth, owner channel, optional default channel.
 - Global: `primaryPlatform` (default `slack`) — the platform the agent
   prefers for outbound notifications when more than one app is paired.
-- Outbound rate limits and quiet hours live on `/settings/schedule`
-  (see [Quiet Hours](../operations/quiet-hours.md)).
+- Outbound rate limits and quiet hours live on `/settings/hours`
+  ("Hours & Notifications" — see
+  [Quiet Hours](../operations/quiet-hours.md)).
 
 ## When Something Goes Wrong
 
@@ -133,7 +136,7 @@ the owner channel independently.
   `/connections/messaging` first (see
   [Pairing & Magic Phrase](pairing-and-magic-phrase.md)).
 - A **notification you expected but did not get**: check quiet hours
-  and rate limits on `/settings/schedule`.
+  and rate limits on `/settings/hours`.
 
 ## Related
 

package/agent-assets/docs/features/messaging/telegram.md

@@ -8,7 +8,7 @@ aliases:
 category: features
 summary: |
   Pair Telegram by creating a bot via @BotFather, pasting the token
-  into Aitne, and DMing the magic phrase.
+  into Aitne, and scanning the pairing QR code.
 section: messaging
 tags:
   - messaging
@@ -24,7 +24,7 @@ ask_examples:
   - Where do I get a Telegram bot token?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - telegram
   - telegram bot
@@ -41,7 +41,7 @@ related:
 ## In One Sentence
 
 The fastest messaging app to pair: create a Telegram bot, paste the
-token, type the magic phrase.
+token, scan the pairing QR code.
 
 ## What It Does
 
@@ -51,7 +51,7 @@ token, type the magic phrase.
 ## When It Runs / How It Is Triggered
 
 Before pairing, nothing listens. Once you paste the bot token and complete
-magic-phrase pairing, Aitne long-polls Telegram's Bot API continuously for new
+QR / deep-link pairing, Aitne long-polls Telegram's Bot API continuously for new
 direct messages.
 
 ## Where in the Dashboard
@@ -63,17 +63,18 @@ direct messages.
 | Field | Notes |
 |---|---|
 | Bot Token | From @BotFather. |
-| Owner Channel | Auto-set on successful magic-phrase pairing. |
+| Owner Channel | Auto-set on successful QR / deep-link pairing. |
 
 ## When Something Goes Wrong
 
 - Bot replied to in a group instead of a DM: group chats are filtered
   out by design; the agent only listens to direct messages.
-- No reply at all after DMing the magic phrase: confirm the bot has a username
-  set via @BotFather (/setname) — the daemon refuses to build the pairing deep
-  link otherwise.
+- No reply at all after scanning the QR: confirm the bot has a username
+  set via @BotFather (/setname or /newbot) — the daemon refuses to build the
+  pairing deep link otherwise.
 - Pairing never completes: re-check the token in Connections → Messaging →
-  Telegram, then DM the magic phrase from your own account. See
+  Telegram, generate a fresh QR, then scan it (or tap the deep link) and press
+  START in Telegram from your own account. See
   [Pairing & Magic Phrase](pairing-and-magic-phrase.md).
 
 ## Related

package/agent-assets/docs/features/operations/activity-and-conversations.md

@@ -26,7 +26,7 @@ ask_examples:
   - How do I find why a routine failed?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - activity
   - conversations
@@ -61,7 +61,7 @@ detail lives one click deeper under Conversations.
 
 Activity is the unified view of:
 
-- **Routines**: morning, evening, weekly, hourly fires.
+- **Routines**: morning, evening, weekly, activity-scan fires.
 - **Reactive sessions**: DMs, dashboard chat, mentions.
 - **Background actions**: notifications sent, mail labeled, schedule
   files written.
@@ -104,9 +104,10 @@ Retention is unlimited locally — the SQLite database keeps every row
 forever. To prune history without losing your configuration, use
 `POST /api/system/purge-history` (it clears `agent_actions`,
 `conversation_sessions`, and `messages` but leaves settings and the
-context vault intact). To wipe everything, `aitne uninstall --wipe-data`
-removes the whole `~/.personal-agent` data directory after a `WIPE`
-confirmation.
+context vault intact). To wipe everything, `aitne uninstall` removes the
+whole `~/.personal-agent` data directory after a literal `WIPE`
+confirmation (pass `--wipe-data` to skip the prompt and wipe
+non-interactively, or `--keep-data` to leave the directory intact).
 
 ## When Something Goes Wrong
 

package/agent-assets/docs/features/operations/approvals.md

@@ -24,7 +24,7 @@ ask_examples:
   - Where do I approve a pending action?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - approval
   - approve tier
@@ -83,10 +83,11 @@ Deny asks for confirmation before discarding the item.
 
 ## When Something Goes Wrong
 
-- **An approval that never clears:** the agent session that produced
-  it may have timed out. The action expires with the session — redo
-  the request that triggered it (for example, re-send the DM or
-  re-run the routine).
+- **A stale approval you never answered:** a pending approval is
+  discarded once the agent day rolls over (the next 04:00 local
+  boundary) — it's marked skipped rather than replayed after the
+  day turns. If that happens, redo the request that triggered it
+  (for example, re-send the DM or re-run the routine).
 
 ## Related
 

package/agent-assets/docs/features/operations/browser-tasks.md

@@ -0,0 +1,184 @@
+---
+schema_version: 1
+slug: features/operations/browser-tasks
+title: Browser Tasks
+id: browser-tasks
+aliases:
+  - browser tasks
+  - browser task
+  - web task
+  - browser automation tasks
+  - sandboxed browser
+category: features
+summary: |
+  Open-ended browser actions the agent runs for you in a sandboxed,
+  one-tab-per-task sub-agent — "send a contact form on Amazon", "check
+  the price of X". You kick a task off in DM (or schedule one); the
+  agent DMs you back for clarification or a final confirm when it needs
+  your input. The Browser Tasks page is where every run shows up, with
+  live state, a screenshot trace, and a cancel button.
+section: operations
+tags:
+  - operations
+  - browser-automation
+  - safety
+status: beta
+ask_examples:
+  - What is the Browser Tasks page?
+  - How do I start a browser task?
+  - Why is my browser task waiting for me?
+  - What do the browser-task states mean?
+  - How do I cancel a running browser task?
+  - Where do I see the screenshots from a browser task?
+locale: en-US
+created: 2026-06-16
+updated: 2026-06-16
+keywords:
+  - browser tasks
+  - browser-task
+  - sandboxed sub-agent
+  - awaiting_user
+  - final_confirm
+  - screenshot trace
+  - allowlist
+  - payment-path block
+  - cancel task
+related:
+  - features/operations/managed-chromium
+  - features/integrations/browser-history
+  - concepts/safety-and-execution
+  - concepts/safety-model
+ui_anchors:
+  - /browser-tasks
+  - /browser
+process_keys:
+  - browser_task
+config_keys:
+  - browserTaskMaxConcurrent
+  - browserTaskPendingQueueTimeoutMinutes
+  - browserTaskRespectQuietHours
+  - browserTaskHostnameDenylist
+api_endpoints:
+  - POST /api/browser-task
+  - GET /api/browser-task
+  - GET /api/browser-task/:id
+  - GET /api/browser-task/:id/events
+  - GET /api/browser-task/:id/screenshots/:file
+  - POST /api/browser-task/:id/clarify
+  - POST /api/browser-task/:id/cancel
+---
+
+# Browser Tasks
+
+A **browser task** is an open-ended action you ask the agent to carry
+out on the web — "send a contact form on Amazon's contact-us page",
+"check the price of X", "fill in this signup". Each task runs in a
+sandboxed sub-agent with **one browser tab to itself**, under allowlist
+enforcement, a payment-path block, and a screenshot trace. The
+**Browser Tasks** page (`/browser-tasks`) is the operational surface
+where every run shows up — what is queued, running, waiting on you, or
+finished.
+
+This is different from two neighbouring surfaces:
+
+- **[Browser History](browser-history)** reads your *existing* Chrome
+  passively (research clusters, revisit nudges). It never drives a
+  browser.
+- **[Managed Chromium / B-4](managed-chromium)** is the heavily-gated,
+  default-off *purchase-confirmation* flow. Browser tasks are the
+  general-purpose, non-purchasing actions; a final purchase confirm is
+  the one thing they hand off to the B-4 token primitive.
+
+## Starting a Task
+
+You don't start a task from this page — you ask in **DM** or `/chat`:
+
+> "Send a contact form on Amazon's contact-us page saying my order
+> #123 never arrived."
+
+The agent creates the task (`POST /api/browser-task`), opens a tab, and
+works the goal step by step. You can also **schedule** one to run later
+(it appears here when it fires). The page itself is a read + monitor
+surface: filter, search, open a run, or cancel it.
+
+## Reading the Page
+
+- **Tasks awaiting you** — a strip pinned to the top that only appears
+  when one or more tasks are blocked on your input. It links straight
+  to the run that needs you. The same signal drives the nav red-dot and
+  the persistent shell banner, so they stay in lock-step.
+- **Filter chips** — narrow by state (`All`, `Active`, or a specific
+  state) and by **site**. `Active` means any non-terminal task.
+- **Search** — free-text match over the task description.
+- **Table** — one row per task: state, description (click to open the
+  run), site, originating channel, created time, and duration. Active
+  rows expose a **Cancel** button.
+
+Click any row to open the **run detail** (`/browser-tasks/:id`): the
+step-by-step event log and the **screenshot trace** the sub-agent
+captured along the way.
+
+## Task States
+
+A task moves through a small state machine. Non-terminal states are
+still in flight; terminal states are done.
+
+| State | Meaning |
+| --- | --- |
+| `pending` | Queued, not started yet. The duration cell shows queue wait and, when known, the site / global queue position. |
+| `running` | The sub-agent is actively driving the tab. |
+| `awaiting_user` | Paused — the agent DMed you a **clarifying question** and is waiting for your answer (`POST /api/browser-task/:id/clarify`). |
+| `final_confirm` | Paused at a **final confirmation** gate (e.g. a submit/checkout step) waiting for your explicit go-ahead. |
+| `completed` | Finished successfully. |
+| `failed` | Stopped on an error; the row shows a short outcome detail. |
+| `cancelled` | You (or the agent) cancelled it. |
+| `timeout` | Exceeded its time budget. |
+| `abandoned` | A pending task expired in the queue before it could start (see `browserTaskPendingQueueTimeoutMinutes`). |
+
+When a task is `awaiting_user` or `final_confirm`, **answer in the DM
+the agent sent you** — that is the loop that unblocks it. The dashboard
+strip and banner are just where you notice it.
+
+## Cancelling
+
+Active tasks have a **Cancel** button (and `POST
+/api/browser-task/:id/cancel`). Cancelling releases the browser context
+immediately and DMs you a confirmation. Terminal tasks can't be
+cancelled — there is nothing left to stop.
+
+## Safety Model (why it's safe to let it drive)
+
+Browser tasks inherit the project's structural browser defences — there
+is **no hardcoded category/brand denylist**:
+
+1. **One sandboxed tab per task.** Tasks don't share a browser context,
+   so one task can't read another's session.
+2. **Allowlist enforcement + hostname denylist.** Navigation is
+   constrained; you manage blocked hostnames via
+   `browserTaskHostnameDenylist`.
+3. **IP egress layer (not configurable).** Navigations that resolve to
+   private, loopback, link-local, or cloud-metadata addresses are
+   denied at the egress chokepoint — defence-in-depth against SSRF.
+4. **Payment-path block.** A URL-pattern matcher trips at form-submit
+   time on payment-handoff paths, so a task can't silently push a
+   transaction through. An actual purchase requires the separate,
+   default-off [B-4 token flow](managed-chromium).
+5. **Human-in-the-loop gates.** Anything ambiguous or consequential
+   surfaces as `awaiting_user` / `final_confirm` and waits for your DM.
+
+See **[Safety and Execution](../../concepts/safety-and-execution)** and
+the **[Safety Model](../../concepts/safety-model)** for the full
+picture.
+
+## Configuration
+
+These keys live in the editable config (Settings → Infrastructure):
+
+- `browserTaskMaxConcurrent` — how many tasks may run at once; the rest
+  queue (`pending`).
+- `browserTaskPendingQueueTimeoutMinutes` — how long a `pending` task
+  waits before it is `abandoned`.
+- `browserTaskRespectQuietHours` — when on, tasks defer during your
+  quiet hours rather than running overnight.
+- `browserTaskHostnameDenylist` — hostnames a task may never navigate
+  to (user-managed; there is no shipped default brand/category list).

package/agent-assets/docs/features/operations/cost-tracking.md

@@ -79,6 +79,16 @@ Open **Analytics**. It has two tabs:
 - **Cost** — per-run USD spend. A period selector switches between
   **Daily**, **Weekly**, and **Monthly** windows, with summary cards for
   **Today**, **Last 7 Days**, and **Last 30 Days**. Inside Cost:
+  - **Today's Spend Drivers** — answers "what is costing money *right
+    now*". **Most Expensive Runs Today** lists the day's costliest runs
+    (top 15, most expensive first); click a row for the full per-run
+    detail, including the actually-billed model and cache token breakdown.
+    Next to it, **By Process Today** shows each process's share of today's
+    total, and **Today at a Glance** tracks the day's efficiency: cache
+    hit rate, autonomous spend share, failed-run spend (money paid for
+    runs that produced no result), average cost per run, and total token
+    volume. Everything here uses the agent-day boundary, so the numbers
+    reconcile with the **Today** summary card.
   - **Overview** — a cost-trend chart over the selected period plus a
     **By Event Type** breakdown (which process keys cost the most).
   - **By Backend** — totals and a trend chart split by the backend that
@@ -105,7 +115,7 @@ reactive work such as DMs and mentions always runs.
 - **`autonomousDailyCostCapUsd`** (Autonomous Daily Cost Cap) — when
   today's autonomous spend reaches the cap, the dispatcher skips
   lower-priority routines first, using priority-based degradation:
-  - `hourly_check` — skipped at 100% of the cap
+  - `activity_scan` — skipped at 100% of the cap
   - `roadmap_refresh` — skipped at 120%
   - `evening_review` — skipped at 150%
   - `morning_routine` — last to be cut, only at 200%

package/agent-assets/docs/features/operations/managed-chromium.md

@@ -31,7 +31,7 @@ ask_examples:
   - How do I block a site from managed Chromium?
 locale: en-US
 created: 2026-05-22
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - managed chromium
   - browser automation
@@ -48,6 +48,7 @@ related:
   - concepts/safety-and-execution
   - reference/disallowed-tools
 ui_anchors:
+  - /browser
   - /settings/integrations/browser-history-managed
   - /settings/integrations/browser-history-managed/b4
 process_keys:
@@ -136,7 +137,8 @@ ships empty.
 1. The agent prepares the checkout in a managed Chromium tab and
    pauses at the final confirm step.
 2. The daemon mints a single-use token with the prefix `!~` followed
-   by 8 random hex characters (e.g. `!~3a1f9c7b`), inserts a
+   by 8 random base32 characters (alphabet `A-Z2-7`, e.g.
+   `!~K7QM3ZAB`), inserts a
    `browser_automation_purchase_tokens` row keyed on a server-side
    `jti`, and DMs the token to a primary channel together with a
    screenshot of the exact cart state.

package/agent-assets/docs/features/operations/notifications.md

@@ -23,7 +23,7 @@ ask_examples:
   - How do I limit how often it notifies me?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-10
 keywords:
   - notification
   - notify
@@ -74,6 +74,14 @@ by quiet hours and rate limits.
 4. It is sent to the operator over `primaryPlatform` (or, when set, the
    exact channels in `defaultNotificationPlatforms`).
 
+Explicit agent notifications (`POST /api/notify`) ride the same gates
+with one difference: inside quiet hours they are **deferred, not
+dropped** — the full message is queued as a scheduled DM that fires
+when the window ends (visible under Schedule), and repeat sends from
+the same agent overnight coalesce into one combined DM. Outside quiet
+hours the per-hour / per-day caps apply; a capped call is rejected
+(`rate_limited`) rather than silently queued, so the agent can adapt.
+
 ### Safety categories always get through
 
 Notifications tagged `security`, `deadline`, `error`, or `critical`
@@ -104,6 +112,8 @@ The agent can also emit a one-off notification via `POST /api/notify`
 - **A notification you expected never arrived:** check the rate-limit
   counters (`maxNotificationsPerHour` / `maxNotificationsPerDay`) and the
   quiet-hours window — a non-safety alert can be suppressed by either.
+  Explicit `/api/notify` messages caught by quiet hours are not lost —
+  look for a pending scheduled DM under Schedule.
   Safety-category alerts (`error`/`critical`/`security`/`deadline`) are
   never suppressed, so a missing one points at delivery/pairing instead.
 - **Too many notifications:** lower the per-hour / per-day caps or widen

package/agent-assets/docs/features/operations/quiet-hours.md

@@ -25,7 +25,7 @@ ask_examples:
   - Will routines still run during quiet hours?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-10
 keywords:
   - quiet hours
   - dnd
@@ -39,7 +39,7 @@ related:
   - features/routines/morning-routine
   - concepts/agent-day
 ui_anchors:
-  - /settings/schedule
+  - /settings/hours
 config_keys:
   - quietHoursStart
   - quietHoursEnd
@@ -65,6 +65,16 @@ the window:
   notification path, sees that it is quiet hours, and is logged as
   `suppressed` — it is **dropped, not held**. You will not receive it
   later.
+- **An explicit agent notification (`POST /api/notify`) is deferred,
+  not dropped.** When an agent session calls the notify endpoint inside
+  the window, the full message is queued as a scheduled DM that fires
+  the moment the window ends (visible under Schedule). Repeat calls
+  from the same agent overnight coalesce into one combined DM at the
+  edge instead of a morning pile-up. `critical` priority bypasses the
+  gate and sends immediately. If you change the quiet-hours window
+  while deferred DMs are pending, they are retimed to the new window
+  end (or released immediately when the new window no longer covers
+  the current time).
 - **A notification already in a batch queue is deferred, not dropped.**
   Aitne batches repeat notifications of the same event type within
   `batchIntervalMinutes`. When a batch is pending and quiet hours are
@@ -82,6 +92,20 @@ the window:
   defaults — boundary `04`, quiet hours `22:00`→`08:00` — that 04:00 run
   lands inside quiet hours, so it runs normally but its proactive output
   is held back or suppressed like any other notification.
+- **A custom Agent can opt its whole run out of the window.** A user
+  Agent created with `schedule.defer_in_quiet_hours: true` (the
+  "Respect quiet hours" toggle in the New Agent form) does not run
+  inside the window at all — the firing itself is pushed to the moment
+  quiet hours end, so a DM-producing Agent delivers fresh results right
+  at the edge instead of burning a 3 AM session whose message would be
+  held anyway. Each deferral is recorded in the action log
+  (`agent.task.deferred_for_quiet_hours`). The default is off, so a
+  silent file-writing Agent deliberately scheduled overnight stays put.
+  Built-in routines never defer. Scheduled browser tasks get the same
+  treatment via `browserTaskRespectQuietHours` (default on). Like
+  deferred DMs, already-deferred runs are retimed when you change the
+  quiet-hours window — shrinking or disabling it releases them at the
+  new edge instead of holding them until the old one.
 
 ## When It Runs / How It Is Triggered
 
@@ -93,11 +117,15 @@ timezone) before sending. The window may wrap midnight — the default
 
 ## Where in the Dashboard
 
-**Settings → Schedule** holds `quietHoursStart` and `quietHoursEnd`,
-shown as a red band on the same 24-hour slider as the hourly-check
-active window. There is **no overlap validation** — quiet hours and the
-active window are allowed to overlap, and the morning routine fires
-regardless of where the bands sit.
+**Settings → Hours & Notifications** (`/settings/hours`) holds
+`quietHoursStart` and `quietHoursEnd`, shown as a red arc on the same
+24-hour ring (dial) as the activity-scan active window — drag the red
+handles to adjust quiet hours. The active-window band is read-only on
+this page; the activity scan owns its hours, edited from **Agents →
+Activity Scan** (`/agents/activity-scan`). There is **no overlap
+validation** — quiet hours and the active window are allowed to
+overlap, and the morning routine fires regardless of where the bands
+sit.
 
 ## Configuration
 
@@ -111,10 +139,12 @@ regardless of where the bands sit.
 
 - **You expected an important alert to wake you but nothing came.**
   Only the safety categories (`security`, `deadline`, `error`,
-  `critical`) bypass quiet hours. A regular proactive notification that
-  isn't already batched is dropped, not delayed. If you need real-time
-  night alerts for, say, a critical mail label, either ensure that path
-  emits a safety-category notification or disable quiet hours.
+  `critical`) bypass quiet hours. A regular routine-output notification
+  that isn't already batched is dropped, not delayed (explicit
+  `/api/notify` messages are deferred to the window end instead). If
+  you need real-time night alerts for, say, a critical mail label,
+  either ensure that path emits a safety-category notification or
+  disable quiet hours.
 - **A notification fired after the window ended but feels stale.**
   Check `batchIntervalMinutes` — a long interval means a deferred batch
   flush can lag the window end by several minutes. The deferral targets

package/agent-assets/docs/features/operations/schedule-approaching.md

@@ -72,7 +72,7 @@ integration mode:
 - **`native` mode** — the daemon does not poll, so it reads
   `observations` rows instead. These are posted by the agent's
   native-mode `routine.fetch_window` pre-pass. Because that pre-pass
-  refreshes on the hourly-check tick (~60-minute cadence), events
+  refreshes on the activity-scan tick (~60-minute cadence), events
   scheduled with less than ~60 minutes of lead time may miss their
   reminder. Direct mode (5-minute poll) does not have this limit.
 
@@ -94,7 +94,7 @@ If a reminder you expected never arrived:
 - Check the integration mode. Reminders fire in `direct`, `delegated`,
   and `native` modes; only `disabled` mode suppresses them entirely.
 - In `native` mode, short-notice events (< ~60 min lead time) can be
-  missed because observations refresh on the hourly-check cadence.
+  missed because observations refresh on the activity-scan cadence.
 
 ## Related