@aitne/daemon 0.1.10 → 0.1.11

package/dist/messaging/browser-task-mcp-notifier.d.ts

@@ -1,77 +1,19 @@
 /**
- * Browser-task MCP-side DM dispatcher — BROWSER_TASK_REDESIGN_PLAN.md §5.
+ * Browser-task MCP-side delivery bridge — BACKGROUND_TASK_RUNNER_DESIGN.md
+ * Phase 1.
  *
- * The browser-task sub-agent's `ask_user` and `finish` tools call out to
- * this surface to DM the originating channel:
- *
- *   - `notifyAskUser`  → "❓ Browser task <id> needs your input." with
- *                        the question + the screenshot attached inline.
- *   - `notifyFinish`   → the agent's markdown report + the ordered list
- *                        of screenshots (attached inline) the user should
- *                        review.
- *
- * Distinct from the runner-side `BrowserTaskNotifier` (queued / terminal
- * structural DMs):
- *
- *   - The runner-side notifier covers events the sub-agent never sees
- *     (the slot manager queued the task, the SDK loop crashed before any
- *     tool fired, etc.). Plain templated bodies.
- *   - This MCP-side notifier carries agent-authored prose — the
- *     `question` / `report` strings come from the sub-agent.
- *
- * The two cannot collapse into one because:
- *   - The SDK tool body needs synchronous access to a notifier (it's
- *     invoked inside `mcp__aitne-browser__ask_user`'s handler); the
- *     runner-side notifier is invoked from the runner's lifecycle hooks.
- *   - The agent-authored vs. structural split keeps the redaction-
- *     coverage guard happy: structural bodies are templated text that
- *     the guard knows is safe; agent bodies pass the same redaction
- *     pipeline already applied to other LLM-authored outbound text.
- *
- * Best-effort delivery: DM failures log + continue. The DB row for the
- * task / clarification has already been written by the tool handler, so
- * a DM hiccup does NOT block the parent task — the dashboard surfaces
- * the row regardless. (See §5 ask_user "Resume — Deadline enforcement"
- * for the deadline-driven fallback when the user never sees the DM.)
- *
- * No capability-symbol gate here. The structural anti-spoofing surface
- * (B-4 purchase confirms + lite-final-confirm tokens) protects DM bodies
- * that the agent could otherwise mint to itself; `ask_user` / `finish`
- * bodies are intentionally agent-authored — the user is reading the
- * agent's question / report. The only header marker we attach is for the
- * user's benefit, not for adapter-side trust gating.
+ * The browser-task sub-agent still writes clarifications/reports through
+ * its `ask_user` and `finish` tools, but this bridge no longer sends a
+ * templated DM directly. It enqueues a `task.delivery` event instead; the
+ * dispatcher acquires the owner-DM gates, chooses active vs idle delivery,
+ * records the sent assistant message into conversation history, and marks
+ * the row delivered for recovery.
  */
-import { type MessageHub } from "../adapters/message-hub.js";
-import { type IngestOutboundImage } from "./browser-task-screenshot-attachment.js";
+import type { EventBus } from "../core/event-bus.js";
+import type Database from "better-sqlite3";
 import type { BrowserTaskMcpNotifier } from "../services/browser-history/automation/browser-task-tools/server.js";
