@aitne-sh/aitne 0.1.4 → 0.1.6

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

@@ -13,8 +13,9 @@ session backend (Claude) matches the integration's `nativeBackend`.
 > actionable per-integration routing table is what you act on. For any
 > native integration the user's DM may need:
 >
-> - Call `mcp__claude_ai_<Service>__*` MCP tools directly. The exact
->   tool namespace per service is documented in each skill's
+> - Call the in-session connector tools your harness exposes for that
+>   service directly. Your tool menu lists every available tool at
+>   session start. Per-service guidance lives in each skill's
 >   `SKILL.native.claude.md` body materialised for this session
 >   (`mail`, `external-services`, `notion`).
 > - Do **NOT** call `POST /api/integrations/<key>/exec` — returns 410
@@ -22,7 +23,7 @@ session backend (Claude) matches the integration's `nativeBackend`.
 > - Do **NOT** call the per-integration daemon routes listed in
 >   `<integration-routing-table>` as `(DO NOT call /api/<key>/*)` —
 >   each route-prefix returns 410 in native mode.
-> - Write-class MCP calls (per each connector's registry
+> - Write-class connector calls (per each connector's registry
 >   `destructiveTools` set) still require explicit user confirmation
 >   per `docs/design/09-safety-cost.md` §7. The absolute-block layer
 >   continues to fire regardless of mode.
@@ -35,38 +36,36 @@ session backend (Claude) matches the integration's `nativeBackend`.
 
 <integration-routing-table>
 
-### Native MCP routing — per integration
+### Native connector routing — per integration
 
 The Calendar / Mail / Notion entries below override the matching
 sections in the shared base flow. Mode-conditional markers in the base
 (`<!-- mode:native:google_calendar -->`) still fire, but the explicit
-prose here carries the exact tool namespace and the safety contract
-for Claude's hosted connectors so the agent does not have to derive it
-mid-turn.
+prose here carries the per-service intent and the safety contract for
+in-session connectors so the agent does not have to derive it mid-turn.
 
 **Calendar — real-time queries.** When `google_calendar="native"`, use
-the `mcp__claude_ai_Google_Calendar__*` MCP tools (`list_events` /
-`get_event` / `list_calendars` / `suggest_time`). See the
-`external-services` skill's native body for argument shapes and the
-destructive-confirm contract for `create_event` / `update_event` /
-`delete_event` / `respond_to_event`. `/api/calendar/*` returns 410.
-`POST /api/integrations/google_calendar/exec` returns 410.
+your in-session Google Calendar connector (list events / get event /
+list calendars / suggest free-busy slot). See the `external-services`
+skill's native body for capability shapes and the destructive-confirm
+contract for create / update / delete / RSVP. `/api/calendar/*` returns
+410. `POST /api/integrations/google_calendar/exec` returns 410.
 
-**Mail — DM read / draft / reply.** When `gmail="native"`, use the
-`mcp__claude_ai_Gmail__*` MCP tools per the `mail` skill's native
-body (`search_threads` / `get_thread` / `create_draft` / label
-operations). Claude's hosted Gmail connector is **draft-only** —
-there is no send / forward / delete surface. If the user explicitly
-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.
+**Mail — DM read / draft / reply.** When `gmail="native"`, use your
+in-session Gmail connector per the `mail` skill's native body (search
+threads / read thread / create draft / label operations). The hosted
+Gmail connector is typically **draft-only** — there is no send /
+forward / delete surface. If the user explicitly 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 — DM read / search / page operations.** When `notion="native"`,
-use the `mcp__claude_ai_Notion__*` MCP tools per the `notion` skill's
-native body (`notion-search` / `notion-fetch` / read-class + the
-destructive set). `/api/notion/databases` (label → UUID config dump)
-is still reachable in every mode — consult it before any Notion
-read so the MCP call carries a concrete UUID.
+use your in-session Notion connector per the `notion` skill's native
+body (search / fetch / read-class + the destructive set).
+`/api/notion/databases` (label → UUID config dump) is still reachable
+in every mode — consult it before any Notion read so the connector
+call carries a concrete UUID.
 
 The dispatch decision flow (capture user info, profile-question
 reconcile, compose reply, route durable intent) is identical to the

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

