@aitne-sh/aitne 0.1.11 → 0.1.13

package/agent-assets/docs/glossary.md

@@ -13,9 +13,7 @@ summary: |
   Single flat term list for Aitne vocabulary. Cross-references
   link to a single canonical anchor here so concept docs do not drift.
 tags:
-  - core
-  - reference
-  - glossary
+  - knowledge
 status: stable
 ask_examples:
   - What is a ProcessKey?
@@ -35,7 +33,7 @@ ask_examples:
   - What is an observation?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - terminology
   - vocabulary
@@ -102,7 +100,7 @@ and rationale.
 
 ## Backend
 
-One of the model providers Aitne can dispatch to: `claude`
+One of the AI model providers Aitne can send work to: `claude`
 (Claude Code SDK), `codex` (Codex CLI), `gemini` (Gemini CLI), or
 `opencode` (`@opencode-ai/sdk` HTTP server). Each backend is configured
 per-installation; one is the **main backend**, and the others can be
@@ -110,12 +108,13 @@ enabled as fallbacks.
 
 ## Browser History (B-3)
 
-Local-only history poller that reads the browser's own SQLite database
+A local-only poller that reads the browser's own SQLite history database
 (Chromium-based browsers — Chrome, Chromium, Edge, Brave, Comet, Atlas)
-and records page visits as observations. Drives the **research cluster** derivation, the weekly
-reload-memory block, and the [`!checks`](features/messaging/bang-commands.md)
-on-demand reload tally. No content is uploaded; only URLs, titles, and
-visit timings the browser itself recorded. See
+and records page visits as observations. It feeds the **research cluster**
+derivation, the weekly reload-memory block, and the
+[`!checks`](features/messaging/bang-commands.md) on-demand reload tally.
+Nothing is uploaded — only the URLs, titles, and visit timings the browser
+itself already recorded. See
 [Browser History](features/integrations/browser-history.md).
 
 ## Managed Chromium (B-4)
@@ -146,8 +145,9 @@ enabled custom commands appear in `!help`. See
 
 ## Backend Router
 
-The component that resolves a `ProcessKey` to a concrete `(backend,
-model, maxTurns, maxBudgetUsd)` binding at dispatch time. Lives in
+The component that turns a `ProcessKey` into a concrete `(backend,
+model, maxTurns, maxBudgetUsd)` binding at dispatch time (the moment an
+invocation is handed to a backend). Lives in
 `packages/daemon/src/core/backends/backend-router.ts`. Routing reads
 `process_backend_config` (per-process pins) layered over
 `backend_global_defaults` (installation-wide defaults).
@@ -160,8 +160,8 @@ matching anchor.
 
 ## Day Boundary
 
-The hour-of-day at which the agent day rolls over. Configured via
-`dayBoundaryHour` (default `4`).
+The hour of the day when the agent day rolls over (when "today" starts
+fresh). Configured via `dayBoundaryHour` (default `4`).
 
 ## deniedTools
 
@@ -228,10 +228,11 @@ dashboard page.
 
 Operator-facing umbrella for the two non-heavy lanes on each backend:
 
-- **Medium / Main** (Claude Sonnet 4.6, `gpt-5.4` on Codex,
-  `gemini-3.1-pro-preview` on Gemini, Sonnet 4.6 via OpenCode) —
+- **Medium / Main** (Claude Sonnet 5, `gpt-5.4` on Codex,
+  `gemini-3.1-pro-preview` on Gemini, Sonnet 5 via OpenCode) —
   default for owner DMs, dashboard chat, the activity scan, and the
-  morning / evening / weekly review routines.
+  morning / evening / weekly review routines. (Sonnet 4.6 became a
+  `(legacy)` pin when Sonnet 5 shipped on 2026-06-30.)
 - **Lite / Delegated** (Claude Haiku 4.5, `gpt-5.4-mini` on Codex,
   `gemini-3.1-flash-lite-preview` on Gemini, Haiku 4.5 via OpenCode) —
   reserved for mechanical / delegated surfaces: Gmail classification,