-/** Header line for ask_user DMs. Chosen so it does NOT collide with the
- *  B-4 / lite-final-confirm markers (which carry the literal substring
- *  "confirmation") nor with the runner's `🕒` / `🟦` queue / terminal
- *  emojis. */
-export declare const ASK_USER_HEADER = "Browser task \u2014 needs your input";
-/** Header line for finish DMs. */
-export declare const FINISH_HEADER = "Browser task \u2014 report";
 export interface CreateBrowserTaskMcpNotifierDeps {
-    messageHub: MessageHub;
-    /** Daemon data directory (`PA_DATA_DIR`). Required to resolve a
-     *  screenshotKey (`/api/browser-task/<id>/screenshots/<file>`) back to
-     *  its on-disk location under
-     *  `<paDataDir>/automation-traces/<id>/<file>` so the bytes can be
-     *  uploaded through the messaging adapter / ingested for the dashboard.
-     *  When omitted, every screenshot resolves to an "unavailable" note. */
-    paDataDir?: string;
-    /** Ingest a resolved trace-store screenshot into the chat
-     *  `AttachmentStore` and return a store-backed `OutboundAttachmentRef`
-     *  (or null on failure). Used for the `dashboard` platform ONLY: the
-     *  dashboard fetches attachments by id through the authenticated
-     *  same-origin `/api/chat/attachments/:id` proxy, so a loopback trace
-     *  URL embedded as markdown would 401 (the bearer token is never
-     *  attached to a raw `<img>` request). Minting a real store id lets the
-     *  dashboard render the bytes inline like any other agent attachment —
-     *  never a URL. Messaging adapters take the trace file directly via
-     *  their native upload API, so they do NOT go through this. Optional:
-     *  when omitted, dashboard screenshots resolve to an "unavailable"
-     *  note. */
-    ingestOutboundImage?: IngestOutboundImage;
+    eventBus: EventBus;
+    db: Database.Database;
 }
 export declare function createBrowserTaskMcpNotifier(deps: CreateBrowserTaskMcpNotifierDeps): BrowserTaskMcpNotifier;

package/dist/messaging/browser-task-mcp-notifier.js

@@ -1,164 +1,43 @@
 /**
- * Browser-task MCP-side DM dispatcher — BROWSER_TASK_REDESIGN_PLAN.md §5.
+ * Browser-task MCP-side delivery bridge — BACKGROUND_TASK_RUNNER_DESIGN.md
+ * Phase 1.
  *
- * The browser-task sub-agent's `ask_user` and `finish` tools call out to
- * this surface to DM the originating channel:
- *
- *   - `notifyAskUser`  → "❓ Browser task <id> needs your input." with
- *                        the question + the screenshot attached inline.
- *   - `notifyFinish`   → the agent's markdown report + the ordered list
- *                        of screenshots (attached inline) the user should
- *                        review.
- *
- * Distinct from the runner-side `BrowserTaskNotifier` (queued / terminal
- * structural DMs):
- *
- *   - The runner-side notifier covers events the sub-agent never sees
- *     (the slot manager queued the task, the SDK loop crashed before any
- *     tool fired, etc.). Plain templated bodies.
- *   - This MCP-side notifier carries agent-authored prose — the
- *     `question` / `report` strings come from the sub-agent.
- *
- * The two cannot collapse into one because:
- *   - The SDK tool body needs synchronous access to a notifier (it's
- *     invoked inside `mcp__aitne-browser__ask_user`'s handler); the
- *     runner-side notifier is invoked from the runner's lifecycle hooks.
- *   - The agent-authored vs. structural split keeps the redaction-
- *     coverage guard happy: structural bodies are templated text that
- *     the guard knows is safe; agent bodies pass the same redaction
- *     pipeline already applied to other LLM-authored outbound text.
- *
- * Best-effort delivery: DM failures log + continue. The DB row for the
- * task / clarification has already been written by the tool handler, so
- * a DM hiccup does NOT block the parent task — the dashboard surfaces
- * the row regardless. (See §5 ask_user "Resume — Deadline enforcement"
- * for the deadline-driven fallback when the user never sees the DM.)
- *
- * No capability-symbol gate here. The structural anti-spoofing surface
- * (B-4 purchase confirms + lite-final-confirm tokens) protects DM bodies
- * that the agent could otherwise mint to itself; `ask_user` / `finish`
- * bodies are intentionally agent-authored — the user is reading the
- * agent's question / report. The only header marker we attach is for the
- * user's benefit, not for adapter-side trust gating.
+ * The browser-task sub-agent still writes clarifications/reports through
+ * its `ask_user` and `finish` tools, but this bridge no longer sends a
+ * templated DM directly. It enqueues a `task.delivery` event instead; the
+ * dispatcher acquires the owner-DM gates, chooses active vs idle delivery,
+ * records the sent assistant message into conversation history, and marks
+ * the row delivered for recovery.
  */
