@aitne-sh/aitne 0.1.10 → 0.1.12

package/agent-assets/docs/features/routines/custom-routines.md

@@ -1,179 +1,123 @@
 ---
 schema_version: 1
 slug: features/routines/custom-routines
-title: Custom Routines
+title: Custom Routines (Retired)
 id: custom-routines
 aliases:
   - custom routine
   - cron routine
   - user routine
+  - migrated_to_agent
 category: features
 summary: |
-  Beyond the built-in morning / evening / weekly / hourly routines,
-  the operator can define custom routines that fire on any cron
-  schedule. Each routine is a Markdown file under
-  policies/routines/custom/, runs under the tier the operator picks,
-  and is bounded by the same safety layers as the built-ins.
+  Custom routines — cron-driven Markdown files under
+  policies/routines/custom/ — are retired. User Agents replaced them.
+  At the first daemon start after the upgrade, each valid custom
+  routine was converted once into a user Agent with the same cron,
+  tier, budget, and enabled state; the source file is kept but marked
+  inert. Recurring work now lives on /agents.
 section: routines
 tags:
   - routines
+  - agents
   - autonomous
   - scheduler
-  - core
   - advanced
-status: stable
+status: deprecated
 ask_examples:
-  - How do I add a custom routine?
-  - What can a custom routine do?
-  - Can I disable a custom routine?
-  - Which tier does a custom routine run under?
+  - What happened to my custom routines?
+  - Where did my custom routine go?
+  - What does migrated_to_agent mean?
+  - How do I create a recurring task now?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-06-10
 keywords:
   - custom routine
   - routine.custom.<slug>
-  - user-defined routine
-  - scheduled task
-  - recurring schedule
-  - cron routine
+  - migrated_to_agent
+  - user agent
+  - recurring agent
+  - migration
 related:
   - guides/add-a-custom-routine
   - concepts/routines
-  - features/memory-files/schedule
 prerequisites:
   - concepts/routines
 process_keys:
   - routine.custom.<slug>
 context_files:
   - policies/routines/custom/<slug>.md
+  - policies/agents/<slug>/agent.md
 api_endpoints:
