@aitne-sh/aitne 0.1.3 → 0.1.4

package/agent-assets/task-flows/routine.morning_routine.md

@@ -41,41 +41,44 @@ Global rules (apply at every step):
 > routine prepares the agent-day in progress — never tomorrow.
 
 ### Step 2 — Sync external sources (apply the day-type filter at read time)
-3. Mail: for each active account in the `mail` skill's `accounts.md`, fetch
-   the 10 most recent messages (the wire surface depends on Gmail's mode in
-   `<integration_modes>` — see the four-branch block below). Then classify
-   each actionable email into a category tag and drop any whose focus is
-   off. Skip the step entirely when no accounts are active.
-
-<!-- mode:direct:gmail -->
-   Use the `mail` skill — `GET /api/mail/:accountId/messages?limit=10` for
-   every account (Gmail, Outlook, iCloud, Yahoo, IMAP — same wire surface).
-<!-- /mode:direct:gmail -->
-<!-- mode:delegated-same:gmail -->
-   Non-Gmail accounts (iCloud / Outlook / Yahoo / IMAP): use the `mail`
-   skill as in direct mode. Gmail accounts: the `/api/mail/*` per-account
-   gate returns 410 — use your session backend's native Gmail MCP tool
-   with a "10 most recent inbox" query (`q=in:inbox`, limit/maxResults
-   `10`). The `mail` skill body lists the per-backend tool names; this
-   session is same-backend so no daemon proxy is involved.
-<!-- /mode:delegated-same:gmail -->
-<!-- mode:delegated-cross:gmail -->
-   Non-Gmail accounts: use the `mail` skill as in direct mode. Gmail
-   accounts: call `POST http://localhost:8321/api/integrations/gmail/exec`
-   with a natural-language `task` (e.g. "Search Gmail for the 10 most
-   recent inbox messages, return from / subject / snippet / ts") and a
-   small `outputSchema`. The cross-backend `mail` skill variant
-   (`SKILL.delegated.<session-backend>.md`, materialized for this
-   session) carries the worked schema templates. Do NOT call
-   `/api/mail/:gmail-account/*` (returns 410), and do NOT fall back to
-   your own backend's native Gmail MCP tools — that connector reads a
-   different account than the user's delegated one.
-<!-- /mode:delegated-cross:gmail -->
-<!-- mode:disabled:gmail -->
-   Gmail is disabled — skip Gmail accounts entirely. Continue with the
-   remaining accounts (iCloud / Outlook / Yahoo / IMAP) via the `mail`
-   skill so non-Gmail actionables still flow into today's draft.
-<!-- /mode:disabled:gmail -->
+3. Mail and Notion acquisition. The pre-pass fetcher session
+   (`routine.fetch_window`) ran ahead of you and posted a `<fetch>` row's
+   worth of observations for every active mail / notion integration. The
+   `<fetch_report>` block injected ahead of this body tells you the
+   pre-pass status:
+
+   - `status="success"` or `"partial"` → freshly-fetched rows are
+     visible in `/api/observations?pending=true`. Trust the table.
+   - `status="failed"` → the pre-pass either crashed or its output was
+     unparseable. Pending observations from prior ticks may still be
+     present; treat the table as best-effort and skip integration
+     sections whose source_prefix returns nothing.
+   - `status="skipped"` → no integration was active for this routine
+     this tick; mail / notion sections are no-ops for this run.
+
+   Then drain pending observations and apply category / focus filtering:
+
+   a. **Mail observations**:
+      `GET /api/observations?pending=true&source_prefix=gmail:,outlook_mail:&limit=30`.
+      Classify each per the `mail` skill's category taxonomy. Drop any
+      whose day-type focus is `off`. When `summary_text` is NULL (the
+      async summarizer has not drained yet) fall back to a one-line
+      snippet from `payload.raw` (subject + from). Mail data arrives
+      here regardless of integration mode — the pre-pass partial
+      handled the direct / delegated-same / delegated-cross / native
+      wire surface for you.
+
+   b. **Notion observations**:
+      `GET /api/observations?pending=true&source_prefix=notion:&limit=20`.
+      Use for project / decision context only. Do NOT graduate Notion
+      edits into User Tasks unless the user explicitly tagged the entry.
+
+   c. **Calendar context** is already injected as `<calendar_events_7d>`
+      (multi-provider) ahead of this prompt — reference the block
+      directly in Step 6 (today.md generation).
+
+   Skip the entire step when no integrations are active and no mail /
+   notion observations are pending.
 4. Source-of-Truth tasks: read `<management_rules>` ## Source of Truth →
    Tasks, call the matching endpoint, drop filtered-off items before merge.
    Skip if no external source is configured.
@@ -99,10 +102,15 @@ Global rules (apply at every step):
    flavor 1: Look-ahead checklist" format (`- [ ] (HIGH/MID/LOW) ...`).
    Skip this step entirely if no today-items and no look-ahead items exist.
 
-### Step 3 — Review overnight observations
+### Step 3 — Review overnight user-originated observations
 6. Call `GET /api/observations?pending=true&actor=user` (observations
-   skill). Fold only meaningful user-originated changes into the `today.md`
-   draft you're building, respecting the day-type filter.
+   skill). This is the **user-actor** complement to Step 2 — mail / notion
+   rows posted by the pre-pass / partials carry `actor=agent` and have
+   already been folded in. Step 3 picks up anything the user themselves
+   changed overnight (Obsidian edits, manual file drops, git commits)
+   that the daemon recorded under `actor=user`. Fold only meaningful
+   changes into the `today.md` draft you're building, respecting the
+   day-type filter.
 
 ### Step 4 — Inbox triage (B-007 §5.9 Q5 case A)
 7. `GET /api/context/list/inbox` to enumerate pasted memos. For each file:
