@aitne-sh/aitne 0.1.7 → 0.1.8

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

@@ -279,11 +279,11 @@ voice carries the whole message.
 ### Delivery channel — final text only, NOT `/api/notify`
 
 The briefing is delivered as the final assistant turn of this
-session. Do NOT call `POST /api/notify` for it — that path applies
-the `notify` skill's evening wrap-up contract (silent-by-default,
-priority `high`) which has the wrong semantics for a daily DM.
-Compose the briefing as your final assistant turn; the daemon DMs
-it automatically.
+session. Do NOT call `POST /api/notify` for it — that path is for
+ad-hoc alerts and applies the `notify` skill's universal
+message-discipline rules, which have the wrong semantics for a daily
+DM. Compose the briefing as your final assistant turn; the daemon
+DMs it automatically.
 
 ### Bookkeeping (silent — never visible to the user)
 
@@ -460,7 +460,7 @@ Inspect `<recent_dm_messages window="60min">`:
     "time": "<current_time + 15min, ISO 8601 with offset>",
     "taskType": "dm_session",
     "description": "confirm:<topic> — <hint>",
-    "model": "sonnet",
+    "tier": "medium",
     "taskContext": {
       "scheduledBy": "scheduled_dm.confirm_followup.self_defer",
       "sub_flow": "confirm",
@@ -775,7 +775,7 @@ curl -s -X POST http://localhost:8321/api/schedule \
   "time": "<current_time + 24h, ISO 8601 with offset>",
   "taskType": "dm_session",
   "description": "confirm:<topic> — <hint, softened paraphrase>",
-  "model": "sonnet",
+  "tier": "medium",
   "taskContext": {
     "scheduledBy": "scheduled_dm.confirm_followup.retry",
     "sub_flow": "confirm",
@@ -817,7 +817,7 @@ curl -s -X POST http://localhost:8321/api/schedule \
   "time": "<current_time + 24h, ISO 8601 with offset>",
   "taskType": "dm_session",
   "description": "confirm:<topic> — silence-evaluator",
-  "model": "sonnet",
+  "tier": "medium",
   "taskContext": {
     "scheduledBy": "scheduled_dm.confirm_followup.evaluator",
     "sub_flow": "confirm",

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

@@ -91,14 +91,14 @@ confirmation.
       proceed to Step 3 below so the task still executes.
    2. `GET /api/context/roadmap` and locate the matching
       `### Scheduled: ... (task #<id>)  <!-- id: rm-... -->` entry.
-      Flip only its Status line to `▶ running` via `PATCH`
+      Flip only its Status line to `running` via `PATCH`
       `section=agent_action_plan` `mode=replace` (include
       `X-Lock-Id: <lockId>`). Preserve the heading ID marker and any
-      `✓ completed ...` Preparation Timeline rows byte-for-byte.
+      `completed ...` Preparation Timeline rows byte-for-byte.
       Follow the **roadmap** skill for the exact entry shape.
    3. Execute the task body (the remaining steps in this prompt).
    4. After Step 4 closes the loop, PATCH the entry Status to
-      `✓ completed` / `✗ failed` (`X-Lock-Id: <lockId>`), then
+      `completed` / `failed` (`X-Lock-Id: <lockId>`), then
       `DELETE /api/context/lock/roadmap` with `{"lockId": "<lockId>"}`
       — always release even on failure paths.
 
@@ -129,8 +129,8 @@ confirmation.
 7. If Step 1 found a matching Agent Plan row, flip it to `- [x]` via the
    lifecycle recipe in the context skill (GET → edit body → PATCH
    replace section=agent_plan). Annotate per the skill's outcome table:
-   success = no annotation, skip = `⚠ skipped: <reason>`, failure =
-   `⚠ failed: <reason>`. Never leave a past-HH:MM row as `[ ]`.
+   success = no annotation, skip = `(skipped: <reason>)`, failure =
+   `(failed: <reason>)`. Never leave a past-HH:MM row as `[ ]`.
 8. If the PATCH returns 409 (Morning Routine lock), follow the skill's
    "retry 3 times, else log deferred" guidance. Do not drop silently.
 

package/agent-assets/task-flows/setup.initial.md

@@ -2,249 +2,148 @@
 
 ## Task: Initial Setup — Create rules/management.md
 
-The user has started the initial setup from the dashboard. The dashboard
-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 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
-configured the user's integrations, so you derive the Source-of-Truth
-rows yourself and confirm them rather than asking from scratch.
-
-Your role is to derive an initial Source-of-Truth table from the
-configured integrations, confirm it with the user, gather the two
-remaining management preferences, and generate rules/management.md.
-This is a multi-turn conversation — subsequent user messages will
-arrive via session resume.
-
-Output language for this conversation: follow `<output_language_policy>` —
-match the user's input language from the very first message; fall back
-to `<settings primary_language>` when input is ambiguous.
-
-### Step 0 (silent, agent-owned) — Derive Source-of-Truth rows
-
-Read integration state and the external-vault path **from the prompt
-context tags** the daemon injects on every turn. Do NOT curl `GET
-/api/integrations` or `GET /api/config` for this step — both are
-Approve-tier (Bearer-only) and the agent's session has only an
-`X-Read-Token`, so those two reads will 401. (Other curls in this
-file — e.g. `PUT /api/context/user/profile` — are Autonomous-tier and
-work normally.)
-
-Tags available in the prompt:
-
-- `<integration_modes …/>` — one attribute per integration. Always
-  present, always covers every key. Example:
-  `<integration_modes gmail="disabled" google_calendar="direct" notion="delegated" notion_delegated_to="claude" outlook_calendar="disabled" outlook_mail="disabled" git="disabled" github="disabled" />`.
-  Values are `direct | delegated | disabled`.
-- `<obsidian_vault_path>…</obsidian_vault_path>` — emitted **iff** the
-  user has configured an external Obsidian vault. **Absence means the
-  user has no external Obsidian vault** (treat as "no").
+The dashboard wizard already captured `settings.primary_language` and
+`settings.vault_mode`. Steps 4–6 (Mail / Calendar / Note) configured
+the user's integrations. Your role:
+derive an initial Source-of-Truth table from those integrations,
+confirm it with the user, gather two remaining preferences, and
+generate rules/management.md.
+
+Output language: follow `<output_language_policy>`. The conversation
+matches the user's input language.
+
+This is a **strictly two-turn** dashboard conversation. The same prompt
+renders every turn — decide which turn you're on by inspecting prior
+assistant messages.
+
+| Turn | Trigger | What you emit |
+|------|---------|---------------|
+| Turn 1 | No prior assistant message | One natural-language message: greeting + derived Source-of-Truth table + remaining questions. **No code blocks. No curl.** |
+| Turn 2 | The most recent prior assistant message was Turn 1 and the user has now replied | `management-rules` block **FIRST**, then optional `character` block, then silent PUT /api/context/user/profile + any user/*.md PATCHes |
+| Turn 3+ | User requested revisions after Turn 2 | Revised `management-rules` block only (cap: 2 revision rounds). No curl writes — they already ran in Turn 2. |
+
+### Step 0 (silent) — Derive Source-of-Truth from context tags
+
+Read these tags from the prompt context. Do **NOT** curl
+`/api/integrations` or `/api/config` — both are Approve-tier and the
+agent's session has only an `X-Read-Token`, so those reads return 401.
+
+- `<integration_modes …/>` — one attribute per integration, always
+  emitted. Values are `direct | delegated | native | disabled`. Any
+  value other than `disabled` means the integration is wired up.
+- `<obsidian_vault_path>…</obsidian_vault_path>` — present **iff** the
+  user has configured an external Obsidian vault. Absence means "no".
 - `<settings primary_language="…" vault_mode="…" />` — primary
-  language and primary-vault layout (`plain` | `obsidian`).
+  language and primary-vault layout.
 
-Apply these deterministic rules to draft the four rows:
+Derive the four rows:
 
 | Source-of-Truth row | Derive from |
 |---|---|
-| Schedule | `google_calendar != "disabled"` → `Google Calendar`; else `outlook_calendar != "disabled"` → `Outlook Calendar`; else ask the user |
-| Notes | `<obsidian_vault_path>` tag present → `Obsidian`; else `notion != "disabled"` → `Notion`; else ask the user |
-| Tasks | `notion != "disabled"` → `Notion`; else `Obsidian` if `<obsidian_vault_path>` tag present; else ask the user |
+| Schedule | `google_calendar != "disabled"` → `Google Calendar`; else `outlook_calendar != "disabled"` → `Outlook Calendar`; else ask |
+| Notes | `<obsidian_vault_path>` present → `Obsidian`; else `notion != "disabled"` → `Notion`; else ask |
+| Tasks | `notion != "disabled"` → `Notion`; else `<obsidian_vault_path>` present → `Obsidian`; else ask |
 | Projects | same precedence as Tasks |
 
-Surface the derived table back to the user in the first message
-("Here's what I picked up from your setup — does this look right?")
-and ask **only** about rows you could not infer. Typical outcome:
-zero or one follow-up question.
-
-Defensive fallback: if `<integration_modes …/>` is somehow missing
-from the prompt (shouldn't happen — `context-builder.ts` emits it
-unconditionally before any routine-specific branch), ask the user
-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
-   row + the two preference questions in the same turn. Do NOT label
-   anything "Q1", "Q2", etc. — speak naturally.
-2. Ask the two preference questions in a single message:
-   - Communication style preference (how should the agent talk to you?)
-   - 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. 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). See
-   `docs/design/15-character.md` for the split rule.
-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
-       (user/profile.md ## Expertise keeps a one-line summary only)
-     - Long-term goals, aspirations → user/goals.md
-     - Hobbies, lifestyle habits, dietary notes → user/personal.md
-   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.
-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.
-
-### Questions to ask (do NOT show these labels to the user)
-
-Ask both in a single natural message:
-
-- **Communication style** — how should the agent talk to you? (e.g.,
-  be concise, speak casually, no emojis, end every reply with a
-  period, etc.) Skip if no preference.
-- **Project-management method** — any preferences for how the agent
-  should handle your projects? (e.g., break work into weekly
-  milestones, always produce a design doc before code, prefer GitHub
-  issues over markdown TODOs, etc.) Skip if no preference.
-
-Notification hours and working hours are NOT asked here — they default
-to quiet hours 22:00–08:00 and working hours Weekdays 09:00–18:00, and
-the user can change them on the Settings page.
-
-### user/profile.md Format
-
-When you PUT /api/context/user/profile, write the full file in this shape so setup is deterministic:
-
-```
----
-type: user
-owner: shared
-updated: 2026-04-21
----
-# User
-> Primary profile injected into every session. Keep this file concise.
-> Detailed profile lives under `user/`.
-> Fetch index: `curl -s http://localhost:8321/api/context/user/_index`
-
-## Identity
-(leave bullets blank — setup does not collect name or timezone)
-
-## Work Pattern
-- Working hours: Weekdays 09:00–18:00
-
-## Platforms
-- Schedule: {from derived Source-of-Truth table}
-- Tasks: {from derived Source-of-Truth table}
-- Notes: {from derived Source-of-Truth table}
-- Projects: {from derived Source-of-Truth table}
-
-## Expertise
-- {one-line summary if the user mentioned their field; otherwise leave empty}
-
-## Notification Preferences
-- Quiet hours: 22:00–08:00
-
-## Learned Context
-
-## Raw Signals
-```
-
-Use today's YYYY-MM-DD for `updated` (the date above is only an example).
-Do not omit `## Notification Preferences` — Morning Routine reads it directly.
-
-### How to submit user/profile.md
-
-Use inline `-d '{"content": "..."}'` with `\n` escapes. Do NOT use
-`-d @-`, heredoc pipelines, or `--data-raw '@-'` — those have
-produced malformed bodies in this flow (server saw literal `@-` and
-returned 500).
-
-```bash
-curl -s -X PUT http://localhost:8321/api/context/user/profile \
-  -H 'Content-Type: application/json' \
-  -d '{"content": "---\ntype: user\nowner: shared\nupdated: 2026-04-23\n---\n<!-- DO NOT write tone / style / voice / formality / verbosity / emoji / language preferences in this file. Those are Character-field content — write them via PATCH http://localhost:8321/api/config/character with {\"character\": \"...\"}. This file is for USER FACTS only: identity, expertise, habits, relationships, goals. -->\n# User\n> Primary profile injected into every session.\n> Detailed profile lives under `user/`.\n> Fetch index: `curl -s http://localhost:8321/api/context/user/_index`\n\n## Identity\n\n## Work Pattern\n- Working hours: Weekdays 09:00–18:00\n\n## Platforms\n- Schedule: Google Calendar\n- Notes: Obsidian\n- Projects: Notion\n\n## Expertise\n\n## Notification Preferences\n- Quiet hours: 22:00–08:00\n\n## Learned Context\n\n## Raw Signals\n"}'
-```
-
-If the response is non-2xx, retry once with a smaller body or switch
-to section-level PATCH. Do not report the error to the user as a
-permission issue — the default allowlist includes `Bash(curl *)`.
-
-### Character code block format
-
-If the user answered the communication-style question with an actual
-preference (not "no preference" / "skip"), emit a ```character``` code
-block in the same turn the management-rules block is emitted:
-
-```character
-Speak casually. Tight bullets. No emojis.
-```
-
-Rules for the block body:
-- The body is raw text — no markdown, no outer quotes, no nested fences.
-- Stay under the 1000-char cap; surface the excess to the user rather
-  than silently truncating.
-- Emit **at most one** character block per turn.
-
-The dashboard extracts this block, stages it into an inline editor
-alongside the Management Rules Preview, and PATCHes `/api/config`
-atomically when the user clicks Save & Finish. **Do NOT call `/api/config/character` (or any `/api/config*`) yourself from the agent during setup.**
-
-If the user did not state a preference, omit the block entirely — the
-dashboard will leave the existing `character` value unchanged.
-
-The character value is written verbatim into every session's
-CLAUDE.md / AGENTS.md / GEMINI.md (between the safety preamble and
-the profile body) uniformly across Claude, Codex, and Gemini. Never
-write tone/style preferences into user/profile.md.
+Defensive fallback: if `<integration_modes>` is missing from the prompt
+(shouldn't happen), ask the user about all four rows rather than
+fabricating defaults. Do not retry with a curl.
+
+### Turn 1 — Greet, present derived table, ask questions
+
+Emit ONE natural-language message containing:
+
+1. A one-line greeting using `<agent_identity>` display_name.
+2. The derived Source-of-Truth table ("Here's what I picked up from
+   your setup — does this look right?").
+3. Any **rows you could NOT infer** (typically zero or one).
+4. Two preference questions in the **same** message — no `Q1`/`Q2`
+   labels, speak naturally:
+   - Communication style — how should the agent talk to you?
+     (e.g., concise, casual, no emojis). Skip is OK.
+   - Project-management preferences — any preferences for how the
+     agent should handle your projects? (e.g., weekly milestones,
+     design doc before code). Skip is OK.
+
+Hard rules for Turn 1:
+
+- Do **NOT** emit a `management-rules` code block.
+- Do **NOT** emit a `character` code block.
+- Do **NOT** call any curl.
+
+Then wait for the user's reply.
+
+A common failure mode here is the model treating Turn 1 as a one-shot
+"produce the document" task and emitting `management-rules` before
+the user has answered — the dashboard would silently lock in default
+preferences on the unanswered Turn-1 emission. Don't.
+
+### Turn 2 — After the user replies, emit the artifacts
+
+In this exact order:
+
+1. Emit the `management-rules` code block **FIRST** — the dashboard
+   reveals the preview as soon as the block lands, so emitting it
+   first makes visible-progress immediate. Use the template in
+   "rules/management.md Format" below.
+
+2. If the user stated a tone / style preference (not "no preference" /
+   "skip"), emit a `character` code block immediately after — see
+   "Character code block format" below. Omit the block entirely if
+   they skipped.
+   **Do NOT put communication style inside rules/management.md, and do NOT put it inside user/profile.md.**
+   Tone / style / voice / formality / emoji / language preferences
+   live in the `character` runtime-config field only.
+
+3. Silently PUT /api/context/user/profile using the
+   "user/profile.md Format" template below. Working hours and quiet
+   hours pre-populate with defaults (Weekdays 09:00–18:00,
+   Quiet hours 22:00–08:00) — do not ask. Fill Platforms from the
+   **derived Source-of-Truth table** (Step 0). Leave Identity blank —
+   setup does not collect name or timezone.
+
+4. If the user shared detail-heavy facts in their reply, PATCH the
+   matching `user/*.md` file. **Only seed what the user actually
+   stated — do not invent or infer.**
+
+   | Fact type | File |
+   |-----------|------|
+   | Named colleagues, family, friends | user/people.md |
+   | Current company, role specifics, ongoing projects | user/work.md |
+   | Specific frameworks, years of experience | user/expertise.md |
+   | Long-term goals, aspirations | user/goals.md |
+   | Hobbies, lifestyle habits, dietary notes | user/personal.md |
+
+   See the user-profile skill for the read-before-write PATCH recipe
+   and the `section_not_found` → `append_to_file` first-write
+   fallback. (user/profile.md `## Expertise` keeps a one-line summary
+   only — detailed framework history goes to user/expertise.md.)
+
+**Important**: Do NOT curl-write rules/management.md yourself. The
+dashboard persists it via `POST /setup/save-rules` when the user
+clicks Save & Finish. Do NOT PATCH /api/config/character either —
+the dashboard stages the `character` block and writes it atomically
+on Save & Finish.
+
+### Turn 3+ — Revisions (cap: 2 rounds)
+
+If the user requests changes, revise the `management-rules` block and
+re-emit it. Hard cap: **at most 2 revision rounds** total. Do NOT
+re-run the Turn-2 curl writes — they already persisted. The dashboard
+saves the revised rules block on Save & Finish.
 
 ### 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:
+Output language: section headers stay English (the daemon parses
+them); descriptive bullets under `## Autonomy Levels`, `## Notification
+Rules`, `## Schedule`, `## Project Management` follow `<settings
+primary_language>`. Also stay English: `## Agent Identity` field
+labels (`- AI name:`, `- WhatsApp label:`), Source-of-Truth table
+headers and Domain labels, and product/brand cells (`Google
+Calendar`, `Obsidian`, `Notion`, `today.md`, `projects/*.md`).
+
+Fill the Source of Truth table from the rows you confirmed in Turn 1.
+Use today's YYYY-MM-DD for `updated` (the date below is an example).
 
 ```management-rules
 ---
@@ -288,18 +187,39 @@ updated: 2026-04-21
 - {user's project-management-method answer verbatim, or "No specific preferences — follow standard project practices" if they skipped}
 ```
 
-Use today's YYYY-MM-DD for `updated` (the date above is only an example).
+Reproduce blank lines exactly — every `##` heading and every table
+must be preceded by a blank line. Never concatenate a heading onto
+the end of the previous list item.
 
-### Markdown formatting (the block is saved to disk verbatim)
+### Character code block format
 
-Reproduce the template's blank lines exactly — every `##` heading and
-every table must be preceded by a blank line. Never concatenate a
-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.
+Emit only when the user stated an actual preference. Body rules:
+raw text only (no markdown, no outer quotes, no nested fences),
+≤1000 chars (surface excess rather than silently truncating), at
+most one block per turn.
 
-**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.)
+```character
+Speak casually. Tight bullets. No emojis.
+```
+
+### user/profile.md Format
+
+When you PUT /api/context/user/profile, write the full file in this
+shape. Use today's YYYY-MM-DD for `updated`. Do not omit
+`## Notification Preferences` — Morning Routine reads it directly.
+
+Use inline `-d '{"content": "..."}'` with `\n` escapes. Do **NOT**
+use `-d @-`, heredoc pipelines, or `--data-raw '@-'` — those have
+produced malformed bodies in this flow (server saw literal `@-` and
+returned 500).
+
+```bash
+curl -s -X PUT http://localhost:8321/api/context/user/profile \
+  -H 'Content-Type: application/json' \
+  -d '{"content": "---\ntype: user\nowner: shared\nupdated: 2026-04-23\n---\n# User\n\n## Identity\n\n## Work Pattern\n- Working hours: Weekdays 09:00–18:00\n\n## Platforms\n- Schedule: Google Calendar\n- Notes: Obsidian\n- Projects: Notion\n\n## Expertise\n\n## Notification Preferences\n- Quiet hours: 22:00–08:00\n\n## Learned Context\n\n## Raw Signals\n"}'
+```
+
+If the response is non-2xx, retry once with a smaller body or switch
+to section-level PATCH. The default allowlist includes
+`Bash(curl *)` — a denial here is a body-shape issue, not a
+permission issue.

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

@@ -26,7 +26,7 @@ The shim reads stdin when `-d @-` is passed, so the heredoc body lands as the JS
 
 ### Procedure
 
-1. Fetch the URL with the per-backend primitive (WebFetch on Claude, curl on Codex, web_fetch on Gemini).
+1. Fetch the URL with the per-backend primitive (WebFetch on Claude, curl on Codex/OpenCode, 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.
 

package/agent-assets/templates/_manifest.json

@@ -1,6 +1,6 @@
 {
   "manifestVersion": 1,
-  "generatedAt": "2026-04-23",
+  "generatedAt": "2026-05-18",
   "notes": "Auto-generated inventory of versioned templates. Each entry's 'version' must equal the `template_version:` field in the corresponding template file's frontmatter. Bump both in the same PR. A unit test asserts this consistency.",
   "templates": {
     "_index.md": {
@@ -64,7 +64,7 @@
       "version": 1
     },
     "rules/journal-format.md": {
-      "version": 1
+      "version": 3
     },
     "rules/management.md": {
       "version": 2
@@ -82,22 +82,22 @@
       "version": 1
     },
     "user/expertise.md": {
-      "version": 1
+      "version": 2
     },
     "user/goals.md": {
-      "version": 1
+      "version": 2
     },
     "user/people.md": {
-      "version": 1
+      "version": 2
     },
     "user/personal.md": {
-      "version": 1
+      "version": 2
     },
     "user/profile.md": {
       "version": 2
     },
     "user/work.md": {
-      "version": 1
+      "version": 2
     }
   }
 }

package/agent-assets/templates/dossiers/_index.md

@@ -15,7 +15,7 @@ Injected into prompts through the root-level context-index.md catalog.
 | File | Process key |
 |---|---|
 | `hourly.md` | `routine.hourly_check` |
-| `morning.md` | `routine.morning_routine`, `routine.morning_routine_initial` |
+| `morning.md` | `routine.morning_routine`, `routine.morning_routine_today` |
 | `evening.md` | `routine.evening_review` |
 | `weekly.md` | `routine.weekly_review` |
 | `monthly.md` | `routine.monthly_review` |