@aitne-sh/aitne 0.1.12 → 0.1.13

package/agent-assets/docs/guides/import-knowledge-file.md

@@ -15,9 +15,7 @@ summary: |
   recipes for exporting your existing profile out of ChatGPT and Gemini.
 section: import-knowledge-file
 tags:
-  - guides
   - knowledge
-  - import
   - memory
 status: stable
 ask_examples:
@@ -27,7 +25,7 @@ ask_examples:
   - What format does the Knowledge upload accept?
 locale: en-US
 created: 2026-04-28
-updated: 2026-05-28
+updated: 2026-07-01
 ui_anchors:
   - /knowledge
 keywords:
@@ -58,9 +56,10 @@ Bring a single Markdown (`.md`, `.markdown`) or plain-text (`.txt`)
 file you wrote elsewhere — a hand-written profile, an Obsidian or
 Notion export, or a summary you produced in ChatGPT / Gemini — into
 Aitne's `identity/*.md` Context Files. The agent reads the file once
-and appends each fact verbatim into the right topic file. Existing
-bullets are never overwritten; identity-class facts are deferred for
-your explicit confirmation.
+and appends each fact, word for word, into the right topic file. It
+never overwrites bullets you already have, and it holds back
+identity-class facts — things like your legal name or timezone — until
+you confirm them yourself.
 
 ## Prerequisites
 
@@ -130,8 +129,8 @@ date inline, so you can resolve them later without losing data.
 - **`415 unsupported_extension`** — the file is not `.md`,
   `.markdown`, or `.txt`. Convert PDFs / DOCX / HTML to plain
   Markdown first.
-- **`413 file_too_large`** — exceed 64 KB. Split the file into
-  smaller chunks and upload each separately.
+- **`413 file_too_large`** — the file is over 64 KB. Split it into
+  smaller chunks and upload each one separately.
 - **`400 secret_shape_detected`** — the route found content shaped
   like a private key or token. Remove the offending lines and re-
   upload.
@@ -152,8 +151,8 @@ following two paths produce a file that uploads cleanly.
 ### Recommended: ask ChatGPT to write it for you (≈ 2 min)
 
 Works against ChatGPT's *Memory* feature — the model already holds a
-list of personal facts about you. This procedure asks it to dump them
-in the exact format the upload expects.
+list of personal facts about you. This recipe asks it to write those
+out in the exact format the upload expects.
 
 1. Open <https://chatgpt.com> and start a **new conversation**. (Use
    a model with Memory enabled — GPT-4o, GPT-5, etc.)

package/agent-assets/docs/guides/install-and-run.md

@@ -15,12 +15,10 @@ summary: |
   start the daemon and dashboard, and open the dashboard at :8322.
 section: install-and-run
 tags:
-  - core
-  - guides
   - getting-started
-  - install
   - setup
   - operations
+  - migration
 status: stable
 ask_examples:
   - How do I install Aitne?
@@ -29,7 +27,7 @@ ask_examples:
   - How do I install the aitne npm package?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - install
   - first run
@@ -90,10 +88,10 @@ pnpm install
 pnpm start
 ```
 
-`pnpm start` builds first when the source is stale (mtime check against
-`.buildstamp`), then launches the daemon + dashboard detached. The
-`pnpm <cmd>` scripts are thin aliases that forward to
-`node bin/aitne.mjs <cmd>`.
+`pnpm start` builds first if the source has changed since the last build
+(a modified-time check against `.buildstamp`), then launches the daemon
+and dashboard in the background. The `pnpm <cmd>` scripts are thin aliases
+that forward to `node bin/aitne.mjs <cmd>`.
 
 ### Then, for both paths
 
@@ -101,8 +99,9 @@ Open `http://localhost:8322` and follow the setup wizard.
 
 ## Verification
 
-- `aitne status` (or `pnpm status` from a clone) shows two PIDs (daemon
-  + dashboard), uptime, connected backends, and a green health pill.
+- `aitne status` (or `pnpm status` from a clone) shows two process IDs
+  (one for the daemon, one for the dashboard), uptime, connected backends,
+  and a green health pill.
 - `~/.personal-agent/` has been created, containing
   `data/personal_agent.db`, `context/`, and `logs/`.
 

package/agent-assets/docs/guides/maintain-wiki-health.md

