@aitne-sh/aitne 0.1.2 → 0.1.4

package/agent-assets/task-flows/_partials/calendar-acquire.google_calendar.md

@@ -0,0 +1,119 @@
+---
+name: calendar-acquire.google_calendar
+description: Acquire a Google Calendar event window per <acquisition-plan> row.
+spec: ROUTINE_DATA_ACQUISITION_DESIGN.md §6.8 / §8.3
+---
+
+# Google Calendar acquisition
+
+For every `<fetch integration="google_calendar" ...>` row in
+`<acquisition-plan>`, take the branch below that matches the row's `mode`
+attribute. Calendar rows do not fan out per account today — the dispatcher
+emits one row per active provider, scoped to the bound primary calendar.
+
+Note on coverage: routines whose calendar window is already covered by
+`ContextBuilder.buildCalendarBlock` (the `<calendar_events_*>` blocks) do
+**not** appear in the pre-pass plan for the same window — that would
+double-fetch. The catalog only emits drift / retrospective / imminent
+windows for the pre-pass.
+
+POST every returned event to `http://localhost:8321/api/observations`:
+
+- `source`     = `"google_calendar:<calendarId>"` (use `"primary"` when the
+  provider returns no explicit id)
+- `ref`        = provider-side stable event id
+- `changeType` = `"created"` for fresh events; `"modified"` when the
+  payload updates an existing `(source, ref)`; `"deleted"` for cancelled
+  events (payload = `{ "kind": "calendar", "providerId": "<calendarId>",
+  "raw": { "deletedAt": "<iso>" } }`)
+- `actor`      = `"agent"`
+- `payload`    = `{ "kind": "calendar", "providerId": "<calendarId>",
+                    "raw": { "title": ..., "start": ..., "end": ...,
+                             "attendees": [...], "status": ... } }`
+
+Server computes the dedup hash from `(source, payload)`. Response shape:
+
+- `200 {action: "created"|"modified"}` — fresh / updated row; count in `posted`.
+- `409 {error: "duplicate"}` — identical payload already pending; count in `duplicates`.
+- `409 {error: "integration_flip_in_progress"}` — append
+  `{type:"flip-locked","integration":"google_calendar"}` to `errors`
+  and move on.
+
+<!-- mode:direct:google_calendar -->
+GET `http://localhost:8321/api/calendar/events<query>` where `<query>` is
+the literal `query` attribute of the `<fetch>` row (e.g.
+`?date=2026-05-11&days=1` or `?date=2026-05-04&days=7`). The route
+accepts `date=YYYY-MM-DD` (or `today`) plus `days=N` (≤90); `timeMin`
+/ `timeMax` are NOT recognised. The daemon returns `{ "events": [...] }`;
+map each event into one observation POST as specified above.
+<!-- /mode:direct:google_calendar -->
+
+<!-- mode:delegated-same:google_calendar -->
+The connector is bound to your own session backend. Use the in-session
+connector surface your skills document; the `<fetch>` row's `query`
+attribute carries the catalog's `delegated` form (e.g.
+`timeMin="..." timeMax="..." maxResults=50`). Translate it into the args
+your bound surface accepts. POST every returned event as specified above.
+<!-- /mode:delegated-same:google_calendar -->
+
+<!-- mode:delegated-cross:google_calendar -->
+The connector is bound to a different backend than this session — reach
+it through the daemon's delegation proxy. POST to
+`http://localhost:8321/api/integrations/google_calendar/exec` with the
+following body (substitute the row's `query` into `task`):
+
+```json
+{
+  "task": "List Google Calendar events for the window <query>. Return id, title, start, end, attendees (email + responseStatus), and status. Up to 100 events.",
+  "outputSchema": {
+    "type": "object",
+    "required": ["events"],
+    "properties": {
+      "events": {
+        "type": "array",
+        "items": {
+          "type": "object",
+          "required": ["id"],
+          "properties": {
+            "id":     { "type": "string" },
+            "title":  { "type": "string" },
+            "start":  { "type": "string" },
+            "end":    { "type": "string" },
+            "status": { "type": "string" },
+            "attendees": {
+              "type": "array",
+              "items": {
+                "type": "object",
+                "properties": {
+                  "email":          { "type": "string" },
+                  "responseStatus": { "type": "string" }
+                }
+              }
+            }
+          }
+        }
+      }
+    }
+  },
+  "maxToolCalls": 3,
+  "cacheable": true
+}
+```
+
+Map each item in `result.events[]` to one observation POST.
+<!-- /mode:delegated-cross:google_calendar -->
+
+<!-- mode:native:google_calendar -->
+The connector is bound natively to your own session backend. Use the
+in-session connector surface your skills document — same call shape as
+`delegated-same`. The daemon does not proxy. POST every returned event as
+specified above.
+<!-- /mode:native:google_calendar -->
+
+<!-- mode:disabled:google_calendar -->
+Defensive no-op. The dispatcher filters disabled integrations out of
+`<acquisition-plan>`. If a `<fetch integration="google_calendar">` row
+still reaches this branch, skip it and append
+`{"type":"unexpected-row","integration":"google_calendar","reason":"disabled-row-emitted"}`
+to your `errors` array.
+<!-- /mode:disabled:google_calendar -->

package/agent-assets/task-flows/_partials/calendar-acquire.outlook_calendar.md

@@ -0,0 +1,101 @@
+---
+name: calendar-acquire.outlook_calendar
+description: Acquire an Outlook Calendar event window per <acquisition-plan> row.
+spec: ROUTINE_DATA_ACQUISITION_DESIGN.md §6.8 / §8.4
+---
+
+# Outlook Calendar acquisition
+
+For every `<fetch integration="outlook_calendar" ...>` row in
+`<acquisition-plan>`, take the branch below that matches the row's `mode`
+attribute. Calendar rows do not fan out per account today — the dispatcher
+emits one row per active provider, scoped to the bound primary calendar.
+
+Outlook Calendar is a **user-managed** integration: the daemon has no
+delegation proxy (no `/api/integrations/outlook_calendar/exec` exists).
+The four non-disabled branches therefore split into two real flows:
+
+- `direct` → the daemon's Outlook calendar route
+  (`/api/calendar/outlook/events`).
+- `delegated-same`, `delegated-cross`, `native` → use the in-session
+  connector surface your skills document. The user picks the binding (an
+  in-session connector, a local CLI invoked via a skill, a custom
+  script); the partial states the intent, not specific tool names. If no
+  surface is bound, record an error and continue.
+
+Note on coverage: when `ContextBuilder.buildCalendarBlock` already covers
+the window via `<calendar_events_*>` (multi-provider after §6.6), the
+catalog skips the pre-pass row to avoid double-fetching. The pre-pass
+only ships drift / retrospective / imminent windows.
+
+POST every returned event to `http://localhost:8321/api/observations`:
+
+- `source`     = `"outlook_calendar:<calendarId>"` (use `"primary"` when
+  the provider returns no explicit id)
+- `ref`        = provider-side stable event id
+- `changeType` = `"created"` for fresh events; `"modified"` when the
+  payload updates an existing `(source, ref)`; `"deleted"` for cancelled
+  events
+- `actor`      = `"agent"`
+- `payload`    = `{ "kind": "calendar", "providerId": "<calendarId>",
+                    "raw": { "title": ..., "start": ..., "end": ...,
+                             "attendees": [...], "status": ... } }`
+
+Server computes the dedup hash from `(source, payload)`. Response shape:
+
+- `200 {action: "created"|"modified"}` — fresh / updated row; count in `posted`.
+- `409 {error: "duplicate"}` — identical payload already pending; count in `duplicates`.
+- `409 {error: "integration_flip_in_progress"}` — append
+  `{type:"flip-locked","integration":"outlook_calendar"}` to `errors`
+  and move on.
+
+<!-- mode:direct:outlook_calendar -->
+GET `http://localhost:8321/api/calendar/outlook/events<query>` where
+`<query>` is the literal `query` attribute of the `<fetch>` row (e.g.
+`?date=2026-05-11&days=1` or `?date=2026-05-04&days=7`). The route
+accepts `date=YYYY-MM-DD` (or `today`) plus `days=N` (≤90); `timeMin`
+/ `timeMax` are NOT recognised. The daemon returns
+`{ "events": [...] }`; map each event into one observation POST as
+specified above.
+<!-- /mode:direct:outlook_calendar -->
+
+<!-- mode:delegated-same:outlook_calendar -->
+The integration is bound to your own session backend. Use the in-session
+connector surface your skills document for Outlook Calendar; the
+`<fetch>` row's `query` attribute carries the catalog's `delegated` form
+(e.g. `startDateTime=... endDateTime=...`). Translate it into the args
+your bound surface accepts. POST every returned event as specified above.
+
+If no Outlook Calendar surface is bound, append
+`{"type":"no-surface","integration":"outlook_calendar"}` to your `errors`
+array and continue with the next row. Do NOT halt the pre-pass.
+<!-- /mode:delegated-same:outlook_calendar -->
+
+<!-- mode:delegated-cross:outlook_calendar -->
+Outlook Calendar is user-managed, so the daemon does not host a
+delegation proxy. The dispatcher should not have emitted a
+`delegated-cross` row for this integration — if you see one, treat it
+exactly like `delegated-same`: use whichever in-session connector
+surface your skills document for Outlook Calendar. If nothing is bound,
+append `{"type":"no-surface","integration":"outlook_calendar"}` to
+`errors` and continue.
+<!-- /mode:delegated-cross:outlook_calendar -->
+
+<!-- mode:native:outlook_calendar -->
+The integration is bound natively to your own session backend. Use the
+in-session connector surface your skills document — same call shape as
+`delegated-same`. The daemon does not proxy. POST every returned event as
+specified above.
+
+If no Outlook Calendar surface is bound, append
+`{"type":"no-surface","integration":"outlook_calendar"}` to `errors` and
+continue.
+<!-- /mode:native:outlook_calendar -->
+
+<!-- mode:disabled:outlook_calendar -->
+Defensive no-op. The dispatcher filters disabled integrations out of
+`<acquisition-plan>`. If a `<fetch integration="outlook_calendar">` row
+still reaches this branch, skip it and append
+`{"type":"unexpected-row","integration":"outlook_calendar","reason":"disabled-row-emitted"}`
+to your `errors` array.
+<!-- /mode:disabled:outlook_calendar -->

package/agent-assets/task-flows/_partials/mail-acquire.gmail.md

@@ -0,0 +1,113 @@
+---
+name: mail-acquire.gmail
+description: Acquire a Gmail message window per <acquisition-plan> row.
+spec: ROUTINE_DATA_ACQUISITION_DESIGN.md §6.8 / §8.1
+---
+
+# Gmail acquisition
+
+For every `<fetch integration="gmail" ...>` row in `<acquisition-plan>`, take
+the branch below that matches the row's `mode` attribute and acquire the
+window described by `query`. Each row carries `account="<accountId>"` — apply
+the query against that account only, do not pool across accounts.
+
+POST every returned message to `http://localhost:8321/api/observations` per
+the contract in your agent profile (the response from the upstream call IS
+the payload; do not summarise or rank). Use:
+
+- `source`     = `"gmail:<accountId>"`
+- `ref`        = provider-side stable message id
+- `changeType` = `"created"` for fresh items; `"modified"` when the row updates
+  a payload the server already has under the same `(source, ref)`
+- `actor`      = `"agent"`
+- `payload`    = `{ "kind": "mail", "providerId": "<accountId>", "raw": {
+                    "subject": ..., "from": ..., "snippet": ...,
+                    "date": ... } }`
+
+Do NOT compute the dedup hash — the server derives it from `(source, payload)`.
+The response body shape distinguishes three outcomes:
+
+- `200 {action: "created"}` — fresh row inserted; count it in `posted`.
+- `200 {action: "modified"}` — same `(source, ref)` pending row existed
+  with a different payload; the row was updated and re-summarized.
+  Count it in `posted`.
+- `409 {error: "duplicate"}` — same `(source, ref)` pending row already
+  stores an identical payload. Nothing was written; count it in
+  `duplicates` and move on.
+- `409 {error: "integration_flip_in_progress"}` — a mode flip is
+  draining for this integration. Record
+  `{type:"flip-locked","integration":"gmail","account":"<accountId>"}`
+  in `errors` and continue with the next row (the parent routine will
+  retry on the next tick).
+
+<!-- mode:direct:gmail -->
+GET `http://localhost:8321/api/mail/<accountId>/messages<query>` where
+`<query>` is the literal `query` attribute of the `<fetch>` row (e.g.
+`?since=2026-05-11T00:00:00.000Z&limit=20` or
+`?since=2026-05-11T10:00:00.000Z&unreadOnly=true&limit=10` or
+`?folder=sent&since=2026-05-11T00:00:00.000Z&limit=30`). The route
+accepts `since` (ISO 8601 datetime), `limit`, `folder`, `q`,
+`unreadOnly` — `days=…` is NOT recognised. The daemon returns
+`{ "messages": [...] }`; map each item to one POST as specified above.
+<!-- /mode:direct:gmail -->
+
+<!-- mode:delegated-same:gmail -->
+The Gmail connector is bound to your own session backend. Use the in-session
+connector surface your skills document for this integration; the `<fetch>`
+row's `query` attribute carries the catalog's `delegated` form (e.g.
+`q="newer_than:1d" maxResults=20`) — translate it into the args your bound
+surface accepts. POST every returned message as specified above. The daemon
+does not proxy in this branch.
+<!-- /mode:delegated-same:gmail -->
+
+<!-- mode:delegated-cross:gmail -->
+The connector is bound to a different backend than this session, so reach it
+through the daemon's delegation proxy. POST to
+`http://localhost:8321/api/integrations/gmail/exec` with the following body
+(substitute the row's `query` and `accountId` into `task`):
+
+```json
+{
+  "task": "On account <accountId>, search Gmail with the query expression <query> and return id, subject, from, snippet, date for each message. Up to 30 messages.",
+  "outputSchema": {
+    "type": "object",
+    "required": ["messages"],
+    "properties": {
+      "messages": {
+        "type": "array",
+        "items": {
+          "type": "object",
+          "required": ["id"],
+          "properties": {
+            "id":      { "type": "string" },
+            "subject": { "type": "string" },
+            "from":    { "type": "string" },
+            "snippet": { "type": "string" },
+            "date":    { "type": "string" }
+          }
+        }
+      }
+    }
+  },
+  "maxToolCalls": 3,
+  "cacheable": true
+}
+```
+
+Map each item in `result.messages[]` to one observation POST.
+<!-- /mode:delegated-cross:gmail -->
+
+<!-- mode:native:gmail -->
+The connector is bound natively to your own session backend. Use the
+in-session connector surface your skills document — same call shape as
+`delegated-same`. The daemon does not proxy. POST every returned message as
+specified above.
+<!-- /mode:native:gmail -->
+
+<!-- mode:disabled:gmail -->
+Defensive no-op. The dispatcher filters disabled integrations out of
+`<acquisition-plan>`, so no `<fetch integration="gmail">` row should ever
+land in this branch. If one does, skip it and append
+`{"type":"unexpected-row","integration":"gmail","reason":"disabled-row-emitted"}`
+to your `errors` array.
+<!-- /mode:disabled:gmail -->

package/agent-assets/task-flows/_partials/mail-acquire.outlook_mail.md

@@ -0,0 +1,97 @@
+---
+name: mail-acquire.outlook_mail
+description: Acquire an Outlook Mail message window per <acquisition-plan> row.
+spec: ROUTINE_DATA_ACQUISITION_DESIGN.md §6.8 / §8.2
+---
+
+# Outlook Mail acquisition
+
+For every `<fetch integration="outlook_mail" ...>` row in `<acquisition-plan>`,
+take the branch below that matches the row's `mode` attribute. Each row
+carries `account="<accountId>"` — apply the query to that account only.
+
+Outlook Mail is a **user-managed** integration: the daemon has no
+delegation proxy for it (no `/api/integrations/outlook_mail/exec` exists).
+The four non-disabled branches therefore split into two real flows:
+
+- `direct` → the unified daemon mail route (transparently handles Outlook
+  accounts).
+- `delegated-same`, `delegated-cross`, `native` → use the in-session
+  connector surface your skills document. The user picks the binding (an
+  in-session connector, a local CLI invoked via a skill, a custom script);
+  this partial states the intent, not specific tool names. If no surface
+  is bound, record an error and continue.
+
+POST every returned message to `http://localhost:8321/api/observations`:
+
+- `source`     = `"outlook_mail:<accountId>"`
+- `ref`        = provider-side stable message id
+- `changeType` = `"created"` for fresh items; `"modified"` when the row
+  updates a payload already known under `(source, ref)`
+- `actor`      = `"agent"`
+- `payload`    = `{ "kind": "mail", "providerId": "<accountId>", "raw": {
+                    "subject": ..., "from": ..., "snippet": ...,
+                    "date": ... } }`
+
+The server computes the dedup hash from `(source, payload)`. Response
+shape:
+
+- `200 {action: "created"|"modified"}` — fresh / updated row; count in `posted`.
+- `409 {error: "duplicate"}` — identical payload already pending; count in `duplicates`.
+- `409 {error: "integration_flip_in_progress"}` — append
+  `{type:"flip-locked","integration":"outlook_mail","account":"<accountId>"}`
+  to `errors` and move on; do not retry inline.
+
+<!-- mode:direct:outlook_mail -->
+GET `http://localhost:8321/api/mail/<accountId>/messages<query>` where
+`<query>` is the literal `query` attribute of the `<fetch>` row (e.g.
+`?since=2026-05-11T00:00:00.000Z&limit=20` or
+`?folder=sent&since=2026-05-11T00:00:00.000Z&limit=30`). The route
+accepts `since` (ISO 8601), `limit`, `folder`, `q`, `unreadOnly` — it
+does NOT accept `days=…`. The daemon returns `{ "messages": [...] }`
+regardless of the underlying provider; map each item into one
+observation POST as specified above.
+<!-- /mode:direct:outlook_mail -->
+
+<!-- mode:delegated-same:outlook_mail -->
+The integration is bound to your own session backend. Use the in-session
+connector surface your skills document for Outlook Mail. The `<fetch>`
+row's `query` attribute carries the catalog's `delegated` form (e.g.
+`filter=receivedDateTime ge 2026-05-11T00:00:00Z`) — translate it into the
+args your bound surface accepts. POST every returned message as specified
+above.
+
+If no Outlook Mail surface is bound on this backend, append
+`{"type":"no-surface","integration":"outlook_mail","account":"<accountId>"}`
+to your `errors` array and continue with the next row. Do NOT halt the
+pre-pass; the parent routine continues with whatever observations the rest
+of the plan produced.
+<!-- /mode:delegated-same:outlook_mail -->
+
+<!-- mode:delegated-cross:outlook_mail -->
+Outlook Mail is user-managed, so the daemon does not host a delegation
+proxy. The dispatcher should not have emitted a `delegated-cross` row for
+this integration — if you see one, treat it exactly like
+`delegated-same`: use whichever in-session surface your skills document
+for Outlook Mail. If nothing is bound, append
+`{"type":"no-surface","integration":"outlook_mail","account":"<accountId>"}`
+to `errors` and continue.
+<!-- /mode:delegated-cross:outlook_mail -->
+
+<!-- mode:native:outlook_mail -->
+The integration is bound natively to your own session backend. Use the
+in-session connector surface your skills document for Outlook Mail —
+same call shape as `delegated-same`. The daemon does not proxy.
+
+If no Outlook Mail surface is bound, append
+`{"type":"no-surface","integration":"outlook_mail","account":"<accountId>"}`
+to `errors` and continue.
+<!-- /mode:native:outlook_mail -->
+
+<!-- mode:disabled:outlook_mail -->
+Defensive no-op. The dispatcher filters disabled integrations out of
+`<acquisition-plan>`. If a `<fetch integration="outlook_mail">` row still
+reaches this branch, skip it and append
+`{"type":"unexpected-row","integration":"outlook_mail","reason":"disabled-row-emitted"}`
+to your `errors` array.
+<!-- /mode:disabled:outlook_mail -->

package/agent-assets/task-flows/_partials/notion-acquire.notion.md

@@ -0,0 +1,104 @@
+---
+name: notion-acquire.notion
+description: Acquire recently-updated Notion pages per <acquisition-plan> row.
+spec: ROUTINE_DATA_ACQUISITION_DESIGN.md §6.8 / §8.5
+---
+
+# Notion acquisition
+
+For every `<fetch integration="notion" ...>` row in `<acquisition-plan>`,
+take the branch below that matches the row's `mode` attribute. Notion rows
+do not fan out per account — the dispatcher emits one row per workspace.
+
+POST every returned page to `http://localhost:8321/api/observations`:
+
+- `source`     = `"notion:<workspaceId>"` (use `"default"` when the daemon
+  reports no explicit workspace id)
+- `ref`        = Notion page id (stable UUID)
+- `changeType` = `"created"` for fresh pages; `"modified"` when the
+  payload updates an existing `(source, ref)`
+- `actor`      = `"agent"`
+- `payload`    = `{ "kind": "notion", "providerId": "<workspaceId>",
+                    "raw": { "title": ..., "last_edited": ...,
+                             "parent": ..., "url": ... } }`
+
+The server computes the dedup hash from `(source, payload)`. Response shape:
+
+- `200 {action: "created"|"modified"}` — fresh / updated row; count in `posted`.
+- `409 {error: "duplicate"}` — identical payload already pending; count in `duplicates`.
+- `409 {error: "integration_flip_in_progress"}` — append
+  `{type:"flip-locked","integration":"notion"}` to `errors` and move on.
+
+<!-- mode:direct:notion -->
+GET `http://localhost:8321/api/notion/search<query>` where `<query>` is
+the literal `query` attribute of the `<fetch>` row (e.g.
+`?page_size=50&sort=descending` or `?page_size=20&sort=descending`).
+The route accepts `q`, `type`, `sort` (`ascending` / `descending`),
+`page_size` (≤100), `start_cursor` — it has NO time filter, so do the
+window cutoff client-side. The daemon returns `{ "results": [...] }`
+sorted by `last_edited_time` descending; filter to entries whose
+`last_edited_time` is at or after the window the `<fetch>` row's
+window symbol implies (`updated_24h` → today's agent-day start,
+`updated_1h` → the current hour boundary), then map each surviving
+page into one observation POST as specified above.
+<!-- /mode:direct:notion -->
+
+<!-- mode:delegated-same:notion -->
+The connector is bound to your own session backend. Use the in-session
+connector surface your skills document for Notion; the `<fetch>` row's
+`query` attribute carries the catalog's `delegated` form
+(e.g. `last_edited_time>=<iso>`). Translate it into the args your bound
+surface accepts. POST every returned page as specified above.
+<!-- /mode:delegated-same:notion -->
+
+<!-- mode:delegated-cross:notion -->
+The connector is bound to a different backend than this session — reach
+it through the daemon's delegation proxy. POST to
+`http://localhost:8321/api/integrations/notion/exec` with the following
+body (substitute the row's `query` into `task`):
+
+```json
+{
+  "task": "Search Notion for pages with last_edited_time matching <query>. Return id, title, last_edited, parent, url for each page. Up to 50 pages.",
+  "outputSchema": {
+    "type": "object",
+    "required": ["pages"],
+    "properties": {
+      "pages": {
+        "type": "array",
+        "items": {
+          "type": "object",
+          "required": ["id"],
+          "properties": {
+            "id":          { "type": "string" },
+            "title":       { "type": "string" },
+            "last_edited": { "type": "string" },
+            "parent":      { "type": "string" },
+            "url":         { "type": "string" }
+          }
+        }
+      }
+    }
+  },
+  "maxToolCalls": 3,
+  "cacheable": true
+}
+```
+
+Map each item in `result.pages[]` to one observation POST.
+<!-- /mode:delegated-cross:notion -->
+
+<!-- mode:native:notion -->
+The connector is bound natively to your own session backend. Use the
+in-session connector surface your skills document — same call shape as
+`delegated-same`. The daemon does not proxy. POST every returned page as
+specified above.
+<!-- /mode:native:notion -->
+
+<!-- mode:disabled:notion -->
+Defensive no-op. The dispatcher filters disabled integrations out of
+`<acquisition-plan>`. If a `<fetch integration="notion">` row still
+reaches this branch, skip it and append
+`{"type":"unexpected-row","integration":"notion","reason":"disabled-row-emitted"}`
+to your `errors` array.
+<!-- /mode:disabled:notion -->

package/agent-assets/task-flows/git.project.refresh_architecture.md

@@ -10,6 +10,28 @@ surgical merge — you submit only the new section body and it replaces the
 marker-bracketed Architecture block in place. Other sections (Summary,
 Notable Changes, Daily Activity Log) are preserved automatically.
 
+## Tools available to you
+
+This session runs under a **read-only clamp**. Your only write surface is the
+single daemon-API call in Step 6. The runtime denies every other writer.
+
+Available:
+
+- `Read` / `Glob` / `Grep` — inspect the repository at `<localPath>` and any
+  documentation under it. Pass absolute paths; you do **not** need to `cd`.
+- `Bash(curl *)` — pinned to `localhost:<apiPort>` by the security hook; used
+  exclusively for the Step 6 `PUT`.
+- `Bash(jq *)` — JSON post-processing for the curl response.
+
+Denied (these tools will fail at the SDK layer — do not attempt them):
+
+- `Write`, `Edit` — no agent-side write to the worktree. The daemon owns
+  every byte under `git/<slug>/`.
+- `Bash(git ...)`, `Bash(ls ...)`, `Bash(cat ...)` and any other shell verbs —
+  use `Glob` to enumerate directories and `Read` to inspect files. You are
+  analysing *current code structure*, not git history, so the git CLI is not
+  needed here. The daily-journal cron is the path that consumes git history.
+
 ## Inputs
 
 Read `<task_context>` first. It contains:
@@ -52,7 +74,8 @@ synthesize.
 1. **Read the README** at `<localPath>/README.md` (or `README.*`). Use
    it as the author's stated framing of the project, but verify against
    the code; the README can drift.
-2. **Survey top-level structure.** `ls <localPath>` + targeted reads of
+2. **Survey top-level structure.** `Glob` `<localPath>/*` (and
+   `<localPath>/.*` for dotfiles you care about) + targeted `Read`s of
    `package.json` / `pyproject.toml` / `Cargo.toml` / `go.mod` / etc. to
    identify the language, build system, and entry points.
 3. **Walk the meaningful directories.** Read enough source to confirm

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

@@ -75,6 +75,9 @@ same-backend delegated → your session's native Google Calendar MCP tools (no s
 <!-- mode:delegated-cross:google_calendar -->
 cross-backend delegated → `POST /api/integrations/google_calendar/exec` with a natural-language `task` + `outputSchema`, via the external-services skill (cross-backend variant materialized for this session). 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.native.claude.md

@@ -0,0 +1,76 @@
+{context}
+
+## DM Reply — Native Mode (Claude 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 (Claude) 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. The
+> `<integration-routing-table>` block below is the audit table; the
+> 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
+>   `SKILL.native.claude.md` body materialised for this session
+>   (`mail`, `external-services`, `notion`).
+> - Do **NOT** call `POST /api/integrations/<key>/exec` — returns 410
+>   with `X-Integration-Mode: native`.
+> - 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
+>   `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.
+> - For direct-mode siblings (e.g. when `gmail="native"` and
+>   `google_calendar="direct"`), keep using the direct routes
+>   documented in the base skill body for the direct integrations —
+>   the native gate is per-key.
+
+### Per-session integration routing
+
+<integration-routing-table>
+
+### Native MCP 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.
+
+**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.
+
+**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.
+
+**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.
+
+The dispatch decision flow (capture user info, profile-question
+reconcile, compose reply, route durable intent) is identical to the
+direct variant and lives below via the `{{> base }}` partial. Read
+through it after the per-integration overrides above.
+
+{{> base }}