@aitne-sh/aitne 0.1.12 → 0.1.13

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

@@ -17,7 +17,6 @@ section: memory-files
 tags:
   - memory
   - journal
-  - reflection
   - routines
 status: stable
 ask_examples:
@@ -27,7 +26,7 @@ ask_examples:
   - Why did journal/agent.md stop growing?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - journal
   - retros
@@ -77,20 +76,22 @@ Each entry carries:
 - The reflection itself.
 
 The file lives at `~/.personal-agent/context/journal/agent.md`. The
-day-to-day morning and ad-hoc entries accumulate indefinitely; the
-daily retention rollup keeps only a rolling window of the structured
-retros (the most recent 12 `## Weekly` and 24 `## Monthly` sections),
-pruning older ones. Later routines read it back to look for patterns.
+day-to-day morning and ad-hoc entries accumulate indefinitely. A daily
+retention rollup then keeps only a rolling window of the structured
+retros — the most recent 12 `## Weekly` and 24 `## Monthly` sections —
+and prunes older ones. Later routines read the file back to look for
+patterns.
 
 ## Who writes it, and when
 
 Three routines append to the journal — none ever rewrites it:
 
 - **Morning routine** is the recurring daily writer — and here the
-  daemon itself does the writing, not an LLM stage. After the day's
+  daemon (the always-on local background service) does the writing
+  itself, rather than an AI-model (LLM) stage. Once 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
+  `routine.morning_routine_journal`) finish, the daemon appends a
+  one-paragraph audit-trail entry built 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.
@@ -104,7 +105,8 @@ Three routines append to the journal — none ever rewrites it:
   rejected. It does not write the bulk of the diary.
 
 In-the-moment notes can also land here when the agent flags something
-worth recording during reactive work.
+worth recording during reactive work — its live back-and-forth with
+you, outside the scheduled routines.
 
 ### Example entry
 

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

@@ -18,8 +18,6 @@ summary: |
 section: memory-files
 tags:
   - memory
-  - feedback
-  - learning
   - routines
 status: beta
 ask_examples:
@@ -30,7 +28,7 @@ ask_examples:
   - How do I tune the lesson caps?
 locale: en-US
 created: 2026-06-08
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - lessons
   - feedback
@@ -61,20 +59,21 @@ ui_anchors:
 
 The lesson stores are where the agent remembers how you want it to
 behave: a short, dated list of learned directives that grows from your
-corrections and the agent's own retros, and is fed back into the agent's
-work so it stops repeating the same mistakes.
+corrections and from the agent's own reviews of its work, and is fed back
+into the agent's work so it stops repeating the same mistakes.
 
 ## What they are
 
 There are two kinds of store:
 
 - **Global agent behavior** — `policies/agent-lessons.md`. Lessons that
-  apply to the agent as a whole. These are injected into your DM
-  conversations and into the routines that decide whether to notify you.
+  apply to the agent as a whole. They are fed into your DM (direct
+  message) chats with the agent and into the routines that decide whether
+  to notify you.
 - **Per-agent** — `policies/agents/<slug>/lessons.md`, one per Agent
-  Definition. These are injected **only** into that agent's own
-  executions, so a lesson learned for your "weekly-report" agent never
-  leaks into an unrelated one.
+  Definition. These are fed in **only** when that agent itself runs, so a
+  lesson learned for your "weekly-report" agent never leaks into an
+  unrelated one.
 
 Both live under `~/.personal-agent/context/policies/`, alongside your
 other rule files, and are plain Markdown you can read or hand-edit.
@@ -111,7 +110,7 @@ it for you. There are three ways signals enter:
 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
+consumed (it skips the step entirely when nothing is waiting). Once a month
 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
@@ -122,8 +121,8 @@ principle, keeping each store small.
 A new lesson is stored but is not necessarily *injected* right away. A
 lesson carries a `<!-- provisional -->` marker until it has enough
 corroborating evidence; provisional lessons sit in the file but are not