+import { createBrowserTaskClarificationDeliveryEvent, createBrowserTaskResultDeliveryEvent, } from "../core/dispatcher-task-delivery.js";
+import { getBrowserTask } from "../db/browser-task-store.js";
 import { createLogger } from "../logging.js";
-import { MessageDeliveryError, } from "../adapters/message-hub.js";
-import { parseChannelRef } from "../db/browser-automation-purchase-primary-channels-store.js";
-import { resolveScreenshotAttachment, } from "./browser-task-screenshot-attachment.js";
 const logger = createLogger("browser-task-mcp-notifier");
-/** Header line for ask_user DMs. Chosen so it does NOT collide with the
- *  B-4 / lite-final-confirm markers (which carry the literal substring
- *  "confirmation") nor with the runner's `🕒` / `🟦` queue / terminal
- *  emojis. */
-export const ASK_USER_HEADER = "Browser task — needs your input";
-/** Header line for finish DMs. */
-export const FINISH_HEADER = "Browser task — report";
-/** Soft cap on the `finish` report body inside the DM. The agent's tool
- *  schema already caps `report` at 8 KB; some adapters (Telegram) cap
- *  individual messages at ~4 KB. We truncate at 3 800 chars to leave
- *  comfortable room for headers + screenshot links and append a "[…]"
- *  marker so the user can tell the report was cropped.
- *  The Aitne dashboard's per-task detail page renders the full report
- *  via `GET /api/browser-task/:id`, so truncation is purely a DM-side
- *  ergonomic. */
-const FINISH_REPORT_DM_BODY_CAP = 3_800;
-/** Max screenshots attached to a single finish DM. The full ordered list
- *  is preserved in the row's `report` field; this cap just keeps the DM
- *  from ballooning with attachments. */
-const FINISH_DM_SCREENSHOT_LINK_CAP = 8;
 export function createBrowserTaskMcpNotifier(deps) {
-    const paDataDir = deps.paDataDir ?? null;
-    /** Per-channel delivery. Both surfaces receive the screenshot as actual
-     *  image bytes — never a URL:
-     *
-     *   - `dashboard`: each key is ingested into the chat `AttachmentStore`
-     *     and delivered as an `OutboundAttachmentRef`; the dashboard renders
-     *     it inline by fetching `/api/chat/attachments/:id` through its
-     *     authenticated same-origin proxy.
-     *   - messaging adapters (WhatsApp / Telegram / Slack / Discord): each
-     *     key is handed to the adapter as a trace-file `OutboundAttachmentRef`
-     *     so the adapter uploads the bytes via its native API.
-     *
-     *  Any key that cannot be resolved (file dropped by §14.7 retention,
-     *  ingest unavailable, unknown extension) is replaced by a single
-     *  "unavailable" note rather than an unreachable link. The dashboard's
-     *  `/browser-tasks/<id>` page remains the canonical full-trace view. */
-    async function dispatch(ref, head, tail, screenshotKeys) {
-        const parsed = parseChannelRef(ref);
-        if (!parsed) {
-            logger.warn({ ref }, "browser-task MCP notifier: unparseable channel ref — DM skipped");
-            return;
-        }
-        const headLines = head.filter((s) => s !== null);
-        const tailLines = tail.filter((s) => s !== null);
-        const resolved = (await Promise.all(screenshotKeys.map((key) => resolveScreenshotAttachment({
-            platform: parsed.platform,
-            key,
-            paDataDir,
-            ingestOutboundImage: deps.ingestOutboundImage,
-        })))).filter((a) => a !== null);
-        const unresolved = screenshotKeys.length - resolved.length;
-        const noteBlock = unresolved > 0
-            ? [
-                "",
-                `(${unresolved} screenshot${unresolved === 1 ? "" : "s"} could not be attached — open the browser-task detail page)`,
-            ]
-            : [];
-        const body = [...headLines, ...noteBlock, ...tailLines].join("\n");
-        const attachments = resolved.length > 0 ? resolved : undefined;
-        try {
-            await deps.messageHub.sendToPlatform(parsed.platform, parsed.channelId, body, undefined, attachments);
-        }
-        catch (err) {
-            const reason = err instanceof MessageDeliveryError
-                ? err.message
-                : err instanceof Error
-                    ? err.message
-                    : String(err);
-            logger.warn({ ref, reason }, "browser-task MCP notifier: DM dispatch failed (continuing)");
-        }
+    function titleFor(taskId) {
+        return getBrowserTask(deps.db, taskId)?.description ?? `Browser task ${taskId}`;
     }
     async function notifyAskUser(input) {
-        if (!input.originatingChannel) {
-            logger.warn({
-                taskId: input.taskId,
-                clarificationId: input.clarificationId,
-            }, "ask_user: no originating channel persisted — DM skipped (clarification row still written)");
-            return;
-        }
-        const screenshotKeys = input.screenshotKey ? [input.screenshotKey] : [];
-        const head = [
-            `❓ ${ASK_USER_HEADER}`,
-            `Task: ${input.taskId}`,
-            `Question: ${input.question}`,
-            `Context: ${input.contextSummary}`,
-        ];
-        const tail = [
-            ``,
-            `Reply in this DM to answer (clarification id: ${input.clarificationId}).`,
-        ];
-        await dispatch(input.originatingChannel, head, tail, screenshotKeys);
+        await deps.eventBus.put(createBrowserTaskClarificationDeliveryEvent({
+            taskId: input.taskId,
+            originatingChannel: input.originatingChannel,
+            title: titleFor(input.taskId),
+            clarificationId: input.clarificationId,
+            question: input.question,
+            contextSummary: input.contextSummary,
+            screenshotKey: input.screenshotKey,
+        }));
+        logger.debug({ taskId: input.taskId, clarificationId: input.clarificationId }, "browser-task clarification queued for task.delivery");
     }
     async function notifyFinish(input) {
-        if (!input.originatingChannel) {
-            logger.warn({ taskId: input.taskId }, "finish: no originating channel persisted — DM skipped (report still stored on the row)");
-            return;
-        }
-        const reportBody = input.report.length > FINISH_REPORT_DM_BODY_CAP
-            ? `${input.report.slice(0, FINISH_REPORT_DM_BODY_CAP)}\n\n[… truncated; open the dashboard for the full report]`
-            : input.report;
-        const keyBudget = input.screenshotKeys.slice(0, FINISH_DM_SCREENSHOT_LINK_CAP);
-        const overflowCount = Math.max(0, input.screenshotKeys.length - keyBudget.length);
-        const head = [
-            `✅ ${FINISH_HEADER}`,
-            `Task: ${input.taskId}`,
-            ``,
-            reportBody,
-        ];
-        const tail = overflowCount > 0
-            ? [``, `(+${overflowCount} more — see dashboard)`]
-            : [];
-        await dispatch(input.originatingChannel, head, tail, keyBudget);
+        await deps.eventBus.put(createBrowserTaskResultDeliveryEvent({
+            taskId: input.taskId,
+            originatingChannel: input.originatingChannel,
+            title: titleFor(input.taskId),
+            report: input.report,
+            screenshotKeys: input.screenshotKeys,
+        }));
+        logger.debug({ taskId: input.taskId }, "browser-task report queued for task.delivery");
     }
     return { notifyAskUser, notifyFinish };
 }

package/dist/messaging/browser-task-screenshot-attachment.d.ts

@@ -60,3 +60,18 @@ export declare function resolveScreenshotAttachment(params: {
     paDataDir: string | null;
     ingestOutboundImage?: IngestOutboundImage;
 }): Promise<OutboundAttachmentRef | null>;
+/**
+ * Resolve a worker-produced output FILE (absolute path) to a
+ * platform-appropriate outbound attachment — the generic-asset sibling of
+ * `resolveScreenshotAttachment` (BACKGROUND_TASK_RUNNER_DESIGN.md Phase 1 —
+ * delivery assets). Messaging adapters take the file path directly; the
+ * dashboard ingests it into the `AttachmentStore` so it renders inline.
+ * Returns null when the file is missing on disk or the dashboard ingest
+ * hook is unavailable — the caller omits it rather than sending a dead link.
+ */
+export declare function buildPathAttachment(params: {
+    platform: string;
+    absPath: string;
+    filename: string;
+    ingestOutboundImage?: IngestOutboundImage;
+}): Promise<OutboundAttachmentRef | null>;

package/dist/messaging/browser-task-screenshot-attachment.js

@@ -113,3 +113,66 @@ export async function resolveScreenshotAttachment(params) {
         ? buildStoreAttachment(params.paDataDir, params.ingestOutboundImage, params.key)
         : buildTraceAttachment(params.paDataDir, params.key);
 }
+/** MIME by extension for generic worker-produced deliverables (PDF / slides
+ *  / docs / images). Superset of the screenshot image map. Unknown
+ *  extensions fall back to `application/octet-stream` so the adapter still
+ *  uploads the bytes. */
+const DELIVERABLE_MIME_BY_EXT = {
+    ...IMAGE_MIME_BY_EXT,
+    gif: "image/gif",
+    pdf: "application/pdf",
+    pptx: "application/vnd.openxmlformats-officedocument.presentationml.presentation",
+    ppt: "application/vnd.ms-powerpoint",
+    docx: "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
+    doc: "application/msword",
+    xlsx: "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet",
+    csv: "text/csv",
+    txt: "text/plain",
+    md: "text/markdown",
+};
+function mimeForFilename(filename) {
+    const ext = filename.slice(filename.lastIndexOf(".") + 1).toLowerCase();
+    return DELIVERABLE_MIME_BY_EXT[ext] ?? "application/octet-stream";
+}
+/**
+ * Resolve a worker-produced output FILE (absolute path) to a
+ * platform-appropriate outbound attachment — the generic-asset sibling of
+ * `resolveScreenshotAttachment` (BACKGROUND_TASK_RUNNER_DESIGN.md Phase 1 —
+ * delivery assets). Messaging adapters take the file path directly; the
+ * dashboard ingests it into the `AttachmentStore` so it renders inline.
+ * Returns null when the file is missing on disk or the dashboard ingest
+ * hook is unavailable — the caller omits it rather than sending a dead link.
+ */
+export async function buildPathAttachment(params) {
+    const mimeType = mimeForFilename(params.filename);
+    if (params.platform === "dashboard") {
+        if (!params.ingestOutboundImage)
+            return null;
+        try {
+            return await params.ingestOutboundImage({
+                absPath: params.absPath,
+                mimeType,
+                originalFilename: params.filename,
+            });
+        }
+        catch (err) {
+            logger.warn({ absPath: params.absPath, err: toErrMsg(err) }, "deliverable asset: dashboard ingest failed");
+            return null;
+        }
+    }
+    let sizeBytes;
+    try {
+        sizeBytes = (await stat(params.absPath)).size;
+    }
+    catch (err) {
+        logger.warn({ absPath: params.absPath, err: toErrMsg(err) }, "deliverable asset: file missing — omitted");
+        return null;
+    }
+    return {
+        id: params.absPath,
+        path: params.absPath,
+        originalFilename: params.filename,
+        mimeType,
+        sizeBytes,
+    };
+}

package/dist/observers/delegated-sync-worker.d.ts

@@ -43,7 +43,7 @@ interface DelegatedSyncRuntimeConfig {
     /**
      * Shared active-hours window applied to every cadence. Local-time hours
      * in the daemon's `timezone`; `[startHour, endHour)`. When unset, defaults
-     * to `[4, 24)` to mirror the Hourly Check window.
+     * to `[4, 24)` to mirror the Activity Scan window.
      */
     activeStartHour?: number;
     activeEndHour?: number;
@@ -287,11 +287,11 @@ export declare class DelegatedSyncWorker implements Observer {
      * Native rows are skipped by `backendForCadence` returning null — their
      * observations come from the in-turn `routine.fetch_window` pre-pass
      * instead, see `docs/design/appendices/native-integration-mode.md`
-     * §"Polling, observers, and the hourly-check threshold".
+     * §"Polling, observers, and the activity-scan threshold".
      *
      * Why this exists: when every cadence is disabled (the post-Phase-9
      * default), Gmail / Notion observations would otherwise dry up entirely
-     * — the delegated `routine.hourly_check` task flow's Step 0a / 0c rely
+     * — the delegated `routine.activity_scan` task flow's Step 0a / 0c rely
      * on `mail:lifecycle` / `notion:<db>` rows the worker writes server-
      * side, and the agent prompt is explicitly told NOT to call the
      * gmail / notion `/reconcile` route directly (would poison the worker's
@@ -300,7 +300,7 @@ export declare class DelegatedSyncWorker implements Observer {
      * opted into a per-cadence schedule.
      *
      * Active-hours are NOT consulted: this method runs only because the
-     * hourly check itself fired, which already passed `hourlyCheckActive*`
+     * activity scan itself fired, which already passed `activityScanActive*`
      * gating. The cadence-side `activeStartHour` / `activeEndHour` window
      * applies only to the worker's own 60 s tick.
      *
@@ -313,7 +313,7 @@ export declare class DelegatedSyncWorker implements Observer {
      * circuit-breaker) and surfaced through the next `getStatus()` snapshot;
      * this method does not throw.
      */
-    runDisabledCadencesForHourlyCheck(): Promise<void>;
+    runDisabledCadencesForActivityScan(): Promise<void>;
     /**
      * Run a single cadence on demand (dashboard "Run Now" button). Bypasses
      * `cadenceEnabled`, `cadenceDue`, and active-hours gating — the user
@@ -410,7 +410,7 @@ export declare function resolveActiveHours(runtimeConfig: DelegatedSyncRuntimeCo
 /**
  * `true` when `now` falls inside `[startHour, endHour)` in the daemon's
  * configured timezone. `endHour=24` is exclusive — i.e. covers up to
- * 23:59:59. Mirrors the semantics of Hourly Check's window so an operator
+ * 23:59:59. Mirrors the semantics of Activity Scan's window so an operator
  * who already understands one understands the other.
  */
 export declare function isWithinActiveHours(now: Date, timezone: string | undefined, activeHours: DelegatedSyncActiveHours): boolean;

package/dist/observers/delegated-sync-worker.js

@@ -15,7 +15,7 @@ const CIRCUIT_FAILURE_THRESHOLD = 5;
 const CIRCUIT_BACKOFF_MULTIPLIER = 4;
 /**
  * Default active-hours window for delegated-sync cadences. Mirrors Hourly
- * Check defaults (`hourlyCheckActiveStartHour=4`, `hourlyCheckActiveEndHour=24`)
+ * Check defaults (`activityScanActiveStartHour=4`, `activityScanActiveEndHour=24`)
  * so the two schedules align unless an operator overrides one or the other.
  * See `docs/design/appendices/delegated-sync-opt-in.md`.
  *
@@ -126,7 +126,7 @@ const CALENDAR_24H_CADENCE = {
  *   - Window is the last 7 days. Reconcile keys by `(integration,
  *     window_key)` so the partition is wide enough that a recent thread
  *     with a fresh reply doesn't drop out and falsely emit `deleted`. The
- *     LLM hourly check still post-filters to "last hour" inside its own
+ *     LLM activity scan still post-filters to "last hour" inside its own
  *     decision flow; this cadence's job is structural diff, not selection.
  *   - `query="newer_than:7d"` Gmail search operator. `pageSize` /
  *     `max_results` / `maxResults` differs by backend (Claude / Codex /
@@ -136,7 +136,7 @@ const GMAIL_INBOX_7D_CADENCE = {
     integration: "gmail",
     windowKey: "inbox:7d",
     displayName: "Gmail — inbox (last 7 days)",
-    description: "Polls thread-level changes in the last 7 days of inbox. Surfaces new threads and replies for the hourly check.",
+    description: "Polls thread-level changes in the last 7 days of inbox. Surfaces new threads and replies for the activity scan.",
     defaultIntervalSeconds: 30 * 60,
     softFloorSeconds: 15 * 60,
     maxResults: 25,
@@ -159,7 +159,7 @@ const GMAIL_INBOX_7D_CADENCE = {
  *     and lets reconcile + the per-page `lastEditedTime` payload + the
  *     Notion normalizer's `inWindow` predicate sort out true churn.
  *   - The window's `created_date_range.start_date` arg is per the same
- *     date format the hourly_check prompt uses (`YYYY-MM-DD`), to mirror
+ *     date format the activity_scan prompt uses (`YYYY-MM-DD`), to mirror
  *     what the LLM-driven path was already producing — connectors uniformly
  *     accept that.
  */
@@ -387,11 +387,11 @@ export class DelegatedSyncWorker {
      * Native rows are skipped by `backendForCadence` returning null — their
      * observations come from the in-turn `routine.fetch_window` pre-pass
      * instead, see `docs/design/appendices/native-integration-mode.md`
-     * §"Polling, observers, and the hourly-check threshold".
+     * §"Polling, observers, and the activity-scan threshold".
      *
      * Why this exists: when every cadence is disabled (the post-Phase-9
      * default), Gmail / Notion observations would otherwise dry up entirely
-     * — the delegated `routine.hourly_check` task flow's Step 0a / 0c rely
+     * — the delegated `routine.activity_scan` task flow's Step 0a / 0c rely
      * on `mail:lifecycle` / `notion:<db>` rows the worker writes server-
      * side, and the agent prompt is explicitly told NOT to call the
      * gmail / notion `/reconcile` route directly (would poison the worker's
@@ -400,7 +400,7 @@ export class DelegatedSyncWorker {
      * opted into a per-cadence schedule.
      *
      * Active-hours are NOT consulted: this method runs only because the
-     * hourly check itself fired, which already passed `hourlyCheckActive*`
+     * activity scan itself fired, which already passed `activityScanActive*`
      * gating. The cadence-side `activeStartHour` / `activeEndHour` window
      * applies only to the worker's own 60 s tick.
      *
@@ -413,9 +413,9 @@ export class DelegatedSyncWorker {
      * circuit-breaker) and surfaced through the next `getStatus()` snapshot;
      * this method does not throw.
      */
-    async runDisabledCadencesForHourlyCheck() {
+    async runDisabledCadencesForActivityScan() {
         if (this.tickRunning) {
-            logger.debug("Skipping hourly-check delegated refresh — worker tick already in flight");
+            logger.debug("Skipping activity-scan delegated refresh — worker tick already in flight");
             return;
         }
         this.tickRunning = true;
@@ -923,7 +923,7 @@ export function resolveActiveHours(runtimeConfig) {
 /**
  * `true` when `now` falls inside `[startHour, endHour)` in the daemon's
  * configured timezone. `endHour=24` is exclusive — i.e. covers up to
- * 23:59:59. Mirrors the semantics of Hourly Check's window so an operator
+ * 23:59:59. Mirrors the semantics of Activity Scan's window so an operator
  * who already understands one understands the other.
  */
 export function isWithinActiveHours(now, timezone, activeHours) {

package/dist/observers/git-delegated-cron.d.ts

@@ -11,7 +11,7 @@ interface GitDelegatedCronOptions {
     githubRepos: readonly string[];
     cadenceSeconds: number;
     pushOverdueMinutes: number;
-    hourlyCheckEnabled?: boolean;
+    activityScanEnabled?: boolean;
     now?: () => Date;
 }
 export declare function hasActiveDelegatedGitLifecycleIntegration(db: Database.Database, override?: {

package/dist/observers/git-delegated-cron.js

@@ -81,10 +81,10 @@ export class GitDelegatedCronObserver {
         this.timer.unref?.();
     }
     initialDelaySeconds() {
-        // Keep 1h delegated Git checks away from routine.hourly_check. This is
+        // Keep 1h delegated Git checks away from routine.activity_scan. This is
         // the collision-avoidance rule from the Git lifecycle design: no session
         // reuse, just a 30-minute offset to avoid light-tier concurrency spikes.
-        if (this.options.hourlyCheckEnabled && this.cadenceSeconds === 3600) {
+        if (this.options.activityScanEnabled && this.cadenceSeconds === 3600) {
             return 30 * 60;
         }
         return this.cadenceSeconds;

package/dist/observers/github-poller-classifier.d.ts

@@ -48,7 +48,7 @@ export type Classification = {
     /**
      * When `true`, the orchestrator emits to EventBus in addition to
      * recording the observation. Reserved for HIGH-priority signals that
-     * should DM the user without waiting for the hourly check.
+     * should DM the user without waiting for the activity scan.
      */
     emitEvent: boolean;
 };
@@ -57,8 +57,8 @@ export type Classification = {
  * emit-to-EventBus) per the agent's "patterns not events" philosophy.
  *
  * - `review_requested` / `assign` / `security_alert` are HIGH and bypass
- *   hourly_check via direct DM.
- * - `mention` / `team_mention` are NORMAL — coalesced in hourly_check.
+ *   activity_scan via direct DM.
+ * - `mention` / `team_mention` are NORMAL — coalesced in activity_scan.
  * - `subscribed` / `manual` / `comment` / `state_change` etc. are LOW
  *   noise; recorded as observations only so the agent can surface them
  *   if a pattern emerges.

package/dist/observers/github-poller-classifier.js

@@ -4,8 +4,8 @@ import { EventPriority } from "@aitne/shared";
  * emit-to-EventBus) per the agent's "patterns not events" philosophy.
  *
  * - `review_requested` / `assign` / `security_alert` are HIGH and bypass
- *   hourly_check via direct DM.
- * - `mention` / `team_mention` are NORMAL — coalesced in hourly_check.
+ *   activity_scan via direct DM.
+ * - `mention` / `team_mention` are NORMAL — coalesced in activity_scan.
  * - `subscribed` / `manual` / `comment` / `state_change` etc. are LOW
  *   noise; recorded as observations only so the agent can surface them
  *   if a pattern emerges.
@@ -145,7 +145,7 @@ export function classifyWorkflowRun(run, defaultBranch, repoFullName) {
         ref,
         payload,
         // Only DM-grade for default-branch failures. Feature-branch failures
-        // are noise during normal development and only surface via hourly_check.
+        // are noise during normal development and only surface via activity_scan.
         emitEvent: onDefaultBranch,
     };
 }

package/dist/observers/imminent-event-scheduler.d.ts

@@ -17,7 +17,7 @@ import type { Observer } from "./manager.js";
  *    by design (`INTEGRATION_SNAPSHOT_PARTITIONS_BY_MODE[google_calendar].native = []`);
  *    without this second source, native-mode users would silently lose
  *    every 15-minute reminder. Cadence note: native observations refresh
- *    on the hourly_check tick (60-min cadence) so events scheduled with
+ *    on the activity_scan tick (60-min cadence) so events scheduled with
  *    less than ~60 min lead-time may miss their reminder. The 5-min
  *    direct-mode polling cadence does not have this limit.
  *

package/dist/observers/imminent-event-scheduler.js

@@ -38,7 +38,7 @@ function extractCalendarPayload(parsed) {
  *    by design (`INTEGRATION_SNAPSHOT_PARTITIONS_BY_MODE[google_calendar].native = []`);
  *    without this second source, native-mode users would silently lose
  *    every 15-minute reminder. Cadence note: native observations refresh
- *    on the hourly_check tick (60-min cadence) so events scheduled with
+ *    on the activity_scan tick (60-min cadence) so events scheduled with
  *    less than ~60 min lead-time may miss their reminder. The 5-min
  *    direct-mode polling cadence does not have this limit.
  *

package/dist/observers/mail-poller.d.ts

@@ -98,6 +98,7 @@ export declare class MailPoller implements Observer {
     private isAccountManagedExternally;
     private stopIdleForInactiveAccounts;
     private ensureIdle;
+    private startIdleForAccount;
     private softDeleteByProviderMsgId;
     /**
      * Upsert poller-observed messages into `mail_messages_index`.