@aitne-sh/aitne 0.1.7 → 0.1.9

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

@@ -3,20 +3,25 @@
 ## Task: Evening Review
 
 The "Vault policy files" block appended to this prompt includes
-`routines/evening.md` — run any `### <label>` entries there alongside the
+`policies/routines/evening.md` — run any `### <label>` entries there alongside the
 built-in review steps below, using the same journaling conventions.
 The "Vault review context" block includes `context-index.md` and
-`dossiers/evening.md`; consult it before Step 1 and update the
+`knowledge/dossiers/evening.md`; consult it before Step 1 and update the
 dossier's Open items / Last run before finishing. Writes to
-`dossiers/<flow>.md` MUST preserve the existing YAML frontmatter block
+`knowledge/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.
 
 Close out today and prepare tomorrow. Steps 1–3 are internal bookkeeping
-(Morning Routine depends on them). Step 4 is the ONLY user-visible output,
-and it must be written for the user — not as a report of what you just did.
+(Morning Routine depends on them) and emit no user-facing output by default.
+User-defined entries in `policies/routines/evening.md` run alongside the built-in
+steps and are authoritative: execute them as written, including any that
+call `POST /api/notify` — the built-in steps' silence does not override the
+user's explicit rulebook intent. For ad-hoc deadline or surprise nudges,
+the surfacing event handler that discovered the item — not this routine —
+is the right vehicle.
 
 ### Step 0 — Read today's mail outcomes
 
@@ -39,22 +44,11 @@ GET /api/observations?pending=true&source_prefix=gmail:,outlook_mail:&observed_a
 
 Fold meaningful items into the in-memory state you carry into Step 1
 (Finalize today.md — Agent Log entries when an outbound reply closed a
-loop) and Step 4 (Wrap-up — an unanswered inbound that surfaced today
-might satisfy trigger (b)). Do NOT push back into the mail provider —
-this step is read-only; outbound replies belong to the user / morning
-routine / DM-reply paths.
+loop). Do NOT push back into the mail provider — this step is read-only;
+outbound replies belong to the user / morning routine / DM-reply paths.
 
 ### Step 1 — Finalize today.md
    - Check incomplete ## User Tasks status and mark accordingly.
-   - Reconcile ## Agent Plan: every row whose HH:MM has already passed should be
-     either `- [x]` (executed) or `- [x] ... ⚠ failed: <reason>` (attempted).
-     Any row still `- [ ]` with a past HH:MM is a bug — the scheduled task did
-     not close its loop. Flip it to `- [x] ... ⚠ did-not-fire` and log a line to
-     ## Agent Log so the user can see the gap.
-   - **Do not retroactively execute did-not-fire rows.** The window is
-     gone — a 10:00 briefing fired at 21:00 is noise, not value. Only
-     flip the row and log the gap; do not send a stand-alone catch-up
-     notify here.
    - Update the ## Handoff section per the context skill:
      ### Tomorrow — carry-over User Tasks with reason, key context, suggested priorities
      ### Later — keep existing future items, add new ones discovered today
@@ -62,27 +56,33 @@ routine / DM-reply paths.
      setup completion, or placeholder cleanup unless the user explicitly asked
      to track them.
    - Do **not** carry Agent Plan rows into Handoff — Agent Plan is regenerated
-     fresh by Morning Routine the next day.
+     fresh by Morning Routine the next day. Past-HH:MM `[ ]` rows are flipped
+     to `did-not-fire` by Morning Routine reading yesterday.md the next day;
+     this routine no longer reconciles Agent Plan row state.
 
-### Step 2 — Roadmap maintenance (sweep, reconcile, promote)
+### Step 2 — Roadmap maintenance (promote, fire)
 
 Consult the **roadmap** skill for section shapes, entry schema, and the
 write lock. This step only touches `## Long-term Plans` and
 `## Agent Action Plan`; `## Annual Goals`, `## Quarterly Focus`, and
 `## Recurring` are preserved verbatim.
 
