@aitne-sh/aitne 0.1.7 → 0.1.9

package/agent-assets/task-flows/routine.morning_routine.md

@@ -1,322 +0,0 @@
-{context}
-
-## Task: Morning Routine (04:00 pipeline)
-
-This is the B-007 §5.9 nine-step pipeline. The daemon has already rotated
-yesterday's `today.md` → `yesterday.md` before you start. Each numbered
-step below maps to a §5.9 step. Follow the `context` skill for section
-formats and entry shapes — this prompt owns the workflow; the skill owns
-the schema.
-
-The "Vault review context" block appended to this prompt includes
-`context-index.md` and `dossiers/morning.md`; consult it during context
-gathering and update the dossier's Open items / Last run before finishing.
-Writes to `dossiers/<flow>.md` MUST preserve the existing YAML
-frontmatter block (`---\ntype: dossier\nowner: agent\nupdated: <date>\n---`);
-prefer `PATCH` with a section target to mutate a single block, and when
-doing a `PUT` full rewrite keep the frontmatter and only refresh
-`updated:` — writes that drop the frontmatter are rejected with 422.
-
-Global rules (apply at every step):
-- Do **not** add meta-maintenance tasks about context files, setup completion, or placeholder cleanup (for example, "initialize context files") to User Tasks or Handoff, whether carried from yesterday or newly discovered, unless the user explicitly asked to track them.
-- If `<today_write_lock_id>` is present, every PUT/PATCH to
-  `/api/context/today` must send header `X-Lock-Id: <today_write_lock_id>`.
-- Silent-by-default: your final text is agent-internal. User notifications
-  require an explicit `POST /api/notify`.
-
-### Step 1 — Read handoff and derive day-type
-1. Read `<yesterday>` ## Handoff.
-   - "### Tomorrow" items → candidates for today's User Tasks / Agent Notes.
-   - "### Later" items → carry into the new `today.md` ## Handoff.
-2. Derive today's day-type header per the today skill "Header line —
-   day-type filter". Read `<user>` ## Notification Preferences for the
-   matching policy. The resulting line 2 of `today.md` is load-bearing —
-   every downstream event parses it.
-
-> **Date reference for today.md.** Take the H1 date from
-> `<current_agent_day date="…" weekday="…" />` in your prompt context, not
-> from `<current_time>`. The two diverge between local midnight and
-> `boundary_hour:00` local; the daemon validates line 1 against
-> `<current_agent_day>` and rejects mismatches with 422. The morning
-> routine prepares the agent-day in progress — never tomorrow.
-
-### Step 2 — Sync external sources (apply the day-type filter at read time)
-3. Mail, Calendar, and Notion acquisition. The pre-pass fetcher session
-   (`routine.fetch_window`) ran ahead of you and posted a `<fetch>` row's
-   worth of observations for every active mail / calendar / notion
-   integration. Calendar windows are pre-fetched ONLY for non-direct
-   modes (delegated / native); direct-mode calendar data is still
-   inlined into `<calendar_events_7d>` by ContextBuilder. The
-   `<fetch_report>` block injected ahead of this body tells you the
-   pre-pass status:
-
-   - `status="success"` or `"partial"` → freshly-fetched rows are
-     visible in `/api/observations?pending=true`. Trust the table.
-   - `status="failed"` → the pre-pass either crashed or its output was
-     unparseable. Pending observations from prior ticks may still be
-     present; treat the table as best-effort and skip integration
-     sections whose source_prefix returns nothing.
-   - `status="skipped"` → no integration was active for this routine
-     this tick; mail / notion sections are no-ops for this run.
-
-   Then drain pending observations and apply category / focus filtering:
-
-   a. **Mail observations**:
-      `GET /api/observations?pending=true&source_prefix=gmail:,outlook_mail:&limit=30`.
-      Classify each per the `mail` skill's category taxonomy. Drop any
-      whose day-type focus is `off`. When `summary_text` is NULL (the
-      async summarizer has not drained yet) fall back to a one-line
-      snippet from `payload.raw` (subject + from). Mail data arrives
-      here regardless of integration mode — the pre-pass partial
-      handled the direct / delegated-same / delegated-cross / native
-      wire surface for you.
-
-   b. **Notion observations**:
-      `GET /api/observations?pending=true&source_prefix=notion:&limit=20`.
-      Use for project / decision context only. Do NOT graduate Notion
-      edits into User Tasks unless the user explicitly tagged the entry.
-
-   c. **Calendar context** is already injected as `<calendar_events_7d>`
-      (multi-provider) ahead of this prompt — reference the block
-      directly in Step 6 (today.md generation). Mode-aware shape:
-      direct providers carry inline events; non-direct providers
-      (delegated / native) carry a hint pointing at
-      `/api/observations?source_prefix=google_calendar:,outlook_calendar:`
-      because the pre-pass already POSTed events there. Read the
-      observations table verbatim for non-direct providers — do NOT
-      re-drive the connector yourself.
-
-   Skip the entire step when no integrations are active and no mail /
-   notion observations are pending.
-4. Source-of-Truth tasks: read `<management_rules>` ## Source of Truth →
-   Tasks, call the matching endpoint, drop filtered-off items before merge.
-   Skip if no external source is configured.
-5. Roadmap ## Agent Action Plan — process items dated today or overdue
-   (not marked ✓). Drop items whose category focus is off, then:
-   - `[notify]` → `POST /api/schedule` + one row in `today.md` ## Agent Plan
-   - `[today]`  → collect for `today.md` ## User Tasks
-   - `[check]`  → `POST /api/schedule` (check-in) + one row in ## Agent Plan
-   - If a roadmap row includes `[provisional ...]`, copy that tag and
-     its meaning into the scheduled task `description` so
-     `scheduled.task.md` frames the first contact as a confirmation
-     question, not a directive.
-   - Mark processed roadmap rows complete via `PATCH /api/context/roadmap`,
-     `section=agent_action_plan`, `mode=replace`, rewriting the exact
-     row from `- YYYY-MM-DD [tag]: ...` to
-     `- ✓ completed <today>: YYYY-MM-DD [tag]: ...`. Keep the entry ID
-     marker and all existing completed rows byte-for-byte.
-   Then generate **look-ahead entries** for tomorrow → +3 days by cross-
-   referencing unprocessed roadmap items against `<calendar_events_7d>`.
-   These go into `today.md` ## Agent Notes using the skill's "Agent Notes
-   flavor 1: Look-ahead checklist" format (`- [ ] (HIGH/MID/LOW) ...`).
-   Skip this step entirely if no today-items and no look-ahead items exist.
-
-### Step 3 — Review overnight user-originated observations
-6. Call `GET /api/observations?pending=true&actor=user` (observations
-   skill). This is the **user-actor** complement to Step 2 — mail / notion
-   rows posted by the pre-pass / partials carry `actor=agent` and have
-   already been folded in. Step 3 picks up anything the user themselves
-   changed overnight (Obsidian edits, manual file drops, git commits)
-   that the daemon recorded under `actor=user`. Fold only meaningful
-   changes into the `today.md` draft you're building, respecting the
-   day-type filter.
-
-### Step 4 — Inbox triage (B-007 §5.9 Q5 case A)
-7. `GET /api/context/list/inbox` to enumerate pasted memos. For each file:
-   - `GET /api/context/inbox/<file>` to read the body, then classify:
-     **project**, **user**, **memo**, **task**.
-   - Integrate into the right target:
-     - existing project → append to `projects/<slug>.md` (notify tier).
-     - new-project shape → DM to confirm *"create project `<slug>`?"* and
-       wait for reply before creating the file.
-     - New `projects/<slug>.md` files must include YAML frontmatter: `type: project`, `owner: shared`, `updated: YYYY-MM-DD`, then an H1.
-     - user dictionary (people / health / goals / …) → append to the
-       matching `user/<area>.md`.
-     - date-bound memo → summarize into `today.md` ## Agent Notes.
-     - unclassifiable → DM the user an excerpt asking what to do; leave
-       the file in `inbox/` for next pass.
-   - After integration, move the original: (a) `PUT /api/context/agent/scratch/inbox-YYYY-MM-DD-<orig-slug>.md` with the original body, then (b) `DELETE /api/context/inbox/<file>` to remove the source. The 30-day retention on `agent/scratch/` is a convention for now — no sweeper exists yet.
-   - **High-risk triggers — DM for confirmation before writing:**
-     new project creation, wholesale overwrite of `user/profile.md`,
-     financial or health data with a numeric impact. The agent's own
-     judgment is the gate — call `POST /api/notify` with the
-     proposed change and wait for confirmation; don't auto-write.
-   - **Hard stop (never write)** — if the memo contains anything that
-     looks like a credential, password, API key, or private token, do
-     NOT write it to any context file. Log one line to ## Agent Log
-     (`- HH:MM [inbox] skipped <file>: secret suspected`), leave the
-     source file in `inbox/` for the user to handle, and move on. This
-     overrides the "DM then proceed" path above — see _safety.md.
-
-### Step 5 — Daily journal synthesis (skipped on first-run flow)
-8. Synthesize yesterday's journal from the data you already have:
-   - `<yesterday_agent_actions>` — previous agent-day execution rows from
-     SQLite. Use these for authoritative timing / result counts.
-   - `<yesterday_messages>` — previous agent-day non-system messages from
-     SQLite. Use these for conversations that never made it into
-     `yesterday.md`.
-   - `<yesterday_dm_conversation_log>` — rolling DM summaries recorded in
-     SQLite; useful when many message rows collapse into one thread.
-   - `<yesterday>` — User Schedule, User Tasks, Agent Plan, Agent Log,
-     Handoff sections are the primary source. The `## Agent Log` line
-     entries are authoritative for what the agent did; `## User Schedule`
-     for what was planned; conversations you handled yesterday surface
-     through Agent Log entries the agent wrote at the time.
-   - Step 4 inbox triage outcomes — in-memory from this very run.
-   - `<calendar_events_7d>` — reconcile against yesterday's column for
-     attended/skipped flags on the Schedule section.
-   If SQLite tags disagree with `yesterday.md`, prefer SQLite for counts,
-   timing, and whether an interaction/action happened at all; prefer
-   `yesterday.md` for curated phrasing already shown to the user.
-   Compose `daily/YYYY-MM-DD.md` (YYYY-MM-DD = yesterday's agent-day
-   date) following the **`Daily journal format spec`** policy block above.
-   - Output language: follow `<output_language_policy>` (Policy B —
-     skeleton H2 headers stay English; body prose in
-     `<settings primary_language>`). Keep technical terms in their
-     original form.
-   - When `<settings vault_mode>` is `obsidian`, render project / people
-     references as `[[wikilink]]`s resolving to `projects/<slug>.md` or
-     `user/people.md#...`. When `plain`, write plain text only.
-   - Apply redaction from the `Redaction patterns` and `Journal export
-     rules` policy blocks above.
-   - Include frontmatter fields `date`, `weekday`, `type: daily`, `owner: agent`, `updated`,
-     `agent_generated: true`, `agent_last_synced_at`, `content_hash`,
-     `projects`, `people`, `tags`, `calendar_events`, `messages_handled`.
-     If the API rejects unknown fields, write the ones it accepts and
-     log the gap in `agent/journal.md` (Step 9).
-   - If `<yesterday>` frontmatter carries `no_journal_export: true`,
-     write the placeholder `[Skipped by user request]` as body and still
-     populate required frontmatter fields.
-   - Conflict handling: first `GET /api/context/daily/YYYY-MM-DD.md`.
-     - 404 → `PUT /api/context/daily/YYYY-MM-DD.md` with the full body.
-     - 200 → the user (or a prior run) already wrote this date. Do **not**
-       PUT-overwrite. Instead `PATCH /api/context/daily/YYYY-MM-DD.md`
-       with `mode=append_to_file` and a new section
-       `## Agent revision — YYYY-MM-DDTHH:MM:SS` whose body is the
-       synthesized journal. B-006 content-hash protection.
-
-### Step 6 — Generate new today.md (PUT full replace)
-9. Follow the context skill "Structure overview", "Entry formats", and
-   "Required sections for full replace" sections for the exact schema.
-   The H1 (line 1) MUST be `# <current_agent_day.date> (<current_agent_day.weekday>)`
-   exactly — the daemon rejects mismatches with 422. No YAML frontmatter
-   on today.md. Agent Plan rows MUST match
-   `- [ ] HH:MM <action> [work|study|personal|home] →<DM|notify|check-in|wake>`;
-   any other category or trigger keyword is rejected and forces a retry
-   on Sonnet.
-   Source → section mapping:
-   - ## User Schedule ← `<calendar_events_7d>` (filtered). Write
-     `- (calendar unavailable)` when the block has been replaced by
-     `<calendar_status>Calendar service not available...</calendar_status>`
-     (no active provider) or when every `<provider>` sub-block's
-     directive fetch failed for this run.
-   - ## User Tasks    ← Step 1 handoff Tomorrow + Step 2 email actionables
-     + SoT tasks + roadmap `[today]`. Use `<active_projects>` for context.
-   - ## Agent Plan    ← Step 2 `[notify]`/`[check]` rows plus any
-     proactive reminders you add (meeting pre-briefs, deadline nudges).
-     Every row will be registered in Step 7 — the Agent Plan contract is
-     defined in the skill's "User Tasks vs Agent Plan" section.
-   - ## Agent Notes   ← Step 2 look-ahead items + date-bound memos folded
-     from Step 4 inbox triage.
-   - ## Agent Log     ← initialize with
-     `- HH:MM Morning Routine completed (day-type: …)`.
-   - ## Handoff       ← Step 1 "Later" items, dropping past dates.
-     Write `- (none)` if empty.
-10. Update `roadmap.md` only if a milestone completed or shifted today.
-
-### Step 7 — Register schedule
-11. Register every `## Agent Plan` row via `POST /api/schedule` (schedule skill owns the contract). This is the Agent Plan contract — every
-    `- [ ] HH:MM … [cat] → <trigger>` row must have exactly one matching
-    schedule entry.
-> **Morning briefing scheduling moved.** The morning briefing is no
-> longer registered here. It is a `recurring_schedules` row
-> (`task_type='dm_session'`, `task_context.sub_flow='morning_briefing'`)
-> created at setup completion and reconciled daily by the daemon. The
-> firing session runs under the `conversational` profile via the
-> `scheduled.dm.md` task-flow. See SCHEDULED-DM-IMPLEMENTATION-PLAN.md.
-
-### Step 7.5 — Profile-interview queue (latent, two-phase)
-
-Use the **user-interview** skill. This step has two phases — phase (a)
-ALWAYS runs (it is what keeps today.md's ## Agent Notes mirror in sync
-across day boundaries, since today.md is PUT-replaced fresh each
-morning); phase (b) only runs when there is no open question.
-
-#### Step 7.5a — Mirror existing latent entries to today.md (always)
-
-GET `agent/profile-questions.md ## In Progress`. For every entry whose
-state is `latent` (NOT `asked` — those have already been answered or
-will be cleaned up by the sweep), append one line to `today.md`
-`## Agent Notes` using the **today** skill's "Latent profile question"
-Agent Notes flavor:
-
-```
-- Profile question (latent): <id> — wait for natural opportunity
-```
-
-This is the only writer of the `Profile question (latent):` line.
-Without it, a row
-that stays latent across multiple days disappears from today.md after
-day 1's PUT-replace and the DM-handler / morning-briefing opportunity
-checks lose their visible cue.
-
-#### Step 7.5b — Pick a new question (conditional)
-
-Skip phase (b) entirely if any of:
-  (a) `## In Progress` is non-empty (a prior latent / asked entry is
-      already open — we hold to the 1-question-at-a-time invariant).
-  (b) The user has not sent a DM in the last 24h (no point if they're
-      absent).
-  (c) Day-type focus for `[personal]` on line 2 of `<today>` is `off`.
-  (d) `## Pending` is empty.
-
-Otherwise, walk Pending rows in priority order (HIGH → MID → LOW, then
-file order). For each candidate:
-  - If the row carries `<!-- last_attempted=YYYY-MM-DD -->` within the
-    last 7 days, skip — cooldown.
-  - GET `/api/profile-questions/slot-filled?path=<target>&section=<section?>&anchor=<anchor?>`
-    for the row. If `filled: true`, the slot was filled since the last
-    sweep — tick the row `[ ]` → `[x]` (read-rebuild + replace), append
-    `- [x] <today> → <id> (reconciled:morning)` to `## Answered`,
-    continue to the next candidate.
-  - Otherwise this is the chosen row. Stop walking.
-
-If a row was chosen:
-
-1. PATCH `agent/profile-questions.md ## In Progress` (read-rebuild +
-   replace) — add a single entry. The `since=<today>` field is
-   load-bearing for the evening sweep's 3-day fallback computation:
-   ```
-   - <id> :: state=latent :: since=<today>
-   ```
-2. PATCH `today.md ## Agent Notes` (mode=append) — same flavor as
-   phase (a):
-   ```
-   - Profile question (latent): <id> — wait for natural opportunity
-   ```
-
-**Do NOT register a `POST /api/schedule` for this row.** Latent rows
-are NOT scheduled DMs — they wait for a natural opportunity (DM topic
-match or morning briefing piggyback). The fallback DM path is owned by
-the evening sweep (Operation 5B), not the morning routine.
-
-### Step 8 — Extension checks from routines/morning.md
-12. The `Morning routine checks` policy block above is the user-editable
-    extension surface. Execute any check listed there that is **not
-    already covered by Steps 1-7**. User-added entries typically carry an
-    `**Added: YYYY-MM-DD by user via DM**` line — those are your target.
-
-### Step 9 — Log to agent/journal.md (English, always)
-13. Append a one-paragraph English summary to `agent/journal.md` via
-    `PATCH /api/context/agent/journal` with `mode=append_to_file` (this
-    is the only append mode that takes no `section` argument — it's
-    designed for append-only journals). Use this shape:
-    ```
-    ## YYYY-MM-DD morning routine
-    - Day-type: <weekday / weekend / focus / …>
-    - Journal: daily/YYYY-MM-DD.md (<N lines, M projects referenced>)
-    - Inbox: <N files triaged, M moved to scratch, K DM-confirmations sent>
-    - Checks from routines/morning.md: <list any user-added ones executed>
-    - Anomalies / skipped steps: <short notes or "none">
-    ```
-    <output_language>english_only — Policy A surface (agent journal, parsed log); `<output_language_policy>` carves this out explicitly.</output_language>