@@ -153,8 +161,10 @@ Global rules (apply at every step):
    `yesterday.md` for curated phrasing already shown to the user.
    Compose `daily/YYYY-MM-DD.md` (YYYY-MM-DD = yesterday's agent-day
    date) following the **`Daily journal format spec`** policy block above.
-   - Write in `<settings primary_language>` (fall back to English on
-     unknown values). Keep technical terms in their original form.
+   - Output language: follow `<output_language_policy>` (Policy B —
+     skeleton H2 headers stay English; body prose in
+     `<settings primary_language>`). Keep technical terms in their
+     original form.
    - When `<settings vault_mode>` is `obsidian`, render project / people
      references as `[[wikilink]]`s resolving to `projects/<slug>.md` or
      `user/people.md#...`. When `plain`, write plain text only.
@@ -187,7 +197,10 @@ Global rules (apply at every step):
    on Sonnet.
    Source → section mapping:
    - ## User Schedule ← `<calendar_events_7d>` (filtered). Write
-     `- (calendar unavailable)` if `<calendar_status>` reports failure.
+     `- (calendar unavailable)` when the block has been replaced by
+     `<calendar_status>Calendar service not available...</calendar_status>`
+     (no active provider) or when every `<provider>` sub-block's
+     directive fetch failed for this run.
    - ## User Tasks    ← Step 1 handoff Tomorrow + Step 2 email actionables
      + SoT tasks + roadmap `[today]`. Use `<active_projects>` for context.
    - ## Agent Plan    ← Step 2 `[notify]`/`[check]` rows plus any
