@aitne-sh/aitne 0.1.7 → 0.1.8

package/agent-assets/system-prompts/skill-index-instruction.md

@@ -0,0 +1,26 @@
+## Skills
+
+You have access to skills materialized under `.codex/skills/` (or
+`.gemini/skills/` when running Gemini). Each skill is a small markdown
+file with frontmatter (`name`, `description`, `allowed-tools`) followed
+by guidance and worked examples.
+
+All skills require: `Bash(curl *)` for daemon API calls, `Read` for
+on-demand `SKILL.md` introspection. Skills with additional tool
+requirements declare them in their own `SKILL.md` frontmatter — `Read`
+the file to see the full list before invoking those tools.
+
+Before acting on a user request:
+
+1. Scan the `<skill-index>` below for a skill whose `description` matches
+   your task.
+2. If one matches, `Read` `.codex/skills/<name>/SKILL.md` (or
+   `.gemini/skills/<name>/SKILL.md`) and follow its contents. The path is
+   fixed by the header sentence inside `<skill-index>`; the `<name>` comes
+   verbatim from the entry.
+3. You may load multiple skills in a single turn.
+4. Do not invent skill names — only use entries listed in `<skill-index>`.
+
+The directory under `.codex/skills/` (or `.gemini/skills/`) is the
+authoritative source of skill content. Anything inlined in this system
+prompt above is supporting context only.

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

@@ -1,7 +1,7 @@
 ---
 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
+spec: docs/design/appendices/routine-data-acquisition.md §6.8 / §8.3
 ---
 
 # Google Calendar acquisition
@@ -17,8 +17,13 @@ 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 — for a whole window in **one** call — to
-`http://localhost:8321/api/observations/batch`. Build the body as:
+Submit every returned event — for a whole window in **one** call — via the
+`mcp__aitne-observations__submit_observations` MCP tool when it is in your
+allowed tools (preferred — bypasses the SDK bash preflight). Build the
+tool input as `{"observations":[…]}` with one entry per event.
+
+If the MCP tool is unavailable (non-Claude session backend), fall back to
+`POST http://localhost:8321/api/observations/batch` with the same envelope:
 
 ```json
 {"observations":[
@@ -42,9 +47,10 @@ Field rules per element:
                     "raw": { "title": ..., "start": ..., "end": ...,
                              "attendees": [...], "status": ... } }`
 
