@aitne-sh/aitne 0.1.10 → 0.1.12

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.
 

package/agent-assets/docs/features/integrations/calendar.md

@@ -74,9 +74,10 @@ around them and DM you ahead of meetings that matter.
 
 ## What It Does
 
-- **Polls** the connected calendar(s) on `calendarPollIntervalSeconds`.
+- **Polls** Google Calendar on `calendarPollIntervalSeconds`; Outlook
+  and Apple calendars are read on demand rather than polled.
 - **Records observations** when events change (add / move / remove),
-  consumed by the hourly check.
+  consumed by the activity scan.
 - **Surfaces today's events** to the morning routine so they land in
   `state/today.md` and the day's schedule file.
 - **Reads** events on demand for reactive turns ("am I free at 3?").
@@ -99,18 +100,20 @@ an explicit request.
 
 ## Where in the Dashboard
 
-- **Connections → Calendar** holds OAuth, scope, and polling.
+- **Connections → Calendar** holds OAuth, scope, and the integration
+  mode; the poll interval itself is edited on Settings → Infrastructure.
 - The same page hosts the **Calendar Event Model** card (see below)
-  when Google Calendar is in direct mode.
+  unless Google Calendar runs in delegated mode.
 
 ## Calendar Event Model
 
 The Calendar Event Model picker chooses the backend and model that
 runs when the **daemon-side poller detects a calendar change**. It binds
-the `calendar.change` ProcessKey, which fires in two situations:
+the `calendar.change` ProcessKey. The poller's change detection reacts
+in two situations:
 
 - An event was added, moved, or deleted between polls (recorded as a
-  change observation; the hourly check picks it up).
+  change observation; the activity scan picks it up).
 - An event was created far in advance (long-horizon events more than 14
   days out nudge the roadmap-refresh routine so `plans/roadmap.md` can
   build a preparation timeline).
@@ -127,22 +130,28 @@ different mix.
 
 The picker is **only meaningful when Google Calendar runs in direct
 mode.** In delegated mode the daemon hands off all Google Calendar
-work to the connector inside your agent's backend, so:
+work to the connector inside your agent's backend, so, by default:
 
 - No approaching-event reminders fire from the daemon.
 - No change observations are recorded between polls.
-- The hourly check has no calendar-side observations to react to.
+- The activity scan has no calendar-side observations to react to.
 - Long-horizon roadmap-refresh nudges from calendar do not fire.
 
 The agent only learns about calendar state in delegated mode when it
 asks the connector itself inside a session (for example, while
 running the morning routine). It is a pull-only model — the daemon
-does not push.
+does not push. The exception is **Background Sync** (Settings → Hours
+& Notifications): two opt-in cadences, off by default, poll the
+calendar through the backend's connector while delegated — the
+imminent cadence (next 1 h) restores the 15-minute reminders, and the
+day-ahead cadence (next 24 h) restores change observations and
+far-future roadmap-refresh detection.
 
 To avoid presenting a setting that does nothing, the dashboard hides
 the Calendar Event Model card whenever Google Calendar is delegated.
 If you want approaching-event reminders and change observations back,
-switch the integration mode to direct on the same page.
+switch the integration mode to direct on the same page, or enable the
+calendar Background Sync cadences.
 
 ## Configuration
 
@@ -158,10 +167,12 @@ rather than an env-style setting; the underlying state lives in the
 
 - A **stale calendar** in `/schedule` after a real-world add usually
   means the poll has not yet run. Check the next-fire timestamp.
-- An **OAuth-expired** state reports on the auth-health card.
+- An **OAuth-expired** state reports on the Google card's connection
+  status on Connections → Calendar.
 - **No reminders or change observations** while in delegated mode is
-  expected behavior, not a bug — switch to direct mode to restore the
-  daemon-side flows. See "Calendar Event Model" above.
+  expected behavior, not a bug — switch to direct mode or enable the
+  Background Sync cadences to restore the daemon-side flows. See
+  "Calendar Event Model" above.
 
 ## Related
 

package/agent-assets/docs/features/integrations/git.md

@@ -10,7 +10,7 @@ aliases:
 category: features
 summary: |
   Watch one or more git repositories for new commits. Changes record
-  observations the hourly check coalesces — there is no per-commit
+  observations the activity scan coalesces — there is no per-commit
   notification spam.
 section: integrations
 tags:
@@ -26,7 +26,7 @@ ask_examples:
   - How often does the daemon poll my repos?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - git
   - commit
