@aitne-sh/aitne 0.1.10 → 0.1.12

package/agent-assets/docs/features/lifestyle/git.md

@@ -62,7 +62,7 @@ keywords:
 related:
   - features/integrations/git
   - features/integrations/github
-  - features/routines/hourly-check
+  - features/routines/activity-scan
   - concepts/observations
 ui_anchors:
   - /git
@@ -114,7 +114,7 @@ per repo (all open by default so the controls are visible at a glance):
    require the repository to have a `localPath`.
 3. **Daily git management** — opt-in per repo. Enabling it does three
    distinct kinds of work, on different cadences:
-   - On the first **Run init now** click, writes the curated
+   - On the first **Generate overview** click, writes the curated
      `knowledge/repos/<slug>/overview.md` skeleton, mirrors the source
      `README.*` to `knowledge/repos/<slug>/README.md`, and
      **automatically queues a one-shot Architecture refresh** so the AI
@@ -143,7 +143,7 @@ a Sonnet-class agent that reads the actual code.
 **When it's generated**
 
 - **First time** — automatically queued the moment you click
-  **Run init now**. Returns immediately with `architectureScheduleId`;
+  **Generate overview**. Returns immediately with `architectureScheduleId`;
   the agent runs in the background (typically 30 s – 2 min) and
   replaces the placeholder block with real analysis.
 - **On demand** — click **Refresh architecture** any time. The daemon
@@ -171,7 +171,7 @@ new Architecture body via the chokepoint
 `PUT /api/repositories/:id/architecture-section`; the daemon performs
 the marker-bracketed replacement so other sections (Notable Changes,
 Daily Activity Log, Open Threads) are preserved verbatim. Every write
-also snapshots the previous Architecture body to `md_file_snapshots`
+also snapshots the previous `overview.md` to `md_file_snapshots`
 for recovery.
 
 ## README Mirror
@@ -180,7 +180,7 @@ for recovery.
 the repository's `README.*` (whichever extension exists, with `.md`
 preferred). It is refreshed on:
 
-- Every **Run init now** (initial mirror).
+- Every **Generate overview** click (initial mirror).
 - Every **Refresh architecture** click (so the mirror tracks what the
   agent just analyzed).
 
@@ -197,21 +197,24 @@ README is rewritten.
 ## When It Runs / How It Is Triggered
 
 - **Polling** runs continuously on the per-repo cadence (or the global
-  default). Observations land in the `observations` table; the hourly
-  check coalesces them.
+  default). Observations land in the `observations` table; the activity
+  scan coalesces them.
 - **Triggers** fire when the matching event arrives on the EventBus.
 - **Daily git management** is dispatched by `RepositoryManagementCron`,
   which iterates the `repository_management` table once an hour and
-  emits a `scheduled.task` (`git.project.update`) for any enabled row
-  whose `last_scan_at` is more than 24 hours old.
+  runs the scan writer directly (an in-process daemon write — no agent
+  session) for any enabled row whose `last_scan_at` is more than
+  24 hours old.
 - **Architecture refresh** (`git.project.refresh_architecture`) is
   enqueued only on:
-  - Manual **Run init now** (auto-enqueue, first time only).
+  - **Generate overview** (auto-enqueue — skipped when a previous
+    analysis already landed, re-queued when the Architecture section
+    is still pending).
   - Manual **Refresh architecture** click.
+  - A scan (cron or manual) that finds `overview.md` missing and
+    re-creates the skeleton via the implicit init.
   
-  No cron, no observer fires this. The cron-driven implicit init
-  (when daily scan creates a missing skeleton) deliberately does NOT
-  auto-enqueue.
+  There is no recurring cron that re-runs the analysis on a timer.
 
 ## What It Outputs
 
@@ -231,8 +234,8 @@ trigger's process key.
 
 - **My Life → Git** (`/git`) — this page. Polling, Triggers, and Daily
   git management are all expanded by default. The Daily-git-management
