@aitne-sh/aitne 0.1.3 → 0.1.4

package/agent-assets/task-flows/message.received.dm.native.codex.md

@@ -0,0 +1,57 @@
+{context}
+
+## DM Reply — Native Mode (Codex connectors)
+
+Variant of `message.received.dm` selected when at least one integration
+the agent may need to reach during this DM is in `native` mode and the
+session backend (Codex) matches the integration's `nativeBackend`.
+
+> **Connector routing (native).** `<integration_modes>` carries
+> `gmail`, `google_calendar`, and `notion` mode attributes plus
+> `<key>_native_backend="<backend>"` for every native key. For any
+> native integration the user's DM may need:
+>
+> - Call `mcp__codex_apps__<service>._*` MCP tools directly. The Codex
+>   namespace terminates with `._` — the bare suffix from each skill's
+>   `SKILL.native.codex.md` body is what you append.
+> - Do **NOT** call `POST /api/integrations/<key>/exec` (410 in native).
+> - Do **NOT** call the per-integration daemon routes
+>   (`/api/calendar/*`, `/api/notion/query|search|pages|...`, Gmail
+>   accounts under `/api/mail/*`) — each returns 410 in native mode.
+> - Write-class MCP calls (per registry `destructiveTools`) require
+>   explicit user confirmation; the absolute-block layer continues to
+>   fire.
+> - Direct-mode siblings keep using their direct routes — native gate
+>   is per-key.
+
+### Per-session integration routing
+
+<integration-routing-table>
+
+### Native MCP routing — per integration
+
+**Calendar — real-time queries.** When `google_calendar="native"`, use
+the `mcp__codex_apps__google_calendar._*` MCP tools (`_search` /
+`_search_events` / `_read_event` / `_fetch` / `_get_availability` +
+destructive set). `/api/calendar/*` and
+`POST /api/integrations/google_calendar/exec` both return 410.
+
+**Mail — DM read / draft / reply.** When `gmail="native"`, use the
+`mcp__codex_apps__gmail._*` MCP tools per the `mail` skill's native
+body (`_search_emails` / `_read_email` / `_read_email_thread` /
+`_create_draft`). Destructive set (`_send_email` / `_send_draft` /
+`_forward_emails` / `_delete_emails` / `_archive_emails` / etc.)
+requires explicit user confirmation. For non-Gmail accounts (IMAP /
+Outlook / iCloud / Yahoo), keep using the direct-mode
+`/api/mail/<acct>/*` routes per the base `mail` skill body.
+
+**Notion — DM read / search.** When `notion="native"`, use the
+`mcp__codex_apps__notion._*` MCP tools (`_search` / `_fetch` /
+`_notion_query_data_sources` for structured filters). The
+`/api/notion/databases` config dump remains reachable in every mode.
+
+The dispatch decision flow (capture user info, profile-question
+reconcile, compose reply, route durable intent) is shared with the
+direct variant via the `{{> base }}` partial below.
+
+{{> base }}

package/agent-assets/task-flows/message.received.dm.native.gemini.md