@@ -35,10 +35,11 @@ keywords:
   - polling
 related:
   - features/integrations/github
-  - features/routines/hourly-check
+  - features/routines/activity-scan
   - concepts/observations
 ui_anchors:
   - /connections/repositories
+  - /git
 config_keys:
   - gitPollIntervalSeconds
 process_keys:
@@ -53,7 +54,7 @@ api_endpoints:
 # Git
 
 Add local git repositories to a watched set; the daemon polls them
-and the hourly check decides whether the recent activity is worth
+and the activity scan decides whether the recent activity is worth
 flagging.
 
 ## What It Does
@@ -71,19 +72,20 @@ by design.
 ## When It Runs / How It Is Triggered
 
 - The poller is continuous.
-- The hourly check consumes the accumulated observations.
+- The activity scan consumes the accumulated observations.
 
 ## What It Outputs
 
 - An `observation` row per detected change set.
-- A summary in the hourly check's output when observations qualified.
+- A summary in the activity scan's output when observations qualified.
 
 ## Where in the Dashboard
 
-- **Connections → Repositories** lists the watched paths and last-poll
-  times. Git repos are managed as part of the unified Repositories
-  surface (the same place that links a local checkout to its GitHub
-  remote).
+- **Connections → Repositories** lists the watched paths. Git repos are
+  managed as part of the unified Repositories surface (the same place
+  that links a local checkout to its GitHub remote).
+- **My Life → Git** (`/git`) configures per-repo polling cadence,
+  automation triggers, and daily git management.
 
 ## Configuration
 
@@ -103,4 +105,4 @@ by design.
 ## Related
 
 - [GitHub](github.md) — separate integration for remote-side data.
-- [Hourly Check](../routines/hourly-check.md) — the consumer.
+- [Activity Scan](../routines/activity-scan.md) — the consumer.

package/agent-assets/docs/features/integrations/github.md

@@ -29,7 +29,7 @@ ask_examples:
   - Where do I add a GitHub repo to watch?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - github
   - issue
@@ -63,7 +63,7 @@ context_files:
 
 The daemon polls GitHub via the local `gh` CLI: review requests, CI
 failures on the default branch, security alerts, and assignments
-become DMs; everything else is recorded for the hourly check.
+become DMs; everything else is recorded for the activity scan.
 
 ## What It Does
 
@@ -77,16 +77,21 @@ become DMs; everything else is recorded for the hourly check.
   to the workflow-runs side; the notifications poll always runs at the
   global cadence.
 - **DMs the user** on the four high-priority triggers below; quieter
-  signals are coalesced into the hourly check summary.
+  signals are coalesced into the activity scan summary.
 
 The agent never auto-comments, auto-merges, or pushes.
 
 ## High-priority events
 
-The agent will DM the user (priority `high`, can break quiet hours
-depending on your notify-skill settings) on:
+The agent will DM the user (priority `high`; during quiet hours the DM
+is deferred until they end rather than dropped — only `critical`
+safety messages break through) on:
 
-- A teammate or bot **requested your review** on a PR.
+- A teammate or bot **requested your review** on a PR — only when it
+  looks time-sensitive (release-blocker keywords in the title, or the
+  repo is already on your `state/today.md` plan or an active roadmap
+  milestone); otherwise it's noted in `state/today.md` and coalesced
+  into the activity scan.
 - You were **assigned** to an issue or PR.
 - A **Dependabot or code-scanning security alert** fired on a watched
   repository.
@@ -144,7 +149,9 @@ Watched repos are no longer config keys. The old `gitRepos` /
 cutover — repos now live in the `repositories` table and are managed on
 **Connections → Repositories**. Per-repo polling cadence is set on
 **My Life → Git** and overrides the global interval for that repo's
-workflow-runs poll.
+workflow-runs poll. The global interval is the floor — a per-repo
+cadence longer than it slows that repo down, while a shorter one
+still polls at the global tick.
 
 ## When Something Goes Wrong
 
@@ -173,24 +180,25 @@ need a daemon-spawned poller's bookkeeping.
 - **direct** — the daemon's `GitHubPoller` runs as described above.
   Use this when you want the daemon to own the poll schedule and to
   emit DMs without the main backend having to wake up.