@@ -16,7 +16,6 @@ summary: |
   approval before promoting them.
 section: maintain-wiki-health
 tags:
-  - guides
   - wiki
   - health
 status: stable
@@ -28,7 +27,7 @@ ask_examples:
   - What is a taxonomy candidate?
 locale: en-US
 created: 2026-05-12
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - wiki health
   - wiki lint
@@ -59,11 +58,12 @@ ui_anchors:
 
 # Maintain Wiki Health
 
-The wiki is a living artifact. Notes accumulate, sources drift,
-slugs collide, and the taxonomy slowly diverges from the vocabulary
-your raw notes actually use. `!lint` is the periodic audit pass
-that surfaces all of this in one report — without changing your
-notes itself.
+The wiki is a living thing. Notes pile up, sources go stale,
+slugs (the short id each note is filed under) collide, and the
+taxonomy — the list of canonical topic names your notes are filed
+under — slowly drifts away from the words your raw notes actually
+use. `!lint` is the periodic audit that surfaces all of this in one
+report, without changing any of your notes.
 
 ## When to Run
 
@@ -120,7 +120,7 @@ page is also reachable from a button at the top of `/settings/wiki`,
 and the same view is mirrored under `/settings/wiki/timeline`. The
 most-recent report is parsed and rendered with:
 
-- A coloured date badge.
+- A colored date badge.
 - The `## Summary` bullets.
 - The `## Action items` list (this is the part you actually act on).
 - A "View full report" expander showing the raw Markdown for
@@ -132,8 +132,8 @@ that produced the state.
 
 ## Acting on Action Items
 
-The audit never modifies content layers itself. For each action
-item:
+The audit never edits your notes itself — it only reports. For each
+action item:
 
 - **Orphan** → either link the note from `20_wiki/_index.md` and
   related notes, or archive it. From a DM you can run `!ask` to

package/agent-assets/docs/guides/migrate-machines.md

@@ -15,7 +15,6 @@ summary: |
   because schema migrations auto-forward at boot.
 section: migrate-machines
 tags:
-  - guides
   - operations
   - migration
   - backup
@@ -25,7 +24,7 @@ ask_examples:
   - Will my DB still work after upgrading on the new machine?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-07-01
 keywords:
   - migrate
   - move install
@@ -50,22 +49,25 @@ context-file history or activity logs.
 | `~/.personal-agent/data/personal_agent.db` (sessions, actions, observations, FTS) | Messaging pairing tokens (Slack / Telegram / Discord / WhatsApp) |
 | `~/.personal-agent/logs/` (optional — for reference) | Integration OAuth grants (Gmail / Google Calendar / Notion) |
 
-The DB carries cleanly even across daemon versions: at boot, Aitne
-runs forward-only migrations from `packages/daemon/src/db/migrations.ts`
-that bring older schemas up to the current shape. As long as you're
-upgrading (not downgrading), the same DB works.
+The database carries cleanly even across daemon versions. Each time it
+starts, Aitne runs forward-only migrations from
+`packages/daemon/src/db/migrations.ts` — one-way updates that bring an
+older database up to the current shape. As long as you're upgrading
+(not downgrading), the same database works.
 
 ## Steps
 
-1. **On the old machine:** stop the daemon.
+1. **On the old machine:** stop the daemon (the background Aitne process).
    ```bash
    aitne stop
    ```
-2. **Copy the data directory** to the new machine — context plus DB.
+2. **Copy the data directory** to the new machine — the context files
+   plus the database. The command below uses `rsync`, a standard
+   file-copy tool.
    ```bash
    rsync -av ~/.personal-agent/ user@new-host:~/.personal-agent/
    ```
-   (Or rsync just `context/` and `data/` if you want to skip logs.)
+   (Or copy just `context/` and `data/` if you want to skip the logs.)
 3. **On the new machine:** install per [Install and Run](install-and-run.md).
 4. **Re-register secrets and re-pair messaging** through the dashboard:
    - Re-register each backend's API key, or re-run its CLI auth flow for
@@ -73,16 +75,16 @@ upgrading (not downgrading), the same DB works.
      Gemini run `gemini` and choose **Sign in with Google**.
    - Walk the setup wizard's messaging pairing steps for each app you
      had paired.