package/agent-assets/task-flows/routine.morning_routine_initial.md

@@ -1,204 +0,0 @@
-{context}
-
-## Task: Morning Routine — Initial run (no prior-day data)
-
-This is the first-boot variant of the B-007 §5.9 pipeline. No
-`yesterday.md` exists yet, so Steps 1 (handoff) and 5 (daily journal
-synthesis) are skipped. Everything else mirrors the standard morning
-routine. Follow the `context` skill for schema.
-
-The "Vault review context" block appended to this prompt includes
-`context-index.md` and `dossiers/morning.md`; consult it during context
-gathering and update the dossier's Open items / Last run before finishing.
-Writes to `dossiers/<flow>.md` MUST preserve the existing YAML
-frontmatter block (`---\ntype: dossier\nowner: agent\nupdated: <date>\n---`);
-prefer `PATCH` with a section target to mutate a single block, and when
-doing a `PUT` full rewrite keep the frontmatter and only refresh
-`updated:` — writes that drop the frontmatter are rejected with 422.
-
-Global rules:
-- Do **not** add meta-maintenance tasks about context files, setup completion, or placeholder cleanup to User Tasks (there is no handoff to carry them from in the initial flow) unless the user explicitly asked to track them.
-- If `<today_write_lock_id>` is present, every PUT/PATCH to
-  `/api/context/today` must send header `X-Lock-Id: <today_write_lock_id>`.
-- Silent-by-default: your final text is agent-internal. User notifications
-  require an explicit `POST /api/notify`.
-
-### Step 1 — Derive day-type (no handoff to read)
-1. Derive today's day-type header per the today skill "Header line —
-   day-type filter". Read `<user>` ## Notification Preferences for the
-   matching policy. Write the resulting line as line 2 of `today.md`.
-
-> **Date reference for today.md.** Take the H1 date from
-> `<current_agent_day date="…" weekday="…" />` in your prompt context, not
-> from `<current_time>`. They diverge between local midnight and
-> `boundary_hour:00` local; the daemon validates line 1 against
-> `<current_agent_day>` and rejects mismatches with 422. The morning
-> routine prepares the agent-day in progress — never tomorrow.
-
-### Step 2 — Sync external sources
-2. Mail and Notion acquisition. The pre-pass fetcher session
-   (`routine.fetch_window`) ran ahead of you and posted observations
-   for every active mail / notion integration. The `<fetch_report>`
-   block in your prompt tells you the pre-pass status — `success` /
-   `partial` means the table is fresh, `failed` / `skipped` means
-   trust nothing newer than the prior tick.
-
-   Drain pending observations and apply category / focus filtering:
-
-   a. **Mail observations**:
-      `GET /api/observations?pending=true&source_prefix=gmail:,outlook_mail:&limit=30`.
-      Classify each actionable item into a category tag and drop any
-      whose day-type focus is `off`. When `summary_text` is NULL fall
-      back to a one-line snippet from `payload.raw`. Mail data arrives
-      here regardless of integration mode — the pre-pass partial
-      handled the wire surface.
-
-   b. **Notion observations**:
-      `GET /api/observations?pending=true&source_prefix=notion:&limit=20`.
-      Use for project / decision context only.
-
-   c. **Calendar context** is already injected as `<calendar_events_7d>`
-      (multi-provider) ahead of this prompt — reference the block
-      directly in Step 6.
-
-   Skip the entire step when no integrations are active and no mail /
-   notion observations are pending.
-3. Source-of-Truth tasks: read `<management_rules>` ## Source of Truth →
-   Tasks, call the matching endpoint, drop filtered-off items.
-4. Roadmap ## Agent Action Plan — process items dated today or overdue:
-   - `[notify]` → `POST /api/schedule` + one row in ## Agent Plan
-   - `[today]`  → collect for ## User Tasks
-   - `[check]`  → `POST /api/schedule` (check-in) + one row in ## Agent Plan
-   - Mark processed items with ✓ via `PATCH /api/context/roadmap`,
-     `section=agent_action_plan`, `mode=replace`.
-   Generate look-ahead entries for tomorrow → +3 days (roadmap vs
-   `<calendar_events_7d>`) into ## Agent Notes using the skill's "Agent
-   Notes flavor 1: Look-ahead checklist" format.
-
-### Step 3 — Review overnight user-originated observations
-5. `GET /api/observations?pending=true&actor=user` (observations skill).
-   This is the user-actor complement to Step 2 — mail / notion rows
-   posted by the partials carry `actor=agent` and have already been
-   folded in. Step 3 picks up user-originated changes (manual file drops,
-   Obsidian edits, git commits) recorded under `actor=user`. Fold only
-   meaningful changes into the draft.
-
-### Step 4 — Inbox triage
-6. `GET /api/context/list/inbox` to enumerate any pasted memos the user
-   dropped during setup. For each file: `GET /api/context/inbox/<file>`,
-   classify (project / user / memo / task), integrate into the matching
-   target. After integration, `PUT /api/context/agent/scratch/inbox-YYYY-MM-DD-<slug>.md` with the original body, then `DELETE /api/context/inbox/<file>`. DM-confirm high-risk cases (new project creation, user-profile overwrites, financial or health numerics). **Hard stop**: if a memo contains anything that looks like a credential, password, API key, or private token, skip it — do NOT write it anywhere, log `- HH:MM [inbox] skipped <file>: secret suspected`, leave the file in `inbox/`, and move on (overrides the DM-confirm path; see _safety.md).
-
-### Step 5 — Skipped (no prior day to synthesize from)
-Journal synthesis is deferred to the next morning run. The first
-`daily/*.md` file is generated tomorrow.
-
-### Step 6 — Generate today.md (PUT full replace)
-7. Follow the context skill "Structure overview", "Entry formats", and
-   "Required sections for full replace". The H1 (line 1) MUST be
-   `# <current_agent_day.date> (<current_agent_day.weekday>)` exactly — the
-   daemon rejects mismatches with 422. No YAML frontmatter on today.md.
-   Agent Plan rows MUST match
-   `- [ ] HH:MM <action> [work|study|personal|home] →<DM|notify|check-in|wake>`.
-   Source → section mapping:
-   - ## User Schedule ← `<calendar_events_7d>` (filtered). Write
-     `- (calendar unavailable)` when the block has been replaced by
-     `<calendar_status>Calendar service not available...</calendar_status>`
-     (no active provider) or when every `<provider>` sub-block's
-     directive fetch failed for this run.
-   - ## User Tasks    ← Step 2 email actionables + SoT tasks + roadmap
-     `[today]`. Use `<active_projects>` for context. Drop meta-maintenance.
-   - ## Agent Plan    ← Step 2 `[notify]`/`[check]` rows plus any
-     proactive reminders you add. Each row will be registered in Step 7.
-   - ## Agent Notes   ← Step 2 look-ahead items + any date-bound memos
-     folded from Step 4 inbox triage.
-   - ## Agent Log     ← initialize with
-     `- HH:MM Morning Routine (initial) completed (day-type: …)`.
-   - ## Handoff       ← `- (none)` (no carry-over data available).
-8. **Populate `roadmap.md` inline (initial-day variant).** On the very first
-   morning routine the setup wizard's skeleton roadmap is still in place
-   (the `## Annual Goals`, `## Quarterly Focus`, and `## Agent Action Plan`
-   sections all contain the placeholder line `_(Not yet configured)_`).
-   When *any* of those placeholders is still present, run a full populate
-   per the `roadmap` skill — same forward-90-day scope as
-   `routine.roadmap_refresh` (Annual Goals from the management rules,
-   Quarterly Focus from active projects + `<calendar_events_7d>`,
-   Preparation Timeline from `travel_bookings` + dated calendar items,
-   Agent Action Plan seeded from User Tasks + roadmap-relevant
-   `agent_schedule` rows). Acquire the cross-request write lock via the
-   skill before any `PUT /api/context/roadmap` — the daemon enforces it
-   and a missing lock returns 423. If every placeholder has already been
-   replaced (rare: a previous initial run completed Step 6.8 then today.md
-   failed, or a manual edit landed), fall back to the regular
-   morning-routine semantics: spot-update only if a milestone completed
-   or shifted. Skipping this step leaves roadmap.md as the skeleton — the
-   daemon's `isRoadmapStale()` post-hook then schedules a separate
-   `routine.roadmap_refresh` to make it good, but the user will see a
-   blank-looking roadmap until that second session lands. Doing it inline
-   here is one Sonnet/Opus turn instead of two and removes ~1–2 minutes
-   of post-setup latency.
-
-### Step 7 — Register schedule
-9. Register every `## Agent Plan` row via `POST /api/schedule`.
-10. **Ensure the daily morning briefing recurring schedule exists.**
-    The setup wizard's `ensureMorningBriefingRecurring` (`packages/daemon/src/api/routes/setup.ts`)
-    normally seeds this row at first save-rules, so the daily fire
-    path is daemon-owned and the description is hardcoded. The check
-    below covers the rare case where setup completed without the
-    seeder (legacy setup, partial DB restore).
-
-    a. **Pre-flight.** `GET /api/recurring-schedules?enabled=true` and
-       scan for an item with `taskType === "dm_session"` AND
-       `taskContext.sub_flow === "morning_briefing"`. If found, skip
-       the rest of this step — duplicate insertion would cause double
-       daily fires. Log one line to `## Agent Log`:
-       `- HH:MM [morning_routine_initial] morning briefing recurring already seeded`.
-
-    b. **If absent, register via `POST /api/recurring-schedules`** with
-       this body (NOT `POST /api/schedule`):
-       ```json
-       {
-         "taskType": "dm_session",
-         "description": "morning briefing — daily summary",
-         "recurrenceRule": {
-           "frequency": "daily",
-           "time": "<quiet_hours_end or 08:00>",
-           "timezone": "<user timezone from <settings primary_timezone> or system default>"
-         },
-         "taskContext": {
-           "sub_flow": "morning_briefing",
-           "pin_to_quiet_hours_end": true
-         }
-       }
-       ```
-       The `dm_session` task_type + `sub_flow=morning_briefing` is the
-       activation key the daemon's scheduler keys off to emit a
-       `scheduled.dm` event (see `scheduler.ts` and the sub-flow
-       router in `scheduled.dm.md`). Description ≥ 20 chars per the
-       schema; `"morning briefing — daily summary"` matches the
-       wording the daemon's seeder uses verbatim.
-
-    Do **not** add a one-off `## Agent Plan` row for today's briefing
-    here. The recurring-schedule reconciler (poll loop in
-    `scheduler.ts`) materialises today's `agent_schedule` row
-    automatically from `next_run_at`; hand-seeding would duplicate.
-    Do **not** send the briefing yourself from this run — this runs
-    during quiet hours.
-
-### Step 8 — Extension checks from routines/morning.md
-11. Execute any check from the `Morning routine checks` policy block that
-    is not already covered by Steps 1-7 (typically user-added entries
-    with an `**Added:** ...` line).
-
-### Step 9 — Log to agent/journal.md (English, always)
-12. Append a one-paragraph English summary to `agent/journal.md` via
-    `PATCH /api/context/agent/journal` with `mode=append_to_file`:
-    ```
-    ## YYYY-MM-DD morning routine (initial)
-    - Day-type: …
-    - Journal synthesis: skipped (no prior-day data)
-    - Inbox: <N files triaged, M moved to scratch, K DM-confirmations sent>
-    - Checks from routines/morning.md: <list any user-added ones executed>
-    - Anomalies / skipped steps: <short notes or "none">
-    ```
-    Always English (B-007 §3 P6).