@@ -0,0 +1,70 @@
+{context}
+
+## DM Reply — Native Mode (Gemini connectors)
+
+Variant of `message.received.dm` selected when at least one integration
+the agent may need to reach during this DM is in `native` mode and the
+session backend (Gemini) matches the integration's `nativeBackend`.
+
+> **Connector routing (native).** `<integration_modes>` carries
+> `gmail`, `google_calendar`, and `notion` mode attributes plus
+> `<key>_native_backend="<backend>"` for every native key. For any
+> native integration the user's DM may need:
+>
+> - Call `mcp_google-workspace_*.*` and `mcp_notion_*` MCP tools
+>   directly. Gemini's namespace convention uses single underscores
+>   between server and tool names with `.` as the inner separator (see
+>   each skill's `SKILL.native.gemini.md` body for exact tool names).
+> - Do **NOT** call `POST /api/integrations/<key>/exec` (410 in native).
+> - Do **NOT** call the per-integration daemon routes
+>   (`/api/calendar/*`, `/api/notion/query|search|pages|...`, Gmail
+>   accounts under `/api/mail/*`) — each returns 410 in native mode.
+> - Write-class MCP calls (per registry `destructiveTools`) require
+>   explicit user confirmation; the absolute-block layer continues to
+>   fire.
+> - Direct-mode siblings keep using their direct routes.
+> - **Gemini-specific quirks** (carry over from delegated mode):
+>   `maxResults` is silently ignored on Gmail `search` and Calendar
+>   `listEvents` — narrow the query window when the result is larger
+>   than expected.
+
+### Per-session integration routing
+
+<integration-routing-table>
+
+### Native MCP routing — per integration
+
+**Calendar — real-time queries.** When `google_calendar="native"`, use
+the `mcp_google-workspace_calendar.*` MCP tools (`listEvents` /
+`getEvent` / `list` (list calendars) / `findFreeTime` + destructive
+set). `/api/calendar/*` and
+`POST /api/integrations/google_calendar/exec` both return 410.
+`maxResults` is silently ignored on `listEvents` — narrow the window
+when needed. The default `attendeeResponseStatus` excludes declined
+events; pass the full list explicitly when declined meetings are
+relevant.
+
+**Mail — DM read / draft / reply.** When `gmail="native"`, use the
+`mcp_google-workspace_gmail.*` MCP tools per the `mail` skill's
+native body (`search` / `get` / `createDraft`). Destructive set
+(`send` / `sendDraft` / `modify` / `modifyThread` / `createLabel` /
+`batchModify`) requires explicit user confirmation. The extension
+has no dedicated `delete` or `forward` tool — compose from primitives.
+For non-Gmail accounts (IMAP / Outlook / iCloud / Yahoo), keep using
+the direct-mode `/api/mail/<acct>/*` routes per the base `mail` skill
+body.
+
+**Notion — DM read / search.** When `notion="native"`, use the
+`mcp_notion_*` MCP tools per the `notion` skill's native body
+(`mcp_notion_notion-search` / `mcp_notion_notion-fetch` and the
+destructive set). The descriptor assumes the user registered Notion's
+official MCP server under the literal name `notion`
+(`gemini mcp add notion <url>`); the §9.3 probe at flip time verifies
+presence. The `/api/notion/databases` config dump remains reachable in
+every mode.
+
+The dispatch decision flow (capture user info, profile-question
+reconcile, compose reply, route durable intent) is shared with the
+direct variant via the `{{> base }}` partial below.
+
+{{> base }}

package/agent-assets/task-flows/message.received.dm_first.md

@@ -86,6 +86,9 @@ same-backend delegated → use your session's native Google Calendar MCP tools (
 <!-- mode:delegated-cross:google_calendar -->
 cross-backend delegated → call `POST /api/integrations/google_calendar/exec` with a natural-language `task` + `outputSchema`, via the external-services skill. Do NOT call `/api/calendar/events` (returns 410) and do NOT fall back to your own backend's native Calendar MCP tools — they read a different Google account.
 <!-- /mode:delegated-cross:google_calendar -->
+<!-- mode:native:google_calendar -->
+native → your session backend's native Google Calendar MCP tools (see the `external-services` skill's native body for the exact tool namespace per backend). `/api/calendar/*` returns 410 in native mode and `POST /api/integrations/google_calendar/exec` returns 410 with `X-Integration-Mode: native` — do NOT call either; the daemon does not proxy Calendar in native mode.
+<!-- /mode:native:google_calendar -->
 <!-- mode:disabled:google_calendar -->
 disabled → tell the user real-time calendar access is unavailable in this configuration; work from the morning snapshot in <today> only.
 <!-- /mode:disabled:google_calendar -->

package/agent-assets/task-flows/message.received.dm_first.native.claude.md