@@ -261,7 +262,7 @@ in 2026-05 to trim morning-routine input tokens by ~24%.
 
 ## Observation
 
-One row in the `observations` table. A change record a polling
+One row in the `observations` table. A change record that a polling
 integration (Obsidian, Git, Notion, calendar, mail, browser history)
 or a `routine.fetch_window` pre-pass wrote into SQLite. The
 `routine.activity_scan` is the consumer — there is no per-change
@@ -271,7 +272,8 @@ to break the agent-observing-its-own-writes loop. See
 
 ## ProcessKey
 
-The branded string identifier for a class of agent invocation, e.g.
+The typed string identifier (a "branded" string in the TypeScript code)
+for a class of agent invocation, e.g.
 `routine.morning_routine`, `message.dm`, `dashboard.docs_qa`. Drives
 backend selection, skill manifest, agent profile, and task-flow
 template lookup. Defined in `packages/shared/src/process-key.ts`.

package/agent-assets/docs/guides/add-a-custom-routine.md

@@ -18,12 +18,10 @@ summary: |
   prompt for every run; runs appear on the Agent's detail page.
 section: add-a-custom-routine
 tags:
-  - guides
   - agents
   - routines
   - scheduler
   - autonomous
-  - core
 status: stable
 ask_examples:
   - How do I create a recurring agent?
@@ -32,7 +30,7 @@ ask_examples:
   - Where do I see my agent's runs?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-10
+updated: 2026-07-01
 keywords:
   - recurring agent
   - new agent
@@ -60,8 +58,8 @@ related:
 
 ## Goal
 
-Make the agent fire a particular kind of work on a schedule you pick —
-as a user **Agent** you can watch, tune, and toggle from `/agents`.
+Run a task you write on a schedule you pick, packaged as a user
+**Agent** you can watch, tune, and toggle from `/agents`.
 
 ## Prerequisites
 
@@ -89,7 +87,7 @@ as a user **Agent** you can watch, tune, and toggle from `/agents`.
      becomes the Markdown body of `agent.md` and is the prompt the
      agent receives every time it fires.
    - An **Advanced (YAML)** toggle reveals the raw `agent.md` editor
-     for long-tail fields the form doesn't expose (tags, tools,
+     for the extra fields the form doesn't expose (tags, tools,
      success criteria, error handling).
 3. Save. The dashboard writes `policies/agents/<slug>/agent.md`
    through the context vault and opens the new Agent's detail page;
@@ -114,7 +112,10 @@ curl -X POST http://localhost:8321/api/agents \
 ```
 
 - **`prompt` becomes the Agent's task prompt** — it is stored as the
-  Markdown body of `agent.md` and sent to the agent on every run.
+  Markdown body of `agent.md` and sent to the agent on every run. It
+  must be a real task definition: an empty body or a stand-in like
+  `"placeholder"`/`"TODO"` is rejected as `400 invalid_definition`
+  (the agent would skip every run as too ambiguous to act on).
 - **`schedule`** takes one of two forms: a raw 5-field cron
   (`{ "kind": "cron", "expression": "0 11 * * 2" }`, interpreted in
   the daemon's timezone unless `schedule.timezone` is set) or a
@@ -122,8 +123,8 @@ curl -X POST http://localhost:8321/api/agents \
   "weekly", "daysOfWeek": ["tuesday"], "time": "11:00" } }`).
   `/agents` is recurring-only — a one-time task belongs on
   `POST /api/schedule` instead.
-- **`backend.tier`** is optional; omitted, the Agent inherits the
-  `agent.task` process default (medium). `backend.process_key`
+- **`backend.tier`** is optional; if you omit it, the Agent inherits
+  the `agent.task` process default (medium). `backend.process_key`
   defaults to `agent.task` — you don't need to set it.
 - **`limits`** defaults: 20 turns, $0.25 per run, 10-minute timeout.
 - Success returns `201 { "status": "created", "slug": ... }`. A taken
