@aitne-sh/aitne 0.1.10 → 0.1.11

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

@@ -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.
@@ -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-06-07
+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
@@ -155,8 +156,8 @@ curl -X PATCH http://localhost:8321/api/context/state/today.md \
 - `policies/management.md` — the umbrella registry: Source-of-Truth
   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, hourly
-  check, today refresh, observer events, scheduled tasks) opt out to
+  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
@@ -164,10 +165,13 @@ curl -X PATCH http://localhost:8321/api/context/state/today.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
 

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

@@ -155,8 +155,9 @@ of "report to me" events. Information about what the agent did is
 ## Recommended Starter Denylists
 
 The setup wizard pre-populates these on first delegated setup. The
-operator can keep them, edit, or explicitly opt for an empty list (a
-confirmation modal explains the trade-off).
+operator can keep them, edit, or explicitly opt for an empty list by
+saving `deniedTools: []` (the safety-floor guidance rendered above the
+deny-list editor explains the trade-off).
 
 **Gmail × Codex** (Codex's `mcp__codex_apps__gmail._*`):
 
@@ -172,10 +173,19 @@ delete / archive surface):
 
 | Tool | Why deny by default |
 |---|---|
-| `label_message` | The only mutating tool the connector exposes |
+| `label_message` | Label mutations are the connector's only state-changing surface; the starter denies 2 of the 5 `label` tools, keeping the capability satisfiable |
 | `label_thread` | Same |
 
-**Google Calendar** (Codex + Claude):
+**Gmail × Gemini** (the google-workspace connector; `sendDraft` and the
+`modify` / `modifyThread` label tools stay available):
+
+| Tool | Why deny by default |
+|---|---|
+| `send` | Compose-and-send in one call — strictly destructive |
+| `batchModify` | The mass-mutation path; same rationale as Codex's `apply_labels_to_emails` |
+
+**Google Calendar** (Codex + Claude; Gemini denies the same two
+operations under its camelCase names `deleteEvent` / `updateEvent`):
 
 | Tool | Why deny by default |
 |---|---|
@@ -214,7 +224,7 @@ against the connector's `capabilityTools` set so typos fail fast.
 The starter floor re-fires not just on first-delegated setup but also
 on `delegatedBackend` swap (e.g. claude → codex) when the previous
 deny list is namespace-stale on the new backend and the operator
-hadn't already chosen an empty list. The audit row carries
+hadn't already chosen an empty list. The daemon log entry carries
 `trigger="backend_swap_stale"` to distinguish from
 `trigger="first_delegated"`. Operators who explicitly set
 `deniedTools: []` before the swap are honored — the swap clause does
@@ -239,9 +249,10 @@ and answers in conversation. The endpoint:
 - Redacts the free-text `error` / `detail` fields via the standard
   secret-redaction utility before serializing.
 - Returns rows from `agent_actions` only. Same-backend / native MCP