@@ -0,0 +1,56 @@
+{context}
+
+## DM — First Message of the Day (Native Mode — Claude connectors)
+
+This is the first DM of today. <today> contains today's schedule,
+user tasks, and the agent's day plan. Variant of
+`message.received.dm_first` selected when at least one integration is
+in `native` mode bound to Claude.
+
+Behavior is identical to `message.received.dm.native.claude.md` except
+for the first-day delta in Step 3 (you may briefly preview the user's
+most imminent task as a follow-up question — handled by the base
+`message.received.dm_first.md` flow inlined below).
+
+> **Connector routing (native).** `<integration_modes>` carries
+> `<key>_native_backend="claude"` for every native key. For any native
+> integration the user's DM may need:
+>
+> - Call `mcp__claude_ai_<Service>__*` MCP tools directly per each
+>   skill's `SKILL.native.claude.md` body.
+> - Do **NOT** call `POST /api/integrations/<key>/exec` (410 in native).
+> - Do **NOT** call the per-integration daemon routes — each returns
+>   410 in native mode.
+> - Write-class MCP calls require explicit user confirmation.
+> - Direct-mode siblings keep using their direct routes.
+
+### Per-session integration routing
+
+<integration-routing-table>
+
+### Native MCP routing — per integration
+
+**Calendar.** When `google_calendar="native"`, use
+`mcp__claude_ai_Google_Calendar__*` MCP tools (`list_events` /
+`get_event` / `list_calendars` / `suggest_time`). `/api/calendar/*` and
+`POST /api/integrations/google_calendar/exec` both return 410.
+Destructive calendar tools require explicit user confirmation.
+
+**Mail.** When `gmail="native"`, use `mcp__claude_ai_Gmail__*` MCP
+tools per the `mail` skill's native body. Claude's hosted Gmail
+connector is **draft-only** — there is no send / forward / delete
+surface; if the user asks to send, point them at the Gmail web UI.
+For non-Gmail accounts (IMAP / Outlook / iCloud / Yahoo), keep using
+the direct-mode `/api/mail/<acct>/*` routes per the base `mail`
+skill body.
+
+**Notion.** When `notion="native"`, use the
+`mcp__claude_ai_Notion__*` MCP tools. `/api/notion/databases` (label
+→ UUID config dump) remains reachable in every mode.
+
+The first-DM dispatch decision flow (capture user info, profile-question
+reconcile, compose reply with the optional 1–2 task preview, route
+durable intent) is shared with the direct first-DM variant via the
+`{{> base }}` partial below.
+
+{{> base }}

package/agent-assets/task-flows/message.received.dm_first.native.codex.md

@@ -0,0 +1,48 @@
+{context}
+
+## DM — First Message of the Day (Native Mode — Codex connectors)
+
+This is the first DM of today. <today> contains today's schedule,
+user tasks, and the agent's day plan. Variant of
+`message.received.dm_first` selected when at least one integration is
+in `native` mode bound to Codex.
+
+Behavior is identical to `message.received.dm.native.codex.md` except
+for the first-day delta in Step 3 (handled by the base
+`message.received.dm_first.md` flow inlined below).
+
+> **Connector routing (native).** Use
+> `mcp__codex_apps__<service>._*` MCP tools directly. Do **NOT** call
+> `POST /api/integrations/<key>/exec` (410) or the per-integration
+> daemon routes (410). Write-class MCP calls require explicit user
+> confirmation; direct-mode siblings keep using their direct routes.
+
+### Per-session integration routing
+
+<integration-routing-table>
+
+### Native MCP routing — per integration
+
+**Calendar.** When `google_calendar="native"`, use
+`mcp__codex_apps__google_calendar._*` MCP tools (`_search` /
+`_search_events` / `_read_event` / `_fetch` / `_get_availability` +
+destructive set). `/api/calendar/*` and
+`POST /api/integrations/google_calendar/exec` both return 410.
+
+**Mail.** When `gmail="native"`, use `mcp__codex_apps__gmail._*` MCP
+tools. Destructive set (`_send_email` / `_send_draft` /
+`_forward_emails` / `_delete_emails` / `_archive_emails` / ...)
+requires explicit user confirmation. For non-Gmail accounts keep
+using `/api/mail/<acct>/*`.
+
+**Notion.** When `notion="native"`, use `mcp__codex_apps__notion._*`
+MCP tools. `_notion_query_data_sources` is the SQL-style structured
+query for property-shaped intents (Codex-only capability).
+`/api/notion/databases` config dump is reachable in every mode.
+
+The first-DM dispatch decision flow (capture user info, profile-question
+reconcile, compose reply with the optional 1–2 task preview, route
+durable intent) is shared with the direct first-DM variant via the
+`{{> base }}` partial below.
+
+{{> base }}

package/agent-assets/task-flows/message.received.dm_first.native.gemini.md

