@aitne-sh/aitne 0.1.4 → 0.1.6

package/agent-assets/skills/notion/SKILL.native.gemini.md

@@ -1,13 +1,13 @@
 ---
 name: notion
-description: Load when the task touches Notion and Notion is in native mode bound to Gemini (`nativeBackend === "gemini"`). Use the user-installed Notion MCP server on Gemini CLI directly; the daemon does not proxy Notion. `/api/notion/databases` (label → UUID config dump) is the only daemon route still reachable.
+description: Load when the task touches Notion and Notion is in native mode bound to Gemini (`nativeBackend === "gemini"`). Use the in-session Notion connector your Gemini harness exposes directly; the daemon does not proxy Notion. `/api/notion/databases` (label → UUID config dump) is the only daemon route still reachable.
 allowed-tools:
   - Bash(curl *)
   - Bash(jq *)
   - Read
 ---
 
-# Notion (native — Gemini, user-installed Notion MCP)
+# Notion (native — in-session Notion connector)
 
 > **Refusal directive — read first.** Notion is in `native` mode bound
 > to Gemini. Do **NOT** call any of:
@@ -18,22 +18,22 @@ allowed-tools:
 > - `/api/notion/query`, `/api/notion/search`, `/api/notion/pages`,
 >   `/api/notion/pages/<id>/content` (each route-prefix 410)
 >
-> Reach Notion through the `mcp_notion_*` MCP tools your Gemini session
-> already holds via the user-installed Notion MCP server.
+> Reach Notion through the in-session Notion connector your harness
+> exposes (typically a user-installed Notion MCP server registered
+> against the Gemini CLI). Your tool menu lists every available tool at
+> session start — pick the Notion one.
 >
 > Exception: **`GET /api/notion/databases`** remains reachable in every
 > mode (config dump, no Notion API side-effect).
 
-## Server-name assumption
+## Connector presence assumption
 