-- **delegated** — the delegated-sync worker invokes the chosen
-  backend's read-only `gh` CLI surface on opt-in cadences (see
-  [Delegated Mode](../../concepts/delegated-mode.md) and
-  `docs/design/appendices/delegated-sync-opt-in.md`). The daemon
+- **delegated** — a dedicated Git/GitHub cron queues a lite-tier
+  `git.lifecycle.poll` task on the `gitPollIntervalSeconds` cadence
+  (default hourly); that session uses the chosen backend's read-only
+  `gh` CLI surface (see
+  [Delegated Mode](../../concepts/delegated-mode.md)). The daemon
   poller stays off; the lite-tier delegated session takes the polling
   cost.
-- **disabled** — neither the poller nor the delegated worker runs;
+- **disabled** — neither the poller nor the delegated cron runs;
   the integration is silent.
 
 Pick the mode from the GitHub card on **Connections → Repositories**.
 Mode changes go through the standard `PATCH /api/integrations/github`
-flip-lock so the poller and the delegated worker never run
+flip-lock so the poller and the delegated cron never run
 simultaneously.
 
 ## Related
 
 - [Git](git.md) — local repo file watcher (separate observer).
-- [Hourly Check](../routines/hourly-check.md) — the consumer of
+- [Activity Scan](../routines/activity-scan.md) — the consumer of
   non-DM-priority observations.
 - [Delegated Mode](../../concepts/delegated-mode.md) — how the
   `delegated` mode polls without a daemon poller.

package/agent-assets/docs/features/integrations/mail.md

@@ -60,8 +60,8 @@ context_files:
 
 # Mail
 
-Connect one or more mailboxes (Gmail, Outlook, Yahoo, iCloud, or any
-IMAP server) and Aitne polls them, classifies incoming threads, and
+Connect one or more mailboxes (Gmail, Outlook, Yahoo, or iCloud) and
+Aitne polls them, classifies incoming threads, and
 lets the agent search / label / read via the `mail` skill. Search is
 local — backed by SQLite FTS5 — so the agent doesn't need to round-trip
 the provider for every query.
@@ -69,8 +69,8 @@ the provider for every query.
 ## What It Does
 
 - **Read & search** existing threads (FTS5-backed local index).
-- **Classify** incoming messages — does this need owner attention,
-  is it a marketing list, is it a receipt.
+- **Classify** incoming messages — is it a travel booking, a receipt
+  attachment, a Kindle notebook export.
 - **Label** threads so the operator and the agent agree on triage state.
 - **Surface** the small set of mail items in the morning routine that
   actually need owner action.
@@ -81,15 +81,15 @@ yourself. Direct send (`POST /mail/:account/messages/send`) is *not*
 blocked — it is classified as an autonomous action, so the daemon does
 not DM you for approval first. The agent only sends directly when it
 judges you'd clearly want it to, and it tells you afterward; during the
-hourly check the `mail` skill is hard read-only (no sending, drafting,
+activity scan the `mail` skill is hard read-only (no sending, drafting,
 labeling, or filing).
 
 ## When It Runs / How It Is Triggered
 
 - In `direct` mode a poller pulls new messages on a cadence. Gmail uses
-  `gmailPollIntervalSeconds` (default 600); IMAP-backed accounts (Yahoo,
-  iCloud, generic IMAP) use `mailPollIntervalSeconds` (default 180).
-  Adjust both under **Settings → Advanced**.
+  `gmailPollIntervalSeconds` (default 600); all other accounts (Outlook,
+  Yahoo, iCloud) use `mailPollIntervalSeconds` (default 180).
+  The Gmail cadence is adjustable under **Settings → Infrastructure**.
 - The morning routine reads the labeled queue and decides which need
   surfacing.
 - Reactive turns (you DM "what's in my mail?") use the `mail` skill on
@@ -97,17 +97,17 @@ labeling, or filing).
 
 ## Integration Modes
 
-Mail supports all four integration modes
-(`direct | delegated | native | disabled`); each provider may sit in a
-different mode.
+Gmail and Outlook support all four integration modes
+(`direct | delegated | native | disabled`); each may sit in a
+different mode. Yahoo and iCloud have no integration-registry entry —
+they are direct-only by design.
 
 | Provider | Direct | Delegated | Native | Notes |
 |---|---|---|---|---|
