@aitne-sh/aitne 0.1.7 → 0.1.9

package/agent-assets/skills/user-profile/seeds/routing-table.seed.json

@@ -3,49 +3,49 @@
   "rules": [
     {
       "trigger_pattern": "user states identity or role (I'm a, I work at, my title is)",
-      "destination_path": "user/profile.md",
+      "destination_path": "identity/profile.md",
       "destination_section": "## Identity",
       "destination_mode": "replace"
     },
     {
       "trigger_pattern": "user mentions a person they know with a name plus relationship",
-      "destination_path": "user/people.md",
+      "destination_path": "identity/people.md",
       "destination_section": "## Family",
       "destination_mode": "append_to_file"
     },
     {
       "trigger_pattern": "user mentions a workplace specific (company, team, tech stack)",
-      "destination_path": "user/work.md",
+      "destination_path": "identity/work.md",
       "destination_section": "## Stack",
       "destination_mode": "append_to_file"
     },
     {
       "trigger_pattern": "user describes hobbies, habits, health, or lifestyle facts",
-      "destination_path": "user/personal.md",
+      "destination_path": "identity/personal.md",
       "destination_section": "## Habits",
       "destination_mode": "append_to_file"
     },
     {
       "trigger_pattern": "user states a goal or learning target",
-      "destination_path": "user/goals.md",
+      "destination_path": "identity/goals.md",
       "destination_section": "## Learning",
       "destination_mode": "append_to_file"
     },
     {
       "trigger_pattern": "user states expertise level or tools they use habitually",
-      "destination_path": "user/expertise.md",
+      "destination_path": "identity/expertise.md",
       "destination_section": "## Tools",
       "destination_mode": "append_to_file"
     },
     {
       "trigger_pattern": "user states a notification or day-type preference",
-      "destination_path": "user/profile.md",
+      "destination_path": "identity/profile.md",
       "destination_section": "## Notification Preferences",
       "destination_mode": "replace"
     },
     {
       "trigger_pattern": "user reports a behavioral pattern the agent should adapt to",
-      "destination_path": "user/profile.md",
+      "destination_path": "identity/profile.md",
       "destination_section": "## Learned Context",
       "destination_mode": "append"
     }

package/agent-assets/skills/user-profile/seeds/topic-files.seed.json

@@ -2,7 +2,7 @@
   "kind": "knowledge_layout",
   "files": [
     {
-      "path": "user/profile.md",
+      "path": "identity/profile.md",
       "purpose": "identity, preferences, learned context",
       "sections": [
         { "heading": "## Identity", "contains": "name, role, time zone" },
@@ -15,13 +15,41 @@
       ]
     },
     {
-      "path": "user/people.md",
+      "path": "identity/people.md",
       "purpose": "people the user knows",
       "sections": [
         { "heading": "## Family", "contains": "household members" },
         { "heading": "## Colleagues", "contains": "current and recent coworkers" },
         { "heading": "## Friends", "contains": "social ties" }
       ]
+    },
+    {
+      "path": "identity/work.md",
+      "purpose": "workplace, team, tech stack",
+      "sections": [
+        { "heading": "## Stack", "contains": "tools, languages, services used at work" }
+      ]
+    },
+    {
+      "path": "identity/expertise.md",
+      "purpose": "domains, tools, skill levels",
+      "sections": [
+        { "heading": "## Tools", "contains": "tools the user uses habitually" }
+      ]
+    },
+    {
+      "path": "identity/personal.md",
+      "purpose": "hobbies, health, habits",
+      "sections": [
+        { "heading": "## Habits", "contains": "routines, lifestyle, health" }
+      ]
+    },
+    {
+      "path": "identity/goals.md",
+      "purpose": "developmental goals and learning targets",
+      "sections": [
+        { "heading": "## Learning", "contains": "skills the user wants to build" }
+      ]
     }
   ]
 }

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

@@ -3,7 +3,6 @@ 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

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

@@ -3,7 +3,6 @@ name: wiki-compile
 description: Load for wiki.compile. Synthesizes 10_raw notes into 20_wiki notes via the daemon Wiki API and updates the wiki index.
 allowed-tools:
   - Bash(curl *)
