@zibby/workflow-templates 0.4.2 → 0.7.1

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

@@ -0,0 +1,262 @@
+/**
+ * dispatch_alerts node — LLM-driven dispatcher with author routing.
+ *
+ * The agent reads each classified issue (+ its Sentry suspectCommits
+ * author, when available) and decides per-issue where to send the
+ * alert. Three layers of decisioning, top-down:
+ *
+ *   1. `DISPATCH_RULES` (free-form natural-language override)
+ *      — when set, the agent applies these rules verbatim and treats
+ *        the structured env vars below as defaults. For advanced
+ *        routing ("security tag always pages @security regardless of
+ *        severity", "weekend hours quiet unless CRITICAL", etc.).
+ *
+ *   2. Structured env vars (the 90% path):
+ *        SLACK_CHANNEL / LARK_RECEIVE_ID   — pick provider, channel fallback
+ *        SEVERITY_THRESHOLD                — skip anything below
+ *        ROUTING_PREFER_AUTHOR             — if suspectCommit.author email
+ *                                            resolves to a user, DM them
+ *        ROUTING_HIGH_SEVERITY_GROUP       — handle/id of a Slack
+ *                                            usergroup (@oncall) that gets
+ *                                            mentioned on CRITICAL/HIGH
+ *        SLACK_MENTIONS / LARK_MENTIONS    — flat mention list, CRITICAL only
+ *
+ *   3. Built-in defaults (when neither rules nor env set anything):
+ *        - threshold MEDIUM, no author DM, channel-only post.
+ *
+ * Author-routing tools the agent has access to (from the slack/lark
+ * skills via SKILLS.CHAT_NOTIFY):
+ *   slack:
+ *     - slack_lookup_user_by_email   email → user id (DM target)
+ *     - slack_list_usergroups        list @oncall etc., with handle + count
+ *     - slack_get_usergroup_members  expand a group → user ids
+ *     - slack_post_message           DM user id OR channel
+ *   lark:
+ *     - lark_lookup_user_by_email    email → open_id (DM target)
+ *     - lark_send_message            DM open_id OR oc_* group chat
+ *
+ * Provider selection: chatNotifySkill.resolve() picks slack or lark
+ * based on which env var (`SLACK_CHANNEL` or `LARK_RECEIVE_ID`) the
+ * project sets. The LLM only sees one provider's tools, so it can't
+ * accidentally fan out to the wrong workspace.
+ *
+ * Reliability: outputSchema enforces a per-dispatch record + summary.
+ * A malformed LLM response triggers a retry with the schema embedded.
+ *
+ * ENV tab config — required:
+ *   SLACK_CHANNEL OR LARK_RECEIVE_ID  — provider selector + channel fallback
+ *
+ * ENV tab config — optional:
+ *   SEVERITY_THRESHOLD                — NOISE|LOW|MEDIUM|HIGH|CRITICAL (default MEDIUM)
+ *   ROUTING_PREFER_AUTHOR             — "true" enables suspectCommit author DM
+ *   ROUTING_HIGH_SEVERITY_GROUP       — e.g. "@oncall" or "S012ABC" (Slack usergroup id)
+ *   SLACK_MENTIONS / LARK_MENTIONS    — JSON array of mentions on CRITICAL
+ *   DISPATCH_RULES                    — free-form natural-language overrides
+ */
+
+import { z, SKILLS } from '@zibby/core';
+import { SEVERITY_LEVELS } from '../state.js';
+
+const DispatchedRecordSchema = 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']),
+  // Who actually received this message. Helps post-hoc auditing of
+  // routing decisions ("why did the agent send this to @sarah?").
+  recipient: z.object({
+    kind: z.enum(['channel', 'user_dm', 'usergroup']).optional(),
+    id: z.string().optional(),
+    label: z.string().optional(),
+  }).optional(),
+  messageTs: z.string().optional(),  // Slack
+  messageId: z.string().optional(),  // Lark
+  detail: z.string().optional(),
+});
+
+const DispatchAlertsOutputSchema = z.object({
+  dispatched: z.array(DispatchedRecordSchema),
+  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 SEVERITY_ORDER = ['NOISE', 'LOW', 'MEDIUM', 'HIGH', 'CRITICAL'];
+
+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          || '';
+  const preferAuthor    = /^(1|true|yes|on)$/i.test(process.env.ROUTING_PREFER_AUTHOR || '');
+  const highSevGroup    = process.env.ROUTING_HIGH_SEVERITY_GROUP || '';
+  const dispatchRules   = process.env.DISPATCH_RULES           || '';
+
+  // ── No-op short-circuit ─────────────────────────────────────────
+  // Same three "nothing to do this run" cases as before — keep the
+  // run green without forcing channel setup.
+  const minSeverityRank = SEVERITY_ORDER.indexOf(threshold);
+  const aboveThreshold = minSeverityRank < 0
+    ? classifications
+    : classifications.filter((c) => SEVERITY_ORDER.indexOf(c.severity) >= minSeverityRank);
+
+  if (issues.length === 0 || classifications.length === 0 || aboveThreshold.length === 0) {
+    const reason =
+      issues.length === 0          ? 'fetch_issues returned no issues' :
+      classifications.length === 0 ? 'classifier emitted no records' :
+                                     `all ${classifications.length} issue(s) below SEVERITY_THRESHOLD=${threshold}`;
+    return `No Sentry issues to dispatch this run (${reason}).
+
+Return this exact JSON envelope and call no tools:
+
+\`\`\`json
+{ "dispatched": [], "summary": { "total": 0, "sent": 0, "skipped": 0, "failed": 0 } }
+\`\`\`
+`;
+  }
+
+  // ── Provider selection ──────────────────────────────────────────
+  let provider, postTool, lookupTool, channelId, mentionsRaw;
+  if (slackChannel) {
+    provider    = 'slack';
+    postTool    = 'slack_post_message';
+    lookupTool  = 'slack_lookup_user_by_email';
+    channelId   = slackChannel;
+    mentionsRaw = process.env.SLACK_MENTIONS || '[]';
+  } else if (larkReceiveId) {
+    provider    = 'lark';
+    postTool    = 'lark_send_message';
+    lookupTool  = 'lark_lookup_user_by_email';
+    channelId   = larkReceiveId;
+    mentionsRaw = process.env.LARK_MENTIONS || '[]';
+  } else {
+    throw new Error(
+      'sentry-triage has issues to dispatch but no destination configured. ' +
+      'Go to Project Settings -> ENV and set ONE of:\n' +
+      '  - SLACK_CHANNEL=#your-alerts-channel    (uses connected Slack integration)\n' +
+      '  - LARK_RECEIVE_ID=oc_xxxxxxxx           (uses connected Lark integration)\n' +
+      'The integration OAuth token gives the workflow auth, but you still need to tell it WHERE to post.'
+    );
+  }
+
+  let mentions;
+  try { mentions = JSON.parse(mentionsRaw); } catch { mentions = []; }
+  if (!Array.isArray(mentions)) mentions = [];
+
+  // ── Routing policy block ────────────────────────────────────────
+  // Two voices: a default policy (always rendered, derived from env
+  // vars) and the optional natural-language override (rendered only
+  // when DISPATCH_RULES is set). When the override exists, the
+  // agent is told to treat it as authoritative.
+  const defaultPolicyLines = [
+    `Skip any classification below severity ${threshold}.`,
+    `Channel fallback (every alert at minimum goes here): ${JSON.stringify(channelId)}`,
+  ];
+  if (preferAuthor) {
+    defaultPolicyLines.push(
+      `Author-DM enabled: when an issue has \`suspectCommits[0].authorEmail\`, FIRST call \`${lookupTool}({ email })\`. ` +
+      `If \`ok:true\`, send the alert as a DM to that user (use their id as the recipient — Slack ${'`channel`'}, Lark ${'`receive_id`'}). ` +
+      `Also still post to the channel fallback above so the team has visibility. ` +
+      `If \`ok:false\` or there's no email, channel-only.`
+    );
+  } else {
+    defaultPolicyLines.push(
+      `Author-DM disabled (ROUTING_PREFER_AUTHOR=false). Post all alerts to the channel fallback.`
+    );
+  }
+  if (highSevGroup) {
+    defaultPolicyLines.push(
+      provider === 'slack'
+        ? `High-severity escalation: on CRITICAL/HIGH, mention the Slack usergroup ${JSON.stringify(highSevGroup)} in the channel message. ` +
+          `If it's a handle (starts with @), call \`slack_list_usergroups\` once to resolve handle → id, then mention as \`<!subteam^ID>\`. ` +
+          `If it already looks like an id (starts with "S"), mention directly as \`<!subteam^${highSevGroup}>\`.`
+        : `High-severity escalation: on CRITICAL/HIGH, also send the alert to the chat/user ${JSON.stringify(highSevGroup)} (Lark receive_id).`
+    );
+  }
+  if (mentions.length > 0) {
+    defaultPolicyLines.push(`CRITICAL messages prepend: ${JSON.stringify(mentions.join(' '))}`);
+  }
+
+  const policyBlock = defaultPolicyLines.map((l, i) => `${i + 1}. ${l}`).join('\n');
+
+  const overrideBlock = dispatchRules
+    ? `\n\n# DISPATCH_RULES (override — authoritative)\nThe project has set custom routing rules. Apply these verbatim; the defaults above are only fallbacks for behavior the rules don't cover.\n\n${dispatchRules.trim()}\n`
+    : '';
+
+  // ── Prompt body ─────────────────────────────────────────────────
+  return `You are the dispatch_alerts node of a Sentry triage workflow. Post chat alerts using the **${postTool}** tool (and the lookup helpers below for author routing).
+
+# Default routing policy
+${policyBlock}${overrideBlock}
+
+# Severity scale
+${SEVERITY_LEVELS.join(' < ')}
+
+# Tools you should use
+- \`${postTool}\` — post the message (channel id OR user/DM id for the recipient field).
+- \`${lookupTool}\` — resolve an email to a user id. **Important**: this can return \`{ ok: false }\` — handle that by falling back to channel-only, don't retry with variations of the email.
+${provider === 'slack' ? '- `slack_list_usergroups` / `slack_get_usergroup_members` — expand @group → user ids.' : ''}
+
+# Your judgment (unchanged from before)
+- Batch issues with the same culprit / metadata.filename into ONE message.
+- De-dupe near-duplicates ("seen N times"). Keep messages short. Lead with severity in *[BRACKETS]*. Include Sentry permalinks.
+
+# Message format
+\`\`\`
+*[CRITICAL]* TypeError: Cannot read 'id' of undefined
+12 users hit /checkout — likely regression on r1234.
+📍 handleCheckout(checkout.ts) · 47 events
+Suspect commit: a1b2c3d4 by sarah@acme.com — "refactor checkout state"
+https://sentry.io/.../1234/
+\`\`\`
+
+# Output (outputSchema-enforced)
+Return ONE record per dispatch call you actually made (or skipped/failed). \`issueIds\` is an array — batched messages carry every issue in the group. \`recipient\` records who got the message (channel id, user id, or usergroup id) so the audit trail shows the routing decision.
+
+\`\`\`json
+{
+  "dispatched": [
+    {
+      "issueIds": ["1", "5"],
+      "severity": "CRITICAL",
+      "status": "sent",
+      "recipient": { "kind": "user_dm", "id": "U012ABC", "label": "sarah@acme.com" }${provider === 'slack' ? ',\n      "messageTs": "1716109330.555"' : ',\n      "messageId": "om_xxxxx"'}
+    }
+  ],
+  "summary": { "total": 1, "sent": 1, "skipped": 0, "failed": 0 }
+}
+\`\`\`
+
+# Issues + classifications + suspect commits
+
+Each entry has the Sentry issue, the classifier's verdict, and any suspect commits Sentry's GitHub integration could blame. **An empty \`suspectCommits\` array means the team hasn't set up Sentry's GitHub integration OR the file wasn't touched in the last 14 days** — fall back to channel-only routing in that case.
+
+\`\`\`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 (status="skipped"; no chat call). Include them in \`dispatched\` so the run record is complete.
+- DON'T invent severities, issue IDs, or email addresses. Only use what's in the data block above.
+- 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.
+`;
+};
+
+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,46 @@
 /**
- * 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, sentryGetIssue } from '@zibby/skills/sentry';
+
+// Per-commit shape Sentry returns under `suspectCommits[]`. We only
+// surface what the dispatch agent actually uses for routing — author
+// email (→ slack_lookup_user_by_email) + a short SHA + the commit
+// message so the agent can sanity-check "is this commit plausibly the
+// cause?". Everything else (date, repository url, etc.) is dropped to
+// keep the per-issue payload small.
+const SuspectCommitShape = z.object({
+  id: z.string().optional(),
+  shortId: z.string().optional(),
+  message: z.string().optional(),
+  authorEmail: z.string().optional(),
+  authorName: z.string().optional(),
+});
 
 const IssueShape = z.object({
   id: z.string(),
@@ -34,19 +59,107 @@ const IssueShape = z.object({
     value: z.string().optional(),
     filename: z.string().optional(),
   }).optional(),
+  // Populated by the per-issue sentryGetIssue() fetch below. Empty
+  // array when Sentry's GitHub integration can't blame the issue's
+  // stack frames to any recent commits (no integration / no code
+  // mapping / file untouched in 14 days).
+  suspectCommits: z.array(SuspectCommitShape).optional(),
 });
 
 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 query = `is:unresolved is:unassigned firstSeen:-${sinceMinutes}m`;
+
+    // Surface intent BEFORE the call. Deterministic nodes don't go
+    // through an LLM that would print its reasoning, so the activity
+    // panel would otherwise just show "started" then a result count —
+    // operators have no way to tell what query ran or whether the empty
+    // result was "Sentry returned nothing" vs "we asked the wrong
+    // question". Two-line preamble fixes that without log-spam.
+    console.log(`Sentry query: ${query}`);
+    console.log(`Sort: new (firstSeen desc) · Limit: 100`);
+
+    const issues = await sentryListIssues({
+      query,
+      // Sentry's /projects/{org}/{project}/issues/ endpoint only accepts
+      // these sort keys: date | new | priority | freq | user. `new` sorts
+      // by firstSeen desc which matches our triage intent (newest issues
+      // surface first). `created` was wrong and made Sentry return 400.
+      sort: 'new',
+      // 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,
+    });
+
+    // Always log the count + a head sample. On 0 issues this prints
+    // "Fetched 0 issues" which is the actionable signal — operator
+    // knows the query worked but there's nothing new to triage.
+    console.log(`Fetched ${issues.length} issue${issues.length === 1 ? '' : 's'} from Sentry`);
+    if (issues.length > 0) {
+      const preview = issues.slice(0, 5).map((i) => `  - ${i.shortId || i.id} [${i.level || '?'}] ${i.title || '(no title)'}`);
+      console.log(preview.join('\n'));
+      if (issues.length > 5) console.log(`  ... (${issues.length - 5} more)`);
+    }
+
+    // Enrich each issue with `suspectCommits` (author email + SHA +
+    // commit message). The /issues/ list endpoint does NOT include
+    // suspectCommits — only /issues/<id>/ does. So we do N parallel
+    // GETs to hydrate. Practical concerns:
+    //
+    //   - N is capped at 100 (the list limit above). One parallel
+    //     batch finishes in ~1-2s against sentry.io.
+    //   - Per-issue failures are swallowed (logged + empty array)
+    //     so one 404 doesn't break the entire run. The classifier
+    //     downstream doesn't NEED suspectCommits to function — it's
+    //     a routing hint, not a classification input.
+    //   - When the customer hasn't installed Sentry's GitHub
+    //     integration OR hasn't configured Code Mappings, every
+    //     issue will come back with suspectCommits=[]. That's the
+    //     designed-for steady state; dispatch agent falls back to
+    //     channel-only routing.
+    const enriched = await Promise.all(
+      issues.map(async (issue) => {
+        try {
+          const detail = await sentryGetIssue(issue.id);
+          const sc = (detail?.suspectCommits || []).map((c) => ({
+            id: c.id,
+            shortId: c.shortId || (c.id ? String(c.id).slice(0, 7) : undefined),
+            message: c.message,
+            authorEmail: c.author?.email,
+            authorName: c.author?.name,
+          }));
+          return { ...issue, suspectCommits: sc };
+        } catch (err) {
+          console.warn(`  · suspectCommits fetch failed for ${issue.shortId || issue.id}: ${err.message}`);
+          return { ...issue, suspectCommits: [] };
+        }
+      })
+    );
+    const withAuthor = enriched.filter((i) => (i.suspectCommits || []).some((c) => c.authorEmail)).length;
+    console.log(`Hydrated suspectCommits — ${withAuthor}/${enriched.length} issue(s) have an identifiable author.`);
+
+    return {
+      issues: enriched,
+      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.26",
     "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);