@aitne-sh/aitne 0.1.0

package/agent-assets/task-flows/routine.hourly_check.triage.md

@@ -0,0 +1,93 @@
+{context}
+
+## Hourly Check — Stage 2 Triage
+
+You are the Stage-2 lite-tier triage gate of the three-stage
+`routine.hourly_check` funnel (cost-reduction-structural §B). The
+deterministic Stage-1 gate already screened out the obviously-quiet
+cron ticks and the obviously-urgent ones. Your job is the narrow
+middle band: low-signal observations that *might* deserve a full
+Stage-3 session, or *might* be safely silenced with a single Agent Log
+line.
+
+You have NO write tools. You produce ONLY a single JSON line on
+stdout. The dispatcher reads that line and either spawns Stage 3 or
+appends a one-line silent log via the daemon-direct writer.
+
+### Hard contract — read carefully
+
+1. The ONLY output is one JSON object on its own line. No prose
+   before, no prose after. If you produce anything else the dispatcher
+   defaults to `escalate` so a malformed reply is never a silent skip.
+2. The schema is exactly:
+
+   ```json
+   { "action": "log_only" | "escalate", "reason": "<<=80 chars>" }
+   ```
+
+3. `action="log_only"` means: the daemon will silently consume pending
+   observations and append one bullet to today.md `## Agent Log`. No
+   user-visible side effect.
+4. `action="escalate"` means: the daemon spawns the full Stage-3
+   hourly_check session with a `<gate_decision>` block that carries
+   your `reason` so the routine knows what to prioritize.
+5. `reason` is short, mechanical, telemetry-friendly. Examples:
+   `"calendar event needs review"`, `"only journal noise"`,
+   `"vip mail not urgent yet"`, `"new git commit on watched repo"`.
+   Do NOT include user-identifying details, secrets, or full file
+   paths — the reason ends up in `agent_actions.detail` and feeds the
+   shadow-mode telemetry dashboard.
+
+### Triage rubric — when to escalate
+
+Escalate to Stage 3 when **any** of these hold:
+
+- The summary mentions a hard deadline, time-bounded ask, or "today /
+  this morning / this afternoon" cue from a user-actor source (DM,
+  mail, calendar, notion).
+- A calendar observation indicates a meeting that lands inside today
+  AND `<gate_decision>` snapshot's `pendingObs > 0` AND the meeting is
+  not already covered by the existing `## Agent Plan`.
+- A git observation is on a watched personal/work repo AND the change
+  type is `created` or `modified` (not `deleted`) AND the path is not
+  obviously generated (`*.lock`, `dist/`, `build/`).
+- A mail observation has `novelty_score >= 2` and the
+  `<gate_decision>` snapshot shows `vipMail >= 1`.
+- The summary text references the user by name OR mentions an
+  imminent action ("send", "reply", "review", "approve").
+- Two or more observations cross-reference the same path / project /
+  thread — that pattern is more interesting than the rows individually.
+
+Stay log-only when **all** these hold:
+
+- Every pending observation is `novelty_score <= 1` per its summary.
+- No calendar / VIP-mail / agent-plan-overdue / schedule-approaching
+  signal is present in the snapshot above.
+- The observations are journal-only, trivial formatting churn,
+  auto-generated artifacts, or already-processed agent writes.
+- Nothing in the summaries names the user, a deadline, or a request.
+
+### When in doubt
+
+Default to `escalate`. Stage 3 has the full skills, MCP surface, and
+context to reach the right answer; a wrongly-escalated tick costs ~$0.01
+in Sonnet tokens, while a wrongly-suppressed tick costs the user a
+missed reminder. The shadow-mode validation phase explicitly rewards
+high recall over high precision: ship the bias toward escalate, the
+operator-tunable thresholds will trim it later.
+
+### Output examples
+
+```json
+{ "action": "log_only", "reason": "5 obsidian journal edits, no deadlines" }
+```
+
+```json
+{ "action": "escalate", "reason": "calendar created in next 6h" }
+```
+
+```json
+{ "action": "escalate", "reason": "git commit on hot project repo" }
+```
+
+Output one line. Then stop.

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

