@aitne-sh/aitne 0.1.4 → 0.1.6

package/agent-assets/skills/wiki/wiki-vault-rules/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: wiki-vault-rules
+description: Load for every wiki.* process. Defines wiki vault layout, layer ownership, and the daemon Wiki API call convention (endpoints + canonical curl shape).
+allowed-tools:
+  - Bash(curl *)
+  - Bash(jq *)
+  - Read
+---
+
+# Wiki Vault Rules
+
+The wiki vault is `{{vault_path}}` for workspace `{{workspace_name}}` (schema `{{schema_version}}`, language `{{language}}`).
+
+Never write this directory directly. Use only the daemon Wiki API at `http://localhost:8321`:
+
+```
+GET    /api/wiki/{{workspace_name}}/index
+GET    /api/wiki/{{workspace_name}}/search?q=<query>
+GET    /api/wiki/{{workspace_name}}/files/<path>
+POST   /api/wiki/{{workspace_name}}/files/<path>
+PATCH  /api/wiki/{{workspace_name}}/files/<path>
+```
+
+Every request must include `x-process-key` with your current process key.
+
+## Layers
+
+- `00_inbox/` is human-only. Agents may read it but must never write it.
+- `10_raw/` is create-only source capture. `wiki.ingest_url` may create root-level `<slug>.md`; existing raw notes are immutable.
+- `10_raw/images/<slug>/<file>` is reserved for source images.
+- `20_wiki/` is synthesized knowledge. `wiki.compile` may write root-level `<slug>.md` and `_index.md`.
+- `30_outputs/` is answers and reports. `wiki.ask` may write root-level `<YYYY-MM-DD>-<slug>.md`.
+- `90_meta/` holds taxonomy, schemas, and health notes. Treat schema files as read-mostly.
+- `log.md` is append-only operational history (PATCH `mode: "append"` only).
+
+Slugs are lowercase kebab-case (`^[a-z0-9][a-z0-9-]*$`). Preserve source URLs in raw and wiki notes.
+
+## Calling the Wiki API from Bash
+
+The session installs a node-backed curl shim at `.pa/bin/curl` (first on `PATH`) which pins host/port and auto-attaches read-side auth. From your point of view it behaves like plain `curl` against `http://localhost:8321/api/*` — with the constraints below.
+
+### The command MUST start with the literal `curl` token
+
+The session's allow-list is `Bash(curl *)`, **prefix-matched against the full command string**. These shapes are silently denied under `dontAsk` (no error, no `PA_API_ERROR`, no body — the call simply does not run):
+
+```
+echo '{...}' | curl ...      # starts with `echo`
+cat <<JSON | curl ... -d @-  # starts with `cat`
+bash -c "curl ..."           # starts with `bash`
+( curl ... )                 # starts with `(`
+curl1=... ; curl ...         # starts with `curl1` then `;` — chained-curl deny
+```
+
+Write a single, flat curl call. Multi-line / large bodies use a heredoc redirected directly to curl's stdin (the command still starts with `curl`):
+
+```
+curl http://... -X POST -H 'content-type: application/json' \
+  -H 'x-process-key: ...' -d @- <<'JSON'
+{"content":"... multi-line body ..."}
+JSON
+```
+
+The shim reads stdin when `-d @-` is passed, so the heredoc body lands as the request payload. For small single-line bodies, prefer `-d '<inline-json>'`.
+
+### Allowed curl flags
+
+The shim only understands `-X/--request`, `-H/--header`, `-d/--data/--data-raw/--data-binary`, `-o/--output`, `-F/--form`, and silently ignores `-s/--silent/--show-error`. Any other flag exits with `Unsupported curl flag`.
+
+### Allowed headers
+
+`content-type`, `x-process-key`, `x-lock-id`, `x-session-id`. Other authentication headers are managed by the shim — do not pass `Authorization`, `x-read-token`, or environment-variable expansions; they will be rejected.
+
+### Body-quoting cheat sheet
+
+For inline `-d '<json>'` bodies, wrap the JSON in **outer single quotes** so the shell does not expand it, then follow JSON's own escapes inside:
+
+| Need in `content` | Write in the shell-arg |
+|---|---|
+| `"` | `\"` |
+| `\` | `\\` |
+| newline | `\n` |
+| `'` | `'\''` (close-escape-reopen), or substitute `’` (U+2019) |
+| `$`, backticks | leave as-is |
+
+For heredoc `-d @-` bodies the shell does NOT expand the heredoc body when the marker is single-quoted (`<<'JSON'`), so the JSON inside is verbatim — no shell escaping required, only JSON's own (`\"`, `\\`, `\n`). Use heredoc for any body that's more than a few lines or contains lots of `"`.
+
+`-d @<path>` (file-read) is rejected by both the security hook and the shim — there is no agent-facing reason to load a body from disk.
+
+### What ELSE is silently denied (no `Bash(find|ls|cat|...)`)
+
+Only `Bash(curl *)` and `Bash(jq *)` are on the allow-list. `Bash(find ...)`, `Bash(ls ...)`, `Bash(cat ...)`, `Bash(grep ...)`, `Bash(wc ...)`, and every other shell utility hit the same `dontAsk` denial — no useful tool result. Enumerate the workspace via `GET /api/wiki/<ws>/index` (returns `{ files: [{ path, mtime, sizeBytes }] }`); do not walk `{{vault_path}}` from disk.
+
+`Write` and `Edit` tools are **stripped from the session allow-list** for every `wiki.*` process key — the SDK denies them silently. The Wiki API is the only legal write surface; `{{vault_path}}` is informational, not a target.
+
+### Canonical shapes
+
+```bash
+# LIST every file in the workspace (returns JSON with path/mtime/sizeBytes per file)
+curl http://localhost:8321/api/wiki/{{workspace_name}}/index \
+  -H 'x-process-key: <your-process-key>'
+
+# SEARCH bodies for a substring (returns matches with snippet + mtime)
+curl 'http://localhost:8321/api/wiki/{{workspace_name}}/search?q=<query>' \
+  -H 'x-process-key: <your-process-key>'
+
+# READ a file
+curl http://localhost:8321/api/wiki/{{workspace_name}}/files/<path> \
+  -H 'x-process-key: <your-process-key>'
+
+# CREATE a file (POST — used by wiki.ingest_url, wiki.compile, wiki.ask)
+curl http://localhost:8321/api/wiki/{{workspace_name}}/files/<path> \
+  -X POST \
+  -H 'content-type: application/json' \
+  -H 'x-process-key: <your-process-key>' \
+  -d '{"content":"..."}'
+
+# APPEND/PREPEND to a file (PATCH — used for log.md, _index.md, taxonomy.md)
+curl http://localhost:8321/api/wiki/{{workspace_name}}/files/<path> \
+  -X PATCH \
+  -H 'content-type: application/json' \
+  -H 'x-process-key: <your-process-key>' \
+  -d '{"mode":"append","content":"..."}'
+```
+
+Filtering the index is a `jq` job — e.g. raw notes touched since a baseline ISO timestamp:
+
+```bash
+curl http://localhost:8321/api/wiki/{{workspace_name}}/index \
+  -H 'x-process-key: <your-process-key>' \
+  | jq -r --arg since '<YYYY-MM-DDTHH:MM:SSZ>' \
+      '.files[] | select(.path | startswith("10_raw/")) | select(.mtime > $since) | .path'
+```
+
+### Common error codes
+
+The shim emits `PA_API_ERROR {...}` to stderr on every non-2xx. React on `status` + `bodyPreview.error`:
+
+- `403 missing_process_key` → add `-H 'x-process-key: ...'`.
+- `403 raw_write_denied` / `wiki_write_denied` / `meta_write_denied` / `output_write_denied` / `log_write_denied` → your process key isn't authorized for that layer; fix the target path, not the header.
+- `400 invalid_path` / `invalid_layer` → fix the slug shape or layer prefix.
+- `400 invalid_body` → JSON shape wrong (e.g. `content` must be a string; PATCH `content` must be non-empty).
+- `409 append_only` → file is immutable in this layer; either suffix the slug or use PATCH instead of POST.
+- `413` → body exceeds the 512 KB cap.
+
+If the Bash call returns to the prompt with no `PA_API_ERROR` and no body, your command did not start with literal `curl` and was denied under `dontAsk`. Rewrite as a flat curl invocation.

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

@@ -17,7 +17,18 @@ Note on coverage: routines whose calendar window is already covered by
 double-fetch. The catalog only emits drift / retrospective / imminent
 windows for the pre-pass.
 
-POST every returned event to `http://localhost:8321/api/observations`:
+POST every returned event — for a whole window in **one** call — to
+`http://localhost:8321/api/observations/batch`. Build the body as:
+
+```json
+{"observations":[
+  {"source":"google_calendar:<calendarId>","ref":"<eventId>","changeType":"created","actor":"agent",
+   "payload":{"kind":"calendar","providerId":"<calendarId>","raw":{"title":"…","start":"…","end":"…","attendees":[…],"status":"…"}}},
+  …
+]}
+```
+
+Field rules per element:
 
 - `source`     = `"google_calendar:<calendarId>"` (use `"primary"` when the
   provider returns no explicit id)
@@ -31,13 +42,19 @@ POST every returned event to `http://localhost:8321/api/observations`:
                     "raw": { "title": ..., "start": ..., "end": ...,
                              "attendees": [...], "status": ... } }`
 
-Server computes the dedup hash from `(source, payload)`. Response shape:
+Server computes the dedup hash from `(source, payload)`. The batch endpoint
+always returns `200` with a JSON envelope `{ "results": [...], "fetched": N,
+"posted": N, "duplicates": N, "errors": N }`. Per-item `results[*].status`:
+
+- `"created"` / `"modified"` — rolled into `posted`.
+- `"duplicate"` — rolled into `duplicates`.
+- `"flip_locked"` — append `{type:"flip-locked","integration":"google_calendar"}`
+  to `errors` and continue.
+- `"validation_error"` — append `{type:"validation-error","integration":"google_calendar","ref":"<ref>","detail":"<results[*].error>"}`
+  to `errors` and continue.
 
-- `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.
+Cap each batch at 200 entries — split the window into multiple POSTs if the
+upstream call returns more than that.
 
 <!-- mode:direct:google_calendar -->
 GET `http://localhost:8321/api/calendar/events<query>` where `<query>` is