+The mechanical sweeps (Scheduled-status sync, 180d Agent Action Plan
+sweep, Long-term Plans stale/awaiting-reply marking) ran 15 minutes
+ago as the daemon-driven `roadmap_mechanical_maintenance` job — they
+are NOT this routine's job anymore. This step only carries the two
+substeps that genuinely need an LLM in the loop: promote-on-resolution
+and Review-date fire.
+
 **Write-lock handling.** `<roadmap_write_lock_id>` is NOT injected for
 evening_review, so acquire the lock explicitly before the first PATCH:
 `POST /api/context/lock/roadmap` → read back `lockId`. On 409 (a
 refresh is mid-write), back off 30 s and retry up to 3 times; if still
-held, skip Step 2 entirely — substeps 2a / 2b will be picked up by the
-next `routine.roadmap_refresh` (Phase 2 does `Scheduled:` status
-reconciliation and Agent Action Plan pruning). 2c / 2d (Long-term
-Plans promotion + stale-mark) are evening-only and will just wait
-until the next Evening Review — a 24-hour delay is acceptable. Release
-with `DELETE /api/context/lock/roadmap` with `{"lockId": "<lockId>"}`
-at the end, and on every early-exit path. Every PATCH / PUT must
-carry `X-Lock-Id: <lockId>`.
+held, skip Step 2 entirely — 2a / 2b are evening-only and will just
+wait until the next Evening Review (a 24-hour delay is acceptable).
+Release with `DELETE /api/context/lock/roadmap` with
+`{"lockId": "<lockId>"}` at the end, and on every early-exit path.
+Every PATCH / PUT must carry `X-Lock-Id: <lockId>`.
 
 **Section-body-rebuild discipline** (applies to every `mode=replace`
 below). LLM rebuilds silently drop lines far too easily. Before each
@@ -94,24 +94,7 @@ PATCH:
 - The new body equals `keep-list + new/mutated line(s)`, byte-for-byte
   for kept lines. Do NOT paraphrase or reformat sibling lines.
 
-2a. **Reconcile `Scheduled:` entry statuses.** For each `### Scheduled:
-    <desc>  (task #<id>)` entry under `## Agent Action Plan`, compare
-    its Status line against the latest `/api/schedule` row for that id.
-    Flip `⏳ pending` → `▶ running` → `✓ completed` / `✗ failed` as
-    needed. Completed entries persist one extra day for the journal,
-    then the next refresh removes them. PATCH
-    `section=agent_action_plan` `mode=replace` so sibling entries
-    survive — apply the rebuild discipline above.
-
-2b. **Sweep `## Agent Action Plan` event entries.** Remove entries
-    whose header date is more than 180 days in the future, and entries
-    whose latest `✓`'d Preparation Timeline row is older than 7 days
-    (past events whose prep is wrapped up). Preserve every entry in
-    the `[today - 7d, today + 180d]` window even if no prep rows
-    fired — the next refresh prunes them when the header date rolls
-    off.
-
-2c. **Promote Long-term Plans → Agent Action Plan.** Scan
+2a. **Promote Long-term Plans → Agent Action Plan.** Scan
     `## Long-term Plans` lines. If an entry has resolved to a concrete
     date today (user DM confirmed, mail booking landed, calendar event
     created), move it into `## Agent Action Plan` as an event entry
@@ -125,25 +108,7 @@ PATCH:
     doubly carefully; dropping an unrelated sibling here is silent user
     data loss.
 