-  - PUT /api/context/*
-  - POST /api/recurring-schedules
+  - POST /api/agents
 ui_anchors:
-  - /settings/routines
-  - /connections/routines
+  - /agents
 ---
 
-# Custom Routines
+# Custom Routines (Retired)
 
 ## In One Sentence
 
-Operator-defined routines fire on any cron schedule, run under the
-tier the operator picks (`lite` / `medium` / `high`), and are bounded
-by the same safety layers as the built-ins.
-
-## What It Does
-
-- Runs a vault-file-defined check list on a cron schedule.
-- Resolves the backend at fire time from the chosen tier (no concrete
-  model picker — tier resolution mirrors the built-in routines).
-- Logs its run to Activity exactly like a built-in routine.
-
-## When It Runs
-
-The cron expression in the routine's vault file
-`policies/routines/custom/<slug>.md` drives the cadence. The scheduler
-wires one `node-cron` job per enabled routine at startup and fires a
-`routine.custom.<slug>` event on each tick.
-
-It is a **standard 5-field cron expression** (`min hour day-of-month
-month day-of-week`); for example `0 11 * * 2` is every Tuesday at
-11:00 local time, in your configured timezone.
-
-## How Changes Are Picked Up
-
-There is **no filesystem watcher**. The scheduler reloads only when a
-write goes through the context API — a `PUT` / `PATCH` / `DELETE`
-under `policies/routines/custom/` triggers an automatic re-diff of the
-registered jobs against what is on disk, so edits made through the
-dashboard, the API, or the agent take effect without a daemon restart.
-
-A raw file edit that bypasses the API (for example, opening the `.md`
-in an external editor) is *not* picked up until the next API write to
-that directory or a daemon restart. Prefer editing through **Settings
-→ Routines** or the context API.
-
-## What It Outputs
-
-- Whatever the check list produces — a context-file write, a
-  notification, or a no-op.
-
-## Where in the Dashboard
-
-- **Settings → Routines** (`/settings/routines`) is the operator
-  surface for adding, editing, and disabling. `/connections/routines`
-  is an equivalent page that opens the same surface.
-
-## Configuration
-
-Each custom routine is a Markdown file under
-`~/.personal-agent/context/policies/routines/custom/<slug>.md` whose
-frontmatter carries:
-
-| Field | Type | Notes |
-|---|---|---|
-| `type` | `rule` | Always `rule` for custom routines. |
-| `slug` | string | Kebab-case; matches the file stem and the ProcessKey suffix. |
-| `cron` | string | Standard 5-field cron expression (e.g. `0 11 * * 2`). |
-| `process_key` | `routine.custom.<slug>` | Must match the slug. |
-| `enabled` | boolean (`true` / `false`) | Disable without deleting by setting `false`. |
-| `backend_tier` | `lite` \| `medium` \| `high` | Drives BackendRouter tier resolution. Legacy `light` (→ `medium`) and `heavy` (→ `high`) are still accepted for files written before the rename. |
-| `max_budget_usd` | number | Per-execute USD cap; must be a positive number (e.g. `0.05`). |
-
-Every field above is required; the body must contain a `## Checks`
-section — a routine that is missing any of them is rejected at write
-time with a validation error.
-
-The `## Checks` section is the list the agent runs through on each
-fire. To change a routine, write through the context API (the
-dashboard, the API, or the agent), which triggers an automatic reload
-as described above — no daemon restart is needed.
-
-### Example
-
-A `tuesday-standup-prep` routine at
-`policies/routines/custom/tuesday-standup-prep.md`:
-
-```markdown
----
-type: rule
-slug: tuesday-standup-prep
-cron: "0 11 * * 2"
-process_key: routine.custom.tuesday-standup-prep
-enabled: true
-backend_tier: medium
-max_budget_usd: 0.10
----
-
-## Checks
-
-- Summarize commits I pushed since last Tuesday.
-- List any calendar events for the rest of the week that mention
-  "standup" or "review".
-- If there is anything noteworthy, DM me a short prep note.
-```
-
-This fires every Tuesday at 11:00 (your configured timezone), runs
-under the `medium` tier (Sonnet on the Claude backend), and stops
-spending once the run reaches $0.10.
-
-> **Distinct from `recurring_schedules`.** The `recurring_schedules`
-> table now powers recurring scheduled DMs only (`task_type =
-> 'dm_session'`) — e.g. the morning briefing. They use a structured
-> `RecurrenceRule` (frequency + time + dayOf*) and are managed via
-> `POST /api/recurring-schedules`. Recurring agent *work* moved to the
-> `/agents` layer — `POST /api/recurring-schedules` with any
-> non-`dm_session` task type returns 410 Gone with a pointer to
-> `POST /api/agents`. Neither is the same surface as
-> `routine.custom.<slug>`.
-
-## When Something Goes Wrong
-
-- A cron expression that resolves to "never": the routine appears in
-  the list but never fires. The dashboard's "Next runs" preview shows
-  "No upcoming runs found within the next year for this timezone."
+Custom routines (`policies/routines/custom/<slug>.md` files fired as
+`routine.custom.<slug>`) no longer run — **user Agents replaced
+them**, and every valid routine was converted automatically, exactly
+once, at the first daemon start after the upgrade.
+
+## What Changed
+
+- The custom-routine scheduler was removed. Files under
+  `policies/routines/custom/` are no longer read by any scheduler, and
+  no `routine.custom.<slug>` events fire. (Historical Activity rows
+  tagged with those keys remain and still resolve to this page.)
+- Recurring work you define is now an **Agent**: a
+  `policies/agents/<slug>/agent.md` file that appears on the
+  **Agents** page (`/agents`) with its schedule, an enable toggle, run
+  metrics, execution history, and a **Run now** button — surfaces
+  custom routines never had. See
+  [Create a Recurring Agent](../../guides/add-a-custom-routine.md).
+
+## The One-Time Migration
+
+At the first daemon start after the upgrade — and only once, guarded
+by a persisted flag — every file under `policies/routines/custom/` is
+examined:
+
+- A **valid routine becomes a user Agent** at
+  `policies/agents/<slug>/agent.md` carrying over:
+  - the same **cron expression** (pinned to your configured timezone),
+  - the same **model tier** (`backend_tier` → the Agent's tier),
+  - the same **per-run budget** (`max_budget_usd`),
+  - the same **enabled state** — a disabled routine migrates disabled.
+
+  The routine's body (its `## Checks` section) becomes the Agent's
+  **task prompt** verbatim, and the Agent's description records where
+  it came from (`Migrated from custom routine "<slug>".`).
+- The **source file is never deleted.** It is rewritten in place with
+  `enabled: false` and a `migrated_to_agent: <slug>` marker in its
+  frontmatter, so it is visibly inert while your content is preserved.
+
+### Collisions and invalid files
+
+- **Slug collision** — if an Agent (built-in or user) already exists
+  under the routine's slug, the migration falls back to
+  `custom-<slug>`. If that also collides, the routine is skipped with
+  a warning and the file is left untouched.
+- **Invalid files** — a routine with broken frontmatter or missing
+  required fields is left untouched and logged; it is not migrated.
+  (Such files never fired under the old scheduler either.)
+
+## After the Migration
+
+- Find your migrated routines on **`/agents`** — each one's
+  description says which custom routine it came from.
+- Edit the schedule, tier, limits, or prompt there (or directly in the
+  `agent.md` file; the daemon picks up changes without a restart).
+- The inert files under `policies/routines/custom/` can stay as a
+  reference or be deleted whenever you like — they have no effect
+  either way.
 
 ## Related
 
-- [Add a Custom Routine](../../guides/add-a-custom-routine.md)
+- [Create a Recurring Agent](../../guides/add-a-custom-routine.md)
+- [Routines](../../concepts/routines.md)

package/agent-assets/docs/features/routines/evening-review.md

@@ -27,7 +27,7 @@ ask_examples:
   - How do I disable the evening review?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-06-10
 keywords:
   - evening review
   - retro
@@ -39,7 +39,7 @@ related:
   - features/memory-files/agent-journal
   - features/memory-files/today
   - features/routines/morning-routine
-  - features/routines/custom-routines
+  - guides/add-a-custom-routine
 process_keys:
   - routine.evening_review
 context_files:
@@ -50,8 +50,8 @@ context_files:
   - policies/routines/evening.md
   - policies/agent-lessons.md
 ui_anchors:
-  - /connections/journal
-  - /settings/routines
+  - /knowledge?tab=context-files
+  - /agents/evening-review
 ---
 
 # Evening Review
@@ -110,19 +110,21 @@ including steps that call `POST /api/notify`.)
 
 ## Where in the Dashboard
 
-- **Connections → Journal** (`/connections/journal`) shows `journal/agent.md`
-  entries when the roadmap step logged one.
-- **Settings → Routines** (`/settings/routines`) is where you manage the
-  evening rulebook.
+- **Knowledge → Context Files** (`/knowledge?tab=context-files`) shows
+  `journal/agent.md` entries when the roadmap step logged one.
+- **Agents → Evening Review** (`/agents/evening-review`) is where you
+  manage the evening rulebook (Rulebook tab) and enable or disable the
+  routine.
 
 ## Configuration
 
 The fire time and tier are fixed in code, but the routine is not a black box:
 - **Add your own evening checks.** Append `### <label>` entries to
-  `policies/routines/evening.md` (via the dashboard, or the
-  [custom routines guide](../../guides/add-a-custom-routine.md)). They run
-  alongside the built-in steps using the same journaling conventions and
-  may notify you explicitly.
+  `policies/routines/evening.md` (via the dashboard or the context
+  API). They run alongside the built-in steps using the same
+  journaling conventions and may notify you explicitly. For a
+  standalone recurring job on its own schedule, create a
+  [recurring Agent](../../guides/add-a-custom-routine.md) instead.
 - **Verify it stays healthy.** `aitne verify evening-review-slimdown`
   checks that recent `routine.evening_review` sessions ran inside their
   seeded token envelope (read-only; `--days N` widens the window).

package/agent-assets/docs/features/routines/morning-routine.md

@@ -26,7 +26,7 @@ ask_examples:
   - What model does morning routine use?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-06-10
 keywords:
   - morning
   - day plan
@@ -42,7 +42,7 @@ related:
 prerequisites:
   - concepts/agent-day
 ui_anchors:
-  - /settings/routines
+  - /agents/morning-routine
   - /settings/models
   - /schedule
   - /activity
@@ -91,7 +91,7 @@ Within Stage A, the work proceeds in this order:
 2. Pull today's calendar events from any connected calendar integration.
 3. Scan recent unread mail and surface the few that need owner attention.
 4. Walk the roadmap for items whose **Preparation Timeline** rows fire today.
-5. Consume any pending observations the hourly check has already queued.
+5. Consume any pending observations the activity scan has already queued.
 6. Write the rebuilt `state/today.md`.
 7. Log a single status line to the dashboard activity feed.
 
@@ -126,13 +126,14 @@ through the parent `routine.morning_routine` envelope.)
 - **Schedule view** — the column for today is rebuilt against the new schedule file.
 - **Activity feed** — a `routine.morning_routine` row appears at the run timestamp.
 - **Settings → Models** — the routine's backend, model, max-turns, and budget cap are configured here.
+- **Agents → Morning Routine** (`/agents/morning-routine`) — the agent's Rulebook tab edits the morning rulebook (`policies/routines/morning.md`) plus the daily-journal Format and Export rules.
 
 ## Configuration
 
 | Setting | Default | Notes |
 |---|---|---|
 | `dayBoundaryHour` | `4` | Both the agent-day boundary and the morning-routine fire time. See [Agent Day](../../concepts/agent-day.md). |
-| Stage A tier (`routine.morning_routine_today`) | medium (Sonnet 4.6) | Synthesises `state/today.md` + the day's roadmap fan-out. Adjustable per-row in Settings → Models. |
+| Stage A tier (`routine.morning_routine_today`) | medium (Sonnet 5) | Synthesises `state/today.md` + the day's roadmap fan-out. Adjustable per-row in Settings → Models. |
 | Stage B tier (`routine.morning_routine_journal`) | lite (Haiku 4.5) | Authors `journal/daily/<date>.md` and the `journal/agent.md` audit paragraph. |
 | Stage A max turns / budget | 50 turns / $1.50 | Per-execute envelope for `routine.morning_routine_today`. Adjustable in Settings → Models. |
 | Stage B max turns / budget | 20 turns / $0.30 | Per-execute envelope for `routine.morning_routine_journal`. |

package/agent-assets/docs/features/routines/weekly-review.md

@@ -27,7 +27,7 @@ ask_examples:
   - Where do weekly retros get stored?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-10
 keywords:
   - weekly review
   - Friday review
@@ -45,9 +45,10 @@ process_keys:
 config_keys:
   - timezone
   - dayBoundaryHour
+  - selfTuningEnabled
 ui_anchors:
   - /settings/models
-  - /settings/routines
+  - /agents/weekly-review
 context_files:
   - journal/weekly/YYYY-Www.md
   - journal/agent.md
@@ -75,6 +76,17 @@ into every morning routine of the following ISO week.
   feedback signal (in addition to the `journal/agent.md` prose), so the
   idea is consolidated into the [agent lessons](../memory-files/agent-lessons.md)
   rather than only living in the journal.
+- Judges the daemon's self-tuning recommendations: when the weekly
+  pre-step finds a cost knob worth changing (e.g. raising the mail
+  pre-pass freshness window because most fetches came back empty), it
+  injects up to three bounded proposals and the review records an
+  apply / reject / defer verdict for each. While `selfTuningEnabled` is
+  `false` (the default) nothing is ever changed automatically — verdicts
+  are recorded for the owner to review (shadow mode). With the flag on,
+  an apply verdict is actuated immediately by the daemon within hard
+  per-key bounds; the owner gets a one-line DM per applied change
+  (`!revert tuning` undoes the latest one) and a daily monitor
+  auto-reverts any change whose 7-day follow-up metrics regressed.
 - Sends a brief Friday-evening notification by default (the silence
   gate triggers only on an essentially blank week).
 - Refreshes `identity/reading-taste.md` and Book Candidates when
@@ -103,7 +115,10 @@ The fire time (Friday 19:00 local) and day-of-week are fixed in code
 and are not operator-tunable. The backend and model that handle this
 routine, however, are configurable: `routine.weekly_review` is a
 configurable process key (default **medium** tier — Sonnet on Claude)
-that you can repoint from **Settings → Models**.
+that you can repoint from **Settings → Models**. The weekly rulebook
+(`policies/routines/weekly.md`) is edited on the weekly-review agent's
+Rulebook tab (`/agents/weekly-review?tab=rulebook`), where the agent
+can also be enabled or disabled.
 
 ## When Something Goes Wrong
 

package/agent-assets/docs/features/wiki/commands.md

@@ -146,7 +146,7 @@ Full rebuilds touch every wiki note and are the most expensive
 command in the wiki surface. The flow:
 
 1. The bang handler estimates the cost (per raw note, an on-disk
-   char→token approximation × Sonnet 4.6 input price, bracketed
+   char→token approximation × Sonnet 5 input price, bracketed
    optimistic 0.5× / expected 1× / pessimistic 2×).
 2. On an external git-tracked vault with **Auto-commit before
    `!compile full`** enabled and a clean working tree, Aitne runs

package/agent-assets/docs/features/wiki/dashboard.md

@@ -222,7 +222,7 @@ The full configuration:
   model, turn limit, and per-run budget on each `wiki.*` process key
   (`wiki.ingest_url`, `wiki.compile`, `wiki.ask`, `wiki.lint`,
   `wiki.trace`, `wiki.connect`). All six default to the medium tier
-  (Claude Sonnet 4.6) with a sensible `maxTurns` / `maxBudgetUsd`; you
+  (Claude Sonnet 5) with a sensible `maxTurns` / `maxBudgetUsd`; you
   can override per key.
 - **Archive / delete** — archive keeps the row but flips `active=0`;
   delete drops the row (data on disk is untouched on external mode).

package/agent-assets/docs/getting-started/01-what-is-this.md

@@ -90,8 +90,8 @@ You can change the times, disable any of them, or add your own.
 
 → [Morning Routine](../features/routines/morning-routine.md) ·
 [Evening Review](../features/routines/evening-review.md) ·
-[Hourly Check](../features/routines/hourly-check.md) ·
-[Custom Routines](../features/routines/custom-routines.md)
+[Activity Scan](../features/routines/activity-scan.md) ·
+[Create a Recurring Agent](../guides/add-a-custom-routine.md)
 
 ### Reach you through a messenger
 
@@ -117,7 +117,7 @@ Pairing is one-time per channel.
 
 When you connect an integration, the agent polls it on a schedule and
 records anything that looks relevant as an
-[observation](../concepts/observations.md). The hourly routine then
+[observation](../concepts/observations.md). The activity scan then
 decides what (if anything) is worth telling you about.
 
 - [Mail](../features/integrations/mail.md) — Gmail, Outlook, Yahoo,
@@ -181,7 +181,7 @@ dashboard surfaces a warning whenever a backend is running on
 subscription auth.
 
 Each kind of work is mapped to a backend and a tier — most work runs
-on medium (Claude Sonnet 4.6 by default) and quick triage on lite
+on medium (Claude Sonnet 5 by default) and quick triage on lite
 (Claude Haiku 4.5). The high tier (Claude Opus 4.8) is registered but
 left unseeded; you opt into it per task from the dashboard. You can
 change any of this mapping at any time.

package/agent-assets/docs/getting-started/04-first-day.md

@@ -43,7 +43,7 @@ ui_anchors:
   - /knowledge?tab=context-files
   - /connections
   - /connections/mcp
-  - /settings/routines
+  - /agents
   - /activity
 context_files:
   - identity/profile.md
@@ -52,14 +52,14 @@ context_files:
 api_endpoints:
   - POST /api/knowledge/import
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-06-10
 related:
   - getting-started/02-first-steps
   - getting-started/03-what-can-this-do
   - guides/setup-wizard
   - guides/import-knowledge-file
   - features/routines/morning-routine
-  - features/routines/custom-routines
+  - guides/add-a-custom-routine
   - features/memory-files/user-profile
   - concepts/delegated-mode
   - concepts/skills
@@ -236,12 +236,11 @@ recurring:
   and message me on WhatsApp."* The agent stores a recurring
   schedule and runs the same prompt at the same cron. Best for
   per-channel reminders and small recurring asks.
-- **Custom routines** — heavier, multi-step jobs that should write
-  to Markdown memory and DM you with a summary. Add one under
-  **Settings → Routines → Add custom routine**, or DM the agent the
-  cron + steps and ask it to save the routine. See
-  [Custom Routines](../features/routines/custom-routines.md) and
-  [Add a Custom Routine](../guides/add-a-custom-routine.md).
+- **User Agents** — heavier, multi-step jobs that should write
+  to Markdown memory and DM you with a summary. Create one under
+  **Agents → New Agent** (`/agents`), or DM the agent the
+  cron + steps and ask it to save it as an Agent. See
+  [Create a Recurring Agent](../guides/add-a-custom-routine.md).
 
 ### A worked example: a richer morning routine
 
@@ -265,23 +264,22 @@ Shortest path from zero to that:
    notes." This makes the gaps obvious — Notion not connected?
    Calendar not connected? WhatsApp not paired? Drive not reachable
    through a connector or MCP server? Fix them as they show up.
-2. **Once each piece works standalone**, open **Settings → Routines
-   → Add custom routine**:
-   - Slug: `morning-deep-prep`
-   - Cron: `0 7 * * 1-5`
-   - Backend tier: `high (opus)` — this is a heavy, multi-tool job
-   - Max budget (USD): `0.20` (a generous per-execute override; the
-     form default is `0.05`)
-   - Description: paste the four numbered steps above verbatim.
-3. **Watch the next firing in Agent Log** and iterate. The vault file
-   at `~/.personal-agent/context/policies/routines/custom/morning-deep-prep.md`
-   is a plain Markdown file: edit the `## Checks` body to refine the
-   step wording, or the `cron:` field in the YAML frontmatter to
-   change the schedule. The watcher picks up changes without a
-   restart.
-
-→ [Custom Routines](../features/routines/custom-routines.md) ·
-[Add a Custom Routine](../guides/add-a-custom-routine.md)
+2. **Once each piece works standalone**, open **Agents → New Agent**
+   (`/agents`):
+   - Name / ID: `morning-deep-prep`
+   - Schedule: weekdays (Mon–Fri) at 07:00
+   - Model tier: `high (opus)` — this is a heavy, multi-tool job
+   - Max budget (USD): `0.20` (a generous per-execute override)
+   - Task prompt: paste the four numbered steps above verbatim.
+3. **Watch the next firing in Agent Log** and iterate. The agent
+   definition lives in the vault at
+   `~/.personal-agent/context/policies/agents/morning-deep-prep/agent.md`
+   — a plain Markdown file whose body is the task prompt and whose
+   YAML frontmatter carries the schedule — but the easiest place to
+   refine the step wording or the schedule is the agent's own page
+   at `/agents/morning-deep-prep`.
+
+→ [Create a Recurring Agent](../guides/add-a-custom-routine.md)
 
 ---
 
@@ -294,8 +292,8 @@ By end of day one you should have:
   **Activity**.
 - One DM whose answer references something only your connected
   apps could have told the agent.
-- (Stretch) one custom routine or recurring schedule in **Settings
-  → Routines** that you'd be sad to lose.
+- (Stretch) one user agent or recurring schedule under **Agents**
+  (`/agents`) that you'd be sad to lose.
 
 ## If it fails
 
@@ -312,8 +310,7 @@ By end of day one you should have:
 
 - [Import a Knowledge File](../guides/import-knowledge-file.md)
 - [Morning Routine](../features/routines/morning-routine.md)
-- [Custom Routines](../features/routines/custom-routines.md)
-- [Add a Custom Routine](../guides/add-a-custom-routine.md)
+- [Create a Recurring Agent](../guides/add-a-custom-routine.md)
 - [Delegated Mode](../concepts/delegated-mode.md)
 - [Skills and MCP](../concepts/skills.md)
 - [identity/profile.md](../features/memory-files/user-profile.md)

package/agent-assets/docs/glossary.md

@@ -78,7 +78,7 @@ process_keys:
   - dashboard.docs_qa
   - delegated_task_heavy
   - routine.fetch_window
-  - routine.hourly_check
+  - routine.activity_scan
   - routine.research_cluster_update
 config_keys:
   - dayBoundaryHour
@@ -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) —
-  default for owner DMs, dashboard chat, the hourly check, and the
-  morning / evening / weekly review routines.
+- **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. (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,
@@ -252,7 +253,7 @@ fallback when upstream reports zero.
 ## Routine Pre-pass
 
 A lite-tier `routine.fetch_window` session spawned before each main
-routine (morning / today_refresh / hourly_check / evening / weekly).
+routine (morning / today_refresh / activity_scan / evening / weekly).
 It fetches each routine's mail / calendar / Notion window
 (`ROUTINE_WINDOWS`) and POSTs the results to `/api/observations`. The
 main routine then consumes the resulting `<fetch_report>` block and
@@ -264,7 +265,7 @@ in 2026-05 to trim morning-routine input tokens by ~24%.
 One row in the `observations` table. A change record a polling
 integration (Obsidian, Git, Notion, calendar, mail, browser history)
 or a `routine.fetch_window` pre-pass wrote into SQLite. The
-`routine.hourly_check` is the consumer — there is no per-change
+`routine.activity_scan` is the consumer — there is no per-change
 notification. `actor='agent'` rows are filtered out by the consumer
 to break the agent-observing-its-own-writes loop. See
 [Observations](concepts/observations.md).