@@ -11,16 +11,18 @@ session backend (Codex) matches the integration's `nativeBackend`.
 > `<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.
+> - Call the in-session connector tools your harness exposes for that
+>   service directly. Your tool menu lists every available tool at
+>   session start. Per-service guidance lives in each skill's
+>   `SKILL.native.codex.md` body materialised for this session
+>   (`mail`, `external-services`, `notion`).
 > - 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.
+> - Write-class connector 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.
 
@@ -28,26 +30,30 @@ session backend (Codex) matches the integration's `nativeBackend`.
 
 <integration-routing-table>
 
-### Native MCP routing — per integration
+### Native connector 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
+your in-session Google Calendar connector (search / window-list events
+/ read event / batch-read / free-busy + destructive set). See the
+`external-services` skill's native body for capability shapes and the
+destructive-confirm contract for create / update / delete / RSVP.
+`/api/calendar/*` and `POST /api/integrations/google_calendar/exec`
+both return 410.
+
+**Mail — DM read / draft / reply.** When `gmail="native"`, use your
+in-session Gmail connector per the `mail` skill's native body (search /
+read / read-thread / create-draft). The Codex-side hosted Gmail
+connector typically exposes a richer destructive surface than Claude's
+(send / send-draft / forward / delete / archive / label / batch
+modify); each of those capability classes 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 your
+in-session Notion connector per the `notion` skill's native body
+(search / fetch + the structured query primitive when the connector
+exposes it, for property-shaped intents like "tasks in status X"). The
 `/api/notion/databases` config dump remains reachable in every mode.
 
 The dispatch decision flow (capture user info, profile-question

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

@@ -11,57 +11,57 @@ session backend (Gemini) matches the integration's `nativeBackend`.
 > `<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).
+> - Call the in-session connector tools your harness exposes for that
+>   service directly. Your tool menu lists every available tool at
+>   session start. Per-service guidance lives in each skill's
+>   `SKILL.native.gemini.md` body materialised for this session
+>   (`mail`, `external-services`, `notion`).
 > - 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.
+> - Write-class connector 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.
+> - **Gemini-specific quirks** (typical of the `google-workspace`
+>   extension): `maxResults` is silently ignored on Gmail search and
+>   Calendar list-events — narrow the query window when the result is
+>   larger than expected.
 
 ### Per-session integration routing
 
 <integration-routing-table>
 
-### Native MCP routing — per integration
+### Native connector 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
+your in-session Google Calendar connector (list-events / get-event /
+list-calendars / find-free-time + destructive set). See the
+`external-services` skill's native body for capability shapes and the
+destructive-confirm contract. `/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.
+`maxResults` is typically silently ignored on list-events — narrow the
+window when needed. The default `attendeeResponseStatus` typically
+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.
+**Mail — DM read / draft / reply.** When `gmail="native"`, use your
+in-session Gmail connector per the `mail` skill's native body (search /
+read / create-draft). The destructive set (send / send-draft / modify
+/ modify-thread / create-label / batch-modify) requires explicit user
+confirmation. Some Gemini-side Gmail connectors expose no dedicated
+delete or forward tool — compose from primitives (delete = modify +
+add `TRASH`; forward = send with re-quoted body). 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.
+**Notion — DM read / search.** When `notion="native"`, use your
+in-session Notion connector per the `notion` skill's native body
+(search / fetch and the destructive set). Native:gemini mode assumes
+the user has registered a Notion MCP server against their Gemini CLI;
+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

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

@@ -4,7 +4,7 @@
 
 This is the first message in today's DM session. <today> contains today's schedule, the user's tasks, and the agent's day plan. Respond to <user_input> below, applying the steps in order.
 
-The behavior in this flow is identical to `message.received.dm.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).
+The behavior in this flow is identical to `message.received.dm.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 — but ONLY when the gates in §"First-day delta" pass, never on a content-rich opener).
 
 ### Step 1 — Capture user info silently (before replying)
 
@@ -38,10 +38,34 @@ The user must never feel they are filling out a profile.
 
 Apply the conversational profile's "speak as one agent" rule: phrase your knowledge as your own memory; never name internal storage, sections, files, or routines in user-visible text.
 
-#### First-day delta — optional 1–2 task preview
+#### No topic-pivoting trailing question (universal, non-negotiable)
+
+Never append a question that **changes the topic** of the user's message. A topic-continuing question (clarifier, follow-up, "want me to track this as X?" that flows from what the user just said) is fine when it reads as a natural beat in the same thread. A topic-pivoting question — about an unrelated task, deadline, or profile slot — is forbidden in the same reply, even if a gate's conditions for that ask are technically met.
+
+If the reply does not naturally invite a question of its own, end with a statement. The agent has other surfaces (the morning briefing, the `scheduled.dm` confirm sub-flow, observation alerts) for non-conversational asks — the inbound DM reply is not the only channel, and pushing them here costs the conversation more than it saves the agent.
+
+Worked examples (illustrate the topic-continuing vs. topic-pivoting distinction; tone follows persona / Character, NOT these example phrasings):
+
+| User opener | Acceptable trailing question | Forbidden trailing question |
+|---|---|---|
+| "I quit IBM Japan, moved to LA for a PM master's." | *"Want me to start tracking the program — syllabus, deadlines — as a project?"* (continues the share) | *"By the way, your 23:59 PT 407632 midterm is tomorrow — how's prep?"* (pivots to an unrelated deadline) |
+| "Feeling pretty drained today." | *(no trailing question — acknowledge the mood)* | *"What time should I remind you about the design review?"* (ignores the mood) |
+| "What's on today?" | *"Want a heads-up 15 min before the 2pm review?"* (continues the orientation) | *"Also — what city are you in these days?"* (latent-profile weave on a tight factual ask) |
+
+This rule covers the First-day delta below, the latent-profile-question weave in Step 2, and any future opportunistic ask. **When a gate would have asked here but this rule suppresses it, the gate SHOULD instead schedule a `confirm:` sub-flow row** (see `scheduled.dm.md` ## Confirmation follow-up) so the question lands at a natural moment without violating the thread.
+
+#### First-day delta — optional 1–2 task preview (gated)
 
 After responding to the user's actual message, you MAY briefly preview the user's 1–2 most imminent uncompleted tasks as a natural follow-up question. This delta only applies on the first DM of the day — once contact is established, subsequent DMs in `message.received.dm.md` skip this step.
 
+The preview is **opt-in by opener shape**, not the default:
+
+- **Eligible openers (preview welcome).** Short greetings ("morning", "hey", "hi", "yo") or explicit status queries ("what's on today", "schedule pls", "give me the day", "what's up"). The opener is generic with no embedded content; the user is asking for orientation. The preview is welcome here because the user has *asked* for it. Recognise the same opener shapes in any language the user writes in — the examples are English for prompt clarity only.
+- **Disqualifying openers (preview forbidden — stay in the thread).** Substantive personal share, mood / feeling, question about the agent's behaviour, or anything the agent needs to acknowledge first. When the opener carries content the agent must respond to, *stay in the thread* — defer the preview to the next DM or the morning briefing. Pivoting away from a content-rich opener violates the universal rule above.
+- **Compose-time length check.** If your reply is already 3+ lines acknowledging the user's content, do NOT append a task preview regardless of opener shape. The reply length is itself the signal that you are in conversation, not orientation.
+
+If the preview clears all three gates, surface 1–2 tasks:
+
 - Look at the user's uncompleted tasks (`- [ ] HH:MM ...` rows in `## User Tasks`). Do NOT include `## Agent Plan` rows — those are the agent's internal to-dos.
 - Parse the day-type filter on line 2 of <today>. Drop tasks whose category focus is `off`.
 - Surface the 1–2 closest to <current_time> by HH:MM (overdue rank first).
@@ -101,13 +125,28 @@ When an incoming message has an attachment or asks you to operate on one, attemp
 
 These dispatchers are not exclusive — multiple may apply to one message.
 
+**Confirm-reply continuation.** Before evaluating the per-domain
+dispatchers below, scan `<conversation_history>` for the most recent
+assistant message. If that message was a one-question confirm DM
+(emitted by `scheduled.dm.md` ## Confirmation follow-up — typical
+shape: a short single-question DM with no project/task name
+embedded), route the user's reply to the originating gate's **reply
+branches** based on the topic of the question, not on the literal
+text of the user's reply. A bare "yeah" / "no" / counter-proposal
+will not match the named-workstream shape the per-domain dispatchers
+expect, so without this routing rule the reply silently misses the
+gate. Example: confirm DM about *"track LA PM master's as a
+project?"* → user replies "yeah" → route through the context skill's
+"Project DM-intent detection" §"Reply branches" with branch=
+affirmative.
+
 **Scheduling.** Recurring ("every morning at 9", "weekly") → `POST /api/recurring-schedules`. One-shot ("tomorrow 3pm", "in 30 min") → `POST /api/schedule/dm` (pre-composed; default) or `POST /api/schedule` (wake-up). Edit / cancel / list use the same endpoints. Load the schedule skill for the request shape, dedup pre-check, and description contract. Use `<current_time>` for timezone resolution.
 
 Schedules go through this daemon — never through any cloud-hosted scheduled-agent feature your CLI may expose. Cloud routines cannot reach `localhost:8321`, so they cannot deliver via the user's chat platforms or use any integration registered here.
 
-**Long-horizon intent** (commitment, trip, deliverable, learning target beyond today) → route through the roadmap skill's "Long-horizon DM-intent detection". Ambiguous or speculative items belong in `agent-journal.md` as a candidate line for the next morning routine to confirm — do **not** write directly to `roadmap.md` without a clear positive signal.
+**Long-horizon intent** (commitment, trip, deliverable, learning target beyond today) → route through the roadmap skill's "Long-horizon DM-intent detection". Ambiguous or speculative items belong in `agent/journal.md` as a candidate line for the next morning routine to confirm — do **not** write directly to `roadmap.md` without a clear positive signal.
 
-**Project intent** (state, progress, milestone, blocker, or a new-project request for a named workstream) → route through the context skill's "Project DM-intent detection". A new project requires the DM-confirm gate before any write; silently inferring a slug is forbidden. A project update tied to a dated milestone runs both this dispatcher and the long-horizon one (see the context skill's "Tie-breakers").
+**Project intent** (state, progress, milestone, blocker, or a new-project request for a named workstream) → route through the context skill's "Project DM-intent detection". A new project requires the project-creation gate before any write; the gate's "No match" path schedules a `confirm:` DM rather than asking inline (see the context skill Step 3 and `scheduled.dm.md` ## Confirmation follow-up). Silently inferring a slug is forbidden. A project update tied to a dated milestone runs both this dispatcher and the long-horizon one (see the context skill's "Tie-breakers").
 
 ## User Message
 Platform: {event_data[platform]}

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

@@ -16,37 +16,37 @@ most imminent task as a follow-up question — handled by the base
 > `<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.
+> - Call the in-session connector tools your harness exposes for that
+>   service 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.
+> - Write-class connector 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
+### Native connector 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
+**Calendar.** When `google_calendar="native"`, use your in-session
+Google Calendar connector (list events / get event / list calendars /
+suggest free-busy slot). `/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.
+Destructive calendar capabilities require explicit user confirmation.
+
+**Mail.** When `gmail="native"`, use your in-session Gmail connector
+per the `mail` skill's native body. Hosted Gmail connectors are
+typically **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 your in-session Notion
+connector. `/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

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

@@ -11,34 +11,37 @@ 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
+> **Connector routing (native).** Use the in-session connector tools
+> your harness exposes for each native integration directly, per each
+> skill's `SKILL.native.codex.md` body. 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.
+> daemon routes (410). Write-class connector 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
+### Native connector 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
+**Calendar.** When `google_calendar="native"`, use your in-session
+Google Calendar connector (search / window-list events / read event /
+batch-read / free-busy + 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.
+**Mail.** When `gmail="native"`, use your in-session Gmail connector.
+The Codex-side hosted Gmail destructive surface (send / send-draft /
+forward / delete / archive / label / batch modify) requires explicit
+user confirmation. For non-Gmail accounts keep using
+`/api/mail/<acct>/*`.
+
+**Notion.** When `notion="native"`, use your in-session Notion
+connector. Use the structured query primitive when the connector
+exposes it (Codex-side hosted Notion connectors typically do — see the
+`notion` skill's native body); fall back to search + client-side
+filtering otherwise. `/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

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

@@ -11,40 +11,44 @@ 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
+> **Connector routing (native).** Use the in-session connector tools
+> your harness exposes for each native integration directly, per each
+> skill's `SKILL.native.gemini.md` body. 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.
+> daemon routes (410). Write-class connector calls require explicit
+> user confirmation; direct-mode siblings keep using their direct
+> routes. **Gemini quirks**: `maxResults` is typically silently
+> ignored on Gmail search and Calendar list-events — narrow the query
+> window when the result is larger than expected.
 
 ### Per-session integration routing
 
 <integration-routing-table>
 
-### Native MCP routing — per integration
+### Native connector 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).
+**Calendar.** When `google_calendar="native"`, use your in-session
+Google Calendar connector (list-events / get-event / list-calendars /
+find-free-time + destructive set). `maxResults` typically silently
+ignored on list-events; default `attendeeResponseStatus` typically
+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.
+**Mail.** When `gmail="native"`, use your in-session Gmail connector.
+Some Gemini-side connectors expose no dedicated delete or forward
+tool — compose from primitives (delete = modify + add `TRASH`;
+forward = send with re-quoted body). The destructive set requires
+explicit user confirmation. For non-Gmail accounts keep using
+`/api/mail/<acct>/*`.
+
+**Notion.** When `notion="native"`, use your in-session Notion
+connector per the `notion` skill's native body. No SQL-style
+structured query primitive is typically exposed on this surface
+(Notion's official MCP server lacks it) — use workspace search with a
+data-source filter 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