@aitne-sh/aitne 0.1.12 → 0.1.13

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

@@ -26,7 +26,7 @@ ask_examples:
   - How often does the daemon poll my repos?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - git
   - commit
@@ -53,31 +53,33 @@ api_endpoints:
 
 # Git
 
-Add local git repositories to a watched set; the daemon polls them
-and the activity scan decides whether the recent activity is worth
-flagging.
+Add local git repositories to a watched set. The daemon checks them
+on a schedule (it polls them), and the activity scan decides whether
+the recent activity is worth flagging.
 
 ## What It Does
 
-- **Polls** each watched repo every `gitPollIntervalSeconds`.
-- **Records observations** when new commits land between polls. The
-  commit author is included so agent-originated commits do not
-  re-surface to the agent (defended via `AgentWriteTracker`).
+- **Checks (polls)** each watched repo every `gitPollIntervalSeconds`
+  seconds.
+- **Records an observation** when new commits land between two checks.
+  It notes who authored each commit, so commits the agent made itself
+  are not shown back to it (enforced by `AgentWriteTracker`).
 - **Surfaces patterns**, not individual commits — three small commits
-  in an hour will not page you.
+  in an hour will not each trigger a notification.
 
 The agent never pushes, never amends, never force-resets. Read-only
 by design.
 
 ## When It Runs / How It Is Triggered
 
-- The poller is continuous.
-- The activity scan consumes the accumulated observations.
+- The poller runs continuously in the background.
+- The activity scan reads the observations it has collected.
 
 ## What It Outputs
 
-- An `observation` row per detected change set.
-- A summary in the activity scan's output when observations qualified.
+- One `observation` row for each detected set of changes.
+- A summary in the activity scan's output when those observations are
+  worth reporting.
 
 ## Where in the Dashboard
 

package/agent-assets/docs/features/integrations/github.md

@@ -29,7 +29,7 @@ ask_examples:
   - Where do I add a GitHub repo to watch?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - github
   - issue
@@ -61,14 +61,16 @@ context_files:
 
 # GitHub
 
-The daemon polls GitHub via the local `gh` CLI: review requests, CI
-failures on the default branch, security alerts, and assignments
-become DMs; everything else is recorded for the activity scan.
+The daemon polls GitHub through the local `gh` CLI. Four kinds of
+signal turn into a direct message (DM): review requests, CI failures
+on the default branch, security alerts, and assignments. Everything
+else is recorded for the activity scan instead of pinging you.
 
 ## What It Does
 
 - **Polls Notifications** every `githubPollIntervalSeconds` (default
-  1800s / 30 min) using ETag caching — 304 responses cost no
+  1800s / 30 min) using ETag caching, so when nothing has changed
+  GitHub returns a 304 ("not modified") and that poll costs no
   rate-limit quota.
 - **Polls workflow_runs** per watched GitHub repository, filtered by
   `status=failure`. Each repo's GitHub side comes from a unified
