@aitne-sh/aitne 0.1.9 → 0.1.11

package/agent-assets/docs/concepts/costs-and-quotas.md

@@ -31,7 +31,7 @@ ask_examples:
   - How does Gemini's per-day quota work?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - cost
   - budget
@@ -58,7 +58,7 @@ config_keys:
 process_keys:
   - routine.morning_routine
   - routine.fetch_window
-  - routine.hourly_check
+  - routine.activity_scan
 ---
 
 # Costs and Quotas
@@ -100,7 +100,7 @@ costs so you can re-pin tiers if a routine has gotten too expensive.
 The autonomous daily-cost cap (`autonomousDailyCostCapUsd`) is a
 bumper, not a budget — once the day's autonomous spend crosses it the
 dispatcher starts shedding the *lowest-priority* routines first
-(hourly check), and only escalates to higher-priority ones as spend
+(activity scan), and only escalates to higher-priority ones as spend
 climbs further; the morning routine is the last to be cut. Reactive
 (in-the-loop) DMs and dashboard chat always pass through. A separate
 `autonomousMonthlyCostCapUsd` is a notifications-only soft cap — it
@@ -127,7 +127,7 @@ Concretely:
   against your provider account.
 - **Subscription is fallback only.** If you skip the key, the
   daemon runs against whatever local CLI login is present
-  (`claude`, `codex login`, `gemini auth`). The dashboard surfaces
+  (`claude`, `codex login`, `gemini`). The dashboard surfaces
   a `SubscriptionAuthWarning` banner whenever any backend is on
   this path because most provider policies for headless /
   programmatic agents do not extend to personal subscriptions —
@@ -145,12 +145,12 @@ register an API key on `/settings/models`.
   `ANTHROPIC_API_KEY` / `OPENAI_API_KEY` / `GEMINI_API_KEY` /
   `GOOGLE_API_KEY`.
 - **Subscription fallback**: the CLI's local login (`claude`,
