@aitne-sh/aitne 0.1.12 → 0.1.13

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

@@ -16,7 +16,6 @@ summary: |
   agent uses the same channel to send notifications back.
 section: messaging
 tags:
-  - core
   - messaging
   - integrations
   - pairing
@@ -29,7 +28,7 @@ ask_examples:
   - Can I send the agent a voice note?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - messaging
   - dm
@@ -66,17 +65,17 @@ config_keys:
 
 # Messaging Overview
 
-Aitne treats DMs from a paired messaging app as its primary reactive
-surface — you message it, it answers; it messages you when a
-notification fires. Voice notes are transcribed locally with Whisper
+Direct messages (DMs) from a paired messaging app are Aitne's main way
+to talk with you: you message it, it answers; it messages you back when
+a notification fires. Voice notes are transcribed locally with Whisper,
 so you can talk to the agent the same way you'd type.
 
 ## What It Does
 
 - **Reactive DMs**: the agent answers every direct message you send.
 - **@-mentions (Slack and Discord)**: @-mentioning the agent inside a
-  shared channel routes to the `message.mention` ProcessKey and is
-  answered the same way as a DM. Telegram and WhatsApp drop all non-DM
+  shared channel routes to the `message.mention` process key and is
+  answered the same way as a DM. Telegram and WhatsApp ignore all non-DM
   traffic (no group support).
 - **Outbound notifications**: routines and observations fire alerts
   back through the same channel.
@@ -94,16 +93,17 @@ so you can talk to the agent the same way you'd type.
 
 Aitne serves exactly one owner. Any message that does not come from a
 paired owner channel is dropped — group chats, multi-user Slack DMs
-(`mpim`), and unrecognized senders never reach the agent. This is
-defense in depth: both the messaging adapter and the dispatcher check
-the owner channel independently.
+(`mpim`), and unrecognized senders never reach the agent. Two layers
+enforce this independently (defense in depth): the messaging adapter
+and the dispatcher each check the owner channel on their own.
 
 ## When It Runs / How It Is Triggered
 
-- 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.
+- The messaging adapter for each connected platform watches for
+  incoming messages — Telegram by long-polling (repeatedly asking the
+  server for updates), Slack, Discord, and WhatsApp by holding an
+  always-open WebSocket connection.
+- An incoming DM dispatches to the `message.dm` process key.
 - An incoming mention dispatches to `message.mention`.
 - Notifications fire as a side-effect of routines and observations
   reaching the notifier (subject to quiet hours and rate limits).

package/agent-assets/docs/features/messaging/pairing-and-magic-phrase.md

@@ -17,7 +17,6 @@ summary: |
   to your owner identity so nobody else can impersonate you.
 section: messaging
 tags:
-  - core
   - messaging
   - pairing
   - safety
@@ -25,7 +24,7 @@ tags:
 status: stable
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-07-01
 keywords:
   - pairing
   - magic phrase
@@ -86,23 +85,24 @@ on the platform.
 
 ### The magic phrase (Slack, Discord)
 
-The dashboard generates a short, memorable phrase of four lowercase words
-joined by hyphens, drawn from a 64-word list (24 bits of entropy). You DM
-that exact phrase to the bot. Matching is tolerant — it ignores case,
-punctuation, and emoji — but the phrase must be **sent by itself**. If you
-wrap it in a sentence ("my phrase is apple-banana-cherry-date"), the agent
-will reply asking you to send the phrase on its own.
+The dashboard generates a short, memorable phrase: four lowercase words
+joined by hyphens, drawn from a 64-word list. That makes it easy to type
+but hard to guess (24 bits of entropy). You DM that exact phrase to the
+bot. Matching is forgiving — it ignores case, punctuation, and emoji — but
+you have to send the phrase **by itself**. If you wrap it in a sentence
+("my phrase is apple-banana-cherry-date"), the agent replies asking you to
+send just the phrase on its own.
 
-The phrase is single-use and expires after **5 minutes**. If it lapses,
-regenerate a fresh one from the dashboard.
+The phrase works once and expires after **5 minutes**. If it runs out,
+generate a fresh one from the dashboard.
 
 ### Token pairing (Telegram, WhatsApp)
 
 Telegram and WhatsApp don't use a typed phrase:
 