-  panel's buttons appear in lifecycle order — **Run init now → Refresh
-  architecture → Run today's scan now** — and each surfaces an inline
+  panel's buttons appear in lifecycle order — **Generate overview →
+  Refresh architecture → Run today's scan now** — and each surfaces an inline
   green confirmation on success or a red error message on failure.
 - **Connections → Repositories** (`/connections/repositories`) —
   register a repo (link a `localPath` and/or `owner/repo`), rename,
@@ -289,9 +292,10 @@ repository has a `localPath`:
 - **The toggle is greyed out with "No local clone".** Add a
   `localPath` on **Connections → Repositories**, then return.
 - **`Last status` shows `failed` and `Failure streak` keeps climbing.**
-  The cron still iterates but the dispatched session is failing —
-  open the latest conversation under that repo's tile, or check
-  **Activity** for the `git.project.update` run. A high streak does
+  The cron still iterates but the in-process scan writer is failing —
+  check the daemon logs (`aitne logs`) for "Failed to run repository
+  management scan", or click **Run today's scan now** to surface the
+  error inline. A high streak does
   not prevent further scans (the cron retries on the next interval).
 - **`Last scan` is "never" but the row is enabled.** Either the cron
   has not ticked yet (default tick is 1 hour) or the row has no local
@@ -313,7 +317,7 @@ repository has a `localPath`:
   before clicking again.
 - **The README mirror went out of date** after the source repo's
   README was rewritten. Click **Refresh architecture** (which also
-  re-copies the README) or **Run init now** on the repo.
+  re-copies the README) or **Generate overview** on the repo.
 
 ## Related
 
@@ -322,5 +326,5 @@ repository has a `localPath`:
 - [GitHub integration](../integrations/github.md) — remote-side data
   (notifications, workflow runs) reachable via `gh` even without a
   local clone.
-- [Hourly check](../routines/hourly-check.md) — the routine that
+- [Activity scan](../routines/activity-scan.md) — the routine that
   consumes the observations this page's polling generates.

package/agent-assets/docs/features/lifestyle/reading.md

@@ -73,7 +73,7 @@ at `/reading`.
   `completed` stamps `completed_at` automatically; you can also set a 1–5
   `rating` or `notes`.
 - **Recommend** from the list during reactive turns, and refresh the