-| Gmail | ✓ | ✓ | ✓ (descriptor-driven) | Native mode uses Google's official Gmail MCP connector on the main backend; the connector POSTs observations back via `/api/observations`. |
+| Gmail | ✓ | ✓ | ✓ (descriptor-driven) | Native mode uses the main backend's own Gmail MCP connector (Claude's hosted connector, the Codex apps connector, or Gemini's google-workspace extension); the backend POSTs observations back via `/api/observations`. |
 | Outlook | ✓ | ✓ | ✓ (user-managed) | Native mode requires you to install your own MCP / skill harness on the main backend (`userManagedConnector: true`); the probe synthesises a user-managed result and skips the missing-variant gate. |
-| Yahoo | ✓ | ✓ | — | IMAP transport. No native MCP variant. |
-| iCloud | ✓ | ✓ | — | IMAP transport. No native MCP variant. |
-| Generic IMAP | ✓ | ✓ | — | IMAP transport. No native MCP variant. |
+| Yahoo | ✓ | — | — | IMAP transport. Direct-only; never enters the delegated surface. |
+| iCloud | ✓ | — | — | IMAP transport. Direct-only; never enters the delegated surface. |
 
 Mode flips run through the §14.7 live probe + the per-key
 `runtime_state.integration_flip_lock:<key>`. Changing the main
@@ -120,18 +120,20 @@ mode lifecycle.
 
 - New threads land in the local `mail_messages_index` table
   (FTS-indexed via `fts_mail_messages`).
-- Classification labels are written via the provider API.
+- Labels/tags are written via the provider API when the agent applies
+  them (`POST /mail/:account/messages/:id/tags`).
 - A short "mail" section in `state/today.md` when items qualified.
 
 ## Where in the Dashboard
 
 - **Connections → Mail** is the per-account configuration: providers,
-  credentials, polling, label setup.
+  credentials, per-account active toggles, and the Gmail classification
+  model.
 
 ## Configuration
 
 Per account you choose a provider kind (`gmail` / `outlook` / `yahoo` /
-`icloud`) plus credentials, label conventions, and polling interval. You
+`icloud`) plus credentials and an optional display label. You
 pick the kind, not the transport — Yahoo and iCloud connect over IMAP
 under the hood, but that is an implementation detail. The set of enabled
 providers is `enabledMailProviders` (default `["gmail"]`).
@@ -140,8 +142,8 @@ providers is `enabledMailProviders` (default `["gmail"]`).
 
 - An **auth failure** points at expired credentials. The dashboard's
   auth-health card flips to a warning. See [Auth Failed](../../troubleshooting/auth-failed.md).
-- A **classifier that misses** a sender consistently — add a manual
-  label rule on `/connections/mail`.
+- A **classifier that misses** consistently — switch the model behind
+  it via the Gmail Classification Model card on `/connections/mail`.
 
 ## Related
 

package/agent-assets/docs/features/integrations/notion.md

@@ -8,8 +8,8 @@ aliases:
   - notion integration
 category: features
 summary: |
-  Watch a Notion database (or a curated set of pages) for changes.
-  Changes record observations consumed by the hourly check.
+  Watch one or more configured Notion databases for changes.
+  Changes record observations consumed by the activity scan.
 section: integrations
 tags:
   - integrations
@@ -21,9 +21,10 @@ ask_examples:
   - How do I connect Notion?
   - Will Notion notify me on every page change?
   - What does Notion native mode do?
+  - Why are my Notion routine fetches skipped?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-11
 keywords:
   - notion
   - page
@@ -33,11 +34,11 @@ keywords:
   - integration modes
 related:
   - features/integrations/obsidian
-  - features/routines/hourly-check
+  - features/routines/activity-scan
   - concepts/delegated-mode
   - concepts/observations
 ui_anchors:
-  - /connections/knowledge
+  - /connections/notes
 config_keys:
   - notionPollIntervalSeconds
 api_endpoints:
@@ -47,8 +48,8 @@ api_endpoints:
 
 # Notion
 
-Aitne polls a configured Notion database or page set, records an
-observation on change, and the hourly check decides whether anything
+Aitne polls the configured Notion databases, records an
+observation on change, and the activity scan decides whether anything
 warrants surfacing. The agent can also read pages on demand through
 the `notion` skill.
 
@@ -66,10 +67,10 @@ modes the poller does not run — see Integration Modes below.
 ## Integration Modes
 
 Notion supports all four integration modes (`direct` / `delegated` /
-`native` / `disabled`), selected from **Connections → Knowledge**.
+`native` / `disabled`), selected from **Connections → Notes**.
 
 - **`direct`** — the daemon polls Notion itself, records change