-- **Telegram** encodes a high-entropy, single-use token in a QR / deep
+- **Telegram** hides a hard-to-guess, one-time token inside the QR / deep
   link. Tapping **START** sends `/start <token>` to the bot, which
-  promotes you to owner. The token is matched exactly and also expires
+  promotes you to owner. The token has to match exactly and also expires
   after 5 minutes.
 - **WhatsApp** uses WhatsApp's own linked-device flow — you scan a QR from
   your phone to attach the daemon as a device. Set the owner phone number

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

@@ -17,7 +17,6 @@ section: messaging
 tags:
   - messaging
   - integrations
-  - slack
   - pairing
 status: stable
 ask_examples:
@@ -26,7 +25,7 @@ ask_examples:
   - Can the agent listen in shared channels?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-07-01
 keywords:
   - slack
   - socket mode
@@ -49,18 +48,20 @@ config_keys:
 
 ## In One Sentence
 
-A Slack bot user becomes the agent's surface in your workspace: DMs to
-the bot are owner messages, and `@`-mentions of the bot in channels are
-mention events — but only from the one paired owner.
+You add a Slack bot user to your workspace, and that bot is how you talk
+to the agent: DMs you send the bot are treated as owner messages, and
+`@`-mentions of the bot in channels are treated as mentions — but only
+when they come from the one paired owner.
 
 ## What It Does
 
-- Listens for **DMs** to the bot (owner reactive path).
+- Listens for **DMs** to the bot — your direct messages to the agent.
 - Listens for **`@`-mentions of the bot** in channels you've added it to.
 - Sends notifications back to your owner DM.
 
-The adapter runs over Slack **Socket Mode** (a WebSocket), so Aitne does
-not need a public inbound URL or webhook endpoint.
+The adapter connects to Slack over **Socket Mode**, a WebSocket (a
+persistent two-way link Slack opens to Aitne). Because Slack does the
+reaching-out, Aitne needs no public inbound URL or webhook endpoint.
 
 ## Single-Owner Scope
 

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

@@ -13,7 +13,6 @@ section: messaging
 tags:
   - messaging
   - integrations
-  - telegram
 status: stable
 config_keys:
   - telegramOwnerChatId
@@ -24,7 +23,7 @@ ask_examples:
   - Where do I get a Telegram bot token?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - telegram
   - telegram bot
@@ -45,14 +44,15 @@ token, scan the pairing QR code.
 
 ## What It Does
 
-- Acts as the agent's reactive surface for your incoming direct messages (owner DMs only — group chats are ignored).
-- Delivers the agent's outbound notifications and replies back to the same Telegram chat.
+- Receives your incoming direct messages so the agent can react to them (owner DMs only — group chats are ignored).
+- Sends the agent's notifications and replies back to the same Telegram chat.
 
 ## When It Runs / How It Is Triggered
 
-Before pairing, nothing listens. Once you paste the bot token and complete
-QR / deep-link pairing, Aitne long-polls Telegram's Bot API continuously for new
-direct messages.
+Before pairing, nothing listens. Once you paste the bot token and finish pairing
+(scan the QR code or tap the deep link), Aitne continuously long-polls Telegram's
+Bot API — it keeps an open request that returns the moment a new direct message
+arrives.
 
 ## Where in the Dashboard
 

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

@@ -17,7 +17,6 @@ summary: |
 section: messaging
 tags:
   - messaging
-  - whatsapp
   - integrations
   - pairing
 status: stable
@@ -27,7 +26,7 @@ ask_examples:
   - Why does WhatsApp say the device is unlinked?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-07-01
 keywords:
   - whatsapp
   - qr code
@@ -57,10 +56,11 @@ messages that flow exactly like Telegram.
 
 ## How It Works
 
-Aitne connects to WhatsApp as a **linked device** (the multi-device feature
-in the WhatsApp mobile app), not through the WhatsApp Cloud API or a paid
-bridge such as Twilio. There is no business account, no bot token, and no
-inbound webhook to expose:
+Aitne connects to WhatsApp as a **linked device** — the same "linked
+devices" feature in the WhatsApp mobile app that powers WhatsApp Web. It does
+not use the WhatsApp Cloud API or a paid bridge such as Twilio. There is no
+business account, no bot token, and no inbound webhook (a public URL that
+WhatsApp would call) to expose:
 
 - You scan a QR code once to link the daemon as a device on your account.
 - Incoming WhatsApp messages arrive over the linked-device connection.

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