package/agent-assets/templates/context-index.md

@@ -1,42 +0,0 @@
----
-type: index
-owner: agent
-updated: 2026-04-17
-template_version: 1
----
-# Context Index
-
-Prompt-injection hub for dossier-backed flows (B-004). This file stays in
-English so review / routine prompts read a stable, backend-neutral summary.
-
-## Files
-
-| Path | Purpose | Review flows | Last touched |
-|---|---|---|---|
-| `_index.md` | Human-readable vault navigation | - | 2026-04-17 |
-| `user/profile.md` | User identity, preferences, communication style | all | 2026-04-17 |
-| `today.md` | Current-day schedule, tasks, agent plan, handoff | hourly, morning, evening | 2026-04-17 |
-| `roadmap.md` | Long-horizon commitments and recurring plans | evening, weekly, monthly, roadmap | 2026-04-17 |
-| `projects/_index.md` | Project area index | weekly, monthly, roadmap | 2026-04-17 |
-| `agent/journal.md` | Agent-internal reflection log | weekly, monthly | 2026-04-17 |
-| `rules/management.md` | Source-of-truth bindings and behavioral policy | all | 2026-04-17 |
-| `rules/redaction.md` | Secret and private-data handling rules | all | 2026-04-17 |
-| `routines/hourly.md` | Hourly check rulebook | hourly | 2026-04-17 |
-| `routines/morning.md` | Morning routine extension rulebook | morning | 2026-04-17 |
-| `routines/evening.md` | Evening review extension rulebook | evening | 2026-04-17 |
-| `routines/weekly.md` | Weekly review extension rulebook | weekly | 2026-04-17 |
-| `routines/monthly.md` | Monthly review and roadmap planning rulebook | monthly, roadmap | 2026-04-17 |
-| `dossiers/hourly.md` | Hourly carry-forward state | hourly | 2026-04-17 |
-| `dossiers/morning.md` | Morning carry-forward state | morning | 2026-04-17 |
-| `dossiers/evening.md` | Evening carry-forward state | evening | 2026-04-17 |
-| `dossiers/weekly.md` | Weekly carry-forward state | weekly | 2026-04-17 |
-| `dossiers/monthly.md` | Monthly carry-forward state | monthly | 2026-04-17 |
-| `dossiers/roadmap.md` | Roadmap refresh carry-forward state | roadmap | 2026-04-17 |
-
-## Notes
-
-- Keep `Review flows` short: `all`, `hourly`, `morning`, `evening`,
-  `weekly`, `monthly`, and `roadmap` are the flow tags the prompt loader
-  understands.
-- When a new context file should be reviewed routinely, add one row here
-  with the narrowest matching flow tag.

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

