@aitne-sh/aitne 0.1.7 → 0.1.9

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

@@ -272,18 +272,18 @@ voice carries the whole message.
 - Tasks list: cap 10, append `...and N more` if over.
 - Overnight: cap 5 per category (mail / dm / calendar).
 - No internal names ("Morning Routine", "Agent Plan",
-  "scheduled.dm", "today.md") in user-facing text.
+  "scheduled.dm", "state/today.md") in user-facing text.
 - Forbidden openers across all variants: "Morning briefing —",
   "Morning briefing delivered", "Here's your day".
 
 ### 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)
 
@@ -305,7 +305,7 @@ occurring outgoing-DM opportunities to slip a question in without it
 feeling cold. Use the **user-interview** skill's "Operation 3 — Latent
 piggyback" recipe:
 
-1. GET `agent/profile-questions.md` ## In Progress. If no entry has
+1. GET `state/profile-questions.md` ## In Progress. If no entry has
    `state=latent`, skip this section entirely.
 1.5 **Slot-filled pre-check.** GET
    `/api/profile-questions/slot-filled?path=<target>&section=<section?>&anchor=<anchor?>`.
@@ -352,7 +352,7 @@ recipe:
 
 ### Step 1 — Fire-time abort (Layer 3)
 
-GET `agent/profile-questions.md` and the row's `<target_path>`. Call:
+GET `state/profile-questions.md` and the row's `<target_path>`. Call:
 
 ```bash
 curl -s "http://localhost:8321/api/profile-questions/slot-filled?path=<target>&section=<section?>&anchor=<anchor?>"
@@ -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",
@@ -623,12 +623,12 @@ handled in one read-then-branch sequence:
    ```
 
    `<confirm_decline_marker.path>` is the value from `taskContext`
-   (e.g. `agent/journal.md`). The endpoint accepts the path with or
+   (e.g. `journal/agent.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
+     (`journal/agent`) 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
@@ -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

@@ -26,7 +26,7 @@ message the user reads — plan the closing turn accordingly.
 - **Non-empty only when** the task's job is to deliver a short message
   AND you did not call `/api/notify`. Write the message itself, not a
   meta-report about it.
-- **Never name internal mechanisms** in the final text: no `today.md`,
+- **Never name internal mechanisms** in the final text: no `state/today.md`,
   `## Agent Plan`, `## Agent Log`, `did-not-fire`, "DM sent", "logged",
   "closed the row" — those go in Agent Log only. The same rule applies
   in whatever language you respond to the user; no status-word openers
@@ -89,16 +89,16 @@ confirmation.
       off 30 s and retry up to 3 times. If still held, **skip the
       roadmap flip entirely** — the next refresh reconciles — and
       proceed to Step 3 below so the task still executes.
-   2. `GET /api/context/roadmap` and locate the matching
+   2. `GET /api/context/plans/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,13 +129,13 @@ 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.
 
 ### Step 5: Follow-up (optional)
 9. Register follow-up wake-ups if the action produced new work (schedule skill).
 10. For additional context if needed:
-    - GET /api/context/roadmap — long-term goals and milestones
-    - GET /api/context/projects/_active — active projects summary
+    - GET /api/context/plans/roadmap — long-term goals and milestones
+    - GET /api/context/plans/projects/_active — active projects summary

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

@@ -1,250 +1,149 @@
 {context}
 
-## 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").
+## Task: Initial Setup — Create policies/management.md
+
+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 policies/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/identity/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.
-
-### 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:
+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
+   "policies/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 policies/management.md, and do NOT put it inside identity/profile.md.**
+   Tone / style / voice / formality / emoji / language preferences
+   live in the `character` runtime-config field only.
+
+3. Silently PUT /api/context/identity/profile using the
+   "identity/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 | identity/people.md |
+   | Current company, role specifics, ongoing projects | identity/work.md |
+   | Specific frameworks, years of experience | identity/expertise.md |
+   | Long-term goals, aspirations | identity/goals.md |
+   | Hobbies, lifestyle habits, dietary notes | identity/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. (identity/profile.md `## Expertise` keeps a one-line summary
+   only — detailed framework history goes to identity/expertise.md.)
+
+**Important**: Do NOT curl-write policies/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.
+
+### policies/management.md 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`, `state/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
 ---
@@ -271,7 +170,7 @@ updated: 2026-04-21
 - today.md updates: Autonomous
 - Notifications: Autonomous (within rules)
 - External service operations: Confirm with user
-- rules/management.md changes: Always confirm
+- policies/management.md changes: Always confirm
 
 ## Notification Rules
 - Quiet hours: 22:00–08:00 (default — adjustable in Settings)
@@ -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.
+
+### Character code block format
+
+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.
+
+```character
+Speak casually. Tight bullets. No emojis.
+```
+
+### identity/profile.md Format
+
+When you PUT /api/context/identity/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.
 
-### Markdown formatting (the block is saved to disk verbatim)
+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).
 
-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.
+```bash
+curl -s -X PUT http://localhost:8321/api/context/identity/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"}'
+```
 
-**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.)
+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/setup.update.md

@@ -12,7 +12,7 @@ Output language: follow `<output_language_policy>` (this is a DM-style turn —
 2. Ask the user which part they'd like to change, presenting these options:
    - **Source of Truth** — Change tools
    - **Notification Rules** — Notification timing and methods
-   - **Character (tone / style / voice)** — Update the `character` runtime-config field, emitted as a ```character``` code block (NOT `rules/management.md`, NOT `user/profile.md`)
+   - **Character (tone / style / voice)** — Update the `character` runtime-config field, emitted as a ```character``` code block (NOT `policies/management.md`, NOT `identity/profile.md`)
    - **Autonomy Levels** — Agent decision scope
    - **Schedule** — Working hours
    - **Project Management** — Preferences for how the agent should handle your projects
@@ -45,7 +45,7 @@ not part of the wizard's editable surface, and stripping them silently
 breaks downstream features:
 
 - **`## Agent Identity`** — populated by the daemon from `agentDisplayName`. Re-emit it as-is or omit it (the server upserts it on save).
-- **`## Active Policies`** — a static wikilink to `rules/policies/_index.md` placed by skeleton seeding. Owned by the management-policy capture flow (the wizard is read-only here). If it is missing from the current rules (legacy installs), do NOT invent it; the next skeleton run will add it.
+- **`## Active Policies`** — a static wikilink to `policies/management-captures/_index.md` placed by skeleton seeding. Owned by the management-policy capture flow (the wizard is read-only here). If it is missing from the current rules (legacy installs), do NOT invent it; the next skeleton run will add it.
 
 The same applies to any other section the wizard does not explicitly
 ask the user about — when in doubt, copy it through unchanged.

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.