@@ -15,7 +15,6 @@ summary: |
   answer "what happened" and "what was said".
 section: operations
 tags:
-  - core
   - operations
   - audit
   - dashboard
@@ -26,7 +25,7 @@ ask_examples:
   - How do I find why a routine failed?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - activity
   - conversations
@@ -53,9 +52,9 @@ ui_anchors:
 
 ## In One Sentence
 
-Every agent session, action, and outcome is logged to SQLite and
-surfaced as the Activity timeline; the matching message-by-message
-detail lives one click deeper under Conversations.
+The agent logs every session, action, and outcome to a local SQLite
+database and shows them as the Activity timeline; the matching
+message-by-message detail lives one click deeper under Conversations.
 
 ## What It Does
 
@@ -71,10 +70,11 @@ Each row links to the underlying conversation when one exists.
 
 ## How It Works
 
-Activity has no trigger of its own — it is a read-only projection.
-Every other event in the system writes to it as a side effect, landing
-in three SQLite tables: `agent_actions` (what happened), and
-`conversation_sessions` + `messages` (what was said).
+Activity never runs anything on its own — it only mirrors what already
+happened (a read-only view). Every other event in the system writes to
+it as a side effect, landing in three SQLite tables: `agent_actions`
+(what happened), plus `conversation_sessions` and `messages` (what was
+said).
 
 ## What You See
 

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

@@ -9,12 +9,11 @@ aliases:
   - human in the loop
 category: features
 summary: |
-  A few high-blast-radius actions queue as approvals. The action
-  blocks until you click Approve on the dashboard Overview page;
-  the approval card stays visible there regardless of quiet hours.
+  A few high-impact actions queue as approvals. The action blocks
+  until you click Approve on the dashboard Overview page; the
+  approval card stays visible there regardless of quiet hours.
 section: operations
 tags:
-  - core
   - safety
   - operations
 status: stable
@@ -24,7 +23,7 @@ ask_examples:
   - Where do I approve a pending action?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - approval
   - approve tier
@@ -47,9 +46,10 @@ api_endpoints:
 
 ## In One Sentence
 
-A small set of high-blast-radius actions queue as approvals; the
-agent waits for you to click **Approve** on the dashboard before it
-proceeds.
+A small set of high-impact actions — the ones that could cause
+real harm if they ran by mistake — queue as approvals. The agent
+waits for you to click **Approve** on the dashboard before it runs
+one.
 
 ## How It Works
 
@@ -84,10 +84,11 @@ Deny asks for confirmation before discarding the item.
 ## When Something Goes Wrong
 
 - **A stale approval you never answered:** a pending approval is
-  discarded once the agent day rolls over (the next 04:00 local
-  boundary) — it's marked skipped rather than replayed after the
-  day turns. If that happens, redo the request that triggered it
-  (for example, re-send the DM or re-run the routine).
+  discarded once the agent day rolls over — the moment "today"
+  resets, at 04:00 local time by default. It is marked skipped
+  rather than replayed after the day turns. If that happens, redo
+  the request that triggered it (for example, re-send the DM or
+  re-run the routine).
 
 ## Related
 

package/agent-assets/docs/features/operations/backend-routing.md

@@ -14,7 +14,6 @@ summary: |
   main backend's session fails over to the fallback's mid-run.
 section: operations
 tags:
-  - core
   - operations
   - backends
   - routing
@@ -25,7 +24,7 @@ ask_examples:
   - How do fallbacks work?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-07-01
 keywords:
   - backend routing
   - BackendRouter
@@ -55,64 +54,66 @@ related:
 
 ## In One Sentence
 
-Every job carries a ProcessKey. The router resolves that key to a
-`(main, fallback)` backend pair plus a tier — and if the main backend
-hits a quota wall or a decisive failure, the dispatcher transitions to
-the fallback mid-run, then DMs you that it happened.
+Every job carries a ProcessKey (a label saying what kind of work it is).
+The router turns that key into a `(main, fallback)` backend pair plus a
+tier — and if the main backend runs out of quota or hits a decisive
+failure, the dispatcher switches to the fallback partway through the run,
+then DMs you that it happened.
 
 ## How It Resolves a Backend
 
-The router never picks a model itself. The dispatcher hands it a
-ProcessKey, and `BackendRouter` resolves the binding in this order:
+The router never picks a model on its own. The dispatcher hands it a
+ProcessKey, and `BackendRouter` works out the binding in this order:
 
