@aitne-sh/aitne 0.1.5 → 0.1.6

package/agent-assets/task-flows/scheduled.dm.md

@@ -78,6 +78,7 @@ content rules.
 
 - starts with `morning briefing` → see `## Morning briefing` below
 - starts with `profile_interview:` → see `## Profile interview` below
+- starts with `confirm:` → see `## Confirmation follow-up` below
 - (future sub-flows added here)
 
 If no sub-flow matches:
@@ -148,6 +149,16 @@ the daily greeting.
      to your own backend's native Gmail MCP tools — that connector
      reads a different account than the user's delegated one.
 <!-- /mode:delegated-cross:gmail -->
+<!-- mode:native:gmail -->
+     Non-Gmail accounts: use the `mail` skill as in direct mode.
+     Gmail accounts: the `/api/mail/*` per-account gate returns 410
+     `{"error":"integration_native"}` — use your session backend's
+     native Gmail MCP tool with a "10 most recent inbox" query
+     (`q=in:inbox`, limit/maxResults `10`). The materialized `mail`
+     skill body (`SKILL.native.<session-backend>.md`) lists the
+     per-backend tool names. The daemon does not proxy in native mode;
+     do NOT call `/api/integrations/gmail/exec` (also returns 410).
+<!-- /mode:native:gmail -->
 <!-- mode:disabled:gmail -->
      Gmail is disabled — skip Gmail accounts entirely. Continue with
      the remaining accounts (iCloud / Outlook / Yahoo / IMAP) via the
@@ -391,3 +402,469 @@ preserve any other entries byte-for-byte, PATCH `mode=replace`. Without
 this transition, the DM-handler queue-flip (Operation 4) will see
 `state=scheduled` and treat the user's reply as unrelated, leaving the
 row open.
