@aitne-sh/aitne 0.1.0

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

@@ -0,0 +1,242 @@
+{context}
+
+## Task: User-profile sweep (`phase`: {event_data[phase]})
+
+Autonomous background run. There is no user-visible output — writes
+go silently to `user/profile.md` and `user/<topic>.md` per the
+**user-profile** skill. Do NOT call `/api/notify`.
+
+The sweep runs 10 min before each paired routine — 03:50 before
+Morning Routine at 04:00, 17:50 before Evening Review at 18:00 — so
+that the paired routine reads a freshly up-to-date `user/profile.md`
+(the only user file auto-injected into sessions via `<user>`) when it
+starts. This is the safety net for DM-time captures that the
+`message.received.dm` / `message.received.dm_first` task-flows missed.
+
+### Step 1 — Read the DM window
+
+Read `<agent_day_messages>` + `<agent_day_dm_conversation_log>`. The
+window is the current agent-day bounds at session start — for the
+morning phase (03:50) that spans ~04:00 yesterday → 03:50 today, and
+for the evening phase (17:50) that spans ~04:00 today → 17:50 today.
+The two windows overlap on the daytime portion; the idempotency check
+in Step 3 keeps this from producing duplicate writes.
+
+If neither tag is present, the ContextBuilder failed to inject the
+window — append one line to `agent/journal.md` (`- HH:MM user-profile
+sweep (phase=<phase>) — aborted: missing agent-day window`) and exit.
+Do not guess at the bounds.
+
+### Step 2 — Extract fact candidates
+
+Scan the window using the trigger shapes in the **user-profile**
+skill's "When to Update" section (identity, explicit preference,
+correction, etc.). For detail-heavy facts the DM-time capture block
+already routes — people, work, expertise, personal, goals — see the
+trigger-shape list in `message.received.dm.md` §"Capture user info"
+for the canonical enumeration. Apply the same routing here.
+
+Focus on persistent facts the user **stated about themselves**. Ignore
+one-off references, speculative inferences, and facts already
+recorded (Step 3 handles deduplication).
+
+### Step 3 — Idempotent routing + PATCH
+
+For each candidate, classify by the **user-profile** skill's decision
+rule (profile.md vs `user/<topic>.md` vs the expertise tie-breaker
+that writes a one-line summary to profile.md and full detail to
+`user/expertise.md`).
+
+For each target file:
+
+1. **GET** the file.
+2. **Check whether the fact (or a paraphrase) is already present.**
+   Idempotency is load-bearing. Two sweeps per day + DM-handler writes
+   will double-cover the same conversation window, so naïve re-writes
+   would duplicate every fact the DM handler already captured.
+3. **If absent and the target section exists**: PATCH `mode: "append"`
+   with the single new bullet.
+4. **If absent and the target section does NOT exist** (PATCH returns
+   `{"error": "section_not_found"}`): retry with PATCH `mode:
+   "append_to_file"` and include the section header in the content:
+   ```bash
+   curl -s -X PATCH http://localhost:8321/api/context/user/people \
+     -H 'Content-Type: application/json' \
+     -d '{"mode": "append_to_file", "content": "\n## Family\n- Sister (Sarah): two kids as of 2026-04"}'
+   ```
+   `append_to_file` does not require a section and is the intended
+   first-write path for a freshly-created topic file with only its H1.
+5. **If a near-duplicate bullet exists with less detail, merge in
+   memory then rewrite the whole section.** GET the section body,
+   replace the matching line with the merged bullet (preserve all
+   other lines byte-for-byte), PATCH `mode: "replace"` with the FULL
+   new section body. `mode: "replace"` rewrites the entire section —
+   sending just the merged bullet as `content` overwrites the whole
+   section and deletes every sibling bullet. This is the same
+   read-before-write discipline the **user-profile** skill's "Worked
+   example" illustrates.
+
+**Scope.** This sweep writes the same `profile.md` sections the DM
+handler writes — Identity, Work Pattern, Expertise (summary),
+Notification Preferences, Learned Context — plus the five
+`user/<topic>.md` files (people, work, expertise, personal, goals).
+Do **not** touch `## Raw Signals` — that section belongs to
+`SignalDetector` only. Tone / style / voice / formality / emoji /
+language preferences do **not** belong in profile.md either — route
+those to the `character` runtime-config field via PATCH
+/api/config/character (see user-profile skill §"Tone / character
+preferences"). Learned
+Context has multiple writers (DM handler, this sweep, Evening Review
+Step 3a's Raw Signals graduation); read-before-write and merge, never
+rewrite the whole section to add a single bullet.
+
+**Learned Context date prefix on merge.** Learned Context entries
+carry a `[YYYY-MM-DD]` prefix (see the **user-profile** skill's
+"Learned Context entry format") so Evening Review can prune entries
+older than 30 days. When your merge logic touches an existing Learned
+Context bullet, **refresh the prefix to today's date** rather than
+preserving the original — a restatement of the same preference is
+evidence it's still live, so the age-based pruning timer should
+reset. Other sections don't carry a date prefix; the byte-for-byte
+preservation rule applies there.
+
+### Step 4 — Log once
+
+Append ONE line to `agent/journal.md`:
+
+```
+- HH:MM user-profile sweep (phase=<phase>) — N facts appended, M merged, K skipped-duplicate
+```
+
+Use `<current_time>` for `HH:MM` in the configured timezone.
+`N` = new bullets added (including first-write `append_to_file`
+paths), `M` = existing bullets merged via `mode: "replace"`,
+`K` = candidates skipped because a paraphrase was already recorded.
+
+If Step 1 aborted due to a missing window, the abort line from Step 1
+is the only journal output — do not append a summary line on top of
+it. Silence otherwise.
+
+---
+
+## Profile-interview queue maintenance (evening run only)
+
+The remaining steps cover the profile-interview queue
+(`agent/profile-questions.md`). They run **only on the evening
+phase** (`phase=evening`) — the morning phase at 03:50 races with the
+04:00 morning routine that picks the next latent question, so the
+queue is not safe to mutate from the 03:50 run.
+
+**On the morning phase (03:50): skip Steps 5, 5.5, and 6 entirely.**
+
+Use the **user-interview** skill's "Operation 5" recipe for the
+sub-steps below.
+
+### Step 5 — Stale recovery (state=asked older than 24h)
+
+GET `agent/profile-questions.md ## In Progress`. For each entry with
+`state=asked` AND `(now − asked_at) > 24h`:
+
+1. Remove the entry from `## In Progress` (PATCH replace; read-rebuild,
+   drop just that line).
+2. Refresh the inline `<!-- last_attempted=<today> -->` HTML comment
+   on the matching `## Pending` row (PATCH replace; read-rebuild the
+   row line, swap or insert the comment, preserve siblings byte-for-byte).
+3. Remove the matching `Profile question (asked HH:MM): <id>` line
+   from today.md `## Agent Notes` (PATCH replace, read-rebuild —
+   preserve every other Agent Notes line byte-for-byte). Without this
+   the line lingers visibly in today.md until tomorrow's PUT-replace.
+4. Do NOT tick the row to `[x]` — the user did not reply. The 7-day
+   `last_attempted` cooldown will keep it out of the morning selector
+   until then.
+
+### Step 5.5 — Latent fallback promotion (state=latent ≥ 3 days)
+
+For each entry with `state=latent`, parse the `since=YYYY-MM-DD` field
+on the entry line. Compute `today − since`; skip rows under 3 days.
+For rows at or over 3 days latent, derive whether the user has been
+actively DMing in the past 24h (use `<agent_day_messages>` from the
+evening window):
+
+**If user is active**: promote to `state=scheduled` and register a
+fallback DM. Pick HH:MM = `quiet_hours_end + 2h` (or 14:00 if working
+hours start before that) on tomorrow's date.
+
+```bash
+curl -s -X POST http://localhost:8321/api/schedule \
+  -H 'Content-Type: application/json' \
+  -d '{
+    "time": "<tomorrow ISO8601 with offset>",
+    "taskType": "dm_session",
+    "description": "profile_interview:<id> — <ask-hint from Pending row>",
+    "model": "sonnet",
+    "taskContext": {
+      "scheduledBy": "user_profile_sweep_fallback",
+      "queueId": "<id>",
+      "importance": "low"
+    }
+  }'
+```
+
+PATCH the In Progress entry (preserve `since=`):
+```
+- <id> :: state=scheduled :: since=<unchanged> :: scheduled_at=<tomorrow HH:MM>
+```
+
+Then remove the matching `Profile question (latent): <id>` line from
+today.md `## Agent Notes` (PATCH replace, read-rebuild — preserve all
+other Agent Notes lines byte-for-byte). Without this the line
+misrepresents state from 17:50 until tomorrow's PUT-replace.
+
+**If user is inactive (≥ 24h silence)**: refresh
+`<!-- last_attempted=<today> -->` on the Pending row (same recipe as
+Step 5), remove the In Progress entry, AND remove the matching
+`Profile question (latent): <id>` line from today.md `## Agent Notes`
+(PATCH replace). Tomorrow's morning routine will pick a different row
+(this one has the 7-day cooldown).
+
+### Step 6 — Daily LLM reconcile (Layer 4)
+
+GET `agent/profile-questions.md` and every distinct `<target_path>`
+referenced by the union of `## Pending` AND `## Answered` rows. For
+each row, judge with model reasoning whether the target section
+**substantively answers the question's intent** — using the row's
+`<id>`, `<target_path>`, optional `match=<anchor>`, `<ask-hint>`, and
+the section body. Substantive ≠ "has any bullet": a populated `## Family`
+section with `Sister (Sarah)` answers `family`; one holding only
+`> Add later` does not. When `match=<anchor>` is present, look for a
+bullet whose key references the anchor's subject.
+
+**Tick path** (Pending `[ ]` → `[x]`):
+
+- PATCH `## Pending`: flip the row, preserve siblings byte-for-byte.
+- Append `- [x] <today> → <id> (reconciled:sweep)` to `## Answered`.
+
+**Untick path** (Answered `[x]` → Pending `[ ]`):
+
+- For rows in `## Answered` tagged `(reconciled:skeleton)` or
+  `(reconciled:morning)` whose target section the LLM judges does NOT
+  in fact answer the question (heuristic false positive from Layer 1
+  or Layer 2): revert. Re-add the row to `## Pending` with the original
+  priority, append `<!-- last_attempted=<today> -->` so it does not
+  immediately re-pick on tomorrow morning, and remove the corresponding
+  `## Answered` entry.
+- **Do NOT untick rows tagged `(DM)`, `(import:*)`, or
+  `(reconciled:fire-time)`** — those represent user-confirmed closures.
+
+For rows the section does NOT answer (and that are still Pending),
+leave them. Do NOT add new rows here — Phase 2 evening-review
+extension owns that path.
+
+### Step 7 — Profile-interview journal line
+
+Append a journal line to `agent/journal.md` (in addition to Step 4's
+sweep line):
+
+```
+- HH:MM profile-questions reconcile — N stale, M latent→scheduled, P latent→deferred, T ticked, U unticked
+```
+
+Skip this line if Steps 5/5.5/6 were no-ops (no In Progress entries
+AND no tick/untick transitions). Keep the journal terse on inactive
+days.

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

@@ -0,0 +1,247 @@
+{context}
+
+## Task: Weekly Review
+
+The "Vault policy files" block appended to this prompt includes
+`routines/weekly.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/weekly.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 weekly review snapshot for the current ISO week and prepare next-week priorities.
+
+This routine produces **two separate artifacts** with strict audience boundaries:
+  - **User-facing**: `weekly/YYYY-Www.md` + (optionally) a short notification.
+    Only real user outcomes and next-week focus. No agent mechanics.
+  - **Agent-internal**: `agent/journal.md` (append). Self-reflection, filter
+    quality, system improvement ideas, failed scheduled actions, pipeline
+    observations. **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 week
+1. Determine the target file name from <current_time>:
+   `weekly/YYYY-Www.md` (ISO week in the daemon timezone).
+2. Fetch the source days for the current week:
+   - Use GET /api/context/list/daily to discover archived daily files.
+   - Read each `daily/YYYY-MM-DD.md` whose date falls in the current ISO week.
+   - Include <today> as the in-progress final day if it belongs to the same week.
+3. Use <roadmap>, <active_projects>, and <calendar_events_7d> to understand:
+   - which milestones moved this week,
+   - what remains incomplete,
+   - what needs attention next week.
+
+### Phase 2: Synthesize — split into two buckets
+4. Build TWO separate mental lists before writing anything:
+   a. **User-facing bucket** (goes to `weekly/YYYY-Www.md` and possibly notify):
+      - What meaningful user work moved forward this week?
+      - Which user tasks or commitments slipped or stalled (with the reason
+        the USER cares about — "blocked on Sarah's reply", not "agent skipped
+        reminder")?
+      - What should the user focus on next week?
+   b. **Agent-internal bucket** (goes to `agent/journal.md` only):
+      - Scheduled tasks / reminders that did-not-fire or failed, and any
+        pattern behind the failures
+      - Quality of the day-type / focus-dimension filter (false positives,
+        false negatives)
+      - Observation pipeline health (how many observations reviewed vs.
+        ignored, any categories consistently skipped)
+      - Self-critique: where I over-notified, under-notified, or made a poor
+        prioritization call this week
+      - Concrete system improvement ideas (tighter silence gates, prompt
+        adjustments, missing context features)
+5. Anything that fits the agent-internal bucket MUST NOT land in the
+   user-facing file or notification. When in doubt about a line item: "would
+   the user act on this, or is it a note about how the agent is doing?" →
+   agent-internal if the latter.
+
+### Phase 3a: Write the user-facing review
+6. PUT the review to `weekly/YYYY-Www.md`.
+   Required structure (user outcomes only — no agent mechanics in any section):
+   ```
+   ---
+   type: weekly
+   owner: agent
+   updated: YYYY-MM-DD
+   ---
+   # Weekly Review YYYY-Www
+   > Period: YYYY-MM-DD to YYYY-MM-DD
+   > Generated at: YYYY-MM-DD HH:MM
+
+   ## Highlights
+   - ...
+
+   ## Completed
+   - ...
+
+   ## Open Loops
+   - ...
+
+   ## Metrics
+   - User tasks completed: N
+   - User tasks carried over: N
+   - Key meetings / commitments kept: N
+
+   ## Next Week Priorities
+   - ...
+   ```
+   The `## Metrics` section tracks **user** activity only. Do not add rows
+   like "agent plan rows completed", "scheduled tasks fired", "observations
+   processed" — those are agent mechanics and belong in agent/journal.md.
+7. If the review reveals roadmap drift or stale project status, update
+   roadmap.md and the relevant projects/*.md in the same session.
+
+### Phase 3b: Append to agent/journal.md (internal)
+8. PATCH-append a new section to `agent/journal.md` with the agent-internal
+   bucket from Phase 2. Use `mode: "append_to_file"` (no `section` param
+   needed — content is appended to the end of the file).
+   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.
+   ```
+   ## Weekly YYYY-Www
+   > Appended at: YYYY-MM-DD HH:MM
+
+   ### What worked
+   - (max 5 bullets, each ≤ 1 line, concrete and specific — no padding)
+   ### What slipped on my side
+   - (max 5 bullets; scheduled tasks that did-not-fire, mis-filtered items,
+     over-notifications. If none, write a single line: "- nothing notable")
+   ### System improvement ideas
+   - (max 3 bullets; each must propose a specific, testable change —
+     prompt tweak / schedule adjustment / filter rule. "Improve the filter"
+     is not testable; "Add Saturday to Weekend day-type default" is)
+   ### Metrics (agent side)
+   - Agent plan rows completed: N
+   - Did-not-fire / failed rows: 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: What worked ≤ 5, What slipped ≤ 5, Improvement ideas ≤ 3
+     - Metrics section: exactly 3 numeric lines, no commentary
+   If you have more than 5 notable items in one subsection, keep only the
+   top 5 by actionable impact and drop the rest. Do not try to fit
+   everything — the monthly review synthesizes across weeks and surfaces
+   recurring items anyway.
+
+   If `agent/journal.md` does not yet exist (GET returns 404), PUT a minimal
+   file with just `# Agent Journal\n\n` as header and your new section below
+   it, in a single call. Do not abort the review.
+
+   **Idempotency note**: if a `## Weekly YYYY-Www` section for the current
+   week already exists (e.g. a previous run of this routine today), 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. Do not spend tokens trying to locate and
+   overwrite the old section in place.
+
+### Phase 4: Notify (user-facing only)
+9. The notification is for the USER, not a report of Phases 1–3. Never
+   mention weekly/YYYY-Www.md, agent/journal.md, "Weekly 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 Highlights worth naming (a quiet week)
+  - No Open Loops the user is not already aware of
+  - No Next Week priority that needs a heads-up tonight (the user will see
+    it in Monday's morning briefing anyway)
+  - No hard deadline within the next 7 days
+When the gate triggers: skip POST /api/notify entirely. The weekly/YYYY-Www.md
+file is still written (user can open it on demand); just no push. Also log
+one line into agent/journal.md's "What worked" subsection:
+`silent weekly wrap-up — nothing actionable`.
+
+#### 4b. When you DO notify — content rules
+Answer, in the user's preferred language from the Character block:
+  1. **One concrete win** from this week (1 line).
+  2. **At most one open loop** that carries into next week, with a brief
+     user-meaningful reason. Omit if Open Loops is empty.
+  3. **The single most important focus for next week** (1 line).
+
+Optional 4th line: a hard deadline heads-up if one falls within the next 7
+days and the user has not yet acted on it.
+
+#### 4c. Format rules (hard limits)
+  - Maximum 4 short lines total. No markdown headers. No bullet list.
+  - Lead with the win, not with "Weekly Review" or any ceremony.
+  - Forbidden vocabulary in the user-facing message: "Weekly Review",
+    "weekly/", "agent-journal", "did-not-fire", "Agent Plan", "observations",
+    "processed", "summary", "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):
+    Big win this week: the design doc shipped Thursday.
+    Still open: the API spec review — Sarah back Monday.
+    Next week's focus: auth refactor landing before the Q2 deadline.
+
+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):
+    Weekly Review YYYY-Www complete. Wrote weekly/2026-W14.md with
+    5 highlights, 3 open loops. Metrics: user tasks 7/10, agent plan
+    rows 24, did-not-fire 2. Observations processed: 18. Next week
+    priorities updated in roadmap.md.
+
+The bad example reports the agent's bookkeeping. Everything in it either
+belongs in agent/journal.md or was never worth telling the user.
+
+### Phase 5: Reading sweep (silent context update)
+
+This phase is **always silent** — it never adds a line to the user-facing
+weekly file or agent-journal unless something unusual happens (see "When
+to abort" below). The weekly notification MAY, but is not required to,
+include one optional reading line; see the reading skill for the rule.
+
+Run after Phase 4 regardless of whether Phase 4 sent a notification.
+Purpose: keep `user/reading-taste.md` fresh, and refresh the
+Book Candidates list.
+
+10. Check whether a sweep is warranted using the exact delta check from
+    the `reading` skill ("Refresh-trigger check"):
+    - `GET /api/context/user/reading-taste` — treat 404 as
+      `Highlights at last sweep = 0` (first sweep writes the file).
+    - `GET /api/books/summary` — read `totalHighlights` as `M`.
+    - Extract `N` from the file's `Highlights at last sweep: N`
+      frontmatter line. If that line is missing (older file schema),
+      treat `N = 0` to force a one-time re-baseline.
+    - If `M - N < 10`, **skip Phase 5** and append one bullet under
+      agent/journal.md "What worked":
+      `reading sweep skipped — only (M-N) new highlights since last refresh`.
+    - Do NOT use the `Sampled: X` line for this check — `X` is the
+      sample size, not a DB count.
+11. Otherwise, follow the **Reading Taste Profile** workflow in the
+    `reading` skill:
+    a. Sample highlights via the skill's sampling recipe.
+    b. Infer Topics / Thinking Patterns / Values / Preferred Formats
+       grounded in specific highlights.
+    c. Propose ≤10 Book Candidates using existing-books exclusion.
+    d. Write or PATCH `user/reading-taste.md` per the skill's
+       schema.
+12. If the taste profile gained ≥1 new candidate and the weekly notify
+    gate in Phase 4 did NOT already fire a silent-path skip, you MAY
+    append one optional line to the already-sent notification by using a
+    second `POST /api/notify` — but only if the candidate is genuinely
+    novel and ties to a pattern the user would recognize as theirs.
+    When in doubt: omit. A forced reading pick is worse than silence.
+
+**When to abort Phase 5 loudly**: if you detect the `reading-taste.md`
+file is corrupted, contains non-English sections, or its "Last updated"
+timestamp is in the future, leave it alone and append one bullet under
+agent/journal.md "What slipped on my side" with a one-line description.
+Never self-heal corrupted profile files without user awareness.

package/agent-assets/task-flows/schedule.approaching.md

@@ -0,0 +1,124 @@
+{context}
+
+## Calendar Event Approaching
+Event: {event_data[event_title]}
+Calendar event id: {event_data[calendarEventId]}
+Start: {event_data[start_time]}
+End: {event_data[end_time]}
+Minutes until start: {event_data[minutesUntil]}
+
+### Decision Framework
+
+The user already knows their own calendar (notify skill § Universal
+user-facing message discipline § Awareness gate). The default for an
+upcoming-event signal is therefore: append to today.md and stay
+silent. Notification is only warranted when the agent has new context
+the user could not see by glancing at their calendar app.
+
+1. **Default: do NOT notify.** Append a heads-up to today.md
+   ## Agent Notes per the context skill ("Observer event formats →
+   schedule.approaching"). If a task in <today> is affected by this
+   event (blocked by, needs prep, scheduled against), note the
+   dependency in the same entry.
+
+2. **Notify ONLY if at least one positive trigger holds and its
+   detection mechanism is implemented.** A trigger without a concrete
+   detection path is a vacuous rule — the LLM can never honestly
+   satisfy it, so it either gets ignored or gets fabricated. Each
+   trigger below names its detection mechanism; unverified ones are
+   scoped out.
+
+   | Trigger | Priority | Detection mechanism |
+   |---|---|---|
+   | (a) reschedule arrived in the past 24 hours | `high` | See **Detection mechanism — trigger (a)** section below the table. |
+   | (d) travel-time concern | `critical` | `POST /api/travel-time` with the user's last-known location + the event venue. |
+
+   #### Detection mechanism — trigger (a) calendar reschedule
+
+   Issue the following call from this session:
+
+   ```
+   GET /api/observations?source=calendar:&pending=false&since=<UTC_24H_AGO>&limit=100
+   ```
+
+   Then filter the response client-side to:
+
+   - `changeType === 'modified'`
+   - `ref === <calendarEventId from prompt header>`
+
+   If any row matches, trigger (a) clears. All five wiring points
+   below matter; getting any one wrong silently zeros this trigger.
+
+   1. **`source=calendar:`** — the API does a SQL `LIKE 'source%'`
+      prefix match (`packages/daemon/src/db/observations.ts:79-82`),
+      so pass the literal prefix `calendar:` with NO wildcard.
+      `calendar:*` is treated as a literal asterisk character and
+      matches zero rows.
+
+   2. **`pending=false`** — `routine.hourly_check` consumes
+      `actor=user` observations every hour, and calendar mutations
+      are tagged `actor='user'` (`calendar-poller.ts:210-212`). A
+      `pending=true` query would miss any reschedule older than the
+      latest hourly tick.
+
+   3. **`since=<UTC_24H_AGO>`** — pass the timestamp 24 hours before
+      the `utc=` attribute on the `<current_time>` block in your
+      context, formatted as `YYYY-MM-DD HH:MM:SS` (UTC, **space
+      separator, no `T`, no `Z`, no fractional seconds**). The DB
+      layer compares with raw lexicographic string equality against
+      `observed_at` storage (`db/observations.ts:87-90`);
+      `observed_at` is SQLite `CURRENT_TIMESTAMP` which writes the
+      space-separator format (`schema.ts:206`). An ISO `T`-separated
+      value lexicographically *exceeds* a same-instant
+      space-separated value (T 0x54 > space 0x20), so passing
+      `2026-04-25T14:30:00Z` would silently exclude observations
+      recorded the same calendar second. Worked example: if
+      `<current_time utc="2026-04-26T14:30:00.000Z" .../>`, pass
+      `since=2026-04-25 14:30:00`.
+
+   4. **`limit=100`** (NOT the default 20) — the API sorts
+      `ORDER BY observed_at ASC` (`db/observations.ts:100`), i.e.
+      oldest-first. With the default `limit=20` and a busy 24h
+      window (multiple calendars syncing, many recurring-event
+      updates), the API returns the 20 *oldest* observations in the
+      window — and the recent reschedule you're hunting for gets
+      clipped off the end. 100 is the API maximum
+      (`observations.ts:39` clamps higher values down). If a user's
+      calendar produces more than ~100 mod observations per 24
+      hours, this trigger needs a server-side `ORDER BY DESC` /
+      `changeType` filter — tracked as a follow-up beyond
+      agent-asset scope.
+
+   5. **`ref === <calendarEventId>`** — the calendar poller writes
+      `ref: event.id` (`calendar-poller.ts:214-215`), and the
+      `Calendar event id` line at the top of this prompt is the
+      exact value to match. The poller's payload also surfaces
+      `summary`/`start`/`end` for sanity-checking the result.
+
+   Triggers (b) conflict-with-another-event and (c) missing-prep are
+   **out of scope** — neither has an implemented detection mechanism
+   in this codebase. Do not notify on these heuristically; treat the
+   event as the default-silent path.
+
+   **Priority rationale.** `schedule.approaching` only fires inside
+   the heads-up window (event starts within the next ~15 minutes by
+   current daemon convention — see `calendar-poller.ts:125`'s
+   `minutesUntil <= 15` gate; the precise figure is on the `Minutes
+   until start:` line at the top of this prompt), so anything that
+   clears the awareness gate at this point is something the user
+   must act on before the event starts. `high` on (a) reaches the
+   user even in quiet hours; `critical` on (d) additionally bypasses
+   rate limits because missing the trip makes the event
+   unattendable. This overrides the notify skill's "`high` reserved
+   for 8h-delay-matters" guidance — inside the heads-up window,
+   every cleared trigger is by definition same-hour-matters.
+
+   Send via `POST /api/notify` per the notify skill at the priority
+   above. If multiple triggers fire for the same event, take the
+   highest. Never send more than one notification per
+   `schedule.approaching` event (observer.md "Boundaries").
+
+3. **Always** log the decision to today.md ## Agent Log per the
+   context skill ("Observer event formats → schedule.approaching") —
+   even when skipping — so the user can audit calendar-triggered
+   decisions.