@aitne-sh/aitne 0.1.10 → 0.1.11

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. |
 

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

@@ -62,7 +62,7 @@ keywords:
 related:
   - features/integrations/git
   - features/integrations/github
-  - features/routines/hourly-check
+  - features/routines/activity-scan
   - concepts/observations
 ui_anchors:
   - /git
@@ -114,7 +114,7 @@ per repo (all open by default so the controls are visible at a glance):
    require the repository to have a `localPath`.
 3. **Daily git management** — opt-in per repo. Enabling it does three
    distinct kinds of work, on different cadences:
-   - On the first **Run init now** click, writes the curated
+   - On the first **Generate overview** click, writes the curated
      `knowledge/repos/<slug>/overview.md` skeleton, mirrors the source
      `README.*` to `knowledge/repos/<slug>/README.md`, and
      **automatically queues a one-shot Architecture refresh** so the AI
@@ -143,7 +143,7 @@ a Sonnet-class agent that reads the actual code.
 **When it's generated**
 
 - **First time** — automatically queued the moment you click
-  **Run init now**. Returns immediately with `architectureScheduleId`;
+  **Generate overview**. Returns immediately with `architectureScheduleId`;
   the agent runs in the background (typically 30 s – 2 min) and
   replaces the placeholder block with real analysis.
 - **On demand** — click **Refresh architecture** any time. The daemon
@@ -171,7 +171,7 @@ new Architecture body via the chokepoint
 `PUT /api/repositories/:id/architecture-section`; the daemon performs
 the marker-bracketed replacement so other sections (Notable Changes,
 Daily Activity Log, Open Threads) are preserved verbatim. Every write
-also snapshots the previous Architecture body to `md_file_snapshots`
+also snapshots the previous `overview.md` to `md_file_snapshots`
 for recovery.
 
 ## README Mirror
@@ -180,7 +180,7 @@ for recovery.
 the repository's `README.*` (whichever extension exists, with `.md`
 preferred). It is refreshed on:
 
-- Every **Run init now** (initial mirror).
+- Every **Generate overview** click (initial mirror).
 - Every **Refresh architecture** click (so the mirror tracks what the
   agent just analyzed).
 
@@ -197,21 +197,24 @@ README is rewritten.
 ## When It Runs / How It Is Triggered
 
 - **Polling** runs continuously on the per-repo cadence (or the global
-  default). Observations land in the `observations` table; the hourly
-  check coalesces them.
+  default). Observations land in the `observations` table; the activity
+  scan coalesces them.
 - **Triggers** fire when the matching event arrives on the EventBus.
 - **Daily git management** is dispatched by `RepositoryManagementCron`,
   which iterates the `repository_management` table once an hour and
-  emits a `scheduled.task` (`git.project.update`) for any enabled row
-  whose `last_scan_at` is more than 24 hours old.
+  runs the scan writer directly (an in-process daemon write — no agent
+  session) for any enabled row whose `last_scan_at` is more than
+  24 hours old.
 - **Architecture refresh** (`git.project.refresh_architecture`) is
   enqueued only on:
-  - Manual **Run init now** (auto-enqueue, first time only).
+  - **Generate overview** (auto-enqueue — skipped when a previous
+    analysis already landed, re-queued when the Architecture section
+    is still pending).
   - Manual **Refresh architecture** click.
+  - A scan (cron or manual) that finds `overview.md` missing and
+    re-creates the skeleton via the implicit init.
   
-  No cron, no observer fires this. The cron-driven implicit init
-  (when daily scan creates a missing skeleton) deliberately does NOT
-  auto-enqueue.
+  There is no recurring cron that re-runs the analysis on a timer.
 
 ## What It Outputs
 
@@ -231,8 +234,8 @@ trigger's process key.
 
 - **My Life → Git** (`/git`) — this page. Polling, Triggers, and Daily
   git management are all expanded by default. The Daily-git-management
-  panel's buttons appear in lifecycle order — **Run init now → Refresh
-  architecture → Run today's scan now** — and each surfaces an inline
+  panel's buttons appear in lifecycle order — **Generate overview →
+  Refresh architecture → Run today's scan now** — and each surfaces an inline
   green confirmation on success or a red error message on failure.
 - **Connections → Repositories** (`/connections/repositories`) —
   register a repo (link a `localPath` and/or `owner/repo`), rename,
@@ -289,9 +292,10 @@ repository has a `localPath`:
 - **The toggle is greyed out with "No local clone".** Add a
   `localPath` on **Connections → Repositories**, then return.
 - **`Last status` shows `failed` and `Failure streak` keeps climbing.**
-  The cron still iterates but the dispatched session is failing —
-  open the latest conversation under that repo's tile, or check
-  **Activity** for the `git.project.update` run. A high streak does
+  The cron still iterates but the in-process scan writer is failing —
+  check the daemon logs (`aitne logs`) for "Failed to run repository
+  management scan", or click **Run today's scan now** to surface the
+  error inline. A high streak does
   not prevent further scans (the cron retries on the next interval).
 - **`Last scan` is "never" but the row is enabled.** Either the cron
   has not ticked yet (default tick is 1 hour) or the row has no local
@@ -313,7 +317,7 @@ repository has a `localPath`:
   before clicking again.
 - **The README mirror went out of date** after the source repo's
   README was rewritten. Click **Refresh architecture** (which also
-  re-copies the README) or **Run init now** on the repo.
+  re-copies the README) or **Generate overview** on the repo.
 
 ## Related
 
@@ -322,5 +326,5 @@ repository has a `localPath`:
 - [GitHub integration](../integrations/github.md) — remote-side data
   (notifications, workflow runs) reachable via `gh` even without a
   local clone.
-- [Hourly check](../routines/hourly-check.md) — the routine that
+- [Activity scan](../routines/activity-scan.md) — the routine that
   consumes the observations this page's polling generates.

package/agent-assets/docs/features/lifestyle/reading.md

@@ -73,7 +73,7 @@ at `/reading`.
   `completed` stamps `completed_at` automatically; you can also set a 1–5
   `rating` or `notes`.
 - **Recommend** from the list during reactive turns, and refresh the
-  reading-taste profile during weekly and monthly reviews.
+  reading-taste profile during the weekly review.
 
 There is **no bare "add a book" endpoint** — new books arrive through the
 two Kindle import pipelines above (or are created internally during an
@@ -93,8 +93,10 @@ drives the list shape. The reading skill loads in two situations:
 
 - **Reactively**, when you mention a book or highlight in a DM.
 - **From existing routines** — the morning routine can mention what
-  you're currently reading, and the weekly and monthly reviews pull
-  reading progress and refresh the reading-taste profile.
+  you're currently reading, the weekly review refreshes the
+  reading-taste profile, and the monthly review pulls reading progress
+  for its reading report (it reads the existing taste profile but does
+  not re-derive it).
 
 ## What It Outputs