+
+---
+
+## Confirmation follow-up
+
+Triggered by `{event_data[task]}` starting with `confirm:`. The DM
+handler scheduled this row because a gate (e.g. project-creation, a
+managed-task duplicate, a long-horizon ambiguity) was triggered during
+an earlier DM but could not be asked then — either the conversation
+topic was incompatible, or the user's reply was already long, or the
+universal "no topic-pivoting trailing question" rule in
+`message.received.dm{,_first}.md` suppressed the inline ask.
+
+The full `taskContext` schema is documented in
+`docs/design/appendices/dm-conversational-flow.md` §B1. The fields
+this sub-flow reads at fire time are:
+
+- `confirm_id` — opaque per-row identifier; logged on abort / fire
+- `confirm_dedup_key` (required) — stable topic key (`<gate>:<topic>`)
+- `confirm_hint` — agent-internal English brief of what to ask
+- `confirm_recent_window_hours` (default 24) — DM-history scan horizon
+- `confirm_attempt` (default 1) / `confirm_max_attempts` (default 2)
+  — retry accounting (see Step 3)
+- `confirm_defer_count` (default 0) / `confirm_max_defers` (default 3)
+  — active-conversation-interlock deferrals (see Step 1 check 1)
+- `confirm_decline_marker` (optional, `{path, section, match}`) —
+  file + section + match string that, when present in the named
+  context file, signals the user already declined
+- `confirm_slot` (optional, `{path, section?, anchor?}`) — file slot
+  that, when filled, means the answer already landed via a different
+  path
+
+### Step 1 — Fire-time abort or defer
+
+Four checks, run in order. **The first positive result terminates
+Step 1** — either abort silent or self-defer; checks after a positive
+are skipped.
+
+#### Check 1 — Active-conversation interlock
+
+Inspect `<recent_dm_messages window="60min">`:
+
+- **state=very-recent** (inbound user DM in the last 5 min):
+  **self-defer.** The user is mid-thread. Firing now violates Goal 1
+  ("don't break the conversation thread") even with a Variant-B
+  bridge. POST a replacement schedule row at
+  `<current_time> + 15 min` with the SAME `confirm_dedup_key`,
+  `confirm_attempt` unchanged, `confirm_defer_count += 1`, and all
+  other `taskContext` fields inherited:
+
+  ```bash
+  curl -s -X POST http://localhost:8321/api/schedule \
+    -H 'Content-Type: application/json' \
+    -d @- <<JSON
+  {
+    "time": "<current_time + 15min, ISO 8601 with offset>",
+    "taskType": "dm_session",
+    "description": "confirm:<topic> — <hint>",
+    "model": "sonnet",
+    "taskContext": {
+      "scheduledBy": "scheduled_dm.confirm_followup.self_defer",
+      "sub_flow": "confirm",
+      "confirm_id": "<new short id>",
+      "confirm_dedup_key": "<inherited>",
+      "confirm_hint": "<inherited>",
+      "confirm_recent_window_hours": <inherited>,
+      "confirm_attempt": <inherited unchanged>,
+      "confirm_max_attempts": <inherited>,
+      "confirm_defer_count": <prior + 1>,
+      "confirm_max_defers": <inherited>,
+      "confirm_decline_marker": <inherited>,
+      "confirm_slot": <inherited>,
+      "importance": "low"
+    }
+  }
+  JSON
+  ```
+
+  If `confirm_defer_count` after increment would **exceed**
+  `confirm_max_defers` (default 3, max total ~45 min delay), do NOT
+  re-schedule. Instead fall through to checks 2-4 below and let one
+  of them decide whether to fire or abort. The conversation has been
+  continuously hot for ~45 min; further deferral is unlikely to find
+  a better moment, and at this point the universal Goal-1-outranks-
+  Goal-3 rule means we accept Variant-B framing rather than letting
+  the confirm starve forever.
+
+  Log:
+  ```
+  - HH:MM [dm_session] confirm:<topic> deferred (defer=N): user mid-thread
+  ```
+  Then end the turn with NO assistant text.
+
+- **state=active** (last 30 min, not last 5 min): **proceed** to
+  check 2. The conversational weave (Variant B) framing in this
+  task flow handles the on-the-fly bridge.
+
+- **state=asleep**: **proceed** to check 2. Variant A applies.
+
+#### Check 2 — Decline-marker probe (when `confirm_decline_marker` is set)
+
+If `taskContext.confirm_decline_marker` is set, the user may have
+previously said "no" to this exact intent. Read the file and grep the
+named section for the `match` string:
+
+```bash
+curl -sS -w '\n%{http_code}' "http://localhost:8321/api/context/<confirm_decline_marker.path>"
+```
+
+A `404` status means the file has not yet been created → no marker
+can exist → continue to Check 3. On `200`, parse the body and look
+under the `<confirm_decline_marker.section>` heading: if any line in
+that section contains `<confirm_decline_marker.match>` as a
+substring, the marker is present → **abort silent** with reason
+`decline-marker`.
+
+#### Check 3 — Slot-filled probe (when `confirm_slot` is set)
+
+If `taskContext.confirm_slot` is set, the gate's durable state may
+have been written via a different path since this confirm was
+scheduled. Probe:
+
+```bash
+curl -s "http://localhost:8321/api/profile-questions/slot-filled?path=<confirm_slot.path>&section=<confirm_slot.section?>&anchor=<confirm_slot.anchor?>"
+```
+
+(The endpoint is profile-questions-named but generic — see
+`packages/daemon/src/core/profile-questions/slot-filled.ts`.)
+
+**Abort silent** with reason `slot-filled` when EITHER:
+
+- `filled: true` — the named section / anchor has a substantive
+  bullet. This is the standard case (e.g. user-profile slot already
+  landed via a separate write), OR
+- `fileExists: true` AND `confirm_slot.section` is null/omitted
+  AND `confirm_slot.anchor` is null/omitted — i.e. the gate
+  encoded "the file's mere existence is the answer". This covers
+  project-creation, where the durable state is "a
+  `projects/<slug>.md` file with frontmatter + H1 exists" rather
+  than "a specific section is populated". The endpoint reports
+  `filled: false` for a fresh frontmatter+H1 file (zero substantive
+  bullets), so a `filled`-only check would let the confirm fire
+  even though the project was already created — `fileExists` is
+  the correct signal in the no-section/no-anchor case.
+
+Otherwise (file does not exist, or filled=false with a section
+or anchor specified) continue to Check 4.
+
+#### Check 4 — DM-history scan
+
+Read `<recent_dm_conversation>` (last 20 turns) AND
+`<recent_dm_messages window="60min">`. Judge whether the user
+already answered the question described in
+`taskContext.confirm_hint`. Three answer shapes count as "answered":
+
+- **Affirmative resolution** — user wrote a sentence that lets the
+  gate complete its write. Examples: *"yeah, track it as
+  la-pm-masters"*, *"sounds good"*, *"go ahead"*, *"please do"*.
+  Abort silent with reason `already answered (yes) in DM`.
+- **Negative resolution** — user wrote a clear decline. Examples:
+  *"no"*, *"don't bother"*, *"later"*, *"skip it"*, *"drop it"*.
+  Abort silent with reason `already answered (no) in DM`. AND if
+  `taskContext.confirm_decline_marker` is set, write the marker now
+  (see §"Decline-marker write" below) so subsequent re-fires of the
+  same gate see the declined state.
+- **Volunteered answer** — user wrote the underlying fact without
+  prompting (e.g. *"I changed my mind about LA — heading back to
+  Tokyo"*, or supplied the value the gate would have asked for).
+  The gate's write-side picks this up. Abort silent with reason
+  `already answered (volunteered) in DM`.
+
+Does NOT count as "answered" (fire the DM):
+- bare re-mention without action: *"still thinking about LA PM"*
+- status updates on the topic without consent/decline: *"LA
+  classes started"*, *"midterm was hard"*
+- non-answer continuations: *"hmm"*, *"not sure"*
+
+The examples above are English for prompt clarity only; recognise
+the same shapes in any language the user writes in.
+
+**Bias conservative on ambiguous shapes, strict on explicit "yes" /
+"no".** A redundant ask is recoverable; a missed confirmation can
+leave a project / roadmap entry unwritten. When the DM-history
+evidence is genuinely ambiguous, fire the DM (fall through to
+Step 2).
+
+#### On abort
+
+1. Append one line to today.md `## Agent Log` via the `today` skill
+   (PATCH `mode: "append"`, `section: "agent_log"`):
+   ```
+   - HH:MM [dm_session] confirm:<topic> aborted: <reason>
+   ```
+   Where `<reason>` is one of `interlock-skip`, `decline-marker`,
+   `slot-filled`, `already answered (yes|no|volunteered) in DM`.
+2. End the turn with **NO assistant text**. `shouldNotify` is
+   unconditional for `scheduled.dm` — an empty turn means no DM is
+   sent. Do NOT emit a placeholder string.
+3. Step 2 and Step 3 are skipped.
+
+#### On self-defer (Check 1 only)
+
+Same as abort (no DM, no Step 2 / Step 3 execution) — the replacement
+schedule row is the recovery path.
+
+#### Decline-marker write (helper for Check 4 "no" branch and evaluator)
+
+When Check 4 detects a "no" (or the evaluator branch in Step 2 fires
+on silence) and `taskContext.confirm_decline_marker` is set, write
+the marker before ending the turn. Three cases — file missing
+entirely, file present but section missing, both present — are
+handled in one read-then-branch sequence:
+
+1. GET the file, capturing the status code:
+   ```bash
+   resp=$(curl -sS -w '\n%{http_code}' "http://localhost:8321/api/context/<confirm_decline_marker.path>")
+   status=$(printf '%s\n' "$resp" | tail -n1)
+   body=$(printf '%s\n' "$resp" | sed '$d')
+   ```
+
+   `<confirm_decline_marker.path>` is the value from `taskContext`
+   (e.g. `agent/journal.md`). The endpoint accepts the path with or
+   without the `.md` suffix.
+
+2. Branch on status + section presence:
+   - **status=404 (file missing).** Some marker paths
+     (`agent/journal`) support `PUT` for first-write creation via the
+     daemon's CREATE_ONLY_PUT allowlist. PUT a minimal file
+     containing an H1, the section header, and the new marker line:
+     ```bash
+     curl -s -X PUT "http://localhost:8321/api/context/<confirm_decline_marker.path>" \
+       -H 'Content-Type: application/json' \
+       -d "$(jq -n --arg m '- <YYYY-MM-DD> [<confirm_dedup_key>] user declined (DM fire-time scan)' \
+                  --arg s '<confirm_decline_marker.section as Title Case heading>' \
+             '{content: "# Agent Journal\n\n## \($s)\n\($m)\n"}')"
+     ```
+     If the PUT returns 403 (`forbidden`), the path is not on the
+     create-only allowlist — fall through to an `append_to_file`
+     PATCH (which will fail with 404, surfacing the design gap so
+     the operator can fix it).
+   - **status=200 AND `body` contains `## <section title>`.**
+     Append a bullet to the existing section:
+     ```bash
+     curl -s -X PATCH "http://localhost:8321/api/context/<confirm_decline_marker.path>" \
+       -H 'Content-Type: application/json' \
+       -d '{"section":"<section snake_case>","mode":"append","content":"- <YYYY-MM-DD> [<confirm_dedup_key>] user declined (DM fire-time scan)"}'
+     ```
+   - **status=200 AND section heading missing.** Use
+     `mode: "append_to_file"` and include the header in the content:
+     ```bash
+     curl -s -X PATCH "http://localhost:8321/api/context/<confirm_decline_marker.path>" \
+       -H 'Content-Type: application/json' \
+       -d '{"mode":"append_to_file","content":"\n## <Section Title>\n- <YYYY-MM-DD> [<confirm_dedup_key>] user declined (DM fire-time scan)\n"}'
+     ```
+
+The marker is one short line; do not paraphrase the user's words.
+Lifetime: append-only, no rotation — the gate that opted in can
+remove the line later if the user explicitly revisits ("OK now let's
+start that LA project after all"), but the confirm sub-flow itself
+never deletes markers.
+
+**Duplicate-line tolerance.** Both this helper and the gate's
+reply-branch Decline path (e.g. `context` skill §"Reply branches")
+can in principle write the same `[<confirm_dedup_key>]` line if a
+narrow race slips past `runWithSessionGates`. Do NOT add a defensive
+"check before write" guard. The pre-check readers (e.g. Step 1
+Check 2 here; the gate's Step 1 decline-marker pre-check) all match
+on the `[<confirm_dedup_key>]` substring, so duplicate lines do not
+break the dedup contract — they are cosmetic only.
+
+### Step 2 — Compose the confirmation (or close the chain silently)
+
+#### Evaluator branch — chain-close on silence
+
+If `taskContext.confirm_attempt > taskContext.confirm_max_attempts`,
+this row is a **decline-on-silence evaluator** (see Step 3). Step 1's
+four checks already established that the user has not replied. Do
+NOT compose a DM. Instead:
+
+1. Write the decline marker described in §"Decline-marker write"
+   above, with marker text:
+   ```
+   - <YYYY-MM-DD> [<confirm_dedup_key>] silence-after-<confirm_max_attempts>-asks
+   ```
+2. Append one line to today.md `## Agent Log`:
+   ```
+   - HH:MM [dm_session] confirm:<topic> chain closed: silent decline
+   ```
+3. End the turn with **NO assistant text**. The chain is now closed;
+   Step 3 below is skipped for the evaluator branch.
+
+#### Compose branch — emit a single short DM
+
+`taskContext.confirm_attempt <= taskContext.confirm_max_attempts`.
+Compose a single short DM in persona voice that asks the question
+from `taskContext.confirm_hint`. The hint is agent-internal English
+(Policy A); the rendered DM follows `<output_language_policy>` and
+the persona / Character voice rules at the top of this file.
+
+Hard rules:
+
+- **One question, one sentence** unless the topic genuinely needs
+  more context. End with the question; do NOT layer a second topic.
+- **Do NOT mention** the schedule, the queue, the gate that fired
+  it, the word "confirm" / "confirmation", `taskContext`, IDs, or
+  any internal mechanism. The user sees a natural DM, not a queue
+  entry.
+- **Conversation-state framing applies.** If state=active or
+  very-recent (Check 1 returned "proceed"), use Variant B — no
+  greeting, acknowledge the interruption briefly, hand the floor
+  back at the end. If state=asleep, use Variant A — persona
+  greeting opener is fine.
+- **Softened re-check on retries.** If `confirm_attempt > 1`, this
+  is a re-check after silence, NOT a re-issue of the same question.
+  Phrase it as a check-in with a soft exit ("...or skip?", "...or
+  did this change?", "...or want me to leave it open?"). The user
+  must feel acknowledged, not pestered.
+
+Examples (English source; render per `<output_language_policy>` and
+persona — these phrasings are STRUCTURAL):
+
+- Initial (`confirm_attempt=1`):
+  - hint: `create project "la-pm-masters"? (origin: DM said they moved to LA and started a PM master's)` →
+    *"Should I track 'LA PM master's' as a project so I can keep the syllabus / deadlines in one place?"*
+  - hint: `ambiguous: trip to Tokyo "next month" — date 5/15?` →
+    *"Was the Tokyo trip 5/15, or are you still picking the date?"*
+- Softened re-check (`confirm_attempt=2`):
+  - same first hint →
+    *"Still on for tracking the LA PM master's as its own project, or skip for now?"*
+  - same second hint →
+    *"Did the Tokyo date settle, or want me to leave it open?"*
+
+### Step 3 — Schedule the chain successor
+
+This step runs only on the **compose branch** of Step 2 (a DM was
+emitted). The evaluator branch already closed the chain in Step 2;
+Step 3 is skipped in that case.
+
+After Step 2 emits the DM text (which the daemon will dispatch as
+this turn's final assistant text), schedule a successor row based on
+the current attempt counter. Inherit all unchanged `taskContext`
+fields from this row.
+
+**Quiet-hours discipline.** The literal `<current_time> + 24h` may
+land inside the user's quiet hours (default 22:00-08:00, configurable
+via `runtime_settings.quietHoursStart/End`). The schedule skill's
+"Time discipline" section forbids non-`critical` rows in quiet hours,
+and the scheduler rejects them. Pick a target time that:
+
+1. Is at least 24h after `<current_time>` (the §B6 minimum-interval
+   contract), and
+2. Falls outside the user's quiet hours.
+
+The simplest pattern: take `<current_time> + 24h` and, if that
+clock-time is inside quiet hours, roll forward to quiet-hours-end
+on that day. For a 23:30 initial fire with quiet hours starting at
+22:00, this yields a 08:00 successor 24h+8.5h later — slightly more
+than 24h, still within the spirit of "next agent-day". Do not roll
+*backward* to fit before quiet hours; that violates the 24h
+minimum.
+
+#### Case A — `confirm_attempt < confirm_max_attempts`
+
+Schedule a **softened retry** at `<current_time> + 24h`:
+
+```bash
+curl -s -X POST http://localhost:8321/api/schedule \
+  -H 'Content-Type: application/json' \
+  -d @- <<JSON
+{
+  "time": "<current_time + 24h, ISO 8601 with offset>",
+  "taskType": "dm_session",
+  "description": "confirm:<topic> — <hint, softened paraphrase>",
+  "model": "sonnet",
+  "taskContext": {
+    "scheduledBy": "scheduled_dm.confirm_followup.retry",
+    "sub_flow": "confirm",
+    "confirm_id": "<new short id>",
+    "confirm_dedup_key": "<inherited unchanged>",
+    "confirm_hint": "<softened English brief — e.g. 'still on for tracking LA PM master's, or skip?'>",
+    "confirm_recent_window_hours": <inherited>,
+    "confirm_attempt": <prior + 1>,
+    "confirm_max_attempts": <inherited>,
+    "confirm_defer_count": 0,
+    "confirm_max_defers": <inherited>,
+    "confirm_decline_marker": <inherited>,
+    "confirm_slot": <inherited>,
+    "importance": "low"
+  }
+}
+JSON
+```
+
+The successor's `confirm_hint` SHOULD be softened by the composing
+session — the next fire's Step 2 reads the hint as written, so a
+gentler hint produces a gentler DM. Reset `confirm_defer_count` to 0
+on a retry (defers are per-fire, not per-chain).
+
+#### Case B — `confirm_attempt == confirm_max_attempts`
+
+Schedule a single **decline-on-silence evaluator** at
+`<current_time> + 24h` with `confirm_attempt = confirm_max_attempts + 1`
+(sentinel). At the evaluator's fire time, Step 1 runs as usual; if
+all four checks pass (user still has not replied), Step 2's
+evaluator branch silently writes the decline marker and ends —
+no DM, no further successor.
+
+```bash
+curl -s -X POST http://localhost:8321/api/schedule \
+  -H 'Content-Type: application/json' \
+  -d @- <<JSON
+{
+  "time": "<current_time + 24h, ISO 8601 with offset>",
+  "taskType": "dm_session",
+  "description": "confirm:<topic> — silence-evaluator",
+  "model": "sonnet",
+  "taskContext": {
+    "scheduledBy": "scheduled_dm.confirm_followup.evaluator",
+    "sub_flow": "confirm",
+    "confirm_id": "<new short id>",
+    "confirm_dedup_key": "<inherited unchanged>",
+    "confirm_hint": "<inherited>",
+    "confirm_recent_window_hours": <inherited>,
+    "confirm_attempt": <confirm_max_attempts + 1>,
+    "confirm_max_attempts": <inherited>,
+    "confirm_defer_count": 0,
+    "confirm_max_defers": <inherited>,
+    "confirm_decline_marker": <inherited>,
+    "confirm_slot": <inherited>,
+    "importance": "low"
+  }
+}
+JSON
+```
+
+#### Bookkeeping (silent — never visible to the user)
+
+After scheduling the successor (Case A or B), append one line to
+today.md `## Agent Log`:
+
+```
+- HH:MM [dm_session] confirm:<topic> sent (attempt=N/max=M); successor scheduled <case>
+```
+
+(Use `case=retry` for Case A and `case=evaluator` for Case B.)
+
+### Notes — invariants this sub-flow upholds
+
+- **Goal 1 (thread preservation).** Check 1's self-defer keeps a
+  hot thread intact even though the confirm has been waiting.
+  When defers exhaust, Goal 1 still wins: Variant-B framing softens
+  the entry rather than firing a cold opener.
+- **Goal 2 (confirmations happen naturally).** Step 2's persona
+  voice + state-aware framing means the user experiences the DM as
+  a check-in, not a queue ping.
+- **Goal 3 (never ask twice).** Checks 2-4 dedup against all
+  observable answer surfaces (declined, slot-filled, replied in
+  DM). Step 3's chained-fire model caps the chain at
+  `confirm_max_attempts + 1` fires (default 3), of which only
+  `confirm_max_attempts` (default 2) send DMs. The minimum
+  inter-fire interval is 24h — no same-day re-asks.
+- **Schedule row IS the queue.** No new table, no
+  `pending-confirmations.md`. All chain state lives in
+  `taskContext`; cross-path cancellation is the gate's
+  responsibility (see the gate's reply-branch contract, e.g. the
+  `context` skill's Project DM-intent detection §"Reply branches").

package/agent-assets/task-flows/wiki.ask.md

@@ -0,0 +1,11 @@
+{context}
+
+## Task: Answer from the wiki
+
+Read `<wiki_command>` for the question. Follow the `wiki-ask` skill:
+
+1. Search `20_wiki/` for relevant notes.
+2. Verify against source links or `10_raw/` only when needed.
+3. Write one `30_outputs/<YYYY-MM-DD>-<slug>.md` answer through the Wiki API with `x-process-key: wiki.ask`.
+4. Keep the final assistant response concise; the durable answer belongs in `30_outputs/`.
+

package/agent-assets/task-flows/wiki.compile.md

@@ -0,0 +1,28 @@
+{context}
+
+## Task: Compile wiki notes
+
+A `!compile` (or approved `!compile full`) landed here. Read `<wiki_command>` for `data.mode` — `"incremental"` (compile only `10_raw/` notes touched since the last compile) or `"full"` (compile every raw). Read `<wiki_workspace>` for the destination workspace.
+
+You succeed if and only if every wiki note you claim to have created came back from the daemon's Wiki API as `{"ok":true,"path":"20_wiki/<slug>.md"}`. The vault is on disk and there is no other path to write it.
+
+### Critical: the only write surface is the Wiki API via `curl`
+
+- `Write` and `Edit` tools are **stripped from this session's allow-list**. The SDK denies them silently under `dontAsk` ("Permission to use Write has been denied …"). They cannot be made to work via path rewriting; do not try.
+- `Bash(find ...)`, `Bash(ls ...)`, `Bash(cat ...)`, `Bash(grep ...)`, `Bash(wc ...)` and every other shell utility are also silently denied. Only `Bash(curl *)` and `Bash(jq *)` are on the allow-list. Enumerate raw notes via `GET /api/wiki/<workspace>/index`, NOT by walking `{{vault_path}}` from disk.
+- The `Bash(curl *)` allow-rule is prefix-matched against the full command. Wrappers — `echo '{...}' | curl …`, `cat <<JSON | curl …`, `bash -c "curl …"`, `( curl … )`, `var=… curl …`, chained `curl … ; curl …` — are silently denied (no output, no `PA_API_ERROR`). The reverse, `curl … -d @- <<'JSON' … JSON` on the same line, IS allowed because the command still starts with `curl`; the shim reads stdin via `-d @-`.
+
+### Procedure
+
+1. **Baseline (incremental only).** Read `20_wiki/_index.md` (or the most recent `wiki.compile` entry in `log.md`) to recover the prior `compiled_at` ISO timestamp. If the workspace has never been compiled, compile every raw.
+2. **Enumerate raw notes** via `GET /api/wiki/<workspace>/index`, then filter with `jq` for `path` under `10_raw/` and (incremental) `mtime > <baseline>`.
+3. **Read existing wiki + taxonomy** so synthesis can de-duplicate and use canonical slugs.
+4. **For each topic**, synthesize a root-level `20_wiki/<slug>.md` note (one note per coherent topic — merge multiple raws when they cover the same thing). `POST` for a new slug, `PATCH mode: "replace"` for an existing one (read-before-write).
+5. **Append `20_wiki/_index.md`** (`PATCH mode: "append"`) with one bullet per added or updated note.
+6. **Append `log.md`** (`PATCH mode: "append"`) with one summary line: `[<ISO>] wiki.compile (<mode>): compiled <N> notes from <M> raws — added <A>, updated <B>, unchanged <C>`.
+
+The `wiki-compile` skill carries the canonical curl shapes (including the multi-KB heredoc body shape), the per-error recovery table, and the slug rules. The `wiki-vault-rules` skill carries the body-quoting cheat-sheet and the full layer/endpoint reference.
+
+Do NOT modify `00_inbox/` or existing `10_raw/` notes. Do NOT call `/api/send-message`, `/api/whatsapp/send`, `/api/notify-user`, or any other "send" endpoint — those routes do not exist. Your final assistant text IS the delivery channel; the daemon forwards it to the bang's reply target automatically.
+
+End with the single-line completion DM from the skill (Success / Partial / Failure).

package/agent-assets/task-flows/wiki.connect.md

@@ -0,0 +1,12 @@
+{context}
+
+## Task: Bridge two domains in the wiki
+
+Read `<wiki_command>` for `topic_a` and `topic_b`. Follow the `wiki-connect` skill:
+
+1. Search each topic independently and read enough matches to characterise each domain. Disambiguate string matches against `90_meta/taxonomy.md`.
+2. Surface bridges in four buckets — shared terminology, common references, structural analogies, and bridging concept candidates. Cite every bridge with at least one wiki path from each side. A bridge that can only cite one side belongs in the candidates list, not in the others.
+3. Write one connection report to `30_outputs/<YYYY-MM-DD>-connect-<slug-a>--<slug-b>.md` through the Wiki API with `x-process-key: wiki.connect`. Use the canonical slugs from `90_meta/taxonomy.md` when available.
+4. Append a one-line `log.md` entry referencing the output filename and both topics.
+
+If no real bridges exist, write the report anyway with empty sections marked `_(none)_` and a `## Summary` that names that directly — a "no connection" finding is still useful. Do not create new wiki notes from this flow; the bridging concept candidates section is a proposal for `wiki.compile` to pick up later. End with a short internal summary only.

package/agent-assets/task-flows/wiki.ingest_url.md

@@ -0,0 +1,35 @@
+{context}
+
+## Task: Ingest URL into the wiki
+
+A single `!ingest` call landed here. Read `<wiki_command>` for the target `url` and `<wiki_workspace>` for the destination workspace.
+
+You succeed if and only if you POST a new file to `/api/wiki/<workspace>/files/10_raw/<slug>.md` and the daemon responds with `{"ok":true,"path":"10_raw/<slug>.md"}`. There is no other definition of success. The vault file is created by that POST and nothing else — `Write` tool / shell redirection / other endpoints do not put a file in the vault.
+
+### Critical: the Bash command MUST start with literal `curl`
+
+The `Bash(curl *)` allow-list is prefix-matched. Wrappers (`echo '{...}' | curl …`, `cat <<JSON | curl … -d @-`, `bash -c "curl …"`, parentheses, chained `curl … ; curl …`) are silently denied under `dontAsk` — you get no error, no `PA_API_ERROR`, just an empty response. If a Bash call returns nothing, rewrite it to start with `curl`.
+
+Article bodies are typically multi-KB — use a heredoc redirected directly into curl (the command still starts with `curl`):
+
+```
+curl http://localhost:8321/api/wiki/<workspace>/files/10_raw/<slug>.md \
+  -X POST \
+  -H 'content-type: application/json' \
+  -H 'x-process-key: wiki.ingest_url' \
+  -d @- <<'JSON'
+{"content":"---\n…frontmatter…\n---\n\n# Title\n\n## Source extracts\n\n…"}
+JSON
+```
+
+The shim reads stdin when `-d @-` is passed, so the heredoc body lands as the JSON payload. Inside `<<'JSON'` (single-quoted marker) the body is verbatim — no shell escaping, only JSON escapes (`\"`, `\\`, `\n`). For short bodies (a few hundred bytes) inline `-d '<json>'` is fine.
+
+### Procedure
+
+1. Fetch the URL with the per-backend primitive (WebFetch on Claude, curl on Codex, web_fetch on Gemini).
+2. POST one new note at `10_raw/<slug>.md` via the daemon Wiki API with `-H 'x-process-key: wiki.ingest_url'`. Path is EXACTLY `10_raw/<slug>.md` — no nested folders like `10_raw/articles/...`.
+3. **Inspect the curl response.** Only `{"ok":true,"path":"10_raw/<slug>.md"}` counts as success. Anything else (4xx, 5xx, missing fields, hallucinated endpoint like `/api/send-message`, no response) means the file was NOT created — PATCH `log.md` with the failure reason and emit the failure DM.
+
+The `wiki-ingest` skill carries the full curl shapes, slug rules, error-code recovery table, and completion-DM format.
+
+End the turn with the single-line completion DM defined in the skill. The path you cite in the success DM must be byte-identical to the `path` field the daemon returned. Do not fabricate a path. Do not claim success without seeing `{"ok":true,...}`. The daemon forwards your final assistant text to the user — you must NOT also call `/api/send-message`, `/api/whatsapp/send`, `/api/notify-user`, `/api/dm`, or any other "send" endpoint; those do not exist.

package/agent-assets/task-flows/wiki.lint.md

@@ -0,0 +1,13 @@
+{context}
+
+## Task: Audit wiki health
+
+Read `<wiki_command>` for the target workspace. Follow the `wiki-lint` skill:
+
+1. Inventory the workspace via `GET /api/wiki/{{workspace_name}}/index` and read `90_meta/schemas/*` for the current schema.
+2. Run every check the skill enumerates (orphans, broken wikilinks, missing frontmatter, stale content, term inconsistencies, taxonomy candidates, index drift). Empty findings are still reported.
+3. Write exactly one health report to `90_meta/health/<YYYY-MM-DD>.md` through the Wiki API with `x-process-key: wiki.lint`. The report must include the `## Action items` and `## Summary` sections in the exact order documented by the skill.
+4. If — and only if — there are taxonomy candidates, append a `# Candidates` section to `90_meta/taxonomy.md` with `mode: "append"`. The owner reviews this before any promotion happens; do not edit the existing `## Topics` section.
+5. Append a concise summary line to `log.md`.
+
+Do not modify content layers (`10_raw/`, `20_wiki/`, `30_outputs/`). End with a short internal summary only.

package/agent-assets/task-flows/wiki.trace.md

@@ -0,0 +1,13 @@
+{context}
+
+## Task: Trace an idea's evolution across the wiki
+
+Read `<wiki_command>` for the `topic`. Follow the `wiki-trace` skill:
+
+1. Search across all layers (`10_raw/`, `20_wiki/`, `30_outputs/`) and read the matches that look load-bearing. Use `90_meta/taxonomy.md` to canonicalise the topic slug.
+2. Order findings chronologically using the most authoritative date available (asserted dates → output filename dates → file `mtime`). Mark any date that came from `mtime` as "discovered on" rather than "happened on".
+3. Group into two to five phases of stable framing. For each phase, name the dominant question, the new evidence, and what changed compared to the previous phase. Cite every claim with a wiki path.
+4. Write one timeline report to `30_outputs/<YYYY-MM-DD>-trace-<slug>.md` through the Wiki API with `x-process-key: wiki.trace`. Follow the section order documented by the skill.
+5. Append a one-line `log.md` entry referencing the output filename and the topic.
+
+If the wiki has fewer than two distinct sources on the topic, keep the report short and say so directly in `## Summary` — do not pad it with speculation. End with a short internal summary only.

package/agent-assets/wiki-seeds/schemas/output.md

@@ -0,0 +1,12 @@
+# Output Schema
+
+Outputs live under `30_outputs/` and answer a specific user question from the wiki.
+
+## Required Shape
+
+- Question
+- Short answer
+- Evidence
+- Source links
+- Follow-up gaps
+

package/agent-assets/wiki-seeds/schemas/raw.md

@@ -0,0 +1,13 @@
+# Raw Note Schema
+
+Raw notes live under `10_raw/` and preserve source facts before synthesis.
+
+## Required Shape
+
+- Source URL
+- Retrieved timestamp
+- Source title when available
+- Extracted facts
+- Quotes or snippets only when they are short and necessary
+- Open questions
+

package/agent-assets/wiki-seeds/schemas/wiki.md

@@ -0,0 +1,12 @@
+# Wiki Note Schema
+
+Wiki notes live under `20_wiki/` and contain synthesized, cited knowledge.
+
+## Required Shape
+
+- Summary
+- Key facts
+- Source links
+- Related notes
+- Unknowns or conflicts
+