-   - Re-authorize each integration's OAuth grant (Gmail / Calendar /
-     Notion are the common ones).
+   - Re-authorize each integration's OAuth grant — the access you
+     approved for Gmail, Calendar, and Notion (the common ones).
 5. Start the daemon.
    ```bash
    aitne start
    ```
 
-On first boot the migration runner brings the carried DB up to the
-new daemon's schema. Check the daemon log if you want to see exactly
-which migrations applied:
+On first boot the migration runner brings the carried database up to
+the new daemon's schema. Check the daemon log if you want to see
+exactly which migrations applied:
 
 ```bash
 aitne logs -n 200 | grep -i migration

package/agent-assets/docs/guides/multiple-wikis-for-multiple-domains.md

@@ -15,7 +15,6 @@ summary: |
   on disk.
 section: guides
 tags:
-  - guides
   - wiki
   - workspaces
   - knowledge
@@ -26,7 +25,7 @@ ask_examples:
   - What does `@research` do before a wiki command?
 locale: en-US
 created: 2026-05-12
-updated: 2026-05-28
+updated: 2026-07-01
 keywords:
   - multi-workspace
   - wiki workspace
@@ -76,10 +75,10 @@ DM agent routes commands per workspace; the file trees never overlap.
   pull from your parenting journal. Separate workspaces give you
   separate `_index.md` and `20_wiki/` trees so the agent never has to
   filter across domains.
-- **Different audiences.** A workspace synced via Obsidian to a shared
-  iCloud folder for a team is governed differently from the daemon's
-  internal workspace under its data directory. Per-workspace settings
-  handle the asymmetry.
+- **Different audiences.** A workspace that Obsidian syncs to a shared
+  iCloud folder for a team needs different handling from the daemon's
+  own internal workspace under its data directory. Per-workspace
+  settings let you treat each one on its own terms.
 - **Different cadences.** A "current project" wiki gets multiple
   ingests per day; a long-term commonplace book may compile weekly.
   Per-workspace dispatch / cost / approval thresholds let you tune
@@ -138,12 +137,12 @@ comma-separated arguments verbatim.
 
 ## What the agent sees per workspace
 
-Each session is materialised against a single workspace's tree. The
-`wiki-vault-rules` skill loaded for the session names that workspace's
-language, dispatch mode, layer invariants, and frontmatter
-conventions. Layer authorisation in the daemon API is workspace-scoped
-— a `wiki.ask` session against `@research` cannot reach into
-`@parenting`'s `10_raw/` even if the agent attempts it.
+Each session works against a single workspace's file tree. The
+`wiki-vault-rules` skill loaded for the session spells out that
+workspace's language, dispatch mode, layer rules, and frontmatter
+conventions. Access to vault layers is workspace-scoped in the daemon
+API: a `wiki.ask` session against `@research` cannot reach into
+`@parenting`'s `10_raw/`, even if the agent tries.
 
 ## `!wiki` status with multiple workspaces
 

package/agent-assets/docs/guides/pause-the-agent.md

@@ -12,7 +12,6 @@ summary: |
   every routine, or use dashboard toggles and quiet hours for finer control.
 section: pause-the-agent
 tags:
-  - guides
   - operations
   - messaging
   - autonomous
@@ -23,7 +22,7 @@ ask_examples:
   - Can I disable everything for a week?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-10
+updated: 2026-07-01
 keywords:
   - pause agent
   - stop agent
@@ -58,24 +57,25 @@ losing your install.
 
 ## The fastest pause: `!stop`
 
-DM `!stop` to the agent on any paired messaging app. This is the
-recommended way to go silent and the only one you need for most cases:
+DM `!stop` to the agent on any paired messaging app (any chat app you
+have connected). This is the recommended way to go silent, and the only
+step you need for most cases:
 
-- It pauses **every** cron-driven routine — morning, evening, weekly,
+- It pauses **every** scheduled routine — morning, evening, weekly,
   monthly, and the activity scan — not just one of them.
-- Non-command DMs are declined with a paused notice (no LLM cost)
-  until you resume.
-- The paused state is persisted, so a daemon restart does **not**
-  silently resume autonomous work.
-- In-flight runs are not aborted; the pause takes effect from the next
-  scheduled tick.
+- While paused, a plain (non-command) DM gets a short "paused" reply
+  instead of an answer, so it costs nothing to run.
+- The pause is saved to disk, so restarting the daemon does **not**
+  quietly start the agent working again.
+- A run that is already in progress keeps going; the pause applies from
+  the next scheduled run onward.
 
 Resume with `!start` whenever you want the agent active again. See
 [Bang Commands](../features/messaging/bang-commands.md).
 
 ## Finer-grained control from the dashboard
 
-If you want to mute specific behaviour rather than pause everything:
+If you want to quiet one specific behavior rather than pause everything:
 
 1. **Disable the activity scan** — open `/agents/activity-scan` and click
    **Disable**. This leaves the morning, evening, weekly, and monthly
@@ -90,22 +90,22 @@ If you want to mute specific behaviour rather than pause everything:
    take an `HH:MM` string. Routines still run; they just don't notify
    you.
 
-Morning (fires at the day boundary, default 04:00), evening (18:00),
-and weekly (Fri 19:00) reviews each have a per-routine Enable/Disable
-toggle on the `/agents` page — open `/agents/<slug>` (e.g.
-`/agents/weekly-review`) and click Disable (a stop-warning confirmation
-appears for these system agents). To halt all of them at once, use
-`!stop` above instead. Each routine's instructions (its rulebook) are
-edited on the same page's **Rulebook** tab
-(`/agents/<slug>?tab=rulebook`).
+The morning review (fires at the day boundary — the moment "today"
+rolls over, 04:00 by default), evening (18:00), and weekly (Fri 19:00)
+reviews each have their own Enable/Disable toggle on the `/agents`
+page. Open `/agents/<slug>` (e.g. `/agents/weekly-review`) and click
+Disable; a stop-warning confirmation appears for these system agents.
+To halt all of them at once, use `!stop` above instead. To edit a
+routine's instructions (its rulebook), use the same page's **Rulebook**
+tab (`/agents/<slug>?tab=rulebook`).
 
 ## Last resort: stop the daemon
 
-`aitne stop` shuts the daemon down entirely (graceful SIGTERM, then
-SIGKILL after 10 seconds). Nothing runs — no routines, no messaging, no
-dashboard. Use this only when you want the agent fully offline; for a
-temporary pause that survives across days, prefer `!stop`. Restart with
-`aitne start`.
+`aitne stop` shuts the daemon down entirely: it asks the process to
+quit (SIGTERM), then forces it (SIGKILL) after 10 seconds. Nothing
+runs — no routines, no messaging, no dashboard. Use this only when you
+want the agent fully offline. For a temporary pause that survives across
+days, prefer `!stop`. Restart with `aitne start`.
 
 ## Verification
 

package/agent-assets/docs/guides/reinstall-cleanly.md

@@ -17,9 +17,7 @@ summary: |
   DB is genuinely corrupt.
 section: reinstall-cleanly
 tags:
-  - guide
   - operations
-  - reinstall
   - migration
   - backup
 status: stable
@@ -30,7 +28,7 @@ ask_examples:
   - Do I need to wipe the DB to upgrade Aitne?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-07-01
 keywords:
   - reinstall
   - factory reset
@@ -54,10 +52,12 @@ ui_anchors:
 
 ## You Almost Never Need This
 
-Aitne upgrades through **forward-only schema migrations** applied at
-daemon boot — your DB and context files survive every
+Aitne upgrades itself safely. Each time the background service (the
+**daemon**) starts, it runs **forward-only schema migrations** — small
+scripts that update the database structure without erasing anything. So
+your database and context files survive every
 `npm install -g @aitne-sh/aitne@latest` upgrade. If you're reading this
-because you just upgraded, **don't run the steps below**; restart the
+right after upgrading, **don't run the steps below.** Just restart the
 daemon and let the migration runner do its job.
 
 This guide is the last-resort escape hatch for:
@@ -97,8 +97,8 @@ with different scopes — make sure you're running the one you mean:
    ```bash
    cp -R ~/.personal-agent/context backup/
    ```
-   Context Markdown is what makes the agent know who you are; the DB is
-   recoverable, context is not.
+   Context Markdown is how the agent knows who you are; the DB can be
+   rebuilt, but context cannot.
 3. **Back up the DB** if there's any chance you'll want to recover it
    later:
    ```bash