@@ -152,9 +153,13 @@ curl -X POST http://localhost:8321/api/agents \
 - `400 invalid_definition` — fix the fields listed in `issues`.
 - `400 one_shot_not_supported` — `/agents` is recurring-only; use
   `POST /api/schedule` for one-time work.
-- A prompt that hits the absolute-block guardrails: the run fires but
-  the offending tool call is logged as `blocked_absolute` in the
-  action log.
+- **Run now** returns `409 agent_prompt_placeholder` — the Agent's
+  stored prompt is empty or still a placeholder stub (possible for
+  Agents created before this was validated); write the real task into
+  its `agent.md` and try again.
+- A prompt that trips the absolute-block guardrails — the run still
+  executes, but the offending tool call is logged as `blocked_absolute`
+  in the action log.
 
 ## Migrating From Custom Routines
 

package/agent-assets/docs/guides/backup-and-restore.md

@@ -17,7 +17,6 @@ summary: |
   this directory, so re-register them after a restore.
 section: backup-and-restore
 tags:
-  - guides
   - operations
   - backup
 status: stable
@@ -27,7 +26,7 @@ ask_examples:
   - Why are my API keys gone after restoring a backup?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-07-01
 keywords:
   - backup
   - restore
@@ -46,12 +45,12 @@ related:
 
 ## Goal
 
-Capture all of Aitne's durable state in a single tar archive you can
-restore later — on this machine or a fresh one.
+Save everything Aitne keeps on disk into a single tar archive (a `.tgz`
+file) that you can restore later — on this machine or a new one.
 
 ## What's in the backup (and what isn't)
 