@@ -84,8 +86,8 @@ The agent never auto-comments, auto-merges, or pushes.
 ## High-priority events
 
 The agent will DM the user (priority `high`; during quiet hours the DM
-is deferred until they end rather than dropped — only `critical`
-safety messages break through) on:
+waits until quiet hours end rather than being dropped — only
+`critical` safety messages break through) on:
 
 - A teammate or bot **requested your review** on a PR — only when it
   looks time-sensitive (release-blocker keywords in the title, or the
@@ -149,9 +151,9 @@ Watched repos are no longer config keys. The old `gitRepos` /
 cutover — repos now live in the `repositories` table and are managed on
 **Connections → Repositories**. Per-repo polling cadence is set on
 **My Life → Git** and overrides the global interval for that repo's
-workflow-runs poll. The global interval is the floor — a per-repo
-cadence longer than it slows that repo down, while a shorter one
-still polls at the global tick.
+workflow-runs poll. The global interval is the floor: a per-repo
+cadence longer than the global one slows that repo down, but a shorter
+one still only polls at the global tick.
 
 ## When Something Goes Wrong
 

package/agent-assets/docs/features/integrations/mail.md

@@ -19,7 +19,6 @@ section: integrations
 tags:
   - integrations
   - mail
-  - core
 status: stable
 ask_examples:
   - How do I connect my Gmail to the agent?
@@ -27,7 +26,7 @@ ask_examples:
   - How do I add a second mail account?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - mail
   - gmail
@@ -60,46 +59,46 @@ context_files:
 
 # Mail
 
-Connect one or more mailboxes (Gmail, Outlook, Yahoo, or iCloud) and
-Aitne polls them, classifies incoming threads, and
-lets the agent search / label / read via the `mail` skill. Search is
-local — backed by SQLite FTS5 — so the agent doesn't need to round-trip
-the provider for every query.
+Connect one or more mailboxes (Gmail, Outlook, Yahoo, or iCloud). Aitne
+then polls them, sorts incoming threads, and lets the agent search,
+label, and read your mail through the `mail` skill. Search runs locally,
+backed by a SQLite full-text index (FTS5), so the agent doesn't have to
+call the provider every time you ask about your inbox.
 
 ## What It Does
 
-- **Read & search** existing threads (FTS5-backed local index).
-- **Classify** incoming messages — is it a travel booking, a receipt
-  attachment, a Kindle notebook export.
-- **Label** threads so the operator and the agent agree on triage state.
-- **Surface** the small set of mail items in the morning routine that
-  actually need owner action.
+- **Read & search** existing threads (from the local FTS5 index).
+- **Classify** incoming messages — for example, a travel booking, a
+  receipt attachment, or a Kindle notebook export.
+- **Label** threads so you and the agent agree on where each one stands.
+- **Surface** the few mail items in the morning routine that actually
+  need your attention.
 
-The agent **prefers drafts** over sending. By convention it creates a
-draft (`POST /mail/:account/drafts`) and lets you review and hit send
+The agent **prefers drafts** over sending. By default it writes a draft
+(`POST /mail/:account/drafts`) and leaves it for you to review and send
 yourself. Direct send (`POST /mail/:account/messages/send`) is *not*
-blocked — it is classified as an autonomous action, so the daemon does
-not DM you for approval first. The agent only sends directly when it
-judges you'd clearly want it to, and it tells you afterward; during the
-activity scan the `mail` skill is hard read-only (no sending, drafting,
-labeling, or filing).
+blocked — it counts as an autonomous action, so the daemon does not DM
+you for approval first. The agent only sends on its own when it's clear
+you'd want it to, and it tells you afterward. During the activity scan
+the `mail` skill is strictly read-only: no sending, drafting, labeling,
+or filing.
 
 ## When It Runs / How It Is Triggered
 
-- In `direct` mode a poller pulls new messages on a cadence. Gmail uses
-  `gmailPollIntervalSeconds` (default 600); all other accounts (Outlook,
-  Yahoo, iCloud) use `mailPollIntervalSeconds` (default 180).
-  The Gmail cadence is adjustable under **Settings → Infrastructure**.
-- The morning routine reads the labeled queue and decides which need
-  surfacing.
-- Reactive turns (you DM "what's in my mail?") use the `mail` skill on
-  demand.
+- In `direct` mode a poller checks for new messages on a set interval.
+  Gmail uses `gmailPollIntervalSeconds` (default 600); all other accounts
+  (Outlook, Yahoo, iCloud) use `mailPollIntervalSeconds` (default 180).
+  You can adjust the Gmail interval under **Settings → Infrastructure**.
+- The morning routine reads the labeled queue and picks which threads to
+  bring to your attention.
+- When you ask directly (you DM "what's in my mail?"), the agent uses the
+  `mail` skill on demand.
 
 ## Integration Modes
 
 Gmail and Outlook support all four integration modes
-(`direct | delegated | native | disabled`); each may sit in a
-different mode. Yahoo and iCloud have no integration-registry entry —
+(`direct | delegated | native | disabled`), and each account can sit in
+a different mode. Yahoo and iCloud have no integration-registry entry, so
 they are direct-only by design.
 
 | Provider | Direct | Delegated | Native | Notes |
@@ -109,9 +108,10 @@ they are direct-only by design.
 | Yahoo | ✓ | — | — | IMAP transport. Direct-only; never enters the delegated surface. |
 | iCloud | ✓ | — | — | IMAP transport. Direct-only; never enters the delegated surface. |
 
-Mode flips run through the §14.7 live probe + the per-key
-`runtime_state.integration_flip_lock:<key>`. Changing the main
-backend cascades unmatched `native` rows to `disabled`.
+Switching a provider between modes goes through the §14.7 live probe and
+a per-key lock (`runtime_state.integration_flip_lock:<key>`). If you
+change the main backend, any `native` rows it no longer matches fall back
+to `disabled`.
 
 See [Delegated Mode](../../concepts/delegated-mode.md) for the full
 mode lifecycle.
@@ -119,10 +119,10 @@ mode lifecycle.
 ## What It Outputs
 
 - New threads land in the local `mail_messages_index` table
-  (FTS-indexed via `fts_mail_messages`).
-- Labels/tags are written via the provider API when the agent applies
-  them (`POST /mail/:account/messages/:id/tags`).
-- A short "mail" section in `state/today.md` when items qualified.
+  (full-text indexed via `fts_mail_messages`).
+- Labels and tags are written back through the provider API when the
+  agent applies them (`POST /mail/:account/messages/:id/tags`).
+- A short "mail" section in `state/today.md` when items qualify.
 
 ## Where in the Dashboard
 
@@ -132,18 +132,20 @@ mode lifecycle.
 
 ## Configuration
 
-Per account you choose a provider kind (`gmail` / `outlook` / `yahoo` /
-`icloud`) plus credentials and an optional display label. You
+For each account you choose a provider kind (`gmail` / `outlook` /
+`yahoo` / `icloud`), plus credentials and an optional display label. You
 pick the kind, not the transport — Yahoo and iCloud connect over IMAP
-under the hood, but that is an implementation detail. The set of enabled
-providers is `enabledMailProviders` (default `["gmail"]`).
+behind the scenes, but that's an implementation detail you don't manage.
+The list of enabled providers is `enabledMailProviders` (default
+`["gmail"]`).
 
 ## When Something Goes Wrong
 
-- An **auth failure** points at expired credentials. The dashboard's
-  auth-health card flips to a warning. See [Auth Failed](../../troubleshooting/auth-failed.md).
-- A **classifier that misses** consistently — switch the model behind
-  it via the Gmail Classification Model card on `/connections/mail`.
+- An **auth failure** usually means the credentials have expired. The
+  dashboard's auth-health card turns to a warning. See
+  [Auth Failed](../../troubleshooting/auth-failed.md).
+- A **classifier that keeps guessing wrong** — switch the model behind it
+  from the Gmail Classification Model card on `/connections/mail`.
 
 ## Related
 

package/agent-assets/docs/features/integrations/notion.md

@@ -13,7 +13,6 @@ summary: |
 section: integrations
 tags:
   - integrations
-  - notion
   - knowledge
   - observations
 status: stable
@@ -24,7 +23,7 @@ ask_examples:
   - Why are my Notion routine fetches skipped?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-11
+updated: 2026-07-01
 keywords:
   - notion
   - page
@@ -48,21 +47,25 @@ api_endpoints:
 
 # Notion
 
-Aitne polls the configured Notion databases, records an
-observation on change, and the activity scan decides whether anything
-warrants surfacing. The agent can also read pages on demand through
+Aitne watches the Notion databases you configure. When a page changes,
+it records an *observation* (a short note that something happened), and
+the [activity scan](../routines/activity-scan.md) — the routine that
+periodically reviews recent activity — decides whether anything is worth
+surfacing to you. The agent can also read Notion pages on demand through
 the `notion` skill.
 
 ## What It Does
 
-- Polls Notion via the official API at `notionPollIntervalSeconds`.
-- Records an observation per detected change.
+- Checks Notion through the official API on the interval set by
+  `notionPollIntervalSeconds`.
+- Records one observation for each change it detects.
 - Lets the agent read pages on demand.
 
 ## When It Runs / How It Is Triggered
 
-Continuous polling in `direct` mode. In `delegated` / `native` / `disabled`
-modes the poller does not run — see Integration Modes below.
+The poller runs continuously, but only in `direct` mode. In the
+`delegated`, `native`, and `disabled` modes it does not run — see
+[Integration Modes](#integration-modes) below.
 
 ## Integration Modes
 
@@ -84,8 +87,9 @@ Notion supports all four integration modes (`direct` / `delegated` /
   `disabled`.
 - **`disabled`** — silence; no observations, no daemon access.
 
-Switching modes requires the integration flip-lock probe to pass
-(connector reachable, capabilities reported). See `POST /api/integrations/notion/probe`.
+Switching modes requires the integration flip-lock probe to pass — a
+quick check that the connector is reachable and reports its
+capabilities. See `POST /api/integrations/notion/probe`.
 
 ## Routine Fetch Targets
 

package/agent-assets/docs/features/integrations/obsidian.md

@@ -8,15 +8,14 @@ aliases:
   - knowledge vault
 category: features
 summary: |
-  Watch an Obsidian vault for new and changed notes. Changes record
-  observations the activity scan consumes; the agent can also read
-  notes on demand.
+  Watch an Obsidian vault for new and changed notes. Each change
+  records an observation that the activity scan later reviews; the
+  agent can also read notes on demand.
 section: integrations
 tags:
   - integrations
   - knowledge
   - observations
-  - obsidian
 status: stable
 ask_examples:
   - How do I connect my Obsidian vault?
@@ -24,7 +23,7 @@ ask_examples:
   - Why didn't the agent see my new note?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-11
+updated: 2026-07-01
 keywords:
   - obsidian
   - vault
@@ -45,18 +44,22 @@ config_keys:
 
 # Obsidian
 
-Point Aitne at your Obsidian vault directory; new and changed notes
-record observations the activity scan consumes. The agent can read and
-write vault notes through the `external-services` skill.
+Point Aitne at your Obsidian vault folder (the directory where your
+notes live). When you add or change a note, Aitne records an
+observation — a short note-to-self that the
+[activity scan](../routines/activity-scan.md) reviews on its next run.
+The agent can also read and write vault notes through the
+`external-services` skill.
 
-Reads and writes go through the Obsidian app's CLI — the Obsidian app
-must be running, or vault read/write calls fail.
+Reads and writes go through the Obsidian app's own command-line tool
+(CLI), so the Obsidian app must be running — otherwise vault read and
+write calls fail.
 
 ## What It Does
 
-- Watches the vault for filesystem changes.
-- Filters out agent-originated writes via `AgentWriteTracker`.
-- Records observations for genuine operator edits.
+- Watches the vault folder for file changes.
+- Ignores writes the agent made itself, using `AgentWriteTracker`.
+- Records an observation for each edit you make by hand.
 
 ### Will it edit my notes?
 
@@ -70,10 +73,11 @@ its own output.
 ## When It Runs / How It Is Triggered
 
 Continuously — the watcher runs as long as the daemon is up and a vault
-path is configured (`externalObsidianWatch=true`). Saves are debounced
-by `obsidianDebounceSeconds` before an observation is recorded; the
-[activity scan](../routines/activity-scan.md) later consumes those
-observations.
+path is configured (`externalObsidianWatch=true`). After you save,
+Aitne waits `obsidianDebounceSeconds` before recording the change (a
+short pause called debouncing), so a burst of quick saves is folded
+into one observation. The [activity scan](../routines/activity-scan.md)
+picks up those observations on its next run.
 
 ## Where in the Dashboard
 
@@ -84,15 +88,15 @@ observations.
 | Setting | Default | Notes |
 |---|---|---|
 | `externalObsidianVaultPath` | unset | Vault directory; set in Connections → Notes. |
-| `externalObsidianWatch` | true | Set false to keep the path but stop recording changes (large-vault churn control). |
-| `obsidianDebounceSeconds` | 5 | How long to wait after a save before recording. |
+| `externalObsidianWatch` | true | Set false to keep the path but stop recording changes — handy for a large, busy vault. |
+| `obsidianDebounceSeconds` | 5 | How many seconds to wait after a save before recording. |
 
 ## When Something Goes Wrong
 
-- A vault read or write that failed: the Obsidian app must be running,
-  since reads and writes proxy through its CLI. Open Obsidian and retry.
-- A change that did not record: the debounce may have folded multiple
-  saves; the next one will fire.
+- A read or write failed: the Obsidian app must be running, because
+  reads and writes go through its CLI. Open Obsidian and try again.
+- A change didn't show up: the debounce pause may have folded several
+  saves together; the next save will record it.
 
 ## Related
 

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

@@ -28,7 +28,6 @@ tags:
   - github
   - autonomous
   - observations
-  - core
 status: stable
 ask_examples:
   - What is the My Life › Git page for?
@@ -46,7 +45,7 @@ ask_examples:
   - How much does one Architecture refresh cost?
 locale: en-US
 created: 2026-05-05
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - my life
   - git
@@ -102,18 +101,18 @@ The page lists every repository registered on
 **Connections → Repositories** and exposes three collapsible sections
 per repo (all open by default so the controls are visible at a glance):
 
-1. **Polling** — overrides the global `gitPollIntervalSeconds` for
-   this repository alone. Useful when one repo is high-traffic and
-   you want it scanned more aggressively (or vice-versa). Also shows
-   the most recent observations gathered from that repo's polling
-   sources.
+1. **Polling** — how often the agent checks this repo for new
+   activity. It overrides the global `gitPollIntervalSeconds` for
+   this repository alone, which is handy when one repo is busy and you
+   want it scanned more often (or the reverse). It also shows the most
+   recent observations gathered from that repo's polling sources.
 2. **Triggers** — fire when matching Git or GitHub events arrive on
    this repository. Triggers run **alongside** the project-wide
    task-flow defaults, not in place of them. Each trigger has a
    workdir mode (`local-clone` or `temp`); local-clone triggers
    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:
+   distinct kinds of work, each on its own schedule:
    - 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

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

@@ -26,7 +26,7 @@ ask_examples:
   - Where do reading-list items get stored?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - reading
   - books
@@ -37,6 +37,7 @@ related:
   - features/memory-files/user-profile
   - features/lifestyle/receipts
   - features/lifestyle/travel-bookings
+  - pages/reading
 api_endpoints:
   - GET /api/books
   - PATCH /api/books/:id
@@ -52,7 +53,7 @@ ui_anchors:
 
 A reading list backed by the `books` and `reading_highlights` SQLite
 tables: imports your Kindle highlights, tracks each book's status
-(`reading`, `completed`, or `abandoned`), and surfaces the working set
+(`reading`, `completed`, or `abandoned`), and shows your current list
 at `/reading`.
 
 ## What It Does
@@ -65,14 +66,15 @@ at `/reading`.
     "Export Notebook" email.
 - **List** the library on `/reading` or via `GET /api/books`
   (filterable by `status` and `source`, paginated to 200 rows per call).
-- **Mark complete or abandoned** — an existing row is updated via
-  `PATCH /api/books/:id`. This is an **Approve-tier** write that requires
-  an operator `Authorization: Bearer` token, so it is driven from the
-  dashboard, not autonomously by the agent (an unauthenticated agent curl
-  is rejected with **401** before the handler runs). Setting `status` to
+- **Mark complete or abandoned** — `PATCH /api/books/:id` updates a book
+  that already exists. This is an **Approve-tier** write (a change that
+  needs your explicit sign-off), so it requires an operator
+  `Authorization: Bearer` token and runs from the dashboard rather than
+  on the agent's own initiative (an unauthenticated agent curl is
+  rejected with **401** before the handler runs). Setting `status` to
   `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
+- **Recommend** from the list when you ask in a chat, and refresh the
   reading-taste profile during the weekly review.
 
 There is **no bare "add a book" endpoint** — new books arrive through the
@@ -126,5 +128,6 @@ drives the list shape. The reading skill loads in two situations:
 
 ## Related
 
+- [Reading Page](../../pages/reading.md)
 - [Receipts](receipts.md)
 - [Travel Bookings](travel-bookings.md)

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

@@ -16,7 +16,6 @@ summary: |
 section: lifestyle
 tags:
   - lifestyle
-  - receipts
   - mail
   - integrations
 status: stable
@@ -27,7 +26,7 @@ ask_examples:
   - What receipts haven't I saved yet?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - receipt
   - invoice
@@ -58,10 +57,10 @@ your external Obsidian vault on request.
 ## How Detection Works
 
 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:
+mail account and records each attachment it finds. Every detected
+attachment becomes one row in the `receipts` table. Each row is keyed
+uniquely on `(account_id, provider_msg_id, attachment_id)`, so
+re-scanning the same mail never creates a duplicate. Columns:
 
 - `category` — `travel` at detection time; reclassify to `document`
   via PATCH (nullable on legacy rows)
@@ -72,22 +71,22 @@ idempotent. Columns:
   vault (see below)
 - `id`, `created_at` — row identity and detection time
 
-There is no Markdown context file for receipts; the durable record is
-the SQLite row plus the optional Obsidian copy.
+There is no Markdown context file for receipts. The lasting record is
+the SQLite row, plus the optional Obsidian copy you save yourself.
 
 ## Saving a Receipt to Your Vault
 
-Saving is a two-step flow — the download endpoint never writes to the
-vault by itself:
+Saving takes two steps. The download endpoint never writes to the vault
+on its own:
 
-1. The agent downloads the original bytes via
+1. The agent downloads the original bytes with
    `POST /api/receipts/:id/download`, which streams the raw attachment
-   (resolved through the mail registry by `account_id`; oversized files
-   over 100 MB and orphaned rows with a null `account_id` are rejected).
-2. The agent writes the file into your **external** Obsidian vault — not
-   the primary management vault — under the convention
-   `receipts/YYYY/MM/<merchant>-<date>.<ext>` (e.g.
-   `receipts/2026/04/amazon-2026-04-12.pdf`), then records that path
+   (found in the mail registry by `account_id`). Files larger than
+   100 MB, and orphaned rows with a null `account_id`, are rejected.
+2. The agent writes the file into your **external** Obsidian vault —
+   not the primary management vault — using the naming convention
+   `receipts/YYYY/MM/<merchant>-<date>.<ext>` (for example,
+   `receipts/2026/04/amazon-2026-04-12.pdf`). It then records that path
    with `PATCH /api/receipts/:id` (body `{"obsidianPath": "..."}`),
    which also stamps `saved_at`.
 
@@ -96,11 +95,11 @@ To reclassify a receipt, the agent PATCHes `{"category": "travel"}`
 
 ## Where in the Dashboard
 
-There is no dedicated tab today. Receipts surface inline when you ask
-for them in chat (e.g. "what receipts haven't I saved yet?"). List and
-filter them with `GET /api/receipts` (`category`, `saved`, `limit`
-params) and pull totals from `GET /api/receipts/summary`. The full API
-is documented in
+There is no dedicated tab yet. Receipts show up inline when you ask for
+them in chat (for example, "what receipts haven't I saved yet?"). List
+and filter them with `GET /api/receipts` (the `category`, `saved`, and
+`limit` params) and pull totals from `GET /api/receipts/summary`. The
+full API is documented in
 `agent-assets/skills/gmail-lifestyle/references/receipts-api.md`
 (loaded by the `gmail-lifestyle` skill).
 

package/agent-assets/docs/features/lifestyle/travel-bookings.md

@@ -17,7 +17,6 @@ summary: |
 section: lifestyle
 tags:
   - lifestyle
-  - travel
   - mail
   - integrations
 status: stable
@@ -27,7 +26,7 @@ ask_examples:
   - Where are my travel bookings stored?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - flight
   - hotel
@@ -76,10 +75,10 @@ confirmation email never creates a duplicate row.
 
 ## How Bookings Get Created
 
-Bookings are extracted from email only — there is no manual "log a
-flight" command or DM shortcut. To start capturing travel, connect a
-mail account (see [Mail](features/integrations/mail)) and let the
-classifier do the rest. The flow is:
+Bookings come from email only — there is no manual "log a flight"
+command or DM shortcut. To start capturing travel, connect a mail
+account (see [Mail](../integrations/mail.md)) and let the classifier
+do the rest. The flow is:
 
 1. The mail poller fetches new messages.
 2. The classifier (`gmail_classify`, lite tier) tags travel
@@ -99,9 +98,10 @@ classifier do the rest. The flow is:
 
 ## API
 
-Read-only and status-update access (read endpoints are read-sensitive —
-they expose personal travel data; the PATCH endpoint follows the standard
-write-safety tier and requires approval):
+These endpoints give read and status-update access. The two read
+endpoints are read-sensitive, because they expose personal travel data.
+The `PATCH` endpoint follows the standard write-safety tier, so it
+requires approval before it runs.
 
 ```bash
 # All bookings (optionally filter by type/status/date range)