@aitne-sh/aitne 0.1.9 → 0.1.11

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

@@ -34,7 +34,7 @@ ask_examples:
   - Where do I see what the agent has been doing?
 locale: en-US
 created: 2026-04-26
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - deniedTools
   - safety floor
@@ -74,8 +74,8 @@ The risk classifier has two write tiers, not three:
   delete event, …) and for normal context writes.
 - **Approve** — agent must present a Bearer token issued through the
   dashboard. Reserved for posture-changing daemon configuration:
-  flipping integration modes, swapping the main backend, deleting
-  backends, wiping config.
+  flipping integration modes, swapping the main backend, enabling/
+  disabling backends, wiping config.
 - (`ReadSensitive` is the third tier, but it gates *reads* of personal
   data — orthogonal to write notifications. It is unchanged.)
 
@@ -134,27 +134,30 @@ of "report to me" events. Information about what the agent did is
   `deniedTools` server-side — see the *Where the Defenses Apply* table
   below for the exact mechanism.
 - **`agent_actions`** — SQLite table of every agent action. Direct +
-  cross-backend rows are full-fidelity (current cross-backend writes
+  cross-backend rows are full-fidelity (cross-backend task-mode writes
   emit `delegated_task.run` / `delegated_task.exec` /
-  `delegated_task.tool_step`; legacy rows from before 2026-05-01 carry
-  `delegated_proxy.invoke`). Same-backend native MCP rolls up to
+  `delegated_task.tool_step`; the `delegated_proxy.invoke` row type
+  carries both legacy rows from the retired RPC `/invoke` route and
+  the hourly drift-detection probes still written by the
+  delegated-sync worker). Same-backend native MCP rolls up to
   `mcp_tool_calls` + the parent session row.
 
 ## Where the Defenses Apply
 
 | Path | Enforcement |
 |---|---|
-| Direct mode (`/api/mail/*`, `/api/calendar/*`) | Route handler middleware checks `deniedTools` against the materialized skill body's `allowed-tools` list (frontmatter). |
+| Direct mode (`/api/mail/*`, `/api/calendar/*`) | `deniedTools` is **inert** — the daemon runs the poller and the agent calls the daemon API through its direct-mode skill, so there is no per-tool deny surface. The list only persists for a future flip to delegated mode. Direct-mode safety comes from the route-level risk tiers (Approve gates posture-changing writes) and the always-disallowed layer, not `deniedTools`. |
 | Cross-backend (`/api/integrations/:key/exec`) | Invoker filters the integration's `capabilityTools` through `deniedTools` before spawning the delegated backend so the task-mode planner can only pick from the allowed surface. A fully-denied surface short-circuits with `errorClass: "denied_tool"`; individual tool denials surface as the same error from the invoker's `resolveAllowedToolPatterns`. |
 | Same-backend / native MCP — Claude | `collectSessionDeniedTools` merges the deny patterns into the SDK's `disallowedTools` array at `query()` time. Same code path covers both delegated same-backend and native — they share the in-session MCP surface. |
-| Same-backend / native MCP — Gemini | Patterns are folded into `generateAdminPolicy`'s TOML deny rules (priority 1000). |
+| Same-backend / native MCP — Gemini | Patterns are folded into `generateAdminPolicy`'s TOML deny rules (priority 936 — above the registry-driven native allows, below the absolute-block layer). |
 | Same-backend / native MCP — Codex | **Prose-only.** Codex bundles its connector apps into the binary; there is no per-tool deny config and the workspace-write sandbox does not match MCP tool calls. Skill prose lists the denied tools explicitly. Operators who require strict deny on Gmail / Calendar should pick a non-Codex DM backend or route those integrations through `delegated` cross-backend mode (which IS deny-enforced at `/exec`). |
 
 ## 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._*`):
 
@@ -170,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 |
 |---|---|
@@ -212,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
@@ -224,7 +236,7 @@ When the operator asks "what did you do yesterday?" / "have you sent
 anything from Gmail this week?" the agent calls:
 
 ```bash
-curl 'http://localhost:8321/api/agent/actions?since=2026-04-25T00:00:00Z&kind=delegated_task.run&kind=delegated_task.tool_step&limit=50'
+curl 'http://localhost:8321/api/agent/actions?since=2026-04-25T00:00:00Z&kind=delegated_task.exec&kind=delegated_task.tool_step&limit=50'
 ```
 
 and answers in conversation. The endpoint:
@@ -237,16 +249,17 @@ 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.
-
-Common `kind` values for the cross-backend proxy: `delegated_task.run`
-(one row per `/exec` call), `delegated_task.exec` (the planner's
-chosen tool), `delegated_task.tool_step` (each individual tool call
-inside the task). The legacy `delegated_proxy.invoke` rows persist
-from before 2026-05-01 — include them if the `since` window crosses
-that date.
+  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
+per generic `/run` call), `delegated_task.tool_step` (each individual
+tool call inside the task). The `delegated_proxy.invoke` rows cover the
+retired RPC `/invoke` route plus the delegated-sync worker's hourly
+drift-detection probes — include them when you want that surface too.
 
 This **replaces** the rejected daily-digest pattern. Reasons:
 
@@ -269,7 +282,8 @@ Approve still gates:
 
 - `PATCH /api/integrations/:key` — mode / `delegatedBackend` /
   `deniedTools` changes.
-- `PUT /api/backends/main`, `DELETE /api/backends/:id`.
+- `PUT /api/backends/main`, `POST /api/backends/:id/enable`,
+  `POST /api/backends/:id/disable`.
 - `PATCH /api/config` for fields that wipe protections.
 - `/api/system/*` — config reset, history purge, factory reset.
 

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

@@ -28,7 +28,7 @@ ask_examples:
   - Where do skill overlays live?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - SKILL.md
   - allowed-tools
@@ -74,7 +74,7 @@ The agent runs against a real machine. Without scoped permissions, a
 "please summarize my mail" turn could in principle invoke `Bash(rm)`,
 post to your social accounts, or rewrite arbitrary files. Skills fix
 that by making the available toolset task-shaped: the morning routine
-loads the routines/observations/today/schedule skills; a docs question
+loads the context/today/observations/schedule skills; a docs question
 loads only `docs-search`. Tools outside the allow-list aren't even
 visible to the model.
 
@@ -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

@@ -12,9 +12,10 @@ aliases:
 category: features
 summary: |
   Local-only poller that reads the browser's own SQLite databases
-  (Chrome / Safari / Firefox / Arc), records visits as observations,
-  derives research clusters from sustained reading patterns, and
-  surfaces what you keep refreshing. Nothing leaves the daemon.
+  (Chrome / Chromium / Edge / Brave / Comet / Atlas), records visits as
+  observations, derives research clusters from sustained reading
+  patterns, and surfaces what you keep refreshing. Nothing leaves the
+  daemon.
 section: integrations
 tags:
   - integrations
@@ -31,7 +32,7 @@ ask_examples:
   - How do I opt out of browser history?
 locale: en-US
 created: 2026-05-22
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - browser history
   - browser history poller
@@ -74,9 +75,9 @@ api_endpoints:
 
 # Browser History
 
-Aitne can read the SQLite history databases that Chrome, Safari,
-Firefox, and Arc already maintain on disk, classify visits into
-categories, and use the result to notice what you've been
+Aitne can read the SQLite history databases that Chrome, Chromium,
+Edge, Brave, Comet, and Atlas already maintain on disk, classify visits
+into categories, and use the result to notice what you've been
 researching, what you've been refreshing, and what comparison-shopping
 windows you're in. Everything stays local — no URLs, titles, or
 clicks leave the daemon.
@@ -105,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
 
@@ -119,10 +120,10 @@ 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 / docs / media / …) get
+  visit categories (research / shopping / news / dev / entertainment / …) get
   ingested. Categories you exclude are dropped at ingest time, not
   filtered later.
 - **Retention.** `browserHistoryRetentionDays` (visits) and
@@ -135,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.
 
@@ -170,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
 
@@ -179,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

@@ -33,7 +33,7 @@ ask_examples:
   - Which model handles detected calendar changes?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - calendar
   - google calendar
@@ -68,15 +68,16 @@ process_keys:
 
 # Calendar
 
-Aitne pulls events from one or more calendars (Google Calendar today,
-more backends planned) so it can build today's plan around them and
-DM you ahead of meetings that matter.
+Aitne pulls events from one or more calendars (Google Calendar,
+Outlook Calendar, and Apple Calendar) so it can build today's plan
+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.