@zibby/workflow-templates 0.4.1 → 0.7.0

package/sentry-triage/graph.mjs

@@ -1,51 +1,41 @@
 /**
- * sentry-triage — parent workflow.
+ * sentry-triage — parent workflow. Hourly Sentry issue triage.
  *
- * Pipeline:
+ * Pipeline (3 LLM nodes, end-to-end agent-driven):
  *
- *   fetch_issues   (LLM + SKILLS.SENTRY)
+ *   fetch_issues    (LLM + SKILLS.SENTRY)        → list recent unresolved issues
  *        ↓
- *   filter_noise   (pure JS regex pre-filter — kills ~80% of LLM cost)
+ *   classify        (LLM, no tools)              → label NOISE/LOW/MEDIUM/HIGH/CRITICAL
  *        ↓
- *   classify       (LLM — assigns CRITICAL/HIGH/MEDIUM/LOW/NOISE per issue)
- *        ↓
- *   dispatch_alerts (custom execute — sub-graphs to notify-slack OR notify-lark
- *                    per issue at or above severityThreshold)
+ *   dispatch_alerts (LLM + SKILLS.CHAT_NOTIFY)   → batch + post to Slack OR Lark for
+ *                                                   issues ≥ SEVERITY_THRESHOLD
  *
- * Sub-graph dispatch: each "real" alert fans out to ONE notify-* child
- * workflow (configurable per deploy via state.notifyWorker). Failures
- * on individual alerts don't kill the triage run — failed entries are
- * reported in dispatch_alerts.summary.failed and surfaced in
- * onComplete logging.
+ * Why all three nodes are LLM (not deterministic for-loops):
+ *   - At hourly cadence with ≤20 issues/run, LLM cost is $1.50–$32/mo
+ *     depending on model. Trivial relative to Sentry / Slack subscriptions.
+ *   - LLM dispatch can BATCH related issues (5 errors in /checkout/ →
+ *     1 consolidated message) and DE-DUP near-duplicates. A
+ *     deterministic for-loop can't.
+ *   - outputSchema enforcement guarantees every above-threshold issue
+ *     either gets a "sent" record or an explicit "failed/skipped" —
+ *     no silent drops.
  *
- * In-process sub-graph execution (when both parent + child are bundled
- * in the same Fargate task) means each fan-out adds ~5ms overhead vs
- * an HTTP /trigger round-trip's 80s cold-start. For 20 issues that's
- * 100ms vs 1600s — the architecture is what makes this template
- * cheap enough to run hourly.
+ * Customize prompts: each node's prompt lives in its own module under
+ * nodes/. Override per-deploy by editing the file or by passing a
+ * custom prompt string via inputSchema (planned).
  */
 
-import { readFileSync, existsSync } from 'fs';
-import { join, dirname } from 'path';
-import { fileURLToPath } from 'url';
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';
 
 import { fetchIssuesNode } from './nodes/fetch-issues-node.js';
-import { filterNoiseNode } from './nodes/filter-noise-node.js';
 import { classifyNode } from './nodes/classify-node.js';
-import { dispatchAlertsNode } from './nodes/dispatch-alerts-node.js';
+import { dispatchNode } from './nodes/dispatch-node.js';
 
 import {
   sentryTriageInputSchema,
   sentryTriageContextSchema,
 } from './state.js';
 