@@ -115,8 +115,9 @@ with different scopes — make sure you're running the one you mean:
    ```bash
    rm ~/.personal-agent/data/personal_agent.db*
    ```
-   (The `*` glob clears `-shm` / `-wal` left behind by WAL mode. The DB
-   lives inside `data/`, not at the top of the data dir.)
+   (The `*` at the end also clears the `-shm` and `-wal` helper files
+   that SQLite's write-ahead log leaves behind. The DB lives inside
+   `data/`, not at the top of the data dir.)
 3. Start the daemon.
    ```bash
    aitne start
@@ -135,5 +136,5 @@ with different scopes — make sure you're running the one you mean:
 
 - [Backup and Restore](backup-and-restore.md)
 - [Migrate Machines](migrate-machines.md)
-- [Schema Migration](../glossary.md#schema-migration) — the boring
-  alternative to this guide that runs automatically on every boot.
+- [Glossary: Schema Migration](../glossary.md) — the boring alternative
+  to this guide that runs automatically on every boot.

package/agent-assets/docs/guides/setup-wizard.md

@@ -15,8 +15,6 @@ summary: |
   Rules step.
 section: guides
 tags:
-  - core
-  - guides
   - getting-started
   - setup
   - backends
@@ -29,7 +27,7 @@ ask_examples:
   - Where do I paste my API key?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-10
+updated: 2026-07-01
 keywords:
   - setup
   - wizard
@@ -65,10 +63,10 @@ ui_anchors:
 
 ## Goal
 
-Take a fresh install through the wizard with informed answers at each
-step. The wizard is rerunnable any time at `/setup?mode=update`, which
-jumps straight to the Customize Rules step so you can refine the agent
-without redoing the whole flow.
+Walk a fresh install through the wizard, making an informed choice at
+each step. You can rerun the wizard any time at `/setup?mode=update`,
+which jumps straight to the Customize Rules step so you can refine the
+agent without redoing the whole flow.
 
 ## Prerequisites
 
@@ -77,10 +75,10 @@ without redoing the whole flow.
 
 ## The steps at a glance
 
-The wizard has eight collection steps plus a terminal "Done" screen.
-Three are required (**Basics**, **Vault**, **AI Backend**, plus
-**Customize Rules**); the four integration/messaging steps are
-skippable and re-runnable later.
+The wizard has eight collection steps plus a final "Done" screen. Four
+of them are required — **Basics**, **Vault**, **AI Backend**, and
+**Customize Rules**; the other four (the integration and messaging
+steps) are skippable, and you can run them later.
 
 | # | Step | Required? | What it sets |
 |---|------|-----------|--------------|

package/agent-assets/docs/guides/switch-default-backend.md

@@ -14,7 +14,6 @@ summary: |
   different backend.
 section: switch-default-backend
 tags:
-  - guides
   - backends
   - operations
   - routing
@@ -25,7 +24,7 @@ ask_examples:
   - How do I change the main backend the agent uses?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-07-01
 keywords:
   - main backend
   - switch backend
@@ -52,9 +51,10 @@ api_endpoints:
 ## Goal
 
 Change which backend the agent uses by default for most work —
-`claude`, `codex`, `gemini`, or `opencode`. This is the broad switch
-that re-seeds every ProcessKey to the new backend's per-tier default
-models. To change just one ProcessKey instead, see
+`claude`, `codex`, `gemini`, or `opencode`. This is the broad switch:
+it re-seeds every ProcessKey (each named job the agent runs, like a DM
+reply or a morning routine) to the new backend's default model for
+that job's tier. To change just one ProcessKey instead, see
 [Change which model handles X](change-which-model-handles-x.md).
 
 ## Prerequisites
@@ -65,10 +65,10 @@ will start failing the moment it routes work there.
 - Register an API key for the backend on `/settings/models`
   (`anthropic` / `openai` / `google`, or one of the cloud-provider
   options for that backend).
-- API keys are the supported path. If no key is set, the daemon falls
-  back to whatever subscription login the backend's CLI already has —
-  the auth-health card on `/settings/models` flags this so you can
-  tell which credential is actually in use.
+- An API key is the supported way in. If no key is set, the daemon
+  falls back to whatever subscription login the backend's CLI already
+  has — the auth-health card on `/settings/models` flags this so you
+  can tell which credential is actually in use.
 
 ## Steps
 

package/agent-assets/docs/guides/use-an-existing-obsidian-vault.md

@@ -14,9 +14,7 @@ summary: |
   through Adopt vs Migrate vs Split.
 section: use-an-existing-obsidian-vault
 tags:
-  - guides
   - wiki
-  - obsidian
   - knowledge
 status: stable
 ask_examples:
@@ -26,7 +24,7 @@ ask_examples:
   - Why is Split greyed out?
 locale: en-US
 created: 2026-05-12
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - external vault
   - existing obsidian vault
@@ -58,11 +56,11 @@ process_keys:
 
 ## Goal
 
-Aitne can point the wiki subsystem at a vault you already maintain
-in Obsidian, instead of creating its own at `$PA_DATA_DIR/wiki`.
-This is "external mode", and the setup wizard walks you through
-three decisions: **probe**, **classify**, then **Adopt vs Migrate
-vs Split**.
+Aitne can point the wiki at a vault you already keep in Obsidian,
+instead of creating its own at `$PA_DATA_DIR/wiki`. This is called
+"external mode". The setup wizard walks you through three steps:
+it **probes** the folder you pick, **classifies** what it finds,
+then asks you to choose **Adopt vs Migrate vs Split**.
 
 ## Step 1 — Open Settings → Wiki
 
@@ -110,9 +108,9 @@ levels:
   an existing wiki layout is detected, the wizard will surface the
   Adopt / Migrate decision in Step 3.
 
-The **Use this folder** button is greyed out while the banner
-is an error so you cannot fire a workspace-create that the daemon
-already knows will fail.
+The **Use this folder** button stays greyed out while the banner
+shows an error, so you cannot start a workspace-create that the
+daemon already knows will fail.
 
 ## Step 2 — Probe Classifies the Vault
 

package/agent-assets/docs/pages/activity.md

@@ -0,0 +1,76 @@
+---
+schema_version: 1
+slug: pages/activity
+title: "Agent Log Page"
+id: page-activity
+aliases:
+  - agent log page
+  - activity page
+  - log page
+  - conversations page
+category: pages
+summary: |
+  The Agent Log is the historical record of everything the agent has seen
+  or done — invocations (Events), daemon output (System Logs), completed
+  chat threads (Conversations), and proactive outbound messages
+  (Notifications).
+tags:
+  - audit
+  - notifications
+  - operations
+status: stable
+ask_examples:
+  - What can I do on the Agent Log page?
+  - Where do I see why a routine failed?
+  - Where do I read a full conversation transcript?
+  - Where are the daemon's system logs?
+locale: en-US
+created: 2026-07-01
+updated: 2026-07-01
+keywords:
+  - agent log
+  - activity
+  - events
+  - system logs
+  - conversations
+  - notifications
+related:
+  - features/operations/activity-and-conversations
+  - features/operations/notifications
+  - features/operations/backend-routing
+  - pages/analytics
+ui_anchors:
+  - /activity
+  - /conversations
+---
+
+# Agent Log Page
+
+The `/activity` page is the agent's audit trail — a permanent record you can
+look back on of everything the agent has seen or done, split across four tabs.
+
+## What you can do here
+
+- **Events** — one row each time the agent ran (an "invocation"): what
+  triggered the run, which backend served it, and whether it succeeded or
+  failed. This is where you diagnose a routine that didn't do what you expected.
+- **System Logs** — output from the daemon itself: startup messages, errors,
+  and warnings from the Hono server.
+- **Conversations** — completed chat threads from every messaging platform,
+  each of which you can open as a full transcript.
+- **Notifications** — messages the agent sent you on its own, without you
+  asking.
+
+## Where to go deeper
+
+- [Activity & Conversations](../features/operations/activity-and-conversations.md)
+  — the audit timeline and per-session transcripts in detail.
+- [Notifications](../features/operations/notifications.md) — when and how
+  the agent reaches out.
+- [Backend routing](../features/operations/backend-routing.md) — how to
+  read the "which backend served it" column.
+
+## Related
+
+- [Analytics page](analytics.md) — the aggregated view of this same data.
+- [Overview page](overview.md) — the recent-events feed is a slice of Events.