@aitne-sh/aitne 0.1.7 → 0.1.8

package/agent-assets/task-flows/message.received.dm.md

@@ -6,17 +6,9 @@ The user has sent <user_input> below. Respond to it, applying the steps in order
 
 ### Step 1 — Capture user info silently (before replying)
 
-Scan <user_input> for declarative user facts or imperative tone/style directives. If matched, persist in the **same turn** — silent (no acknowledgement to the user); do not defer to Evening Review (the message may be truncated by then).
+Apply the canonical capture-user-info routing below to `<user_input>`.
 
-**Imperative tone/style directives** ("always reply in English", "shorter please", "don't add emojis", "speak casually", "be more concise") are agent directives, NOT user facts → PATCH `/api/config/character` per the user-profile skill §"Tone / character preferences" (read-before-write, 1000-char cap). When ambiguous (e.g. "I prefer short replies"), default to character — never duplicate in profile.md.
-
-**Declarative facts about the user** → route through the user-profile skill. The skill owns the trigger shapes, the file split (`profile.md` vs `user/<topic>.md`), the read-before-write contract, the `section_not_found` → `append_to_file` first-write fallback, and the Learned-Context-vs-personal.md disambiguator. Key calls:
-
-- Top-level identity / platform / notification fact → `user/profile.md`.
-- Detail-heavy fact (specific person, workplace, hobby, tool, goal) → matching `user/<topic>.md` (`people` / `work` / `expertise` / `personal` / `goals`).
-- Self-reported behavioral pattern the agent should adapt to ("I'm not a morning person") → `user/profile.md ## Learned Context` with today's `[YYYY-MM-DD]` prefix.
-
-Never invent facts the user did not state. Never re-write a fact a paraphrase of which already exists in the target file.
+{include:_partials/capture-user-info.md}
 
 ### Step 2 — Profile-question reconcile / latent opportunity
 