-fed into the agent's prompts. This avoids over-fitting to a single
-offhand comment.
+fed into the agent's prompts. This keeps the agent from over-reacting to a
+single offhand comment.
 
 How a lesson crosses from provisional to active:
 
@@ -135,6 +134,26 @@ How a lesson crosses from provisional to active:
   promotes on the first occurrence — it is taken at your word.
 - An **ignore on its own never promotes** a lesson, and is never read as
   disapproval.
+- A candidate that **contradicts an established lesson** (one whose
+  confidence is at or above `feedbackContradictionGuardCf`, default 0.6)
+  is held provisional until it accumulates 1.5x the usual evidence — a
+  single stray signal can't flip a well-supported lesson. Your explicit
+  corrections bypass this guard entirely.
+
+## Confidence (`cf`)
+
+Every lesson carries a numeric confidence `cf` between 0 and 1, stamped
+deterministically by the daemon (never trusted from the model's rewrite).
+It rises with corroboration and decays with time since the lesson was
+last reinforced. Inferred lessons whose decayed confidence falls below
+`feedbackLessonConfidenceFloor` (default 0.25) quietly stop being
+injected — but the two highest-authority classes are protected: a
+durable `constraint` is never filtered, and an explicit owner correction
+is tested on its undecayed confidence (obeying a directive produces no
+new signals, so decay alone can't silently un-bind it). A daily
+mechanical pass (the **Lesson Maintenance** agent at
+`/agents/lesson-maintenance`, 17:40) keeps the stamps fresh even on days
+with no new feedback.
 
 ## Bounded by design
 
@@ -142,19 +161,25 @@ The stores can't grow without limit. Each is capped in bytes and entry
 count — the global store at `feedbackLessonMaxBytesGlobal` bytes
 (default 8192) / 40 entries, the per-agent stores at
 `feedbackLessonMaxBytesPerAgent` (default 4096) / 20 entries. When a
-store is full, the lowest-signal lessons are dropped first. Lessons that
-go untouched for `feedbackLessonStaleDays` (default 60) are pruned — with
-one exception: a `kind=constraint` lesson is durable and is never
-stale-pruned or collapsed away. The underlying feedback signals
-themselves are retained for `feedbackSignalRetentionDays` (default 180).
+store is full, the lowest-signal lessons are dropped first. Expiration is
+graduated and reversible: a lesson untouched past
+`feedbackLessonStaleDays` (default 60) whose decayed confidence is below
+the floor **demotes** back to provisional; a provisional lesson that goes
+uncorroborated for twice that horizon is **archived** (removed from the
+file — its raw signals remain in the database); fresh corroboration
+**re-promotes** a demoted lesson. One exception: a `kind=constraint`
+lesson is durable and never expires or collapses away. The underlying
+feedback signals themselves are retained for
+`feedbackSignalRetentionDays` (default 180).
 
 ## Where in the dashboard
 
 **Settings → Lessons** (`/settings/lessons`, labelled "Lessons" with a
-**Preview** badge) is the read/tune surface. From there you can view and
-edit the lessons themselves and adjust every knob above:
+**Preview** badge) is where you read and tune all of this. From there you
+can view and edit the lessons themselves and adjust every knob above:
 `feedbackLearningEnabled` (the master kill-switch, on by default),
-`feedbackPromotionThreshold`, the byte caps, the stale-days horizon, and
+`feedbackPromotionThreshold`, the byte caps, the stale-days horizon, the
+confidence floor, the contradiction guard, the outcome-rollup toggle, and
 the signal retention window. Turning `feedbackLearningEnabled` off stops
 both capture and consolidation.
 

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

@@ -16,8 +16,6 @@ summary: |
 section: memory-files
 tags:
   - memory
-  - projects
-  - core
 status: stable
 ask_examples:
   - Where do I find the per-project files?
@@ -25,7 +23,7 @@ ask_examples:
   - How does the agent write to a project file?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - projects
   - project file
@@ -67,11 +65,11 @@ only the minimum — `type: project`, `owner: shared`, an `updated`
 date, and an H1 title. By convention the agent also writes `slug`,
 `state`, `start`, `due`, `stakeholders`, `next_milestone`, and `tags`.
 
-`state` is what marks a project **active**: the Obsidian `_active.base`
-Bases view filters on it (`state != "archived"`), and the morning
-routine surfaces every project whose `state` is not `archived` — a
-file with no `state` (or any state other than `archived`) is treated
-as active and surfaced.
+The `state` field is what marks a project **active**. The Obsidian
+`_active.base` view filters on it (keeping rows where
+`state != "archived"`), and the morning routine surfaces every project
+whose `state` is not `archived`. A file with no `state` at all — or any
+state other than `archived` — counts as active and shows up.
 
 ```markdown
 ---
@@ -95,13 +93,14 @@ Ship the public beta before the conference.
 
 ## When It Runs / How It Is Triggered
 
-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).
+Read on demand. Written when you ask the agent to remember something
+project-specific, or when a direct message (DM) signals project intent
+— create, update status, or mark done.
 
-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:
+The agent cannot edit context files directly on disk: a pre-write hook
+blocks the `Edit` and `Write` tools anywhere inside the context vault
+(the folder that holds these Markdown memory files). Instead, every
+project write goes 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/roadmap.md

@@ -9,13 +9,13 @@ aliases:
   - preparation timeline
 category: features
 summary: |
-  roadmap.md captures long-running goals plus Preparation Timeline
-  rows that fire on specific days. The morning routine walks the
-  roadmap each day to surface items whose offsets fire.
+  roadmap.md holds long-running goals plus Preparation Timeline
+  rows dated for specific days. Each day the morning routine reads the
+  roadmap and surfaces any row whose date has arrived.
 section: memory-files
 tags:
   - memory
-  - core
+  - scheduler
 status: stable
 ask_examples:
   - What is the roadmap file?
@@ -24,7 +24,7 @@ ask_examples:
   - How do I add a roadmap entry?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - roadmap.md
   - roadmap
@@ -49,7 +49,7 @@ context_files:
 ## In One Sentence
 
 A multi-week plan: each goal carries dates and Preparation Timeline
-rows that the morning routine fires on the day they come due.
+rows, and the morning routine surfaces each row on the day it comes due.
 
 ## What It Does
 
@@ -87,16 +87,17 @@ hotel", and so on.
 
 ## When It Runs / How It Is Triggered
 
-Read by the morning routine each day, which walks the roadmap and
-surfaces any Preparation Timeline rows dated for that day (or overdue).
-The file is updated by the operator, or by the agent on request (for
-example via the roadmap skill or `aitne run-now roadmap_maintenance`).
+The morning routine reads the roadmap each day and surfaces any
+Preparation Timeline rows dated for that day — plus any earlier row it
+has not handled yet (overdue). You can update the file yourself, or ask
+the agent to (for example via the roadmap skill or
+`aitne run-now roadmap_maintenance`).
 
-The agent never edits the file directly. All writes go through the
+The agent never edits the file directly. Every write goes through the
 daemon's context endpoint — `PUT /api/context/plans/roadmap` (full
-replace) or `PATCH /api/context/plans/roadmap` (section op) — which is
-guarded by an exclusive roadmap write lock so two flows can't clobber
-each other.
+replace) or `PATCH /api/context/plans/roadmap` (section op). A write
+lock holds the roadmap exclusively during each write, so two flows can
+never overwrite each other.
 
 ## Where in the Dashboard
 
@@ -104,6 +105,6 @@ each other.
 
 ## Related
 
-- [Morning Routine](../../routines/morning-routine.md) — reads the roadmap each day.
+- [Morning Routine](../routines/morning-routine.md) — reads the roadmap each day.
 - [Projects](projects.md) — deeper, per-project context the roadmap links to.
 - [today.md](today.md) — the single-day plan the roadmap feeds into.

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

@@ -21,7 +21,6 @@ tags:
   - memory
   - journal
   - routines
-  - core
 status: stable
 ask_examples:
   - Where does the agent store the day's diary?
@@ -29,7 +28,7 @@ ask_examples:
   - How do I change which sections the daily journal includes?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-10
+updated: 2026-07-01
 keywords:
   - daily journal
   - diary
@@ -42,7 +41,7 @@ related:
   - features/memory-files/agent-journal
   - concepts/agent-day
 ui_anchors:
-  - /schedule
+  - /tasks
   - /agents/morning-routine?tab=rulebook
 process_keys:
   - routine.morning_routine_journal
@@ -55,8 +54,9 @@ context_files:
 ## In One Sentence
 
 `journal/daily/YYYY-MM-DD.md` is the morning routine's first-person
-diary of the **previous** agent-day — what the user did, who they met,
-what they talked about — composed by the daemon and kept as a
+diary of the **previous** agent-day (the agent's version of a day,
+which rolls over at 04:00 by default) — what the user did, who they
+met, what they talked about — composed by the daemon and kept as a
 read-only archive that the weekly and monthly reviews read back.
 
 > **Renamed from `schedule/`.** The old mechanical `schedule/YYYY-MM-DD.md`
@@ -93,11 +93,11 @@ typically includes:
 - `## Tasks` — what the user worked on.
 - `## Conversations` — who they talked to and about what.
 
-When the `browser_history` integration is active, a reading/research
-surface is woven in from the day's browser digest. Daemon-owned
-frontmatter (`date`, `weekday`, `calendar_events`, `messages_handled`,
-`projects`, `people`, `tags`, `content_hash`, `updated`) is filled in
-automatically. The exact sections and tone are governed by the
+When the `browser_history` integration is turned on, a reading and
+research section is added from the day's browser digest. The daemon
+fills in the frontmatter fields automatically (`date`, `weekday`,
+`calendar_events`, `messages_handled`, `projects`, `people`, `tags`,
+`content_hash`, `updated`). The exact sections and tone are set by the
 journal-format and journal-export policy files (see
 [Configuration](#configuration)).
 

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

@@ -13,9 +13,7 @@ summary: |
   and the operator all read and append to it during the day.
 section: memory-files
 tags:
-  - core
   - memory
-  - today
 status: stable
 ask_examples:
   - What is in today.md?
@@ -23,7 +21,7 @@ ask_examples:
   - Why does today.md keep getting rewritten?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - today
   - day plan
@@ -48,9 +46,10 @@ context_files:
 
 ## In One Sentence
 
-The single live file for the current agent day — plan, log, tasks, and
-hand-off. The morning routine rebuilds it; everything else during the
-day appends to it.
+The single live file for the current agent day (the window the agent
+treats as "today") — its plan, log, tasks, and hand-off. The morning
+routine rebuilds it fresh each day; everything else during the day only
+appends to it.
 
 ## What It Does
 
@@ -58,12 +57,12 @@ 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; 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 Plan** — what the agent means to work on today. The morning
+  routine turns each row into a schedule entry; a later session that day
+  can add rows for new signals or drop a row whose reason no longer
+  holds.
+- **Agent Notes** — upcoming items and date-specific memos pulled in from
+  inbox triage (the sorting of new incoming items).
 - **Agent Log** — what actually happened, appended throughout the day.
 - **Handoff** — what carries over to tomorrow.
 
@@ -73,17 +72,18 @@ today.md holds six sections, written in this order:
   rotates the previous day's file to `state/yesterday.md`).
 - 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 **evening review** closes out the file — it updates Agent Log and
   the Handoff section. (The daily journal itself is written the next
   morning, from the rotated file.)
 
 ## How It Is Written
 
-The agent never edits today.md with a file tool. All writes go through
-the daemon's context API — `PUT`/`PATCH /api/context/state/today` (the
-canonical, class-prefixed path). A `today-write-lock` serializes writes
-during the morning routine: while the lock is held, a write to
-`state/today` must carry the `X-Lock-Id` header or it is rejected.
+The agent never edits today.md with a file tool. Every write goes
+through the daemon's context API — `PUT`/`PATCH /api/context/state/today`
+(the canonical, class-prefixed path). A `today-write-lock` forces writes
+to happen one at a time during the morning routine: while the lock is
+held, any write to `state/today` must carry the `X-Lock-Id` header, or
+it is rejected.
 
 ## Where in the Dashboard
 

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

@@ -18,8 +18,6 @@ summary: |
 section: memory-files
 tags:
   - memory
-  - profile
-  - core
 status: stable
 ask_examples:
   - What is identity/profile.md?
@@ -27,7 +25,7 @@ ask_examples:
   - Will the agent change my profile without asking?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - user profile
   - identity/profile.md
@@ -55,19 +53,21 @@ context_files:
 
 ## In One Sentence
 
-A stable profile of you — the agent reads it every session and
-silently appends durable facts you state in DMs.
+A steady profile of you. The agent reads it at the start of every
+session and quietly adds durable facts — things that stay true, like
+your role or your manager's name — that you mention in DMs.
 
 ## What It Does
 
 - Captures who you are, what you do, and who matters in your life.
-- Is pinned at the top of every session prompt, so the agent keeps
-  the same baseline understanding of you turn-to-turn.
-- Anchors a set of companion slices in the `identity/` directory that
-  split the dossier into topic-shaped files:
+- Sits at the top of every session prompt, so the agent keeps the same
+  baseline understanding of you from one message to the next.
+- Anchors a set of companion files — called slices — in the `identity/`
+  directory, one per topic:
   `identity/people.md`, `identity/work.md`, `identity/expertise.md`,
-  `identity/personal.md`, `identity/goals.md`. The agent loads these on
-  demand instead of inlining everything into every prompt.
+  `identity/personal.md`, `identity/goals.md`. The agent loads these
+  only when it needs them, instead of packing everything into every
+  prompt.
 
 > Older docs and exports may call these files `user/profile.md`,
 > `user/people.md`, and so on. `user/` is a legacy alias for
@@ -77,11 +77,11 @@ silently appends durable facts you state in DMs.
 ## When It Runs / How It Is Triggered
 
 - **Read continuously** — loaded at the start of every session.
-- **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
+- **Written** silently, within the same reply, 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 that the
+  in-chat capture missed and files them into the right
   `identity/*.md` slice.
 
 The agent never edits these files directly. It writes through the
@@ -106,7 +106,7 @@ 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 silently appends a line to the relevant slice (here
-`identity/people.md`) in the same turn, and recalls it in future
+`identity/people.md`) right away, and recalls it in future
 sessions.
 
 ## When Something Goes Wrong

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

@@ -23,10 +23,8 @@ summary: |
   and list every command.
 section: messaging
 tags:
-  - core
   - messaging
   - operations
-  - bang-commands
 status: stable
 ask_examples:
   - How do I pause the agent from my phone?
@@ -37,7 +35,7 @@ ask_examples:
   - How do I accept a research-cluster offer?
 locale: en-US
 created: 2026-05-12
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - bang command
   - "!stop"
@@ -70,10 +68,12 @@ process_keys:
 
 # Bang Commands
 
-DM the agent a short word starting with `!` and the daemon answers
-directly — no LLM call, no cost, no session opened. Use them to pause,
-check spend, look at recent failures, manage research clusters, and
-list every command.
+DM the agent a short word that starts with `!` — the `!` symbol is
+nicknamed a "bang," which is where these commands get their name — and
+the daemon (the always-on local background service) answers it directly.
+No AI model runs, so there is no cost and no chat session is opened. Use
+bang commands to pause the agent, check spend, look at recent failures,
+manage research clusters, and list every command.
 
 ## Who Can Use Them
 
@@ -89,9 +89,9 @@ 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 (activity scan, morning / evening / weekly routines, scheduled tasks). In-flight runs are **not** aborted. |
+| `!stop` | Pause cron-driven (scheduled) autonomous work: activity scan, the morning / evening / weekly routines, and scheduled tasks. Runs already in progress 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. |
+| `!close` | Close the active DM session for the current routing tuple (this platform + channel + thread) so the next DM starts a fresh conversation. |
 
 ### Tasks (detached background / browser work)
 
@@ -206,12 +206,12 @@ were hidden.
 
 ## How They Behave
 
-- **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.
+- **Exact match for atomic commands** — single words like `!stop`,
+  `!cost`, and `!checks`, where each `!cost <backend>` variant is its
+  own exact-match entry — and **prefix match for parameterised ones**
+  that take an argument (`!research accept <slug>`, `!compile @work
+  full`). Anything that spans more than one line 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.
 - **No agent cost on built-ins.** No LLM is invoked for the
   daemon-side commands; one `bang_command` row is appended to

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

@@ -16,7 +16,6 @@ summary: |
   messaging app.
 section: messaging
 tags:
-  - core
   - messaging
   - dashboard
 status: stable
@@ -26,7 +25,7 @@ ask_examples:
   - Why are my dashboard chat replies different from my Telegram replies?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-07-01
 keywords:
   - chat
   - dashboard
@@ -55,13 +54,14 @@ ui_anchors:
 
 ## In One Sentence
 
-`/chat` is a browser-mounted DM with the agent — a fully featured
-conversational surface separate from any paired messaging app.
+`/chat` is a DM with the agent that lives in your browser — a fully
+featured chat, separate from any paired messaging app.
 
 ## What It Does
 
-- **Real-time** message stream over SSE — the same conversational
-  experience as a paired DM, but in the browser.
+- **Real-time** message stream over SSE (Server-Sent Events, a live
+  one-way feed from the daemon to your browser) — the same
+  conversational experience as a paired DM, but in the browser.
 - **Tool progress** rendered inline (which tool, which file, which
   endpoint) so you can watch the agent work.
 - **Session history** persisted to SQLite (`scope='dashboard_chat'`)
@@ -113,3 +113,4 @@ demand when you send, never on a schedule. Its default tier is
 - [Messaging Overview](overview.md)
 - [Backends and Tiers](../../concepts/backends-and-tiers.md)
 - [Process Keys](../../concepts/process-keys.md)
+- [Keyboard Shortcuts](../../reference/keyboard-shortcuts.md)

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

@@ -26,7 +26,7 @@ ui_anchors:
   - /connections/messaging
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-07-01
 keywords:
   - discord
   - bot token
@@ -44,8 +44,9 @@ related:
 
 ## In One Sentence
 
-A Discord bot becomes the agent's surface; pair via DM after
-installing the bot in the developer portal.
+Aitne talks to you through a Discord bot you create. Set the bot up in
+Discord's developer portal, then link it to yourself by sending it a
+direct message.
 
 ## How to Set Up
 
@@ -57,8 +58,9 @@ installing the bot in the developer portal.
    DM or mention text without it.
 4. Invite the bot to any servers where you want mentions to work.
 5. Paste the token under **Connections → Messaging → Discord**.
-6. DM the magic phrase from your own Discord account to complete
-   pairing.
+6. From your own Discord account, DM the bot the magic phrase (the
+   short one-time pairing code Aitne shows you) to finish pairing. See
+   [Pairing & Magic Phrase](pairing-and-magic-phrase.md).
 
 ## What It Does