@@ -45,7 +62,8 @@ 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.
+map every event into the `observations[]` array of a single
+`POST /api/observations/batch` call.
 <!-- /mode:direct:google_calendar -->
 
 <!-- mode:delegated-same:google_calendar -->
@@ -100,7 +118,8 @@ following body (substitute the row's `query` into `task`):
 }
 ```
 
-Map each item in `result.events[]` to one observation POST.
+Map all items in `result.events[]` into a single
+`POST /api/observations/batch` call.
 <!-- /mode:delegated-cross:google_calendar -->
 
 <!-- mode:native:google_calendar -->

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

@@ -28,7 +28,18 @@ 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`:
+POST every returned event — for a whole window in **one** call — to
+`http://localhost:8321/api/observations/batch`. Build the body as:
+
+```json
+{"observations":[
+  {"source":"outlook_calendar:<calendarId>","ref":"<eventId>","changeType":"created","actor":"agent",
+   "payload":{"kind":"calendar","providerId":"<calendarId>","raw":{"title":"…","start":"…","end":"…","attendees":[…],"status":"…"}}},
+  …
+]}
+```
+
+Field rules per element:
 
 - `source`     = `"outlook_calendar:<calendarId>"` (use `"primary"` when
   the provider returns no explicit id)
@@ -41,13 +52,19 @@ POST every returned event to `http://localhost:8321/api/observations`:
                     "raw": { "title": ..., "start": ..., "end": ...,
                              "attendees": [...], "status": ... } }`
 
-Server computes the dedup hash from `(source, payload)`. Response shape:
+Server computes the dedup hash from `(source, payload)`. The batch endpoint
+always returns `200` with a JSON envelope `{ "results": [...], "fetched": N,
+"posted": N, "duplicates": N, "errors": N }`. Per-item `results[*].status`:
 
-- `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.
+- `"created"` / `"modified"` — rolled into `posted`.
+- `"duplicate"` — rolled into `duplicates`.
+- `"flip_locked"` — append `{type:"flip-locked","integration":"outlook_calendar"}`
+  to `errors` and continue.
+- `"validation_error"` — append `{type:"validation-error","integration":"outlook_calendar","ref":"<ref>","detail":"<results[*].error>"}`
+  to `errors` and continue.
+
+Cap each batch at 200 entries — split the window into multiple POSTs if the
+upstream call returns more than that.
 
 <!-- mode:direct:outlook_calendar -->
 GET `http://localhost:8321/api/calendar/outlook/events<query>` where