@@ -0,0 +1,54 @@
+{context}
+
+## DM — First Message of the Day (Native Mode — Gemini connectors)
+
+This is the first DM of today. <today> contains today's schedule,
+user tasks, and the agent's day plan. Variant of
+`message.received.dm_first` selected when at least one integration is
+in `native` mode bound to Gemini.
+
+Behavior is identical to `message.received.dm.native.gemini.md`
+except for the first-day delta in Step 3 (handled by the base
+`message.received.dm_first.md` flow inlined below).
+
+> **Connector routing (native).** Use `mcp_google-workspace_*.*` and
+> `mcp_notion_*` MCP tools directly. Do **NOT** call
+> `POST /api/integrations/<key>/exec` (410) or the per-integration
+> daemon routes (410). Write-class MCP calls require explicit user
+> confirmation; direct-mode siblings keep using their direct routes.
+> **Gemini quirks**: `maxResults` is silently ignored on Gmail
+> `search` and Calendar `listEvents` — narrow the query window when
+> the result is larger than expected.
+
+### Per-session integration routing
+
+<integration-routing-table>
+
+### Native MCP routing — per integration
+
+**Calendar.** When `google_calendar="native"`, use
+`mcp_google-workspace_calendar.*` MCP tools (`listEvents` / `getEvent`
+/ `list` / `findFreeTime` + destructive set). `maxResults` silently
+ignored on `listEvents`; default `attendeeResponseStatus` excludes
+declined events (pass full list explicitly when needed).
+`/api/calendar/*` and `POST /api/integrations/google_calendar/exec`
+both return 410.
+
+**Mail.** When `gmail="native"`, use `mcp_google-workspace_gmail.*`
+MCP tools. The extension has no dedicated `delete` or `forward` tool
+— compose from primitives (delete = `modify` + add TRASH; forward =
+`send` with re-quoted body). Destructive set requires explicit user
+confirmation. For non-Gmail accounts keep using `/api/mail/<acct>/*`.
+
+**Notion.** When `notion="native"`, use `mcp_notion_*` MCP tools per
+the `notion` skill's native body. No SQL-style structured query
+exists on this connector — use `mcp_notion_notion-search` for
+property-shaped intents and filter client-side.
+`/api/notion/databases` config dump is reachable in every mode.
+
+The first-DM dispatch decision flow (capture user info, profile-question
+reconcile, compose reply with the optional 1–2 task preview, route
+durable intent) is shared with the direct first-DM variant via the
+`{{> base }}` partial below.
+
+{{> base }}

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

@@ -18,6 +18,32 @@ Close out today and prepare tomorrow. Steps 1–3 are internal bookkeeping
 (Morning Routine depends on them). Step 4 is the ONLY user-visible output,
 and it must be written for the user — not as a report of what you just did.
 
+### Step 0 — Read today's mail outcomes
+
+The pre-pass fetcher session (`routine.fetch_window`) ran ahead of you
+and posted observations for the `today_outcomes` window (mail sent /
+replied since the agent-day start) for every active mail integration.
+The `<fetch_report>` block in your prompt tells you the pre-pass
+status — `success` / `partial` means the table is fresh; `skipped`
+means every mail integration is disabled and this step contributes
+nothing to the wrap-up; `failed` means trust no row newer than the
+prior tick and treat the section as best-effort.
+
+Drain pending mail observations with the agent-day-start floor — the
+daily synthesis already has the morning inflows from the morning
+routine:
+
+```
+GET /api/observations?pending=true&source_prefix=gmail:,outlook_mail:&observed_at_after=<agent_day_start_iso>&limit=50
+```
+
+Fold meaningful items into the in-memory state you carry into Step 1
+(Finalize today.md — Agent Log entries when an outbound reply closed a
+loop) and Step 4 (Wrap-up — an unanswered inbound that surfaced today
+might satisfy trigger (b)). Do NOT push back into the mail provider —
+this step is read-only; outbound replies belong to the user / morning
+routine / DM-reply paths.
+
 ### Step 1 — Finalize today.md
    - Check incomplete ## User Tasks status and mark accordingly.
    - Reconcile ## Agent Plan: every row whose HH:MM has already passed should be
@@ -312,7 +338,8 @@ wrap-up contract** in the notify skill. That contract owns:
   - the 4-line cap and markdown rules,
   - the no-ceremony / no-filler-timing-commentary rule,
   - the no-internal-mechanism-names vocabulary rule,
-  - the language and tone from the Character block (always present when set),
+  - output language per `<output_language_policy>` and tone from the
+    Character block (always present when set),
   - the good / bad worked examples (including the exact anti-pattern
     the user has flagged).
 

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