-  reading-taste profile during weekly and monthly reviews.
+  reading-taste profile during the weekly review.
 
 There is **no bare "add a book" endpoint** — new books arrive through the
 two Kindle import pipelines above (or are created internally during an
@@ -93,8 +93,10 @@ drives the list shape. The reading skill loads in two situations:
 
 - **Reactively**, when you mention a book or highlight in a DM.
 - **From existing routines** — the morning routine can mention what
-  you're currently reading, and the weekly and monthly reviews pull
-  reading progress and refresh the reading-taste profile.
+  you're currently reading, the weekly review refreshes the
+  reading-taste profile, and the monthly review pulls reading progress
+  for its reading report (it reads the existing taste profile but does
+  not re-derive it).
 
 ## What It Outputs
 

package/agent-assets/docs/features/lifestyle/receipts.md

@@ -10,7 +10,7 @@ aliases:
   - receipt files
 category: features
 summary: |
-  A SQLite-backed log of receipt and invoice attachments the Gmail
+  A SQLite-backed log of receipt and invoice attachments the mail
   observer detects, plus an export path that saves them into the
   operator's external Obsidian vault for tax / reimbursement tracking.
 section: lifestyle
@@ -27,7 +27,7 @@ ask_examples:
   - What receipts haven't I saved yet?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - receipt
   - invoice
@@ -50,20 +50,21 @@ related:
 
 ## In One Sentence
 
-Receipts are PDF / image attachments the Gmail observer detects while
-scanning your mail; their metadata lives in the `receipts` SQLite
-table, and the agent can save the original file into your external
-Obsidian vault on request.
+Receipts are attachments (typically PDFs or images) the mail observer
+detects while scanning your mail; their metadata lives in the
+`receipts` SQLite table, and the agent can save the original file into
+your external Obsidian vault on request.
 
 ## How Detection Works
 
-The Gmail observer scans travel-booking emails for PDF / image
-attachments and retains other generic documents it finds. Each detected
+The mail observer scans travel-booking emails across every connected
+mail account and records each attachment it finds. Each detected
 attachment inserts a row into the `receipts` table, keyed uniquely on
 `(account_id, provider_msg_id, attachment_id)` so re-scans are
 idempotent. Columns:
 
-- `category` — `document` or `travel` (nullable until classified)
+- `category` — `travel` at detection time; reclassify to `document`
+  via PATCH (nullable on legacy rows)
 - `provider_msg_id`, `attachment_id`, `account_id` — locate the source
   attachment in the unified mail registry
 - `filename`, `mime_type`, `size_bytes` — attachment metadata
@@ -105,7 +106,7 @@ is documented in
 
 ## Configuration
 
-Detection runs as part of the Gmail observer; see
+Detection runs as part of the mail observer; see
 [Mail](../integrations/mail.md). The save target follows the external
 vault convention `receipts/YYYY/MM/<merchant>-<date>.<ext>`.
 

package/agent-assets/docs/features/memory-files/agent-journal.md

@@ -42,6 +42,7 @@ related:
   - features/operations/activity-and-conversations
   - concepts/memory-model
 process_keys:
+  - routine.morning_routine_today
   - routine.morning_routine_journal
   - routine.evening_review
   - routine.weekly_review
@@ -49,7 +50,7 @@ context_files:
   - journal/agent.md
 ui_anchors:
   - /knowledge?tab=context-files
-  - /settings/journal
+  - /agents/morning-routine?tab=rulebook
 ---
 
 # journal/agent.md
@@ -85,15 +86,18 @@ pruning older ones. Later routines read it back to look for patterns.
 
 Three routines append to the journal — none ever rewrites it:
 
-- **Morning routine** (Stage B, `routine.morning_routine_journal`) is
-  the recurring daily writer. After the day's stages settle, the
-  daemon appends a one-paragraph audit-trail entry assembled from the
-  prior day's `agent_actions` — stage results, retry stats, anomalies.
-  This is the entry you'll see most often.
+- **Morning routine** is the recurring daily writer — and here the
+  daemon itself does the writing, not an LLM stage. After the day's
+  stages (Stage A `routine.morning_routine_today`, Stage B
+  `routine.morning_routine_journal`) settle, the daemon appends a
+  one-paragraph audit-trail entry assembled from the run's
+  `agent_actions` rows — stage results, inbox stats, anomalies — plus
+  a one-line footprint of the prior day's actions. This is the entry
+  you'll see most often.
 - **Weekly review** (`routine.weekly_review`) appends the largest
   structured block: a `## Weekly YYYY-Www` retro with *What worked*,
   *What slipped on my side*, *System improvement ideas*, and agent-side
-  metrics. It quotes prior entries to find a thread.
+  metrics.
 - **Evening review** (`routine.evening_review`) appends short
   bookkeeping lines — for example a one-liner each time it bumps a
   roadmap review forward, or a validation error if a roadmap write was
@@ -115,11 +119,15 @@ worth recording during reactive work.
 ### System improvement ideas
 - Add Saturday to the Weekend day-type default so weekend pushes triage.
 ### Metrics (agent side)
-- Agent plan rows completed: 12
-- Did-not-fire / failed rows: 1
-- Observations reviewed / ignored: 18 / 4
+- Routine runs (7d): 142 total / 3 failed (prev week: 150 / 5)
+- Spend (7d): $4.10 (prev week: $4.80); top cost: routine.fetch_window $2.10
+- Notifications (7d): 9 sent / 4 ignored (prev week sent: 11)
 ```
 
+The metrics lines are copied verbatim from the `<self_performance>`
+block the daemon computes and injects into the weekly session — the
+review does not count anything itself.
+
 ## Append-only — enforced, not just convention
 
 The journal is append-only at the API layer, not merely by prompt
@@ -137,8 +145,9 @@ cannot destroy history. Writes go through the daemon context API
   read view of the file — `journal/agent` is listed among the top-level
   context files. It is flagged as sensitive: entering edit mode surfaces
   a "deliberately pruning noise" warning before you change anything.
-- **Settings → Journal** (`/settings/journal`) does *not* edit this
-  file. It is a two-tab editor for the daily-journal rule files —
+- **The morning-routine agent's Rulebook tab**
+  (`/agents/morning-routine?tab=rulebook`)
+  does *not* edit this file. It hosts the daily-journal rule files —
   `policies/journal-format.md` (sections, voice, frontmatter) and
   `policies/journal-export.md` (redaction / inclusion rules) — both of
   which the morning routine reads when synthesizing `daily/YYYY-MM-DD.md`,
@@ -155,7 +164,8 @@ agent's own writes, not to you editing the file on disk.
 ## When something goes wrong
 
 - **The journal stops growing.** This usually points at the morning
-  routine's Stage B (the daily writer) or the evening/weekly review not
+  routine (whose daemon-side appender writes the daily entry) or the
+  evening/weekly review not
   running. See [Morning Routine](../routines/morning-routine.md) and
   [Evening Review](../routines/evening-review.md).
 - **Entries look duplicated.** This usually means a routine retried
@@ -170,9 +180,8 @@ agent's own writes, not to you editing the file on disk.
 ## Related
 
 - [Morning Routine](../routines/morning-routine.md) — the recurring
-  daily writer (Stage B).
-- [Weekly Review](../routines/weekly-review.md) — the largest retro,
-  and the main consumer that reads prior entries back.
+  daily writer (via the daemon-side appender).
+- [Weekly Review](../routines/weekly-review.md) — the largest retro.
 - [Evening Review](../routines/evening-review.md) — appends short
   bookkeeping lines.
 - [Activity & Conversations](../operations/activity-and-conversations.md)

package/agent-assets/docs/features/memory-files/agent-lessons.md

@@ -30,7 +30,7 @@ ask_examples:
   - How do I tune the lesson caps?
 locale: en-US
 created: 2026-06-08
-updated: 2026-06-08
+updated: 2026-06-07
 keywords:
   - lessons
   - feedback
@@ -112,9 +112,10 @@ Those raw signals don't become lessons immediately. Each night the
 [evening review](../routines/evening-review.md) folds the day's
 unconsumed signals into the right store as dated lessons, then marks them
 consumed (it skips the step entirely when nothing pends). Once a month
-the monthly review runs a re-generalize pass that collapses several
-same-theme lessons into one higher-level principle, keeping each store
-small.
+the monthly review — off by default; opt in by enabling the
+monthly-review agent at `/agents/monthly-review` — runs a re-generalize
+pass that collapses several same-theme lessons into one higher-level
+principle, keeping each store small.
 
 ## Provisional vs. active
 
@@ -169,8 +170,8 @@ any time — the loop will pick up from whatever it finds the next night.
 - [Evening Review](../routines/evening-review.md) — folds the day's
   feedback signals into these stores each night.
 - [Weekly Review](../routines/weekly-review.md) — posts self-critique
-  signals that feed the loop. The monthly review re-generalizes the
-  stores once a month.
+  signals that feed the loop. The optional (off-by-default) monthly
+  review re-generalizes the stores once a month.
 - [agent journal](agent-journal.md) — the reflection-shaped diary, a
   separate file from these directive stores.
 - [Knowledge layout](../../reference/knowledge-layout.md) — where the

package/agent-assets/docs/features/memory-files/projects.md

@@ -56,8 +56,8 @@ project's lifetime.
 
 - Captures the project's purpose, status, links, and recent decisions
   in a single durable note.
-- Surfaces in the morning routine while the project is active and the
-  roadmap has Preparation Timeline rows pointing at it.
+- Surfaces in the morning routine while the project is active (its
+  `state` is not `archived`).
 - Becomes the canonical reference the agent quotes from in DMs.
 
 ## File Shape
@@ -99,8 +99,9 @@ Read on demand. Written when the operator asks the agent to remember
 something project-specific, or when a DM expresses project intent
 (create, update status, mark done).
 
-The agent never edits files on disk — it has no `Edit`/`Write` tools.
-All project writes go through the context API:
+The agent cannot edit context files on disk — a pre-write hook blocks
+`Edit`/`Write` anywhere inside the context vault. All project writes go
+through the context API:
 
 - `GET /api/context/list/projects` — discover existing project files.
 - `PUT /api/context/plans/projects/<slug>` — create or fully replace.

package/agent-assets/docs/features/memory-files/schedule.md

@@ -29,7 +29,7 @@ ask_examples:
   - How do I change which sections the daily journal includes?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-10
 keywords:
   - daily journal
   - diary
@@ -43,6 +43,7 @@ related:
   - concepts/agent-day
 ui_anchors:
   - /schedule
+  - /agents/morning-routine?tab=rulebook
 process_keys:
   - routine.morning_routine_journal
 context_files:
@@ -122,7 +123,8 @@ do not rewrite them.
 The daily journal does **not** appear on the Schedule page — that page
 shows the scheduler's wake-ups and recurring routines, not these files.
 
-- **Journal settings (`/settings/journal`)** is where you shape the
+- **The morning-routine agent's Rulebook tab
+  (`/agents/morning-routine?tab=rulebook`)** is where you shape the
   output: the Format and Export rule files control which sections
   appear, the voice, the required frontmatter, and the redaction /
   inclusion rules applied on every synthesis run. Edits take effect on
@@ -132,7 +134,8 @@ shows the scheduler's wake-ups and recurring routines, not these files.
 
 There is nothing to configure on the files themselves; they are a
 side effect of the morning routine. To change *what* gets written, edit
-the journal Format and Export rules at `/settings/journal`.
+the journal Format and Export rules on the morning-routine agent's
+Rulebook tab (`/agents/morning-routine?tab=rulebook`).
 
 Retention is unlimited — old files accumulate. A manual prune
 (`rm ~/.personal-agent/context/journal/daily/2025-*.md`) is safe.

package/agent-assets/docs/features/memory-files/today.md

@@ -9,7 +9,7 @@ aliases:
 category: features
 summary: |
   today.md is the live plan for the current agent day. The morning
-  routine rebuilds it each day; the hourly check, evening review,
+  routine rebuilds it each day; the activity scan, evening review,
   and the operator all read and append to it during the day.
 section: memory-files
 tags:
@@ -23,7 +23,7 @@ ask_examples:
   - Why does today.md keep getting rewritten?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - today
   - day plan
@@ -31,7 +31,7 @@ keywords:
   - handoff
 related:
   - features/routines/morning-routine
-  - features/routines/hourly-check
+  - features/routines/activity-scan
   - features/routines/evening-review
   - features/memory-files/schedule
   - concepts/agent-day
@@ -59,7 +59,9 @@ today.md holds six sections, written in this order:
 - **User Schedule** — the day's calendar events.
 - **User Tasks** — today's external tasks plus agent-tracked to-dos.
 - **Agent Plan** — what the agent intends to work on today (each row is
-  registered as a schedule entry by the morning routine).
+  registered as a schedule entry by the morning routine; mid-day
+  sessions may add rows for new signals or cancel ones whose premise
+  changed).
 - **Agent Notes** — look-ahead items and date-bound memos folded in from
   inbox triage.
 - **Agent Log** — what actually happened, appended throughout the day.
@@ -69,10 +71,11 @@ today.md holds six sections, written in this order:
 
 - The **morning routine** fully rebuilds today.md (the daemon first
   rotates the previous day's file to `state/yesterday.md`).
-- The **hourly check** routes new observations into the right section
+- The **activity scan** routes new observations into the right section
   and appends short status lines under Agent Log.
 - The **evening review** finalizes the file — it updates Agent Log and
-  the Handoff section before writing the daily journal.
+  the Handoff section. (The daily journal itself is written the next
+  morning, from the rotated file.)
 
 ## How It Is Written
 
@@ -94,6 +97,6 @@ during the morning routine: while the lock is held, a write to
 ## Related
 
 - [Morning routine](../routines/morning-routine.md)
-- [Hourly check](../routines/hourly-check.md)
+- [Activity scan](../routines/activity-scan.md)
 - [Evening review](../routines/evening-review.md)
 - [schedule/ files](schedule.md)

package/agent-assets/docs/features/memory-files/user-profile.md

@@ -13,7 +13,8 @@ category: features
 summary: |
   identity/profile.md is the agent's stable profile of the operator — role,
   focus areas, preferences, names of important people. The agent reads it
-  on every session and appends only with the operator's permission.
+  on every session and silently appends durable facts the operator states
+  in DMs.
 section: memory-files
 tags:
   - memory
@@ -26,7 +27,7 @@ ask_examples:
   - Will the agent change my profile without asking?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - user profile
   - identity/profile.md
@@ -54,8 +55,8 @@ context_files:
 
 ## In One Sentence
 
-A stable, mostly hand-edited profile of you — the agent reads it
-every session and appends only with explicit permission.
+A stable profile of you — the agent reads it every session and
+silently appends durable facts you state in DMs.
 
 ## What It Does
 
@@ -76,9 +77,12 @@ every session and appends only with explicit permission.
 ## When It Runs / How It Is Triggered
 
 - **Read continuously** — loaded at the start of every session.
-- **Written** only when you say "remember that…" in a DM, or during
-  the profile sweep routine (`routine.user_profile_sweep`), which
-  routes captured facts into the appropriate `identity/*.md` slice.
+- **Written** silently, in the same turn, when you state a durable
+  fact about yourself in a DM ("remember that…", "I'm a…", "my
+  manager is…"), and during the profile sweep routine
+  (`routine.user_profile_sweep`), which catches facts the DM-time
+  capture missed and routes them into the appropriate
+  `identity/*.md` slice.
 
 The agent never edits these files directly. It writes through the
 daemon's context API — for example
@@ -101,8 +105,9 @@ To tell the agent a durable fact about yourself, just say it in a DM:
 
 > remember that my manager is Priya and we sync every Monday at 10am
 
-The agent appends a line to the relevant slice (here `identity/people.md`)
-after confirming, and recalls it in future sessions.
+The agent silently appends a line to the relevant slice (here
+`identity/people.md`) in the same turn, and recalls it in future
+sessions.
 
 ## When Something Goes Wrong
 

package/agent-assets/docs/features/messaging/bang-commands.md

@@ -6,6 +6,7 @@ id: bang-commands
 aliases:
   - "!stop"
   - "!start"
+  - "!status"
   - "!cost"
   - "!report"
   - "!help"
@@ -36,7 +37,7 @@ ask_examples:
   - How do I accept a research-cluster offer?
 locale: en-US
 created: 2026-05-12
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - bang command
   - "!stop"
@@ -88,10 +89,21 @@ Pair your messaging app first; see
 | Command | What it does |
 |---|---|
 | `!help` | List every registered command — built-ins plus enabled user commands. |
-| `!stop` | Pause cron-driven autonomous work (hourly check, morning / evening / weekly routines, scheduled tasks). In-flight runs are **not** aborted. |
+| `!stop` | Pause cron-driven autonomous work (activity scan, morning / evening / weekly routines, scheduled tasks). In-flight runs are **not** aborted. |
 | `!start` | Resume autonomous work after `!stop`. |
 | `!close` | Close the active DM session for the current routing tuple so the next DM starts a fresh conversation. |
 
+### Tasks (detached background / browser work)
+
+These inspect and cancel the long-running detached workers (background
+tasks and browser tasks). They run ahead of the agent — even while a DM
+turn or a result-delivery turn is in flight — and are safe while paused.
+
+| Command | What it does |
+|---|---|
+| `!status` | List the active background + browser tasks (kind, short id, state, title). Empty when nothing is running. |
+| `!stop <id>` | Cancel one task by its id (the short id from `!status` is fine; any unambiguous prefix works). **Bare `!stop` (no id) pauses the whole agent** — the lifecycle command above. |
+
 ### Reporting (pure DB reads, safe while paused)
 
 | Command | What it does |
@@ -100,6 +112,7 @@ Pair your messaging app first; see
 | `!cost claude` · `!cost codex` · `!cost gemini` · `!cost opencode` | Spend for a single backend (one row per registered backend). |
 | `!report` | Recent agent failures (last 7 days, top groups, most recent sample). |
 | `!checks` | Today's top browser reload patterns (domain + first path segment). Pure read on `browser_reload_signals`; anchored on the agent-day (`dayBoundaryHour`). Empty state is the common case for a quiet day. |
+| `!revert tuning` | Undo the most recent self-tuning config change (the one announced in a "Self-tuning (R…)" DM). Restores the previous value through the standard config chokepoint and puts the key into a 28-day re-proposal cool-down. Safe while paused. |
 
 ### Research clusters (browser-history)
 
@@ -193,9 +206,10 @@ were hidden.
 
 ## How They Behave
 
-- **Exact match for atomic commands** (`!stop`, `!cost`, `!checks`)
-  and **prefix match for parameterised ones** (`!cost claude`,
-  `!research accept <slug>`, `!compile @work full`). Anything
+- **Exact match for atomic commands** (`!stop`, `!cost`, `!checks` —
+  each `!cost <backend>` variant is its own exact-match entry) and
+  **prefix match for parameterised ones**
+  (`!research accept <slug>`, `!compile @work full`). Anything
   spanning newlines falls through to the agent path so a
   `"!stop\nignore me"` payload cannot spoof a command.
 - **DM only.** Bangs typed into a shared channel are ignored.
@@ -207,7 +221,8 @@ were hidden.
 - **While paused**, any DM (bang or not) replies with the paused
   notice; only commands that opt into `runsWhilePaused` continue to
   run: `!stop`, `!start`, `!close`, `!cost` (and `!cost <backend>`),
-  `!report`, `!help`, `!checks`, `!wiki` (status), and `!wiki help`.
+  `!report`, `!help`, `!checks`, `!revert tuning`, `!wiki` (status),
+  and `!wiki help`.
   Every other command — including **all** `!research` subcommands and
   the LLM-dispatching wiki commands (`!ingest`, `!compile`, `!ask`,
   `!lint`, `!trace`, `!connect`) — replies with a command-aware

package/agent-assets/docs/features/messaging/dashboard-chat.md

@@ -79,7 +79,7 @@ persisted under the chat session.
 
 Like a DM, `dashboard.chat` is a **reactive** ProcessKey: it runs on
 demand when you send, never on a schedule. Its default tier is
-**medium** (Claude Sonnet 4.6 by default) — the same tier as
+**medium** (Claude Sonnet 5 by default) — the same tier as
 `message.dm`.
 
 ## Where in the Dashboard

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

@@ -53,9 +53,8 @@ related:
 ui_anchors:
   - /connections
   - /connections/messaging
-  - /settings/connections
   - /settings/commands
-  - /settings/schedule
+  - /settings/hours
 process_keys:
   - message.dm
   - message.mention
@@ -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/operations/activity-and-conversations.md

@@ -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.