@aitne-sh/aitne 0.1.3 → 0.1.5

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

@@ -8,6 +8,13 @@ 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.
+
 today.md has a **day-type header line** (second line) and **six required sections**.
 
 ```
@@ -179,15 +186,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/user-interview/SKILL.md

@@ -37,7 +37,7 @@ curl -s http://localhost:8321/api/context/agent/profile-questions
 | `target_path` | which user file the answer should land in, e.g. `user/profile.md` |
 | `## Section`  | optional — narrows to a section within the target file |
 | `match=<anchor>` | optional — bullet key (English, like `Name`, `Timezone`, `Sleep`, `Working hours`). Required when multiple rows share a section, or when setup pre-seeds the section with an unrelated bullet |
-| `ask-hint`    | English brief of WHAT to ask. Render the actual DM in the user's `primary_language` at delivery time |
+| `ask-hint`    | English brief of WHAT to ask (agent-internal, Policy A). Render the actual DM per `<output_language_policy>` — this skill intentionally splits the two surfaces |
 | `last_attempted=...` | optional inline HTML comment maintained by the evening sweep — selector deprioritises rows whose comment is < 7 days old |
 
 ### In Progress entry format

package/agent-assets/skills/user-profile/SKILL.md

@@ -8,6 +8,13 @@ allowed-tools:
 
 # User Profile Update Guide
 
+Output language: follow `<output_language_policy>`. `user/profile.md`
+and `user/*.md` are Policy B — template H2 headers (`## Identity`,
+`## Work Pattern`, `## Platforms`, `## Expertise`, `## Notification
+Preferences`, `## Learned Context`, `## Raw Signals`) are skeleton and
+stay English; the facts you write under them are in
+`<settings primary_language>`. Preserve user-customized headers verbatim.
+
 `user/profile.md` stores the user's identity, preferences, and learned behavioral patterns. It is injected into every agent session via `<user>` tags — keep it concise (target: under ~600 tokens total).
 
 Detailed, dictionary-like background belongs under `user/*.md`. Read `user/_index.md` first, then fetch only the topic file you need.

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

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

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

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

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

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

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

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

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

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

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

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