@@ -0,0 +1,93 @@
+{context}
+
+## Routine Data-Fetch Pre-Pass
+
+You are the **pre-pass fetcher** dispatched by the daemon immediately
+ahead of a parent routine session. Your sole job is to materialise the
+`<fetch>` rows from the `<acquisition-plan>` block in your prompt into
+fresh `/api/observations` rows. The parent routine reads those rows
+after you terminate; you do not write to context files, do not
+synthesize, and do not notify the owner.
+
+Read the `<acquisition-plan>` block carefully — every row carries the
+exact `(integration, mode, window, account?, query)` tuple the daemon
+already resolved for you. Trust that routing: do **not** probe MCP
+registries, do **not** guess tool names, do **not** call the daemon's
+`/api/integrations/<key>/exec` proxy for any `userManagedConnector`
+integration (`outlook_mail`, `outlook_calendar` today). If a row has
+no usable surface, append a `no-surface` error entry and move on.
+
+For every `<fetch>` row, follow the matching integration partial
+below. Each partial owns the wire surface for its `(integration, mode)`
+cell — `applyIntegrationModeFilter` has already pruned the inactive
+branches, so the body you see is the one that applies for the current
+deployment state.
+
+### Step 1 — Fetch every row in `<acquisition-plan>`
+
+For each `<fetch integration="…" mode="…" window="…" query="…" account="…?">` element:
+
+- `integration="gmail"`     → follow the gmail mail partial below.
+- `integration="outlook_mail"` → follow the outlook_mail mail partial below.
+- `integration="google_calendar"`   → follow the google_calendar partial below.
+- `integration="outlook_calendar"`  → follow the outlook_calendar partial below.
+- `integration="notion"`    → follow the notion partial below.
+
+If `<acquisition-plan>` carries no `<fetch>` rows (an empty plan is
+legal — every routine has at least the wrapper) print the
+`{"fetched":0,"posted":0,"duplicates":0,"errors":[]}` JSON line and
+terminate.
+
+{include:_partials/mail-acquire.gmail.md}
+
+{include:_partials/mail-acquire.outlook_mail.md}
+
+{include:_partials/calendar-acquire.google_calendar.md}
+
+{include:_partials/calendar-acquire.outlook_calendar.md}
+
+{include:_partials/notion-acquire.notion.md}
+
+### Step 2 — Emit a single JSON line and terminate
+
+After every row has been processed (success, duplicate, or recorded
+error), emit exactly one JSON line on stdout with the shape:
+
+```json
+{"fetched":<int>,"posted":<int>,"duplicates":<int>,"errors":[<{type,...}>]}
+```
+
+- `fetched`    — total items returned by upstream APIs across every row.
+- `posted`     — count of 2xx responses from `/api/observations` (new rows).
+- `duplicates` — count of 409 responses (server-side dedup-hash collision).
+- `errors`     — list of `{type, ...}` records. Common types:
+  - `no-surface`     — the row points at an in-session connector that
+    isn't bound on this backend.
+  - `unexpected-row` — `mode="disabled"` slipped past the daemon
+    filter (defensive).
+  - `fetch-failed`   — upstream API returned a non-2xx; include
+    `{type, integration, account?, status, message}`.
+  - `budget-exhausted` — you hit the configured `max_turns` /
+    `max_budget_usd` for `routine.fetch_window`. Include
+    `{type, remaining: <fetch-row-summary>}` so the audit trail
+    surfaces which rows were not attempted.
+
+Do NOT print prose around the JSON line — the dispatcher reads the
+last JSON-shaped object on stdout. A malformed line surfaces as a
+`pre-pass-failed` error in the parent routine's `<fetch_report>`
+block and the parent continues with whatever observations the rest of
+the plan produced.
+
+### Hard guardrails
+
+- Do NOT call `/api/context/*` (read or write). The parent routine
+  owns every context-MD file.
+- Do NOT call `/api/notify`. The pre-pass is invisible to the owner
+  by contract.
+- Do NOT spawn sub-agents (Task tool or otherwise). Keep the run flat
+  so the dispatcher can clamp turn / budget cleanly.
+- `actor` on every `/api/observations` POST MUST be `"agent"` — the
+  server rejects `"user"`.
+- Do NOT compute a `contentHash` yourself; the server derives it from
+  `(source, payload)`. A 409 means dedup — count it in `duplicates`
+  and continue.

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

@@ -17,13 +17,51 @@ framework for the observation-review step; additional checks the user
 has added to the routine file run alongside them using the same
 routing rules.
 
-Use the observations skill to fetch pending user-originated items:
-GET /api/observations?pending=true&actor=user&limit=20. Follow the
+Output language: follow `<output_language_policy>` (Policy B for any
+context-MD write-up; Policy C for the optional `POST /api/notify` DM).
+Agent log appends to `agent/journal.md` stay English (Policy A).
+
+Use the observations skill to fetch pending items. The pre-pass
+fetcher session (`routine.fetch_window`) ran ahead of you and posted
+small `unread_last_hour` / `imminent_2h` / `updated_1h` windows for
+every active mail / calendar / notion integration; both `actor=user`
+and `actor=agent` rows reach this session — the user-actor rows are
+vault / git / file activity, the agent-actor rows are the windows
+the pre-pass posted. The downstream steps draw on the merged view:
+
+```
+GET /api/observations?pending=true&limit=30
+```
+
+The legacy `actor=user&limit=20` query stays valid for sessions that
+only want the user-actor surface (e.g. early triage). Follow the
 context skill for today.md section formats and the day-type filter
 mapping — this prompt owns the decision workflow only. Most runs should
 do bookkeeping silently; only fire POST /api/notify on the urgency gate
 in Step 8 below.
 