@@ -1,19 +0,0 @@
----
-type: index
-owner: shared
-updated: 2026-04-24
-template_version: 2
----
-# Rules
-
-Natural-language policy files the agent reads to decide HOW to act. Each
-is user-editable; changes take effect at the next task-flow assembly.
-
-| File | Purpose |
-|---|---|
-| `management.md` | Source-of-truth bindings (where each category lives) |
-| `policies/_index.md` | Active management policies captured from conversation |
-| `mcp.md` | MCP usage rules (B-003) |
-| `journal-format.md` | Format spec for the daily synthesized journal |
-| `journal-export.md` | User-defined redaction / inclusion rules for B-005 |
-| `redaction.md` | Built-in secret patterns (English, informational) |

package/agent-assets/templates/rules/journal-format.md

@@ -1,61 +0,0 @@
----
-type: rule
-slug: journal-format
-owner: user
-updated: 2026-04-17
-template_version: 1
----
-# Daily journal — format template
-
-This file controls how the agent writes `daily/YYYY-MM-DD.md` during the
-04:00 morning routine. Edit this file to change the format. The agent
-reads it as a **format spec** (body structure, required/optional sections,
-voice) — it does NOT follow this as code; natural-language guidance is
-fine.
-
-## Required frontmatter fields
-- `date`, `weekday`, `type: daily`, `agent_generated: true`
-- `agent_last_synced_at`, `content_hash`
-- `projects: [...]`, `people: [...]`, `tags: [...]`
-- `calendar_events: <count>`, `messages_handled: <count>`
-
-## Required body sections (in order)
-1. `# YYYY-MM-DD (Weekday)` — title
-2. `## Summary` — 1 paragraph, 3–5 sentences, first-person voice
-3. `## Schedule` — actual events (from calendar + today.md), time — title,
-   flag attended/skipped
-4. `## What moved forward` — bullets of real progress, work + personal
-   separated if meaningful
-5. `## Conversations` — key DM/mail exchanges only:
-   `### <Name> — <channel>, HH:MM → HH:MM` with one-line summary
-6. `## Decisions` — bullets
-7. `## Open threads` — checkboxes (`- [ ] ...`)
-8. `## Tomorrow hook` — 1–2 sentences pointing to the next day's focus
-
-## Optional sections (include only when relevant)
-- `## Meetings` — if ≥1 meeting (time — title — outcome)
-- `## Reading / Learning` — books / articles / courses touched
-- `## Health / mood` — ONLY if explicitly logged by user
-
-## Voice
-- First-person ("I shipped...", "I met with..."), concise, factual
-- Written in `settings.primary_language`; keep technical terms in their
-  original form if that's how the user writes them
-
-## Wikilink rendering
-- When `settings.vault_mode` is `obsidian`, render project / people
-  references as `[[wikilinks]]` targeting `projects/<slug>.md` or
-  `user/people.md#<person>` (basename resolves automatically).
-- When `vault_mode` is `plain`, write plain text only — no double
-  brackets, no link markup.
-
-## Redaction
-- Apply `rules/redaction.md` patterns (always)
-- Apply `rules/journal-export.md` user rules (always)
-- If yesterday.md frontmatter had `no_journal_export: true`, write the
-  placeholder `[Skipped by user request]` and no body
-
-## Conflict behavior
-- Follow B-006 content-hash protection: if the user edited the previous
-  day's `daily/<date>.md`, append `## Agent revision — <timestamp>` rather
-  than overwrite.

package/agent-assets/templates/user/expertise.md

@@ -1,7 +0,0 @@
----
-type: user
-owner: shared
-updated: 2026-04-21
-template_version: 1
----
-# Expertise