@aitne-sh/aitne 0.1.4 → 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/setup.initial.md

@@ -7,8 +7,9 @@ Vault step already captured `settings.primary_language` (BCP-47 tag, e.g.
 `en` or `es`) and `settings.vault_mode` (`plain` or `obsidian`) — the
 latter controls how the **primary management vault** is laid out, not the
 separate external Obsidian integration. Do NOT re-ask those questions.
-Output language for user-editable prose (profile, today, daily journal):
-follow `<output_language_policy>`.
+Output language for everything written to disk in this flow
+(`user/profile.md`, `user/*.md`, `rules/management.md` body): follow
+`<output_language_policy>`.
 
 SETUP-FLOW-REDESIGN-PLAN §5.8 — the legacy "tool selections" form was
 removed. Steps 4–6 of the wizard (Mail, Calendar, Note) already
@@ -68,6 +69,15 @@ about all four rows rather than fabricating defaults. Do not retry
 with a curl.
 
 ### Instructions
+
+Steps 3–8 all happen in the same agent turn. They are ordered to match
+the actual emission sequence: the two staged code blocks (rules then
+character) land in the stream first; the silent curl writes follow. The
+dashboard reveals the preview as soon as the rules block lands but
+keeps "Save & Finish" disabled until the whole turn ends, so emitting
+blocks before curls minimizes how long the user waits on a disabled
+button.
+
 1. Run Step 0 silently. Greet the user in one line, introducing
    yourself by the name in `<agent_identity>` display_name. Then
    present the derived Source-of-Truth table and ask any remaining
@@ -78,28 +88,30 @@ with a curl.
    - Project-management method preferences (anything you want the agent
      to follow when handling your projects?)
    Either answer may be "no preference" / "skip" — accept that cleanly.
-3. Once the user has answered, generate rules/management.md inside a
-   ```management-rules code block. This triggers the dashboard preview.
-4. If the user requests changes, revise. Complete within **at most 2
-   revision rounds**.
+3. Generate rules/management.md inside a ```management-rules code
+   block. This is the FIRST thing emitted in the turn — the dashboard
+   reveals the preview as soon as it lands.
+4. If the user requests changes, revise (return to step 3). Complete
+   within **at most 2 revision rounds**.
 5. **Do NOT put communication style inside rules/management.md, and do NOT
    put it inside `user/profile.md` either.** Tone / style / voice / emoji
    / language preferences live in the `character` runtime-config field
-   only — emitted as a ```character``` code block (see step 6.5). See
+   only — emitted as a ```character``` code block (see step 6). See
    `docs/design/15-character.md` for the split rule.
-6. In the same turn as the management-rules block, silently call
-   PUT /api/context/user/profile using the template in "user/profile.md
-   Format" below. Working hours and quiet hours are pre-populated with
-   defaults (Weekdays 09:00–18:00, Quiet hours 22:00–08:00) — do not
-   ask about them. Fill Platforms from the **derived Source-of-Truth
-   table** (Step 0) — the row values you confirmed with the user.
-   Leave Identity blank — setup does not collect name or timezone.
-6.5. If the user stated a communication-style preference in step 2,
-   emit a ```character``` code block in the same turn (see "Character
-   code block format" below). If the user skipped, omit the block.
-7. If the conversation surfaced detail-heavy facts that belong in the
-   detailed profile layer, also PATCH the matching user/*.md file in the
-   same turn. Typical Q&A → file mappings:
+6. If the user stated a communication-style preference in step 2, emit
+   a ```character``` code block immediately after the rules block (see
+   "Character code block format" below). If the user skipped, omit the
+   block.
+7. After the staged blocks, silently call PUT /api/context/user/profile
+   using the template in "user/profile.md Format" below. Working hours
+   and quiet hours are pre-populated with defaults (Weekdays 09:00–18:00,
+   Quiet hours 22:00–08:00) — do not ask about them. Fill Platforms
+   from the **derived Source-of-Truth table** (Step 0) — the row values
+   you confirmed with the user. Leave Identity blank — setup does not
+   collect name or timezone.
+8. If the conversation surfaced detail-heavy facts that belong in the
+   detailed profile layer, also PATCH the matching user/*.md file (still
+   the same turn, after step 7). Typical Q&A → file mappings:
      - Named colleagues, family, friends → user/people.md
      - Current company, role specifics, ongoing projects → user/work.md
      - Specific frameworks, years of experience → user/expertise.md
@@ -109,7 +121,7 @@ with a curl.
    Only seed what the user actually stated — do not invent or infer. If
    nothing came up for a given file, do not touch it. See the user-profile
    skill for the read-before-write PATCH recipe.
-8. Keep the updates in steps 6–7 silent — the dashboard handles saving
+9. Keep steps 7–8 silent — the dashboard handles saving
    rules/management.md separately when the user approves the preview. Do
    not create or modify any other context files; the daemon seeds the
    rest of the primary-vault scaffold automatically.
@@ -218,6 +230,18 @@ write tone/style preferences into user/profile.md.
 
 ### rules/management.md Format
 
+Output language: follow `<output_language_policy>`. rules/management.md
+is Policy B — the section headers (`## Agent Identity`, `## Source of
+Truth`, `## Autonomy Levels`, `## Notification Rules`, `## Schedule`,
+`## Project Management`) are skeleton and stay English; the descriptive
+bullets under `## Autonomy Levels`, `## Notification Rules`, `## Schedule`,
+and `## Project Management` are written in `<settings primary_language>`.
+File-specific carve-outs that also stay English: the `## Agent Identity`
+field labels (`- AI name:`, `- WhatsApp label:`) — the daemon parses and
+rewrites this section; the Source of Truth table column headers and
+Domain-column row labels; and product/brand cells (`Google Calendar`,
+`Obsidian`, `Notion`, `today.md`, `projects/*.md`).
+
 Fill the Source of Truth table from the **derived rows you confirmed
 with the user in Step 0** (Schedule / Tasks / Notes / Projects).
 Generate using this format:
@@ -274,5 +298,8 @@ heading onto the end of the previous list item (e.g. `- Label:
 <value>## Next Section` on one line). Copy user-provided values as-is,
 then newline, blank line, then the next heading.
 
-**Important**: Outputting a ```management-rules code block triggers the dashboard to display a preview.
-The dashboard handles saving when the user approves, so you do NOT need to save via curl.
+**Important**: Do NOT curl-write rules/management.md to disk yourself.
+The dashboard persists it via `POST /setup/save-rules` when the user
+clicks Save & Finish. (The silent curl PUT to /api/context/user/profile
+in step 7 and the user/*.md PATCHes in step 8 ARE required — only the
+rules file is saved by the dashboard.)

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