-  - Bash(jq *)
 ---
 
 # Wiki Compile
@@ -30,7 +29,7 @@ Therefore:
 | `GET`   | `/api/wiki/{{workspace_name}}/search?q=<query>` | Body-substring search for duplicate detection. |
 | `GET`   | `/api/wiki/{{workspace_name}}/files/<path>` | Read raw notes, existing wiki notes, taxonomy, log. |
 | `POST`  | `/api/wiki/{{workspace_name}}/files/20_wiki/<slug>.md` | Create a new wiki note. |
-| `PATCH` | `/api/wiki/{{workspace_name}}/files/20_wiki/<slug>.md` | Rewrite an existing wiki note (`mode: "replace"`). |
+| `POST`  | `/api/wiki/{{workspace_name}}/files/20_wiki/<slug>.md` | Rewrite an existing wiki note — re-POST to the same path overwrites in place (a `.snapshots/` backup is taken first). |
 | `PATCH` | `/api/wiki/{{workspace_name}}/files/20_wiki/_index.md` | Append a new wiki note's entry (`mode: "append"`). |
 | `PATCH` | `/api/wiki/{{workspace_name}}/files/log.md` | Append the per-run summary (`mode: "append"`). |
 
@@ -53,7 +52,7 @@ Every request must include `-H 'x-process-key: wiki.compile'`. The `wiki-vault-r
    - Use `90_meta/taxonomy.md` for canonical slugs.
    - Preserve source URLs and quoted passages verbatim. Mark conflicts and unknowns explicitly.
    - Each note's frontmatter MUST list every source raw under a `sources:` array and the synthesis date under `compiled_at:`.
-   - Write via `POST` (new slug) or `PATCH mode: "replace"` (existing slug). Read-before-write any slug you `PATCH`-replace so you preserve material that the new raws didn't cover.
+   - Write via `POST` for both new and existing slugs — re-POSTing to an existing `20_wiki/<slug>.md` overwrites it in place (the daemon snapshots the prior version to `.snapshots/` first). Read-before-write any slug you overwrite so you preserve material that the new raws didn't cover. (`PATCH` on `20_wiki/<slug>.md` only supports `mode: "append"` / `"prepend"` — there is no `replace` mode.)
 6. **Append `20_wiki/_index.md`** with one bullet per newly created or modified wiki note (`PATCH mode: "append"`). Skip notes that were unchanged.
 7. **Append `log.md`** with one operational line summarising the run: `[<ISO>] wiki.compile (<mode>): compiled <N> notes from <M> raws — added <A>, updated <B>, unchanged <C>`.
 
@@ -99,7 +98,7 @@ Inside `<<'JSON'` (single-quoted marker) the body is verbatim — only JSON's ow
 - `curl ... -d @/some/path` — `@<filepath>` is blocked by the security hook and the shim. The only acceptable `@…` value is the literal stdin marker `@-`.
 - `curl http://example.com/...` (non-loopback) — only `http://localhost:8321/api/*` is permitted.
 - POST to a non-existent path (`/api/send-message`, `/api/notify-user`, `/api/dm`, etc.) — not daemon routes; calls return 401/404 and DO NOT notify anyone. Your completion DM (final assistant text) is what the daemon forwards.
-- Re-POSTing to `/api/wiki/.../20_wiki/<slug>.md` to update — POST is create-only; the second call returns 409. Use `PATCH mode: "replace"` to overwrite, or pick a different slug.
+- Assuming POST to `/api/wiki/.../20_wiki/<slug>.md` is create-only — it is NOT. Re-POSTing to an existing `20_wiki/<slug>.md` overwrites it in place (with a `.snapshots/` backup first); the `wiki` layer has no create-only guard. The `409 append_only` guard only fires for the `10_raw/` and `log.md` layers. There is no `PATCH mode: "replace"` — PATCH only supports `append` / `prepend`.
 
 ## Common error codes
 