@@ -55,8 +72,8 @@ GET `http://localhost:8321/api/calendar/outlook/events<query>` where
 `?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.
+`{ "events": [...] }`; map every event into the `observations[]` array
+of a single `POST /api/observations/batch` call.
 <!-- /mode:direct:outlook_calendar -->
 
 <!-- mode:delegated-same:outlook_calendar -->

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

@@ -8,37 +8,60 @@ spec: ROUTINE_DATA_ACQUISITION_DESIGN.md §6.8 / §8.1
 
 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.
+window described by `query`.
 
-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:
+**Account attribution.** In `direct` mode each row carries
+`account="<accountId>"` — apply the query against THAT account only, do not
+pool across accounts. In `delegated-same` / `delegated-cross` / `native` modes
+the daemon emits a single row WITHOUT an `account` attribute because the
+bound Gmail MCP authenticates as a single user; substitute the literal
+string `default` wherever the observation contract below references
+`<accountId>`. Never invent an accountId from the message body — `default`
+is the canonical placeholder.
 
-- `source`     = `"gmail:<accountId>"`
+POST every returned message — for a whole window in **one** call — to
+`http://localhost:8321/api/observations/batch` (the response from the
+upstream call IS the payload; do not summarise or rank). Build the body as:
+
+```json
+{"observations":[
+  {"source":"gmail:<accountId>","ref":"<messageId>","changeType":"created","actor":"agent",
+   "payload":{"kind":"mail","providerId":"<accountId>","raw":{"subject":"…","from":"…","snippet":"…","date":"…"}}},
+  …
+]}
+```
+
+Field rules per element:
+
+- `source`     = `"gmail:<accountId>"` (use `"gmail:default"` when the
+  `<fetch>` row has no `account` attribute — see Account attribution above)
 - `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": ... } }`
