@aitne-sh/aitne 0.1.7 → 0.1.9

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

@@ -12,19 +12,20 @@ aliases:
   - on-demand retrospective
 category: concepts
 summary: |
-  Aitne's safety model collapsed from four tiers to two: most
-  actions run autonomously, a small set of posture-changing operations
-  require explicit Approve. The previous Notify tier (DM the operator
-  before / during a write) was abolished — the operator's `deniedTools`
-  list is now the primary defense, and "what did the agent do?" is
-  answered on demand via `GET /api/agent/actions` instead of pushed as
-  a daily digest.
+  Aitne's risk classifier dropped from three write tiers to two: most
+  actions run autonomously, and a small set of posture-changing
+  operations require explicit Approve. The previous Notify tier (DM the
+  operator before / during a write) was abolished — the operator's
+  `deniedTools` list is now the primary defense, and "what did the
+  agent do?" is answered on demand via `GET /api/agent/actions` instead
+  of pushed as a daily digest. (The read-gating `ReadSensitive` tier is
+  unchanged.)
 section: safety
 tags:
   - core
   - safety
   - integrations
-  - skills
+  - audit
 status: stable
 ask_examples:
   - Why doesn't the agent ask before sending an email anymore?
@@ -33,7 +34,7 @@ ask_examples:
   - Where do I see what the agent has been doing?
 locale: en-US
 created: 2026-04-26
-updated: 2026-04-26
+updated: 2026-05-28
 keywords:
   - deniedTools
   - safety floor
@@ -50,10 +51,16 @@ related:
   - reference/disallowed-tools
 ui_anchors:
   - /connections
-  - /settings/cost
-config_keys:
-  - integrations
-  - deniedTools
+  - /connections/mail
+  - /connections/calendar
+  - /analytics
+api_endpoints:
+  - GET /api/agent/actions
+  - POST /api/integrations/:key/exec
+  - PATCH /api/integrations/:key
+context_files:
+  - policies/integrations.md
+  - journal/agent.md
 ---
 
 # Safety Model (deniedTools + Approve Tier)
@@ -121,21 +128,27 @@ of "report to me" events. Information about what the agent did is
 - **`matchToolPattern`** — pattern matcher used everywhere `deniedTools`
   is enforced. Exact match (`send_email`), prefix glob (`send_*`), or
   bare `*`.
-- **`/api/integrations/:key/invoke`** — the cross-backend chokepoint.
-  Enforces `deniedTools` server-side before spawning a subprocess.
+- **`/api/integrations/:key/exec`** — the cross-backend chokepoint
+  (task mode; the RPC-style `/invoke` route was retired 2026-05-01,
+  see `docs/design/17-delegated-mode-v2.md` §4.2). It enforces
+  `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. Same-backend native MCP rolls
-  up to `mcp_tool_calls` + the parent session row.
+  cross-backend rows are full-fidelity (current cross-backend 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
+  `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). |
-| Cross-backend (`/api/integrations/:key/invoke`) | Endpoint handler runs `matchToolPattern(deniedPattern, tool)` before spawning. Returns `403 denied_tool` on hit. |
-| Same-backend native MCP — Claude | `collectSessionDeniedTools` merges the deny patterns into the SDK's `disallowedTools` array at `query()` time. |
-| Same-backend native MCP — Gemini | Patterns are folded into `generateAdminPolicy`'s TOML deny rules (priority 1000). |
-| 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 run those integrations through the proxy. |
+| 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 — 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
 