-  `codex login`, `gemini auth`). Used only when no API key is
+  `codex login`, `gemini`). Used only when no API key is
   configured. Cost behaviour then matches whatever the subscription
   enforces (e.g. Claude's rolling 5-hour Opus window on a Max plan).
 - **Daily cost cap**: `autonomousDailyCostCapUsd` (default unset) —
   once the day's autonomous spend crosses it, lower-priority routines
-  are skipped first (hourly check at 100% of the cap, the morning
+  are skipped first (activity scan at 100% of the cap, the morning
   routine only at 200%). Reactive DMs / dashboard chat keep running;
   you can always reach the agent. Distinct from the removed
   `maxDailyCostUsd`, which used to blanket-block reactive traffic too.
@@ -182,7 +182,7 @@ register an API key on `/settings/models`.
   and the first-run branch runs on the parent
   `routine.morning_routine` envelope (medium tier) with a
   daemon-prepared `<roadmap_skeleton>` block.
-- Gemini hourly check on Flash via `GEMINI_API_KEY` = ~$0.0005 per
+- Gemini activity scan on Flash via `GEMINI_API_KEY` = ~$0.0005 per
   fire on the paid tier; the free tier instead consumes one of a
   fixed per-day request budget (Aitne caps Gemini at 450 requests/day
   to match Google's free-tier daily limit — this ceiling is
@@ -196,10 +196,11 @@ register an API key on `/settings/models`.
 
 In the dashboard:
 
-- **Analytics** (`/analytics`) rolls today's cost by backend, by
-  ProcessKey, and by hour. When a backend is running on the
-  subscription fallback, remaining-window math is shown there too.
-- **Sidebar footer** shows the day's running total.
+- **Analytics** (`/analytics`) rolls cost by backend, by ProcessKey
+  (event type), by model, and over daily / weekly / monthly periods,
+  plus a today total.
+- **Sidebar** shows the day's running total next to the Analytics
+  entry.
 - **Activity** event details include the per-execute cost.
 - **Settings → Models** (`/settings/models`) exposes the per-backend
   API-key panel and a warning banner whenever a backend is running on
@@ -207,7 +208,8 @@ In the dashboard:
 
 From a DM or the terminal:
 
-- **`!cost`** (and `!cost claude` / `!cost codex` / `!cost gemini`)
+- **`!cost`** (and `!cost claude` / `!cost codex` / `!cost gemini` /
+  `!cost opencode`)
   DM the agent for trailing-7-day spend, broken down or per-backend.
 - **`aitne status`** prints today's action count and spend;
   **`aitne audit`** lists the action log (filter with `--since`,

package/agent-assets/docs/concepts/delegated-mode.md

@@ -36,7 +36,7 @@ ask_examples:
   - Why don't I see a SKILL.md for Gmail in my Codex session?
 locale: en-US
 created: 2026-04-26
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - delegated mode
   - direct mode
@@ -100,8 +100,8 @@ backend is the same as the integration's `delegatedBackend`:
   for the task-mode body shape.
 
 `native` has no sub-cases. The integration's `nativeBackend` must equal
-the main DM backend — `BackendRouter.setMainBackend` cascades unmatched
-`native` rows to `disabled`. From the agent's call-site view, `native`
+the main DM backend — `cascadeNativeBindingsOnMainSwitch` cascades
+unmatched `native` rows to `disabled`. From the agent's call-site view, `native`
 is indistinguishable from `delegated` same-backend (both are in-session
 MCP); the difference is who polls (no one, for `native`).
 
@@ -115,9 +115,9 @@ MCP); the difference is who polls (no one, for `native`).
 
 The setup tax for direct mode (OAuth client setup in a vendor console, then
 JSON download, then keychain seeding) is the single biggest blocker for
-non-technical operators. Every supported backend — Claude Code, Codex,
-Gemini CLI — already ships first-party connectors to Gmail, Calendar,
-Drive, and more. When the operator is signed into claude.ai or ChatGPT,
+non-technical operators. Claude Code, Codex, and Gemini CLI all ship
+first-party connectors to Gmail, Calendar, Drive, and more (OpenCode
+ships none). When the operator is signed into claude.ai or ChatGPT,
 the agent can reach those services through the backend's own MCP tools,
 zero daemon credentials required.
 
@@ -139,9 +139,9 @@ that case the daemon spawns the other backend per call.
   `/exec` proxy (cross-backend).
 - **`native`** — daemon holds nothing AND runs no poller. The main
   backend's MCP connector reaches the integration on-demand within the
-  agent's own turn (DM, hourly_check, routine pre-pass). The agent
+  agent's own turn (DM, activity_scan, routine pre-pass). The agent
   POSTs results to `/api/observations/batch` so the rest of the
-  observation pipeline (summarizer, hourly check) still operates. See
+  observation pipeline (summarizer, activity scan) still operates. See
   `docs/design/appendices/native-integration-mode.md` for the full
   spec, including the per-key `runtime_state.integration_flip_lock:<key>`
   drain protocol.
@@ -152,8 +152,8 @@ that case the daemon spawns the other backend per call.
 - **`nativeBackend`** — when native, which backend's connector is
   expected. Must equal the main DM backend; changing the main backend
   cascades unmatched `native` rows to `disabled` (the cascade is
-  triggered by `BackendRouter.setMainBackend` /
-  `PUT /api/backends/main`).
+  performed by `cascadeNativeBindingsOnMainSwitch` from the
+  `PUT /api/backends/main` handler).
 - **Same-backend** — DM session backend matches `delegatedBackend` /
   `nativeBackend`. The daemon is not in the loop; the agent calls
   native MCP directly. No skill body is materialized for the
@@ -193,10 +193,10 @@ When you pick `delegated`, also pick `delegatedBackend`:
   is your preferred DM driver (e.g. Claude).
 
 When you pick `native`, `nativeBackend` is fixed to your main DM
-backend. Flipping the main backend re-targets every `native` row; rows
-whose new `nativeBackend` has no descriptor connector for the
-integration (e.g. `gmail` native on a backend that doesn't ship a Gmail
-connector) cascade to `disabled` and the operator gets a DM.
+backend. Flipping the main backend never re-targets `native` rows:
+every row whose `nativeBackend` no longer matches the new main backend
+cascades to `disabled` and the operator gets a DM — re-enabling
+requires an explicit re-flip (with its live probe) on the new backend.
 
 ## Concrete Examples
 
@@ -226,7 +226,7 @@ curl -X POST http://localhost:8321/api/integrations/gmail/exec \
 ```
 
 The daemon spawns a Codex subprocess with the `proxy.md` profile, the
-task-mode planner picks `_search_emails` from the registered
+task-mode planner picks `search_emails` from the registered
 `capabilityTools`, runs it, and returns a structured `{messages:[…]}`
 conforming to `outputSchema`.
 
@@ -283,8 +283,9 @@ the agent consults at session-init. It is rendered as a Markdown table:
 The "Backend" column surfaces whichever binding is active for the row —
 `delegatedBackend` for `delegated`, `nativeBackend` for `native`. For
 `direct` and `disabled` rows it is `—`. The "Sub-tier" column annotates
-delegated Gmail rows (`draft-only` for Claude, `full-auto` for Codex)
-and is `—` for everything else. The file also includes the per-backend
+delegated Gmail rows (`draft-only` for Claude, `full-auto` for Codex);
+other delegated rows show `full`, and non-delegated rows show `—`. The
+file also includes the per-backend
 connector support matrix and the `deniedTools` block; both are rendered
 by `renderManagementMd` (`packages/daemon/src/core/management-md.ts`).
 

package/agent-assets/docs/concepts/memory-model.md

@@ -29,7 +29,7 @@ ask_examples:
   - How does the daemon prevent the agent from writing to disk directly?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-11
 keywords:
   - context
   - markdown
@@ -53,7 +53,7 @@ related:
   - features/memory-files/projects
 ui_anchors:
   - /knowledge
-  - /connections/knowledge
+  - /settings
 context_files:
   - state/today.md
   - identity/profile.md
@@ -129,7 +129,8 @@ curl -X PATCH http://localhost:8321/api/context/state/today.md \
 
 - `PUT /api/context/*` replaces a whole file; `PATCH` does a section op
   (`append`, `replace`, `clear`, `clear_before`, `append_to_file`);
-  `DELETE` removes a file (permitted only for custom routines).
+  `DELETE` removes a file (permitted only on a few paths — user Agent
+  definitions, inbox/scratch notes, and legacy custom-routine files).
 - Legacy bare paths (`/api/context/today.md`) still resolve — the daemon
   rewrites them to the canonical class-prefixed form in process, so a
   plain `curl -X PATCH` without `-L` keeps working — but new writes
@@ -153,18 +154,24 @@ curl -X PATCH http://localhost:8321/api/context/state/today.md \
   synthesized by the morning routine.
 - `plans/projects/<slug>.md` — one file per active project.
 - `policies/management.md` — the umbrella registry: Source-of-Truth
-  bindings, Managed Tasks, an Active Policies summary. Always
-  injected into every flow.
+  bindings, Managed Tasks, an Active Policies summary. Injected as
+  `<management_rules>` on the wide-path flows (DMs, mentions, the
+  morning routine); a few narrow routines (the journal stage, activity
+  scan, today refresh, observer events, scheduled tasks) opt out to
+  save budget.
 - `policies/management-captures/<slug>.md` — one file per durable management rule
   ("from now on, do X"). The daemon auto-maintains a slug index at
   `policies/management-captures/_index.md`.
 
 ## Where You See It in the Dashboard
 
-- **Knowledge → Context Files** lists every file with its size, last
-  modified time, and a preview.
-- **Connections → Knowledge** is where vault integrations (Obsidian,
-  Notion) attach.
+- **Knowledge → Context Files** lists every file with its last
+  modified time and a preview.
+- **Settings → Management Mode** shows where the vault lives (this app
+  or an Obsidian-style directory), relocates it, and surfaces vault
+  health.
+- **Connections → Notes** is where personal note sources (your external
+  Obsidian vault, Notion) attach.
 
 ## Related
 

package/agent-assets/docs/concepts/observations.md

@@ -6,13 +6,13 @@ id: observations
 aliases:
   - observation
   - polling
-  - hourly check
+  - activity scan
   - observation queue
   - phase 9
 category: concepts
 summary: |
   Observations are change records the polling integrations write into
-  SQLite. The hourly check consumes them — there is no per-change
+  SQLite. The activity scan consumes them — there is no per-change
   notification. This pivot was the Phase 9 polling change.
 section: observations
 tags:
@@ -25,16 +25,16 @@ status: stable
 ask_examples:
   - What is an observation?
   - Why doesn't the agent message me on every git commit?
-  - How does the hourly check use observations?
+  - How does the activity scan use observations?
   - Where does the routine pre-pass write observations?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - observation
   - observations
   - polling
-  - hourly check
+  - activity scan
   - phase 9
   - routine.fetch_window
   - pre-pass
@@ -44,7 +44,7 @@ keywords:
   - observation queue
   - dedupe
 related:
-  - features/routines/hourly-check
+  - features/routines/activity-scan
   - features/routines/morning-routine
   - concepts/process-keys
   - concepts/routines
@@ -53,13 +53,14 @@ related:
 ui_anchors:
   - /activity
 process_keys:
-  - routine.hourly_check
+  - routine.activity_scan
   - routine.fetch_window
 config_keys:
-  - hourlyCheckIntervalMinutes
-  - hourlyCheckPrePassFreshnessMinutes
+  - activityScanIntervalMinutes
+  - activityScanPrePassFreshnessMinutes
 api_endpoints:
   - POST /api/observations
+  - POST /api/observations/batch
   - GET /api/observations
   - POST /api/observations/consume
 context_files:
@@ -73,15 +74,15 @@ context_files:
 
 Polling integrations (Obsidian, Git, Notion, Calendar) **do not emit
 events** when they detect changes. They write observation rows to
-SQLite. A single `routine.hourly_check` consumes the queue and decides
+SQLite. A single `routine.activity_scan` consumes the queue and decides
 what is worth surfacing.
 
 Since 2026-05, observations have a **second writer**: every main
 routine (`routine.morning_routine`, `routine.today_refresh`,
-`routine.hourly_check`, `routine.evening_review`,
+`routine.activity_scan`, `routine.evening_review`,
 `routine.weekly_review`) is preceded by a lite-tier
 `routine.fetch_window` pre-pass that fetches mail / calendar / Notion
-windows and POSTs them to `/api/observations`.
+windows and POSTs them to `/api/observations/batch`.
 (`routine.monthly_review` has no pre-pass window.) The main routine
 then reads them via the same `pending=true` queue that the polling
 path feeds. Observation rows look identical regardless of which writer
@@ -105,14 +106,17 @@ tell them apart:
    Mail) call `recordObservation` when they detect a change.
 2. **The pre-pass** — the lite-tier `routine.fetch_window` session
    spawned ahead of each main routine — POSTs mail / calendar / Notion
-   windows to `/api/observations`.
+   windows to `/api/observations/batch`.
 
 Both write rows of the same shape; the consumer reads the merged queue.
 
 - **Observation**: one row in the `observations` table.
-- **Actor**: who caused the change. `actor='agent'` rows are filtered
-  out by the consumer (anti-loop).
-- **Hourly check**: the consumer routine. Medium tier by default
+- **Actor**: who caused the change (`user`, `agent`, or `system`). The
+  activity-scan gate filters pending rows by source, not actor —
+  pre-pass and delegated-sync rows arrive as `actor='agent'` and count
+  as real activity. The anti-loop guard lives at write time instead,
+  via `AgentWriteTracker` (below).
+- **Activity scan**: the consumer routine. Medium tier by default
   (Sonnet); fed by both the background polling path and the pre-pass
   fetcher.
 - **`AgentWriteTracker`**: the daemon component that tags
@@ -123,9 +127,9 @@ Both write rows of the same shape; the consumer reads the merged queue.
   per-routine window (`ROUTINE_WINDOWS` in
   `packages/daemon/src/core/routine-windows.ts`) for each enabled
   mail / calendar / Notion integration and POSTs the results to
-  `/api/observations`. The server computes `contentHash` from
+  `/api/observations/batch`. The server computes `contentHash` from
   `(source, payload)`, so an unchanged item written twice in the same
-  cadence dedupes to a 409.
+  cadence dedupes as a `duplicate` instead of writing a second row.
 
 ## Concrete Examples
 
@@ -135,12 +139,12 @@ Both write rows of the same shape; the consumer reads the merged queue.
 
 ## Where You See It in the Dashboard
 
-- **Activity** logs hourly-check fires; the detail shows how many
+- **Activity** logs activity-scan fires; the detail shows how many
   observations were consumed.
 
 ## Related
 
-- [Hourly Check](../features/routines/hourly-check.md)
+- [Activity Scan](../features/routines/activity-scan.md)
 - [Morning Routine](../features/routines/morning-routine.md)
 - [Process Keys](./process-keys.md)
 - [Routines](./routines.md)

package/agent-assets/docs/concepts/process-keys.md

@@ -10,7 +10,7 @@ aliases:
 category: concepts
 summary: |
   A ProcessKey is the agent's dispatch identity for one kind of work
-  ("morning routine", "DM", "hourly check"). The router resolves it
+  ("morning routine", "DM", "activity scan"). The router resolves it
   to a backend + tier binding; the manifest map resolves it to skills.
 section: process-keys
 tags:
@@ -51,9 +51,9 @@ process_keys:
   - routine.morning_routine_today
   - routine.morning_routine_journal
   - routine.evening_review
-  - routine.hourly_check
+  - routine.activity_scan
   - routine.fetch_window
-  - routine.hourly_check.triage
+  - routine.activity_scan.triage
   - message.dm
   - message.mention
   - dashboard.chat
@@ -95,7 +95,7 @@ those subsystems.
   autonomous.
 - **DEFAULT_PROCESS_TIERS**: the per-key default model size — `lite`
   (Haiku-class), `medium` (Sonnet-class), or `high` (Opus-class).
-  Unknown keys (including `routine.custom.<slug>`) default to `medium`.
+  Unknown keys default to `medium`.
 - **TIER_LOCKED_PROCESS_KEYS**: keys whose tier is hard-locked and
   cannot be overridden by an operator pin. Today this is just
   `dashboard.docs_qa`, locked to `medium`.
@@ -109,17 +109,18 @@ those subsystems.
   — `routine.morning_routine_today` (Stage A, today.md, medium) and
   `routine.morning_routine_journal` (Stage B, daily journal, lite). Also
   `routine.evening_review`, `routine.weekly_review`,
-  `routine.hourly_check`, `routine.roadmap_refresh`,
+  `routine.activity_scan`, `routine.roadmap_refresh`,
   `routine.today_refresh`, `routine.user_profile_sweep`.
   `routine.morning_routine_initial` was retired (2026-05-16) — the
   first-run branch now routes through `routine.morning_routine`.
 - **Routine sub-jobs** (lite tier, dispatcher-spawned, not user-facing):
   `routine.fetch_window` (pre-pass mail/calendar/Notion fetcher that
   runs before each main routine and POSTs observations) and
-  `routine.hourly_check.triage` (Stage 2 escalate-vs-log-only gate
-  inside the hourly check).
-- **Custom routines:** `routine.custom.<slug>` (kebab-case slug;
-  defaults to medium tier).
+  `routine.activity_scan.triage` (Stage 2 escalate-vs-log-only gate
+  inside the activity scan).
+- **Custom routines (retired):** `routine.custom.<slug>` appears only
+  in historical Activity rows — operator-defined recurring work now
+  runs as user Agents under `agent.task`.
 - **Messaging:** `message.dm`, `message.mention`
 - **Dashboard:** `dashboard.chat`, `dashboard.docs_qa`
 - **Scheduled / external:** `agent.task` (recurring schedules),

package/agent-assets/docs/concepts/routines.md

@@ -13,8 +13,8 @@ aliases:
 category: concepts
 summary: |
   Routines are the autonomous, scheduled tasks Aitne runs on
-  its own — morning routine, evening review, hourly check, weekly
-  retro, plus any custom routines you define.
+  its own — morning routine, evening review, activity scan, weekly
+  retro, plus any recurring user Agents you define.
 section: routines
 tags:
   - core
@@ -30,7 +30,7 @@ ask_examples:
   - Which routine uses the high tier by default?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - routine
   - routines
@@ -40,18 +40,18 @@ keywords:
   - routine.fetch_window
   - pre-pass
   - dayBoundaryHour
-  - hourly check
+  - activity scan
 related:
   - features/routines/morning-routine
   - features/routines/evening-review
   - features/routines/weekly-review
-  - features/routines/hourly-check
-  - features/routines/custom-routines
+  - features/routines/activity-scan
+  - guides/add-a-custom-routine
   - concepts/process-keys
   - concepts/observations
 ui_anchors:
-  - /connections/routines
-  - /settings/routines
+  - /agents
+  - /agents/activity-scan
 process_keys:
   - routine.morning_routine
   - routine.morning_routine_today
@@ -59,17 +59,18 @@ process_keys:
   - routine.evening_review
   - routine.weekly_review
   - routine.monthly_review
-  - routine.hourly_check
+  - routine.activity_scan
   - routine.today_refresh
   - routine.fetch_window
-  - routine.hourly_check.triage
+  - routine.activity_scan.triage
 config_keys:
   - dayBoundaryHour
-  - hourlyCheckEnabled
-  - hourlyCheckIntervalMinutes
-  - hourlyCheckActiveStartHour
-  - hourlyCheckActiveEndHour
-  - hourlyCheckPrePassFreshnessMinutes
+  - activityScanEnabled
+  - activityScanIntervalMinutes
+  - activityScanActiveStartHour
+  - activityScanActiveEndHour
+  - activityScanPrePassFreshnessMinutes
+  - activityScanStage2Enabled
   - monthlyReviewEnabled
 ---
 
@@ -81,7 +82,7 @@ A routine is a unit of agent work that runs on a schedule, not in
 response to a message. The morning routine fires once per agent day at
 `dayBoundaryHour`; the evening review (18:00 daily), weekly review
 (Friday 19:00), and optional monthly review fire on fixed schedules in
-code; the hourly check coalesces accumulated observations on a
+code; the activity scan coalesces accumulated observations on a
 configurable cadence.
 
 ## Why This Concept Exists
@@ -92,7 +93,7 @@ up without being asked: it builds today, it logs to the journal, it
 files a retro for the week. They are the proactive surface.
 
 Each routine is a single ProcessKey — `routine.morning_routine`,
-`routine.hourly_check`, `routine.weekly_review`, etc. The dispatcher
+`routine.activity_scan`, `routine.weekly_review`, etc. The dispatcher
 treats them as just another event class; the only difference from a
 DM is who fired the event.
 
@@ -108,10 +109,10 @@ DM is who fired the event.
   review once it is past 18:00; weekly review across Fri–Sun). It never
   double-fires a routine that already succeeded.
 - **Tier policy**: **no routine runs the high tier by default.** Every
-  recurring routine — morning, evening, weekly, hourly check —
+  recurring routine — morning, evening, weekly, activity scan —
   defaults to **medium** (Sonnet on Claude). The **lite** (Haiku) tier
   is reserved for the morning routine's Stage B and for mechanical
-  sub-jobs (the hourly-check triage gate and the pre-pass fetcher). The
+  sub-jobs (the activity-scan triage gate and the pre-pass fetcher). The
   only high-tier ProcessKey in the whole system is `delegated_task_heavy`,
   which is opt-in and not a routine. See
   [Backends and Tiers](backends-and-tiers.md).
@@ -140,26 +141,28 @@ DM is who fired the event.
 | `routine.morning_routine_journal` | Stage B of every morning routine (`journal/daily/<yesterday>.md` authoring) | lite |
 | `routine.evening_review` | 18:00 daily (fixed) | medium |
 | `routine.weekly_review` | Friday 19:00 (fixed, one hour after evening review) | medium |
-| `routine.monthly_review` | Last day of month at 18:00, **default off** (`monthlyReviewEnabled`) | medium |
-| `routine.hourly_check` | Every `hourlyCheckIntervalMinutes` (default 60) inside the active window | medium |
+| `routine.monthly_review` | Last day of month at 18:00, **default off** — opt in by enabling the monthly-review agent at `/agents/monthly-review` | medium |
+| `routine.activity_scan` | Every N interval minutes (default 60) inside the active window — cadence set on `/agents/activity-scan` | medium |
 | `routine.today_refresh` | On calendar drift or a dashboard "refresh today" request (not a fixed cron) | medium |
 | `routine.fetch_window` | Spawned before each routine above that needs fresh upstream data | lite |
-| `routine.hourly_check.triage` | Stage 2 gate of every hourly check | lite |
-| `routine.custom.<slug>` | Operator-defined recurrence | medium (override per routine via `backend_tier`) |
+| `routine.activity_scan.triage` | Stage 2 of the activity-scan gate on low-signal ticks — runs only when `activityScanStage2Enabled` is on (default off; disabled ticks escalate straight to the full check) | lite |
+| `routine.custom.<slug>` | Legacy custom-routine recurrence — custom routines are now user Agents created on `/agents`; existing specs were converted at upgrade | medium |
 
 ## Where You See It in the Dashboard
 
-- **Settings → Routines** is where the hourly check active window
-  (`hourlyCheckActiveStartHour` / `hourlyCheckActiveEndHour`), the
-  hourly check cadence (`hourlyCheckIntervalMinutes`), and any custom
-  routines live. Morning, evening, weekly, and monthly fire times are
-  fixed in code and not surfaced here.
-- **Connections → Routines** is the unified view of next-fire times.
+- **Agents** (`/agents`) is the hub: every routine is an agent card
+  showing its schedule, status, and last run. The activity scan's
+  cadence and active window are edited on `/agents/activity-scan`
+  (Definition tab → Cadence card); each routine's rulebook is edited
+  on its Rulebook tab; custom recurring work is a user agent created
+  from the same page's New Agent dialog. Morning, evening, weekly, and
+  monthly fire times are fixed in code and not editable there.
 - **Activity** logs each routine run with its outcome.
 
 ## Related
 
 - [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)
+- [Custom Routines (Retired)](../features/routines/custom-routines.md)

package/agent-assets/docs/concepts/safety-and-execution.md

@@ -28,7 +28,7 @@ ask_examples:
   - How do I see what tools the agent is allowed to use?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - safety
   - safe mode
@@ -44,7 +44,7 @@ related:
   - features/operations/approvals
   - reference/disallowed-tools
 ui_anchors:
-  - /settings/advanced
+  - /settings/safety
   - /settings/models
 config_keys:
   - disallowedTools
@@ -86,9 +86,12 @@ disallowed-tools floor.
   workspace-write sandbox, the Gemini whitelist TOML, and the OpenCode
   permission block.
 - **Allow mode**: the looser posture. SDK bypass, sandbox off, minimal
-  TOML. The absolute-block layer still holds in Allow mode, so the
-  destructive-ops floor never opens. Set independently per backend, so
-  one backend can run Allow while the others stay Safe.
+  TOML. The absolute-block layer still holds in Allow mode on Claude,
+  Gemini, and OpenCode — Codex is the documented exception: its Allow
+  mode is a binary sandbox-off switch with no hook layer the daemon can
+  attach the block list to, so the dashboard warns you before you flip
+  it. Set independently per backend, so one backend can run Allow while
+  the others stay Safe.
 - **Absolute block**: the unconditional layer. `ALWAYS_DISALLOWED_TOOLS`
   in `src/safety/always-disallowed.ts`. Cannot be widened by skills,
   by config, or by allow-mode.
@@ -120,13 +123,14 @@ absolute-block layer and Approve tier are where the agent is actually stopped.
 
 ## Where You See It in the Dashboard
 
-- **Settings → Advanced** holds the `disallowedTools` and
+- **Settings → Safety** holds the `disallowedTools` and
   `allowedToolsOverride` tool-policy lists.
 - **Settings → Models & Cost** holds the per-backend Safe / Allow
   **Execution Mode** switch (you can also set it in the setup wizard).
 - **Activity** logs every absolute-blocked tool call as
   `action_type='blocked_absolute'`.
-- **Approvals** is where Approve-tier actions queue when they fire.
+- The **Overview** page shows an approval card where Approve-tier
+  actions queue when they fire.
 
 ## Related