-2d. **Stale-mark Long-term Plans (silent, marker-only).** For each
-    Long-term Plans line, compare the `Source: ... YYYY-MM-DD` date
-    against today:
-    - 90 days without date movement → append ` [stale since
-      YYYY-MM-DD]` (today's date) if the marker is not already
-      present. Mechanical marker only — do not DM.
-    - 180 days with `[stale since ...]` still present → append `
-      [awaiting-reply YYYY-MM-DD]` (today's date). **Do NOT call
-      `POST /api/notify` from this step.** Evening Review's user-
-      visible messaging is owned entirely by Step 4 (silence-by-
-      default contract). Surfacing the awaiting-reply state to the
-      user is deferred to a follow-up RFC-D.2; for now the marker
-      persists in roadmap.md for the user to discover via the
-      dashboard or a future digest.
-    - `[awaiting-reply YYYY-MM-DD]` older than 7 days with no reply
-      surfaced in <yesterday> / <today> Handoff → remove the line via
-      PATCH replace.
-
-2e. **Fire due Long-term Plans.** For each Long-term Plans line whose
+2b. **Fire due Long-term Plans.** For each Long-term Plans line whose
     `Review:` date is on or before today, ignoring `Review: [noreview]`:
     1. Resolve the horizon anchor using the roadmap skill's horizon
        table.
@@ -161,7 +126,7 @@ PATCH:
        `section=long_term_plans` `mode=replace`.
     3. Otherwise, bump `Review:` forward by the class review interval:
        previous Review +30 days by default, or +90 days for `undated`;
-       increment `ReviewCount:` and log one line to `agent/journal.md`.
+       increment `ReviewCount:` and log one line to `journal/agent.md`.
     4. For `undated` lines reaching `ReviewCount: 3` with no
        promotion, silently rewrite `Review:` to `[noreview]`. Do NOT
        DM.
@@ -173,9 +138,9 @@ PATCH:
 
     If a roadmap PATCH/PUT returns 400 from the transition guard, re-GET
     roadmap.md, rebuild from that current body, and retry once while
-    preserving every existing `✓ completed ...` row byte-for-byte. If
+    preserving every existing `completed ...` row byte-for-byte. If
     the retry still fails, stop Step 2, append the validation error and
-    affected IDs to `agent/journal.md`, and stay silent.
+    affected IDs to `journal/agent.md`, and stay silent.
 
 ### Step 3 — Process user/profile.md and user/ per the user-profile skill
    Read <user> ## Raw Signals and classify each entry into one of four buckets.
@@ -185,23 +150,22 @@ PATCH:
    whether a reasonable rewrite is imperative ("do X") or declarative
    ("user does Y"). When ambiguous, default to **character**.
 
+   The routing surface below is the same one the DM handler / sweep
+   apply to live input. Raw Signals are already-detected facts, so the
+   "scan / persist same turn" framing is moot here, but the
+   imperative-vs-declarative bucket assignment and the `profile.md` vs
+   `user/<topic>.md` vs Learned Context split are identical:
+
+{include:_partials/capture-user-info.md}
+
    a₁. **Tone-class signals (imperative rewrite)** — "replies short when
       tired", "prefers English for technical terms", "dislikes long
       paragraphs", "often asks for bullet points" → graduate to the
-      `character` runtime-config field via `PATCH /api/config/character`.
+      `character` runtime-config field per the **user-profile** skill
+      §"Tone / character preferences" (read-before-write, cap-aware).
       These are agent directives disguised as observations — writing them
       to `Learned Context` would repeat the profile-vs-character
-      conflation the split rule is designed to prevent. Read-before-write:
-      ```bash
-      curl -s http://localhost:8321/api/config/character | jq -r .character
-      curl -s -X PATCH http://localhost:8321/api/config/character \
-        -H 'Content-Type: application/json' \
-        -d '{"character": "<merged value>"}'
-      ```
-      Observe the 1000-char cap — if the merged value would exceed the
-      cap, trim the oldest / least specific directives rather than
-      failing the review silently. The updated `character` is injected
-      into every session's CLAUDE.md / AGENTS.md / GEMINI.md uniformly.
+      conflation the split rule is designed to prevent.
    a₂. **Attribute-class signals (declarative rewrite)** — "seems to
       work late", "tends to skim long messages", "is not a morning
       person", "usually catches up on weekends" → integrate into
@@ -215,7 +179,7 @@ PATCH:
       referenced, a lifestyle habit stated, a long-term goal declared, a
       specific framework with years of experience — → graduate into the
       matching user/*.md file via PATCH. The routing table lives in
-      the user-profile skill "user/profile.md vs user/" section; the curl
+      the user-profile skill "identity/profile.md vs user/" section; the curl
       recipe for read-before-write is under "How to navigate user/".
       Always read the target file first, check for duplicates, then PATCH
       (prefer `mode: "append"` for new bullets — it preserves siblings).
@@ -240,7 +204,7 @@ PATCH:
       mode to remove only those entries, preserving any signals that
       SignalDetector appended after your read:
       ```bash
-      curl -s -X PATCH http://localhost:8321/api/context/user/profile \
+      curl -s -X PATCH http://localhost:8321/api/context/identity/profile \
         -H 'Content-Type: application/json' \
         -d '{"section": "raw_signals", "mode": "clear_before", "cutoff": "<latest_processed_timestamp>"}'
       ```
@@ -260,91 +224,3 @@ PATCH:
       Learned Context entries out to the matching user/*.md file and
       remove them from user/profile.md so the primary profile stays compact.
 
-### Step 4 — User-facing wrap-up (the only externally visible output)
-
-The user lived through today. They do not need a bookkeeping recap of
-what you wrote to disk in Steps 1–3 — that belongs in ## Agent Log only.
-Step 4 is the single notification (if any) that the user actually sees,
-and it must be written FOR the user, not as an agent status report.
-
-#### 4a. Silence is the default — notify only on a positive trigger
-
-The evening is silent by default.
-
-**Awareness gate.** See notify skill § Universal user-facing message
-discipline § Awareness gate.
-
-Only after the awareness gate passes, send a notification ONLY if at
-least one of the following positive triggers holds:
-  (a) A ## User Tasks row ended the day incomplete AND is NOT safely
-      carried to ## Handoff Tomorrow with a clear reason — something is
-      dangling, not merely deferred.
-  (b) A hard deadline within the next 48h that the agent surfaced
-      *today* from new input (mail, DM, observation) and the user has
-      not yet acted on it. **Self-set deadlines, course assignments,
-      class times, and items already on the user's calendar do NOT
-      qualify** — they failed the awareness gate.
-  (c) A `did-not-fire` / `failed` Agent Plan row affected the user's
-      real plans (a meeting pre-brief that was supposed to fire, not a
-      routine nudge the user already handled on their own).
-  (d) A new ## Handoff Tomorrow item the agent *discovered today* that
-      the user has not seen yet and would be surprised by in the
-      morning. Items the user themselves added or already know about
-      do NOT qualify.
-  (e) Today carried unusual weight — a milestone shipped, a hard day
-      survived, an illness — and a brief human acknowledgement is
-      warranted.
-
-If NONE of (a)–(e) holds after the awareness gate, do not send
-anything. Write one line to ## Agent Log (e.g. `- HH:MM Evening Review
-completed (silent — nothing actionable)`) and stop. Do NOT send an
-empty or filler notification, and do NOT invent a reason to break the
-silence. **The vast majority of days should land in the silent path** —
-this is the routine working as intended, not a skipped task.
-
-**Anti-example — do NOT send messages like this.** This is the exact
-shape of message the user has flagged as unwanted noise; every line
-fails either the awareness gate or the no-ceremony rule:
-
-```
-Evening check-in — [408019] Week 3 deadline tonight at 11:59pm PT:
-Procurement Plan, RACI Chart, Resource Plan. Still about 6 hours to go.
-Tomorrow: Agile class 6–9pm @ UCLA Extension Gayley.
-```
-
-Why this is bad: (1) "Evening check-in —" is forbidden ceremony.
-(2) The course assignment deadline is the user's own syllabus —
-they're already aware. (3) Tomorrow's class is on the user's own
-calendar — also already aware. (4) "Still about 6 hours to go" is
-filler timing commentary. The correct action for this content is to
-write to ## Agent Log and stay silent.
-
-#### 4b. Late-run handling (quiet hours)
-
-If the current time is inside quiet hours (default 22:00–08:00, configurable) when the routine
-actually executes — e.g., a daemon restart delayed the cron past
-midnight — go silent regardless of (a)–(e). The Handoff section has
-already been written in Step 1, and the next Morning Routine will
-surface anything the user needs to know. Do NOT schedule a deferred
-wrap-up for quiet_hours_end; that would fire right next to the Morning
-Routine briefing and produce a duplicate.
-
-#### 4c. Content and format — delegated to the notify skill
-
-When one of (a)–(e) triggers a notification, follow the **Evening
-wrap-up contract** in the notify skill. That contract owns:
-  - the content structure (lead with the agent-discovered item that
-    cleared the awareness gate),
-  - the 4-line cap and markdown rules,
-  - the no-ceremony / no-filler-timing-commentary rule,
-  - the no-internal-mechanism-names vocabulary rule,
-  - output language per `<output_language_policy>` and tone from the
-    Character block (always present when set),
-  - the good / bad worked examples (including the exact anti-pattern
-    the user has flagged).
-
-This prompt owns only the go/no-go decision above. Send exactly ONE
-notification via POST /api/notify with priority `high` — the
-awareness gate plus triggers (a)–(e) raise the bar high enough that
-anything reaching this point genuinely needs the user's attention
-tonight. Do not split the wrap-up across multiple messages.

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

@@ -8,11 +8,16 @@ sub-session is scoped to a single integration** — every `<fetch>` row
 in the `<acquisition-plan>` block below shares the same `integration`
 attribute, and the sole partial inlined below owns the only
 `(integration, mode)` cell you can hit. Your job is to materialise
-those `<fetch>` rows into fresh `/api/observations` rows via
-`POST /api/observations/batch` — one batched array per acquired window,
-not one curl per item. The coordinator merges your single JSON-line
-output with the other integrations' sub-sessions; you do not write to
-context files, do not synthesize, and do not notify the owner.
+those `<fetch>` rows into fresh `/api/observations` rows via the
+`mcp__aitne-observations__submit_observations` MCP tool (preferred —
+structured-JSON transport that bypasses the SDK bash preflight, so mail
+subjects/snippets carrying Unicode whitespace land cleanly) — one batched
+array per acquired window, not one call per item. If the MCP tool is not
+in your allowed tools (non-Claude session backend), fall back to
+`POST /api/observations/batch` with the same envelope. The coordinator
+merges your single JSON-line output with the other integrations'
+sub-sessions; you do not write to context files, do not synthesize, and
+do not notify the owner.
 
 Read the `<acquisition-plan>` block carefully — every row carries the
 exact `(integration, mode, window, account?, query)` tuple the daemon
@@ -55,11 +60,11 @@ error), emit exactly one JSON line on stdout with the shape:
 ```
 
 - `fetched`    — total items returned by upstream APIs across every row.
-- `posted`     — sum of the batch endpoint's envelope-level `posted`
-  counter across every `POST /api/observations/batch` call you make
-  (i.e. `results[*].status ∈ {"created","modified"}`).
-- `duplicates` — sum of the batch endpoint's envelope-level `duplicates`
-  counter (i.e. `results[*].status == "duplicate"`).
+- `posted`     — sum of the submit envelope's `posted` counter across
+  every `submit_observations` (or `POST /api/observations/batch`) call
+  you make (i.e. `results[*].status ∈ {"created","modified"}`).
+- `duplicates` — sum of the submit envelope's `duplicates` counter
+  (i.e. `results[*].status == "duplicate"`).
 - `errors`     — list of `{type, ...}` records. Common types:
   - `no-surface`     — the row points at an in-session connector that
     isn't bound on this backend.
@@ -67,11 +72,11 @@ error), emit exactly one JSON line on stdout with the shape:
     filter (defensive).
   - `fetch-failed`   — upstream API returned a non-2xx; include
     `{type, integration, account?, status, message}`.
-  - `flip-locked`    — `POST /api/observations/batch` returned
+  - `flip-locked`    — the submit envelope returned
     `results[*].status="flip_locked"` for an integration mid-flip.
     Include `{type, integration, account?}`. Do NOT retry inline —
     the next routine tick reaps it.
-  - `validation-error` — `POST /api/observations/batch` returned
+  - `validation-error` — the submit envelope returned
     `results[*].status="validation_error"` for a malformed item.
     Include `{type, integration, ref, detail}` (copy `detail` from
     `results[*].error`).
@@ -103,6 +108,6 @@ of the plan produced.
   loop over items in a shell `for`. Do NOT chain multiple curl
   invocations. Those shapes are blocked by the daemon's Bash hooks
   (one curl per Bash call, heredoc bodies are stripped from URL
-  validation). One window → one curl → one JSON body whose
+  validation). One window → one submit → one JSON body whose
   `observations[]` array carries every fetched item (up to 200; split
-  larger windows into multiple POSTs).
+  larger windows into multiple `submit_observations` / POST calls).

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

@@ -2,11 +2,18 @@
 
 ## Hourly Observation Review
 
+This task-flow is the **daemon-internal** hourly cron — a built-in
+observation review the dispatcher fires every hour. It is NOT the
+user-facing recurring path. An operator who wants a custom recurring
+task creates a recurring **Agent** (`POST /api/agents`, e.g. an hourly
+cron `0 * * * *`); those fire `scheduled.task` / `scheduled.dm` events
+instead.
+
 The "Vault policy files" block appended to this prompt includes
-`routines/hourly.md` — your canonical check list for this cadence.
+`policies/routines/hourly.md` — your canonical check list for this cadence.
 The "Vault review context" block includes `context-index.md` and
-`dossiers/hourly.md`; consult it before Step 1 and update the dossier's
-Open items / Last run before finishing. Writes to `dossiers/<flow>.md`
+`knowledge/dossiers/hourly.md`; consult it before Step 1 and update the dossier's
+Open items / Last run before finishing. Writes to `knowledge/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
@@ -19,7 +26,7 @@ routing rules.
 
 Output language: follow `<output_language_policy>` (Policy B for any
 context-MD write-up; Policy C for the optional `POST /api/notify` DM).
-Agent log appends to `agent/journal.md` stay English (Policy A).
+Agent log appends to `journal/agent.md` stay English (Policy A).
 
 Use the observations skill to fetch pending items. The pre-pass
 fetcher session (`routine.fetch_window`) ran ahead of you and posted
@@ -69,11 +76,9 @@ observation warrants project-state context (e.g. references a project,
 milestone, or deliverable — not merely a file edit in a watched repo).
 
 ### Stage gate decision (cost-reduction-structural §B)
-When `<gate_decision>` is present, this run was escalated through the
-three-stage funnel (Stage 0 deterministic gate or Stage 2 lite-tier
-triage; Stage 3 is the current session). The block tells you *why*
-you were spawned — pull the `reason` and `signals_snapshot` into
-your prioritisation. Examples:
+The `<gate_decision>` block is always present — every Stage 3 enqueue
+emits it. The block tells you *why* you were spawned — pull the
+`reason` and `signals_snapshot` into your prioritisation. Examples:
 
 - `reason: vip_mail_unread` → start with the mail observation, do not
   scan obsidian noise first.
@@ -84,9 +89,11 @@ your prioritisation. Examples:
   own dispatcher.
 - `reason: heartbeat_due` → low-signal heartbeat. Stay maximally
   silent unless something actually warrants action.
-
-If `<gate_decision>` is absent, this is a legacy direct invocation
-(Phase-9 path before the gate was wired) — proceed as before.
+- `reason: cautious_escalate_prepass_failure` → the pre-pass fetcher
+  failed for at least one non-direct integration this tick. The
+  `<fetch_report status="failed">` block in your prompt tells you
+  which integration is lossy; treat its observations as potentially
+  stale and lean on whatever rows the previous tick left.
 
 ### Pre-summarized observations (cost-reduction-structural §A)
 Every observation arrives with `summary_text` (≤120 chars) and
@@ -127,7 +134,7 @@ This routine reads external state for context — it does not push back. While r
 - Create / update / delete calendar events.
 - Open / merge / comment on GitHub PRs or issues.
 
-External-source signals (`mail:*`, `notion:*`, `calendar:*`, `git:*`) reach you through `<observations>`. Consume them, route to `today.md` / `projects/*.md` / the `roadmap_candidate` queue per the Decision Framework below, but do **not** act back on the source system. Outbound writes against external services belong in the morning routine, evening review, or DM-reply paths — `routine.hourly_check` is a silent bookkeeping pass.
+External-source signals (`mail:*`, `notion:*`, `calendar:*`, `git:*`) reach you through `<observations>`. Consume them, route to `state/today.md` / `projects/*.md` / the `roadmap_candidate` queue per the Decision Framework below, but do **not** act back on the source system. Outbound writes against external services belong in the morning routine, evening review, or DM-reply paths — `routine.hourly_check` is a silent bookkeeping pass.
 
 This rule applies regardless of integration mode (direct, same-backend delegated, cross-backend delegated). It is owned by the routine, so a session whose `notion` / `mail` / `external-services` skill body was dropped under same-backend delegation (because the connector covers the surface) still inherits the constraint.
 
@@ -182,6 +189,11 @@ This rule applies regardless of integration mode (direct, same-backend delegated
 6. Skip noise: journal-only edits, trivial formatting, auto-generated churn,
    already-processed agent writes, deletion of auto-generated artifacts.
 7. Mark processed observations consumed via POST /api/observations/consume.
+   Shape: `{"ids":[<int>...],"correlationId":"<verbatim from <event_correlation_id>>"}`.
+   Both fields are required and camelCase — `correlation_id` snake_case is
+   rejected. `ids` must be integers (not strings). Copy `correlationId`
+   verbatim from the `<event_correlation_id>…</event_correlation_id>` tag
+   in this prompt; do not paste the angle-bracket placeholder.
 8. Urgency gate for POST /api/notify — the default is SILENCE. At most
    ONE call per run, and only after the dedup pre-check passes AND one
    of (a)(b)(c) holds with its concrete threshold:
@@ -192,7 +204,7 @@ This rule applies regardless of integration mode (direct, same-backend delegated
      last 4 hours.
    - The truncation marker `[...N earlier entries omitted ...]` appears
      in `<today>` and you cannot rule out a same-day prior notification
-     from the truncated view. In that case `GET /api/context/today`
+     from the truncated view. In that case `GET /api/context/state/today`
      once for the full log before deciding.
    - A matching pending `POST /api/schedule/dm` or Agent Plan row is
      already going to fire for this item within the next 2 hours
@@ -202,7 +214,7 @@ This rule applies regardless of integration mode (direct, same-backend delegated
    (a) Hard deadline ≤ 2 hours away that the agent surfaced **this
        hour** from new input (mail, DM, observation) AND the user has
        not yet acted on it. **Self-set deadlines, course assignments,
-       class times, and items already in `today.md` ## User Tasks do
+       class times, and items already in `state/today.md` ## User Tasks do
        NOT qualify** — they fail the awareness gate (see notify skill
        § Universal user-facing message discipline § Awareness gate).
        A 6-hour deadline is NOT urgent regardless.

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

@@ -71,7 +71,7 @@ Stay log-only when **all** these hold:
 
 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
+in medium-tier 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.