@aitne-sh/aitne 0.1.5 → 0.1.7

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

@@ -133,6 +133,65 @@ 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
@@ -154,10 +213,25 @@ curl -s -X POST http://localhost:8321/api/observations/consume \
 | Field | Type | Required | Notes |
 |---|---|---|---|
 | `ids` | `number[]` | yes | Integers, not strings. `["14"]` is rejected. |
-| `correlationId` | `string` | yes | Verbatim from the `<event_correlation_id>` context tag. Non-string or missing → 400. |
+| `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> }`. Validation failures return 400
-`{"error":"validation_error"}`.
+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
 
@@ -210,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
@@ -249,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`.

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**.
 

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 -->

package/agent-assets/skills/wiki/wiki-ask/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: wiki-ask
+description: Load for wiki.ask. Answers a question from the wiki and records the answer under 30_outputs.
+allowed-tools:
+  - Bash(curl *)
+  - Bash(jq *)
+---
+
+# Wiki Ask
+
+You run under process key `wiki.ask`.
+
+Read `<wiki_command>` for the user's `question`. Search and read relevant `20_wiki/` notes first; read `10_raw/` only when the wiki notes need source verification.
+
+Write the answer to:
+
+```
+POST /api/wiki/{{workspace_name}}/files/30_outputs/<YYYY-MM-DD>-<slug>.md
+x-process-key: wiki.ask
+```
+
+The output must include the question, short answer, evidence, source links, and follow-up gaps. If the wiki does not contain enough evidence, say that directly and list what is missing.
+
+### Completion message (mandatory)
+
+End the turn with a short final assistant message that the daemon forwards back to the channel the bang command came from. This is what the user actually reads on their phone — make it the answer in plain prose:
+
+- Lead with the answer in one short paragraph (3–5 lines max).
+- Cite the wiki pages you drew from inline (`see [[<slug>]]`).
+- End with `Full answer: 30_outputs/<YYYY-MM-DD>-<slug>.md` so the user can dig deeper.
+- On insufficient evidence: `Wiki has no entry for <topic>. Missing: <one-line gap>.` and skip the file pointer.
+