-  observations, and the hourly check consumes them.
+  observations, and the activity scan consumes them.
 - **`delegated`** — a delegated-sync worker runs on opt-in cadences;
   observations are recorded the same way but on a different
   schedule (see [Delegated Mode](../../concepts/delegated-mode.md)).
@@ -86,10 +87,30 @@ Notion supports all four integration modes (`direct` / `delegated` /
 Switching modes requires the integration flip-lock probe to pass
 (connector reachable, capabilities reported). See `POST /api/integrations/notion/probe`.
 
+## Routine Fetch Targets
+
+Autonomous routine fetches (the `routine.fetch_window` pre-pass that
+feeds the morning routine and activity scan) are limited to an explicit
+allowlist of pages you configure under **Connections → Notes →
+Routine fetch targets**. This prevents the agent from searching the
+whole workspace on every pass — workspace-wide scans were the dominant
+cost driver before the allowlist existed.
+
+- Each target is a Notion page URL, page ID, or page title. Prefer a
+  URL or ID; titles are matched best-effort and can be ambiguous.
+- **Until at least one target is listed, routine Notion fetches are
+  skipped entirely** (recorded as a `plan_drop:no_fetch_targets` skip in
+  the activity log). On-demand reads in DMs are unaffected.
+- Routine passes fetch at most 10 targets per window; extra entries are
+  skipped each pass.
+- The allowlist applies in every mode (`direct` / `delegated` /
+  `native`) and survives mode switches and main-backend changes.
+
 ## Where in the Dashboard
 
-- **Connections → Knowledge** holds the integration token, target
-  databases, and the mode picker.
+- **Connections → Notes** holds the integration token, target
+  databases, the routine fetch target allowlist, and the mode picker.
+  The same Notion settings body appears in the setup wizard's Notes step.
 
 ## Configuration
 
@@ -103,6 +124,9 @@ Switching modes requires the integration flip-lock probe to pass
   ≥ 300 seconds.
 - "No observations" in `native` mode is expected — observations flow
   only when the main backend POSTs them during a session.
+- Routine fetches silently absent? Check that **Routine fetch targets**
+  is non-empty — an empty allowlist skips Notion in every routine pass
+  (the activity log shows `plan_drop:no_fetch_targets`).
 
 ## Related
 

package/agent-assets/docs/features/integrations/obsidian.md

@@ -9,7 +9,7 @@ aliases:
 category: features
 summary: |
   Watch an Obsidian vault for new and changed notes. Changes record
-  observations the hourly check consumes; the agent can also read
+  observations the activity scan consumes; the agent can also read
   notes on demand.
 section: integrations
 tags:
@@ -24,7 +24,7 @@ ask_examples:
   - Why didn't the agent see my new note?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-11
 keywords:
   - obsidian
   - vault
@@ -32,10 +32,10 @@ keywords:
   - obsidian observer
 related:
   - features/integrations/notion
-  - features/routines/hourly-check
+  - features/routines/activity-scan
   - concepts/observations
 ui_anchors:
-  - /connections/knowledge
+  - /connections/notes
 config_keys:
   - externalObsidianVaultPath
   - externalObsidianVaultName
@@ -46,7 +46,7 @@ config_keys:
 # Obsidian
 
 Point Aitne at your Obsidian vault directory; new and changed notes
-record observations the hourly check consumes. The agent can read and
+record observations the activity scan consumes. The agent can read and
 write vault notes through the `external-services` skill.
 
 Reads and writes go through the Obsidian app's CLI — the Obsidian app
@@ -72,18 +72,18 @@ its own output.
 Continuously — the watcher runs as long as the daemon is up and a vault
 path is configured (`externalObsidianWatch=true`). Saves are debounced
 by `obsidianDebounceSeconds` before an observation is recorded; the
-[hourly check](../routines/hourly-check.md) later consumes those
+[activity scan](../routines/activity-scan.md) later consumes those
 observations.
 
 ## Where in the Dashboard
 
-- **Connections → Knowledge** to point at the vault directory.
+- **Connections → Notes** to point at the vault directory.
 
 ## Configuration
 
 | Setting | Default | Notes |
 |---|---|---|
-| `externalObsidianVaultPath` | unset | Vault directory; set in Connections → Knowledge. |
+| `externalObsidianVaultPath` | unset | Vault directory; set in Connections → Notes. |
 | `externalObsidianWatch` | true | Set false to keep the path but stop recording changes (large-vault churn control). |
 | `obsidianDebounceSeconds` | 5 | How long to wait after a save before recording. |