@aitne/daemon 0.1.7 → 0.1.9

package/dist/core/skills-manifest.js

@@ -1,3 +1,6 @@
+import { existsSync, readFileSync } from "node:fs";
+import { join } from "node:path";
+import { CONTEXT_RELATIVE_PATHS } from "./context-paths.js";
 /**
  * Event-type → agent profile mapping, expressed as prefix rules so every
  * member of a family shares the same profile without needing to list each
@@ -13,7 +16,7 @@
  * some future `schedule.anything_else` that needs a different profile.
  */
 const PROFILE_RULES = [
-    // ROUTINE_DATA_ACQUISITION_DESIGN.md §6.2 / §6.3 — the pre-pass
+    // docs/design/appendices/routine-data-acquisition.md §6.2 / §6.3 — the pre-pass
     // fetcher runs under its own dedicated persona ("fetch, don't think").
     // MUST precede the generic `routine.` rule below; without this entry
     // the prefix match would route the fetcher to the broad recurring-
@@ -51,41 +54,76 @@ export const EVENT_SKILL_SETS = {
     // Status). Hourly is intentionally omitted — hourly writes via
     // recordObservation(kind='roadmap_candidate'), never through the
     // roadmap skill. See ROADMAP-REDESIGN.md §3.7.
+    // Morning routine input cap: the task-flow drives mail + calendar + roadmap
+    // walk + today.md write + schedule register. Skills outside that surface
+    // (`external-services`, `notion`, `travel`) inline 20+ KB of
+    // API reference for endpoints the routine never calls — every dropped slug
+    // here is one whose endpoints don't appear in routine.morning_routine.md.
+    // Notion drain happens via /api/observations (taught by `observations`);
+    // the `notion` skill itself only documents /api/notion/* CRUD which the
+    // routine doesn't touch.
     "routine.morning_routine": [
         "context",
         "today",
         "observations",
         "schedule",
-        "external-services",
         "mail",
-        "notion",
-        "travel",
-        "travel-time",
         "roadmap",
+        // Conditionally loaded via `gmailLifestyleActive(db)` — morning
+        // routine surfaces upcoming travel / commute / unsaved receipts in
+        // today.md when relevant. Routine variant uses the base predicate
+        // (no message-text trigger). See docs/design/appendices/skills-improvement.md §9-§11.
+        "gmail-lifestyle",
         // Step 7.5 — pick at most one profile-interview question per agent-day
         // and write it as a (latent) entry in today.md ## Agent Notes. The
         // morning routine never schedules a cold DM for it; latent rows wait
         // for a natural opportunity. See profile-interview-queue.md §3.1.
         "user-interview",
     ],
-    "routine.morning_routine_initial": [
+    // `routine.morning_routine_initial` is retired. The first-run branch
+    // flows through `routine.morning_routine_today` (Stage A) below. See
+    // morning-routine-optimization.md for the split rationale.
+    // Stage A (today.md synthesis) inherits the legacy bundle PLUS
+    // `agent-actions` for the structured self-report Step 9 makes through
+    // `PATCH /api/agent-actions/self`. The skill is small (~120 lines of
+    // SKILL.md) — well within the medium-tier cold-start budget — and
+    // load-bearing for the daemon's ⑥ AgentJournalAppender step which
+    // reads the metadata column the agent writes here.
+    "routine.morning_routine_today": [
         "context",
         "today",
         "observations",
         "schedule",
-        "external-services",
         "mail",
-        "notion",
-        "travel",
-        "travel-time",
         "roadmap",
-    ],
+        "gmail-lifestyle",
+        "user-interview",
+        "agent-actions",
+    ],
+    // docs/design/appendices/daily-journal-daemon-write.md §4.10 — Stage B
+    // no longer needs the `context` skill (or any other skill). The
+    // daemon-side composer (`core/morning/daily-journal-composer.ts`)
+    // performs the daily-journal write deterministically from the LLM's
+    // tagged final-text output; Stage B has zero tool requirement so the
+    // `dontAsk` denial layer that previously trapped Haiku's
+    // `cat > /tmp/...` attempts becomes structurally moot.
+    "routine.morning_routine_journal": [],
+    // `evening-review-slimdown.md` §2.1 — Phase 2 dropped `travel`
+    // unconditionally (was only kept for Step 4's "newly detected bookings"
+    // path, deleted alongside Step 4). `notify` is loaded *conditionally* via
+    // `resolveSkillManifest` — the built-in steps emit no user-facing output,
+    // so the universal message-discipline contract is only needed when the
+    // user has authored at least one `### ` rule in
+    // `policies/routines/evening.md` that may call `POST /api/notify`. Callers MUST go
+    // through `resolveSkillManifest(event, { contextDir })` to apply the gate;
+    // direct `EVENT_SKILL_SETS[event]` reads see the static (`notify`-on)
+    // shape and are intentionally conservative for tooling that doesn't have
+    // a contextDir handy (manifest-integrity tests, ALL_SKILLS audits).
     "routine.evening_review": [
         "context",
         "today",
         "user-profile",
         "notify",
-        "travel",
         "roadmap",
         "management-policy",
     ],
@@ -115,6 +153,30 @@ export const EVENT_SKILL_SETS = {
         "reading",
     ],
     "routine.roadmap_refresh": ["context", "external-services", "notion", "roadmap"],
+    // BROWSER_HISTORY_INTEGRATION_PLAN P3. Each browser-history routine
+    // loads the agent-facing browser-history skill (curl chokepoint to
+    // /api/browser-history/*) plus `context` for the research-journal /
+    // assistance / wiki write paths. `notify` is layered on for any
+    // routine that DMs the user — the routine_protocol block tells the
+    // agent that /api/notify is the only user-visible channel for
+    // routines, but only `notify`'s SKILL.md carries the actual curl
+    // shape (host, port, body schema, priority field, awareness-gate
+    // rules). Without it the agent has to guess the API surface, which
+    // breaks the "DM the owner with..." instructions in the task-flows.
+    //
+    // cluster_update stays silent — it appends to a journal file and
+    // does not DM. The offer DM routine has the curl shape inline in
+    // its task-flow so the narrow skill set is acceptable there; the
+    // two accept-path routines (research_dispatch, research_wiki_summary)
+    // need `notify` because their task-flows just say "DM the owner".
+    "routine.research_cluster_update": ["browser-history", "context"],
+    // BROWSER_HISTORY_INTEGRATION_PLAN §10.1 (seventh-pass) — offer DM
+    // composition is its own lite-tier session. The task-flow inlines
+    // the curl shape; no browser-history-respond — that skill lives on
+    // the message.dm side where the user's reply lands.
+    "routine.research_offer_dm": ["browser-history", "context"],
+    "routine.research_dispatch": ["browser-history", "context", "notify"],
+    "routine.research_wiki_summary": ["browser-history", "context", "notify"],
     // Dashboard-triggered manual refresh of today.md's User Schedule
     // section. Intentionally narrow — the flow only reads the calendar
     // and PATCHes user_schedule / agent_log. No mail, no roadmap, no
@@ -149,18 +211,24 @@ export const EVENT_SKILL_SETS = {
         "external-services",
         "mail",
         "notion",
-        "travel",
-        "travel-time",
-        "receipts",
+        // docs/design/appendices/skills-improvement.md §9-§11 — merged from travel
+        // + receipts. Conditionally loaded via `gmailLifestyleActiveForDm` so DMs
+        // that don't mention travel / receipts and have no fresh bookings or
+        // unsaved receipts don't pay the ~180-line cost.
+        "gmail-lifestyle",
         "roadmap",
         "management-policy",
-        // docs/design/21-management-registry-and-entities.md §10.1-§10.3 —
-        // DM-driven CRUD on §B managed-task rows. Loaded everywhere the user
-        // can speak naturally to the agent so register/modify/stop intents
-        // are discoverable from any DM entry point.
-        "management-task-register",
-        "management-task-modify",
-        "management-task-stop",
+        // docs/design/appendices/skills-improvement.md §14 — merged from
+        // management-task-{register,modify,stop}. Conditionally loaded via
+        // `managedTasksActiveForDm`. Loaded by default (no db handle =
+        // conservative include) so DM trigger surfaces remain discoverable
+        // from any entry point; the predicate only drops the skill when the
+        // DB has zero rows AND the message text carries no `mt_<n>` /
+        // "managed task" / "recurring fetch" anchor.
+        "managed-tasks",
+        // Scheduling split — author a recurring Agent when the user asks for an
+        // ongoing cadence (`/schedule` is one-shot only).
+        "agent-create",
     ],
     "message.received.dm_first": [
         "context",
@@ -172,19 +240,26 @@ export const EVENT_SKILL_SETS = {
         "external-services",
         "mail",
         "notion",
-        "travel",
-        "travel-time",
-        "receipts",
+        "gmail-lifestyle",
         "roadmap",
         "management-policy",
-        "management-task-register",
-        "management-task-modify",
-        "management-task-stop",
+        "managed-tasks",
+        // Scheduling split — recurring tasks are Agents (see `message.received`).
+        "agent-create",
         // DM handler decides whether the inbound topic is a natural moment
         // to weave a latent profile question into the reply, and ticks the
         // queue when the user answers a previously-asked one. See
         // profile-interview-queue.md §3.3 + the latent-opportunity block.
         "user-interview",
+        // BROWSER_TASK_REDESIGN_PLAN.md §10 / Phase 5 — also loaded for the
+        // user's first DM. The redesign's stated intent ("DM agent can hand
+        // any natural-language browser request") covers first-time DMs too;
+        // omitting it here would mean the user's literal first message
+        // "post to X" silently misses the skill and the agent has to
+        // bluff. The `browser-history-respond` skill is correctly absent
+        // (no prior research offer to respond to) — that exclusion does
+        // not generalise.
+        "browser-task",
     ],
     "message.received.dm": [
         "context",
@@ -196,15 +271,40 @@ export const EVENT_SKILL_SETS = {
         "external-services",
         "mail",
         "notion",
-        "travel",
-        "travel-time",
-        "receipts",
+        "gmail-lifestyle",
         "roadmap",
         "management-policy",
-        "management-task-register",
-        "management-task-modify",
-        "management-task-stop",
+        "managed-tasks",
         "user-interview",
+        // Scheduling split — recurring tasks are Agents (see `message.received`).
+        "agent-create",
+        // BROWSER_HISTORY_INTEGRATION_PLAN §10.1 (seventh-pass) — narrow
+        // accept-surface for natural-language reply to a research offer
+        // DM. The skill body documents the intent-mapping rules
+        // (research/dig → research_assist; summarise → wiki_summary;
+        // no thanks → decline). Conditional load is intentionally absent;
+        // the skill itself no-ops when `GET /offers/pending` is empty,
+        // and the cost of having the skill text in DM context is small.
+        "browser-history-respond",
+        // BROWSER_TASK_REDESIGN_PLAN.md §10 / Phase 5 — DM-driven entry
+        // point to the open-ended browser-task surface. The legacy
+        // `browser-history-managed` skill (and the
+        // `routine.browser_automation_request` / `routine.managed_sync_health_check`
+        // process keys that loaded it) was retired in Phase 6; the new
+        // `browser-task` skill teaches the DM agent to POST a
+        // natural-language description, relay sub-agent clarifications via
+        // /clarify, and cancel on user request — without ever touching the
+        // `!~xxxxxxxx` final-confirm token (that round-trip stays between
+        // the daemon and the user). Loaded for `message.received.dm` AND
+        // `message.received.dm_first` (`dashboard.chat` and `message.dm`
+        // inherit the former via PROCESS_TO_EVENT_TYPE). Mentions /
+        // scheduled DMs / routines do not carry it — mentions land on
+        // `message.received` which is a shared-channel surface, and
+        // scheduled DMs are daemon-initiated (no user-driven browser ask
+        // to relay). No conditional gate — the skill body is small and
+        // the agent simply does not call its endpoints when the user's
+        // request doesn't ask for a browser task.
+        "browser-task",
     ],
     // ── Task events ──
     "schedule.approaching": [
@@ -246,13 +346,25 @@ export const EVENT_SKILL_SETS = {
         "notion",
         "observations",
         "roadmap",
+        // Conditionally loaded via `gmailLifestyleActiveForDm` — the
+        // briefing surfaces upcoming travel / commute when relevant.
+        "gmail-lifestyle",
         // Morning-briefing piggyback (a latent profile question may be woven
         // into the briefing when topic-appropriate) and the
         // `profile_interview:` fallback sub-flow both call into this skill.
         // See profile-interview-queue.md §3.2 + §3.5.3.
         "user-interview",
     ],
-    "setup.initial": ["user-profile", "external-services"],
+    // SETUP-FLOW-REDESIGN-PLAN §5.8 removed the legacy "tool selections"
+    // form; the agent now derives the Source-of-Truth table from the
+    // `<integration_modes>` / `<obsidian_vault_path>` context tags rather
+    // than hitting `/api/*` endpoints. setup.initial writes only to
+    // /api/context/user/* (covered by the user-profile skill), so the
+    // external-services skill — which mirrors /api/calendar, /api/obsidian,
+    // /api/github, /api/skills — is dead weight here. Removing it cuts the
+    // injected skill surface roughly in half for setup.initial on Codex,
+    // where the long single-shot response was the visible symptom.
+    "setup.initial": ["user-profile"],
     "setup.update": ["user-profile"],
     // Knowledge import: minimal manifest to keep the agent focused on
     // one job — read the uploaded blob and route literal facts into
@@ -352,7 +464,7 @@ export const EVENT_SKILL_SETS = {
     // exactly one read-only skill; every other skill is excluded so the
     // model cannot mutate context, send DMs, or hit external APIs.
     "dashboard.docs_qa": ["docs-search"],
-    // ROUTINE_DATA_ACQUISITION_DESIGN.md §6.3 / P3 — the pre-pass fetcher
+    // docs/design/appendices/routine-data-acquisition.md §6.3 / P3 — the pre-pass fetcher
     // does mechanical fetch + POST observations and nothing else. The
     // skill set carries (a) `observations` for the POST contract,
     // (b) `mail` / `notion` / `external-services` for the three
@@ -413,11 +525,16 @@ export const ALL_SKILLS = [
     "external-services",
     "mail",
     "notion",
+    // docs/design/appendices/skills-improvement.md §9-§11 — merged from travel
+    // + receipts. Conditionally loaded for DMs / routines via
+    // `gmailLifestyleActive*` predicates.
+    "gmail-lifestyle",
     "roadmap",
     "management-policy",
-    "management-task-register",
-    "management-task-modify",
-    "management-task-stop",
+    // docs/design/appendices/skills-improvement.md §14 — merged from
+    // management-task-{register,modify,stop}. Conditionally loaded for
+    // DMs via `managedTasksActiveForDm`.
+    "managed-tasks",
     "scheduled-managed-task",
     "project-doc",
     "wiki-vault-rules",
@@ -429,9 +546,36 @@ export const ALL_SKILLS = [
     "wiki-trace",
     "wiki-connect",
     "wiki-graduate",
+    // BROWSER_HISTORY_INTEGRATION_PLAN P3 — agent-facing skill for the
+    // /api/browser-history/* surface. Bundled with `context` for the
+    // research-journal write path.
+    "browser-history",
+    // BROWSER_HISTORY_INTEGRATION_PLAN §10.1 (seventh-pass) — narrow
+    // accept-surface skill loaded for `message.received.dm` (which both
+    // `message.dm` and `dashboard.chat` inherit). Exposes only the
+    // pending-offers list + accept/decline endpoints so the standard
+    // DM agent can translate a user's natural-language reply into the
+    // structured dispatch call. The full `browser-history` skill is
+    // intentionally NOT loaded for message.dm — DM agent isolation.
+    "browser-history-respond",
+    // BROWSER_TASK_REDESIGN_PLAN.md §10 / Phase 5 — DM-driven entry
+    // point to the open-ended browser-task surface. Loaded only for
+    // `message.received.dm` (DM agent + dashboard chat). The legacy
+    // `browser-history-managed` skill that fronted the frozen workflow
+    // registry was retired alongside the route + routines in Phase 6.
+    "browser-task",
+    // Scheduling split — `/schedule` is one-shot only; recurring tasks are
+    // Agents. This skill teaches the DM agent to author a detailed recurring
+    // Agent (`POST /api/agents`) when the user asks for an ongoing cadence.
+    "agent-create",
 ];
 const PROCESS_TO_EVENT_TYPE = {
     "routine.morning_routine": "routine.morning_routine",
+    // morning-routine-optimization.md Phase 5/6 — Stage A + Stage B keys
+    // map to their own event-type strings so `resolveSkillManifestForProcess`
+    // returns the split bundle defined above.
+    "routine.morning_routine_today": "routine.morning_routine_today",
+    "routine.morning_routine_journal": "routine.morning_routine_journal",
     "routine.evening_review": "routine.evening_review",
     "routine.weekly_review": "routine.weekly_review",
     "routine.monthly_review": "routine.monthly_review",
@@ -439,6 +583,10 @@ const PROCESS_TO_EVENT_TYPE = {
     "routine.roadmap_refresh": "routine.roadmap_refresh",
     "routine.today_refresh": "routine.today_refresh",
     "routine.user_profile_sweep": "routine.user_profile_sweep",
+    "routine.research_cluster_update": "routine.research_cluster_update",
+    "routine.research_offer_dm": "routine.research_offer_dm",
+    "routine.research_dispatch": "routine.research_dispatch",
+    "routine.research_wiki_summary": "routine.research_wiki_summary",
     "message.dm": "message.received.dm",
     "message.mention": "message.received",
     "dashboard.chat": "message.received.dm",
@@ -460,6 +608,285 @@ const PROCESS_TO_EVENT_TYPE = {
     "wiki.trace": "wiki.trace",
     "wiki.connect": "wiki.connect",
 };
+/**
+ * `evening-review-slimdown.md` §2.1 — predicate that drives conditional
+ * loading of the `notify` skill for `routine.evening_review`.
+ *
+ * The slim built-in evening steps (Handoff, Long-term Plans promotion,
+ * Review-date fire, Raw Signals graduation) emit no user-facing output.
+ * `notify` is only load-bearing when the operator has written at least
+ * one `### <label>` rule into `policies/routines/evening.md` that may post to
+ * `/api/notify` — the universal message-discipline contract in the
+ * notify skill is the binding format guide for those rules.
+ *
+ * Rules-of-thumb encoded here, mirroring §2.1's three cases:
+ *   - file absent / unreadable → `false` (drop notify)
+ *   - file empty / whitespace-only → `false` (drop notify)
+ *   - file present but no `^### ` line → `false` (no rule headings)
+ *   - file present with at least one `^### ` heading → `true` (keep notify)
+ *
+ * `contextDir` undefined / empty → `false`. Tooling that cannot resolve a
+ * context root (manifest-integrity tests, repo-only audits) gets the
+ * conservative "no rulebook" answer.
+ */
+export function eveningRulebookIsActive(contextDir) {
+    if (!contextDir)
+        return false;
+    const rulebookPath = join(contextDir, CONTEXT_RELATIVE_PATHS.routines.evening);
+    if (!existsSync(rulebookPath))
+        return false;
+    let body;
+    try {
+        body = readFileSync(rulebookPath, "utf-8");
+    }
+    catch {
+        // Unreadable (permissions, deleted between existsSync and read) →
+        // treat as absent. The next session re-evaluates from scratch.
+        return false;
+    }
+    if (body.trim().length === 0)
+        return false;
+    return /^###\s+/m.test(body);
+}
+/**
+ * docs/design/appendices/skills-improvement.md §9-§11 + Open Q #3 — predicate that drives
+ * conditional loading of the merged `gmail-lifestyle` skill.
+ *
+ * Base predicate: true when at least one of
+ *   - `travel_bookings` has a row with `start_date >= now() - 30 days`
+ *     (a fresh-or-near-past booking the agent might still want to
+ *     surface in summaries)
+ *   - `receipts` has a row with `saved_at IS NULL` (an attachment the
+ *     user has not yet filed into the external Obsidian vault)
+ *
+ * Both queries are cheap (one indexed `LIMIT 1` each) and run on every
+ * manifest resolution; do not add a JSON-parsing or fan-out cousin
+ * without a benchmark.
+ *
+ * `db === undefined` → returns `true` (conservative include). Tooling
+ * that cannot pass the DB handle (manifest-integrity tests, ALL_SKILLS
+ * audits) sees the merged skill in every event set, which matches the
+ * static safety net.
+ */
+export function gmailLifestyleActive(db) {
+    if (!db)
+        return true; // conservative include when no DB handle
+    try {
+        const fresh = db.prepare(`SELECT 1 FROM travel_bookings
+       WHERE start_date >= datetime('now', '-30 days')
+       LIMIT 1`).get();
+        if (fresh)
+            return true;
+        const unsaved = db.prepare(`SELECT 1 FROM receipts WHERE saved_at IS NULL LIMIT 1`).get();
+        return Boolean(unsaved);
+    }
+    catch {
+        // Schema gap (tables not migrated yet, or db handle in unexpected
+        // state) → conservative include. The skill body's own "When NOT to
+        // act" copy is the second line of defence.
+        return true;
+    }
+}
+/**
+ * Trigger phrases for the DM variant of `gmailLifestyleActive`. Matches
+ * the inbound message text against keywords that imply the user wants
+ * travel / commute / receipt help even when the DB predicate would say
+ * no (first-ever booking question; receipt query before the first
+ * Gmail-observer scan; etc.).
+ *
+ * Word-boundary regex (not `String.prototype.includes`): a naive
+ * substring match would over-trigger on "stripe" / "stripped" (matches
+ * `trip`), "training" / "constraint" (matches `train`), "tripled"
+ * (matches `trip`), etc. — each false positive loads the ~180-line
+ * skill body for an unrelated DM. The trigger pool is English-only;
+ * the user's primary-language phrasings rely on the description-based
+ * SDK match for routing, not on this predicate.
+ *
+ * Singular/plural is handled via the `s?` suffix; multi-word phrases
+ * use a literal substring (still safe because the phrase itself is
+ * unambiguous).
+ */
+const GMAIL_LIFESTYLE_TRIGGER_RE = new RegExp(String.raw `\b(receipts?|expenses?|invoices?|flights?|hotels?|trains?|commute|trips?|bookings?|reservations?)\b`, "i");
+const GMAIL_LIFESTYLE_PHRASE_TRIGGERS = [
+    "departure time",
+];
+function dmMentionsGmailLifestyle(messageText) {
+    if (!messageText)
+        return false;
+    if (GMAIL_LIFESTYLE_TRIGGER_RE.test(messageText))
+        return true;
+    const lower = messageText.toLowerCase();
+    for (const phrase of GMAIL_LIFESTYLE_PHRASE_TRIGGERS) {
+        if (lower.includes(phrase))
+            return true;
+    }
+    return false;
+}
+/**
+ * DM-aware variant. `gmail-lifestyle` is included when EITHER the base
+ * predicate fires OR the inbound DM text mentions a trigger phrase.
+ *
+ * Non-DM events (morning routine, evening review) use the base
+ * `gmailLifestyleActive` directly — they have no message text to read.
+ */
+export function gmailLifestyleActiveForDm(db, messageText) {
+    if (gmailLifestyleActive(db))
+        return true;
+    return dmMentionsGmailLifestyle(messageText);
+}
+/**
+ * docs/design/appendices/skills-improvement.md §14 — predicate for the merged
+ * `managed-tasks` skill.
+ *
+ * Base predicate: true when at least one `managed_tasks` row exists.
+ * The check is intentionally cheap (one indexed `LIMIT 1`).
+ *
+ * `db === undefined` → conservative include.
+ */
+export function managedTasksActive(db) {
+    if (!db)
+        return true; // conservative include when no DB handle
+    try {
+        const row = db.prepare(`SELECT 1 FROM managed_tasks LIMIT 1`).get();
+        return Boolean(row);
+    }
+    catch {
+        return true;
+    }
+}
+/**
+ * DM trigger phrases for managed-tasks. The `mt_<n>` anchor is a
+ * high-precision id reference; the long-form phrases are the
+ * register-intent surface (the user wants to discuss the concept even
+ * when zero rows exist yet).
+ *
+ * The app-name match uses word boundaries — a naive `t.includes("notion")`
+ * matches "notional" / "notionally", "zoom" matches "zoomed in", "drive"
+ * matches "driveway", "linear" matches "linearly", etc. Each would load
+ * the merged ~250-line skill body for an unrelated DM. The recurring-
+ * cadence anchor stays tight (`daily` / `weekly` / `monthly` / explicit
+ * weekday) so a casual "every day I drink coffee" still misses.
+ */
+const MANAGED_TASKS_ID_RE = /\bmt_\d+\b/i;
+const MANAGED_TASKS_RECURRING_VERB_RE = /\brecurring\s+(fetch|check|sync|pull|sweep)\b/i;
+const MANAGED_TASKS_CADENCE_RE = /\b(every\s+(day|monday|tuesday|wednesday|thursday|friday|saturday|sunday|week|month)|daily|weekly|monthly)\b/i;
+const MANAGED_TASKS_APP_RE = /\b(zoom|gmail|drive|notion|outlook|linear|jira|slack|asana|github|trello|airtable)\b/i;
+function dmMentionsManagedTasks(messageText) {
+    if (!messageText)
+        return false;
+    if (MANAGED_TASKS_ID_RE.test(messageText))
+        return true;
+    if (/\bmanaged\s+tasks?\b/i.test(messageText))
+        return true;
+    if (MANAGED_TASKS_RECURRING_VERB_RE.test(messageText))
+        return true;
+    // "every day check Zoom" / "every Monday pull Drive" — recurring +
+    // common-connector noun. Kept tight to avoid loading the skill on
+    // bland scheduling phrasings that belong in `schedule` instead.
+    if (MANAGED_TASKS_CADENCE_RE.test(messageText) &&
+        MANAGED_TASKS_APP_RE.test(messageText)) {
+        return true;
+    }
+    return false;
+}
+/**
+ * DM-aware variant. `managed-tasks` is included when EITHER the base
+ * predicate fires OR the inbound DM text matches a managed-task
+ * anchor / phrase.
+ */
+export function managedTasksActiveForDm(db, messageText) {
+    if (managedTasksActive(db))
+        return true;
+    return dmMentionsManagedTasks(messageText);
+}
+/**
+ * Scheduling split — predicate for the `agent-create` skill (teaches the DM
+ * agent to author a recurring **work** Agent via `POST /api/agents`). Loaded
+ * only when the inbound DM looks like a recurring-autonomous-work request:
+ * a recurring cadence AND an autonomous-work verb (so a recurring *DM*
+ * — "DM me every morning", which belongs on `dm_session` — and a one-shot
+ * "remind me tomorrow" both miss). A direct "automate" / "recurring agent"
+ * phrasing fires on its own. Message-only (the skill has no runtime DB state);
+ * a DM with no message text (test default) drops the skill.
+ */
+const AGENT_CREATE_CADENCE_RE = /\b(every\s+(day|morning|evening|night|hour|week|month|monday|tuesday|wednesday|thursday|friday|saturday|sunday)|each\s+(day|morning|week|month)|daily|weekly|monthly|hourly|recurring|recurrence|from now on|on a schedule|regularly|periodically)\b/i;
+const AGENT_CREATE_WORK_RE = /\b(triage|check|review|monitor|fetch|pull|scan|audit|sync|compile|summari[sz]e|update|maintain|run|process|organi[sz]e|generate|analy[sz]e|watch|track)\b/i;
+const AGENT_CREATE_DIRECT_RE = /\b(recurring agent|automate|automatically|set up an agent|create an agent|spawn an agent)\b/i;
+export function agentCreateActiveForDm(messageText) {
+    if (!messageText)
+        return false;
+    if (AGENT_CREATE_DIRECT_RE.test(messageText))
+        return true;
+    return (AGENT_CREATE_CADENCE_RE.test(messageText) &&
+        AGENT_CREATE_WORK_RE.test(messageText));
+}
+/**
+ * `evening-review-slimdown.md` §2.1 — context-aware manifest resolver.
+ *
+ * Wraps the static `EVENT_SKILL_SETS` lookup with per-event predicates that
+ * inspect runtime state (today: only the evening rulebook). Other events
+ * pass through unchanged — they reuse the static array verbatim.
+ *
+ * This is a per-event opt-in pattern (Q6 resolution). If a future routine
+ * develops the same "skill needed only when user extends the rulebook"
+ * shape, register its own predicate here rather than forcing every event
+ * to think about context-driven loading.
+ */
+export function resolveSkillManifest(eventType, opts) {
+    const base = EVENT_SKILL_SETS[eventType];
+    if (!base)
+        return ALL_SKILLS;
+    let result = base;
+    if (eventType === "routine.evening_review") {
+        if (!eveningRulebookIsActive(opts?.contextDir ?? null)) {
+            result = result.filter((slug) => slug !== "notify");
+        }
+    }
+    // docs/design/appendices/skills-improvement.md §9-§11 + §14 — gmail-lifestyle and
+    // managed-tasks are present in the base array for the events listed
+    // below and are dropped per-event when the matching predicate fires
+    // false. DM-class events use the *ForDm variant so a trigger phrase
+    // in the inbound message text can override an empty DB.
+    const dmEvents = new Set([
+        "message.received",
+        "message.received.dm",
+        "message.received.dm_first",
+        "scheduled.dm",
+    ]);
+    const routineEventsWithGmailLifestyle = new Set([
+        "routine.morning_routine",
+        "routine.morning_routine_today",
+    ]);
+    if (dmEvents.has(eventType)) {
+        if (result.includes("gmail-lifestyle") &&
+            !gmailLifestyleActiveForDm(opts?.db ?? null, opts?.messageText ?? null)) {
+            result = result.filter((slug) => slug !== "gmail-lifestyle");
+        }
+        if (result.includes("managed-tasks") &&
+            !managedTasksActiveForDm(opts?.db ?? null, opts?.messageText ?? null)) {
+            result = result.filter((slug) => slug !== "managed-tasks");
+        }
+        if (result.includes("agent-create") &&
+            !agentCreateActiveForDm(opts?.messageText ?? null)) {
+            result = result.filter((slug) => slug !== "agent-create");
+        }
+    }
+    else if (routineEventsWithGmailLifestyle.has(eventType)) {
+        if (result.includes("gmail-lifestyle") &&
+            !gmailLifestyleActive(opts?.db ?? null)) {
+            result = result.filter((slug) => slug !== "gmail-lifestyle");
+        }
+    }
+    return result;
+}
+/**
+ * Process-key flavoured wrapper around `resolveSkillManifest`. Mirrors
+ * `getSkillsForProcess` so call sites that already key on `ProcessKey`
+ * (most session materialisation sites) don't need to translate twice.
+ */
+export function resolveSkillManifestForProcess(processKey, opts) {
+    return resolveSkillManifest(PROCESS_TO_EVENT_TYPE[processKey] ?? processKey, opts);
+}
 export function getProfileForEvent(eventType) {
     for (const rule of PROFILE_RULES) {
         if (rule.exact ? eventType === rule.prefix : eventType.startsWith(rule.prefix)) {
@@ -477,4 +904,44 @@ export function getProfileForProcess(processKey) {
 export function getSkillsForProcess(processKey) {
     return getSkillsForEvent(PROCESS_TO_EVENT_TYPE[processKey] ?? processKey);
 }
-//# sourceMappingURL=skills-manifest.js.map
+/**
+ * Compose an Agent definition's `tools.skills` (AGENT_DEFINITIONS_DESIGN.md
+ * §4.2 / `packages/shared/src/agent-definitions.ts` `skills_replace`) with the
+ * process-key default skill bundle. The schema comment promised "the loader
+ * composes the effective set"; this is that composition, applied at session
+ * materialisation (`materializeSessionBundle`) where the skill set is actually
+ * resolved.
+ *
+ * Semantics:
+ *   - `replace === false` (default): union — the default bundle PLUS every
+ *     extra slug not already present. Base order first (so the manifest's
+ *     intentional ordering is preserved), then appended extras.
+ *   - `replace === true`: the extra list is a strict subset that fully
+ *     supplants the default bundle.
+ *   - empty / absent `extra`: pure no-op — returns a copy of `base` unchanged,
+ *     INCLUDING when `replace` is true. An Agent that sets `skills_replace`
+ *     with no `skills` is treated as "no override" rather than "strip every
+ *     skill", because stripping `context` / `notify` from the bundle would
+ *     break the run; callers that want an empty set pass it explicitly and
+ *     the dispatcher gates the override on a non-empty list anyway.
+ *
+ * Output is always deduped (a slug appearing in both base and extra, or twice
+ * in extra, lands once). Unknown slugs are NOT filtered here — the
+ * materialiser skips any slug whose `SKILL.md` is absent on disk, and the
+ * Agent loader already emits an "unknown skill" warning at parse time — so
+ * keeping them keeps the stamp/drift snapshot and this list in agreement.
+ */
+export function composeSkillSet(base, extra, replace) {
+    if (!extra || extra.length === 0)
+        return [...base];
+    const source = replace ? extra : [...base, ...extra];
+    const seen = new Set();
+    const out = [];
+    for (const slug of source) {
+        if (seen.has(slug))
+            continue;
+        seen.add(slug);
+        out.push(slug);
+    }
+    return out;
+}