@@ -211,18 +224,29 @@ 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_proxy.invoke&limit=50'
+curl 'http://localhost:8321/api/agent/actions?since=2026-04-25T00:00:00Z&kind=delegated_task.run&kind=delegated_task.tool_step&limit=50'
 ```
 
 and answers in conversation. The endpoint:
 
 - Lives at `Autonomous` tier — the agent reads only its own audit
   trail, no operator data.
-- Accepts `since`, `kind`, `limit` (default 50, max 200).
-- Redacts values via the standard secret-redaction utility before
-  serializing.
-- Returns rows from `agent_actions`, optionally joined with
-  `mcp_tool_calls` when `kind=mcp` (same-backend native MCP).
+- Accepts `since` (ISO-8601; defaults to the last 24h if omitted),
+  `kind` (an `action_type` filter — repeat for multiple values, e.g.
+  `?kind=a&kind=b`), and `limit` (default 50, max 200).
+- 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.
 
 This **replaces** the rejected daily-digest pattern. Reasons:
 
@@ -231,7 +255,7 @@ This **replaces** the rejected daily-digest pattern. Reasons:
 - The operator does not have to manage the agent's reporting calendar.
 
 The optional fallback — extending the existing morning routine to
-summarize yesterday's `agent_actions` into `agent/journal.md` — is
+summarize yesterday's `agent_actions` into `journal/agent.md` — is
 deferred until the on-demand path proves insufficient.
 
 ## What Stayed Approve-Tier
@@ -251,15 +275,16 @@ Approve still gates:
 
 ## Where You See It in the Dashboard
 
-- **Connections → \<integration\> → Tool Permissions** — the
+- **Connections → \<integration\> → Tool Permissions**
+  (e.g. `/connections/mail`, `/connections/calendar`) — the
   `deniedTools` editor with the starter list pre-populated. Above the
-  editor, the safety guidance prose explains each entry and which the
-  team recommends keeping.
-- **Settings → Cost → Delegated proxy facet** — only cross-backend
-  invocations show here; same-backend rolls up under the parent
-  session.
-- **Activity / Audit** — every action with full attribution, queried
-  the same way the agent queries `GET /api/agent/actions`.
+  editor, the safety guidance prose explains each entry and which ones
+  are recommended to keep.
+- **Analytics** (`/analytics`) — spend and the delegated-task facet;
+  only cross-backend invocations show here, while same-backend MCP
+  rolls up under the parent session.
+- **Activity** (`/activity`) — every action with full attribution,
+  the same audit trail the agent reads via `GET /api/agent/actions`.
 
 ## Related
 
@@ -270,5 +295,5 @@ Approve still gates:
   Allow modes.
 - Integration Delegation Framework (design) — `docs/design/14-integration-delegation.md`
   §14.12, the deniedTools spec.
-- Delegated Mode v2 (design) — `DELEGATED-MODE-V2-DESIGN.md` §4.5,
+- Delegated Mode v2 (design) — `docs/design/17-delegated-mode-v2.md` §4.5,
   the rationale for Notify-tier abolition + the starter denylist.

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

@@ -17,14 +17,18 @@ tags:
   - core
   - skills
   - safety
+  - knowledge
+  - backends
 status: stable
 ask_examples:
   - What skills does the agent have?
   - How do I add a new skill?
   - Why does the agent refuse to run a tool?
+  - How does skill self-optimization work?
+  - Where do skill overlays live?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-04
+updated: 2026-05-28
 keywords:
   - SKILL.md
   - allowed-tools
@@ -33,15 +37,25 @@ keywords:
   - self-optimization
   - skill curation
   - overlays
+  - skill
+  - skills
 related:
   - concepts/safety-and-execution
   - concepts/process-keys
   - reference/skills
-  - features/operations/skill-self-optimization
 ui_anchors:
   - /knowledge
   - /connections/mcp
   - /settings/self-learning
+process_keys:
+  - dashboard.docs_qa
+  - routine.skill_curation
+config_keys:
+  - allowedToolsOverride
+  - disallowedTools
+api_endpoints:
+  - GET /api/skills
+  - GET /api/skills/manifest/:processKey
 ---
 
 # Skills
@@ -68,8 +82,11 @@ visible to the model.
 
 - **SKILL.md**: the Markdown file that defines a single skill. Lives
   under `agent-assets/skills/<slug>/SKILL.md` in the repo and is
-  materialized into each session workdir as `.claude/skills/<slug>/SKILL.md`
-  (or the per-backend equivalent).
+  materialized into each session workdir under a per-backend namespace —
+  `.claude/skills/<slug>/` for Claude, `.codex/skills/` for Codex,
+  `.gemini/skills/` for Gemini, and `.opencode/skills/` for OpenCode.
+  The frontmatter (`name`, `description`, `allowed-tools`) is byte-identical
+  across all four; only the destination directory changes.
 - **`allowed-tools`**: a YAML list in the skill's frontmatter naming
   tools and patterns the session may use. Patterns like
   `Bash(curl http://localhost:8321/api/context/*)` are the daemon's
@@ -82,7 +99,7 @@ visible to the model.
 
 ## Concrete Examples
 
-- `today` — read and rewrite `today.md`.
+- `today` — read and rewrite `state/today.md`.
 - `schedule` — produce per-date schedule files from the calendar.
 - `mail` — search and label messages via the daemon's mail proxy.
 - `docs-search` — read-only fetch over the docs corpus, used only by
@@ -93,25 +110,29 @@ visible to the model.
 
 Skills aren't frozen. A background process — **skill curation** —
 watches how your knowledge layout drifts (file moves, new
-sub-folders, schema tweaks in `user/`, `projects/`, etc.) and
-proposes JSON **overlays** that update specific sections of the
+sub-folders, schema tweaks under `identity/`, `plans/projects/`, etc.)
+and proposes JSON **overlays** that update specific sections of the
 relevant skill: knowledge layout, routing tables, frontmatter
 schema, search recipes, convention notes, cross-references.
 