@@ -50,7 +42,9 @@ Worked examples (illustrate the topic-continuing vs. topic-pivoting distinction;
 | "Feeling pretty drained today." | *(no trailing question — acknowledge the mood)* | *"What time should I remind you about the design review?"* (ignores the mood) |
 | "What's on today?" | *"Want a heads-up 15 min before the 2pm review?"* (continues the orientation) | *"Also — what city are you in these days?"* (latent-profile weave on a tight factual ask) |
 
-This rule covers the latent-profile-question weave in Step 2 and any future opportunistic ask. **When a gate would have asked here but this rule suppresses it, the gate SHOULD instead schedule a `confirm:` sub-flow row** (see `scheduled.dm.md` ## Confirmation follow-up) so the question lands at a natural moment without violating the thread.
+This rule covers the latent-profile-question weave in Step 2 and any future opportunistic ask. **When a gate would have asked here but this rule suppresses it, the gate SHOULD instead schedule a `confirm:` sub-flow row** (see `scheduled.dm.md` ## Confirmation follow-up) so the question lands at a natural moment without violating the thread. The dedup pre-check + `confirm_dedup_key` shape contract apply before scheduling — see the partial below.
+
+{include:_partials/confirm-subflow.md}
 
 **Day-type filter.** Parse line 2 of <today>. For any category whose focus is `off` (map via the today skill's "Category → focus-dimension mapping"), do not volunteer items in that category.
 
@@ -110,7 +104,7 @@ clock and lag). `<turn_context>` is present only on resumed turns; on a
 fresh turn the system-prompt `<current_time>` is already current and the
 snapshot is fresh.
 
-Refetch the live log when the user asks about recent activity — for example "what have you been up to", "did anything come in", "anything new since X", "ここ最近 / さっき / 直近 / ここ N 分 / 何かあった".
+Refetch the live log when the user asks about recent activity — for example "what have you been up to", "did anything come in", "anything new since X", "anything happen", "in the last N minutes".
 
 - Issue `GET /api/context/today` (the standard context-read endpoint).
 - Compare the live `## Agent Log` against what is in <today>.
@@ -149,7 +143,7 @@ detection" §"Reply branches", carrying the user's reply shape (yes /
 counter-proposal / no) into that handler. Apply the same pattern to
 any other gate that opts into the confirm sub-flow in the future.
 
-**Scheduling.** Recurring ("every morning at 9", "weekly") → `POST /api/recurring-schedules`. One-shot ("tomorrow 3pm", "in 30 min") → `POST /api/schedule/dm` (pre-composed; default) or `POST /api/schedule` (wake-up that must look something up at fire time). Edit / cancel / list use the same endpoints. Load the schedule skill for the request shape, dedup pre-check, DM-vs-wake decision, and description contract. Use `<current_time>` for timezone resolution.
+**Scheduling.** Recurring ("every hour", "every morning at 9", "weekly", "25th of each month") → `POST /api/recurring-schedules`. One-shot ("tomorrow 3pm", "in 30 min") → `POST /api/schedule/dm` (pre-composed; default) or `POST /api/schedule` (wake-up that must look something up at fire time). Edit / cancel / list use the same endpoints. Load the schedule skill for the request shape, dedup pre-check, DM-vs-wake decision, and description contract. Use `<current_time>` for timezone resolution. Prefer `tier` over `model`; the two are mutually exclusive on a single row.
 
 Schedules go through this daemon — never through any cloud-hosted scheduled-agent feature your CLI may expose. Cloud routines cannot reach `localhost:8321`, so they cannot deliver via the user's chat platforms or use any integration registered here. Do not propose one as a tradeoff.
 
@@ -163,9 +157,13 @@ Schedules go through this daemon — never through any cloud-hosted scheduled-ag
    - **Re-enable** → `PATCH /api/recurring-schedules/:id` `{"enabled": true}`.
 3. Confirm to the user in persona voice. Keep it short — never name internal mechanisms ("recurring schedule", "pin_to_quiet_hours_end", row IDs) in user-visible text.
 
-**Long-horizon intent** (commitment, trip, deliverable, learning target beyond today) → route through the roadmap skill's "Long-horizon DM-intent detection". Ambiguous or speculative items belong in `agent/journal.md` as a candidate line for the next morning routine to confirm — do **not** write directly to `roadmap.md` without a clear positive signal.
+**Long-horizon intent** (commitment, trip, deliverable, learning target beyond today) → apply the decision tree below; the `roadmap` skill is the writer. Ambiguous or speculative items belong in `agent/journal.md` as a candidate line for the next morning routine to confirm — do **not** write directly to `roadmap.md` without a clear positive signal.
+
+{include:_partials/dm-intent.long-horizon.md}
+
+**Project intent** (state, progress, milestone, blocker, or a new-project request for a named workstream) → apply the decision tree below; the `context` skill is the writer (PUT / PATCH / archive). A new project requires the project-creation gate before any write; the gate's "No match" path schedules a `confirm:` DM rather than asking inline (see Step 3 of the decision tree and `scheduled.dm.md` ## Confirmation follow-up). Silently inferring a slug is forbidden. A project update tied to a dated milestone runs both this dispatcher and the long-horizon one (see "Tie-breakers" inside the partial). Future durable-state domains (e.g. git) follow the same shape — per-domain partial, thin dispatcher here.
 
-**Project intent** (state, progress, milestone, blocker, or a new-project request for a named workstream) → route through the context skill's "Project DM-intent detection". A new project requires the project-creation gate before any write; the gate's "No match" path schedules a `confirm:` DM rather than asking inline (see the context skill Step 3 and `scheduled.dm.md` ## Confirmation follow-up). Silently inferring a slug is forbidden. A project update tied to a dated milestone runs both this dispatcher and the long-horizon one (see the context skill's "Tie-breakers"). Future durable-state domains (e.g. git) follow the same shape — per-domain skill block, thin dispatcher here.
+{include:_partials/dm-intent.project.md}
 
 ## User Message
 Platform: {event_data[platform]}

package/agent-assets/task-flows/message.received.dm_first.md

@@ -8,17 +8,9 @@ The behavior in this flow is identical to `message.received.dm.md` except for th
 
 ### Step 1 — Capture user info silently (before replying)
 
-Scan <user_input> for declarative user facts or imperative tone/style directives. If matched, persist in the **same turn** — silent (no acknowledgement to the user); do not defer to Evening Review.
+Apply the canonical capture-user-info routing below to `<user_input>`.
 
-**Imperative tone/style directives** ("always reply in English", "shorter please", "don't add emojis", "speak casually") are agent directives, NOT user facts → PATCH `/api/config/character` per the user-profile skill §"Tone / character preferences" (read-before-write, 1000-char cap). When ambiguous, default to character.
-
-**Declarative facts about the user** → route through the user-profile skill. The skill owns the trigger shapes, the file split (`profile.md` vs `user/<topic>.md`), the read-before-write contract, the `section_not_found` → `append_to_file` first-write fallback, and the Learned-Context-vs-personal.md disambiguator. Key calls:
-
-- Top-level identity / platform / notification fact → `user/profile.md`.
-- Detail-heavy fact (specific person, workplace, hobby, tool, goal) → matching `user/<topic>.md`.
-- Self-reported behavioral pattern the agent should adapt to → `user/profile.md ## Learned Context` with today's `[YYYY-MM-DD]` prefix.
-
-Never invent facts the user did not state. Never re-write a fact a paraphrase of which already exists in the target file.
+{include:_partials/capture-user-info.md}
 
 ### Step 2 — Profile-question reconcile / latent opportunity
 
@@ -36,7 +28,7 @@ The user must never feel they are filling out a profile.
 
 ### Step 3 — Compose the reply
 
-Apply the conversational profile's "speak as one agent" rule: phrase your knowledge as your own memory; never name internal storage, sections, files, or routines in user-visible text.
+Apply the conversational profile's "speak as one agent" rule: phrase your knowledge as your own memory; never name internal storage, sections, files, or routines in user-visible text. The user-facing message discipline (awareness, no ceremony, no readback, compactness) is owned by the notify skill.
 
 #### No topic-pivoting trailing question (universal, non-negotiable)
 
@@ -140,13 +132,17 @@ project?"* → user replies "yeah" → route through the context skill's
 "Project DM-intent detection" §"Reply branches" with branch=
 affirmative.
 
-**Scheduling.** Recurring ("every morning at 9", "weekly") → `POST /api/recurring-schedules`. One-shot ("tomorrow 3pm", "in 30 min") → `POST /api/schedule/dm` (pre-composed; default) or `POST /api/schedule` (wake-up). Edit / cancel / list use the same endpoints. Load the schedule skill for the request shape, dedup pre-check, and description contract. Use `<current_time>` for timezone resolution.
+**Scheduling.** Recurring ("every hour", "every morning at 9", "weekly", "25th of each month") → `POST /api/recurring-schedules`. One-shot ("tomorrow 3pm", "in 30 min") → `POST /api/schedule/dm` (pre-composed; default) or `POST /api/schedule` (wake-up). Edit / cancel / list use the same endpoints. Load the schedule skill for the request shape, dedup pre-check, and description contract. Use `<current_time>` for timezone resolution. Prefer `tier` over `model`; the two are mutually exclusive on a single row.
 
 Schedules go through this daemon — never through any cloud-hosted scheduled-agent feature your CLI may expose. Cloud routines cannot reach `localhost:8321`, so they cannot deliver via the user's chat platforms or use any integration registered here.
 
-**Long-horizon intent** (commitment, trip, deliverable, learning target beyond today) → route through the roadmap skill's "Long-horizon DM-intent detection". Ambiguous or speculative items belong in `agent/journal.md` as a candidate line for the next morning routine to confirm — do **not** write directly to `roadmap.md` without a clear positive signal.
+**Long-horizon intent** (commitment, trip, deliverable, learning target beyond today) → apply the decision tree below; the `roadmap` skill is the writer. Ambiguous or speculative items belong in `agent/journal.md` as a candidate line for the next morning routine to confirm — do **not** write directly to `roadmap.md` without a clear positive signal.
+
+{include:_partials/dm-intent.long-horizon.md}
+
+**Project intent** (state, progress, milestone, blocker, or a new-project request for a named workstream) → apply the decision tree below; the `context` skill is the writer. A new project requires the project-creation gate before any write; the gate's "No match" path schedules a `confirm:` DM rather than asking inline (see Step 3 of the decision tree and `scheduled.dm.md` ## Confirmation follow-up). Silently inferring a slug is forbidden. A project update tied to a dated milestone runs both this dispatcher and the long-horizon one (see "Tie-breakers" inside the partial).
 
-**Project intent** (state, progress, milestone, blocker, or a new-project request for a named workstream) → route through the context skill's "Project DM-intent detection". A new project requires the project-creation gate before any write; the gate's "No match" path schedules a `confirm:` DM rather than asking inline (see the context skill Step 3 and `scheduled.dm.md` ## Confirmation follow-up). Silently inferring a slug is forbidden. A project update tied to a dated milestone runs both this dispatcher and the long-horizon one (see the context skill's "Tie-breakers").
+{include:_partials/dm-intent.project.md}
 
 ## User Message
 Platform: {event_data[platform]}

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

@@ -18,7 +18,9 @@ it exists.
    either.
 4. For each action, use the same conventions as the other routines:
    - Scheduled actions → append to `today.md` `## Agent Plan` and
-     register a matching `POST /api/schedule` row.
+     register a matching `POST /api/schedule` row. Use `tier` for the
+     row's cost knob; check `GET /api/schedule/options` for the live
+     model list when a step needs to pin a specific model id.
    - User-visible findings → route through the `notify` skill only when
      truly urgent. Silent is the default.
    - Observations → consume via `observations` skill if the step pulls

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

@@ -15,8 +15,13 @@ 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 `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.
@@ -173,7 +138,7 @@ 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.
 
@@ -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
@@ -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`).

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

@@ -2,6 +2,14 @@
 
 ## 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 hourly recurring schedule path. Operators who want to
+register a custom hourly task should POST to
+`/api/recurring-schedules` with `recurrenceRule.frequency:"hourly"`
+(see the `schedule` skill's `references/recurring.md`); those rows
+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.
 The "Vault review context" block includes `context-index.md` and
@@ -69,11 +77,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 +90,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

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.

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

@@ -1,3 +1,45 @@
+<!--
+  STATUS: disabled by default (pre-release).
+
+  The scheduler cron and boot-time catchup in
+  `packages/daemon/src/{core/scheduler.ts,bootstrap/schedule-helpers.ts}`
+  consult `config.monthlyReviewEnabled` (default `false`) before
+  firing this routine. The task flow below is preserved verbatim as
+  the design-of-record but is not exercised at runtime until the kill
+  switch flips on.
+
+  Why disabled: the current routine reads ~30 daily files + 4-5 weekly
+  files + the agent journal to synthesise a user-facing snapshot whose
+  downstream leverage is unimplemented (`<previous_month>` injection
+  is documented as "未実装" in docs/design/06-memory.md §6.2.8 and
+  weekly-next-week-leverage.md §6 "Out of scope"). Cost lands near the
+  per-execute `max_budget_usd: 1.00` ceiling for an output that no
+  routine consumes downstream — the cost/value ratio is poor in the
+  current shape.
+
+  Re-enable path: Mirror+Prune redesign.
+    1. Drop the 30 × daily/*.md re-read (already aggregated in weekly).
+    2. Collapse Wins / Outstanding / Metrics / Risks / Reading sections
+       into two atomic outputs:
+         - Unit 1 — one trend observation, ≥3 weeks of evidence, 1 line.
+         - Unit 2 — aged carry-over decisions (drop/defer/do-now/
+           delegate/decide) on Carry Over entries that appeared ≥4
+           weeks in a row.
+    3. Add `previous-month-digest.ts` so the new-month day-1
+       morning_routine receives a `<previous_month>` block (analogous
+       to `previous-week-digest.ts`). Without this, monthly remains a
+       write-only snapshot.
+    4. Default Phase 4 notification to silent; only send when Unit 2
+       has at least one `decide` verb or Unit 1 contradicts a
+       user-stated commitment.
+    5. Drop the agent-internal `## Monthly YYYY-MM` block — weekly's
+       12-week journal already covers self-critique signal.
+
+  When the redesign ships, flip the default to `true` in
+  `packages/daemon/src/settings/runtime-settings.ts:monthlyReviewEnabled`
+  and re-introduce the docs under `agent-assets/docs/features/routines/`.
+-->
+
 {context}
 
 ## Task: Monthly Review
@@ -122,7 +164,7 @@ continue.
      reliability)
 
    ## Reading
-   - Completed this month: N — short list of "Title — Author (★rating)"
+   - Completed this month: N — short list of "Title — Author (rating: N/5)"
      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.
@@ -157,9 +199,9 @@ continue.
    ### 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]
+       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