-1. Read the `process_backend_config` table for a per-key override
+1. Check the `process_backend_config` table for a per-key override
    (`main_backend` / `main_model` / `fallback_backend` / `fallback_model`).
-2. If no override exists, fall back to the ProcessKey's **default tier**
-   (`lite` → Haiku-class, `medium` → Sonnet-class, `high` → Opus-class)
-   and the seeded backend for that tier.
-3. `dashboard.docs_qa` is **tier-locked to `medium`** — an operator pin
-   can't move it.
+2. If there is no override, use the ProcessKey's **default tier** (a
+   size band: `lite` → Haiku-class, `medium` → Sonnet-class, `high` →
+   Opus-class) and the backend seeded for that tier.
+3. `dashboard.docs_qa` is **tier-locked to `medium`** — pinning it in the
+   dashboard can't move it.
 
 Only one ProcessKey — `delegated_task_heavy` — defaults to the `high`
-tier, and it is opt-in (gated by the `delegatedTaskHeavyEnabled` flag).
-No install-time surface defaults to Opus.
+tier, and it is opt-in (turned on by the `delegatedTaskHeavyEnabled`
+flag). Nothing you get at install time defaults to Opus.
 
 ## What Happens on Failover
 
-The two failover signals are `BackendQuotaError` (the backend hit a
-usage/budget limit) and `BackendDecisiveFailure` (auth failure, model
-unavailable, policy-denied, timeout, or turn-limit). When the main
-backend raises either:
-
-- The router **re-materializes the session workdir** for the fallback
-  backend — writing its instruction file (`AGENTS.md` for Codex,
-  `GEMINI.md` for Gemini, etc.) and skill set into the shared dir. Without
-  this step a Claude → Codex fallover would leave only `CLAUDE.md` and
-  `.claude/skills/`, and the fallback would run blind.
-- The fallback then executes with the same prompt and any
-  per-session tool overrides applied to the main run.
-- On success, you get a **low-priority DM** noting the main backend
-  failed and the fallback served the turn.
+Two signals trigger a failover: `BackendQuotaError` (the backend hit a
+usage or budget limit) and `BackendDecisiveFailure` (an auth failure,
+an unavailable model, a policy-denied request, a timeout, or a
+turn-limit). When the main backend raises either one:
+
+- The router **rebuilds the working directory** for the fallback
+  backend — writing that backend's instruction file (`AGENTS.md` for
+  Codex, `GEMINI.md` for Gemini, and so on) and its skill set into the
+  shared folder. Skip this step and a Claude → Codex failover would find
+  only `CLAUDE.md` and `.claude/skills/`, so the fallback would run
+  blind.
+- The fallback then runs with the same prompt and any per-session tool
+  overrides that applied to the main run.
+- If it succeeds, you get a **low-priority DM** noting that the main
+  backend failed and the fallback served the turn.
 - If the fallback *also* fails, you get a higher-priority notification:
   `Backend execution failed: <key> encountered <kind> on <main>, then
-  <kind> on <fallback>.` This is usually a credentials problem on both
+  <kind> on <fallback>.` This usually means a credentials problem on both
   sides.
 
 ## Where in the Dashboard
 
-- **[Settings → Models](/settings/models)** is the unified surface for
-  picking the main and fallback backend (and tier) per ProcessKey.
+- **[Settings → Models](/settings/models)** is the one place to pick the
+  main and fallback backend (and tier) for each ProcessKey.
 - **[Activity](/activity)** rows show which backend actually served each
-  turn after fallback resolution, so you can see when a fallover fired.
+  turn once fallback was resolved, so you can spot when a failover fired.
 
 ## When Something Goes Wrong
 
 - **A `Backend execution failed` notification** means both the main and
   the fallback rejected the run. Check authentication for both backends
-  first — re-authorize from the dashboard if needed.
-- **A routine ran on the "wrong" backend** is usually a fallover: the
+  first, and re-authorize from the dashboard if needed.
+- **A routine ran on the "wrong" backend** is usually a failover: the
   main backend was over quota, so the fallback served it. The Activity
-  row will confirm which backend ran.
+  row confirms which backend ran.
 
 ## Related
 

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

@@ -20,7 +20,6 @@ summary: |
 section: operations
 tags:
   - operations
-  - browser-automation
   - safety
 status: beta
 ask_examples:
@@ -32,7 +31,7 @@ ask_examples:
   - Where do I see the screenshots from a browser task?
 locale: en-US
 created: 2026-06-16
-updated: 2026-06-16
+updated: 2026-07-01
 keywords:
   - browser tasks
   - browser-task
@@ -73,46 +72,49 @@ api_endpoints:
 A **browser task** is an open-ended action you ask the agent to carry
 out on the web — "send a contact form on Amazon's contact-us page",
 "check the price of X", "fill in this signup". Each task runs in a
-sandboxed sub-agent with **one browser tab to itself**, under allowlist
-enforcement, a payment-path block, and a screenshot trace. The
-**Browser Tasks** page (`/browser-tasks`) is the operational surface
-where every run shows up — what is queued, running, waiting on you, or
-finished.
-
-This is different from two neighbouring surfaces:
-
-- **[Browser History](browser-history)** reads your *existing* Chrome
-  passively (research clusters, revisit nudges). It never drives a
-  browser.
-- **[Managed Chromium / B-4](managed-chromium)** is the heavily-gated,
-  default-off *purchase-confirmation* flow. Browser tasks are the
-  general-purpose, non-purchasing actions; a final purchase confirm is
-  the one thing they hand off to the B-4 token primitive.
+*sandboxed sub-agent* (an isolated, throwaway helper the agent spins
+up) that gets **one browser tab to itself**, guarded by an allowlist, a
+payment-path block, and a screenshot trace of every step. The **Browser
+Tasks** page (`/browser-tasks`) is where every run shows up — what is
+queued, running, waiting on you, or finished.
+
+Browser tasks are different from two related features:
+
+- **[Browser History](../integrations/browser-history.md)** only
+  *reads* your existing Chrome history, passively (research clusters,
+  revisit nudges). It never drives a browser.
+- **[Managed Chromium / B-4](managed-chromium.md)** is the
+  heavily-gated, default-off flow for *confirming a purchase*. Browser
+  tasks handle the general-purpose, non-purchasing actions; the one
+  thing they hand off to the B-4 token flow is a final purchase
+  confirmation.
 
 ## Starting a Task
 
-You don't start a task from this page — you ask in **DM** or `/chat`:
+You don't start a task from this page — you ask in a **DM** or in
+`/chat`:
 
 > "Send a contact form on Amazon's contact-us page saying my order
 > #123 never arrived."
 
 The agent creates the task (`POST /api/browser-task`), opens a tab, and
-works the goal step by step. You can also **schedule** one to run later
-(it appears here when it fires). The page itself is a read + monitor
-surface: filter, search, open a run, or cancel it.
+works toward the goal step by step. You can also **schedule** one to
+run later — it shows up here when it fires. The page itself is just for
+watching and managing runs: filter, search, open a run, or cancel it.
 
 ## Reading the Page
 
-- **Tasks awaiting you** — a strip pinned to the top that only appears
+- **Tasks awaiting you** — a strip pinned to the top that appears only
   when one or more tasks are blocked on your input. It links straight
-  to the run that needs you. The same signal drives the nav red-dot and
-  the persistent shell banner, so they stay in lock-step.
-- **Filter chips** — narrow by state (`All`, `Active`, or a specific
-  state) and by **site**. `Active` means any non-terminal task.
-- **Search** — free-text match over the task description.
+  to the run that needs you. The same signal drives the red dot in the
+  nav and the banner across the top of the app, so they always agree.
+- **Filter chips** — narrow the list by state (`All`, `Active`, or one
+  specific state) and by **site**. `Active` means any task that hasn't
+  finished yet.
+- **Search** — free-text match against the task description.
 - **Table** — one row per task: state, description (click to open the
-  run), site, originating channel, created time, and duration. Active
-  rows expose a **Cancel** button.
+  run), site, the channel it came from, created time, and duration.
+  Active rows show a **Cancel** button.
 
 Click any row to open the **run detail** (`/browser-tasks/:id`): the
 step-by-step event log and the **screenshot trace** the sub-agent
@@ -120,8 +122,9 @@ captured along the way.
 
 ## Task States
 
-A task moves through a small state machine. Non-terminal states are
-still in flight; terminal states are done.
+A task moves through a small set of states. Some are *non-terminal*
+(the task is still going); the rest are *terminal* (the task is
+finished and won't change).
 
 | State | Meaning |
 | --- | --- |
@@ -135,50 +138,53 @@ still in flight; terminal states are done.
 | `timeout` | Exceeded its time budget. |
 | `abandoned` | A pending task expired in the queue before it could start (see `browserTaskPendingQueueTimeoutMinutes`). |
 
-When a task is `awaiting_user` or `final_confirm`, **answer in the DM
-the agent sent you** — that is the loop that unblocks it. The dashboard
-strip and banner are just where you notice it.
+When a task is `awaiting_user` or `final_confirm`, **reply in the DM
+the agent sent you** — that reply is what unblocks it. The dashboard
+strip and banner are just where you notice it needs you.
 
 ## Cancelling
 
-Active tasks have a **Cancel** button (and `POST
+Active tasks have a **Cancel** button (which calls `POST
 /api/browser-task/:id/cancel`). Cancelling releases the browser context
