@aitne/daemon 0.1.7 → 0.1.9

package/dist/core/routine-windows.js

@@ -1,16 +1,12 @@
 /**
  * Routine data-acquisition window catalog.
  *
- * ROUTINE_DATA_ACQUISITION_DESIGN.md §6.5 — declarative map keyed by
+ * docs/design/appendices/routine-data-acquisition.md §6.5 — declarative map keyed by
  * `(routine, window-symbol, integration, mode)` that the pre-pass
  * fetcher (`routine.fetch_window`) and its assembly helper (§6.4)
  * consult to build the `<acquisition-plan>` block.
  *
- * Phase 1 ships the catalog only. The dispatcher hooks that consume it
- * land in Phase 4; the partials that use the `WINDOW_QUERIES` strings
- * land in Phase 2.
- *
- * Design invariants preserved here:
+ * Design invariants:
  *
  *  - **No model IDs.** Routine windows describe *what to fetch*; tier
  *    binding for `routine.fetch_window` lives in
@@ -47,10 +43,21 @@ export const WINDOW_SYMBOLS = [
     // routine genuinely needs one of those, add the symbol back along
     // with the matching `ROUTINE_WINDOWS` row.
     "cal_next_24h_drift",
-    "cal_past_7d",
+    // `cal_iso_week_to_now` — weekly_review's calendar retrospective.
+    // Previously named `cal_past_7d` with rolling-7-day-ending-at-now
+    // semantics, which (a) silently included
+    // last week's Fri–Sun events that did not appear in any current-ISO-week
+    // daily/*.md file, forcing the agent to disambiguate, and (b) misaligned
+    // the direct-mode UTC `date+days` shape with the delegated/native
+    // `timeMin/timeMax` shape, dropping today's events in direct mode. The
+    // window is now anchored at the current ISO week's Monday 00:00 local
+    // (matching the calendar-date keying of `daily/YYYY-MM-DD.md`) and runs
+    // through `now`, so daily files and calendar retrospective cover the
+    // same set of days across all three modes.
+    "cal_iso_week_to_now",
     "imminent_2h",
-    // morning_routine's 7-day calendar fetch — A8 / Finding 5 (2026-05-13).
-    // ContextBuilder's `<calendar_events_7d>` covers `direct` mode inline,
+    // morning_routine's 7-day calendar fetch. ContextBuilder's
+    // `<calendar_events_7d>` covers `direct` mode inline,
     // but emits a "fetch yourself" directive for `delegated` / `native`
     // modes — which forces the main routine session (Sonnet) to drive the
     // MCP fan-out and burn medium-tier turns on a fetch the Haiku pre-pass
@@ -67,14 +74,14 @@ export const WINDOW_SYMBOLS = [
  * Kept narrow on purpose: only routines that need external data
  * acquisition appear here.
  *
- * `routine.morning_routine_initial` shares the morning plan because its
- * deep first-run prose still wants the same external context; the
- * dispatcher reuses the `morning_routine` plan via the alias below
- * rather than introducing a duplicate entry.
+ * `routine.morning_routine_initial` was retired by
+ * `docs/design/appendices/morning-routine-optimization.md`. Both the
+ * recurring and first-run branches now flow through
+ * `routine.morning_routine`; the daemon-prepared `<roadmap_skeleton>`
+ * block (not a window fetch) handles the first-run roadmap populate.
  */
 export const ROUTINE_WINDOW_KEYS = [
     "routine.morning_routine",
-    "routine.morning_routine_initial",
     "routine.today_refresh",
     "routine.hourly_check",
     "routine.evening_review",
@@ -112,8 +119,10 @@ export const ROUTINE_WINDOW_KEYS = [
  *    so no calendar row here. Mail `today_outcomes` is the "what did I
  *    send / reply today" retrospective signal.
  *  - `weekly_review`: ContextBuilder covers `<calendar_events_7d>`
- *    forward. The pre-pass adds the retrospective `cal_past_7d` so the
- *    weekly note has both directions.
+ *    forward. The pre-pass adds the retrospective `cal_iso_week_to_now`
+ *    so the weekly note has both directions, and the retrospective is
+ *    anchored at the same ISO-week boundary the `daily/*.md` archive
+ *    keys on (Monday 00:00 local through `now`).
  *  - `monthly_review`: ContextBuilder covers `<calendar_events_30d>`;
  *    monthly signals already flow through daily journals. The
  *    monthly review is summative — no pre-pass rows.
@@ -133,13 +142,8 @@ export const ROUTINE_WINDOWS = {
         { kind: "calendar", window: "cal_morning_7d", perAccount: false },
         { kind: "notion", window: "updated_24h", perAccount: false },
     ],
-    // morning_routine_initial reuses the same plan; the deep first-run
-    // prose lives in the routine task-flow body, not the acquisition layer.
-    "routine.morning_routine_initial": [
-        { kind: "mail", window: "inbox_today", perAccount: true },
-        { kind: "calendar", window: "cal_morning_7d", perAccount: false },
-        { kind: "notion", window: "updated_24h", perAccount: false },
-    ],
+    // `routine.morning_routine_initial` is retired — its plan was identical
+    // to `routine.morning_routine` above.
     "routine.today_refresh": [
         { kind: "calendar", window: "cal_next_24h_drift", perAccount: false },
     ],
@@ -152,7 +156,7 @@ export const ROUTINE_WINDOWS = {
         { kind: "mail", window: "today_outcomes", perAccount: true },
     ],
     "routine.weekly_review": [
-        { kind: "calendar", window: "cal_past_7d", perAccount: false },
+        { kind: "calendar", window: "cal_iso_week_to_now", perAccount: false },
     ],
     "routine.monthly_review": [],
 };
@@ -175,15 +179,15 @@ export const ROUTINE_WINDOWS = {
  *  - `{day_plus_2h}`     — `{now_iso}` + 2h
  *  - `{hour_start_iso}`  — current hour boundary
  *  - `{now_iso}`         — current instant
- *  - `{week_start_iso}`  — 7 days before `{day_start_iso}`
+ *  - `{iso_week_start_iso}` — current ISO week Monday 00:00 local in UTC
  *  - `{week_end_iso}`    — 7 days after `{day_start_iso}`
  *  - `{month_end_iso}`   — 30 days after `{day_start_iso}`
  *
  *  Date-only (`YYYY-MM-DD`) — used by `/api/calendar/events` and
  *  `/api/calendar/outlook/events`, which take `date=` + `days=`:
- *  - `{day_start_date}`  — agent-day start as `YYYY-MM-DD`
- *  - `{week_start_date}` — 7 days before agent-day start
- *  - `{now_date}`        — today's calendar date
+ *  - `{day_start_date}`     — agent-day start as `YYYY-MM-DD`
+ *  - `{iso_week_start_date}` — current ISO week Monday in local time
+ *  - `{now_date}`           — today's calendar date
  *
  * Missing-cell semantics: if `WINDOW_QUERIES[symbol]?.[integration]?
  * .[mode]` returns `undefined`, the acquisition-plan assembly helper
@@ -202,11 +206,35 @@ export const WINDOW_QUERIES = {
     // its default (today, no filter) and the routine read the wrong
     // window. The shapes below match the route handler's parsed query
     // params verbatim.
+    // Gmail noise filter (`-category:promotions -category:social`) is baked
+    // into every inbox-windowing query. Promotional and social-network
+    // emails account for the majority of unread volume in most accounts and
+    // are deterministic to identify (Gmail labels them server-side).
+    // Promotional payloads (Amazon promo with NBSP in the subject is a
+    // representative case) are exactly the kind of payload that's both
+    // (a) noise the user doesn't want triaged and (b) likely to carry
+    // shell-fragile Unicode whitespace. Filtering at the FETCH boundary
+    // means the agent never sees these messages at all: zero cost, zero
+    // chance of a Unicode-whitespace-bearing curl body, zero observations
+    // for the morning_routine / hourly_check skill to wade through.
+    //
+    // Sent-folder windows (today_outcomes) skip the filter — sent mail is
+    // the user's own writing, not promotional.
+    //
+    // Outlook has no equivalent server-side category — narrowing Outlook
+    // noise is a follow-up (subject/from denylist, Phase D).
+    //
+    // URL encoding: `&q=` value is space-encoded to `+` and `:` to `%3A`
+    // so the daemon's `c.req.query("q")` decoder reads the intended Gmail
+    // operator string. The MCP-shape (delegated / native) query passes
+    // through the partial verbatim into the agent's tool call; no URL
+    // encoding needed because the value is JSON-string-typed at the MCP
+    // boundary.
     inbox_today: {
         gmail: {
-            direct: "?since={day_start_iso}&limit=20",
-            delegated: 'q="newer_than:1d" maxResults=20',
-            native: 'q="newer_than:1d" maxResults=20',
+            direct: "?since={day_start_iso}&limit=20&q=-category%3Apromotions+-category%3Asocial",
+            delegated: 'q="newer_than:1d -category:promotions -category:social" maxResults=20',
+            native: 'q="newer_than:1d -category:promotions -category:social" maxResults=20',
         },
         outlook_mail: {
             direct: "?since={day_start_iso}&limit=20",
@@ -221,9 +249,9 @@ export const WINDOW_QUERIES = {
     },
     unread_last_hour: {
         gmail: {
-            direct: "?since={hour_start_iso}&unreadOnly=true&limit=10",
-            delegated: 'q="is:unread newer_than:1h" maxResults=10',
-            native: 'q="is:unread newer_than:1h" maxResults=10',
+            direct: "?since={hour_start_iso}&unreadOnly=true&limit=10&q=-category%3Apromotions+-category%3Asocial",
+            delegated: 'q="is:unread newer_than:1h -category:promotions -category:social" maxResults=10',
+            native: 'q="is:unread newer_than:1h -category:promotions -category:social" maxResults=10',
         },
         outlook_mail: {
             direct: "?since={hour_start_iso}&unreadOnly=true&limit=10",
@@ -256,7 +284,7 @@ export const WINDOW_QUERIES = {
     // ISO ranges.
     //
     // `cal_next_24h_drift` is intentionally NOT a server-side delta
-    // filter. ROUTINE_DATA_ACQUISITION_DESIGN.md §7.2 / B2 — the daemon
+    // filter. docs/design/appendices/routine-data-acquisition.md §7.2 / B2 — the daemon
     // does not track a per-routine "last sync" anchor today; using
     // `hour_start_iso` (or the equivalent `lastModifiedDateTime ge` on
     // Graph) lost any change that happened earlier in the today_refresh
@@ -278,16 +306,25 @@ export const WINDOW_QUERIES = {
             native: "startDateTime={now_iso}&endDateTime={day_plus_24h}",
         },
     },
-    cal_past_7d: {
+    // `cal_iso_week_to_now` — weekly_review retrospective spanning the
+    // current ISO week's Monday 00:00 local through `now`. Direct mode uses
+    // `timeMin`/`timeMax` on `/api/calendar/events` so the daemon REST
+    // path returns the same window the delegated/native MCP fan-out sees.
+    // Before the rename this row used a UTC `date+days=7` shape, which
+    // (a) silently dropped current-day events
+    // for non-UTC timezones (the window ended at today's UTC midnight, i.e.
+    // 09:00 JST) and (b) drifted away from the ISO week boundary that
+    // `daily/YYYY-MM-DD.md` is keyed on.
+    cal_iso_week_to_now: {
         google_calendar: {
-            direct: "?date={week_start_date}&days=7",
-            delegated: 'timeMin="{week_start_iso}" timeMax="{now_iso}" maxResults=100',
-            native: 'timeMin="{week_start_iso}" timeMax="{now_iso}" maxResults=100',
+            direct: "?timeMin={iso_week_start_iso}&timeMax={now_iso}",
+            delegated: 'timeMin="{iso_week_start_iso}" timeMax="{now_iso}" maxResults=100',
+            native: 'timeMin="{iso_week_start_iso}" timeMax="{now_iso}" maxResults=100',
         },
         outlook_calendar: {
-            direct: "?date={week_start_date}&days=7",
-            delegated: "startDateTime={week_start_iso}&endDateTime={now_iso}",
-            native: "startDateTime={week_start_iso}&endDateTime={now_iso}",
+            direct: "?timeMin={iso_week_start_iso}&timeMax={now_iso}",
+            delegated: "startDateTime={iso_week_start_iso}&endDateTime={now_iso}",
+            native: "startDateTime={iso_week_start_iso}&endDateTime={now_iso}",
         },
     },
     // A8 / Finding 5 — morning_routine 7-day calendar window.
@@ -369,9 +406,8 @@ export function routineHasWindows(key) {
 // (e.g. ContextBuilder.buildCalendarBlock) really wants to make is
 // "does the pre-pass own the window I'm about to emit," and that needs
 // a window-by-window match between ROUTINE_WINDOWS and the requested
-// days — `cal_past_7d` for weekly_review does NOT cover ContextBuilder's
+// days — `cal_iso_week_to_now` for weekly_review does NOT cover ContextBuilder's
 // future 7d block, so a coarse "has calendar row" predicate would be
 // the wrong abstraction. ContextBuilder's call-sites pass an explicit
 // `prepassCovers` flag instead, derived from local knowledge of
 // which window they are constructing.
-//# sourceMappingURL=routine-windows.js.map

package/dist/core/schedule-insert-helper.d.ts

@@ -43,4 +43,3 @@ export declare function shouldTriggerRoadmapRefresh(input: TriggerDecisionInput)
  * run without it.
  */
 export declare function maybeTriggerRoadmapRefresh(input: TriggerDecisionInput, triggerRoadmapRefresh: ((source: string) => void) | null | undefined, source: string): void;
-//# sourceMappingURL=schedule-insert-helper.d.ts.map

package/dist/core/schedule-insert-helper.js

@@ -49,4 +49,3 @@ export function maybeTriggerRoadmapRefresh(input, triggerRoadmapRefresh, source)
         logger.warn({ err, source }, "triggerRoadmapRefresh threw — continuing");
     }
 }
-//# sourceMappingURL=schedule-insert-helper.js.map

package/dist/core/schedule-maintenance.d.ts

@@ -19,4 +19,3 @@ export declare function discardStalePendingSchedules(db: Database.Database, curr
  */
 export declare function recoverOrphanedRunningSchedules(db: Database.Database, currentAgentDayStartUtc: string): OrphanedRunningRecoveryResult;
 export declare function hasActionInWindow(db: Database.Database, actionType: string, startUtc: string, endUtc: string): boolean;
-//# sourceMappingURL=schedule-maintenance.d.ts.map

package/dist/core/schedule-maintenance.js

@@ -54,4 +54,3 @@ export function hasActionInWindow(db, actionType, startUtc, endUtc) {
         .get(actionType, startUtc, endUtc);
     return !!row;
 }
-//# sourceMappingURL=schedule-maintenance.js.map

package/dist/core/scheduler.d.ts

@@ -2,6 +2,7 @@ import type Database from "better-sqlite3";
 import type { AgentConfig } from "../config.js";
 import type { EventBus } from "./event-bus.js";
 import type { MessageDelivery } from "../adapters/message-hub.js";
+import type { AgentEnabledCache } from "./agents/loader.js";
 /**
  * Build the cron expression that drives the hourly check.
  *
@@ -65,6 +66,26 @@ export declare function buildUserProfileSweepMorningCronExpr(dayBoundaryHour: nu
  * track the same config knob in lockstep.
  */
 export declare const USER_PROFILE_SWEEP_EVENING_CRON_EXPR = "50 17 * * *";
+/**
+ * Cron expression for the daemon-side roadmap mechanical maintenance
+ * pass: fixed at 17:45 local — 15 min before Evening Review's fixed
+ * 18:00 and 5 min before the evening user-profile sweep at 17:50.
+ * The ordering matters: this job must release its lock before the
+ * surviving evening_review Step 2 (Long-term Plans promotion + Review:
+ * fire) acquires `roadmap_write_lock`. See
+ * `docs/design/appendices/evening-review-slimdown.md` §2.2.
+ */
+export declare const ROADMAP_MAINTENANCE_CRON_EXPR = "45 17 * * *";
+/**
+ * Cron expression for the BROWSER_HISTORY_INTEGRATION_PLAN §5.F2 P4a
+ * pre-morning digest: 60 min before the day boundary, wrapping
+ * backward across midnight (so `dayBoundaryHour = 4` → "0 3 * * *",
+ * `dayBoundaryHour = 0` → "0 23 * * *"). Extracted as a pure helper
+ * so the wrap arithmetic — identical in shape to
+ * `buildUserProfileSweepMorningCronExpr` but at the top of the hour —
+ * is asserted without standing up node-cron in tests.
+ */
+export declare function buildBrowserHistoryPreMorningDigestCronExpr(dayBoundaryHour: number): string;
 /**
  * AgentScheduler — manages recurring cron jobs and the DB-driven ScheduleWatcher.
  *
@@ -112,6 +133,31 @@ export declare class AgentScheduler {
      * morning flow reads it. The observer owns the run-once guard.
      */
     private onContextIndexReconcile;
+    /**
+     * Evening-review slimdown §2.2 — daily mechanical roadmap.md
+     * maintenance pass at 17:45 local, 15 min before evening_review.
+     * Wraps `runRoadmapMechanicalMaintenance` so substeps 2a / 2b / 2d
+     * run in-process inside the daemon rather than inside a Sonnet
+     * routine that would otherwise re-derive the same date math. The
+     * callback is fire-and-forget (no return value contract): the
+     * implementation owns its own lock acquisition, audit emission, and
+     * agent/journal.md append.
+     */
+    private onRoadmapMaintenance;
+    /**
+     * BROWSER_HISTORY_INTEGRATION_PLAN §5.F2 P4a — pre-morning digest
+     * builder. Fires at `dayBoundaryHour − 1` local each night so the
+     * morning Stage B journal reads a static `context/browser/yesterday-<date>.md`
+     * file (pre-warmed) rather than calling `GET /api/browser-history/
+     * yesterday-summary` at 04:00. The callback is deterministic Node
+     * code (no LLM in the path); the scheduler treats it as
+     * fire-and-forget like the roadmap-maintenance and context-index
+     * callbacks above. A failure here logs but never cascades into the
+     * 04:00 morning routine — the journal task-flow has a documented
+     * fallback to the `/api/browser-history/pre-morning-digest/{date}`
+     * endpoint.
+     */
+    private onBrowserHistoryPreMorningDigest;
     /**
      * Setup gate — returns a skip reason when autonomous work should be
      * paused (initial setup incomplete, or setup conversation active).
@@ -122,26 +168,39 @@ export declare class AgentScheduler {
     private autonomousGate;
     private lastGateBlockLoggedAt;
     /**
-     * Aborted by `stop()` to interrupt the ScheduleWatcher's between-poll sleep
-     * immediately. Without this, SIGTERM has to wait up to
-     * `schedulePollIntervalSeconds` before the loop notices `this.shutdown`.
-     *
-     * Also aborted by `nudgeWatcher()` so a freshly-INSERTed `agent_schedule`
-     * row with `scheduled_for = now` (e.g. the post-setup morning-routine wake)
-     * is picked up on the next event-loop tick instead of waiting up to a
-     * full poll interval. `sleepInterruptible` replaces the controller after
-     * consuming an abort so subsequent sleeps start fresh.
+     * AGENT_DEFINITIONS_DESIGN.md §7.1 — per-built-in enabled gate. Wired from
+     * the Phase-7 boot path via {@link setAgentEnabledCache}; until then (and in
+     * tests that construct a bare scheduler) it is `null` and the gate is a
+     * no-op, so disabling is opt-in and never accidentally stops a routine.
      */
-    private pollAbort;
+    private agentEnabledCache;
     /**
-     * Pending-nudge flag — set by `nudgeWatcher()` and consumed at the top of
-     * `sleepInterruptible`. Covers the race where `nudgeWatcher()` fires
-     * between two sleeps (after the previous sleep's abort listener cleared
-     * the flag, but before the next sleep is entered). The AbortController
-     * alone cannot carry this signal across sleeps because a fresh controller
-     * is created per sleep.
+     * Single source of truth for the ScheduleWatcher's between-poll wake
+     * signaling, unifying what was previously a (pollAbort: AbortController
+     * + hasPendingNudge: boolean) pair (v4.14 audit, Task #3).
+     *
+     * Mechanics:
+     *   - `nudgeSeq` is monotonically incremented by every `nudgeWatcher()`
+     *     call (and `stop()` reuses it to break the sleep too).
+     *   - `observedSeq` is advanced when a nudge has been consumed —
+     *     either at the top of `sleepInterruptible` (between-sleep case)
+     *     or by the resolver path inside `nudgeWatcher()` / `stop()` when
+     *     they wake an in-flight sleep.
+     *   - `sleepWaiter` holds the resolver + timer for the currently-pending
+     *     sleep, if any. The ScheduleWatcher loop awaits sequentially, so
+     *     at most one waiter exists at a time.
+     *
+     * Why this replaces the AbortController pair: with a monotonic counter
+     * we cannot lose a nudge across a sleep boundary — a `nudgeWatcher()`
+     * call that arrives between two sleeps simply leaves `nudgeSeq >
+     * observedSeq`, and the next sleep entry consumes it. The two-stage
+     * (flag + signal) scheme was correct on paper but required readers to
+     * trace the precise synchronous ordering of three branches in
+     * `sleepInterruptible`; the counter compresses that to one branch.
      */
-    private hasPendingNudge;
+    private nudgeSeq;
+    private observedSeq;
+    private sleepWaiter;
     constructor(eventBus: EventBus, db: Database.Database, config: AgentConfig);
     /**
      * Register a callback that runs at the day boundary (4 AM) BEFORE
@@ -167,13 +226,87 @@ export declare class AgentScheduler {
      * and enqueue a reconcile via the observer's run-once guard.
      */
     setContextIndexReconcilerCallback(fn: () => void): void;
+    /**
+     * Register the daily roadmap mechanical maintenance callback. Called
+     * at 17:45 local; the callback is fire-and-forget — it owns its own
+     * lock acquisition, validation, audit emission, and journal append.
+     * Failures are logged but do NOT cascade into the 18:00
+     * evening_review.
+     */
+    setRoadmapMaintenanceCallback(fn: () => void): void;
+    /**
+     * Register the BROWSER_HISTORY_INTEGRATION_PLAN §5.F2 P4a
+     * pre-morning digest cron callback. Fires at `dayBoundaryHour − 1`
+     * local; the callback is fire-and-forget — it builds the digest
+     * from `browser_visits` / `browser_research_clusters` /
+     * `browser_pending_offers` and writes the markdown + JSON sidecar
+     * into the daemon-owned `context/browser/` directory. Failures
+     * inside the callback log but do not throw outward.
+     */
+    setBrowserHistoryPreMorningDigestCallback(fn: () => void): void;
     /**
      * Register the autonomous-work gate. Returning null allows autonomous work;
      * any non-null string is treated as a skip reason and surfaced in logs.
      */
     setAutonomousGate(fn: () => null | string): void;
+    /**
+     * Wire the live built-in enabled cache (AGENT_DEFINITIONS_DESIGN.md §7.1).
+     * The loader watcher + the `PATCH /api/agents/:slug` handler call
+     * `cache.invalidate()` so the next firing re-queries the DB.
+     */
+    setAgentEnabledCache(cache: AgentEnabledCache): void;
+    /**
+     * Per-built-in enabled gate (§7.1), checked BEFORE `autonomousGate()` in
+     * every built-in routine's cron callback. Returns `true` to proceed; on a
+     * disabled Agent returns `false` and records a throttled `agent.firing_blocked`
+     * audit row (one per agent-day, then `detail.suppressed_count++` — §12.3). It
+     * is placed AFTER each callback's runtime gates (monthly last-day, hourly
+     * interval, skill-curation cadence) so a per-minute hourly tick that is not a
+     * real firing never inflates the suppressed count. A `null` cache (unwired /
+     * tests) always proceeds.
+     */
+    private isAgentEnabledForFiring;
     /** Log gate blocks at most once every 5 minutes to avoid spam. */
     private logGateBlock;
+    /**
+     * In-process re-entrance mutex for the stall watchdog. The hourly cron
+     * fires the watchdog as a fire-and-forget promise; a slow `sendDm`
+     * (DM hub latency, owner channel reconnect) could overlap with the
+     * next hourly tick. Without serialization both invocations would pass
+     * the dedup-marker read (the marker isn't written until AFTER the DM
+     * succeeds, see below) and emit duplicate alerts. The mutex is
+     * process-local — fine, since a single scheduler instance is the only
+     * watchdog firing path.
+     */
+    private morningStallWatchdogRunning;
+    /**
+     * Watchdog for the silent-stall pattern documented in the v4.14 audit
+     * (CLAUDE.md "morning_routine wake stall"). When the morning routine
+     * never writes an `agent_actions.result='success'` row, the dedup
+     * inside `queueMorningRoutineWake` keeps the stuck wake row pinned in
+     * `pending`/`running` and the hourly-check pre-routine gate silently
+     * skips every subsequent autonomous tick. The user gets no morning
+     * brief, no evening review, no hourly check, and no error — the
+     * system is functionally dead until the wake row clears.
+     *
+     * Detection: oldest `task_type='wake'` row tied to
+     * `routine='morning_routine'` older than the configured threshold (see
+     * `readMorningRoutineStallThresholdMinutes`) with no matching
+     * `agent_actions.result='success'` row in the current agent-day window.
+     *
+     * Delivery & dedup: DM-then-mark, NOT mark-then-DM. A failed DM (DM
+     * hub error, missing owner channel) leaves the marker empty so the
+     * next hourly tick retries. Repeat alerts on a chronically-broken DM
+     * channel are accepted as the lesser evil vs. a silent miss. The
+     * `morningStallWatchdogRunning` mutex serialises overlapping
+     * invocations so a slow DM cannot produce duplicate alerts.
+     *
+     * Fire-and-forget: returns nothing, surfaces all failures via logger.
+     * The owner DM is best-effort — a sendDm failure logs and does NOT
+     * re-throw, so a missing or broken message hub cannot cascade into a
+     * cron-callback exception.
+     */
+    private checkMorningRoutineStall;
     start(): void;
     stop(): void;
     /**
@@ -183,15 +316,23 @@ export declare class AgentScheduler {
      *
      * Safe to call any time after `start()` (and a no-op before): the public
      * surface is idempotent — multiple rapid calls coalesce into a single
-     * extra wake at the next sleep boundary. The pending-nudge flag covers
-     * the race where this method is invoked between sleeps; `sleepInterruptible`
-     * consumes it at the top of the next sleep cycle.
+     * extra wake at the next sleep boundary. Between-sleep nudges land on
+     * the monotonic `nudgeSeq` counter and are consumed at the top of the
+     * next `sleepInterruptible`; in-flight nudges resolve the active
+     * waiter directly. Both paths advance `observedSeq` so a single nudge
+     * skips exactly one sleep, never two.
      *
      * Wired today from `queueMorningRoutineWake` (post-setup, post-Google-auth,
      * catchup); other `INSERT INTO agent_schedule` sites use future-dated rows
      * and do not need a nudge.
      */
     nudgeWatcher(): void;
+    /**
+     * Resolve and clear the active `sleepWaiter`, if any. Used by both
+     * `stop()` and `nudgeWatcher()` to break a running sleep. Safe to call
+     * when no waiter exists — it's a no-op.
+     */
+    private consumeWaiter;
     /** Hot-reload cron schedules (e.g. after dayBoundaryHour changes) */
     reloadCrons(): void;
     private stopCronJobs;
@@ -220,25 +361,27 @@ export declare class AgentScheduler {
      */
     private startScheduleWatcher;
     /**
-     * Sleep for `ms` milliseconds, but resolve early if `pollAbort` aborts.
-     * Used by the ScheduleWatcher between polls so `stop()` and
-     * `nudgeWatcher()` can interrupt it.
+     * Sleep for `ms` milliseconds, but resolve early when `stop()` or
+     * `nudgeWatcher()` fire. Used by the ScheduleWatcher between polls so
+     * shutdown / "wake now" signals interrupt the wait.
      *
-     * Resolution order:
+     * Resolution order (single linear sequence — no branch fan-out):
      *   1. `shutdown` → immediate resolve.
-     *   2. pending nudge flag (set by `nudgeWatcher()` while we were processing
-     *      the previous batch) → consume and immediate resolve.
-     *   3. existing controller already aborted (legacy `stop()` contract, plus
-     *      the in-flight `nudgeWatcher()` path where `onAbort` already
-     *      consumed the flag) → replace controller and immediate resolve so
-     *      the next sleep starts fresh.
-     *   4. otherwise wait for either the timer or a fresh abort.
+     *   2. `nudgeSeq > observedSeq` → consume + immediate resolve. Covers
+     *      every nudge that arrived while no sleep was active (before the
+     *      first sleep ever ran, or between two consecutive sleeps).
+     *   3. otherwise install a `sleepWaiter` with a setTimeout and wait;
+     *      the resolver is invoked either by the timer or by a subsequent
+     *      `stop()` / `nudgeWatcher()` via `consumeWaiter()`.
      *
-     * Controller lifecycle: a new `AbortController` is installed on entry to
-     * step 4 so a previous abort cannot make this sleep return instantly.
-     * `nudgeWatcher()` always sets `hasPendingNudge` BEFORE calling `abort()`
-     * — the synchronous order is what closes the race against this method
-     * reading `pollAbort` and installing listeners.
+     * Invariant: `observedSeq` only advances on consumption, so a `nudgeSeq`
+     * bump that arrives during the active sleep is observed by the caller
+     * (`nudgeWatcher`) which advances `observedSeq` AND resolves the waiter
+     * in the same synchronous block. A bump that arrives between sleeps is
+     * still visible (`nudgeSeq > observedSeq`) on the next entry and gets
+     * consumed there. The counter therefore cannot lose a nudge across the
+     * sleep boundary that the previous AbortController scheme had to guard
+     * against with a separate `hasPendingNudge` flag.
      */
     private sleepInterruptible;
     /**
@@ -253,4 +396,3 @@ export declare class AgentScheduler {
     /** Daily cleanup: expire sessions, run retention */
     private dailyCleanup;
 }
-//# sourceMappingURL=scheduler.d.ts.map