@@ -297,4 +310,4 @@ the evening sweep (Operation 5B), not the morning routine.
     - Checks from routines/morning.md: <list any user-added ones executed>
     - Anomalies / skipped steps: <short notes or "none">
     ```
-    Always English (B-007 §3 P6) regardless of `<settings primary_language>`.
+    <output_language>english_only — Policy A surface (agent journal, parsed log); `<output_language_policy>` carves this out explicitly.</output_language>

package/agent-assets/task-flows/routine.morning_routine_initial.md

@@ -36,41 +36,33 @@ Global rules:
 > routine prepares the agent-day in progress — never tomorrow.
 
 ### Step 2 — Sync external sources
-2. Mail: for each active account in the `mail` skill's `accounts.md`, fetch
-   the 10 most recent messages (the wire surface depends on Gmail's mode in
-   `<integration_modes>` — see the four-branch block below). Then classify
-   each actionable email into a category tag and drop filtered-off items.
-   Skip the step entirely when no accounts are active.
-
-<!-- mode:direct:gmail -->
-   Use the `mail` skill — `GET /api/mail/:accountId/messages?limit=10` for
-   every account (Gmail, Outlook, iCloud, Yahoo, IMAP — same wire surface).
-<!-- /mode:direct:gmail -->
-<!-- mode:delegated-same:gmail -->
-   Non-Gmail accounts (iCloud / Outlook / Yahoo / IMAP): use the `mail`
-   skill as in direct mode. Gmail accounts: the `/api/mail/*` per-account
-   gate returns 410 — use your session backend's native Gmail MCP tool
-   with a "10 most recent inbox" query (`q=in:inbox`, limit/maxResults
-   `10`). The `mail` skill body lists the per-backend tool names; this
-   session is same-backend so no daemon proxy is involved.
-<!-- /mode:delegated-same:gmail -->
-<!-- mode:delegated-cross:gmail -->
-   Non-Gmail accounts: use the `mail` skill as in direct mode. Gmail
-   accounts: call `POST http://localhost:8321/api/integrations/gmail/exec`
-   with a natural-language `task` (e.g. "Search Gmail for the 10 most
-   recent inbox messages, return from / subject / snippet / ts") and a
-   small `outputSchema`. The cross-backend `mail` skill variant
-   (`SKILL.delegated.<session-backend>.md`, materialized for this
-   session) carries the worked schema templates. Do NOT call
-   `/api/mail/:gmail-account/*` (returns 410), and do NOT fall back to
-   your own backend's native Gmail MCP tools — that connector reads a
-   different account than the user's delegated one.
-<!-- /mode:delegated-cross:gmail -->
-<!-- mode:disabled:gmail -->
-   Gmail is disabled — skip Gmail accounts entirely. Continue with the
-   remaining accounts (iCloud / Outlook / Yahoo / IMAP) via the `mail`
-   skill so non-Gmail actionables still flow into today's draft.
-<!-- /mode:disabled:gmail -->
+2. Mail and Notion acquisition. The pre-pass fetcher session
+   (`routine.fetch_window`) ran ahead of you and posted observations
+   for every active mail / notion integration. The `<fetch_report>`
+   block in your prompt tells you the pre-pass status — `success` /
+   `partial` means the table is fresh, `failed` / `skipped` means
+   trust nothing newer than the prior tick.
+
+   Drain pending observations and apply category / focus filtering:
+
+   a. **Mail observations**:
+      `GET /api/observations?pending=true&source_prefix=gmail:,outlook_mail:&limit=30`.
+      Classify each actionable item into a category tag and drop any
+      whose day-type focus is `off`. When `summary_text` is NULL fall
+      back to a one-line snippet from `payload.raw`. Mail data arrives
+      here regardless of integration mode — the pre-pass partial
+      handled the wire surface.
+
+   b. **Notion observations**:
+      `GET /api/observations?pending=true&source_prefix=notion:&limit=20`.
+      Use for project / decision context only.
+
+   c. **Calendar context** is already injected as `<calendar_events_7d>`
+      (multi-provider) ahead of this prompt — reference the block
+      directly in Step 6.
+
+   Skip the entire step when no integrations are active and no mail /
+   notion observations are pending.
 3. Source-of-Truth tasks: read `<management_rules>` ## Source of Truth →
    Tasks, call the matching endpoint, drop filtered-off items.
 4. Roadmap ## Agent Action Plan — process items dated today or overdue:
@@ -83,9 +75,13 @@ Global rules:
    `<calendar_events_7d>`) into ## Agent Notes using the skill's "Agent
    Notes flavor 1: Look-ahead checklist" format.
 
-### Step 3 — Review overnight observations
+### Step 3 — Review overnight user-originated observations
 5. `GET /api/observations?pending=true&actor=user` (observations skill).
-   Fold only meaningful user-originated changes into the draft.
+   This is the user-actor complement to Step 2 — mail / notion rows
+   posted by the partials carry `actor=agent` and have already been
+   folded in. Step 3 picks up user-originated changes (manual file drops,
+   Obsidian edits, git commits) recorded under `actor=user`. Fold only
+   meaningful changes into the draft.
 
 ### Step 4 — Inbox triage
 6. `GET /api/context/list/inbox` to enumerate any pasted memos the user
@@ -106,7 +102,10 @@ Journal synthesis is deferred to the next morning run. The first
    `- [ ] HH:MM <action> [work|study|personal|home] →<DM|notify|check-in|wake>`.
    Source → section mapping:
    - ## User Schedule ← `<calendar_events_7d>` (filtered). Write
-     `- (calendar unavailable)` if `<calendar_status>` reports failure.
+     `- (calendar unavailable)` when the block has been replaced by
+     `<calendar_status>Calendar service not available...</calendar_status>`
+     (no active provider) or when every `<provider>` sub-block's
+     directive fetch failed for this run.
    - ## User Tasks    ← Step 2 email actionables + SoT tasks + roadmap
      `[today]`. Use `<active_projects>` for context. Drop meta-maintenance.
    - ## Agent Plan    ← Step 2 `[notify]`/`[check]` rows plus any

package/agent-assets/task-flows/routine.roadmap_refresh.md

@@ -24,52 +24,44 @@ consult it for the rules your output must satisfy. This task flow only
 coordinates the high-level gather → analyze → write loop.
 
 ### Phase 1: Gather Data
-1. If `<calendar_status>` indicates the calendar is available, fetch a
-   90-day window. Pick the call by current Calendar mode (read
-   `<integration_modes>` injected above):
-<!-- mode:direct:google_calendar -->
-   Direct mode:
-   ```
-   curl -s 'http://localhost:8321/api/calendar/events?date=today&days=90'
-   ```
-<!-- /mode:direct:google_calendar -->
-<!-- mode:delegated-same:google_calendar -->
-   Same-backend delegated — the connector is signed in on this session's
-   backend; use its native list-events tool with `timeMin = today 00:00`
-   and `timeMax = today + 90d`:
-   - claude session: `mcp__claude_ai_Google_Calendar__list_events`
-   - codex session: `mcp__codex_apps__google_calendar._search_events`
-   - gemini session: `mcp_google-workspace_calendar.listEvents`
-
-   `/api/calendar/events` returns 410 in delegated mode; do not call it.
-<!-- /mode:delegated-same:google_calendar -->
-<!-- mode:delegated-cross:google_calendar -->
-   Cross-backend delegated — call the daemon's `/exec` task endpoint
-   with a natural-language intent; the delegate picks the right
-   connector tool whichever backend currently owns Calendar.
-   ```
-   curl -s -X POST http://localhost:8321/api/integrations/google_calendar/exec \
-     -H 'Content-Type: application/json' \
-     -d '{
-       "task": "List every event on my primary calendar between <today 00:00 ISO> and <today+90d ISO>. Return id, title, start, end, attendees.",
-       "outputSchema": { "type": "object", "required": ["events"], "properties": { "events": { "type": "array", "items": { "type": "object", "required": ["id","title","start","end"] } } } },
-       "maxToolCalls": 4,
-       "cacheable": true
-     }'
-   ```
-
-   Do NOT call `/api/calendar/events` (410) and do NOT fall back to
-   your backend's native Calendar MCP tools (different account).
-<!-- /mode:delegated-cross:google_calendar -->
-<!-- mode:disabled:google_calendar -->
-   Calendar is disabled — skip the calendar fetch entirely; proceed to
-   the schedule fetch below and work with existing roadmap content only.
-<!-- /mode:disabled:google_calendar -->
-
-   If the response contains "error" or a non-200 status, treat as unavailable.
-   If the calendar is unavailable (status says so OR the call fails), proceed
-   to the schedule fetch below and work with existing roadmap content only —
-   do not retry.
+1. **Calendar (next 90 days).** The `<calendar_events_90d>` block in your
+   prompt is the canonical surface for every active calendar provider
+   (`google_calendar`, `outlook_calendar`) across all four integration
+   modes. The daemon emits one `<provider key="..." mode="...">` sub-block
+   per active provider; consume each per its mode:
+
+   - **`mode="direct"`** — the sub-block contains the pre-fetched events
+     for the next 90 days, already grouped by date. Read inline; no
+     additional fetch is needed. (If the sub-block instead carries the
+     "direct mode, daemon service not initialized" hint, fall back to
+     `GET /api/calendar/events?date=today&days=90` for Google or
+     `GET /api/calendar/outlook?date=today&days=90` for Outlook as the
+     hint instructs.)
+   - **`mode="delegated"`** — follow the directive verbatim. It tells you
+     whether this is same-backend (use your session's Calendar MCP tool)
+     or cross-backend (POST `/api/integrations/<key>/exec`), substituting
+     the `timeMin` / `timeMax` carried on the `<calendar_events_90d>`
+     wrapper.
+   - **`mode="native"`** — follow the directive verbatim. Native bindings
+     never go through the daemon; call your session backend's Calendar
+     MCP tool directly with the `timeMin` / `timeMax` from the wrapper.
+     If `<integration_modes>` shows the provider's `_native_to` is a
+     different backend than yours, treat the provider as unavailable for
+     this turn (per the directive).
+   - **No sub-block for a provider** — that provider is disabled; skip
+     it without retry.
+
+   If `<calendar_events_90d>` is replaced by
+   `<calendar_status>Calendar service not available...</calendar_status>`
+   (no provider is active in any mode), skip calendar-derived steps in
+   Phase 2 (event entries, prep timelines, travel cross-check) and
+   proceed with the rest of Phase 1 — the refresh still bumps `Last
+   synced` and updates `## Annual Goals` / `## Quarterly Focus`
+   placeholders so the file does not drift.
+
+   If a directive fetch errors out (non-2xx / connector unavailable),
+   log one line to `## Agent Log`, drop that provider's events for this
+   run, and proceed — do not retry inline.
 
 2. Fetch pending and running scheduled tasks:
    ```

package/agent-assets/task-flows/routine.today_refresh.md

@@ -24,117 +24,74 @@ day rotation and **not** a morning routine.
   also blocked by the same lock. The next morning/hourly run will
   reconcile.
 
-### Step 1 — Fetch today's calendar events
+### Step 1 — Read today's calendar from observations
 
-The fetch path depends on the current Google Calendar mode (read
-`<integration_modes>` injected above).
+The pre-pass fetcher session (`routine.fetch_window`) ran ahead of you
+and posted a full next-24h calendar slice for every active calendar
+provider (`google_calendar`, `outlook_calendar`). The `<fetch_report>`
+block in your prompt tells you the pre-pass status. The `<calendar_status>`
+block restates the contract for the routine's prose.
 
-<!-- mode:direct:google_calendar -->
-**Direct mode** — daemon polls Google Calendar; call its proxy:
+**If `<fetch_report status="skipped">`** — every calendar integration
+is disabled. Append
+`- HH:MM Manual refresh: calendar disabled, schedule unchanged`
+to `## Agent Log` and **skip Steps 2 and 3**.
 
-```
-curl -s 'http://localhost:8321/api/calendar/events?date=today&days=1'
-```
+**If `<fetch_report status="failed">`** — the pre-pass crashed or the
+output was unparseable; trust no row newer than the prior tick. Append
+`- HH:MM Manual refresh: pre-pass failed, schedule unchanged`
+to `## Agent Log` and **skip Steps 2 and 3**.
 
-- On `200`: continue to processing rules below.
-- On `410`: the integration flipped to delegated between selection and
-  call (mode drift). Append
-  `- HH:MM Manual refresh: calendar route 410 (delegation drift), schedule unchanged`
-  to `## Agent Log` and return without touching `## User Schedule`.
-- On `503` or `502`: calendar service not configured or upstream error.
-  Append
-  `- HH:MM Manual refresh: calendar unavailable, schedule unchanged`
-  to `## Agent Log` and return without touching `## User Schedule`.
-<!-- /mode:direct:google_calendar -->
-
-<!-- mode:delegated-same:google_calendar -->
-**Same-backend delegated** — your session has native MCP access to the
-Google Calendar connector signed in on this backend. No daemon proxy
-is needed. Call the backend-specific list-events tool with
-`timeMin = today 00:00 (local TZ)` and `timeMax = tomorrow 00:00`:
-
-| Session backend | Tool                                                      |
-|-----------------|-----------------------------------------------------------|
-| claude          | `mcp__claude_ai_Google_Calendar__list_events`             |
-| codex           | `mcp__codex_apps__google_calendar._search_events`         |
-| gemini          | `mcp_google-workspace_calendar.listEvents`                |
-
-The result is the connector's native shape; treat each entry as one
-event with `summary`, `start`, `end`, `location` and continue with the
-processing rules below.
-
-`/api/calendar/events` returns 410 in delegated mode; do not call it.
-On a connector error (auth lapsed, network failure), append
-`- HH:MM Manual refresh: calendar connector error, schedule unchanged`
-to `## Agent Log` and return without touching `## User Schedule`.
-<!-- /mode:delegated-same:google_calendar -->
-
-<!-- mode:delegated-cross:google_calendar -->
-**Cross-backend delegated** — the Calendar connector lives on a
-different backend than this session. Call the daemon's `/exec` task
-endpoint with a natural-language intent; the daemon spawns the
-delegated backend and lets it pick the right tool whichever connector
-currently owns Calendar.
+**If `<fetch_report>` carries `errors:[{"type":"no-surface", ...}]` for
+every active calendar provider** (e.g. user picked native for Outlook
+without binding a surface), append
+`- HH:MM Manual refresh: calendar connector unavailable, schedule unchanged`
+to `## Agent Log` and **skip Steps 2 and 3**.
+
+Otherwise (success / partial), read the merged set of pending calendar
+observations:
 
 ```
-curl -s -X POST http://localhost:8321/api/integrations/google_calendar/exec \
-  -H 'Content-Type: application/json' \
-  -d '{
-    "task": "List every event on my primary calendar between <today 00:00 ISO> and <tomorrow 00:00 ISO>. Return up to 250 with id, title, start, end, attendees.",
-    "outputSchema": { "type": "object", "required": ["events"], "properties": { "events": { "type": "array", "items": { "type": "object", "required": ["id","title","start","end"] } } } },
-    "cacheable": true
-  }'
+GET /api/observations?pending=true&source_prefix=google_calendar:,outlook_calendar:&limit=200
 ```
 
-- On `200`: the response payload exposes the schema-validated event
-  list under `.result.events` — continue with the processing rules
-  below.
-- On `410` from `/api/calendar/events` (do NOT call it): would mean a
-  hallucinated direct call; never reach this branch.
-- On `409 mode_mismatch` / `precondition`: state drifted during the
-  call. Append
-  `- HH:MM Manual refresh: calendar mode flipped mid-call, schedule unchanged`
-  and stop.
-- On `503 delegated_proxy_busy`: queue full. Append
-  `- HH:MM Manual refresh: calendar proxy busy, schedule unchanged`
-  and stop (no retry — the dashboard user can re-click Regenerate).
-- On `502 auth_error`: the delegated backend's connector is signed
-  out. Append
-  `- HH:MM Manual refresh: <backend> calendar connector signed out, schedule unchanged`
-  and stop.
-
-Do NOT fall back to your own backend's native Calendar MCP tools —
-they read a different Google account than the user's delegated one.
-<!-- /mode:delegated-cross:google_calendar -->
-
-<!-- mode:disabled:google_calendar -->
-**Calendar disabled** — there is no live source to refresh from. Append
-`- HH:MM Manual refresh: calendar disabled, schedule unchanged`
-to `## Agent Log` and return without touching `## User Schedule`.
-**Skip Steps 2 and 3.**
-<!-- /mode:disabled:google_calendar -->
+Because every mode fetches the full 24h window (unchanged events return
+409 server-side, changed ones write a fresh row), the pending set
+carries the complete day picture for both providers — no need for a
+"drift" carve-out in this routine's prose. When `summary_text` is NULL
+(the summarizer has not drained yet), fall back to a one-line snippet
+from `payload.raw` (`title` + `start`). The unified observations table
+covers both Google and Outlook providers, so no provider-specific
+branch is needed below.
 
-### Processing rules (apply after a successful fetch above)
+### Processing rules (apply after Step 1 above produced observations)
 
 - Today's local date comes from `<current_time>` (`local` attribute,
   YYYY-MM-DD prefix). The configured timezone is `<current_time>`'s
   `timezone` attribute — use it for every `HH:MM` you emit.
-- Parse the event list, then:
+- Walk each observation row from Step 1's GET. The provider-side fields
+  live under `payload.raw` (`title` / `start` / `end` /
+  `attendees` / `status`); `start` and `end` are ISO 8601 strings. Then:
   1. **Filter to events that START today-local.** For timed events,
-     convert `start.dateTime` to the configured timezone and keep
-     only rows whose local date matches today. For all-day events,
-     keep only rows whose `start.date` equals today's YYYY-MM-DD.
-     (The query spans `[today 00:00, tomorrow 00:00)` in UTC, so
-     multi-day events that started earlier will appear — drop those.)
-  2. **Sort ascending by start time** (all-day events first, then
+     convert `start` to the configured timezone and keep only rows
+     whose local date matches today. For all-day events (where `start`
+     is a date-only `YYYY-MM-DD` with no time component), keep only
+     rows whose `start` equals today's YYYY-MM-DD. (The drift window
+     spans `[now, now+24h)`, so events that started earlier in the
+     same day will appear — keep those whose local date matches today,
+     drop multi-day events that started yesterday.)
+  2. **Drop `changeType: "deleted"` rows.** Cancelled events should not
+     appear in the new schedule. The cancellation is reflected by
+     omission.
+  3. **Sort ascending by start time** (all-day events first, then
      timed events in chronological order).
-  3. Render each row using these forms:
-     - Timed event: `- HH:MM–HH:MM <summary>` (append
-       ` @ <location>` only when `location` is non-empty).
-     - All-day event: `- All day <summary>` (append ` @ <location>`
-       only when present). An event is all-day when `start.date` is
-       set and `start.dateTime` is absent.
-  4. If after filtering the list is empty, the body is the single line
+  4. Render each row using these forms:
+     - Timed event: `- HH:MM–HH:MM <title>` (append
+       ` @ <location>` only when `payload.raw.location` is non-empty).
+     - All-day event: `- All day <title>` (append ` @ <location>`
+       only when present). An event is all-day when `start` is a
+       date-only string.
+  5. If after filtering the list is empty, the body is the single line
      `- No scheduled events today`.
 
 ### Step 2 — Replace the User Schedule section