+### Step 0 — Read pre-pass `<fetch_report>`
+
+The `<fetch_report>` block in your prompt tells you the pre-pass
+status:
+
+- `status="success"` or `"partial"` → fresh mail / calendar / notion
+  rows are visible in `/api/observations?pending=true`. Trust the
+  table.
+- `status="failed"` → the pre-pass crashed or its output was
+  unparseable; treat the table as best-effort, fall back to
+  user-actor rows for this tick.
+- `status="skipped"` → no integration was active for this tick (or
+  every applicable cell resolved to disabled); the table carries
+  only user-actor signals.
+
+Window sizes are intentionally small by design (typical: 0–2 mail
+items, 0–1 calendar item, 0–3 notion pages) so this step costs
+near-nothing on most ticks. The pre-pass partial bodies own the
+per-(integration, mode) wire surface — do NOT call upstream
+integration APIs from this session; treat the observations table as
+authoritative from Step 1 onward.
+
 ### Execution budget
 Target: 5–10 turns. If you reach 15 turns, wrap up current work and log.
 Do NOT read roadmap.md, projects/*.md, or user/*.md unless an
@@ -32,9 +70,10 @@ milestone, or deliverable — not merely a file edit in a watched repo).
 
 ### Stage gate decision (cost-reduction-structural §B)
 When `<gate_decision>` is present, this run was escalated through the
-three-stage funnel (Stage 1 deterministic gate or Stage 2 lite-tier
-triage). The block tells you *why* you were spawned — pull the
-`reason` and `signals_snapshot` into your prioritisation. Examples:
+three-stage funnel (Stage 0 deterministic gate or Stage 2 lite-tier
+triage; Stage 3 is the current session). The block tells you *why*
+you were spawned — pull the `reason` and `signals_snapshot` into
+your prioritisation. Examples:
 
 - `reason: vip_mail_unread` → start with the mail observation, do not
   scan obsidian noise first.

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

@@ -30,6 +30,17 @@ workflow; the skill owns the file contract.
 ### Phase 1: Gather the month
 1. Determine the target file name from <current_time>:
    `monthly/YYYY-MM.md`.
+
+**Pre-pass acquisition (none).** Unlike morning / hourly / today_refresh /
+evening / weekly, monthly_review does NOT trigger an `<acquisition-plan>`
+block — the 30-day calendar window already arrives via the
+`<calendar_events_30d>` ContextBuilder block (multi-provider after the
+§6.6 generalization), and mail / notion signals already flowed through
+daily journals over the course of the month. The monthly review is
+**summative**, not reactive; it synthesises across previously-captured
+state rather than fetching fresh windows. If the dispatcher emitted any
+`<fetch>` rows for this routine (a misconfiguration), ignore them and
+continue.
 2. Fetch source material for the current month:
    - Use GET /api/context/list/daily to discover archived daily files and
      read each `daily/YYYY-MM-DD.md` in the current month.
@@ -211,7 +222,7 @@ weekly section of agent/journal.md: `silent monthly wrap-up — nothing
 actionable`.
 
 #### 4b. When you DO notify — content rules
-Answer, in the user's preferred language from the Character block:
+Output language: follow `<output_language_policy>`. Answer:
   1. **The biggest win of the month** (1 line).
   2. **The single most important open loop carrying into next month**, with
      a brief user-meaningful reason. Omit if Outstanding Items is empty.
@@ -232,7 +243,7 @@ days and is visibly slipping.
   - Priority `normal`. Respects quiet hours via the notify skill contract.
   - Exactly ONE notification via POST /api/notify. Do not split.
 
-#### 4d. Shape example (illustrative — translate to user's language)
+#### 4d. Shape example (illustrative — render in the language `<output_language_policy>` resolves to)
 Good (something worth saying):
     Biggest win of April: Phase 1 of {APP_NAME} shipped on time.
     Still open: the Phase 2 scope call — you'll want a decision before week 2.