-  calls surface as their own `action_type` rows (e.g. `kind=mcp`);
-  the per-call detail lives in `mcp_tool_calls`, which this endpoint
-  does not join — query it separately if you need step-level fidelity.
+  calls do not get their own rows — they roll up under the parent
+  session row, and the per-call detail lives in `mcp_tool_calls`,
+  which this endpoint does not join — query it separately if you need
+  step-level fidelity.
 
 Common `kind` values for the cross-backend proxy: `delegated_task.exec`
 (one header row per `/exec` call), `delegated_task.run` (one header row

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

@@ -100,7 +100,8 @@ visible to the model.
 ## Concrete Examples
 
 - `today` — read and rewrite `state/today.md`.
-- `schedule` — produce per-date schedule files from the calendar.
+- `schedule` — register future wake-ups, reminders, and recurring
+  tasks via `/api/schedule`.
 - `mail` — search and label messages via the daemon's mail proxy.
 - `docs-search` — read-only fetch over the docs corpus, used only by
   `dashboard.docs_qa`.
@@ -124,11 +125,12 @@ seed payload immediately.
 The optimizer agent runs in an isolated workdir with a tightly
 scoped toolset (`Bash(curl http://localhost:8321/api/skill-curation/*)`,
 `Read`) and an auto-revert safety net: each cadence cycle the daemon
-re-checks recently-applied overlays, and any section that has
-accumulated *more* drift signal weight after the overlay was applied
-than before is rolled back automatically and frozen for two cycles to
-stop thrashing. This is the only roll-back path — there is no
-per-proposal approve/reject API, just the on/off toggle.
+re-checks recently-applied overlays, and any section that keeps
+accumulating drift signal weight after the overlay was applied
+(crossing a fixed regression threshold) is rolled back automatically
+and frozen for two cycles to stop thrashing. This is the only
+roll-back path — there is no per-proposal approve/reject API, just
+the on/off toggle.
 
 Skill curation is **off by default**. The master toggle, curation
 cadence, manual-run trigger, and the per-skill exclusion list are all
@@ -136,8 +138,8 @@ surfaced at **Settings → Self-learning** (`/settings/self-learning`).
 
 ## Where You See It in the Dashboard
 
-- **Knowledge → Skills** lists every skill, its description, and the
-  events it loads for.
+- **Knowledge → Skills** lists every skill, its description, and its
+  `allowed-tools`.
 - **Connections → MCP** is where MCP servers (which surface as tools
   inside skills) attach.
 - **Settings → Self-learning (`/settings/self-learning`)** is where

package/agent-assets/docs/features/integrations/browser-history.md

@@ -106,7 +106,7 @@ clicks leave the daemon.
   containing ≥3 distinct ASINs surface as comparison sessions the
   agent can summarise.
 - **Powers the pre-morning digest** — yesterday's reading and reload
-  patterns feed the morning routine's pre-pass digest.
+  patterns feed the digest the morning routine reads.
 
 ## Privacy and Consent
 
@@ -120,8 +120,8 @@ clicks leave the daemon.
   history file is opened read-only; the daemon never reaches into
   cookies, login sessions, or profile dirs other than the history DB.
 - **Per-browser opt-in.** `browserHistoryBrowserOverrides` lets you
-  enable / disable each detected browser independently and override
-  the DB path for atypical installs.
+  force each detected browser on or off independently
+  (`auto` / `forced-on` / `forced-off`).
 - **Per-category gate.** `browserHistoryCategories` controls which
   visit categories (research / shopping / news / dev / entertainment / …) get
   ingested. Categories you exclude are dropped at ingest time, not
@@ -136,11 +136,13 @@ clicks leave the daemon.
 
 A research cluster qualifies when the combination of meaningful visits,
 foreground time, and distinct domains crosses the thresholds in
-`DEFAULT_OFFER_THRESHOLDS` (tunable via `browserHistoryLifecycle`).
+`DEFAULT_OFFER_THRESHOLDS` (fixed defaults — `browserHistoryLifecycle`
+tunes the poller's check cadence, not these thresholds).
 On each tick the poller evaluates the offer triggers per active cluster
-(`evaluateOfferTriggers`); once the **per-cluster offer rate-limit gate**
-(`gateOfferRateLimit`) approves — this is the 14-day, per-slug offer
-backoff, not the daemon-wide session gate that Phase 9 removed — a
+(`evaluateOfferTriggers`) — this is where the 14-day, per-slug offer
+re-fire window lives — and the **offer rate-limit gate**
+(`gateOfferRateLimit`: daily offer cap, minimum gap between offers,
+quiet hours, and a 30-day decline backoff) must also approve before a
 Two-Option Offer DM is composed by the `routine.research_offer_dm`
 process key.
 
@@ -171,7 +173,7 @@ later tick cannot re-offer the same cluster.
 | Shopping-comparison window scan | Same tick, 7-day lookback | `SHOPPING_COMPARISON_WINDOW_MS` constants |
 | Nightly journal append | Agent-day boundary | `routine.research_cluster_update` (lite tier, one row per active cluster per day) |
 | Weekly reload-memory block | Friday weekly review | `routine.weekly_review` reads `/api/browser-history/reloads/weekly` |
-| Pre-morning digest | Morning routine pre-pass | Yesterday's reading + reloads feed the digest block |
+| Pre-morning digest | Daily, one hour before the agent-day boundary | Yesterday's reading + reloads feed the digest block |
 
 ## When Something Goes Wrong
 
@@ -180,8 +182,10 @@ later tick cannot re-offer the same cluster.
   platform detector might be failing to resolve the user's profile dir.
   The daemon log line will name the candidate paths it tried.
 - **A cluster keeps re-offering.** Check the `lastResearchOfferAt` /
-  `lastWikiOfferAt` columns; the rate-limit gate uses those for the
-  14-day backoff. `!research decline <slug>` stamps both fields.
+  `lastWikiOfferAt` columns; the trigger evaluator uses those for the
+  14-day re-fire window (the rate-limit gate also reads them for its
+  30-day decline backoff). `!research decline <slug>` stamps both
+  fields.
 - **`!checks` is empty.** That's the common case for a quiet day —
   the reload signals are gated to the agent-day, not UTC.