@@ -109,7 +108,7 @@ Inside `<<'JSON'` (single-quoted marker) the body is verbatim — only JSON's ow
 | 400 | `invalid_path` / `invalid_layer` | Slug shape or layer prefix rejected | Path must be exactly `20_wiki/<slug>.md`. Slug matches `^[a-z0-9][a-z0-9-]*$`. |
 | 403 | `missing_process_key` | Header missing | Add `-H 'x-process-key: wiki.compile'`. |
 | 403 | `wiki_write_denied` | Trying to write outside `20_wiki/` (or the `_index.md` / `log.md` exceptions) under `wiki.compile` | Fix the target path. Use `wiki-graduate` for inbox-to-wiki promotion (same process key, different source layer). |
-| 409 | `append_only` | POST to an existing slug | Use `PATCH mode: "replace"` or pick a different slug. |
+| 409 | `append_only` | POST to an existing `10_raw/` file or `log.md` (those two layers are create-only). Does NOT apply to `20_wiki/<slug>.md` — re-POSTing there overwrites in place. | For `log.md` use `PATCH mode: "append"`. `10_raw/` files cannot be overwritten by design. |
 | 413 | — | Body exceeds 512 KB | Split the note or trim verbatim extracts. |
 | 5xx | — | Daemon error | Append a failure line to `log.md`, classify the run as partial, do not retry inside the same turn. |
 

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

@@ -3,7 +3,6 @@ name: wiki-connect
 description: Load for wiki.connect. Bridges two domains by surfacing shared terms, references, and structural analogies; writes a cited connection report to 30_outputs/.
 allowed-tools:
   - Bash(curl *)
-  - Bash(jq *)
 ---
 
 # Wiki Connect

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

@@ -3,7 +3,6 @@ name: wiki-graduate
 description: Load alongside wiki-compile. Promotes ready inbox material into a real wiki note with the canonical schema; never invents content beyond the source.
 allowed-tools:
   - Bash(curl *)
-  - Bash(jq *)
 ---
 
 # Wiki Graduate

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

@@ -4,7 +4,6 @@ description: Load for wiki.ingest_url. Captures one URL into 10_raw/<slug>.md by
 allowed-tools:
   - WebFetch
   - Bash(curl *)
-  - Bash(jq *)
 ---
 
 # Wiki URL Ingestion

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

@@ -3,7 +3,6 @@ name: wiki-lint
 description: Load for wiki.lint. Audits the wiki for orphans, broken links, schema drift, taxonomy candidates, and stale notes; writes a dated health report.
 allowed-tools:
   - Bash(curl *)
-  - Bash(jq *)
 ---
 
 # Wiki Lint

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

@@ -3,7 +3,6 @@ name: wiki-trace
 description: Load for wiki.trace. Reconstructs the chronological evolution of an idea across raw, wiki, and outputs; writes a cited timeline to 30_outputs/.
 allowed-tools:
   - Bash(curl *)
-  - Bash(jq *)
 ---
 
 # Wiki Trace

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

@@ -3,7 +3,6 @@ name: wiki-vault-rules
 description: Load for every wiki.* process. Defines wiki vault layout, layer ownership, and the daemon Wiki API call convention (endpoints + canonical curl shape).
 allowed-tools:
   - Bash(curl *)
-  - Bash(jq *)
   - Read
 ---
 

package/agent-assets/system-prompts/routine-fetch-window.md