+                    "date": ... } }` (providerId is `"default"` when no
+                    `account` attribute)
 
 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
+
+The batch endpoint always returns `200` with a JSON envelope `{ "results": [...],
+"fetched": N, "posted": N, "duplicates": N, "errors": N }`. Add each
+field-count into your top-level totals. Per-item `results[*].status` values:
+
+- `"created"`  / `"modified"` — fresh or updated row; rolled into `posted`.
+- `"duplicate"` — identical pending row already exists; rolled into `duplicates`.
+- `"flip_locked"` — a mode flip is draining for this integration. Append
   `{type:"flip-locked","integration":"gmail","account":"<accountId>"}`
-  in `errors` and continue with the next row (the parent routine will
-  retry on the next tick).
+  (use `"default"` when no `account` attribute) to your `errors` array
+  and continue (the parent routine will retry on the next tick).
+- `"validation_error"` — a malformed item slipped through. Append
+  `{type:"validation-error","integration":"gmail","account":"<accountId>","ref":"<ref>","detail":"<results[*].error>"}`
+  to `errors` and continue.
+
+Cap each batch at 200 entries — split the window into multiple POSTs if the
+upstream call returns more than that.
 
 <!-- mode:direct:gmail -->
 GET `http://localhost:8321/api/mail/<accountId>/messages<query>` where
@@ -48,7 +71,8 @@ GET `http://localhost:8321/api/mail/<accountId>/messages<query>` where
 `?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.
+`{ "messages": [...] }`; map every message into the `observations[]`
+array of a single `POST /api/observations/batch` call.
 <!-- /mode:direct:gmail -->
 
 <!-- mode:delegated-same:gmail -->
@@ -64,11 +88,13 @@ does not proxy in this branch.
 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`):