-immediately and DMs you a confirmation. Terminal tasks can't be
-cancelled — there is nothing left to stop.
+(the task's tab) right away and DMs you a confirmation. A finished
+(terminal) task can't be cancelled — there is nothing left to stop.
 
 ## Safety Model (why it's safe to let it drive)
 
-Browser tasks inherit the project's structural browser defences — there
-is **no hardcoded category/brand denylist**:
+Browser tasks inherit the project's structural browser defenses. There
+is **no hardcoded category or brand denylist** — the safety is built
+into how a task runs, not a list of banned sites:
 
 1. **One sandboxed tab per task.** Tasks don't share a browser context,
    so one task can't read another's session.
-2. **Allowlist enforcement + hostname denylist.** Navigation is
-   constrained; you manage blocked hostnames via
+2. **Allowlist enforcement plus a hostname denylist.** Where a task may
+   navigate is restricted; you manage the blocked hostnames via
    `browserTaskHostnameDenylist`.
-3. **IP egress layer (not configurable).** Navigations that resolve to
-   private, loopback, link-local, or cloud-metadata addresses are
-   denied at the egress chokepoint — defence-in-depth against SSRF.
+3. **IP egress layer (not configurable).** If a navigation resolves to
+   a private, loopback, link-local, or cloud-metadata address, it is
+   blocked at the network exit point — defense-in-depth against SSRF
+   (server-side request forgery, where a request is tricked into
+   reaching an internal address).
 4. **Payment-path block.** A URL-pattern matcher trips at form-submit
-   time on payment-handoff paths, so a task can't silently push a
+   time on payment-handoff paths, so a task can't quietly push a
    transaction through. An actual purchase requires the separate,
-   default-off [B-4 token flow](managed-chromium).
-5. **Human-in-the-loop gates.** Anything ambiguous or consequential
-   surfaces as `awaiting_user` / `final_confirm` and waits for your DM.
+   default-off [B-4 token flow](managed-chromium.md).
+5. **Human-in-the-loop gates.** Anything ambiguous or high-stakes
+   pauses as `awaiting_user` or `final_confirm` and waits for your DM.
 
-See **[Safety and Execution](../../concepts/safety-and-execution)** and
-the **[Safety Model](../../concepts/safety-model)** for the full
+See **[Safety and Execution](../../concepts/safety-and-execution.md)**
+and the **[Safety Model](../../concepts/safety-model.md)** for the full
 picture.
 
 ## Configuration
 
 These keys live in the editable config (Settings → Infrastructure):
 
-- `browserTaskMaxConcurrent` — how many tasks may run at once; the rest
-  queue (`pending`).
+- `browserTaskMaxConcurrent` — how many tasks may run at the same time;
+  any extras wait in the queue (`pending`).
 - `browserTaskPendingQueueTimeoutMinutes` — how long a `pending` task
-  waits before it is `abandoned`.
-- `browserTaskRespectQuietHours` — when on, tasks defer during your
-  quiet hours rather than running overnight.
-- `browserTaskHostnameDenylist` — hostnames a task may never navigate
-  to (user-managed; there is no shipped default brand/category list).
+  waits in the queue before it is marked `abandoned`.
+- `browserTaskRespectQuietHours` — when on, tasks hold off during your
+  quiet hours instead of running overnight.
+- `browserTaskHostnameDenylist` — hostnames a task may never visit (you
+  manage this list; nothing is blocked here by default).