-const __dirname = dirname(fileURLToPath(import.meta.url));
-function loadPrompt(filename) {
-  const path = join(__dirname, 'prompts', filename);
-  return existsSync(path) ? readFileSync(path, 'utf-8') : '';
-}
-
 export class SentryTriageAgent extends WorkflowAgent {
   buildGraph() {
     const graph = new WorkflowGraph();
@@ -53,14 +43,12 @@ export class SentryTriageAgent extends WorkflowAgent {
       .setInputSchema(sentryTriageInputSchema)
       .setContextSchema(sentryTriageContextSchema);
 
-    graph.addNode('fetch_issues', fetchIssuesNode, { prompt: loadPrompt('fetch-issues.md') });
-    graph.addNode('filter_noise', filterNoiseNode);
-    graph.addNode('classify',     classifyNode,    { prompt: loadPrompt('classify.md') });
-    graph.addNode('dispatch_alerts', dispatchAlertsNode);
+    graph.addNode('fetch_issues',    fetchIssuesNode);
+    graph.addNode('classify',        classifyNode);
+    graph.addNode('dispatch_alerts', dispatchNode);
 
     graph.setEntryPoint('fetch_issues');
-    graph.addEdge('fetch_issues',    'filter_noise');
-    graph.addEdge('filter_noise',    'classify');
+    graph.addEdge('fetch_issues',    'classify');
     graph.addEdge('classify',        'dispatch_alerts');
     graph.addEdge('dispatch_alerts', 'END');
 
@@ -69,10 +57,11 @@ export class SentryTriageAgent extends WorkflowAgent {
 
   async onComplete(result) {
     const s = result?.state?.dispatch_alerts?.summary || {};
-    const dropped = result?.state?.filter_noise?.dropped?.length || 0;
+    const classifications = result?.state?.classify?.classifications || [];
+    const noise = classifications.filter((c) => c.severity === 'NOISE').length;
     const fetched = result?.state?.fetch_issues?.issues?.length || 0;
     console.log(
-      `[sentry-triage] complete — fetched=${fetched}, noise=${dropped}, ` +
+      `[sentry-triage] complete — fetched=${fetched}, noise=${noise}, ` +
       `sent=${s.sent || 0}, skipped=${s.skipped || 0}, failed=${s.failed || 0}`,
     );
   }

package/sentry-triage/nodes/classify-node.js

@@ -1,14 +1,13 @@
 /**
  * classify node — LLM-driven severity classification.
  *
- * No tools — pure prompt + structured output. The prompt
- * (prompts/classify.md) carries the rubric (CRITICAL/HIGH/MEDIUM/LOW/
- * NOISE) and the LLM emits one classification record per kept issue.
+ * No tools — the LLM sees the rubric AND the concrete issues array
+ * (inlined as JSON at render time) and emits one classification record
+ * per issue. NOISE detection is part of the rubric itself; no separate
+ * pre-filter step.
  *
- * Temperature should be 0 (set by the runner via `model: 'auto'`'s
- * defaults for classification-style nodes). Schema enforcement
- * guarantees the emitted shape; bad models get a retry with the
- * outputSchema in the prompt.
+ * Severity threshold (skip-floor) lives on dispatch, NOT here — this
+ * node always classifies every issue. dispatch decides whether to send.
  */
 
 import { z } from '@zibby/core';
@@ -27,12 +26,98 @@ const ClassifyOutputSchema = z.object({
   classifications: z.array(ClassificationShape),
 });
 
+const RUBRIC = `You are the classify node of a Sentry triage workflow. Classify each Sentry issue into a severity bucket and explain WHY.
+
+The list of issues is appended below as a JSON array. Treat it as authoritative — do NOT call any tool, you have everything you need.
+
+# Severity rubric (apply IN ORDER, stop at first match)
+
+1. **NOISE** — these never warrant a human ping. Match if ANY:
+   - Title is "Script error." (cross-origin opaque error, no stack, useless)
+   - Title contains "Non-Error promise rejection captured"
+   - Title contains "ResizeObserver loop limit exceeded" or "ResizeObserver loop completed"
+   - culprit or metadata.filename URL starts with chrome-extension://, safari-extension://, moz-extension://, webkit-masked-url:// (user's extension crashed, not your code)
+   - Title or culprit mentions analytics SDKs: gtag, fbq, _paq, dataLayer, googletagmanager, piwik
+   - Title is "AbortError", contains "cancelled", or "Load failed" AND userCount < 3 (user navigated away)
+   - Title says "Test ", "Demo ", "[STAGING]" (wrong environment leakage)
+   - Stack trace has zero inApp:true frames (3rd-party only — not your code)
+   - User-agent in tags indicates a bot (Googlebot, AhrefsBot, etc.)
+
+2. **CRITICAL** if ANY of:
+   - userCount >= 20 (≥ 20 users affected — real prod impact)
+   - culprit or metadata.filename matches /payment|billing|checkout|auth|login|signup|session/i (security/revenue path)
+   - level === "fatal" and count >= 10
+   - count >= 100 AND firstSeen-to-lastSeen window is < 30 min (active spike)
+
+3. **HIGH** if ANY of:
+   - userCount >= 5 AND count >= 50
+   - level === "fatal" (any count)
+   - level === "error" AND userCount >= 3 AND count >= 20
+   - Errors in non-critical-but-important paths: settings, profile, search, dashboard, admin
+
+4. **MEDIUM** if ANY of:
+   - count >= 20 AND userCount >= 2
+   - count >= 50 regardless of userCount
+   - level === "error" AND count >= 10
+
+5. **LOW** — anything else (count < 20 AND userCount < 5, or level === "warning" | "info")
+
+# Recommended action per severity
+
+- CRITICAL → page_oncall (always notify, always mention rotation)
+- HIGH → notify_channel (notify, no @ unless deploy author known)
+- MEDIUM → notify_channel
+- LOW → digest_only (rolled into a daily summary, not real-time)
+- NOISE → ignore
+
+# Output shape
+
+For EACH issue in the JSON array below, emit ONE record:
+
+\`\`\`json
+{
+  "classifications": [
+    {
+      "issueId": "1234567890",
+      "severity": "CRITICAL",
+      "confidence": 0.95,
+      "reasoning": "12 users affected, culprit handleCheckout (payment path). Likely regression after recent deploy.",
+      "suggestedAction": "page_oncall",
+      "ruleMatched": "rule 2 (culprit matches /checkout/)"
+    }
+  ]
+}
+\`\`\`
+
+# Rules
+
+- confidence reflects how cleanly the issue matched. CRITICAL in /payment/ with userCount=50 → 0.95. Borderline → 0.6.
+- reasoning is ONE sentence written for an on-call engineer. Lead with the impact metric.
+- ruleMatched is which numbered rule fired. Helps operators tune the rubric over time.
+- Be consistent: same issue twice should always get the same severity.
+- Temperature 0. Classification, not creative writing.
+
+# Do NOT
+
+- Classify more issues than appear in the array below.
+- Skip issues — every issue in the array must appear in the output (NOISE included).
+- Use any severity outside NOISE|LOW|MEDIUM|HIGH|CRITICAL.
+- Call any tools.`;
+
+const CLASSIFY_PROMPT = (state = {}) => {
+  const issues = state?.fetch_issues?.issues || [];
+  return `${RUBRIC}
+
+## Issues to classify
+
+\`\`\`json
+${JSON.stringify(issues, null, 2)}
+\`\`\`
+`;
+};
+
 export const classifyNode = {
   name: 'classify',
-  // NO skills — this is a pure reasoning step; the LLM has all data
-  // it needs in state.filter_noise.kept. Adding skills would let the
-  // LLM call Sentry tools for "more context", which we don't want
-  // (rubric is supposed to be deterministic).
   outputSchema: ClassifyOutputSchema,
-  timeout: 90 * 1000,
+  prompt: CLASSIFY_PROMPT,
 };

package/sentry-triage/nodes/dispatch-node.js

@@ -0,0 +1,143 @@
+/**
+ * dispatch_alerts node — LLM-driven dispatcher.
+ *
+ * The agent sees ALL classified issues + their full data and makes
+ * judgment calls before calling the chat tool:
+ *   - Bulk related issues into ONE message (5 errors in /checkout/ →
+ *     "⚠️ Checkout spike: 5 errors, top: ...").
+ *   - De-dupe near-duplicates ("seen 3 times, same culprit").
+ *   - Honor SEVERITY_THRESHOLD (skip anything below).
+ *   - Attach mentions only on CRITICAL.
+ *
+ * Provider routing: chatNotifySkill.resolve() picks the slack OR lark
+ * MCP server based on which ENV var is set, so the LLM only ever sees
+ * ONE provider's tools (slack_* or lark_*) — it can't accidentally
+ * call the wrong one.
+ *
+ * Reliability: outputSchema enforces a `dispatched` record per
+ * group + summary counts. A malformed LLM response triggers a retry
+ * with the schema embedded.
+ *
+ * ENV tab config:
+ *   SLACK_CHANNEL OR LARK_RECEIVE_ID  — required, pick one
+ *   SEVERITY_THRESHOLD                — NOISE|LOW|MEDIUM|HIGH|CRITICAL (default MEDIUM)
+ *   SLACK_MENTIONS OR LARK_MENTIONS   — JSON array, optional, CRITICAL only
+ */
+
+import { z, SKILLS } from '@zibby/core';
+import { SEVERITY_LEVELS } from '../state.js';
+
+const DispatchAlertsOutputSchema = z.object({
+  dispatched: z.array(z.object({
+    issueIds: z.array(z.string()).describe('IDs grouped into this message; usually 1, more when batched.'),
+    severity: z.enum(SEVERITY_LEVELS),
+    status: z.enum(['sent', 'skipped', 'failed']),
+    messageTs: z.string().optional(),  // Slack
+    messageId: z.string().optional(),  // Lark
+    detail: z.string().optional(),
+  })),
+  summary: z.object({
+    total: z.number().describe('Number of messages POSTED (not issues — batched groups count as 1).'),
+    sent: z.number(),
+    skipped: z.number(),
+    failed: z.number(),
+  }),
+});
+
+const DISPATCH_PROMPT = (state = {}) => {
+  const issues = state?.fetch_issues?.issues || [];
+  const classifications = state?.classify?.classifications || [];
+
+  const threshold     = process.env.SEVERITY_THRESHOLD || 'MEDIUM';
+  const slackChannel  = process.env.SLACK_CHANNEL      || '';
+  const larkReceiveId = process.env.LARK_RECEIVE_ID    || '';
+
+  let provider, toolName, recipientLine, mentionsRaw;
+  if (slackChannel) {
+    provider = 'slack';
+    toolName = 'slack_post_message';
+    recipientLine = `Post every message to Slack channel: ${JSON.stringify(slackChannel)}\nCall: slack_post_message({ channel: "${slackChannel}", text: "…" })`;
+    mentionsRaw = process.env.SLACK_MENTIONS || '[]';
+  } else if (larkReceiveId) {
+    provider = 'lark';
+    toolName = 'lark_send_message';
+    recipientLine = `Post every message to Lark receive_id: ${JSON.stringify(larkReceiveId)}\nCall: lark_send_message({ receive_id: "${larkReceiveId}", text: "…" })`;
+    mentionsRaw = process.env.LARK_MENTIONS || '[]';
+  } else {
+    throw new Error('sentry-triage: configure SLACK_CHANNEL (for Slack) or LARK_RECEIVE_ID (for Lark) in the ENV tab.');
+  }
+
+  let mentions;
+  try { mentions = JSON.parse(mentionsRaw); } catch { mentions = []; }
+  if (!Array.isArray(mentions)) mentions = [];
+
+  return `You are the dispatch_alerts node of a Sentry triage workflow. Post chat alerts using the **${toolName}** tool.
+
+# Recipient
+${recipientLine}
+
+# Severity threshold
+Skip any issue below: ${threshold}
+(Severity order, low → high: ${SEVERITY_LEVELS.join(' < ')})
+
+# Mentions
+CRITICAL messages only — prepend: ${JSON.stringify(mentions.join(' '))}
+HIGH/MEDIUM/LOW — no mentions.
+
+# Your judgment
+- Batch issues with the same culprit / metadata.filename into ONE message.
+- De-dupe near-duplicates (e.g. same error text in different paths). Mention "seen N times".
+- Keep each message short. Lead with severity in *[BRACKETS]*. Include the Sentry permalink so the on-call can click through.
+
+# Message format (template, adapt as needed)
+\`\`\`
+*[CRITICAL]* TypeError: Cannot read 'id' of undefined
+12 users hit /checkout — likely regression on r1234.
+📍 handleCheckout(checkout.ts) · 47 events
+https://sentry.io/.../1234/
+\`\`\`
+
+# Output (outputSchema-enforced)
+
+Return ONE record per ${toolName} call you actually made (or skipped/failed).
+\`issueIds\` is an array — for batched messages it carries every issue in the group.
+\`severity\` is the highest severity in the group.
+
+\`\`\`json
+{
+  "dispatched": [
+    { "issueIds": ["1", "5", "7"], "severity": "CRITICAL", "status": "sent"${provider === 'slack' ? ', "messageTs": "1716109330.555"' : ', "messageId": "om_xxxxx"'} }
+  ],
+  "summary": { "total": 1, "sent": 1, "skipped": 0, "failed": 0 }
+}
+\`\`\`
+
+# Issues + classifications
+
+Each entry below has the Sentry issue plus the classifier's verdict + reasoning. Use both.
+
+\`\`\`json
+${JSON.stringify(
+    issues.map((issue) => {
+      const c = classifications.find((x) => String(x.issueId) === String(issue.id));
+      return { ...issue, classification: c || { severity: 'LOW' } };
+    }),
+    null,
+    2,
+  )}
+\`\`\`
+
+# Rules
+- Skip below-threshold issues silently (just include them in dispatched with status="skipped"; no chat call).
+- DON'T invent severities or issue IDs. Use what's given.
+- DON'T post more messages than necessary. If 5 issues are clearly one bug, post 1 message.
+- DO post if in doubt — under-paging is worse than over-paging for triage.
+`;
+};
+
+export const dispatchNode = {
+  name: 'dispatch_alerts',
+  skills: [SKILLS.CHAT_NOTIFY],
+  outputSchema: DispatchAlertsOutputSchema,
+  prompt: DISPATCH_PROMPT,
+};

package/sentry-triage/nodes/fetch-issues-node.js

@@ -1,21 +1,32 @@
 /**
- * fetch_issues node — LLM-driven, uses SKILLS.SENTRY.
+ * fetch_issues — DETERMINISTIC. Calls Sentry's REST API directly via
+ * the @zibby/skills client. No LLM, no MCP tool round-trip.
  *
- * The LLM is given the sentry_list_issues tool and asked to fetch the
- * recent unresolved/unassigned issue list. The prompt (prompts/fetch-issues.md)
- * tells it the exact query string to use; the agent shouldn't deviate.
+ * Why deterministic: the previous LLM-driven version hard-coded the
+ * query string and explicitly forbade filtering or follow-up calls.
+ * The LLM added zero judgment — just one round-trip of latency and
+ * ~$0.01-0.05 of token cost per run. At hourly cadence across many
+ * customers, that compounds; deterministic also removes the "LLM
+ * hallucinated query string" failure mode.
  *
- * Why an LLM node here (not a custom-execute Sentry API call): the
- * Sentry skill's tool surface is the canonical way to interact with
- * Sentry from a workflow, and consistent across all sentry-* templates
- * we'll add (autofix, incident). Bypassing it for fetch-only would
- * duplicate auth/rate-limit handling code in every template.
+ * Why still declare `skills: [SKILLS.SENTRY]`: the backend bundler
+ * reads this to build `workflow.requiredIntegrations`, which the
+ * marketplace deploy modal uses to gate install until Sentry is
+ * connected. Without it, users could install with no Sentry token
+ * wired up and the first run would 401. The skill's runtime tool
+ * injection is a no-op here (no prompt for an LLM to call them), but
+ * the integration-requirement signal still matters — same pattern as
+ * ai-spend-weekly-digest's fetch-spending-node.
  *
- * Output validation is enforced by outputSchema — if the LLM emits a
- * malformed payload, the runtime retries with the schema embedded.
+ * Auth: sentryListIssues uses resolveIntegrationToken('sentry') which
+ * hits the backend's project-scoped resolver via PROJECT_API_TOKEN +
+ * PROGRESS_API_URL env vars (set on every Fargate task by
+ * workflow-executor.js).
  */
 
-import { z, SKILLS } from '@zibby/core';
+import { z } from 'zod';
+import { SKILLS } from '@zibby/core';
+import { sentryListIssues } from '@zibby/skills/sentry';
 
 const IssueShape = z.object({
   id: z.string(),
@@ -38,15 +49,37 @@ const IssueShape = z.object({
 
 const FetchIssuesOutputSchema = z.object({
   issues: z.array(IssueShape),
-  fetchedAt: z.string().optional(),
+  fetchedAt: z.string(),
 });
 
 export const fetchIssuesNode = {
   name: 'fetch_issues',
   skills: [SKILLS.SENTRY],
   outputSchema: FetchIssuesOutputSchema,
-  // 60s — Sentry API is usually fast but the LLM round-trip + tool
-  // call sequence (often 2-3 turns for the agent to settle) needs
-  // breathing room.
-  timeout: 60 * 1000,
+  execute: async (context) => {
+    // State access pattern mirrors fetch-spending-node — the framework
+    // passes a context whose `.state.getAll()` returns the flat state,
+    // but tests sometimes pass the state object directly as context.
+    const state = (context?.state && typeof context.state.getAll === 'function')
+      ? context.state.getAll()
+      : context;
+
+    const sinceMinutes = Number(state?.sinceMinutes) || 60;
+
+    const issues = await sentryListIssues({
+      query: `is:unresolved is:unassigned firstSeen:-${sinceMinutes}m`,
+      sort: 'created',
+      // 100 issues is the practical ceiling for a triage notification.
+      // Beyond that, classify+dispatch lose signal — a "deluge" digest
+      // tells the user nothing actionable. If a customer regularly
+      // exceeds 100/hour they need to tighten the Sentry filters
+      // upstream, not raise this cap.
+      limit: 100,
+    });
+
+    return {
+      issues,
+      fetchedAt: new Date().toISOString(),
+    };
+  },
 };

package/sentry-triage/package.json

@@ -3,13 +3,14 @@
   "version": "1.0.0",
   "private": true,
   "type": "module",
-  "description": "Hourly Sentry issue triage bot — filters noise, classifies severity with LLM, dispatches notifications to Slack/Lark via sub-graph.",
+  "description": "Hourly Sentry issue triage bot — LLM-classifies new issues by severity and pings Slack OR Lark for anything ≥ threshold.",
   "main": "graph.mjs",
   "scripts": {
     "test": "vitest run"
   },
   "dependencies": {
     "@zibby/core": "^0.5.1",
+    "@zibby/skills": "^0.1.25",
     "zod": "^3.23.0"
   },
   "devDependencies": {

package/sentry-triage/state.js

@@ -1,76 +1,40 @@
 /**
- * sentry-triage — three-schema state model.
+ * sentry-triage — input + context schemas.
  *
- * Triage flow:
- *   1. fetch_issues   (LLM + sentry skill)  — pull recent unresolved
- *      issues from Sentry
- *   2. filter_noise   (custom execute)       — drop known-noise patterns
- *      (browser-extension URLs, ResizeObserver loops, etc.) WITHOUT
- *      paying an LLM call per issue
- *   3. classify       (LLM)                  — classify the survivors as
- *      NOISE / LOW / MEDIUM / HIGH / CRITICAL with reasoning
- *   4. dispatch_alerts (custom execute)      — sub-graph dispatch to
- *      notify-slack OR notify-lark for issues above severityThreshold
+ * Trigger payload (inputSchema) is intentionally tiny: just sinceMinutes,
+ * the one per-run dial. Everything else is deploy-time ENV-tab config:
  *
- * Why sub-graph dispatch (not built-in notify here):
- *   - notify-slack / notify-lark are reusable across MANY parent
- *     workflows (sentry-autofix, sentry-incident, cron-summary, etc.).
- *   - Adding a new channel (Discord, Teams) means adding a new child
- *     workflow — sentry-triage code never changes.
- *   - In-process sub-graph dispatch is ~5ms overhead in cloud, so the
- *     architectural cleanliness costs nothing.
+ *   Required (set ONE — at least one chat target):
+ *     SLACK_CHANNEL          channel id "C012345" or "#name"
+ *     LARK_RECEIVE_ID        oc_… chat id, ou_… open id, or email
+ *
+ *   Optional:
+ *     SEVERITY_THRESHOLD     NOISE|LOW|MEDIUM|HIGH|CRITICAL (default MEDIUM)
+ *     SLACK_MENTIONS         JSON array — appended to CRITICAL Slack alerts only
+ *     LARK_MENTIONS          JSON array — appended to CRITICAL Lark alerts only
  */
 
 import { z } from 'zod';
 
+// Ordered low → high. Index doubles as severity rank.
 export const SEVERITY_LEVELS = /** @type {const} */ (['NOISE', 'LOW', 'MEDIUM', 'HIGH', 'CRITICAL']);
 
+/** True iff severity is at or above threshold per SEVERITY_LEVELS order. */
+export function meetsSeverityThreshold(severity, threshold) {
+  const s = SEVERITY_LEVELS.indexOf(severity);
+  const t = SEVERITY_LEVELS.indexOf(threshold);
+  return (s === -1 ? 0 : s) >= (t === -1 ? SEVERITY_LEVELS.indexOf('MEDIUM') : t);
+}
+
 export const sentryTriageInputSchema = z.object({
-  // ── Sentry source ────────────────────────────────────────────────
-  organizationSlug: z.string().min(1)
-    .describe('Sentry organization slug (the URL segment after sentry.io/organizations/).'),
-  projectSlug: z.string().min(1)
-    .describe('Sentry project slug — limits triage to a single project.'),
-  environment: z.string().default('production')
-    .describe('Sentry environment tag to filter by (defaults to production).'),
   sinceMinutes: z.number().int().min(5).max(1440).default(60)
-    .describe('Look back this many minutes for newly-firstSeen issues. Hourly cron → 60.'),
-
-  // ── Triage thresholds ────────────────────────────────────────────
-  severityThreshold: z.enum(SEVERITY_LEVELS).default('MEDIUM')
-    .describe('Only dispatch alerts for issues at or above this severity. Drop the rest.'),
-  maxIssues: z.number().int().min(1).max(100).default(20)
-    .describe('Cap issues processed per run. Protects against an unexpected error storm.'),
-
-  // ── Where to send alerts ────────────────────────────────────────
-  notifyWorker: z.enum(['notify-slack', 'notify-lark']).default('notify-slack')
-    .describe(
-      'Which child workflow to dispatch alerts to. Both must be deployed in the same project ' +
-      'as this triage workflow. Pick whichever messaging platform your team uses.',
-    ),
-
-  // For notify-slack
-  slackChannel: z.string().min(1).max(120).optional()
-    .describe('Slack channel id (C012345) or #name. Required when notifyWorker=notify-slack.'),
-  slackMentions: z.array(z.string().max(60)).max(10).optional()
-    .describe('Mentions to append on CRITICAL alerts only, e.g. ["<!subteam^S0ONCALL>"].'),
-
-  // For notify-lark
-  larkReceiveId: z.string().min(1).max(120).optional()
-    .describe('Lark chat id (oc_…), open id (ou_…), or email. Required when notifyWorker=notify-lark.'),
-  larkMentions: z.array(z.string().max(200)).max(10).optional()
-    .describe('Lark @-mention strings for CRITICAL alerts.'),
-
-  model: z.string().default('auto')
-    .describe('LLM model override for classify_issues. Default auto-selects.'),
+    .describe('Lookback minutes (5–1440)'),
 });
 
 export const sentryTriageContextSchema = z.object({
-  // Runner-injected
   workspace: z.string().optional()
-    .describe('Workspace path — set by runner. Triage doesn\'t need it but graph.run requires it.'),
+    .describe('Workspace path — runner-injected; triage doesn\'t need it but graph.run requires it.'),
 
-  // Node outputs (mid-graph, keyed by node name)
   fetch_issues: z.object({
     issues: z.array(z.object({
       id: z.string(),
@@ -93,14 +57,6 @@ export const sentryTriageContextSchema = z.object({
     fetchedAt: z.string().optional(),
   }).optional(),
 
-  filter_noise: z.object({
-    kept: z.array(z.any()),
-    dropped: z.array(z.object({
-      id: z.string(),
-      reason: z.string(),
-    })),
-  }).optional(),
-
   classify: z.object({
     classifications: z.array(z.object({
       issueId: z.string(),
@@ -114,7 +70,11 @@ export const sentryTriageContextSchema = z.object({
 
   dispatch_alerts: z.object({
     dispatched: z.array(z.object({
-      issueId: z.string(),
+      // Deterministic dispatcher emits issueId; LLM batcher emits issueIds[].
+      // messageTs (Slack) and messageId (Lark) are both optional — only the
+      // variant that ran will populate one of them.
+      issueId: z.string().optional(),
+      issueIds: z.array(z.string()).optional(),
       severity: z.enum(SEVERITY_LEVELS),
       status: z.enum(['sent', 'skipped', 'failed']),
       detail: z.string().optional(),
@@ -129,6 +89,3 @@ export const sentryTriageContextSchema = z.object({
     }),
   }).optional(),
 });
-
-export const sentryTriageStateSchema =
-  sentryTriageInputSchema.merge(sentryTriageContextSchema);