+(substitute the row's `query` into `task`). The `<fetch>` row in this mode
+carries no `account` attribute — the proxy's bound MCP authenticates as a
+single user, so the task is account-implicit:
 
 ```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.",
+  "task": "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"],
@@ -94,7 +120,8 @@ through the daemon's delegation proxy. POST to
 }
 ```
 
-Map each item in `result.messages[]` to one observation POST.
+Map all items in `result.messages[]` into a single
+`POST /api/observations/batch` call.
 <!-- /mode:delegated-cross:gmail -->
 
 <!-- mode:native:gmail -->

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

@@ -7,8 +7,16 @@ 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.
+take the branch below that matches the row's `mode` attribute.
+
+**Account attribution.** In `direct` mode each row carries
+`account="<accountId>"` — apply the query against THAT account only. In
+`delegated-same` / `delegated-cross` / `native` modes the daemon emits a
+single row WITHOUT an `account` attribute (the bound MCP authenticates as
+one user); substitute the literal string `default` wherever the observation
+contract below references `<accountId>`. The `userManagedConnector`
+collapse (see below) means `delegated-cross` never carries an account
+either.
 
 Outlook Mail is a **user-managed** integration: the daemon has no
 delegation proxy for it (no `/api/integrations/outlook_mail/exec` exists).
@@ -22,25 +30,47 @@ The four non-disabled branches therefore split into two real flows:
   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`:
+POST every returned message — for a whole window in **one** call — to
+`http://localhost:8321/api/observations/batch`. Build the body as:
+
+```json
+{"observations":[
+  {"source":"outlook_mail:<accountId>","ref":"<messageId>","changeType":"created","actor":"agent",
+   "payload":{"kind":"mail","providerId":"<accountId>","raw":{"subject":"…","from":"…","snippet":"…","date":"…"}}},
+  …
+]}
+```
 
-- `source`     = `"outlook_mail:<accountId>"`
+Field rules per element:
+
+- `source`     = `"outlook_mail:<accountId>"` (use `"outlook_mail:default"`
+  when the `<fetch>` row has no `account` attribute — see Account
+  attribution above)
 - `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": ... } }`
+                    "date": ... } }` (providerId is `"default"` when no
+                    `account` attribute)
 
-The server computes the dedup hash from `(source, payload)`. Response
-shape:
+The server computes the dedup hash from `(source, payload)`. The batch
+endpoint always returns `200` with `{ "results": [...], "fetched": N,
+"posted": N, "duplicates": N, "errors": N }`. Per-item `results[*].status`:
 
-- `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
+- `"created"` / `"modified"` — rolled into `posted`.
+- `"duplicate"` — rolled into `duplicates`.
+- `"flip_locked"` — append
   `{type:"flip-locked","integration":"outlook_mail","account":"<accountId>"}`
-  to `errors` and move on; do not retry inline.
+  (use `"default"` when no `account` attribute) to `errors` and
+  continue; do not retry inline.
+- `"validation_error"` — append
+  `{type:"validation-error","integration":"outlook_mail","account":"<accountId>","ref":"<ref>","detail":"<results[*].error>"}`
+  to `errors` and continue.
+
+Cap each batch at 200 entries — split the window into multiple POSTs if the
+upstream call returns more than that.
 
 <!-- mode:direct:outlook_mail -->
 GET `http://localhost:8321/api/mail/<accountId>/messages<query>` where
@@ -49,8 +79,8 @@ GET `http://localhost:8321/api/mail/<accountId>/messages<query>` where
 `?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.
+regardless of the underlying provider; map every message into the
+`observations[]` array of a single `POST /api/observations/batch` call.
 <!-- /mode:direct:outlook_mail -->
 
 <!-- mode:delegated-same:outlook_mail -->
@@ -62,7 +92,7 @@ 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>"}`
+`{"type":"no-surface","integration":"outlook_mail","account":"<accountId>"}` (use `"default"` when no `account` attribute)
 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.
@@ -74,7 +104,7 @@ 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>"}`
+`{"type":"no-surface","integration":"outlook_mail","account":"<accountId>"}` (use `"default"` when no `account` attribute)
 to `errors` and continue.
 <!-- /mode:delegated-cross:outlook_mail -->
 
@@ -84,7 +114,7 @@ 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>"}`
+`{"type":"no-surface","integration":"outlook_mail","account":"<accountId>"}` (use `"default"` when no `account` attribute)
 to `errors` and continue.
 <!-- /mode:native:outlook_mail -->
 

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

@@ -10,7 +10,18 @@ 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`:
+POST every returned page — for a whole window in **one** call — to
+`http://localhost:8321/api/observations/batch`. Build the body as:
+
+```json
+{"observations":[
+  {"source":"notion:<workspaceId>","ref":"<pageId>","changeType":"created","actor":"agent",
+   "payload":{"kind":"notion","providerId":"<workspaceId>","raw":{"title":"…","last_edited":"…","parent":"…","url":"…"}}},
+  …
+]}
+```
+
+Field rules per element:
 
 - `source`     = `"notion:<workspaceId>"` (use `"default"` when the daemon
   reports no explicit workspace id)
