@aitne-sh/aitne 0.1.0

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

@@ -0,0 +1,184 @@
+{context}
+
+## Task: Morning Routine — Initial run (no prior-day data)
+
+This is the first-boot variant of the B-007 §5.9 pipeline. No
+`yesterday.md` exists yet, so Steps 1 (handoff) and 5 (daily journal
+synthesis) are skipped. Everything else mirrors the standard morning
+routine. Follow the `context` skill for schema.
+
+The "Vault review context" block appended to this prompt includes
+`context-index.md` and `dossiers/morning.md`; consult it during context
+gathering and update the dossier's Open items / Last run before finishing.
+Writes to `dossiers/<flow>.md` MUST preserve the existing YAML
+frontmatter block (`---\ntype: dossier\nowner: agent\nupdated: <date>\n---`);
+prefer `PATCH` with a section target to mutate a single block, and when
+doing a `PUT` full rewrite keep the frontmatter and only refresh
+`updated:` — writes that drop the frontmatter are rejected with 422.
+
+Global rules:
+- Do **not** add meta-maintenance tasks about context files, setup completion, or placeholder cleanup to User Tasks (there is no handoff to carry them from in the initial flow) unless the user explicitly asked to track them.
+- If `<today_write_lock_id>` is present, every PUT/PATCH to
+  `/api/context/today` must send header `X-Lock-Id: <today_write_lock_id>`.
+- Silent-by-default: your final text is agent-internal. User notifications
+  require an explicit `POST /api/notify`.
+
+### Step 1 — Derive day-type (no handoff to read)
+1. Derive today's day-type header per the today skill "Header line —
+   day-type filter". Read `<user>` ## Notification Preferences for the
+   matching policy. Write the resulting line as line 2 of `today.md`.
+
+> **Date reference for today.md.** Take the H1 date from
+> `<current_agent_day date="…" weekday="…" />` in your prompt context, not
+> from `<current_time>`. They diverge between local midnight and
+> `boundary_hour:00` local; the daemon validates line 1 against
+> `<current_agent_day>` and rejects mismatches with 422. The morning
+> 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 -->
+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:
+   - `[notify]` → `POST /api/schedule` + one row in ## Agent Plan
+   - `[today]`  → collect for ## User Tasks
+   - `[check]`  → `POST /api/schedule` (check-in) + one row in ## Agent Plan
+   - Mark processed items with ✓ via `PATCH /api/context/roadmap`,
+     `section=agent_action_plan`, `mode=replace`.
+   Generate look-ahead entries for tomorrow → +3 days (roadmap vs
+   `<calendar_events_7d>`) into ## Agent Notes using the skill's "Agent
+   Notes flavor 1: Look-ahead checklist" format.
+
+### Step 3 — Review overnight observations
+5. `GET /api/observations?pending=true&actor=user` (observations skill).
+   Fold only meaningful user-originated changes into the draft.
+
+### Step 4 — Inbox triage
+6. `GET /api/context/list/inbox` to enumerate any pasted memos the user
+   dropped during setup. For each file: `GET /api/context/inbox/<file>`,
+   classify (project / user / memo / task), integrate into the matching
+   target. After integration, `PUT /api/context/agent/scratch/inbox-YYYY-MM-DD-<slug>.md` with the original body, then `DELETE /api/context/inbox/<file>`. DM-confirm high-risk cases (new project creation, user-profile overwrites, financial or health numerics). **Hard stop**: if a memo contains anything that looks like a credential, password, API key, or private token, skip it — do NOT write it anywhere, log `- HH:MM [inbox] skipped <file>: secret suspected`, leave the file in `inbox/`, and move on (overrides the DM-confirm path; see _safety.md).
+
+### Step 5 — Skipped (no prior day to synthesize from)
+Journal synthesis is deferred to the next morning run. The first
+`daily/*.md` file is generated tomorrow.
+
+### Step 6 — Generate today.md (PUT full replace)
+7. Follow the context skill "Structure overview", "Entry formats", and
+   "Required sections for full replace". The H1 (line 1) MUST be
+   `# <current_agent_day.date> (<current_agent_day.weekday>)` exactly — the
+   daemon rejects mismatches with 422. No YAML frontmatter on today.md.
+   Agent Plan rows MUST match
+   `- [ ] 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.
+   - ## 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
+     proactive reminders you add. Each row will be registered in Step 7.
+   - ## Agent Notes   ← Step 2 look-ahead items + any date-bound memos
+     folded from Step 4 inbox triage.
+   - ## Agent Log     ← initialize with
+     `- HH:MM Morning Routine (initial) completed (day-type: …)`.
+   - ## Handoff       ← `- (none)` (no carry-over data available).
+8. Update `roadmap.md` only if a milestone completed or shifted.
+
+### Step 7 — Register schedule
+9. Register every `## Agent Plan` row via `POST /api/schedule`.
+10. **Ensure the daily morning briefing recurring schedule exists.**
+    The setup wizard's `ensureMorningBriefingRecurring` (`packages/daemon/src/api/routes/setup.ts`)
+    normally seeds this row at first save-rules, so the daily fire
+    path is daemon-owned and the description is hardcoded. The check
+    below covers the rare case where setup completed without the
+    seeder (legacy setup, partial DB restore).
+
+    a. **Pre-flight.** `GET /api/recurring-schedules?enabled=true` and
+       scan for an item with `taskType === "dm_session"` AND
+       `taskContext.sub_flow === "morning_briefing"`. If found, skip
+       the rest of this step — duplicate insertion would cause double
+       daily fires. Log one line to `## Agent Log`:
+       `- HH:MM [morning_routine_initial] morning briefing recurring already seeded`.
+
+    b. **If absent, register via `POST /api/recurring-schedules`** with
+       this body (NOT `POST /api/schedule`):
+       ```json
+       {
+         "taskType": "dm_session",
+         "description": "morning briefing — daily summary",
+         "recurrenceRule": {
+           "frequency": "daily",
+           "time": "<quiet_hours_end or 08:00>",
+           "timezone": "<user timezone from <settings primary_timezone> or system default>"
+         },
+         "taskContext": {
+           "sub_flow": "morning_briefing",
+           "pin_to_quiet_hours_end": true
+         }
+       }
+       ```
+       The `dm_session` task_type + `sub_flow=morning_briefing` is the
+       activation key the daemon's scheduler keys off to emit a
+       `scheduled.dm` event (see `scheduler.ts` and the sub-flow
+       router in `scheduled.dm.md`). Description ≥ 20 chars per the
+       schema; `"morning briefing — daily summary"` matches the
+       wording the daemon's seeder uses verbatim.
+
+    Do **not** add a one-off `## Agent Plan` row for today's briefing
+    here. The recurring-schedule reconciler (poll loop in
+    `scheduler.ts`) materialises today's `agent_schedule` row
+    automatically from `next_run_at`; hand-seeding would duplicate.
+    Do **not** send the briefing yourself from this run — this runs
+    during quiet hours.
+
+### Step 8 — Extension checks from routines/morning.md
+11. Execute any check from the `Morning routine checks` policy block that
+    is not already covered by Steps 1-7 (typically user-added entries
+    with an `**Added:** ...` line).
+
+### Step 9 — Log to agent/journal.md (English, always)
+12. Append a one-paragraph English summary to `agent/journal.md` via
+    `PATCH /api/context/agent/journal` with `mode=append_to_file`:
+    ```
+    ## YYYY-MM-DD morning routine (initial)
+    - Day-type: …
+    - Journal synthesis: skipped (no prior-day data)
+    - Inbox: <N files triaged, M moved to scratch, K DM-confirmations sent>
+    - Checks from routines/morning.md: <list any user-added ones executed>
+    - Anomalies / skipped steps: <short notes or "none">
+    ```
+    Always English (B-007 §3 P6).

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