@@ -0,0 +1,250 @@
+{context}
+
+## Task: Monthly Review
+
+The "Vault policy files" block appended to this prompt includes
+`routines/monthly.md` — run any `### <label>` entries there alongside the
+built-in review phases below, using the same journaling conventions.
+The "Vault review context" block includes `context-index.md` and
+`dossiers/monthly.md`; consult it during Phase 1 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.
+
+Generate the monthly review snapshot for the current month and set up the next month.
+
+This routine produces **two separate artifacts** with strict audience boundaries:
+  - **User-facing**: `monthly/YYYY-MM.md` + (optionally) a short notification.
+    Only real user work, wins, and next-month focus. No agent mechanics.
+  - **Agent-internal**: `agent/journal.md` (append). Monthly self-critique,
+    recurring filter/schedule failures, cross-week patterns in the agent's
+    own behavior, and concrete system improvement proposals. **Never**
+    surfaced to the user via notify.
+
+Follow the context skill for file ownership rules. This routine owns the
+workflow; the skill owns the file contract.
+
+### Phase 1: Gather the month
+1. Determine the target file name from <current_time>:
+   `monthly/YYYY-MM.md`.
+2. Fetch source material for the current month:
+   - Use GET /api/context/list/daily to discover archived daily files and
+     read each `daily/YYYY-MM-DD.md` in the current month.
+   - Use GET /api/context/list/weekly to read weekly reviews that overlap this month.
+   - Read the last ~4 weekly sections of `agent/journal.md` via GET — they
+     accumulate the agent-internal bucket across the month and are the basis
+     for Phase 3b's monthly retrospective.
+   - Also locate the **previous month's** `## Monthly YYYY-MM` section in
+     `agent/journal.md`. Extract its `### Proposed adjustments` bullets —
+     these are the improvement proposals you committed to last month. You
+     will evaluate their status in Phase 3b.
+   - Include <today> if it belongs to the same month.
+3. Use <roadmap>, <active_projects>, and <calendar_events_30d> to understand:
+   - milestone movement,
+   - recurring bottlenecks,
+   - next-month commitments already on the calendar.
+4. Gather reading data for the month via the `reading` skill:
+   - `GET /api/books/summary?months=3` — read the first entry of
+     `monthlyCompleted` matching the current `YYYY-MM` (if any), plus
+     `totalHighlights`.
+   - `GET /api/books?status=completed&limit=50` — filter client-side to
+     rows whose `completedAt` falls in the current month.
+   - `GET /api/books?status=reading&limit=20` — top currently-active reads.
+   - Do NOT re-derive the taste profile here — that is the weekly sweep's
+     job (`user/reading-taste.md`). For the monthly review, just
+     read the existing profile if it exists and include at most one
+     sentence about a recurring theme if it helps frame the Wins or
+     Risks And Patterns sections. If the file does not exist, skip it.
+
+### Phase 2: Synthesize — split into two buckets
+5. Build TWO separate mental lists before writing anything:
+   a. **User-facing bucket** (goes to `monthly/YYYY-MM.md` and possibly notify):
+      - What meaningful user progress happened this month?
+      - Which user commitments slipped or stayed open, and why (in terms the
+        user cares about, not agent mechanics)?
+      - What user-side risks or workload patterns carry into next month?
+      - What should the user prioritize next month?
+   b. **Agent-internal bucket** (goes to `agent/journal.md` only):
+      - Cross-week patterns in scheduled-task failures / did-not-fire
+      - Filter and prioritization failures the agent noticed about itself
+      - Notification discipline: over-notify / under-notify patterns
+      - Observation pipeline throughput and categories consistently skipped
+      - Concrete, testable system improvement proposals (prompt, schedule,
+        filter, silence gate tuning)
+6. Anything that fits the agent-internal bucket MUST NOT land in the
+   user-facing file or notification. The user-side "Risks And Patterns"
+   section is about the user's workload and habits, never about the agent's
+   own performance or reliability.
+
+### Phase 3a: Write the user-facing review
+7. PUT the review to `monthly/YYYY-MM.md`.
+   Required structure (user outcomes only — no agent mechanics in any section):
+   ```
+   ---
+   type: monthly
+   owner: agent
+   updated: YYYY-MM-DD
+   ---
+   # Monthly Review YYYY-MM
+   > Period: YYYY-MM-01 to YYYY-MM-last
+   > Generated at: YYYY-MM-DD HH:MM
+
+   ## Summary
+   - ...
+
+   ## Wins
+   - ...
+
+   ## Outstanding Items
+   - ...
+
+   ## Metrics
+   - User tasks completed: N
+   - User tasks carried into next month: N
+   - Key commitments kept / missed: N / N
+
+   ## Risks And Patterns
+   - (user workload, recurring bottlenecks, habit observations — NOT agent
+     reliability)
+
+   ## Reading
+   - Completed this month: N — short list of "Title — Author (★rating)"
+     bullets, max 5 lines. Omit the Reading section entirely if N = 0
+     AND currently-reading count = 0.
+   - Currently reading: up to 3 titles with highlight count.
+   - Optional single sentence on a recurring theme from `reading-taste.md`
+     if the file exists and says something non-generic. Do not quote the
+     file verbatim — paraphrase in one clause.
+
+   ## Next Month Priorities
+   - ...
+   ```
+   The `## Metrics` section tracks **user** activity only. Do not add rows
+   like "agent plan rows completed", "scheduled tasks fired", "observations
+   processed" — those belong in agent/journal.md.
+
+   Skip the `## Reading` section entirely if the user imported zero books
+   and has zero completions this month — an empty reading block is noise.
+8. Update roadmap.md and relevant projects/*.md when the review shows
+   milestone drift, completed phases, or a changed next-month focus.
+
+### Phase 3b: Append to agent/journal.md (internal)
+9. PATCH-append a monthly retrospective block to `agent/journal.md` via
+   `mode: "append_to_file"` (no `section` param needed — content is
+   appended to the end of the file). This is the cross-week synthesis of
+   the weekly sections that accumulated during the month.
+   Required shape for the appended block — **these bullet caps are hard
+   limits, not suggestions**. The daily retention sweep warns when any
+   section exceeds ~4000 bytes; bloat here indicates you ignored the caps.
+   ```
+   ## Monthly YYYY-MM
+   > Appended at: YYYY-MM-DD HH:MM
+
+   ### Prior adjustments follow-up
+   - (Review EACH bullet from last month's `### Proposed adjustments`.
+     For each one, write exactly one of:
+       ✅ implemented — [what changed]
+       ⏳ in progress — [current state]
+       ❌ dropped — [why]
+     Fallback rules:
+       - No prior monthly section exists → "- First month — no prior adjustments"
+       - Prior section exists but has no `### Proposed adjustments` subsection
+         (e.g. written before this format was introduced) →
+         "- Prior month had no proposed adjustments to follow up on"
+       - Prior section was pruned by retention (>24 months old) →
+         treat as "no prior month")
+   ### Recurring self-critique
+   - (max 5 bullets; only patterns that showed up in multiple weekly sections.
+     One-off issues from a single week do not belong here — they were already
+     captured in that week's journal entry)
+   ### Biggest system gap
+   - (exactly 1 bullet — the single most impactful improvement. Forcing
+     yourself to pick one prevents the agent-journal from becoming a wishlist)
+   ### Proposed adjustments
+   - (max 3 bullets; concrete and testable — prompt tweak, schedule
+     adjustment, filter rule, silence gate tuning. "Improve filter quality"
+     is not testable; "Lower hourly_check observation threshold from 2 to 1
+     on weekends" is)
+   ### Metrics (agent side, monthly roll-up)
+   - Agent plan rows completed: N
+   - Did-not-fire / failed rows: N
+   - Notifications sent vs. suppressed: N / N
+   - Observations reviewed / ignored: N / N
+   ```
+   **Hard limits for this block** (the rollup will warn if exceeded):
+     - Total section budget: ≤ 4000 bytes (~1000 tokens)
+     - Bullet caps: Prior follow-up ≤ 3 (matching the prior month's
+       adjustment cap), Recurring ≤ 5, Biggest gap = 1, Adjustments ≤ 3
+     - Metrics section: exactly 4 numeric lines, no commentary
+   If you notice more than 5 recurring patterns, keep the 5 with the highest
+   cross-week frequency and drop the rest. Single-week anomalies are already
+   in that week's journal entry and do not need re-listing.
+
+   If `agent/journal.md` does not yet exist, PUT a minimal file with
+   `# Agent Journal\n\n` header plus this section, in a single call.
+
+   **Idempotency note**: if a `## Monthly YYYY-MM` section for the current
+   month already exists, append a new section anyway. The daily retention
+   rollup collapses duplicate keys last-write-wins, so your newer append
+   automatically supersedes the earlier one within 24 hours.
+
+### Phase 4: Notify (user-facing only)
+10. The notification is for the USER, not a report of Phases 1–3. Never
+   mention monthly/YYYY-MM.md, agent/journal.md, "Monthly Review complete",
+   agent plan rows, did-not-fire, filter quality, observation processing,
+   or any other internal mechanism.
+
+#### 4a. Silence gate — decide whether to notify at all
+Prefer silence over noise. Send **no notification** if ALL of the following
+hold:
+  - Fewer than 2 real Wins worth naming (a quiet month)
+  - No Outstanding Item the user is not already aware of
+  - No Next Month priority that needs a heads-up tonight (the user will see
+    it in the first morning briefing of the new month anyway)
+  - No hard deadline within the next 30 days that is slipping
+When the gate triggers: skip POST /api/notify entirely. The
+monthly/YYYY-MM.md file is still written. Also log one line in the current
+weekly section of agent/journal.md: `silent monthly wrap-up — nothing
+actionable`.
+
+#### 4b. When you DO notify — content rules
+Answer, in the user's preferred language from the Character block:
+  1. **The biggest win of the month** (1 line).
+  2. **The single most important open loop carrying into next month**, with
+     a brief user-meaningful reason. Omit if Outstanding Items is empty.
+  3. **The main focus for next month** (1 line).
+
+Optional 4th line: a hard deadline heads-up if one falls within the next 30
+days and is visibly slipping.
+
+#### 4c. Format rules (hard limits)
+  - Maximum 4 short lines total. No markdown headers. No bullet list.
+  - Lead with the win, not with "Monthly Review" or any ceremony.
+  - Forbidden vocabulary in the user-facing message: "Monthly Review",
+    "monthly/", "agent-journal", "did-not-fire", "Agent Plan", "observations",
+    "processed", "summary", "retrospective", "completed the review". These
+    describe agent mechanics, not user outcomes. The same rule applies in
+    whatever language the user prefers — do not paste an equivalent
+    meta-phrase.
+  - Priority `normal`. Respects quiet hours via the notify skill contract.
+  - Exactly ONE notification via POST /api/notify. Do not split.
+
+#### 4d. Shape example (illustrative — translate to user's language)
+Good (something worth saying):
+    Biggest win of April: Phase 1 of {APP_NAME} shipped on time.
+    Still open: the Phase 2 scope call — you'll want a decision before week 2.
+    Next month's focus: Phase 2 foundation + the Q2 roadmap refresh.
+
+Good (silent path — nothing is sent):
+    (no POST /api/notify call; one-line note appended to agent/journal.md)
+
+Bad (this is the failure mode this prompt exists to prevent):
+    Monthly Review YYYY-MM complete. Wrote monthly/2026-04.md. Metrics:
+    user tasks 28/35, agent plan rows 120, did-not-fire 7, observations
+    processed 82. System improvement ideas logged. Review notification sent.
+
+The bad example reports the agent's bookkeeping. Everything in it either
+belongs in agent/journal.md or was never worth telling the user.

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

@@ -0,0 +1,300 @@
+{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: for each active account in the `mail` skill's `accounts.md`, fetch
+   the 10 most recent messages (the wire surface depends on Gmail's mode in
+   `<integration_modes>` — see the four-branch block below). Then classify
+   each actionable email into a category tag and drop any whose focus is
+   off. Skip the step entirely when no accounts are active.
+
+<!-- mode:direct:gmail -->
+   Use the `mail` skill — `GET /api/mail/:accountId/messages?limit=10` for
+   every account (Gmail, Outlook, iCloud, Yahoo, IMAP — same wire surface).
+<!-- /mode:direct:gmail -->
+<!-- mode:delegated-same:gmail -->
+   Non-Gmail accounts (iCloud / Outlook / Yahoo / IMAP): use the `mail`
+   skill as in direct mode. Gmail accounts: the `/api/mail/*` per-account
+   gate returns 410 — use your session backend's native Gmail MCP tool
+   with a "10 most recent inbox" query (`q=in:inbox`, limit/maxResults
+   `10`). The `mail` skill body lists the per-backend tool names; this
+   session is same-backend so no daemon proxy is involved.
+<!-- /mode:delegated-same:gmail -->
+<!-- mode:delegated-cross:gmail -->
+   Non-Gmail accounts: use the `mail` skill as in direct mode. Gmail
+   accounts: call `POST http://localhost:8321/api/integrations/gmail/exec`
+   with a natural-language `task` (e.g. "Search Gmail for the 10 most
+   recent inbox messages, return from / subject / snippet / ts") and a
+   small `outputSchema`. The cross-backend `mail` skill variant
+   (`SKILL.delegated.<session-backend>.md`, materialized for this
+   session) carries the worked schema templates. Do NOT call
+   `/api/mail/:gmail-account/*` (returns 410), and do NOT fall back to
+   your own backend's native Gmail MCP tools — that connector reads a
+   different account than the user's delegated one.
+<!-- /mode:delegated-cross:gmail -->
+<!-- mode:disabled:gmail -->
+   Gmail is disabled — skip Gmail accounts entirely. Continue with the
+   remaining accounts (iCloud / Outlook / Yahoo / IMAP) via the `mail`
+   skill so non-Gmail actionables still flow into today's draft.
+<!-- /mode:disabled:gmail -->
+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 observations
+6. Call `GET /api/observations?pending=true&actor=user` (observations
+   skill). Fold only meaningful user-originated 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.
+   - Write in `<settings primary_language>` (fall back to English on
+     unknown values). 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)` if `<calendar_status>` reports failure.
+   - ## 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">
+    ```
+    Always English (B-007 §3 P6) regardless of `<settings primary_language>`.