-Overlays live at `<dataDir>/overlays/<skill>/<section-id>.json` and
-are merged in by the SkillsCompiler at session-init. The original
+Overlays live at `<dataDir>/skill-curation-overlays/<slug>/<section_id>.json`
+and are merged in by the SkillsCompiler at session-init. The original
 `SKILL.md` files in `agent-assets/skills/` are never rewritten;
-disabling the overlay (or deleting the JSON file) reverts to the
+disabling self-learning (or deleting the JSON file) reverts to the
 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 — if the next run sees more
-drift signals than the previous overlay generated, the section is
-reverted and frozen for two cycles.
+`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.
 
-See [Skill Self-Optimization](../features/operations/skill-self-optimization.md)
-for cadence, manual run, and the dashboard surface.
+Skill curation is **off by default**. The master toggle, curation
+cadence, manual-run trigger, and the per-skill exclusion list are all
+surfaced at **Settings → Self-learning** (`/settings/self-learning`).
 
 ## Where You See It in the Dashboard
 
@@ -131,5 +152,5 @@ for cadence, manual run, and the dashboard surface.
   `allowed-tools` is too permissive.
 - [Process Keys](process-keys.md) — the dispatch identity that picks
   which skill manifest to load.
-- [Skill Self-Optimization](../features/operations/skill-self-optimization.md) —
-  how overlays are generated and applied.
+- [Skills (Reference)](../reference/skills.md) — index of every
+  built-in skill.

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

@@ -0,0 +1,195 @@
+---
+schema_version: 1
+slug: features/integrations/browser-history
+title: Browser History
+id: browser-history
+aliases:
+  - browser history
+  - browsing history
+  - research clusters
+  - reload memory
+  - B-3
+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.
+section: integrations
+tags:
+  - integrations
+  - observations
+  - browser-history
+  - polling
+  - autonomous
+status: stable
+ask_examples:
+  - How does Aitne use my browser history?
+  - What is a research cluster?
+  - What does `!checks` show?
+  - Does my browsing data go anywhere?
+  - How do I opt out of browser history?
+locale: en-US
+created: 2026-05-22
+updated: 2026-05-28
+keywords:
+  - browser history
+  - browser history poller
+  - research cluster
+  - reload signal
+  - "!checks"
+  - "!research"
+  - shopping comparison
+  - two-option offer
+  - local-only
+related:
+  - features/messaging/bang-commands
+  - features/integrations/notion
+  - features/operations/managed-chromium
+  - features/routines/weekly-review
+  - features/routines/morning-routine
+ui_anchors:
+  - /settings/integrations/browser-history
+config_keys:
+  - browserHistoryConsentAccepted
+  - browserHistoryBrowserOverrides
+  - browserHistoryCategories
+  - browserHistoryRetentionDays
+  - browserHistorySearchQueryRetentionDays
+  - browserHistoryLifecycle
+  - browserHistoryResearchDomainAllowlist
+  - browserHistoryResearchDomainDenylist
+process_keys:
+  - routine.research_cluster_update
+  - routine.research_offer_dm
+  - routine.research_dispatch
+  - routine.research_wiki_summary
+api_endpoints:
+  - GET /api/browser-history/status
+  - GET /api/browser-history/research-clusters
+  - POST /api/browser-history/offers/:slug/accept
+  - POST /api/browser-history/offers/:slug/decline
+  - GET /api/browser-history/reloads/weekly
+---
+
+# 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
+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.
+
+## What It Does
+
+- **Reads visits** from the browser's own history DB on a 30-min
+  cadence (per browser, per profile) and inserts them into the
+  daemon's `browser_visits` table.
+- **Counts reloads** per `<domain>/<first-path>` into
+  `browser_reload_signals`. Surfaced via [`!checks`](../messaging/bang-commands.md)
+  for the agent-day and via the weekly review's "this week you
+  checked" block.
+- **Derives research clusters** when a topic crosses meaningful-visits
+  / foreground-time / distinct-domain thresholds. Clusters live in
+  `browser_research_clusters` with a slug, display name, journal at
+  `context/research/<slug>.md`, and a status (`active | dormant |
+  muted | concluded`).
+- **Offers engagement DMs** via the Two-Option Offer pattern when a
+  cluster qualifies: pick "research dive" (parallel web research +
+  summary) or "wiki summary" (Obsidian / Notion / local context).
+  Accept paths run through `routine.research_dispatch` /
+  `routine.research_wiki_summary`; decline silences offers for 14
+  days; mute / unmute / rename / conclude via [`!research`](../messaging/bang-commands.md).
+- **Detects shopping comparison windows** — 90-min sliding windows
+  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.
+
+## Privacy and Consent
+
+- **Default off.** The integration does not start until the operator
+  flips `browserHistoryConsentAccepted = true` on the
+  **Settings → Integrations → Browser History**
+  (`/settings/integrations/browser-history`) page. The integration only
+  supports `direct` (the daemon poller) or `disabled` — there is no
+  delegated or native mode.
+- **Local-only.** No request leaves the daemon. The browser's
+  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.
+- **Per-category gate.** `browserHistoryCategories` controls which
+  visit categories (research / shopping / docs / media / …) get
+  ingested. Categories you exclude are dropped at ingest time, not
+  filtered later.
+- **Retention.** `browserHistoryRetentionDays` (visits) and
+  `browserHistorySearchQueryRetentionDays` (search queries) cap the
+  on-disk window; older rows are deleted on the next ingest tick.
+- **Domain controls.** `browserHistoryResearchDomainAllowlist` /
+  `…Denylist` filter which domains can qualify a research cluster.
+
+## How Clusters Qualify
+
+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`).
+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
+Two-Option Offer DM is composed by the `routine.research_offer_dm`
+process key.
+
+Accepting either path clears every pending-offer row for that slug, so a
+later tick cannot re-offer the same cluster.
+
+## Owner Controls
+
+| Surface | What it does |
+|---|---|
+| `!checks` | Today's top reload patterns (pure DB read, safe while paused). |
+| `!research` | List active + dormant clusters. |
+| `!research <slug>` | Show one cluster's detail. |
+| `!research accept <slug>` | Enqueue `routine.research_dispatch`. |
+| `!research wiki <slug>` | Enqueue `routine.research_wiki_summary`. |
+| `!research decline <slug>` | Silence offers for 14 days. |
+| `!research mute <slug>` / `unmute` | Toggle offers off (until unmute) / restore. |
+| `!research rename <slug> <new name>` | Change display name. |
+| `!research conclude <slug>` | Mark concluded; preserve the journal. |
+| Natural-language reply to an offer DM | The `browser-history-respond` skill bridges into the same `/api/browser-history/offers/<slug>/{accept,decline}` call. |
+
+## When It Runs
+
+| Signal | Cadence | Source |
+|---|---|---|
+| Visit ingest | Every 30 min per browser profile | `BrowserHistoryPoller` |
+| Cluster engagement evaluation | Same tick as visit ingest | `pipeline/offer-triggers.ts` |
+| 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 |
+
+## When Something Goes Wrong
+
+- **The settings page shows no browsers.** Open
+  `/settings/integrations/browser-history` and run `aitne doctor` — the
+  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.
+- **`!checks` is empty.** That's the common case for a quiet day —
+  the reload signals are gated to the agent-day, not UTC.
+
+## Related
+
+- [Managed Chromium](../operations/managed-chromium.md) — separate
+  experimental flow for *driving* a Chromium profile (B-4), not
+  reading browser history.
+- [Weekly Review](../routines/weekly-review.md)
+- [Morning Routine](../routines/morning-routine.md)
+- [Bang Commands](../messaging/bang-commands.md)
+- [Glossary: Research Cluster](../../glossary.md#research-cluster)

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

@@ -10,16 +10,18 @@ aliases:
 category: features
 summary: |
   The calendar integration pulls your events into Aitne so the
-  morning routine, schedule files, and travel-time skill can reason
-  about your day. The Connections → Calendar page also picks the
-  backend that handles approaching-event notifications and observed
-  calendar changes (Calendar Event Model) — that picker only applies
-  when the integration runs in direct mode.
+  morning routine and schedule files can reason about your day.
+  The Connections → Calendar page also picks the backend that handles
+  observed calendar changes (the Calendar Event Model card, binding
+  calendar.change) — that picker only applies when the integration runs
+  in direct mode.
 section: integrations
 tags:
-  - integration
+  - integrations
   - calendar
   - core
+  - observations
+  - polling
 status: stable
 ask_examples:
   - How do I connect my Google Calendar?
@@ -28,10 +30,10 @@ ask_examples:
   - What is the Calendar Event Model setting on the Connections page?
   - Why is the Calendar Event Model card missing when my calendar is delegated?
   - Will Aitne notice calendar changes while my calendar is delegated?
-  - Which model handles approaching-event reminders?
+  - Which model handles detected calendar changes?
 locale: en-US
 created: 2026-04-25
-updated: 2026-04-28
+updated: 2026-05-28
 keywords:
   - calendar
   - google calendar
@@ -47,25 +49,28 @@ keywords:
 related:
   - features/routines/morning-routine
   - features/memory-files/schedule
+  - features/operations/schedule-approaching
   - concepts/delegated-mode
   - concepts/process-keys
   - concepts/observations
 ui_anchors:
   - /connections/calendar
 api_endpoints:
-  - /api/calendar
+  - /api/calendar/calendars
+  - /api/calendar/events
+  - /api/calendar/freebusy
 config_keys:
   - calendarPollIntervalSeconds
 process_keys:
   - calendar.change
+  - schedule.approaching
 ---
 
 # Calendar
 
-## In One Sentence
-
-Pull events from one or more calendars (Google Calendar today, more
-backends planned) so Aitne can plan your day around them.
+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.
 
 ## What It Does
 
@@ -73,11 +78,13 @@ backends planned) so Aitne can plan your day around them.
 - **Records observations** when events change (add / move / remove),
   consumed by the hourly check.
 - **Surfaces today's events** to the morning routine so they land in