-The registry assumes the user registered Notion's official MCP server
-under the literal name `notion` (`gemini mcp add notion <url>` or via
-the dashboard's MCP page). Gemini surfaces tools as
-`mcp_<server>_<tool>`, so the namespace `mcp_notion_` only resolves if
-the server is named `notion` exactly. If the user picked a different
-name, the §9.3 probe at flip time will report every required capability
-missing and the dashboard surfaces an actionable "wrong server name"
-hint. This skill body assumes the probe passed.
+Native:gemini mode assumes a Notion MCP server is registered against
+the user's Gemini CLI. The §9.3 probe at flip time verifies every
+required capability is reachable from the in-session tool menu; if the
+probe fails (wrong server name, server not registered, or capabilities
+missing), the dashboard surfaces an actionable hint and the mode does
+not flip. This skill body assumes the probe passed.
 
 Confirm the binding via `<integration_modes>` (`notion="native"`) and
 the `<integration-routing-table>` block in the session preamble.
@@ -47,106 +47,107 @@ curl -s http://localhost:8321/api/notion/databases
 
 Resolve label → UUID before any Notion call.
 
-## 2. Notion — user-installed Notion MCP (native)
+## 2. Notion — in-session connector
+
+The exact tool names depend on which Notion MCP server the user has
+registered against their Gemini CLI. Inspect your tool menu at session
+start and pick the matching capability. Notion's official MCP server
+exposes hyphenated identifiers (search / fetch / get-comments / …);
+under Gemini's namespace convention they surface with a server prefix.
+The capability classes below are stable across connectors; the exact
+tool names depend on the server you have loaded.
+
+### Read-class capabilities
+
+| Capability | What to do |
+|---|---|
+| `search` | Workspace search (text + Notion query parameters), optionally filtered to a specific data source. |
+| `read` | Retrieve a single page / database / block by URL or UUID; returns block tree. |
+| `comments` | Read page comments. |
+| `users` | Enumerate workspace users. |
+| `teams` | Enumerate teams / teamspaces. |
+
+Canonical search flow: invoke your connector's search function with
+the user's text query and the data-source URL constructed from the
+resolved UUID (e.g.
+`https://www.notion.so/<workspace>/<database-uuid>`).
+
+Canonical page read: invoke your connector's fetch / read-page
+function with the page's URL or UUID.
+
+### Destructive capabilities (require explicit user confirmation)
+
+Per the registry's `notion.backendConnectors.gemini.destructiveTools`,
+the following capability classes are destructive in native:gemini mode:
+
+- **Page creation** — adds new pages (batch-aware on most connectors).
+- **Page update** — mutates properties / content; **also** the archive
+  workaround (Status="Archived") — §3 below.
+- **Page duplicate** — clones a page.
+- **Page move** — relocates pages between databases / parents.
+- **Comment create** — posts a comment (user-visible).
+- **Database create** — schema admin (creates new DB).
+- **Data-source update** — schema admin (mutates DB columns).
+- **View create / update** — schema admin (new view / mutates view
+  config).
+
+Apply the destructive-confirm contract every time. Schema-admin
+capability classes warrant an explicit "schema admin" label on the
+surfaced plan. The starter `deniedTools` list is enforced before the
+call lands.
 
-Tool namespace: `mcp_notion_`
-
-The Notion MCP server exposes the same tool names as Anthropic's hosted
-Notion connector (hyphenated identifiers, e.g. `notion-search`); under
-Gemini's namespace convention they surface as `mcp_notion_<tool>`.
-
-### Read-class tools
-
-| Capability | Tool | Use |
-|---|---|---|
-| `search` | `mcp_notion_notion-search` | Workspace search. |
-| `read` | `mcp_notion_notion-fetch` | Single page / database / block by URL or UUID. |
-| `comments` | `mcp_notion_notion-get-comments` | Read page comments. |
-| `users` | `mcp_notion_notion-get-users` | Enumerate workspace users. |
-| `teams` | `mcp_notion_notion-get-teams` | Enumerate teams. |
-
-Canonical search call:
-
-```
-mcp_notion_notion-search(
-  query="acme proposal",
-  data_source_url="https://www.notion.so/<workspace>/<database-uuid>"
-)
-```
-
-Canonical page read:
-
-```
-mcp_notion_notion-fetch(id="<page-url-or-uuid>")
-```
-
-### Destructive tools (require explicit user confirmation)
-
-Per the registry's `notion.backendConnectors.gemini.destructiveTools`:
-
-- `mcp_notion_notion-create-pages`
-- `mcp_notion_notion-update-page` — properties / content / archive
-  workaround.
-- `mcp_notion_notion-duplicate-page`
-- `mcp_notion_notion-move-pages`
-- `mcp_notion_notion-create-comment`
-- `mcp_notion_notion-create-database` — schema admin.
-- `mcp_notion_notion-update-data-source` — schema admin.
-- `mcp_notion_notion-create-view` — schema admin.
-- `mcp_notion_notion-update-view` — schema admin.
+## 3. Page archive — workaround only
 
-Apply the destructive-confirm contract every time. Schema-admin tools
-warrant an explicit "schema admin" label on the surfaced plan. The
-starter `deniedTools` list is enforced before the call lands.
+Same gap as Claude / Codex hosted connectors — typically no dedicated
+archive tool. To "archive":
 
-## 3. Page archive — workaround only
+1. **Property workaround** (preferred): update the page's Status
+   property to "Archived" via the page-update capability.
+2. **Move to a "Trash" page**: relocate the page under a top-level
+   "Trash" page via the page-move capability.
 
-Same gap as Claude / Codex hosted connectors — no dedicated archive
-tool. Use the property-update workaround (Status="Archived") via
-`mcp_notion_notion-update-page`, or move the page under a top-level
-Trash page via `mcp_notion_notion-move-pages`. Surface the choice.
+Surface the choice to the user.
 
 ## 4. Decision rules
 
 - **Hourly check is read-only** — inherits the constraint from
   `routine.hourly_check.native.gemini.md`.
-- **Mass-update — ask first.** `mcp_notion_notion-create-pages` can
-  take up to 100 pages; batches >~10 pages warrant explicit
-  confirmation.
+- **Mass-update — ask first.** Batch page-creation can take up to 100
+  pages; batches >~10 pages warrant explicit confirmation.
 - **Schema admin — Approve-tier.** Database / view / data-source
   mutations alter workspace structure.
-- **Comments are user-visible.** `mcp_notion_notion-create-comment`
-  posts to a page comment thread — treat like a send.
-- **No `_notion_query_data_sources` equivalent** on this connector.
-  For "what tasks are in status X" intents, use
-  `mcp_notion_notion-search` with the data-source filter scoping the
-  workspace and process the result client-side; Codex's SQL-style
-  query is a Codex-only feature.
+- **Comments are user-visible.** Posting a page comment is treated
+  like a send: confirm before issuing.
+- **No SQL-style structured query on this surface.** Notion's official
+  MCP server (the typical native:gemini connector) does not expose a
+  structured-filter primitive equivalent to Codex's
+  `query_data_sources`. For "what tasks are in status X" intents, use
+  the workspace search capability with a data-source filter scoping
+  the request and process the result client-side.
 
 ## 5. Persisting observations from native fetches
 
+**Batch when you have more than one page.** Use
+`POST /api/observations/batch` with up to 200 items in one
+`observations[]` array (see the `observations` skill for the envelope).
+The single-item form below is for the rare "one page changed" case.
+
 ```bash
 curl -s -X POST http://localhost:8321/api/observations \
   -H 'Content-Type: application/json' \
   -d '{
-    "source": "notion",
-    "type": "notion:lifecycle",
+    "source": "notion:<workspaceId>",
     "ref": "<pageId>",
-    "actor": "user",
-    "receivedAt": "<ISO-8601 UTC>",
-    "summary_text": "<title — last edited HH:MM>",
-    "refs": {
-      "pageId": "<id>",
-      "parentDatabase": "<db-uuid-or-null>",
-      "title": "<title>"
-    },
-    "payload": <verbatim MCP page object>
+    "changeType": "created",
+    "actor": "agent",
+    "payload": <verbatim connector page object>
   }'
 ```
 
 The daemon computes `contentHash` server-side. Pass `payload`
-verbatim. HTTP 409 → mode-flip race window (§11.3.1); stop and re-read
-`<integration_modes>`.
+verbatim. `actor` MUST be `"agent"` or `"system"` — the server
+rejects `"user"`. HTTP 409 → mode-flip race window (§11.3.1); stop
+and re-read `<integration_modes>`.
 
 ## 6. Owner notification (opt-in)
 

package/agent-assets/skills/observations/SKILL.md

@@ -26,8 +26,10 @@ the update.
    - Update `roadmap.md` or `projects/*.md` only for material project-state changes
    - Schedule a wake-up if the observation implies a future reminder
 5. Apply the smallest meaningful set of context updates.
-6. Mark processed observations consumed:
-   `curl -s -X POST http://localhost:8321/api/observations/consume -H 'Content-Type: application/json' -d '{"ids":[1,2],"correlationId":"<event-correlation-id>"}'`
+6. Mark processed observations consumed via the bulk endpoint
+   (`POST /api/observations/consume`) — see "POST /api/observations/consume"
+   in the API Reference below for the exact body shape and the
+   `correlationId` rule. There is no per-id variant.
 
 ## Skip Criteria
 
@@ -131,15 +133,105 @@ creating a duplicate. Subkind suffixes after the colon are by
 convention (`roadmap_candidate:calendar`, `roadmap_candidate:vault`,
 etc.) and are picked up by the prefix match on the GET route.
 
+### POST /api/observations/batch
+
+Bulk-insert up to 200 observations in a single transaction. Use this
+whenever a single fetch surface (a mail window, a calendar query, a
+Notion page list) yields more than one observation — calling
+`POST /api/observations` once per item collides with the Bash hook
+that caps each curl invocation at one HTTP request and strips heredoc
+bodies before URL validation. The batch endpoint resolves the
+cardinality mismatch without weakening either hook.
+
+```bash
+curl -s -X POST http://localhost:8321/api/observations/batch \
+  -H 'Content-Type: application/json' \
+  -d @- <<'JSON'
+{
+  "observations": [
+    {"source":"gmail:acct-1","ref":"msg-123","changeType":"created","actor":"agent",
+     "payload":{"kind":"mail","providerId":"acct-1","raw":{"subject":"…","from":"…","snippet":"…","date":"…"}}},
+    {"source":"gmail:acct-1","ref":"msg-124","changeType":"created","actor":"agent",
+     "payload":{"kind":"mail","providerId":"acct-1","raw":{"subject":"…","from":"…","snippet":"…","date":"…"}}}
+  ]
+}
+JSON
+```
+
+Per-element shape mirrors `POST /api/observations` exactly. Same
+forgery guard (`actor` must be `"agent"` or `"system"`), same
+server-side `(source, payload)` content-hash dedup.
+
+Response is always `200` with envelope:
+
+```json
+{
+  "results": [
+    {"index":0,"status":"created","source":"gmail:acct-1","ref":"msg-123","contentHash":"…","id":42},
+    {"index":1,"status":"duplicate","source":"gmail:acct-1","ref":"msg-124","contentHash":"…","id":17}
+  ],
+  "fetched": 2,
+  "posted": 1,
+  "duplicates": 1,
+  "errors": 0
+}
+```
+
+`results[*].status` is one of `"created"`, `"modified"`, `"duplicate"`,
+`"flip_locked"` (integration mode-flip in progress — retry on the next
+tick), `"validation_error"` (malformed item; `error` field names the
+issue). The envelope's `posted` / `duplicates` / `errors` counters are
+pre-aggregated; the per-item array is for correlating a failure back
+to a specific input.
+
+Hard limits:
+
+- Max 200 items per call. Larger batches return 400 `batch_too_large` —
+  split into chunks.
+- 1 MiB body cap (shared with the single-item route).
+- Envelope JSON must have an `observations` array; missing or
+  non-array returns 400 `validation_error` with a hint.
+
 ### POST /api/observations/consume
 
+Marks one or more observations consumed. **Bulk-only** — there is no
+per-id endpoint (`POST /api/observations/<id>/consume` returns 404).
+Always use this shape, even for a single id.
+
+Copy the `correlationId` value verbatim from the
+`<event_correlation_id>…</event_correlation_id>` tag in your turn
+context — do not paste the angle-bracket placeholder.
+
 ```bash
+# Example: <event_correlation_id>hourly-2026-04-23T15:00:00Z-7af3</event_correlation_id>
+# arrived in context, and observations 14 and 17 were processed.
 curl -s -X POST http://localhost:8321/api/observations/consume \
   -H 'Content-Type: application/json' \
-  -d '{"ids": [1, 2, 3], "correlationId": "<event_correlation_id>"}'
+  -d '{"ids":[14,17],"correlationId":"hourly-2026-04-23T15:00:00Z-7af3"}'
 ```
 
-Response: `{ "consumed": 3 }`
+| Field | Type | Required | Notes |
+|---|---|---|---|
+| `ids` | `number[]` | yes | Integers, not strings. `["14"]` is rejected. |
+| `correlationId` | `string` | yes | camelCase, verbatim from the `<event_correlation_id>` context tag. Non-string, missing, snake_case `correlation_id`, or the literal placeholder `<...>` → 400. |
+
+Response: `{ "consumed": <count>, "notFound": [<id>...] }`. Validation
+failures return 400 with `{ "error": "validation_error", "issues": [...], "expectedShape": "...", "example": "..." }`. **Read the
+`issues` array — each entry names the offending field and a one-line
+fix. Do NOT retry with a different shape unless the issue list tells
+you to.**
+
+#### Common mistakes — do not retry these, they will keep failing
+
+| Wrong call | Why it fails | Correct shape |
+|---|---|---|
+| `POST /api/observations -d 'limit=30'` | Body is a query string. POST records, GET fetches. | `GET /api/observations?limit=30&pending=true` |
+| `POST /api/observations/14/consume` | Per-id path returns 405 `use_bulk_endpoint`. | `POST /api/observations/consume -d '{"ids":[14],"correlationId":"..."}'` |
+| `GET /api/observations/consume` | Consume is POST-only; GET returns 405. | `POST /api/observations/consume -d '{"ids":[...],"correlationId":"..."}'` |
+| `PATCH /api/observations` | No PATCH route — auth middleware returns 401. | `POST /api/observations/consume` (or `POST /api/observations` for new rows). |
+| `-d '{"ids":[14],"correlation_id":"..."}'` | snake_case. Field must be camelCase. | `-d '{"ids":[14],"correlationId":"..."}'` |
+| `-d '{"ids":["14"],"correlationId":"..."}'` | Stringified ids. Use integers. | `-d '{"ids":[14],"correlationId":"..."}'` |
+| `-d '{"ids":[14],"correlationId":"<event_correlation_id>"}'` | Pasted the angle-bracket placeholder. | Paste the actual id, e.g. `"hourly-2026-04-23T15:00:00Z-7af3"`. |
 
 ### GET /api/observations/stats
 
@@ -192,17 +284,20 @@ involved. Resolve `<databaseId>` first by reading the un-gated
 (`curl -s http://localhost:8321/api/notion/databases`) and then pass
 the UUID to the connector's data-source / search tool:
 
-| session backend | structured filter (data-source query)              | listing fallback (no filter support)         | workspace search        |
-|-----------------|----------------------------------------------------|----------------------------------------------|-------------------------|
-| claude          | n/a — connector has no filtered query              | `mcp__claude_ai_Notion__notion-fetch`        | `mcp__claude_ai_Notion__notion-search` |
-| codex           | `mcp__codex_apps__notion._notion_query_data_sources` | `mcp__codex_apps__notion._fetch`           | `mcp__codex_apps__notion._search`      |
-| gemini          | n/a — connector has no filtered query              | `mcp_notion_notion-fetch`                    | `mcp_notion_notion-search`             |
-
-For Claude / Gemini sessions: call the listing tool against the data
-source and post-filter in this skill (the structured-filter capability
-is Codex-only). For Codex sessions: pass the SQLite-style `WHERE`
-clause directly to `_notion_query_data_sources`. See the `notion`
-skill body for full property-naming and write-tier conventions.
+| session backend | structured filter (data-source query) | listing fallback (no filter support) | workspace search |
+|-----------------|---------------------------------------|--------------------------------------|------------------|
+| claude          | n/a — hosted connector has no filtered query | in-session Notion page-fetch capability | in-session Notion search capability |
+| codex           | in-session Notion data-source-query capability | in-session Notion fetch capability | in-session Notion search capability |
+| gemini          | n/a — hosted connector has no filtered query | in-session Notion page-fetch capability | in-session Notion search capability |
+
+The exact tool names depend on which Notion connector your harness has
+loaded — pick them from your tool menu at session start by capability.
+For Claude / Gemini sessions: call the listing capability against the
+data source and post-filter in this skill (the structured-filter
+capability is typically Codex-only). For Codex sessions: pass the
+SQLite-style `WHERE` clause directly to the data-source-query
+capability. See the `notion` skill body for full property-naming and
+write-tier conventions.
 <!-- /mode:delegated-same:notion -->
 <!-- mode:delegated-cross:notion -->
 The `/api/notion/query|search|pages` routes return 410 in delegated
@@ -231,6 +326,19 @@ Do NOT call `/api/notion/{query,search,pages}` directly (returns
 tools — that connector reads a different workspace than the user's
 delegated one.
 <!-- /mode:delegated-cross:notion -->
+<!-- mode:native:notion -->
+Notion is in native mode — the `/api/notion/{query,search,pages}`
+routes return 410 `{"error":"integration_native"}` and the daemon
+does not host an `/exec` proxy. Use your session backend's native
+Notion MCP tools directly; the materialized `notion` skill body
+(`SKILL.native.<session-backend>.md`) lists the per-backend tool
+names and the canonical search / fetch call shapes. Resolve
+`<databaseId>` first via the un-gated config dump
+(`curl -s http://localhost:8321/api/notion/databases`) and pass the
+UUID to the connector's data-source / search tool. Do NOT call
+`/api/notion/*` (410) or `/api/integrations/notion/exec` (also 410
+in native mode).
+<!-- /mode:native:notion -->
 <!-- mode:disabled:notion -->
 Notion is disabled — there is no live source. Treat the observation
 as preview-only and proceed without a Notion fetch.

package/agent-assets/skills/roadmap/SKILL.md

@@ -233,6 +233,25 @@ recipe — they always emit the full section schema.
 Roadmap writes serialize via an optional exclusive lock so a
 mid-session refresh is not interleaved with a DM handler PATCH.
 
+**Lock endpoint paths — get the order right:**
+
+| Operation | Method | Path |
+|---|---|---|
+| Acquire | `POST` | `/api/context/lock/roadmap` |
+| Release | `DELETE` | `/api/context/lock/roadmap` |
+
+**Common mistakes (NOT registered):**
+
+- `POST /api/context/roadmap/lock` — order reversed
+- `POST /api/context/roadmap/write-lock` — order reversed and wrong noun
+- `POST /api/context/lock/roadmap-write` — wrong noun
+
+Any of these return `404 {"error":"unknown_route", ...}` with a hint
+pointing at the correct path — re-read the table above and resend. The
+correct lock endpoints are Autonomous-tier, so no bearer token is
+required; if you see `401 {"error":"unauthorized"}` from a path you
+believe is correct, the path is still wrong.
+
 - If `<roadmap_write_lock_id>` is in your context, include
   `X-Lock-Id: <roadmap_write_lock_id>` on every PUT / PATCH to
   `/api/context/roadmap`.
@@ -246,6 +265,12 @@ mid-session refresh is not interleaved with a DM handler PATCH.
 
 ## roadmap.md API
 
+Body submission follows `_safety.md` "Daemon-API body submission":
+small POST / PATCH bodies use inline `-d '{...}'`; the full-file PUT
+runs multi-KB and uses the stdin heredoc `-d @- <<'JSON'` shape.
+Include `X-Lock-Id: <roadmap_write_lock_id>` on every PUT / PATCH
+when that tag is in your context.
+
 ```bash
 # Read
 curl -s http://localhost:8321/api/context/roadmap
@@ -254,19 +279,21 @@ curl -s http://localhost:8321/api/context/roadmap
 curl -s -X POST http://localhost:8321/api/context/roadmap/id \
   -H 'Content-Type: application/json' \
   -H 'X-Lock-Id: <roadmap_write_lock_id>' \
-  -d '{"creationDate": "YYYY-MM-DD"}'
+  -d '{"creationDate":"YYYY-MM-DD"}'
 
-# Full replace (roadmap refresh — include X-Lock-Id if context provides one)
+# Full replace (roadmap refresh) — multi-KB body, use heredoc.
 curl -s -X PUT http://localhost:8321/api/context/roadmap \
   -H 'Content-Type: application/json' \
   -H 'X-Lock-Id: <roadmap_write_lock_id>' \
-  -d '{"content": "# Roadmap\n..."}'
+  -d @- <<'JSON'
+{"content":"# Roadmap\n> Last synced: 2026-04-23\n\n## Annual Goals\n- ...\n\n## Quarterly Focus\n- ...\n\n## Long-term Plans\n- [2026-Q3] ...  <!-- id: rm-20260419-b8e7d4 -->\n\n## Agent Action Plan\n\n## Recurring\n- Every Friday: weekly review\n"}
+JSON
 
 # Section PATCH
 curl -s -X PATCH http://localhost:8321/api/context/roadmap \
   -H 'Content-Type: application/json' \
   -H 'X-Lock-Id: <roadmap_write_lock_id>' \
-  -d '{"section": "long_term_plans", "mode": "append", "content": "- [2026-Q3] ...\n"}'
+  -d '{"section":"long_term_plans","mode":"append","content":"- [2026-Q3] ...\n"}'
 ```
 
 Snapshotting, mtime updates, and path validation are handled by the

package/agent-assets/skills/schedule/SKILL.md

@@ -35,11 +35,52 @@ user but compound into duplicate DMs/notifications at fire time.
    confirm no recurring rule already covers this cadence (e.g. a daily
    09:00 inbox triage). If covered, skip — the recurring instance will
    regenerate on its own.
+4. **`confirm_dedup_key` check (mandatory for `confirm:` sub-flow rows
+   only).** When scheduling a `dm_session` row with
+   `taskContext.sub_flow="confirm"`, additionally filter
+   `GET /api/schedule?status=pending,running` by
+   `taskContext.confirm_dedup_key`. Skip if any match exists —
+   regardless of `scheduledFor` distance or description match. The
+   confirm sub-flow's chained-fire model (see `scheduled.dm.md`
+   §"Confirmation follow-up" Step 3) and a hot-thread defer (Step 1
+   check 1) both inherit the same dedup_key, so a successor or defer
+   row legitimately occupies the queue with the same key — a second
+   gate firing for the same topic MUST yield to it rather than
+   double-asking.
+
+   ```bash
+   curl -s "http://localhost:8321/api/schedule?status=pending,running" \
+     | jq --arg k "<gate>:<stable-topic>" \
+         '[.items[] | select(.taskContext.confirm_dedup_key == $k)] | length'
+   ```
+
+   If the count is `≥ 1`, log to `## Agent Log` and proceed without
+   scheduling:
+   ```
+   - HH:MM [confirm] skipped <dedup_key>: row already pending
+   ```
+
+   **`confirm_dedup_key` shape contract.** The key is
+   `<gate>:<stable-topic>` — for example
+   `create_project:la-pm-masters`,
+   `roadmap_ambiguous:tokyo-trip-date`,
+   `managed_task_dedup:<existing-task-id>`. The gate scope ensures
+   two unrelated gates can't collide on the same topic name; the
+   topic component MUST be deterministic from the topic itself
+   (no timestamps, no message IDs, no random nonces) so re-fires of
+   the same gate produce the same key and this pre-flight catches
+   them.
+
+   This rule layers on top of bullets 1-3, which catch the common
+   recurring / Agent-Plan duplicates. Bullet 4 catches the case
+   where two confirms target the same topic at different scheduled
+   times (e.g. one queued for the morning briefing, another the
+   gate would queue for `+4h`).
 
 Log the skip to `## Agent Log`:
 `- HH:MM [schedule] skipped <subject>: duplicate of <planId|row>`.
 
-Only after all three clear do you create the new schedule.
+Only after all four clear do you create the new schedule.
 
 ## When the user wants a durable rule, not a wake-up
 
@@ -151,7 +192,7 @@ curl -s -X POST http://localhost:8321/api/schedule \
 | `model` | No | `sonnet` (default) or `opus` |
 | `taskContext` | No | Structured metadata object |
 
-Rejects times in the past (> 1 min ago), same as `/api/schedule/dm`.
+Response: `{ "status":"scheduled", "scheduleId":"123", "scheduledFor":"YYYY-MM-DD HH:MM:SS" }`. `scheduledFor` is the normalized UTC SQLite timestamp the daemon actually stored — log this verbatim instead of re-formatting the input `time`. Rejects times in the past (> 1 min ago), same as `/api/schedule/dm`.
 
 ### PATCH /api/schedule/:id — Edit a pending item
 ```bash
@@ -170,7 +211,7 @@ Param `status` (default `pending,running`): comma-separated `pending`, `running`
 Param `roadmapEligible=true`: return only rows that may become
 roadmap `Scheduled:` entries (`transient` / `low` excluded, `normal`
 only beyond 7 days, `strategic` included).
-Response: `{ "items":[{ "id","scheduledFor","taskType","description","prompt","status","createdAt" }] }` — `prompt` is `null` when no override is set.
+Response: `{ "items":[{ "id","scheduledFor","taskType","description","prompt","status","model","taskContext","createdAt" }] }` — `prompt` is `null` when no override is set. `taskContext` is the parsed JSON object (or `null` when none was stored); use it for sub-flow-aware filtering, e.g. `jq '.items[] | select(.taskContext.confirm_dedup_key == "create_project:la-pm-masters")'`.
 
 ### DELETE /api/schedule/:id — Cancel a pending item
 ```bash

package/agent-assets/skills/today/SKILL.md

@@ -9,11 +9,31 @@ allowed-tools:
 # today.md Guide
 
 Output language: follow `<output_language_policy>`. today.md is
-Policy B — the six required H2 headers (`## User Schedule`,
-`## User Tasks`, `## Agent Plan`, `## Agent Notes`, `## Agent Log`,
-`## Handoff`) are skeleton and stay English; bullets, narrative, and
-free-text fields under them are written in `<settings primary_language>`.
-Preserve user-customized headers verbatim.
+Policy B — the **skeleton lines listed below stay English verbatim**;
+bullets, narrative, and free-text fields under each H2 are written in
+`<settings primary_language>`. Preserve user-customized headers verbatim.
+
+**Skeleton (do NOT translate — exact-regex-validated on PUT):**
+
+1. **Line 1** — `# YYYY-MM-DD (day-of-week)` H1 date line. The weekday
+   inside `(...)` is free-form and may be localized; the rest is fixed.
+2. **Line 2** — `> Day type: …` blockquote (full pattern below). Field
+   labels (`Day type`, `Work focus`, `Study focus`, `Personal focus`),
+   values (`Weekday`/`Weekend`, `on`/`off`), pipe separators (` | `),
+   and the leading `> ` are **all English ASCII, fixed casing, fixed
+   spacing**. This is parsed by every downstream event handler.
+3. **The six H2 headers** — `## User Schedule`, `## User Tasks`,
+   `## Agent Plan`, `## Agent Notes`, `## Agent Log`, `## Handoff` —
+   in this order.
+
+A `PUT /api/context/today` whose line 1 or line 2 fails the exact regex
+is rejected with 400 and the daemon does NOT write the file. Translating
+any keyword on line 2 (the field labels, the `Weekday`/`Weekend` value,
+or `on`/`off`) into the user's primary language is the most common
+failure mode — keep it English even when the rest of today.md is being
+written in another language. The `<output_language_policy>` skeleton
+precedence rule already covers this; this paragraph just makes the
+consequence explicit.
 
 today.md has a **day-type header line** (second line) and **six required sections**.
 
@@ -186,15 +206,34 @@ PUT today.md must contain the H1 date line, day-type header quote, and all six s
 
 ## today.md API (subset of context API)
 
+Body submission follows the rule in `_safety.md` "Daemon-API body
+submission": small section PATCHes use inline `-d '{...}'`; full-file
+PUT uses the stdin heredoc `-d @- <<'JSON'` shape because the body
+runs multi-KB. Add `X-Lock-Id: <today_write_lock_id>` on every
+PUT / PATCH when that tag is in your context.
+
 ```bash
-curl -s http://localhost:8321/api/context/today                    # Read
-curl -s -X PUT http://localhost:8321/api/context/today \            # Full replace (Morning only)
-  -H 'Content-Type: application/json' -d '{"content": "# 2026-04-02 (Thu)\n..."}'
-curl -s -X PATCH http://localhost:8321/api/context/today \          # Section operation
-  -H 'Content-Type: application/json' -d '{"section": "agent_log", "mode": "append", "content": "- 09:35 ..."}'
+# Read
+curl -s http://localhost:8321/api/context/today
+
+# Full replace — Morning Routine only. Multi-KB body → heredoc.
+curl -s -X PUT http://localhost:8321/api/context/today \
+  -H 'Content-Type: application/json' \
+  -H 'X-Lock-Id: <today_write_lock_id>' \
+  -d @- <<'JSON'
+{"content":"# 2026-04-02 (Thursday)\n> Day type: Weekday | Work focus: on | Study focus: on | Personal focus: on\n\n## User Schedule\n- 14:00–15:00 Design review [work]\n\n## User Tasks\n- [ ] 11:00 Finalize Q2 draft [work]\n\n## Agent Plan\n- [ ] 08:55 DM reminder: standup [work] →DM\n\n## Agent Notes\n\n## Agent Log\n- 04:00 Morning Routine completed (day-type: Weekday)\n\n## Handoff\n- (none)\n"}
+JSON
+
+# Section operation — small body, inline `-d` is fine.
+curl -s -X PATCH http://localhost:8321/api/context/today \
+  -H 'Content-Type: application/json' \
+  -H 'X-Lock-Id: <today_write_lock_id>' \
+  -d '{"section":"agent_log","mode":"append","content":"- 09:35 ..."}'
 ```
 
-Add `X-Lock-Id` header if `<today_write_lock_id>` is in context. See context skill for full API reference.
+The H1 date and the `> Day type:` quote line are validated by exact
+regex on PUT — keep both English-shaped exactly as the template. See
+context skill for the full endpoint reference.
 
 ## Knowledge map — section shape (auto-curated)
 

package/agent-assets/skills/travel-time/SKILL.md

@@ -43,6 +43,15 @@ enabled.
    `external-services` skill — cross-backend variant for worked
    examples).
 <!-- /mode:delegated-cross:google_calendar -->
+<!-- mode:native:google_calendar -->
+   Native mode → use this session backend's native Calendar
+   list-events MCP tool (same call shape as `delegated-same`). The
+   materialized `external-services` skill body
+   (`SKILL.native.<session-backend>.md`) lists the per-backend tool
+   names. The daemon does not proxy in native mode;
+   `/api/calendar/events` returns 410 and
+   `/api/integrations/google_calendar/exec` returns 410 too.
+<!-- /mode:native:google_calendar -->
 <!-- mode:disabled:google_calendar -->
    Disabled → skip this skill; there is no calendar to source events from.
 <!-- /mode:disabled:google_calendar -->