-Everything Aitne persists lives under `PA_DATA_DIR` (default
+Everything Aitne saves lives under `PA_DATA_DIR` (default
 `~/.personal-agent`), so backing up that one directory captures it all:
 
 - `data/personal_agent.db` — sessions, actions, observations, FTS index
@@ -72,8 +71,9 @@ Both are re-added through the dashboard after restore.
 
 ## Steps
 
-1. **Stop the daemon** so the SQLite write-ahead log is checkpointed and
-   the snapshot is consistent:
+1. **Stop the daemon** (Aitne's background service). This flushes any
+   pending database writes to disk — the SQLite write-ahead log is
+   checkpointed — so your snapshot is a clean, consistent copy:
 
    ```bash
    aitne stop
@@ -95,7 +95,8 @@ Both are re-added through the dashboard after restore.
    ```
 
    Schema migrations run automatically on the first boot (see below), so
-   an older DB is brought up to the current shape without extra steps.
+   Aitne upgrades an older database to the current shape without extra
+   steps.
 
 4. **Re-register secrets and re-pair messaging** through the dashboard —
    they were never in the tar.
@@ -109,16 +110,18 @@ Both are re-added through the dashboard after restore.
 ## If It Fails
 
 - **Schema mismatch on restore.** Aitne ships forward-only schema
-  migrations applied automatically at boot (see
-  [Schema Migration](../glossary.md#schema-migration)), so a restored DB
-  from an older daemon version usually just works — the migration runner
-  brings it up to the current shape on the next start. Only fall back to
-  dropping the DB (see [Reinstall Cleanly](reinstall-cleanly.md)) if the
-  daemon refuses to start *after* you've checked the log
-  (`aitne logs`) for a real migration error.
+  migrations — they only ever upgrade a database, never downgrade it —
+  and applies them automatically at boot (see
+  [Schema Migration](../glossary.md#schema-migration)), so a restored
+  database from an older daemon version usually just works: the migration
+  runner brings it up to the current shape on the next start. Only fall
+  back to dropping the database (see
+  [Reinstall Cleanly](reinstall-cleanly.md)) if the daemon refuses to
+  start *after* you've checked the log (`aitne logs`) for a real
+  migration error.
 - **The agent can't reach its backends after restore.** That's the
   missing keychain secrets — re-add your API keys in the dashboard
-  (Step 4). The DB and context restore fine without them.
+  (Step 4). The database and context restore fine without them.
 
 ## Moving to a different machine?
 

package/agent-assets/docs/guides/budget-and-cost-for-wiki.md

@@ -15,7 +15,6 @@ summary: |
   to tune the threshold.
 section: budget-and-cost-for-wiki
 tags:
-  - guides
   - wiki
   - cost
   - approval
@@ -27,7 +26,7 @@ ask_examples:
   - What does the pre-compile snapshot do?
 locale: en-US
 created: 2026-05-12
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - wiki budget
   - wiki cost
@@ -56,90 +55,86 @@ ui_anchors:
 
 # Wiki Budgets and Cost
 
-The wiki ships with three cost knobs you can tune in
-**Settings → Wiki** (`/settings/wiki`):
+This is the operator's walkthrough for keeping wiki spending under
+control. For the deep mechanics — exactly how the estimate is
+computed and how the approval gate decides — see
+[features/wiki/cost-and-approval](../features/wiki/cost-and-approval.md).
 
-1. **Per-command model selector** for each wiki process. The model
-   picker covers the full set: `wiki.ingest_url`, `wiki.compile`,
-   `wiki.ask`, plus the operational triad `wiki.lint`, `wiki.trace`,
-   `wiki.connect`. Each defaults to your main backend at the medium
-   tier; downgrade `wiki.ingest_url` to a lite tier if you ingest a
-   lot of URLs.
+The wiki gives you three cost knobs, all in **Settings → Wiki**
+(`/settings/wiki`):
+
+1. **Per-command model picker** — one model per wiki process. The
+   picker covers `wiki.ingest_url`, `wiki.compile`, and `wiki.ask`,
+   plus the operational trio `wiki.lint`, `wiki.trace`, and
+   `wiki.connect`. Each starts on your main backend at the medium
+   tier. If you ingest a lot of URLs, drop `wiki.ingest_url` to a lite
+   tier to save money.
 2. **Per-process budget cap** (`max_budget_usd` on each row). The
-   dispatcher's per-session budget envelope is the enforcer.
+   dispatcher's per-session budget envelope enforces it.
 3. **Per-workspace `!compile full` approval threshold** (default
-   $2.00, range $0–$100). The cost estimator brackets the expected
-   spend at 0.5× / 1× / 2× the estimated input-token count; if the
-   pessimistic (2×) estimate breaches the threshold, the bang handler
-   escalates to the approval queue instead of running autonomously.
+   $2.00, range $0–$100). The estimator brackets the likely spend at
+   0.5× / 1× / 2× the estimated input-token count; if the worst-case
+   (2×) number crosses the threshold, `!compile full` asks for
+   approval instead of running on its own.
 
 ## What the Estimator Does
 
 `!compile full` is the most expensive wiki command because a full
-rebuild touches every raw note. The estimator is **pure JS** — it
-does not spawn an agent (spawning one to estimate would itself burn
-budget). It walks the `10_raw/` layer, approximates each file's token
-count from its on-disk character count, sums the total, and brackets:
-
-```
-expected_usd = total_estimated_input_tokens / 1000 × $0.003
-optimistic   = 0.5 × expected
-pessimistic  = 2.0 × expected
-```
-
-Per-file token approximation is script-aware: ~4 characters per token
-for Latin/prose, ~1.5 for majority-CJK files, with a 200-token floor
-per file so empty or one-line stubs still account for the fixed
-per-call overhead (system prompt, skills bundle, tool docs). The unit
-cost (`$0.003` per 1k tokens) matches Claude Sonnet 4.6's ~$3 /
-Mtoken input price. The bracket lets you see a worst case before
-approving.
+rebuild touches every raw note. Before it runs, a small piece of
+plain JavaScript estimates the cost — it never spawns an agent, since
+spawning one just to estimate would itself burn budget. It walks the
+`10_raw/` layer, approximates each file's token count from its size on
+disk, and reports a low/high bracket so you can weigh a worst case
+before you approve. For the exact character-to-token ratios and the
+0.5× / 2× bracket math, see
+[features/wiki/cost-and-approval](../features/wiki/cost-and-approval.md).
+
+The unit cost (`$0.003` per 1k tokens) matches Claude Sonnet 5's ~$3
+/ Mtoken standard input price. (An introductory $2 / Mtoken rate runs
+through 2026-08-31; the estimate lists the standard rate, while the
+SDK's billed `total_cost_usd` reflects the intro price during the
+window.)
 
 > The dashboard surfaces the top raw files by estimated token count,
 > so you can see which sources dominate the bill before approving.
-> An older flat heuristic (`raw_count × 1500 tokens`) survives as an
-> opt-in fallback for deterministic banner copy, but the default is
-> the per-file character scan described above.
 
 ## Where the Gate Fires
 
-- **Below threshold**: the compile runs autonomously and you get a
-  completion DM with actual spend.
-- **Above threshold**: the bang handler inserts an `agent_schedule`
-  row with `task_type='approval'`, DMs you the estimate, and pauses.
-  The request shows up as an **Approvals** card on the dashboard home
-  page (`/`); the `/settings/wiki` page also points you there.
-  Clicking **Approve** flips the row to `task_type='approved_task'`
-  and the scheduler picks it up — only then is the pre-compile git
-  snapshot taken (see below) and the compile session spawned.
+- **Below threshold**: the compile runs on its own, and you get a
+  completion DM with the actual spend.
+- **Above threshold**: the compile pauses. It inserts an
+  `agent_schedule` row with `task_type='approval'`, DMs you the
+  estimate, and waits. The request shows up as an **Approvals** card
+  on the dashboard home page (`/`); the `/settings/wiki` page also
+  points you there. When you click **Approve**, the row flips to
+  `task_type='approved_task'` and the scheduler picks it up — only
+  then does Aitne take the pre-compile git snapshot (see below) and
+  start the compile session.
 
-If you change your mind, hit **Deny** on the approval card — the row
-flips to `skipped`, no git commit is made, and no agent session is
-spawned.
+Changed your mind? Click **Deny** on the approval card. The row flips
+to `skipped`, no git commit is made, and no agent session runs.
 
 ## Git Pre-Compile Snapshot
 
 On an external workspace that is a git repo and has **Auto-commit
-before `!compile full`** enabled, Aitne runs:
-
-```
-git -C <vault> status --porcelain
-# must be empty — dirty trees refuse the operation entirely
-git -C <vault> add -A
-git -C <vault> commit --allow-empty -m "aitne wiki: pre-compile snapshot <ISO-8601-ts>"
-```
-
-before the compile session starts. The commit message is
-deterministic so you can roll back with `git reset --hard HEAD~1` if
-the compile produces a surprise. The `--no-verify` flag is not used —
-your pre-commit hooks run as normal.
+before `!compile full`** enabled, Aitne commits the vault
+(`git add -A && git commit`) just before the compile session starts,
+giving you a rollback point. If the compile produces a surprise,
+`git reset --hard HEAD~1` puts the vault back. A dirty working tree
+refuses the operation entirely — commit or stash first, then re-run.
+The commit runs your normal pre-commit hooks (the `--no-verify` flag
+is not used).
 
 The estimate DM tells you which snapshot path applies:
 **"will commit before compile starts"** (clean repo), **"not taken
 (no git repo)"**, **"disabled by setting"** (auto-commit off), or
 **"not applicable"** for internal-mode workspaces — those recover via
 `md_file_snapshots` instead of git. When no git backup will be taken,
-you can decide whether to add one before approving.
+you can add one yourself before approving.
+
+For the full state-by-state table of what the snapshot gate does in
+each workspace configuration, see
+[features/wiki/cost-and-approval](../features/wiki/cost-and-approval.md).
 
 ## Tuning the Threshold
 

package/agent-assets/docs/guides/build-your-wiki.md

@@ -14,7 +14,6 @@ summary: |
   notes, and ask a question against the vault.
 section: build-your-wiki
 tags:
-  - guide
   - wiki
   - knowledge
 status: stable
@@ -24,7 +23,7 @@ ask_examples:
   - How do I compile my ingested notes into wiki articles?
 locale: en-US
 created: 2026-05-12
-updated: 2026-05-28
+updated: 2026-07-01
 keywords:
   - wiki
   - build wiki
@@ -53,14 +52,14 @@ prerequisites:
 
 ## Goal
 
-Stand up the internal wiki, capture a URL, compile it into a wiki
-article, and run a question against the result.
+Turn on the internal wiki, capture a URL, compile it into a wiki
+article, and ask a question about the result.
 
 ## Prerequisites
 
 - A paired messaging channel (Telegram, Slack, Discord, WhatsApp, or
   dashboard chat) — see
-  [Pairing and the Magic Phrase](../messaging/pairing-and-magic-phrase.md).
+  [Pairing and the Magic Phrase](../features/messaging/pairing-and-magic-phrase.md).
 - The daemon is running and the dashboard is reachable.
 
 ## Where you'll work in the dashboard
@@ -71,8 +70,8 @@ browsing lives under **My Life**.
 
 - **My Life → Wiki** (`/wiki`) — your main entry point. Shows
   workspace stats, the compiled `_index.md`, and recent activity. When
-  the wiki is not enabled yet, this page renders an **Enable Wiki**
-  call-to-action.
+  the wiki is not enabled yet, this page shows an **Enable Wiki**
+  button instead.
 - **Setup → Settings → Wiki** (`/settings/wiki`) — workspace creation,
   internal/external mode, per-command model selectors, budgets,
   archive / delete.
@@ -101,8 +100,8 @@ you enable a workspace, so you do not need to remember the URL.
    number of URLs queued.
 5. Wait for the per-URL completion DMs (parallel mode) or the single
    summary reply (serial mode).
-6. Run `!compile` to compile raw captures into wiki articles. The
-   compile session synthesises `20_wiki/<slug>.md` files and updates
+6. Run `!compile` to turn your raw captures into wiki articles. The
+   compile session writes `20_wiki/<slug>.md` files and updates
    `20_wiki/_index.md`.
 7. Ask a question: `!ask What did this source say about X?`. The
    answer is written to `30_outputs/<YYYY-MM-DD>-<slug>.md` with
@@ -115,9 +114,9 @@ returns the command list.
 ## What to Try Next
 
 - **Send multiple URLs at once**: `!ingest https://a.com, https://b.com`
-  fans out in parallel by default. Switch to serial mode on
-  `/settings/wiki` when you care about ordering and rate
-  predictability.
+  processes them in parallel (all at once) by default. Switch to serial
+  mode on `/settings/wiki` when you want them handled one at a time, for
+  predictable ordering and request pacing.
 - **Point at an existing Obsidian vault** instead of the daemon-owned
   root — see [Use An Existing Obsidian Vault](use-an-existing-obsidian-vault.md).
 - **Tune the budget** for `wiki.compile` and `wiki.ingest_url` from

package/agent-assets/docs/guides/change-which-model-handles-x.md

@@ -14,7 +14,6 @@ summary: |
   reasoning, or run a routine on Codex while Claude stays the default.
 section: change-which-model-handles-x
 tags:
-  - guide
   - backends
   - operations
   - routing
@@ -25,7 +24,7 @@ ask_examples:
   - Can I change the model for just one ProcessKey?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-07-01
 keywords:
   - per-process model
   - /settings/models
@@ -54,50 +53,53 @@ config_keys:
 
 ## Goal
 
-Override the default backend or model tier for a **single** ProcessKey
-without changing the global default. Use this when one surface needs a
-stronger (or cheaper) model than the seeded default — for example,
-pinning the evening review to Opus (high tier), or pushing a noisy
-delegated routine onto Gemini to save Claude quota.
+Change the backend or model tier for a **single** ProcessKey — the label
+the agent gives to one kind of work, such as `routine.evening_review` —
+without touching the global default. Reach for this when one job needs a
+stronger (or cheaper) model than the shipped default: pin the evening
+review to Opus (high tier), or push a noisy delegated routine onto Gemini
+to save your Claude quota.
 
 ## Steps
 
 1. Open `/settings/models`.
 2. Find the ProcessKey row in the per-process table (e.g.
    `routine.evening_review`).
-3. Set its **main backend** and **tier** explicitly. The tier maps to a
+3. Set its **main backend** and **tier** explicitly. Each tier picks a
    model class — `lite` → Haiku-class, `medium` → Sonnet-class,
-   `high` → Opus-class. Optionally set a **fallback** backend too.
-4. Save. The row is now marked operator-edited and will keep your pin
-   through a defaults reset (only an install-time `force` re-seed
-   overwrites it).
+   `high` → Opus-class. You can also set a **fallback** backend to use if
+   the main one is unavailable.
+4. Save. The row is now marked operator-edited, so it keeps your pin
+   through a defaults reset — only an install-time `force` re-seed
+   overwrites it.
 
 ## Concrete Example
 
 To give the evening review deeper reasoning, set
 `routine.evening_review` → main `claude`, tier `high`. The next evening
-run resolves to **Opus 4.8** instead of the default Sonnet 4.6. The
-execution budget for that run also scales with the tier (high tier
-carries a larger turn / cost envelope than medium).
+run then uses **Opus 4.8** instead of the default Sonnet 5. The run's
+budget scales with the tier too — high tier carries a larger turn and
+cost envelope than medium.
 
 ## Verification
 
-- The next fire of that ProcessKey shows the new backend and model in
-  the **Activity** event detail (after fallback resolution).
+- The next time that ProcessKey runs, its **Activity** event detail
+  shows the new backend and model (after fallback resolution).
 
 ## Caveats
 
-- **`dashboard.docs_qa` is tier-locked to `medium`** — a high/lite pin
-  on that row is ignored by the router. It also inherits its backend
-  from `message.dm`'s pin.
-- **High tier is opt-in, not auto-selected.** No install-time-seeded
-  surface defaults to high; the only `high`-tagged ProcessKey shipped is
-  `delegated_task_heavy`, gated behind the `delegatedTaskHeavyEnabled`
-  config flag. Any *other* ProcessKey can still be pinned to high here.
-- **On Codex and Gemini there is no separately-seeded high model** —
-  their high tier collapses to the medium model, so pinning those
-  backends to high won't change the model unless you pick a specific
-  higher model in the row.
+- **`dashboard.docs_qa` is tier-locked to `medium`** — the router
+  ignores a high or lite pin on that row. It also takes its backend from
+  whatever `message.dm` is pinned to.
+- **High tier is opt-in, never auto-selected.** No shipped surface
+  defaults to high. The only `high`-tagged ProcessKey out of the box is
+  `delegated_task_heavy`, and that stays behind the
+  `delegatedTaskHeavyEnabled` config flag. You can still pin any *other*
+  ProcessKey to high here.
+- **Codex and Gemini ship no separate high model.** On those backends
+  the high tier falls back to the medium model, so pinning them to high
+  changes nothing unless you also pick a specific higher model in the
+  row.
 - To change the backend for *every* ProcessKey at once, use the global
   default instead — see Related.