-  `today.md` and the day's schedule file.
+  `state/today.md` and the day's schedule file.
 - **Reads** events on demand for reactive turns ("am I free at 3?").
 
-The agent can create events when the operator asks (a `notify`-tier
-action). It does not auto-schedule on its own.
+The agent can create, move, or delete events when the operator asks
+(`POST`/`PATCH`/`DELETE /api/calendar/events`, all Autonomous-tier — no
+approval prompt). It does not auto-schedule on its own; it acts only on
+an explicit request.
 
 ## When It Runs / How It Is Triggered
 
@@ -99,22 +106,24 @@ action). It does not auto-schedule on its own.
 ## Calendar Event Model
 
 The Calendar Event Model picker chooses the backend and model that
-runs when the agent reacts to a calendar event. It binds the
-`calendar.change` ProcessKey, which fires from the calendar poller in
-three situations:
+runs when the **daemon-side poller detects a calendar change**. It binds
+the `calendar.change` ProcessKey, which fires in two situations:
 
-- An event is about to start (the operator gets an approaching-event
-  reminder).
 - An event was added, moved, or deleted between polls (recorded as a
   change observation; the hourly check picks it up).
-- An event was created far in advance (long-horizon events nudge the
-  roadmap-refresh routine so `roadmap.md` can build a preparation
-  timeline).
+- 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).
+
+Approaching-event reminders are a separate flow: they fire on the
+`schedule.approaching` ProcessKey, not `calendar.change`, and are not
+configured by this card. See [Schedule Approaching](../operations/schedule-approaching.md).
 
-Light tier is the default and almost always sufficient — these flows
-are classification and scheduling, not generation. The default backend
-is whichever you picked as your main backend during setup; you can
-override per-process here if you want a different mix.
+Light tier (Haiku 4.5 / gpt-5.4-mini) is the default and almost always
+sufficient — these flows are event classification at low cost, not
+generation. The default backend is whichever you picked as your main
+backend during setup; you can override per-process here if you want a
+different mix.
 
 The picker is **only meaningful when Google Calendar runs in direct
 mode.** In delegated mode the daemon hands off all Google Calendar
@@ -157,7 +166,8 @@ rather than an env-style setting; the underlying state lives in the
 ## Related
 
 - [Morning Routine](../routines/morning-routine.md)
-- [daily/ files](../memory-files/schedule.md)
+- [Schedule files](../memory-files/schedule.md)
+- [Schedule Approaching](../operations/schedule-approaching.md)
 - [Delegated Mode](../../concepts/delegated-mode.md)
-- [ProcessKeys](../../concepts/process-keys.md)
+- [Process Keys](../../concepts/process-keys.md)
 - [Observations](../../concepts/observations.md)