-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`:
+Server computes the dedup hash from `(source, payload)`. The MCP tool and
+the batch endpoint return the same envelope: `{ "results": [...],
+"fetched": N, "posted": N, "duplicates": N, "errors": N }`. Per-item
+`results[*].status`:
 
 - `"created"` / `"modified"` — rolled into `posted`.
 - `"duplicate"` — rolled into `duplicates`.
@@ -53,8 +59,8 @@ always returns `200` with a JSON envelope `{ "results": [...], "fetched": N,
 - `"validation_error"` — append `{type:"validation-error","integration":"google_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.
+Cap each batch at 200 entries — split the window into multiple
+`submit_observations` (or POST) calls if the upstream returns more than that.
 
 <!-- mode:direct:google_calendar -->
 GET `http://localhost:8321/api/calendar/events<query>` where `<query>` is
@@ -63,7 +69,8 @@ the literal `query` attribute of the `<fetch>` row (e.g.
 accepts `date=YYYY-MM-DD` (or `today`) plus `days=N` (≤90); `timeMin`
 / `timeMax` are NOT recognised. The daemon returns `{ "events": [...] }`;
 map every event into the `observations[]` array of a single
-`POST /api/observations/batch` call.
+`submit_observations` MCP tool call (or `POST /api/observations/batch`
+fallback).
 <!-- /mode:direct:google_calendar -->
 
 <!-- mode:delegated-same:google_calendar -->
@@ -118,8 +125,8 @@ following body (substitute the row's `query` into `task`):
 }
 ```
 
-Map all items in `result.events[]` into a single
-`POST /api/observations/batch` call.
+Map all items in `result.events[]` into a single `submit_observations`
+MCP tool call (or `POST /api/observations/batch` fallback).
 <!-- /mode:delegated-cross:google_calendar -->
 
 <!-- mode:native:google_calendar -->

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

@@ -1,7 +1,7 @@
 ---
 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
+spec: docs/design/appendices/routine-data-acquisition.md §6.8 / §8.4
 ---
 
 # Outlook Calendar acquisition
@@ -28,8 +28,13 @@ 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 — for a whole window in **one** call — to
-`http://localhost:8321/api/observations/batch`. Build the body as:
+Submit every returned event — for a whole window in **one** call — via the
+`mcp__aitne-observations__submit_observations` MCP tool when it is in your
+allowed tools (preferred — bypasses the SDK bash preflight). Build the
+tool input as `{"observations":[…]}` with one entry per event.
+
+If the MCP tool is unavailable (non-Claude session backend), fall back to
+`POST http://localhost:8321/api/observations/batch` with the same envelope:
 
 ```json
 {"observations":[
@@ -52,9 +57,10 @@ Field rules per element:
                     "raw": { "title": ..., "start": ..., "end": ...,
                              "attendees": [...], "status": ... } }`
 
-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`:
+Server computes the dedup hash from `(source, payload)`. The MCP tool and
+the batch endpoint return the same envelope: `{ "results": [...],
+"fetched": N, "posted": N, "duplicates": N, "errors": N }`. Per-item
+`results[*].status`:
 
 - `"created"` / `"modified"` — rolled into `posted`.
 - `"duplicate"` — rolled into `duplicates`.
@@ -63,8 +69,8 @@ always returns `200` with a JSON envelope `{ "results": [...], "fetched": N,
 - `"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.
+Cap each batch at 200 entries — split the window into multiple
+`submit_observations` (or POST) calls if the upstream returns more than that.
 
 <!-- mode:direct:outlook_calendar -->
 GET `http://localhost:8321/api/calendar/outlook/events<query>` where
@@ -73,7 +79,8 @@ GET `http://localhost:8321/api/calendar/outlook/events<query>` where
 accepts `date=YYYY-MM-DD` (or `today`) plus `days=N` (≤90); `timeMin`
 / `timeMax` are NOT recognised. The daemon returns
 `{ "events": [...] }`; map every event into the `observations[]` array
-of a single `POST /api/observations/batch` call.
+of a single `submit_observations` MCP tool call (or `POST
+/api/observations/batch` fallback).
 <!-- /mode:direct:outlook_calendar -->
 
 <!-- mode:delegated-same:outlook_calendar -->

package/agent-assets/task-flows/_partials/capture-user-info.md

@@ -0,0 +1,24 @@
+---
+# capture-user-info — canonical trigger-shape enumeration + routing rules
+# for silent same-turn user-info writes. Included from:
+#   - message.received.dm.md (Step 1)
+#   - message.received.dm_first.md (Step 1)
+#   - routine.user_profile_sweep.md (Step 2)
+#   - routine.evening_review.md (Step 3 cross-reference)
+# Source of truth: this partial. The user-profile skill is the writer
+# (file split, read-before-write, section_not_found fallback, anchor
+# convention); this partial is the trigger-and-routing summary the
+# task-flows consume.
+---
+
+Scan for declarative user facts or imperative tone/style directives. If matched, persist in the **same turn** — silent (no acknowledgement to the user); do not defer to Evening Review (the message may be truncated by then).
+
+**Imperative tone/style directives** ("always reply in English", "shorter please", "don't add emojis", "speak casually", "be more concise") are agent directives, NOT user facts → route per the user-profile skill §"Tone / character preferences". When ambiguous (e.g. "I prefer short replies"), default to character — never duplicate in profile.md.
+
+**Declarative facts about the user** → route through the user-profile skill. The skill owns the trigger shapes, the file split (`profile.md` vs `user/<topic>.md`), the read-before-write contract, the `section_not_found` → `append_to_file` first-write fallback, and the Learned-Context-vs-personal.md disambiguator. Key calls:
+
+- Top-level identity / platform / notification fact → `user/profile.md`.
+- Detail-heavy fact (specific person, workplace, hobby, tool, goal) → matching `user/<topic>.md` (`people` / `work` / `expertise` / `personal` / `goals`).
+- Self-reported behavioral pattern the agent should adapt to ("I'm not a morning person") → `user/profile.md ## Learned Context` with today's `[YYYY-MM-DD]` prefix.
+
+Never invent facts the user did not state. Never re-write a fact a paraphrase of which already exists in the target file.

package/agent-assets/task-flows/_partials/confirm-subflow.md

@@ -0,0 +1,68 @@
+<!--
+  Confirm sub-flow contract (`confirm:` `dm_session` rows).
+  Single source of truth for the `confirm_dedup_key` shape and the
+  cross-path cancellation behaviour. Included from:
+    - `scheduled.dm.md` (`## Confirmation follow-up`)
+    - `message.received.dm.md` / `message.received.dm_first.md`
+      (suppression rule → schedule a `confirm:` row instead)
+    - `schedule/SKILL.md` references this partial via the pointer
+      paragraph in its dedup pre-check section.
+-->
+
+### `confirm_dedup_key` pre-check (mandatory for `confirm:` sub-flow rows)
+
+When scheduling a `dm_session` row with `taskContext.sub_flow="confirm"`,
+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 (successor row queued for `<current_time> + 15 min`)
+and the hot-thread defer both inherit the same `dedup_key`, so a
+legitimate successor / defer row will occupy 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>`. Examples:
+
+- `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 the pre-flight catches them.
+
+This rule layers on top of the schedule skill's three baseline dedup
+checks (Agent Plan, description-match, recurring-schedule). It 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`).
+
+### Cross-path cancellation
+
+A pending `confirm:` row is cancelled by the agent updating
+`taskContext` on either:
+
+- The row itself (via `PATCH /api/schedule/:id`) when the originating
+  gate's outcome resolves through a non-confirm path (e.g. the user
+  answered inline before the scheduled `confirm:` fired).
+- A predecessor confirm row whose decision supersedes the topic.
+
+Cancellation is the gate's responsibility — the scheduler does not
+introspect `taskContext` for it. Use the `confirm_dedup_key` to locate
+the row(s) to cancel.

package/agent-assets/task-flows/_partials/dm-intent.long-horizon.md

@@ -0,0 +1,35 @@
+---
+# dm-intent.long-horizon — Long-horizon DM-intent detection decision tree.
+# Included from: message.received.dm.md (Step 4), message.received.dm_first.md
+# (Step 4). The `roadmap` skill is the WRITER (PUT / PATCH / archive); this
+# partial carries the trigger surface that the DM dispatcher applies before
+# the writer runs.
+---
+
+Referenced from `message.received.dm` and `message.received.dm_first`.
+Identify user messages that describe a commitment or plan beyond the
+current day so the DM handler can route them into roadmap.
+
+**Signals (positive):**
+- Explicit forward-looking verb + horizon phrase:
+  *"going to X next month"*, *"planning to do Y this summer"*,
+  *"want to Z this quarter"*
+- Specific future date ≥ 48h out
+- Concrete object (destination, deliverable, learning target,
+  reservation)
+
+**Not signals:**
+- Speculative language (*"maybe"*, *"someday"*, *"might"*, *"perhaps"*,
+  *"thinking about"*) without a concrete anchor
+- Current-week commitments (those belong in `today.md`)
+- Opinions, preferences, taste statements
+  (those belong in `user/*.md` via the `user-profile` skill)
+
+**Routing after detection:**
+- Dated ≥ 48h out → Agent Action Plan event entry (Preparation
+  Timeline grows once destination / details resolve).
+- Undated horizon ("this summer", "this quarter") →
+  `## Long-term Plans` line with a horizon-tag.
+- Ambiguous → keep in `agent-journal.md` as a candidate line and
+  surface via the next morning routine for user confirmation
+  (dry-run mode).