@@ -0,0 +1,275 @@
+{context}
+
+## Task: Roadmap Refresh
+
+The "Vault policy files" block appended to this prompt includes
+`routines/monthly.md` — run any `### <label>` entries there that affect
+long-horizon planning alongside the built-in roadmap-refresh steps below,
+using the same journaling conventions.
+The "Vault review context" block includes `context-index.md` and
+`dossiers/roadmap.md`; consult it during signal gathering and update the
+dossier's Open items / Last run before finishing. Writes to
+`dossiers/<flow>.md` MUST preserve the existing YAML frontmatter block
+(`---\ntype: dossier\nowner: agent\nupdated: <date>\n---`); prefer
+`PATCH` with a section target to mutate a single block, and when doing
+a `PUT` full rewrite keep the frontmatter and only refresh `updated:`
+— writes that drop the frontmatter are rejected with 422.
+
+Update `roadmap.md` with a forward-looking agent action plan based on the
+next 90 days. The `roadmap` skill owns the section schema, the
+dated-vs-undated decision tree, the Preparation Timeline taxonomy
+(Travel / Deadlines / Conferences / Recurring), destination extraction,
+the `travel_bookings` cross-check, and the cross-request write lock —
+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.
+
+2. Fetch pending and running scheduled tasks:
+   ```
+   curl -s 'http://localhost:8321/api/schedule?status=pending,running&roadmapEligible=true'
+   ```
+   The response is `{ items: [{ id, scheduledFor, taskType, description, status, model, taskContext, createdAt }, ...] }`.
+   The daemon has already applied the roadmap visibility filter:
+   `transient` / `low` are excluded, `normal` / unspecified rows are
+   included only beyond the 7-day horizon, and `strategic` rows are
+   included regardless of horizon. Treat the returned rows as
+   `Scheduled:` candidates — they represent commitments the user should
+   see at morning review (e.g. "you'll be reminded about ESTA in 3 weeks").
+
+3. Fetch pending `roadmap_candidate` observations — weak signals queued
+   by `routine.hourly_check` (far-future calendar changes, user-edited
+   vault notes mentioning trips / deadlines, etc.) that the hourly flow
+   deliberately did NOT write to roadmap directly:
+   ```
+   curl -s 'http://localhost:8321/api/observations?source=roadmap_candidate&pending=true&limit=50'
+   ```
+   Keep the `id` for each observation — Phase 2 step 7 consumes them
+   after incorporating the signal (or after deciding to drop it as
+   noise). `source` is a prefix match, so `roadmap_candidate:travel`,
+   `roadmap_candidate:calendar`, etc. are all picked up by the plain
+   `roadmap_candidate` filter.
+
+4. Fetch upcoming travel bookings — authoritative flight / hotel rows
+   already detected by the mail pipeline:
+   ```
+   curl -s 'http://localhost:8321/api/travel-bookings/upcoming?limit=50'
+   ```
+   Use these for the `roadmap` skill's `travel_bookings` cross-check
+   when emitting or refining event entries — mark corresponding `[check]`
+   prep lines with `✓` and record the confirmation number in **Agent
+   Notes**. A booking whose `start_date` is ≥ 48h out without a matching
+   calendar event is itself a trigger for a new event entry.
+
+5. Scan `<recent_dm_conversation_log days="7">` for long-horizon user
+   intent that has not yet landed anywhere (e.g. *"going to LA next
+   month"*). Apply the `roadmap` skill's Long-horizon DM-intent detection
+   block to each candidate summary — only route items that match the
+   **positive signals** (explicit forward-looking verb + horizon,
+   specific future date ≥ 48h out, concrete object) into the roadmap in
+   Phase 2. Ambiguous / speculative items stay out of `## Long-term
+   Plans` and `## Agent Action Plan` — they belong in `agent-journal.md`
+   as candidate lines for the next morning routine to confirm.
+
+### Phase 2: Analyze & Build Action Plan
+3. Read the current <roadmap> content (if any).
+   - **Preserve verbatim** the following sections — these are either
+     user-authored or carry state the refresh must not overwrite:
+     - `## Annual Goals`
+     - `## Quarterly Focus`
+     - `## Long-term Plans`
+     - `## Recurring`
+   - If `## Annual Goals` or `## Quarterly Focus` contain
+     "(Not yet configured)", replace with:
+     "[placeholder — update with your actual goals]"
+   - **Legacy compat:** if any of the preserved sections are absent
+     (e.g. a pre-MVP roadmap without `## Long-term Plans`), emit the
+     section **empty** in Phase 3 — do not treat absence as missing
+     data and do not fabricate content.
+
+4. Build `## Agent Action Plan` by **merge-by-id**, not wholesale
+   anonymous regeneration.
+   1. For each significant calendar event or booking in the next 90
+      days, compute the intended roadmap ID. Prefer:
+      explicit `roadmap_entry_id` / `payload.roadmap_entry_id` from a
+      queued observation; else an existing AAP entry with the same ID;
+      else an existing Long-term Plan candidate matched conservatively
+      by destination/date (promotion case); else legacy title+date
+      matching only during migration; else mint a fresh ID via
+      `POST /api/context/roadmap/id` using the Source/creation date.
+   2. If an existing AAP entry has this ID, merge: keep every
+      `✓ completed ...` Preparation Timeline row byte-for-byte; re-emit
+      non-completed taxonomy rows only for gaps by lead-time offset.
+      Never drop a completed row.
+   3. If no existing entry has this ID, emit a fresh entry with the ID
+      marker on the `###` heading.
+   4. Follow the `roadmap` skill for classification (Travel
+      international/domestic, Deadlines, Conferences, Recurring
+      milestones), per-class prep-line recipes, destination extraction,
+      and `travel_bookings` cross-check before emitting flight /
+      accommodation `[check]` lines.
+
+   Add **Agent Notes** under each event for supplementary info
+   (timezone differences, application URLs, tips, etc.).
+
+5. For each pending/running scheduled task fetched in Phase 1 step 2
+   that passed the importance / horizon filter, emit a `Scheduled:`
+   entry under `## Agent Action Plan` using the shape defined by the
+   `roadmap` skill. Preserve the existing ID for the same task id when
+   present; otherwise mint one with creation date = task `createdAt`
+   date (fallback to wake-up date if missing):
+
+   ```
+   ### Scheduled: <description>  (task #<id>)  <!-- id: rm-YYYYMMDD-abcdef -->
+   Source: scheduled.task — wake-up YYYY-MM-DD HH:MM
+   Status: ⏳ pending   (or ▶ running / ✓ completed / ✗ failed)
+   ```
+
+   Keep `Scheduled:` entries and event entries interleaved in
+   `## Agent Action Plan`, ordered by their primary date.
+
+6. Incorporate each pending `roadmap_candidate` observation fetched in
+   Phase 1 step 3. For each row, inspect `payload` and route per the
+   `roadmap` skill decision tree — into `## Agent Action Plan` if dated
+   and >48h out, `## Long-term Plans` if undated, or drop as noise. If
+   the candidate is already represented (e.g. a `travel_booking_detected`
+   refresh fired the same morning and an event entry already exists),
+   skip without duplicating. If `payload.roadmap_entry_id` is present,
+   consult that ID before emitting a new entry or matching by text.
+
+7. Consume the observations whose candidate was incorporated or
+   deliberately dropped — always pass the event correlation id:
+   ```
+   curl -s -X POST http://localhost:8321/api/observations/consume \
+     -H 'Content-Type: application/json' \
+     -d '{"ids":[<id>, ...], "correlationId": "<event_correlation_id>"}'
+   ```
+   Observations left pending here will re-appear on the next refresh.
+
+8. Remove entries by ID plus date, never by broad string matching.
+   Remove events only when their ID's primary date is outside the
+   retention window defined in the roadmap skill. Keep completed
+   Preparation Timeline rows while the entry itself remains in window.
+   Remove `Scheduled:` entries whose task `id` is not in the fresh
+   `/api/schedule` response (cancelled or already completed more than
+   a day ago).
+
+### Phase 3: Write
+9. Always write the full roadmap via PUT, even when no substantive
+   changes were warranted. Update `> Last synced` to today's date on
+   every run so the mtime advances deterministically. If
+   `<roadmap_write_lock_id>` is in context, include it as the
+   `X-Lock-Id` header so other concurrent writers see 409 and back off:
+   ```
+   curl -s -X PUT http://localhost:8321/api/context/roadmap \
+     -H 'Content-Type: application/json' \
+     -H 'X-Lock-Id: <roadmap_write_lock_id>' \
+     -d '{"content": "..."}'
+   ```
+
+   An empty `## Agent Action Plan` is permitted when no signals exist.
+
+   Required structure (preserve existing body inside each section;
+   `## Agent Action Plan` is merge-by-id):
+   ```
+   # Roadmap
+   > Last synced: YYYY-MM-DD
+
+   ## Annual Goals
+   (preserved verbatim from existing)
+
+   ## Quarterly Focus
+   (preserved verbatim from existing)
+
+   ## Long-term Plans
+   (preserved verbatim from existing; agent-writable via the roadmap
+    skill for undated long-horizon intents — do not clear this section
+    during refresh)
+
+   ## Agent Action Plan
+
+   ### YYYY-MM-DD ~ MM-DD: Event Title  <!-- id: rm-YYYYMMDD-abcdef -->
+   Source: Google Calendar / Notion / etc.
+
+   **Preparation Timeline:**
+   - YYYY-MM-DD [tag]: Action description
+   - ✓ completed YYYY-MM-DD: YYYY-MM-DD [tag]: Completed action
+   - ...
+
+   **Agent Notes:**
+   - Supplementary information
+
+   ### Scheduled: <description>  (task #<id>)  <!-- id: rm-YYYYMMDD-abcdef -->
+   Source: scheduled.task — wake-up YYYY-MM-DD HH:MM
+   Status: ⏳ pending
+
+   ## Recurring
+   (preserved verbatim from existing)
+   ```
+
+10. If the PUT returns 400 from the roadmap transition guard (for
+    example, a completed row was dropped), recover once:
+    1. Re-GET `/api/context/roadmap`.
+    2. Re-run the merge using the current body as authoritative,
+       preserving every `✓ completed ...` row byte-for-byte.
+    3. retry the full PUT once with the same lock id.
+    4. If the second write also returns 400, do not write the regenerated
+       Agent Action Plan. Instead, PUT a minimal update that only bumps
+       `> Last synced` on the current body, append a diagnostic section
+       to `agent/journal.md` with the validation error and affected IDs,
+       and end silently.
+
+### Important
+- Do NOT notify the user about this refresh — it is a background maintenance task.
+- If no calendar events are found and no scheduled tasks are pending,
+  write a minimal roadmap preserving existing goals / Long-term Plans /
+  Recurring with an empty `## Agent Action Plan`. Always bump
+  `> Last synced`.
+- Keep roadmap.md concise — only include events that benefit from advance preparation.
+  Skip routine daily meetings, standups, 1-on-1s, etc.

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

@@ -0,0 +1,172 @@
+{context}
+
+## Task: Refresh today.md — dashboard-triggered manual refresh
+
+The user clicked **Regenerate** on the dashboard. This is a narrow refresh
+of the `## User Schedule` section from live calendar state — **not** a new
+day rotation and **not** a morning routine.
+
+### Ground rules (apply at every step)
+
+- **Silent-by-default.** Do NOT call `POST /api/notify`. The dashboard UI
+  shows status from this session directly; a DM would duplicate.
+- **No rotation, no Handoff edit.** Do NOT archive, delete, or move
+  sections. Do NOT write to `## Handoff`, `## Agent Notes`, `## User
+  Tasks`, or `## Agent Plan`.
+- **Read-before-write.** `PATCH section=user_schedule mode=replace`
+  overwrites the entire body; always fetch current state first.
+- **Respect the Morning Routine lock.** The lock applies to `today.md`
+  as a whole — both section PATCHes are blocked when it is held. If a
+  PATCH returns `409`, retry up to 3 times with a 30 s pause between
+  tries. If still locked after the final retry, **return a one-line
+  status (`deferred — morning routine lock held`) and stop**. Do NOT
+  attempt to append a deferred line to `## Agent Log` — that PATCH is
+  also blocked by the same lock. The next morning/hourly run will
+  reconcile.
+
+### Step 1 — Fetch today's calendar events
+
+The fetch path depends on the current Google Calendar mode (read
+`<integration_modes>` injected above).
+
+<!-- mode:direct:google_calendar -->
+**Direct mode** — daemon polls Google Calendar; call its proxy:
+
+```
+curl -s 'http://localhost:8321/api/calendar/events?date=today&days=1'
+```
+
+- 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.
+
+```
+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
+  }'
+```
+
+- 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 -->
+
+### Processing rules (apply after a successful fetch above)
+
+- 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:
+  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
+     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
+     `- No scheduled events today`.
+
+### Step 2 — Replace the User Schedule section
+
+```
+curl -s -X PATCH http://localhost:8321/api/context/today \
+  -H 'Content-Type: application/json' \
+  -d '{"section": "user_schedule", "mode": "replace", "content": "<formatted lines>"}'
+```
+
+- Send ONLY the formatted event lines from Step 1. Do not include the
+  `## User Schedule` heading itself — the API manages section boundaries.
+- If `409` Morning Routine lock: see retry-then-defer rule above.
+
+### Step 3 — Log the refresh
+
+Append one line to `## Agent Log` (skip this step entirely when Step 1
+hit the error path or Step 2 gave up after 409 retries — see Ground
+rules):
+
+```
+curl -s -X PATCH http://localhost:8321/api/context/today \
+  -H 'Content-Type: application/json' \
+  -d '{"section": "agent_log", "mode": "append", "content": "- HH:MM Manual refresh: user_schedule updated (<N> events)."}'
+```
+
+Use the local `HH:MM` from `<current_time>` and the actual event count
+`<N>` from Step 1.
+
+### Output contract
+
+Your final text is an internal log — the daemon does NOT forward it.
+The dashboard watches `today.md` mtime to detect completion. Return a
+one-line status like `user_schedule refreshed — N events` (or the
+skip reason) and stop.