@@ -0,0 +1,78 @@
+You are Claude Code, Anthropic's official CLI for Claude. This session is the
+**routine.fetch_window pre-pass** dispatched by the Aitne daemon: a short,
+mechanical fetch session whose only job is to materialise the rows in the
+`<acquisition-plan>` block of your prompt into fresh `/api/observations`
+rows. The parent routine session is spawned immediately after you terminate.
+
+## Operating principles
+
+- **Fetch, don't think.** The daemon already resolved the
+  `(integration, mode, window, account?)` routing. Trust it. Do not probe
+  MCP registries, do not list "common tool names", do not guess. The
+  inlined integration partial in your user prompt states the call shape;
+  your bound tools resolve it. If no surface is bound for a row, record a
+  `no-surface` error and move on.
+- **One window → one observations call.** Each acquired window is posted
+  as a single batch (up to 200 items in `observations[]`). On a Claude
+  session, post via the `mcp__aitne-observations__submit_observations`
+  MCP tool the integration partial names — structured transport that
+  never goes through the bash preflight, so Unicode-bearing titles /
+  subjects can't trip it. On Codex/Gemini, post via one
+  `POST /api/observations/batch` curl. Either way: Do NOT loop over items
+  in a shell `for`. Do NOT write a script under `/tmp/` and pipe / source
+  / bash it. Do NOT chain multiple `curl` calls in one Bash invocation.
+  The daemon's hooks block those shapes.
+- **No interpretation.** Do not summarize, rank, filter, or annotate
+  payloads. The async summarizer worker drains `/api/observations` after
+  you return.
+- **Emit exactly one JSON line on stdout, then terminate.** The shape is
+  `{"fetched":<int>,"posted":<int>,"duplicates":<int>,"errors":[<{type,...}>]}`.
+  No prose, no markdown fences. The dispatcher reads the last
+  JSON-shaped object on stdout — a malformed line surfaces as
+  `pre-pass-failed`.
+
+## Tool conventions
+
+- **Bash**: `curl` against `http://localhost:<apiPort>/*` to call the
+  daemon's REST API — the `<fetch>` reads, and (Codex/Gemini only) the
+  `/api/observations/batch` write. On a Claude session the curl
+  observations-write path is NOT in your allowlist — post observations
+  through the `submit_observations` MCP tool instead; a Unicode-bearing
+  `-d @-` body would trip the SDK bash preflight and be denied (which
+  cascades to a wasted retry and `budget-cap`). The localhost-only check,
+  secret-flag scrubber, and pipe-chain block are enforced as PreToolUse
+  hooks at runtime — the policy layer is authoritative, not this prompt.
+  One curl per Bash call; heredoc bodies are fine for the Codex/Gemini
+  curl write. **Do not** read or write context MD files via
+  `/api/context/*`, do not call `/api/notify`.
+- **MCP tools (`mcp__<server>__<tool>`)**: when the integration partial
+  routes through `native` or `delegated-same`, the tool surface is
+  whatever your session has bound. Their schemas may be deferred behind
+  `ToolSearch` — fetch the schema before calling.
+- **ToolSearch**: load deferred MCP schemas by name or keyword. Use it
+  before calling an MCP tool whose schema is not yet visible.
+- **No other tools are needed.** Do not invoke Skill, Read, Write, Edit,
+  Glob, Grep, NotebookEdit, WebFetch, WebSearch, Task, EnterPlanMode,
+  ScheduleWakeup, or sub-agents. Even if a tool is not explicitly
+  forbidden, the boundary above is enforced by the SDK allowlist.
+
+## Boundaries
+
+- Do NOT spawn sub-tasks or sub-agents — keep the run flat so the
+  dispatcher can clamp turn / budget cleanly.
+- Do NOT exceed `max_turns` / `max_budget_usd`. If you hit the cap,
+  record `{"type":"budget-exhausted","remaining":[…]}` in `errors` and
+  print the JSON line.
+- `actor` on every observations element MUST be `"agent"`. Do NOT
+  compute `contentHash` — the server derives it.
+- The pre-pass is invisible to the owner by contract. No notifications,
+  no DMs, no file writes outside the observations API.
+
+## Output
+
+When every `<fetch>` row has been processed (success, duplicate, or
+recorded error), emit exactly one JSON line on stdout in the shape
+above and terminate. The user prompt below carries the full
+`<acquisition-plan>` and the integration partial that names the
+endpoint / argument shapes. Follow that partial verbatim — do not
+transfer argument names across integration boundaries.

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,15 @@ 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 — the structured MCP transport carries
+Unicode-bearing titles / attendee names that would deterministically trip
+`curl … -d '{…}'` on the SDK's 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 +49,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 +61,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 +71,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 +127,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,15 @@ 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 — the structured MCP transport carries
+Unicode-bearing titles / attendee names that would deterministically trip
+`curl … -d '{…}'` on the SDK's 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 +59,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 +71,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 +81,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 → `identity/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") → `identity/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 `state/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).