@@ -22,12 +33,19 @@ POST every returned page to `http://localhost:8321/api/observations`:
                     "raw": { "title": ..., "last_edited": ...,
                              "parent": ..., "url": ... } }`
 
-The server computes the dedup hash from `(source, payload)`. Response shape:
+The server computes the dedup hash from `(source, payload)`. The batch
+endpoint always returns `200` with `{ "results": [...], "fetched": N,
+"posted": N, "duplicates": N, "errors": N }`. Per-item `results[*].status`:
+
+- `"created"` / `"modified"` — rolled into `posted`.
+- `"duplicate"` — rolled into `duplicates`.
+- `"flip_locked"` — append `{type:"flip-locked","integration":"notion"}`
+  to `errors` and continue.
+- `"validation_error"` — append `{type:"validation-error","integration":"notion","ref":"<ref>","detail":"<results[*].error>"}`
+  to `errors` and continue.
 
-- `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.
+Cap each batch at 200 entries — split the window into multiple POSTs if the
+upstream call returns more than that.
 
 <!-- mode:direct:notion -->
 GET `http://localhost:8321/api/notion/search<query>` where `<query>` is
@@ -39,8 +57,9 @@ 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.
+`updated_1h` → the current hour boundary), then map every surviving
+page into the `observations[]` array of a single
+`POST /api/observations/batch` call.
 <!-- /mode:direct:notion -->
 
 <!-- mode:delegated-same:notion -->
@@ -85,7 +104,8 @@ body (substitute the row's `query` into `task`):
 }
 ```
 
-Map each item in `result.pages[]` to one observation POST.
+Map all items in `result.pages[]` into a single
+`POST /api/observations/batch` call.
 <!-- /mode:delegated-cross:notion -->
 
 <!-- mode:native:notion -->

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

@@ -36,6 +36,22 @@ If any gate fails, leave the latent entry untouched. The user must never feel th
 
 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. The user-facing message discipline (awareness, no ceremony, no readback, compactness) is owned by the notify skill.
 
+#### 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 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.
+
 **Day-type filter.** Parse line 2 of <today>. For any category whose focus is `off` (map via the today skill's "Category → focus-dimension mapping"), do not volunteer items in that category.
 
 **Resolved User Tasks.** When the user reports completing one of their tasks, mark it `[x]` per the today / context skill. Do NOT modify the agent's internal Agent Plan rows from this handler — those flip in `scheduled.task` handlers and Evening Review only.
@@ -116,6 +132,23 @@ If a tool you genuinely need is denied, or no available tool can handle the file
 
 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 asked a question that the user is
+now answering (typical shape: a short, single-question DM with no
+project/task name embedded — emitted by the `scheduled.dm.md` ## Confirmation
+follow-up sub-flow), 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" or "no" from the user
+will not match the named-workstream / commitment shape the per-domain
+dispatchers expect, so without this routing rule the reply would
+silently miss the gate. Concretely: a confirm DM about *"track the LA
+PM master's as a project?"* → user replies "yeah" / "no" / "actually
+call it la-pm" → route through the context skill's "Project DM-intent
+detection" §"Reply branches", carrying the user's reply shape (yes /
+counter-proposal / no) into that handler. Apply the same pattern to
+any other gate that opts into the confirm sub-flow in the future.
+
 **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 that must look something up at fire time). Edit / cancel / list use the same endpoints. Load the schedule skill for the request shape, dedup pre-check, DM-vs-wake decision, 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. Do not propose one as a tradeoff.
@@ -130,9 +163,9 @@ Schedules go through this daemon — never through any cloud-hosted scheduled-ag
    - **Re-enable** → `PATCH /api/recurring-schedules/:id` `{"enabled": true}`.
 3. Confirm to the user in persona voice. Keep it short — never name internal mechanisms ("recurring schedule", "pin_to_quiet_hours_end", row IDs) in user-visible text.
 
-**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"). Future durable-state domains (e.g. git) follow the same shape — per-domain skill block, thin dispatcher here.
+**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"). Future durable-state domains (e.g. git) follow the same shape — per-domain skill block, thin dispatcher here.
 
 ## User Message
 Platform: {event_data[platform]}