@sweny-ai/core 0.1.177 → 0.1.178

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/schema.js CHANGED
@@ -7,7 +7,7 @@
7
7
  * parsing untrusted input (JSON/YAML import, Studio editor).
8
8
  */
9
9
  import { z } from "zod";
10
- import { AUTHOR_ASSOCIATIONS, CONTEXT_MODES, EVALUATOR_KINDS, EVAL_POLICIES, MCP_TRANSPORTS, NODE_ACCESS, NODE_ON_FAIL, REQUIRES_ON_FAIL, SAFE_OUTPUT_APPLIERS, SAFE_OUTPUT_EXPIRES_PATTERN, SAFE_OUTPUT_MAX_CEILING, SAFE_OUTPUT_STATES, SAFE_OUTPUT_TYPES, SKILL_CATEGORIES, SKILL_ID_MAX_LENGTH, SKILL_ID_PATTERN, TOOL_ACCESS, TOOL_CLASSES, WORKFLOW_TYPES, } from "./types.js";
10
+ import { AUTHOR_ASSOCIATIONS, CONTEXT_MODES, DECIDER_CONFIDENCE_FLOOR, DECIDER_MARGIN_FLOOR, DECIDER_MIN_CONFIDENCE, DECIDER_MIN_MARGIN, DECIDER_MODE_REMOVED, DECIDER_PROVIDER_MOVED, EVALUATOR_KINDS, EVAL_POLICIES, MCP_TRANSPORTS, NODE_ACCESS, NODE_ON_FAIL, REQUIRES_ON_FAIL, ROUTE_BY, SAFE_OUTPUT_APPLIERS, SAFE_OUTPUT_EXPIRES_PATTERN, SAFE_OUTPUT_MAX_CEILING, SAFE_OUTPUT_STATES, SAFE_OUTPUT_TYPES, SKILL_CATEGORIES, SKILL_ID_MAX_LENGTH, SKILL_ID_PATTERN, TOOL_ACCESS, TOOL_CLASSES, WORKFLOW_TYPES, } from "./types.js";
11
11
  import { sourceZ } from "./sources.js";
12
12
  import { resolveNodePermissions } from "./node-policy.js";
13
13
  import { workflowInputsZ, WORKFLOW_INPUT_TYPES } from "./inputs.js";
@@ -280,26 +280,22 @@ export const budgetZ = z
280
280
  message: "budget must declare at least one of tokens, cost_usd",
281
281
  });
282
282
  /**
283
- * Decision model for route choices (#357). `shadow` needs a provider; the
284
- * state only ever goes to that `base_url`, there is no fallback. The key is
285
- * named by env var, never inlined.
283
+ * Decision model thresholds (#357) for the nodes that set `route_by:
284
+ * decider`. Thresholds may be raised, and lowered no further than the floors.
285
+ * The provider (endpoint, model, key) comes only from operator config.
286
+ *
287
+ * Shapes from the shadow-mode release fail with an explanation instead of
288
+ * silently changing routing: `mode` ({@link DECIDER_MODE_REMOVED}) and
289
+ * `provider` ({@link DECIDER_PROVIDER_MOVED}).
286
290
  */
287
291
  export const deciderZ = z
288
292
  .object({
289
- mode: z.enum(["off", "shadow"]),
290
- provider: z
291
- .object({
292
- base_url: z.string().url(),
293
- model: z.string().min(1),
294
- api_key_env: z.string().min(1).optional(),
295
- })
296
- .strict()
297
- .optional(),
293
+ mode: z.custom(() => false, { message: DECIDER_MODE_REMOVED }).optional(),
294
+ provider: z.custom(() => false, { message: DECIDER_PROVIDER_MOVED }).optional(),
295
+ min_confidence: z.number().min(DECIDER_CONFIDENCE_FLOOR).max(1).optional(),
296
+ min_margin: z.number().min(DECIDER_MARGIN_FLOOR).max(1).optional(),
298
297
  })
299
- .strict()
300
- .refine((d) => d.mode === "off" || d.provider !== undefined, {
301
- message: "decider.provider is required when mode is shadow",
302
- });
298
+ .strict();
303
299
  /** One typed write intent a node may emit (#365). */
304
300
  export const safeOutputDeclarationZ = z
305
301
  .object({
@@ -342,6 +338,7 @@ export const nodeZ = z
342
338
  tools: nodeToolsZ.optional(),
343
339
  fail_soft: z.boolean().optional(),
344
340
  on_fail: z.enum(NODE_ON_FAIL).optional(),
341
+ route_by: z.enum(ROUTE_BY).optional(),
345
342
  permissions: nodePermissionsZ.optional(),
346
343
  outputs: z.array(safeOutputDeclarationZ).min(1).optional(),
347
344
  rules: nodeSourcesZ.optional(),
@@ -361,6 +358,7 @@ export const edgeZ = z
361
358
  // Natural language (the harness picks the edge) or `{ expr }`, a
362
359
  // deterministic expression sweny evaluates itself (#461). One or the other.
363
360
  when: z.union([z.string(), z.object({ expr: z.string().min(1).max(WHEN_EXPR_MAX_LENGTH) }).strict()]).optional(),
361
+ description: z.string().min(1).optional(),
364
362
  max_iterations: z.number().int().min(1).max(EDGE_MAX_ITERATIONS_CEILING).optional(),
365
363
  })
366
364
  .strict();
@@ -478,6 +476,22 @@ export function validateWorkflow(workflow, knownSkills) {
478
476
  else
479
477
  m.set(k, [v]);
480
478
  };
479
+ // One edge per (from, to) pair (#357). A route picks a target node, so two
480
+ // edges to the same target would make their conditions ambiguous (which
481
+ // one's max_iterations counts, which one's condition the router saw). Write
482
+ // one edge whose condition covers both cases instead.
483
+ const seenPairs = new Set();
484
+ for (const edge of workflow.edges) {
485
+ const key = JSON.stringify([edge.from, edge.to]);
486
+ if (seenPairs.has(key)) {
487
+ errors.push({
488
+ code: "DUPLICATE_EDGE",
489
+ message: `More than one edge from "${edge.from}" to "${edge.to}"; merge them into one edge (combine the conditions with OR)`,
490
+ nodeId: edge.from,
491
+ });
492
+ }
493
+ seenPairs.add(key);
494
+ }
481
495
  // Edge targets must exist
482
496
  for (const edge of workflow.edges) {
483
497
  if (!nodeIds.has(edge.from)) {
@@ -1000,28 +1014,24 @@ export const workflowJsonSchema = {
1000
1014
  },
1001
1015
  Decider: {
1002
1016
  type: "object",
1003
- required: ["mode"],
1004
1017
  additionalProperties: false,
1005
- description: "Decision model for route choices. 'shadow' asks it alongside the agent and logs whether they agree; the route is always the agent's. The workflow state goes only to provider.base_url, with no fallback.",
1018
+ description: "Decision model thresholds for the nodes that set route_by: decider. The provider (URL, model, key) comes only from operator config (.sweny.yml or SWENY_DECIDER_* env), never from the workflow; 'provider' and the removed 'mode' key are rejected.",
1006
1019
  properties: {
1007
- mode: { type: "string", enum: ["off", "shadow"] },
1008
- provider: {
1009
- type: "object",
1010
- required: ["base_url", "model"],
1011
- additionalProperties: false,
1012
- properties: {
1013
- base_url: {
1014
- type: "string",
1015
- format: "uri",
1016
- description: "Server root serving POST /v1/systemone (Ollama or TypeSafe Jev).",
1017
- },
1018
- model: { type: "string", minLength: 1 },
1019
- api_key_env: { type: "string", minLength: 1, description: "Env var holding the bearer key." },
1020
- },
1020
+ min_confidence: {
1021
+ type: "number",
1022
+ minimum: DECIDER_CONFIDENCE_FLOOR,
1023
+ maximum: 1,
1024
+ default: DECIDER_MIN_CONFIDENCE,
1025
+ description: "Accept the decider's answer only at or above this confidence.",
1026
+ },
1027
+ min_margin: {
1028
+ type: "number",
1029
+ minimum: DECIDER_MARGIN_FLOOR,
1030
+ maximum: 1,
1031
+ default: DECIDER_MIN_MARGIN,
1032
+ description: "Accept it only when the top label leads the runner-up by at least this much.",
1021
1033
  },
1022
1034
  },
1023
- if: { properties: { mode: { const: "shadow" } } },
1024
- then: { required: ["provider"] },
1025
1035
  },
1026
1036
  SafeOutput: {
1027
1037
  type: "object",
@@ -1174,7 +1184,7 @@ export const workflowJsonSchema = {
1174
1184
  },
1175
1185
  decider: {
1176
1186
  $ref: "#/$defs/Decider",
1177
- description: "Decision model for route choices (shadow mode only). Default: off.",
1187
+ description: "Thresholds for the decision model that decides the routes of route_by: decider nodes when confident. Default: 0.85 confidence, 0.2 margin.",
1178
1188
  },
1179
1189
  context_mode: {
1180
1190
  type: "string",
@@ -1335,6 +1345,11 @@ export const workflowJsonSchema = {
1335
1345
  enum: [...NODE_ON_FAIL],
1336
1346
  description: "What to do when this node finishes 'failed' (agent-level failure, or an eval failure that exhausted retries and was not softened by fail_soft). 'halt' (default) stops the workflow with the failure surfaced so a broken node never advances down a conditional edge; 'continue' preserves the legacy fall-through where routing proceeds from the failed node. Distinct from requires.on_fail (the pre-condition gate).",
1337
1347
  },
1348
+ route_by: {
1349
+ type: "string",
1350
+ enum: [...ROUTE_BY],
1351
+ description: "Who picks this node's natural-language route. 'agent' (default): the agent's route evaluation. 'decider': the operator's decision model first, the agent when it is not confident. Expressions always win over both; put safety conditions in expressions.",
1352
+ },
1338
1353
  permissions: {
1339
1354
  $ref: "#/$defs/Permissions",
1340
1355
  description: "What this node's agent may do. Absent: read when the node declares outputs, else the workflow's permissions, else write.",
@@ -1456,6 +1471,11 @@ export const workflowJsonSchema = {
1456
1471
  },
1457
1472
  ],
1458
1473
  },
1474
+ description: {
1475
+ type: "string",
1476
+ minLength: 1,
1477
+ description: "The condition in natural language. For an { expr } edge, what the next rung reads when the expression cannot be evaluated because a field it needs is missing or invalid.",
1478
+ },
1459
1479
  max_iterations: {
1460
1480
  type: "integer",
1461
1481
  minimum: 1,
package/dist/types.d.ts CHANGED
@@ -418,6 +418,13 @@ export interface Node {
418
418
  * Distinct from `requires.on_fail`, which is the pre-condition gate.
419
419
  */
420
420
  on_fail?: NodeOnFail;
421
+ /**
422
+ * Who picks this node's natural-language route (#357). `agent` (default):
423
+ * the agent's route evaluation. `decider`: the operator's decision model is
424
+ * asked first and its confident answer is the route; otherwise the agent.
425
+ * Expressions always win over both. Safety conditions belong in expressions.
426
+ */
427
+ route_by?: RouteBy;
421
428
  /**
422
429
  * What this node's agent may do (#365). `read` runs the node read-only:
423
430
  * only `access: "read"` skill tools, no external skill MCP servers, no
@@ -555,6 +562,12 @@ export interface Edge {
555
562
  * evaluated by sweny with no model call.
556
563
  */
557
564
  when?: EdgeWhen;
565
+ /**
566
+ * The condition in natural language (#357). For an `{ expr }` edge it is
567
+ * what the next rung (decider or agent) reads when the expression cannot be
568
+ * evaluated because a field it needs is missing or invalid.
569
+ */
570
+ description?: string;
558
571
  /** Max times this edge can be followed (enables retry loops). Default: unlimited. */
559
572
  max_iterations?: number;
560
573
  }
@@ -569,6 +582,25 @@ export interface Edge {
569
582
  */
570
583
  export declare const WORKFLOW_TYPES: readonly ["pr_review", "e2e_test", "content_generation", "monitor", "data_sync", "generic"];
571
584
  export type WorkflowType = (typeof WORKFLOW_TYPES)[number];
585
+ /**
586
+ * Decision model gates (#357). Shared by the Zod schema, the JSON schema and
587
+ * the executor; kept here so schema-only (browser) consumers need no Node code.
588
+ */
589
+ /** Default: accept a decider answer only at or above this confidence. */
590
+ export declare const DECIDER_MIN_CONFIDENCE = 0.85;
591
+ /** Default: ... and only when the top label leads the runner-up by at least this much. */
592
+ export declare const DECIDER_MIN_MARGIN = 0.2;
593
+ /** A workflow may lower `min_confidence` to this and no further. */
594
+ export declare const DECIDER_CONFIDENCE_FLOOR = 0.7;
595
+ /** A workflow may lower `min_margin` to this and no further. */
596
+ export declare const DECIDER_MARGIN_FLOOR = 0.1;
597
+ /** `route_by` values: who picks a node's natural-language route. */
598
+ export declare const ROUTE_BY: readonly ["agent", "decider"];
599
+ export type RouteBy = (typeof ROUTE_BY)[number];
600
+ /** Load error for a workflow that still declares the removed `decider.mode`. */
601
+ export declare const DECIDER_MODE_REMOVED: string;
602
+ /** Load error for a workflow that declares the provider itself. */
603
+ export declare const DECIDER_PROVIDER_MOVED: string;
572
604
  /** A complete workflow definition. Pure data, fully serializable. */
573
605
  export interface Workflow {
574
606
  id: string;
@@ -598,8 +630,9 @@ export interface Workflow {
598
630
  */
599
631
  budget?: Budget;
600
632
  /**
601
- * Decision model for route choices (#357). `shadow` asks it alongside the
602
- * agent and logs agreement; the route is always the agent's. Default: off.
633
+ * Decision model thresholds (#357) for the nodes that set `route_by:
634
+ * decider`. Never looser than the floors. The provider itself comes only
635
+ * from operator config, never from the workflow.
603
636
  */
604
637
  decider?: DeciderConfig;
605
638
  /**
@@ -801,12 +834,19 @@ export interface TraceStep {
801
834
  /** 0-indexed retry attempt for this iteration. Absent when no retry fired. */
802
835
  retryAttempt?: number;
803
836
  }
837
+ /**
838
+ * Which rung of the route ladder chose a conditional route (#357): a `when`
839
+ * expression, the decision model, or the agent's route evaluation.
840
+ */
841
+ export type RouteRung = "expr" | "decider" | "agent";
804
842
  /** A routing decision between nodes */
805
843
  export interface TraceEdge {
806
844
  from: string;
807
845
  to: string;
808
846
  /** Why this edge was chosen (condition text or "only path") */
809
847
  reason: string;
848
+ /** Who chose it. Absent for an unconditional edge (nothing to decide). */
849
+ rung?: RouteRung;
810
850
  }
811
851
  /** Full execution trace — ordered steps + edges taken */
812
852
  export interface ExecutionTrace {
@@ -816,8 +856,14 @@ export interface ExecutionTrace {
816
856
  edges: TraceEdge[];
817
857
  /** Resolved sources keyed by field path (e.g. "nodes.gather.instruction") */
818
858
  sources: Record<string, _ResolvedSource>;
819
- /** Shadow-mode decider records, one per route decision (#357). Metadata only. Absent when the decider is off. */
859
+ /** One record per decision-model consultation (#357). Metadata only. Absent when no decider runs. */
820
860
  decisions?: DeciderRecord[];
861
+ /**
862
+ * Why the decider did not run for some or all of this run's `route_by:
863
+ * decider` nodes (#357): missing operator config, `--no-decider`, a rejected
864
+ * URL, an open breaker or a spent call cap. Absent when nothing turned it off.
865
+ */
866
+ deciderOff?: string;
821
867
  }
822
868
  /** Result of execute() — final node results + full execution trace */
823
869
  export interface ExecutionResult {
package/dist/types.js CHANGED
@@ -117,6 +117,28 @@ export const WORKFLOW_TYPES = [
117
117
  "data_sync",
118
118
  "generic",
119
119
  ];
120
+ /**
121
+ * Decision model gates (#357). Shared by the Zod schema, the JSON schema and
122
+ * the executor; kept here so schema-only (browser) consumers need no Node code.
123
+ */
124
+ /** Default: accept a decider answer only at or above this confidence. */
125
+ export const DECIDER_MIN_CONFIDENCE = 0.85;
126
+ /** Default: ... and only when the top label leads the runner-up by at least this much. */
127
+ export const DECIDER_MIN_MARGIN = 0.2;
128
+ /** A workflow may lower `min_confidence` to this and no further. */
129
+ export const DECIDER_CONFIDENCE_FLOOR = 0.7;
130
+ /** A workflow may lower `min_margin` to this and no further. */
131
+ export const DECIDER_MARGIN_FLOOR = 0.1;
132
+ /** `route_by` values: who picks a node's natural-language route. */
133
+ export const ROUTE_BY = ["agent", "decider"];
134
+ /** Load error for a workflow that still declares the removed `decider.mode`. */
135
+ export const DECIDER_MODE_REMOVED = "decider.mode was removed with shadow mode. A decider now decides the routes of nodes that set `route_by: decider`, " +
136
+ "using the provider from operator config (.sweny.yml `decider:` or SWENY_DECIDER_URL and SWENY_DECIDER_MODEL). " +
137
+ "Delete the mode line; to keep routing with the agent only, delete the whole decider block.";
138
+ /** Load error for a workflow that declares the provider itself. */
139
+ export const DECIDER_PROVIDER_MOVED = "decider.provider is not allowed in a workflow: the endpoint and key come only from operator config " +
140
+ "(.sweny.yml `decider: { url, model }`, or SWENY_DECIDER_URL and SWENY_DECIDER_MODEL; the key only from SWENY_DECIDER_API_KEY). " +
141
+ "Move it there. A workflow may only set min_confidence and min_margin here, and `route_by: decider` on nodes.";
120
142
  export const consoleLogger = {
121
143
  info: (msg, data) => console.log(`[info] ${msg}`, data ?? ""),
122
144
  warn: (msg, data) => console.warn(`[warn] ${msg}`, data ?? ""),
package/dist/when.d.ts CHANGED
@@ -95,7 +95,14 @@ export interface ExpressionResult {
95
95
  * Evaluate a parsed expression against node outputs. Never throws: a missing
96
96
  * field or a type mismatch yields `{ value: false, problem }`.
97
97
  */
98
- export declare function evaluateExpression(ast: ExprNode, scope: ExpressionScope): ExpressionResult;
98
+ export declare function evaluateExpression(ast: ExprNode, scope: ExpressionScope, opts?: {
99
+ /**
100
+ * `node.field` paths whose value broke its declared type or enum. Any
101
+ * reference to one (or below it), `exists` included, is a problem: the
102
+ * value is unknown, which is neither present nor absent.
103
+ */
104
+ invalid?: ReadonlySet<string>;
105
+ }): ExpressionResult;
99
106
  /**
100
107
  * Check an expression against the workflow it routes. Returns one message per
101
108
  * problem, empty when the expression is valid:
package/dist/when.js CHANGED
@@ -324,8 +324,14 @@ function lookup(scope, segments) {
324
324
  * Evaluate a parsed expression against node outputs. Never throws: a missing
325
325
  * field or a type mismatch yields `{ value: false, problem }`.
326
326
  */
327
- export function evaluateExpression(ast, scope) {
327
+ export function evaluateExpression(ast, scope, opts = {}) {
328
+ const checkInvalid = (path) => {
329
+ if (opts.invalid && path.length >= 2 && opts.invalid.has(`${path[0]}.${path[1]}`)) {
330
+ throw new Abort(`field '${path[0]}.${path[1]}' does not match its declared type`);
331
+ }
332
+ };
328
333
  const read = (path) => {
334
+ checkInvalid(path);
329
335
  const v = lookup(scope, path);
330
336
  if (v === undefined)
331
337
  throw new Abort(`field '${path.join(".")}' is missing`);
@@ -345,6 +351,7 @@ export function evaluateExpression(ast, scope) {
345
351
  case "path":
346
352
  return read(node.segments);
347
353
  case "exists": {
354
+ checkInvalid(node.path.segments);
348
355
  const v = lookup(scope, node.path.segments);
349
356
  return v !== undefined && v !== null;
350
357
  }
@@ -56,7 +56,9 @@ export function buildSystemPrompt(skills, existingWorkflow) {
56
56
  "- Use snake_case for node IDs (e.g. gather_errors, create_ticket)",
57
57
  "- Set `entry` to the first node in the flow",
58
58
  "- Only reference skill IDs from the list above in node `skills` arrays",
59
- "- Use natural language for edge `when` conditions",
59
+ '- Prefer `when: { expr: "..." }` expressions for edge conditions: declare the deciding values as enum, number, integer or boolean properties in the source node\'s `output`, then compare them (e.g. `{ "expr": "triage.severity in [\'high\', \'critical\']" }`). Expressions route with no model call and always the same way',
60
+ "- Use a natural-language `when` only for a fuzzy condition no declared field can express",
61
+ "- Put safety conditions (anything that gates a write, a PR or an issue) in expressions, never in natural language",
60
62
  "- Every node must be reachable from the entry node",
61
63
  "- Return ONLY the workflow JSON object — no markdown fences, no explanation",
62
64
  ];
@@ -1,3 +1,3 @@
1
- export const triageWorkflow = {"id":"triage","name":"Alert Triage","workflow_type":"monitor","description":"Investigate a production alert, determine root cause, create an issue, implement a fix, and notify the team","entry":"gather","permissions":"write","safe_outputs":{"allow":["issue","comment","issue_state","pr"],"max":25},"nodes":{"gather":{"name":"Gather Context","instruction":"You are investigating a production alert. Gather all relevant context using the available tools:\n\n1. **Observability**: Pull error details, stack traces, recent logs, metrics, and active incidents around the time of the alert. Use whichever observability tools are available to you.\n2. **Source control**: Check recent commits, pull requests, and deploys that might be related.\n3. **Issue tracker**: Search for similar past issues or known problems.\n\nBe thorough, but stay in scope: read, search, and summarize. The investigation step depends on complete context, not on fixes.\n\n**Scope boundary (this node is READ-ONLY):**\n- DO NOT create issues, comments, branches, commits, or pull requests, and DO NOT implement fixes. Downstream nodes (`create_issue`, `implement`, `create_pr`) handle ALL writes.\n- Your ONLY job is to collect context and report it, then stop. Doing downstream work here burns your turn budget and duplicates what later nodes will do.","skills":["github","sentry","datadog","betterstack","linear"],"permissions":"read","fail_soft":true},"investigate":{"name":"Root Cause Analysis","instruction":"Based on the gathered context, classify every distinct issue you found into one of two buckets: **novel** or **duplicate**.\n\nFor EACH issue found:\n1. Identify the root cause and affected code/service.\n2. Assess severity: critical (service down), high (major feature broken), medium (degraded), low (cosmetic/minor).\n3. Assess fix complexity: \"simple\" (a few lines, clear change), \"moderate\" (multiple files but well-understood), or \"complex\" (architectural, risky, or unclear).\n4. **Novelty check (REQUIRED — you MUST call tools for this step):** Filing a duplicate ticket is worse than under-reporting — the team inherits sprawl that humans have to clean up later. Complete EVERY step below before classifying anything as novel. Do NOT skip these searches even if the gather context already mentions existing issues or branches — you must verify independently.\n4a. **Search broadly — THIS REQUIRES TOOL CALLS.** You MUST call `linear_search_issues` (or `github_search_issues`) with multiple queries against the issue tracker (BOTH open AND closed): the affected file or module path, the error message or log string verbatim, the feature or service name, and the symptom family (e.g. \"startup crash\", \"data dropped silently\"). Do not rely on a single keyword — a narrow search is how duplicates slip through. If you skip this search, the eval check will fail.\n4b. **Read the full body of every promising candidate — do NOT match on title alone.** For each top match, open the issue and read its entire description, including any \"Recommended Fix\", \"Proposed Fix\", \"Action Items\", or \"Acceptance Criteria\" section. An existing open issue whose recommended fix already prescribes the change you were about to propose IS a duplicate, even if the symptom you just observed is a new instance of the same underlying bug.\n4c. **Check for meta-issues and bug families.** If an existing ticket names a pattern that your finding is another instance of (same root cause, same function/module, different input or caller), treat your finding as a sibling of that family and comment on the existing ticket. Do not file a parallel ticket per instance — that is the exact pattern that produces backlog sprawl.\n4d. **When uncertain, comment don't file.** If you are less than ~80% confident a finding is truly novel after steps 4a–4c, classify it as a duplicate and add a \"+1 — another instance\" comment to the closest existing issue with the new context. Over-reporting duplicates is cheap; ticket sprawl is expensive.\n\n - If matched → **duplicate**. Record the existing issue ID in `duplicate_of`.\n - If no match after 4a–4d → **novel**.\n\n**Output rules:**\n- `findings`: array of ALL issues found (both novel and duplicate).\n- `novel_count`: how many findings are novel (not duplicates).\n- `highest_severity`: the highest severity across ALL findings.\n- `recommendation`: what should happen next.\n\nDownstream nodes will act ONLY on novel findings. Duplicates will be +1'd automatically.\n\n**IMPORTANT — scope boundaries for this node:**\n- DO NOT create issues (Linear, GitHub, or any tracker). A downstream `create_issue` node handles that.\n- DO NOT create branches, commits, or pull requests. A downstream `implement` node handles that.\n- DO NOT call any write tools (`linear_create_issue`, `github_create_issue`, `github_create_pr`, `linear_add_comment`, `github_add_comment`, etc.). Downstream nodes handle all writes — issue creation, +1 comments, and PRs.\n- Your ONLY job is read, search, classify, and output. If you create an issue or add a comment here, the downstream eval check will fail or duplicate work.","skills":["github","linear"],"permissions":"read","eval":[{"name":"novelty_search_was_performed","kind":"function","rule":{"any_tool_called":["linear_search_issues","github_search_issues"]}}],"output":{"type":"object","properties":{"findings":{"type":"array","items":{"type":"object","properties":{"title":{"type":"string","description":"Short description of the issue"},"root_cause":{"type":"string"},"severity":{"type":"string","enum":["critical","high","medium","low"]},"affected_services":{"type":"array","items":{"type":"string"}},"is_duplicate":{"type":"boolean"},"duplicate_of":{"type":"string","description":"Existing issue ID/URL if duplicate"},"fix_approach":{"type":"string"},"fix_complexity":{"type":"string","enum":["simple","moderate","complex"]}},"required":["title","root_cause","severity","is_duplicate"]}},"novel_count":{"type":"number","description":"Count of novel (non-duplicate) findings"},"highest_severity":{"type":"string","enum":["critical","high","medium","low"]},"recommendation":{"type":"string"}},"required":["findings","novel_count","highest_severity","recommendation"]}},"create_issue":{"name":"Create Issues & Triage Duplicates","instruction":"Process ALL findings from the investigation. The findings array contains both novel and duplicate issues.\n\n**How writes work here.** If you have the `emit_output` tool, you cannot write to the tracker directly: request each new issue and each comment with `emit_output`, and sweny files them after this step, within its limits. A requested issue has no identifier yet; sweny records it for the next steps. Without `emit_output`, use the tracker's own tools (for example `linear_create_issue`, `github_create_issue`, `linear_add_comment`, `github_add_comment`, or the configured tracker's MCP tools) and copy the identifier they return.\n\n**For each NOVEL finding** (is_duplicate = false):\n1. **First, check if a prior triage run already created an issue for this exact bug.** Call `linear_search_issues` (or `github_search_issues`) with the error message or root cause. If a matching issue already exists with the same root cause:\n - Treat it as a duplicate: DO NOT create a new issue.\n - Populate `issueIdentifier`, `issueTitle`, and `issueUrl` from the existing issue.\n - Add a \"+1\" comment if appropriate.\n - Set the `action` to `updated` in the `issues` array.\n - This prevents duplicate tickets when the same alert fires multiple times.\n\n2. If no matching issue exists, file a new one with a clear, actionable title (type `issue`). Do NOT synthesize an identifier from an alert ID, commit SHA, or your own imagination: a new issue's identifier comes only from the tracker. Set `dedupe_key` to a short stable fingerprint of the root cause, so two findings with the same cause are filed once. Set the `action` to `requested` (or `created` when you filed it with a tracker tool and have its identifier).\n3. Include: root cause, severity, affected services, reproduction steps, and recommended fix.\n4. Apply the `sweny`, `agent`, and `triage` labels. For Linear: call `linear_list_labels` to find the IDs for labels named `sweny`, `agent`, and `triage`, and pass those IDs as the labels (skip any that don't exist in the team; don't invent IDs). For Linear, the target is the team ID (`linear_list_teams`). For GitHub: labels `[\"sweny\", \"agent\", \"triage\"]`.\n5. Link to relevant commits, PRs, or existing issues.\n6. When you know the identifier (an existing issue, or one a tracker tool returned), copy it verbatim into `issueIdentifier`. It must match `^[A-Z][A-Z0-9]*-\\d+$` (e.g. `OFF-1234`); do not prefix it with anything else. Leave `issueIdentifier` unset for an issue you only requested.\n\n**For each DUPLICATE finding** (is_duplicate = true):\n1. Find the existing issue (check duplicate_of field).\n2. Check the issue's comments. If the most recent comment is already from SWEny (contains \"+1\") within the last 24 hours, skip adding another comment.\n3. Otherwise add a SHORT comment (type `comment`, `number` = the issue ID or number): \"+1 seen again {UTC timestamp}. {one sentence of new context}.\" (Keep it under 2 lines. No markdown headers, no emoji, no formatting.)\n4. If the existing issue is closed or done: reopen it (type `issue_state`, `state` = `reopen`, `number` = the issue ID or number) when you have `emit_output`; with a tracker tool instead, use one that can reopen. If you can do neither, say in the comment that it is closed and was seen again.\n\nIf context.issueTemplate is provided, use it as the format for new issue bodies. Otherwise use a clear structure with: Summary, Root Cause, Impact, Steps to Reproduce, and Recommended Fix.\n\nUse the issue tracker specified in context (e.g. Linear, Jira, or GitHub Issues). Do NOT fall back to a different tracker. Output the issues you requested, created, or updated.\n\n**IMPORTANT: scope boundaries for this node:**\n- DO NOT create branches, commits, or pull requests. The `implement` and `create_pr` nodes handle that.\n- Your job is issue creation and duplicate management ONLY.","skills":["linear","github"],"outputs":[{"type":"issue","max":10},{"type":"comment","max":10},{"type":"issue_state","state":"reopen","max":10}],"tools":{"deny":["github_create_pr"]},"eval":[{"name":"issue_tracker_tool_was_called","kind":"function","rule":{"any_tool_called":["emit_output","linear_create_issue","github_create_issue","linear_search_issues","github_search_issues","linear_add_comment","github_add_comment"]}}],"output":{"type":"object","properties":{"issueIdentifier":{"type":"string","pattern":"^[A-Z][A-Z0-9]*-\\d+$","description":"Primary issue identifier (e.g. OFF-1234) when known in this step: an existing issue the duplicate check matched, or one a tracker tool returned. Unset for an issue only requested through emit_output; sweny records its identifier in safe_outputs. Never invented from a Sentry short-ID or commit SHA."},"issueTitle":{"type":"string","description":"Title of the primary issue"},"issueUrl":{"type":"string","pattern":"^https?://","description":"URL of the primary issue, when known in this step"},"issues":{"type":"array","minItems":1,"description":"All issues requested, created, or updated during this step","items":{"type":"object","properties":{"identifier":{"type":"string"},"title":{"type":"string"},"url":{"type":"string"},"action":{"type":"string","enum":["requested","created","updated","reopened"]}},"required":["action"]}}},"required":["issueTitle","issues"]},"retry":{"max":1,"instruction":{"auto":true}}},"skip":{"name":"Skip - All Duplicates or Low Priority","instruction":"Every finding from the investigation was either a duplicate or low-priority. No new issues need to be created.\n\nFor each **duplicate** finding (check the findings array for items where is_duplicate = true):\n1. Find the existing issue (check duplicate_of field).\n2. Check the issue's comments. If the most recent comment is already from SWEny (contains \"+1\") within the last 24 hours, skip adding another comment.\n3. Otherwise add a SHORT comment (with `emit_output` type `comment` when you have it, `number` = the issue ID or number): \"+1 seen again {UTC timestamp}. {one sentence of new context}.\" (Keep it under 2 lines. No markdown headers, no emoji, no formatting.)\n4. If the issue is closed or done: reopen it (`emit_output` type `issue_state`, `state` = `reopen`, `number` = the issue ID or number) when you have `emit_output`; with a tracker tool instead, use one that can reopen. If you can do neither, say in the comment that it is closed and was seen again.\n\nFor **low priority** findings, log a brief note about why they were skipped.","skills":["linear","github"],"outputs":[{"type":"comment","max":10},{"type":"issue_state","state":"reopen","max":10}]},"implement":{"name":"Implement Fix","instruction":"Implement the fix identified during investigation, plus the tests that pin\nit as a regression guard. The issue from the previous step is in your\ncontext. Use its identifier for branch naming and commit messages.\n\n**The issue identifier** (ISSUE_ID below): the `ref` of the `issue` entry\nwith status `applied` in `context.create_issue.safe_outputs` (the issue\nsweny filed after the previous step), else\n`context.create_issue.issueIdentifier` (an existing issue the previous\nstep matched, or one it filed directly).\n\n## Quality bar (non-negotiable)\n\nEvery change you make must clear all of these. If you cannot, STOP and\nreturn a failed status — do not ship a half-measure.\n\n- **Correctness**: the fix actually closes the failure mode in the issue.\n- **Completeness**: handles the obvious edge cases (nulls, empties, off-by-one,\n concurrent paths). If the issue lists multiple symptoms, address them all\n or explicitly state which are out of scope and why.\n- **Idiomatic for THIS repo, not in general.** Read at least one\n neighboring file in the same module before you write any code, and\n match the patterns you see: error-handling primitives the codebase\n already uses, type discipline, naming, file layout. Examples to make\n the shape concrete:\n - In a NestJS service, throwing `NotFoundException` /\n `BadRequestException` is idiomatic; `throw new Error(...)` is not.\n - In a Go service, returning a wrapped `fmt.Errorf(\"...: %w\", err)`\n beats panicking.\n - In a TypeScript repo, narrow types properly — do not `as any` past\n the type checker.\n These are illustrations. Generalize: whatever the repo already does,\n keep doing.\n- **No hacky shortcuts**: no `try/catch` to swallow errors, no commented-out\n guards, no `// TODO: revisit`, no global flags to bypass validation, no\n copy-pasted bodies. If the right fix needs a small refactor (e.g. extract\n a helper), do it; if it needs a large refactor, file a follow-up issue\n and ship the minimal correct fix without the refactor.\n- **Well-tested**: see Test Requirements below.\n\n## Steps\n\n0. **Precondition: staged preview.** If the `issue` entry in\n `context.create_issue.safe_outputs` has status `staged`, this run is a\n preview (`--stage`) and no issue exists. STOP before touching the\n checkout. Output `test_status: \"skipped\"`, `skipped_reason: \"staged\"`,\n empty file lists, `branch: \"\"`, `commit_sha: \"\"`.\n\n0a. **Precondition: verify ISSUE_ID is well-formed.**\n The identifier MUST match `^[A-Z][A-Z0-9]*-\\d+$` (e.g. `OFF-1234`). If it\n is missing, empty, or matches a Sentry short-ID / slug / any other shape,\n STOP immediately. Do NOT invent a branch name from the Sentry event,\n commit SHA, or alert payload. Return a failed status with a clear message\n instead; a human will pick it up.\n\n0b. **Precondition — check for an existing open PR for this issue.** Call\n `github_search_issues` (which hits GitHub's `/search/issues` endpoint\n and returns both issues and PRs) with `type:pr state:open` and the\n issue identifier wrapped in brackets — e.g. query\n `[OFF-1234] in:title type:pr state:open` and pass `repo` for scoping.\n If the response contains one or more PRs whose title starts with\n `[<issueIdentifier>]`, STOP. Do NOT create a branch, commit, or any\n new PR. Output:\n\n ```\n test_status: \"skipped\"\n skipped_reason: \"open-pr-exists\"\n existing_pr_url: \"<url of the existing PR>\"\n test_files_changed: []\n files_changed: []\n branch: \"\"\n commit_sha: \"\"\n ```\n\n The downstream `create_pr` node will be bypassed and the workflow will\n route to `notify` so the team is told the prior PR is still pending.\n\n Rationale: re-implementing a fix while an open PR already exists\n produces a duplicate (or worse, the agent closes its own prior PR\n mid-run and opens a new one with a different approach — exactly the\n thrash observed in `letsoffload/permit-service` PR #81 → #82 and\n `letsoffload/offload` PR #572 → #573, where two PRs for the same\n identifier were opened-and-closed 12 to 16 seconds apart inside a\n single workflow run).\n\n Only proceed to Step 1 if no open PR exists for the identifier.\n\n1. Create a feature branch from the base branch (check context for\n baseBranch, default `main`). **Branch name MUST include the issue\n identifier** exactly as ISSUE_ID above.\n Format: lowercase the identifier and use it as a prefix, e.g.\n `off-1234-fix-null-check`. If the repository uses a different branch\n convention (check context.branchPattern or the rules/CLAUDE.md for a\n regex), follow that — but the identifier piece MUST still come from\n ISSUE_ID, never from a Sentry short-ID.\n\n2. Read the relevant source files to understand the current code AND read\n the nearest existing test file (e.g. `foo.service.spec.ts` next to\n `foo.service.ts`, or `foo_test.py` next to `foo.py`) so your new tests\n match the existing test conventions: framework, mock style, factory use,\n describe/it shape, naming.\n\n3. Make the necessary code change. Keep it minimal and focused — do not\n refactor surrounding code or add unrelated improvements.\n\n4. **Write tests for the fix.** See Test Requirements below.\n\n5. **Run the test suite for the affected package** and confirm green\n (the package's `test` command from package.json, `pytest` for Python,\n etc.). If the test runner is not obvious, read the project's\n CLAUDE.md / README / package.json scripts. If you cannot run the\n tests at all in this environment, say so explicitly in the output —\n do not claim \"tests pass\" when you didn't run them.\n\n6. Stage and commit with a clear commit message. Start the message with the\n issue identifier in brackets, e.g.\n `[OFF-1234] fix: guard null projectId before database lookup`.\n\n## Scope boundary — do NOT open the PR here\n\nStop after the commit. Do NOT push the branch, do NOT run `gh pr create`,\ndo NOT call any PR-creation tool. The dedicated `create_pr` node pushes the\nbranch and requests the PR. Opening it from this node bypasses the workflow's\neval gate and triggers a self-close-and-recreate workaround (PR opened via\nshell, then `github_create_pr` returns 422 \"already exists\" against the same\nbranch, then the agent closes the first PR to satisfy the eval). The\nidempotent fallback in `github_create_pr` will recover if you ignore this,\nbut the cleaner path is: commit only here, let `create_pr` push and open.\n\n## Test Requirements\n\nA code change without a test is unfinished work. Every fix this node ships\nMUST come with at least one new test case that:\n\n- **Would fail on the unfixed code.** A test that passes both before and\n after the fix is decoration, not a regression guard. Mentally run it\n against the previous version; if it would have passed, it is not the\n right test.\n- **Asserts the user-facing contract**, not just an implementation\n detail. For an API/handler bug: assert the response shape, status code,\n or error type the client sees. For a data corruption bug: assert the\n persisted row's final state, not just an internal call count.\n- **Covers the obvious adjacent edge cases.** If the bug was \"throws plain\n Error on missing record\", add the missing-record case AND at least one\n success-path case to confirm the fix didn't break the happy path.\n- **Lives in the right file** (next to the source under test, in the\n project's existing test layout).\n\nThe eval gate on this node REQUIRES `test_status` to be either\n`pass` (tests ran and all passed) OR `no-framework` (the project\ngenuinely has no test runner — not \"I couldn't be bothered\").\n\nIf the project HAS a test framework, you must write tests and they\nmust pass. Empty `test_files_changed` with `test_status: pass` is a\nlie and eval will reject it via the schema's required-fields\ncontract; `not-run` and `fail` will retry once with reflection and\nthen halt for human attention.\n\nIf the fix turns out to be more complex than expected, stop and\nexplain why — do not force a bad fix.","skills":["github"],"permissions":{"access":"write","deny":["net"]},"tools":{"deny":["github_create_pr","github_create_issue","github_add_comment","github_add_labels"]},"output":{"type":"object","properties":{"branch":{"type":"string","description":"Feature branch name (must include the issue identifier)."},"commit_sha":{"type":"string","description":"SHA of the commit shipping the fix and tests."},"files_changed":{"type":"array","description":"Source files modified by the fix (NOT including test files).","items":{"type":"string"}},"test_files_changed":{"type":"array","description":"Test files added or modified to cover the fix. Should be\nnon-empty whenever `test_status: pass`. May be empty when\n`test_status: no-framework` (genuinely no test runner in\nthe repo).\n","items":{"type":"string"}},"test_command":{"type":"string","description":"Exact command run to validate (e.g. `npx nx test server`)."},"test_status":{"type":"string","enum":["pass","fail","no-framework","not-run","skipped"],"description":"Outcome of running the test suite.\n- `pass` — tests ran end-to-end and every assertion passed.\n `test_files_changed` MUST be non-empty in this case (you\n changed code; tests must cover it).\n- `no-framework` — the repo genuinely has no test runner\n (e.g. a docs-only repo, a YAML-config repo, a research\n notebook collection). Reserved for cases where there is\n no test infrastructure to extend — not a permission slip\n to skip tests in a normal codebase.\n- `fail` — tests ran and at least one failed. Do not push\n a broken fix. Return this status, retry will fire once.\n- `not-run` — tests exist but the environment couldn't\n execute them. Explain in `test_notes`. Retry will fire.\n- `skipped` — the node short-circuited before running tests\n because a precondition was not met: `open-pr-exists` (Step\n 0b found an open PR with the issue identifier in its\n title; `existing_pr_url` MUST be populated) or `staged`\n (Step 0: a preview run filed no issue). `skipped_reason`\n MUST be populated. Downstream `create_pr` is bypassed and\n the workflow routes to `notify`.\n"},"skipped_reason":{"type":"string","description":"Why the node short-circuited. Only set when `test_status` is\n`skipped`: `open-pr-exists` (Step 0b) or `staged` (Step 0).\n","enum":["open-pr-exists","staged"]},"existing_pr_url":{"type":"string","description":"URL of the open PR that triggered the skip. Set when\n`skipped_reason` is `open-pr-exists` so the notify node\ncan link to the prior PR.\n","pattern":"^https?://"},"test_notes":{"type":"string","description":"One-paragraph explanation of which tests were added and what they assert."}},"required":["branch","commit_sha","files_changed","test_files_changed","test_status"]},"eval":[{"name":"test_status_is_pass_or_no_framework","kind":"value","rule":{"output_matches":[{"path":"test_status","in":["pass","no-framework","skipped"]}]}},{"name":"tests_present_when_pass_claimed","kind":"judge","rubric":"You are checking the contract between test_status and test_files_changed.\n\nRead result.data.test_status and result.data.test_files_changed.\n\nRules:\n- If test_status is \"pass\": test_files_changed MUST contain at least\n one real test file path (paths with extensions like .spec.ts,\n .test.ts, .test.tsx, .test.py, _test.go, _spec.rb, .test.rs,\n etc., or paths in a __tests__/, tests/, or spec/ directory).\n An empty array, or paths that are clearly not test files\n (README.md, package.json, source files), is a contract violation.\n- If test_status is \"no-framework\": test_files_changed MAY be empty.\n Pass vacuously.\n- If test_status is \"skipped\": test_files_changed MAY be empty.\n The node short-circuited before writing any code. When\n skipped_reason is \"open-pr-exists\" (Step 0b found an open PR\n for the issue), `existing_pr_url` MUST be populated; when it\n is \"staged\" (a preview run), nothing else is required. If\n skipped_reason is missing, return no.\n- If test_status is \"fail\" or \"not-run\": this evaluator should not\n run (the prior value evaluator catches that). Pass vacuously.\n\nRespond yes if the contract is satisfied, no if it is violated.\n","pass_when":"yes"}],"retry":{"max":1,"instruction":{"auto":true}}},"create_pr":{"name":"Open Pull Request","on_fail":"continue","instruction":"Open a pull request for the fix. The issue is in your context from the create_issue step; its identifier (ISSUE_ID) is the `ref` of the applied `issue` entry in `context.create_issue.safe_outputs`, else `context.create_issue.issueIdentifier`. The branch is `context.implement.branch`.\n\n1. Push the branch to the remote. If the push fails for lack of credentials (a checkout made with `persist-credentials: false`), go on: sweny pushes the head branch itself before it opens the PR.\n2. Request the PR: with `emit_output` (type `pr`, `head` = the branch, `base` = the base branch, default `main`) when you have it; sweny opens it after this step and reuses an open PR for the same branch instead of failing. Without `emit_output`, call `github_create_pr` (use this exact tool name, not `create_pull_request` or any other variant from ToolSearch); if it returns `reused: true`, treat it as success and do NOT close it and call again.\n3. PR title MUST start with the issue identifier in brackets. Format: `[ISSUE_ID] fix: {short description}`.\n4. In the PR body, include: summary of the bug, what the fix does, and a link to the issue (its `url` in `context.create_issue.safe_outputs`, else context.create_issue.issueUrl). If the investigation found a Sentry issue, include \"Fixes {sentryShortId}\" in the PR body so Sentry auto-resolves on merge. If the issue tracker is Linear, also include the line \"Fixes ISSUE_ID\" (e.g. \"Fixes OFF-1234\") so Linear links the PR and moves the issue to Done on merge.\n5. Labels: `[\"sweny\", \"agent\", \"triage\"]`.\n\nIf context.prTemplate is provided, use it as the format for the PR body. Otherwise use a clear structure with: Summary, Changes, Testing, and Related Issues.\n\nIf context.cloudRunId is provided, append this HTML comment to the end of the PR body: <!-- sweny:run_id:{context.cloudRunId} -->\n\nReturn the branch and the PR title you requested (and the PR URL and number when a tool returned them).","skills":["github"],"permissions":"write","outputs":[{"type":"pr","max":1,"labels":["sweny","agent","triage"]}],"tools":{"deny":["github_create_pr","github_create_issue","github_add_comment","github_add_labels"]},"eval":[{"name":"pr_was_created","kind":"function","rule":{"any_tool_called":["emit_output","github_create_pr"]}}],"retry":{"max":1,"instruction":{"auto":true}}},"notify":{"name":"Notify Team","instruction":"Send a notification summarizing the triage result:\n\n1. Include: alert summary, severity, root cause (1-2 sentences), and links to any created issues or PRs.\n Issues and PRs sweny filed are in `safe_outputs` of the create_issue, skip and create_pr steps\n (`ref` and `url` of each `applied` entry).\n2. For critical/high severity, make the notification urgent.\n3. For medium/low, a standard notification is fine.\n4. If any `safe_outputs` entry has status `staged`, this run is a preview: send nothing, and put the\n notification you would have sent in your summary.\n\nUse whichever notification channel is available to you.","skills":["slack","notification"]}},"edges":[{"from":"gather","to":"investigate"},{"from":"investigate","to":"create_issue","when":{"expr":"investigate.novel_count > 0 && investigate.highest_severity in ['medium', 'high', 'critical']"}},{"from":"investigate","to":"skip","when":{"expr":"investigate.novel_count == 0 || investigate.highest_severity == 'low'"}},{"from":"create_issue","to":"implement","when":"at least one novel finding has fix_complexity simple or moderate AND fix_approach is provided"},{"from":"create_issue","to":"notify","when":"all novel findings have fix_complexity complex, OR no clear fix_approach"},{"from":"skip","to":"notify"},{"from":"implement","to":"notify","when":{"expr":"implement.test_status == 'skipped'"}},{"from":"implement","to":"create_pr","when":{"expr":"implement.test_status in ['pass', 'no-framework']"}},{"from":"create_pr","to":"notify"}],"skills":{}};
2
- export const implementWorkflow = {"id":"implement","name":"Implement Fix","workflow_type":"pr_review","description":"Implement a code fix for an issue and open a pull request","entry":"analyze","permissions":"write","safe_outputs":{"allow":["comment","pr"],"max":3},"nodes":{"analyze":{"name":"Analyze Issue","instruction":"Read the issue details and understand what needs to be fixed:\n\n1. Fetch the issue from the tracker (GitHub or Linear).\n2. **Check for an existing open PR for this issue.** Call\n `github_search_issues` (GitHub's `/search/issues` endpoint returns\n both issues and PRs) with `type:pr state:open` and the issue\n identifier wrapped in brackets — e.g. query\n `[OFF-1234] in:title type:pr state:open`. If the response contains\n one or more PRs whose title starts with `[<issueIdentifier>]`,\n STOP analysis. Output `existing_pr_url`\n (the URL of the open PR) and a short `issue_summary` noting the\n skip; leave `fix_plan` set to a one-line \"Skip: open PR\n <url> already exists\". The workflow will route to `notify` and\n the team will be told the prior PR is still pending.\n Rationale: re-implementing while an open PR exists produces a\n duplicate (or worse, the agent closes its own prior PR mid-run\n and opens a new one — exactly the thrash seen in\n `letsoffload/permit-service` PR #81 → #82 and\n `letsoffload/offload` PR #572 → #573).\n3. Read the relevant source files to understand the current code.\n4. Identify the exact files and lines that need to change.\n5. Plan the fix approach.\n\nOutput a clear analysis of what needs to change and why.","skills":["github","linear"],"permissions":"read","output":{"type":"object","properties":{"issue_summary":{"type":"string"},"files_to_change":{"type":"array","items":{"type":"string"}},"fix_plan":{"type":"string"},"risk_level":{"type":"string","enum":["low","medium","high"]},"existing_pr_url":{"type":"string","description":"URL of an open PR found in step 2 whose title starts with the\nissue identifier in brackets. Set ONLY when a prior PR exists\nand the analyze node is short-circuiting. Triggers the\n`analyze → notify` edge.\n","pattern":"^https?://"}},"required":["issue_summary","fix_plan"]}},"implement":{"name":"Implement Fix","instruction":"Implement the planned fix:\n\n1. Create a feature branch. The branch name MUST start with the issue\n identifier from `context.input.issueIdentifier`, lowercased, followed\n by a short kebab-case description: e.g. `off-1234-fix-null-check`.\n2. Make the necessary code changes.\n3. Ensure changes are minimal and focused — fix the bug, nothing more.\n4. Stage and commit. Start the commit message with the issue identifier\n in brackets, e.g. `[OFF-1234] fix: guard null projectId`.\n\nStop after the commit. Do NOT push or open the PR: the dedicated `create_pr`\nnode pushes the branch and requests the PR.\n\nIf the fix is too risky or complex, explain why and skip.","skills":["github"],"permissions":{"access":"write","deny":["net"]},"tools":{"deny":["github_create_pr","github_create_issue","github_add_comment","github_add_labels"]}},"create_pr":{"name":"Open Pull Request","on_fail":"continue","instruction":"Open a pull request for the fix:\n\n1. Push the branch to the remote. If the push fails for lack of credentials (a checkout made with `persist-credentials: false`), go on: sweny pushes the head branch itself before it opens the PR.\n2. Request the PR: with `emit_output` (type `pr`, `head` = the branch, `base` = the base branch, default `main`) when you have it; sweny opens it after this step and reuses an open PR for the same branch instead of failing. Without `emit_output`, call `github_create_pr`. The PR title MUST start with the issue identifier in brackets: `[{context.input.issueIdentifier}] type: short description` (e.g. `[OFF-1234] fix: guard null projectId`).\n3. Reference the original issue in the PR body. If the issue tracker is Linear, include the line \"Fixes {context.input.issueIdentifier}\" (e.g. \"Fixes OFF-1234\") so Linear links the PR and moves the issue to Done on merge.\n4. Labels: add `task` (or `feature` if the issue is a feature request); `sweny` and `agent` are always added.\n\nIf context.prTemplate is provided, use it as the format for the PR body. Otherwise use a clear structure with: Summary, Changes, Testing, and Related Issues.\n\nIf context.cloudRunId is provided, append this HTML comment to the end of the PR body: <!-- sweny:run_id:{context.cloudRunId} -->\n\nReturn the branch and the PR title you requested.","skills":["github"],"permissions":"write","outputs":[{"type":"pr","max":1,"labels":["sweny","agent"]}],"tools":{"deny":["github_create_pr","github_create_issue","github_add_comment","github_add_labels"]}},"notify":{"name":"Notify","instruction":"Send a notification about the implementation result:\n\n1. Include: issue reference, PR link, brief summary of changes. The PR sweny opened is in\n `context.create_pr.safe_outputs` (`ref` and `url` of the `applied` entry).\n2. Keep it concise: one message, not a wall of text.\n3. If any `safe_outputs` entry has status `staged`, this run is a preview: send nothing, and put the\n notification you would have sent in your summary.","skills":["slack","notification"]},"skip":{"name":"Skip - Too Complex","instruction":"The fix was determined to be too complex or risky for automated implementation.\nAdd a comment to the issue explaining what was found and why it needs manual attention\n(with `emit_output` type `comment` when you have it).","skills":["linear","github"],"outputs":[{"type":"comment","max":1,"number":{"input":"issueIdentifier"}}]}},"edges":[{"from":"analyze","to":"notify","when":"analyze.existing_pr_url is set (an open PR for this issue already exists; skip the implement and create_pr nodes)"},{"from":"analyze","to":"implement","when":"Fix risk level is low or medium and a clear plan exists"},{"from":"analyze","to":"skip","when":"Fix is too complex, risky, or unclear"},{"from":"implement","to":"create_pr"},{"from":"skip","to":"notify"},{"from":"create_pr","to":"notify"}],"skills":{}};
1
+ export const triageWorkflow = {"id":"triage","name":"Alert Triage","workflow_type":"monitor","description":"Investigate a production alert, determine root cause, create an issue, implement a fix, and notify the team","entry":"gather","permissions":"write","safe_outputs":{"allow":["issue","comment","issue_state","pr"],"max":25},"nodes":{"gather":{"name":"Gather Context","instruction":"You are investigating a production alert. Gather all relevant context using the available tools:\n\n1. **Observability**: Pull error details, stack traces, recent logs, metrics, and active incidents around the time of the alert. Use whichever observability tools are available to you.\n2. **Source control**: Check recent commits, pull requests, and deploys that might be related.\n3. **Issue tracker**: Search for similar past issues or known problems.\n\nBe thorough, but stay in scope: read, search, and summarize. The investigation step depends on complete context, not on fixes.\n\n**Scope boundary (this node is READ-ONLY):**\n- DO NOT create issues, comments, branches, commits, or pull requests, and DO NOT implement fixes. Downstream nodes (`create_issue`, `implement`, `create_pr`) handle ALL writes.\n- Your ONLY job is to collect context and report it, then stop. Doing downstream work here burns your turn budget and duplicates what later nodes will do.","skills":["github","sentry","datadog","betterstack","linear"],"permissions":"read","fail_soft":true},"investigate":{"name":"Root Cause Analysis","instruction":"Based on the gathered context, classify every distinct issue you found into one of two buckets: **novel** or **duplicate**.\n\nFor EACH issue found:\n1. Identify the root cause and affected code/service.\n2. Assess severity: critical (service down), high (major feature broken), medium (degraded), low (cosmetic/minor).\n3. Assess fix complexity: \"simple\" (a few lines, clear change), \"moderate\" (multiple files but well-understood), or \"complex\" (architectural, risky, or unclear).\n4. **Novelty check (REQUIRED — you MUST call tools for this step):** Filing a duplicate ticket is worse than under-reporting — the team inherits sprawl that humans have to clean up later. Complete EVERY step below before classifying anything as novel. Do NOT skip these searches even if the gather context already mentions existing issues or branches — you must verify independently.\n4a. **Search broadly — THIS REQUIRES TOOL CALLS.** You MUST call `linear_search_issues` (or `github_search_issues`) with multiple queries against the issue tracker (BOTH open AND closed): the affected file or module path, the error message or log string verbatim, the feature or service name, and the symptom family (e.g. \"startup crash\", \"data dropped silently\"). Do not rely on a single keyword — a narrow search is how duplicates slip through. If you skip this search, the eval check will fail.\n4b. **Read the full body of every promising candidate — do NOT match on title alone.** For each top match, open the issue and read its entire description, including any \"Recommended Fix\", \"Proposed Fix\", \"Action Items\", or \"Acceptance Criteria\" section. An existing open issue whose recommended fix already prescribes the change you were about to propose IS a duplicate, even if the symptom you just observed is a new instance of the same underlying bug.\n4c. **Check for meta-issues and bug families.** If an existing ticket names a pattern that your finding is another instance of (same root cause, same function/module, different input or caller), treat your finding as a sibling of that family and comment on the existing ticket. Do not file a parallel ticket per instance — that is the exact pattern that produces backlog sprawl.\n4d. **When uncertain, comment don't file.** If you are less than ~80% confident a finding is truly novel after steps 4a–4c, classify it as a duplicate and add a \"+1 — another instance\" comment to the closest existing issue with the new context. Over-reporting duplicates is cheap; ticket sprawl is expensive.\n\n - If matched → **duplicate**. Record the existing issue ID in `duplicate_of`.\n - If no match after 4a–4d → **novel**.\n\n**Output rules:**\n- `findings`: array of ALL issues found (both novel and duplicate).\n- `novel_count`: how many findings are novel (not duplicates).\n- `fixable_count`: how many NOVEL findings have `fix_complexity` simple or moderate AND a non-empty `fix_approach`. 0 when none do. This decides whether sweny attempts a fix after filing the issue.\n- `highest_severity`: the highest severity across ALL findings.\n- `recommendation`: what should happen next.\n\nDownstream nodes will act ONLY on novel findings. Duplicates will be +1'd automatically.\n\n**IMPORTANT — scope boundaries for this node:**\n- DO NOT create issues (Linear, GitHub, or any tracker). A downstream `create_issue` node handles that.\n- DO NOT create branches, commits, or pull requests. A downstream `implement` node handles that.\n- DO NOT call any write tools (`linear_create_issue`, `github_create_issue`, `github_create_pr`, `linear_add_comment`, `github_add_comment`, etc.). Downstream nodes handle all writes — issue creation, +1 comments, and PRs.\n- Your ONLY job is read, search, classify, and output. If you create an issue or add a comment here, the downstream eval check will fail or duplicate work.","skills":["github","linear"],"permissions":"read","eval":[{"name":"novelty_search_was_performed","kind":"function","rule":{"any_tool_called":["linear_search_issues","github_search_issues"]}}],"output":{"type":"object","properties":{"findings":{"type":"array","items":{"type":"object","properties":{"title":{"type":"string","description":"Short description of the issue"},"root_cause":{"type":"string"},"severity":{"type":"string","enum":["critical","high","medium","low"]},"affected_services":{"type":"array","items":{"type":"string"}},"is_duplicate":{"type":"boolean"},"duplicate_of":{"type":"string","description":"Existing issue ID/URL if duplicate"},"fix_approach":{"type":"string"},"fix_complexity":{"type":"string","enum":["simple","moderate","complex"]}},"required":["title","root_cause","severity","is_duplicate"]}},"novel_count":{"type":"number","description":"Count of novel (non-duplicate) findings"},"fixable_count":{"type":"integer","minimum":0,"description":"Count of novel findings whose fix_complexity is simple or moderate AND whose fix_approach is a non-empty plan. Routes create_issue to implement.","x-sweny-count-of":{"array":"findings","where":{"is_duplicate":[false],"fix_complexity":["simple","moderate"]},"non_empty":["fix_approach"]}},"highest_severity":{"type":"string","enum":["critical","high","medium","low"]},"recommendation":{"type":"string"}},"required":["findings","novel_count","fixable_count","highest_severity","recommendation"]}},"create_issue":{"name":"Create Issues & Triage Duplicates","instruction":"Process ALL findings from the investigation. The findings array contains both novel and duplicate issues.\n\n**How writes work here.** If you have the `emit_output` tool, you cannot write to the tracker directly: request each new issue and each comment with `emit_output`, and sweny files them after this step, within its limits. A requested issue has no identifier yet; sweny records it for the next steps. Without `emit_output`, use the tracker's own tools (for example `linear_create_issue`, `github_create_issue`, `linear_add_comment`, `github_add_comment`, or the configured tracker's MCP tools) and copy the identifier they return.\n\n**For each NOVEL finding** (is_duplicate = false):\n1. **First, check if a prior triage run already created an issue for this exact bug.** Call `linear_search_issues` (or `github_search_issues`) with the error message or root cause. If a matching issue already exists with the same root cause:\n - Treat it as a duplicate: DO NOT create a new issue.\n - Populate `issueIdentifier`, `issueTitle`, and `issueUrl` from the existing issue.\n - Add a \"+1\" comment if appropriate.\n - Set the `action` to `updated` in the `issues` array.\n - This prevents duplicate tickets when the same alert fires multiple times.\n\n2. If no matching issue exists, file a new one with a clear, actionable title (type `issue`). Do NOT synthesize an identifier from an alert ID, commit SHA, or your own imagination: a new issue's identifier comes only from the tracker. Set `dedupe_key` to a short stable fingerprint of the root cause, so two findings with the same cause are filed once. Set the `action` to `requested` (or `created` when you filed it with a tracker tool and have its identifier).\n3. Include: root cause, severity, affected services, reproduction steps, and recommended fix.\n4. Apply the `sweny`, `agent`, and `triage` labels. For Linear: call `linear_list_labels` to find the IDs for labels named `sweny`, `agent`, and `triage`, and pass those IDs as the labels (skip any that don't exist in the team; don't invent IDs). For Linear, the target is the team ID (`linear_list_teams`). For GitHub: labels `[\"sweny\", \"agent\", \"triage\"]`.\n5. Link to relevant commits, PRs, or existing issues.\n6. When you know the identifier (an existing issue, or one a tracker tool returned), copy it verbatim into `issueIdentifier`. It must match `^[A-Z][A-Z0-9]*-\\d+$` (e.g. `OFF-1234`); do not prefix it with anything else. Leave `issueIdentifier` unset for an issue you only requested.\n\n**For each DUPLICATE finding** (is_duplicate = true):\n1. Find the existing issue (check duplicate_of field).\n2. Check the issue's comments. If the most recent comment is already from SWEny (contains \"+1\") within the last 24 hours, skip adding another comment.\n3. Otherwise add a SHORT comment (type `comment`, `number` = the issue ID or number): \"+1 seen again {UTC timestamp}. {one sentence of new context}.\" (Keep it under 2 lines. No markdown headers, no emoji, no formatting.)\n4. If the existing issue is closed or done: reopen it (type `issue_state`, `state` = `reopen`, `number` = the issue ID or number) when you have `emit_output`; with a tracker tool instead, use one that can reopen. If you can do neither, say in the comment that it is closed and was seen again.\n\nIf context.issueTemplate is provided, use it as the format for new issue bodies. Otherwise use a clear structure with: Summary, Root Cause, Impact, Steps to Reproduce, and Recommended Fix.\n\nUse the issue tracker specified in context (e.g. Linear, Jira, or GitHub Issues). Do NOT fall back to a different tracker. Output the issues you requested, created, or updated.\n\n**IMPORTANT: scope boundaries for this node:**\n- DO NOT create branches, commits, or pull requests. The `implement` and `create_pr` nodes handle that.\n- Your job is issue creation and duplicate management ONLY.","skills":["linear","github"],"outputs":[{"type":"issue","max":10},{"type":"comment","max":10},{"type":"issue_state","state":"reopen","max":10}],"tools":{"deny":["github_create_pr"]},"eval":[{"name":"issue_tracker_tool_was_called","kind":"function","rule":{"any_tool_called":["emit_output","linear_create_issue","github_create_issue","linear_search_issues","github_search_issues","linear_add_comment","github_add_comment"]}}],"output":{"type":"object","properties":{"issueIdentifier":{"type":"string","pattern":"^[A-Z][A-Z0-9]*-\\d+$","description":"Primary issue identifier (e.g. OFF-1234) when known in this step: an existing issue the duplicate check matched, or one a tracker tool returned. Unset for an issue only requested through emit_output; sweny records its identifier in safe_outputs. Never invented from a Sentry short-ID or commit SHA."},"issueTitle":{"type":"string","description":"Title of the primary issue"},"issueUrl":{"type":"string","pattern":"^https?://","description":"URL of the primary issue, when known in this step"},"issues":{"type":"array","minItems":1,"description":"All issues requested, created, or updated during this step","items":{"type":"object","properties":{"identifier":{"type":"string"},"title":{"type":"string"},"url":{"type":"string"},"action":{"type":"string","enum":["requested","created","updated","reopened"]}},"required":["action"]}}},"required":["issueTitle","issues"]},"retry":{"max":1,"instruction":{"auto":true}}},"skip":{"name":"Skip - All Duplicates or Low Priority","instruction":"Every finding from the investigation was either a duplicate or low-priority. No new issues need to be created.\n\nFor each **duplicate** finding (check the findings array for items where is_duplicate = true):\n1. Find the existing issue (check duplicate_of field).\n2. Check the issue's comments. If the most recent comment is already from SWEny (contains \"+1\") within the last 24 hours, skip adding another comment.\n3. Otherwise add a SHORT comment (with `emit_output` type `comment` when you have it, `number` = the issue ID or number): \"+1 seen again {UTC timestamp}. {one sentence of new context}.\" (Keep it under 2 lines. No markdown headers, no emoji, no formatting.)\n4. If the issue is closed or done: reopen it (`emit_output` type `issue_state`, `state` = `reopen`, `number` = the issue ID or number) when you have `emit_output`; with a tracker tool instead, use one that can reopen. If you can do neither, say in the comment that it is closed and was seen again.\n\nFor **low priority** findings, log a brief note about why they were skipped.","skills":["linear","github"],"outputs":[{"type":"comment","max":10},{"type":"issue_state","state":"reopen","max":10}]},"implement":{"name":"Implement Fix","instruction":"Implement the fix identified during investigation, plus the tests that pin\nit as a regression guard. The issue from the previous step is in your\ncontext. Use its identifier for branch naming and commit messages.\n\n**The issue identifier** (ISSUE_ID below): the `ref` of the `issue` entry\nwith status `applied` in `context.create_issue.safe_outputs` (the issue\nsweny filed after the previous step), else\n`context.create_issue.issueIdentifier` (an existing issue the previous\nstep matched, or one it filed directly).\n\n## Quality bar (non-negotiable)\n\nEvery change you make must clear all of these. If you cannot, STOP and\nreturn a failed status — do not ship a half-measure.\n\n- **Correctness**: the fix actually closes the failure mode in the issue.\n- **Completeness**: handles the obvious edge cases (nulls, empties, off-by-one,\n concurrent paths). If the issue lists multiple symptoms, address them all\n or explicitly state which are out of scope and why.\n- **Idiomatic for THIS repo, not in general.** Read at least one\n neighboring file in the same module before you write any code, and\n match the patterns you see: error-handling primitives the codebase\n already uses, type discipline, naming, file layout. Examples to make\n the shape concrete:\n - In a NestJS service, throwing `NotFoundException` /\n `BadRequestException` is idiomatic; `throw new Error(...)` is not.\n - In a Go service, returning a wrapped `fmt.Errorf(\"...: %w\", err)`\n beats panicking.\n - In a TypeScript repo, narrow types properly — do not `as any` past\n the type checker.\n These are illustrations. Generalize: whatever the repo already does,\n keep doing.\n- **No hacky shortcuts**: no `try/catch` to swallow errors, no commented-out\n guards, no `// TODO: revisit`, no global flags to bypass validation, no\n copy-pasted bodies. If the right fix needs a small refactor (e.g. extract\n a helper), do it; if it needs a large refactor, file a follow-up issue\n and ship the minimal correct fix without the refactor.\n- **Well-tested**: see Test Requirements below.\n\n## Steps\n\n0. **Precondition: staged preview.** If the `issue` entry in\n `context.create_issue.safe_outputs` has status `staged`, this run is a\n preview (`--stage`) and no issue exists. STOP before touching the\n checkout. Output `test_status: \"skipped\"`, `skipped_reason: \"staged\"`,\n empty file lists, `branch: \"\"`, `commit_sha: \"\"`.\n\n0a. **Precondition: verify ISSUE_ID is well-formed.**\n The identifier MUST match `^[A-Z][A-Z0-9]*-\\d+$` (e.g. `OFF-1234`). If it\n is missing, empty, or matches a Sentry short-ID / slug / any other shape,\n STOP immediately. Do NOT invent a branch name from the Sentry event,\n commit SHA, or alert payload. Return a failed status with a clear message\n instead; a human will pick it up.\n\n0b. **Precondition — check for an existing open PR for this issue.** Call\n `github_search_issues` (which hits GitHub's `/search/issues` endpoint\n and returns both issues and PRs) with `type:pr state:open` and the\n issue identifier wrapped in brackets — e.g. query\n `[OFF-1234] in:title type:pr state:open` and pass `repo` for scoping.\n If the response contains one or more PRs whose title starts with\n `[<issueIdentifier>]`, STOP. Do NOT create a branch, commit, or any\n new PR. Output:\n\n ```\n test_status: \"skipped\"\n skipped_reason: \"open-pr-exists\"\n existing_pr_url: \"<url of the existing PR>\"\n test_files_changed: []\n files_changed: []\n branch: \"\"\n commit_sha: \"\"\n ```\n\n The downstream `create_pr` node will be bypassed and the workflow will\n route to `notify` so the team is told the prior PR is still pending.\n\n Rationale: re-implementing a fix while an open PR already exists\n produces a duplicate (or worse, the agent closes its own prior PR\n mid-run and opens a new one with a different approach — exactly the\n thrash observed in `letsoffload/permit-service` PR #81 → #82 and\n `letsoffload/offload` PR #572 → #573, where two PRs for the same\n identifier were opened-and-closed 12 to 16 seconds apart inside a\n single workflow run).\n\n Only proceed to Step 1 if no open PR exists for the identifier.\n\n1. Create a feature branch from the base branch (check context for\n baseBranch, default `main`). **Branch name MUST include the issue\n identifier** exactly as ISSUE_ID above.\n Format: lowercase the identifier and use it as a prefix, e.g.\n `off-1234-fix-null-check`. If the repository uses a different branch\n convention (check context.branchPattern or the rules/CLAUDE.md for a\n regex), follow that — but the identifier piece MUST still come from\n ISSUE_ID, never from a Sentry short-ID.\n\n2. Read the relevant source files to understand the current code AND read\n the nearest existing test file (e.g. `foo.service.spec.ts` next to\n `foo.service.ts`, or `foo_test.py` next to `foo.py`) so your new tests\n match the existing test conventions: framework, mock style, factory use,\n describe/it shape, naming.\n\n3. Make the necessary code change. Keep it minimal and focused — do not\n refactor surrounding code or add unrelated improvements.\n\n4. **Write tests for the fix.** See Test Requirements below.\n\n5. **Run the test suite for the affected package** and confirm green\n (the package's `test` command from package.json, `pytest` for Python,\n etc.). If the test runner is not obvious, read the project's\n CLAUDE.md / README / package.json scripts. If you cannot run the\n tests at all in this environment, say so explicitly in the output —\n do not claim \"tests pass\" when you didn't run them.\n\n6. Stage and commit with a clear commit message. Start the message with the\n issue identifier in brackets, e.g.\n `[OFF-1234] fix: guard null projectId before database lookup`.\n\n## Scope boundary — do NOT open the PR here\n\nStop after the commit. Do NOT push the branch, do NOT run `gh pr create`,\ndo NOT call any PR-creation tool. The dedicated `create_pr` node pushes the\nbranch and requests the PR. Opening it from this node bypasses the workflow's\neval gate and triggers a self-close-and-recreate workaround (PR opened via\nshell, then `github_create_pr` returns 422 \"already exists\" against the same\nbranch, then the agent closes the first PR to satisfy the eval). The\nidempotent fallback in `github_create_pr` will recover if you ignore this,\nbut the cleaner path is: commit only here, let `create_pr` push and open.\n\n## Test Requirements\n\nA code change without a test is unfinished work. Every fix this node ships\nMUST come with at least one new test case that:\n\n- **Would fail on the unfixed code.** A test that passes both before and\n after the fix is decoration, not a regression guard. Mentally run it\n against the previous version; if it would have passed, it is not the\n right test.\n- **Asserts the user-facing contract**, not just an implementation\n detail. For an API/handler bug: assert the response shape, status code,\n or error type the client sees. For a data corruption bug: assert the\n persisted row's final state, not just an internal call count.\n- **Covers the obvious adjacent edge cases.** If the bug was \"throws plain\n Error on missing record\", add the missing-record case AND at least one\n success-path case to confirm the fix didn't break the happy path.\n- **Lives in the right file** (next to the source under test, in the\n project's existing test layout).\n\nThe eval gate on this node REQUIRES `test_status` to be either\n`pass` (tests ran and all passed) OR `no-framework` (the project\ngenuinely has no test runner — not \"I couldn't be bothered\").\n\nIf the project HAS a test framework, you must write tests and they\nmust pass. Empty `test_files_changed` with `test_status: pass` is a\nlie and eval will reject it via the schema's required-fields\ncontract; `not-run` and `fail` will retry once with reflection and\nthen halt for human attention.\n\nIf the fix turns out to be more complex than expected, stop and\nexplain why — do not force a bad fix.","skills":["github"],"permissions":{"access":"write","deny":["net"]},"tools":{"deny":["github_create_pr","github_create_issue","github_add_comment","github_add_labels"]},"output":{"type":"object","properties":{"branch":{"type":"string","description":"Feature branch name (must include the issue identifier)."},"commit_sha":{"type":"string","description":"SHA of the commit shipping the fix and tests."},"files_changed":{"type":"array","description":"Source files modified by the fix (NOT including test files).","items":{"type":"string"}},"test_files_changed":{"type":"array","description":"Test files added or modified to cover the fix. Should be\nnon-empty whenever `test_status: pass`. May be empty when\n`test_status: no-framework` (genuinely no test runner in\nthe repo).\n","items":{"type":"string"}},"test_command":{"type":"string","description":"Exact command run to validate (e.g. `npx nx test server`)."},"test_status":{"type":"string","enum":["pass","fail","no-framework","not-run","skipped"],"description":"Outcome of running the test suite.\n- `pass` — tests ran end-to-end and every assertion passed.\n `test_files_changed` MUST be non-empty in this case (you\n changed code; tests must cover it).\n- `no-framework` — the repo genuinely has no test runner\n (e.g. a docs-only repo, a YAML-config repo, a research\n notebook collection). Reserved for cases where there is\n no test infrastructure to extend — not a permission slip\n to skip tests in a normal codebase.\n- `fail` — tests ran and at least one failed. Do not push\n a broken fix. Return this status, retry will fire once.\n- `not-run` — tests exist but the environment couldn't\n execute them. Explain in `test_notes`. Retry will fire.\n- `skipped` — the node short-circuited before running tests\n because a precondition was not met: `open-pr-exists` (Step\n 0b found an open PR with the issue identifier in its\n title; `existing_pr_url` MUST be populated) or `staged`\n (Step 0: a preview run filed no issue). `skipped_reason`\n MUST be populated. Downstream `create_pr` is bypassed and\n the workflow routes to `notify`.\n"},"skipped_reason":{"type":"string","description":"Why the node short-circuited. Only set when `test_status` is\n`skipped`: `open-pr-exists` (Step 0b) or `staged` (Step 0).\n","enum":["open-pr-exists","staged"]},"existing_pr_url":{"type":"string","description":"URL of the open PR that triggered the skip. Set when\n`skipped_reason` is `open-pr-exists` so the notify node\ncan link to the prior PR.\n","pattern":"^https?://"},"test_notes":{"type":"string","description":"One-paragraph explanation of which tests were added and what they assert."}},"required":["branch","commit_sha","files_changed","test_files_changed","test_status"]},"eval":[{"name":"test_status_is_pass_or_no_framework","kind":"value","rule":{"output_matches":[{"path":"test_status","in":["pass","no-framework","skipped"]}]}},{"name":"tests_present_when_pass_claimed","kind":"judge","rubric":"You are checking the contract between test_status and test_files_changed.\n\nRead result.data.test_status and result.data.test_files_changed.\n\nRules:\n- If test_status is \"pass\": test_files_changed MUST contain at least\n one real test file path (paths with extensions like .spec.ts,\n .test.ts, .test.tsx, .test.py, _test.go, _spec.rb, .test.rs,\n etc., or paths in a __tests__/, tests/, or spec/ directory).\n An empty array, or paths that are clearly not test files\n (README.md, package.json, source files), is a contract violation.\n- If test_status is \"no-framework\": test_files_changed MAY be empty.\n Pass vacuously.\n- If test_status is \"skipped\": test_files_changed MAY be empty.\n The node short-circuited before writing any code. When\n skipped_reason is \"open-pr-exists\" (Step 0b found an open PR\n for the issue), `existing_pr_url` MUST be populated; when it\n is \"staged\" (a preview run), nothing else is required. If\n skipped_reason is missing, return no.\n- If test_status is \"fail\" or \"not-run\": this evaluator should not\n run (the prior value evaluator catches that). Pass vacuously.\n\nRespond yes if the contract is satisfied, no if it is violated.\n","pass_when":"yes"}],"retry":{"max":1,"instruction":{"auto":true}}},"create_pr":{"name":"Open Pull Request","on_fail":"continue","instruction":"Open a pull request for the fix. The issue is in your context from the create_issue step; its identifier (ISSUE_ID) is the `ref` of the applied `issue` entry in `context.create_issue.safe_outputs`, else `context.create_issue.issueIdentifier`. The branch is `context.implement.branch`.\n\n1. Push the branch to the remote. If the push fails for lack of credentials (a checkout made with `persist-credentials: false`), go on: sweny pushes the head branch itself before it opens the PR.\n2. Request the PR: with `emit_output` (type `pr`, `head` = the branch, `base` = the base branch, default `main`) when you have it; sweny opens it after this step and reuses an open PR for the same branch instead of failing. Without `emit_output`, call `github_create_pr` (use this exact tool name, not `create_pull_request` or any other variant from ToolSearch); if it returns `reused: true`, treat it as success and do NOT close it and call again.\n3. PR title MUST start with the issue identifier in brackets. Format: `[ISSUE_ID] fix: {short description}`.\n4. In the PR body, include: summary of the bug, what the fix does, and a link to the issue (its `url` in `context.create_issue.safe_outputs`, else context.create_issue.issueUrl). If the investigation found a Sentry issue, include \"Fixes {sentryShortId}\" in the PR body so Sentry auto-resolves on merge. If the issue tracker is Linear, also include the line \"Fixes ISSUE_ID\" (e.g. \"Fixes OFF-1234\") so Linear links the PR and moves the issue to Done on merge.\n5. Labels: `[\"sweny\", \"agent\", \"triage\"]`.\n\nIf context.prTemplate is provided, use it as the format for the PR body. Otherwise use a clear structure with: Summary, Changes, Testing, and Related Issues.\n\nIf context.cloudRunId is provided, append this HTML comment to the end of the PR body: <!-- sweny:run_id:{context.cloudRunId} -->\n\nReturn the branch and the PR title you requested (and the PR URL and number when a tool returned them).","skills":["github"],"permissions":"write","outputs":[{"type":"pr","max":1,"labels":["sweny","agent","triage"]}],"tools":{"deny":["github_create_pr","github_create_issue","github_add_comment","github_add_labels"]},"eval":[{"name":"pr_was_created","kind":"function","rule":{"any_tool_called":["emit_output","github_create_pr"]}}],"retry":{"max":1,"instruction":{"auto":true}}},"notify":{"name":"Notify Team","instruction":"Send a notification summarizing the triage result:\n\n1. Include: alert summary, severity, root cause (1-2 sentences), and links to any created issues or PRs.\n Issues and PRs sweny filed are in `safe_outputs` of the create_issue, skip and create_pr steps\n (`ref` and `url` of each `applied` entry).\n2. For critical/high severity, make the notification urgent.\n3. For medium/low, a standard notification is fine.\n4. If any `safe_outputs` entry has status `staged`, this run is a preview: send nothing, and put the\n notification you would have sent in your summary.\n\nUse whichever notification channel is available to you.","skills":["slack","notification"]}},"edges":[{"from":"gather","to":"investigate"},{"from":"investigate","to":"create_issue","when":{"expr":"investigate.novel_count > 0 && investigate.highest_severity in ['medium', 'high', 'critical']"},"description":"at least one novel finding, and the highest severity is medium or higher"},{"from":"investigate","to":"skip","when":{"expr":"investigate.novel_count == 0 || investigate.highest_severity == 'low'"},"description":"no novel findings, or the highest severity is low"},{"from":"create_issue","to":"implement","when":{"expr":"investigate.fixable_count > 0"},"description":"at least one novel finding has fix_complexity simple or moderate AND fix_approach is provided"},{"from":"create_issue","to":"notify","description":"all novel findings have fix_complexity complex, OR no clear fix_approach"},{"from":"skip","to":"notify"},{"from":"implement","to":"notify","when":{"expr":"implement.test_status == 'skipped'"},"description":"the implement step was skipped (an open PR already exists, or a staged preview was found)"},{"from":"implement","to":"create_pr","when":{"expr":"implement.test_status in ['pass', 'no-framework']"},"description":"the fix is committed and its tests passed (or the repo has no test framework)"},{"from":"create_pr","to":"notify"}],"skills":{}};
2
+ export const implementWorkflow = {"id":"implement","name":"Implement Fix","workflow_type":"pr_review","description":"Implement a code fix for an issue and open a pull request","entry":"analyze","permissions":"write","safe_outputs":{"allow":["comment","pr"],"max":3},"nodes":{"analyze":{"name":"Analyze Issue","instruction":"Read the issue details and understand what needs to be fixed:\n\n1. Fetch the issue from the tracker (GitHub or Linear).\n2. **Check for an existing open PR for this issue.** Call\n `github_search_issues` (GitHub's `/search/issues` endpoint returns\n both issues and PRs) with `type:pr state:open` and the issue\n identifier wrapped in brackets — e.g. query\n `[OFF-1234] in:title type:pr state:open`. If the response contains\n one or more PRs whose title starts with `[<issueIdentifier>]`,\n STOP analysis. Output `has_open_pr: true`, `existing_pr_url`\n (the URL of the open PR) and a short `issue_summary` noting the\n skip; leave `fix_plan` set to a one-line \"Skip: open PR\n <url> already exists\". The workflow will route to `notify` and\n the team will be told the prior PR is still pending.\n Rationale: re-implementing while an open PR exists produces a\n duplicate (or worse, the agent closes its own prior PR mid-run\n and opens a new one — exactly the thrash seen in\n `letsoffload/permit-service` PR #81 → #82 and\n `letsoffload/offload` PR #572 → #573).\n3. Read the relevant source files to understand the current code.\n4. Identify the exact files and lines that need to change.\n5. Plan the fix approach.\n\nOutput a clear analysis of what needs to change and why, plus three\nrouting fields: `has_open_pr` (true only when step 2 found an open PR),\n`risk_level` (low, medium or high), and `plan_is_clear` (true only when\nthe plan names the exact files and changes). sweny implements the fix\nonly when there is no open PR, the risk is low or medium, and the plan\nis clear; otherwise it skips.","skills":["github","linear"],"permissions":"read","output":{"type":"object","properties":{"issue_summary":{"type":"string"},"files_to_change":{"type":"array","items":{"type":"string"}},"fix_plan":{"type":"string"},"risk_level":{"type":"string","enum":["low","medium","high"]},"existing_pr_url":{"type":"string","description":"URL of an open PR found in step 2 whose title starts with the\nissue identifier in brackets. Set ONLY when a prior PR exists\nand the analyze node is short-circuiting. Triggers the\n`analyze → notify` edge.\n","pattern":"^https?://"},"has_open_pr":{"type":"boolean","description":"true when step 2 found an open PR for this issue (and\nexisting_pr_url is set), else false. Routes analyze to notify.\n"},"plan_is_clear":{"type":"boolean","description":"true when fix_plan names the exact files and changes, so the fix\ncan be implemented without guessing; false when the fix is\nunclear or needs a decision first.\n"}},"required":["issue_summary","fix_plan","has_open_pr","risk_level","plan_is_clear"]}},"implement":{"name":"Implement Fix","instruction":"Implement the planned fix:\n\n1. Create a feature branch. The branch name MUST start with the issue\n identifier from `context.input.issueIdentifier`, lowercased, followed\n by a short kebab-case description: e.g. `off-1234-fix-null-check`.\n2. Make the necessary code changes.\n3. Ensure changes are minimal and focused — fix the bug, nothing more.\n4. Stage and commit. Start the commit message with the issue identifier\n in brackets, e.g. `[OFF-1234] fix: guard null projectId`.\n\nStop after the commit. Do NOT push or open the PR: the dedicated `create_pr`\nnode pushes the branch and requests the PR.\n\nIf the fix is too risky or complex, explain why and skip.","skills":["github"],"permissions":{"access":"write","deny":["net"]},"tools":{"deny":["github_create_pr","github_create_issue","github_add_comment","github_add_labels"]}},"create_pr":{"name":"Open Pull Request","on_fail":"continue","instruction":"Open a pull request for the fix:\n\n1. Push the branch to the remote. If the push fails for lack of credentials (a checkout made with `persist-credentials: false`), go on: sweny pushes the head branch itself before it opens the PR.\n2. Request the PR: with `emit_output` (type `pr`, `head` = the branch, `base` = the base branch, default `main`) when you have it; sweny opens it after this step and reuses an open PR for the same branch instead of failing. Without `emit_output`, call `github_create_pr`. The PR title MUST start with the issue identifier in brackets: `[{context.input.issueIdentifier}] type: short description` (e.g. `[OFF-1234] fix: guard null projectId`).\n3. Reference the original issue in the PR body. If the issue tracker is Linear, include the line \"Fixes {context.input.issueIdentifier}\" (e.g. \"Fixes OFF-1234\") so Linear links the PR and moves the issue to Done on merge.\n4. Labels: add `task` (or `feature` if the issue is a feature request); `sweny` and `agent` are always added.\n\nIf context.prTemplate is provided, use it as the format for the PR body. Otherwise use a clear structure with: Summary, Changes, Testing, and Related Issues.\n\nIf context.cloudRunId is provided, append this HTML comment to the end of the PR body: <!-- sweny:run_id:{context.cloudRunId} -->\n\nReturn the branch and the PR title you requested.","skills":["github"],"permissions":"write","outputs":[{"type":"pr","max":1,"labels":["sweny","agent"]}],"tools":{"deny":["github_create_pr","github_create_issue","github_add_comment","github_add_labels"]}},"notify":{"name":"Notify","instruction":"Send a notification about the implementation result:\n\n1. Include: issue reference, PR link, brief summary of changes. The PR sweny opened is in\n `context.create_pr.safe_outputs` (`ref` and `url` of the `applied` entry).\n2. Keep it concise: one message, not a wall of text.\n3. If any `safe_outputs` entry has status `staged`, this run is a preview: send nothing, and put the\n notification you would have sent in your summary.","skills":["slack","notification"]},"skip":{"name":"Skip - Too Complex","instruction":"The fix was determined to be too complex or risky for automated implementation.\nAdd a comment to the issue explaining what was found and why it needs manual attention\n(with `emit_output` type `comment` when you have it).","skills":["linear","github"],"outputs":[{"type":"comment","max":1,"number":{"input":"issueIdentifier"}}]}},"edges":[{"from":"analyze","to":"notify","when":{"expr":"analyze.has_open_pr == true || exists analyze.existing_pr_url"},"description":"an open PR for this issue already exists (analyze.existing_pr_url is set); skip the implement and create_pr nodes"},{"from":"analyze","to":"implement","when":{"expr":"analyze.has_open_pr == false && !(exists analyze.existing_pr_url) && analyze.risk_level in ['low', 'medium'] && analyze.plan_is_clear == true"},"description":"no open PR exists, the fix risk level is low or medium, and a clear plan exists"},{"from":"analyze","to":"skip","description":"the fix is too complex, risky, or unclear"},{"from":"implement","to":"create_pr"},{"from":"skip","to":"notify"},{"from":"create_pr","to":"notify"}],"skills":{}};
3
3
  export const seedContentWorkflow = {"id":"seed-content","name":"Content Generation Pipeline","workflow_type":"content_generation","description":"Audit content gaps, generate educational content, validate quality, and publish to Supabase","entry":"audit","nodes":{"audit":{"name":"Audit Content Gaps","instruction":"You are auditing an educational platform's content library.\n\nUse supabase_count to check how many items exist for each combination of:\n- Content types: worksheets, games, lessons\n- Subjects: math, science, english, history, geography, economics, music, art, life-skills, foreign-language\n- Difficulties: beginner, easy, medium, hard\n\nAlso check the input parameters — if the user specified a subject, topic, difficulty, and count,\nskip the full audit and just report what they want generated.\n\nReturn a structured content plan: what to generate, how many, at what difficulty and grade level.\nPrioritize gaps where a subject has ZERO content of a given type.","skills":["supabase"],"output":{"type":"object","properties":{"plan":{"type":"array","items":{"type":"object","properties":{"contentType":{"type":"string"},"subject":{"type":"string"},"topic":{"type":"string"},"difficulty":{"type":"string"},"gradeLevel":{"type":"string"},"count":{"type":"number"},"reason":{"type":"string"}},"required":["contentType","subject","topic","difficulty","count"]}},"summary":{"type":"string"}},"required":["plan","summary"]}},"generate":{"name":"Generate Content","instruction":"You are an expert educator creating content for children ages 5-14.\n\nFor each item in the content plan from the previous step, generate the content directly.\nThe content must be high-quality, engaging, age-appropriate, and educationally sound.\n\n**For worksheets:**\nGenerate a JSON array of problems. Each problem needs: \"problem\", \"answer\", \"format\" (answer-line | multiple-choice | write-on).\nRequirements:\n- Every answer MUST be correct. Double-check math, facts, spelling.\n- Problems must progress in difficulty within the set.\n- Use at least 2 different problem structures (e.g., equations + word problems for math).\n- Vary phrasing — no two problems should feel copy-pasted.\n- For the target grade level, use appropriate vocabulary and complexity.\n\n**For lessons:**\nGenerate complete HTML + CSS + JS for an interactive lesson.\nRequirements:\n- Must have substantial educational content (not just a shell with navigation).\n- Include interactive elements: quizzes, click-to-reveal, drag-and-drop.\n- Must be visually engaging with colors, icons, and clear typography.\n- Include practice exercises with immediate feedback.\n- Minimum 5 teaching sections plus 2 practice activities.\n\n**For games:**\nGenerate a description and educational requirements only (actual game code is generated\nby the platform's Phaser-based generator).\n\nUse supabase_insert to write each piece of content to the appropriate table.\n\nTable schemas:\n- worksheets: id (auto), title, subject, topic, difficulty, grade_level, num_questions, problems (jsonb), status='published', source='ai-seed'\n- lessons: id (auto), title, subject, difficulty, grade_level, lesson_type, html_code, css_code, js_code, status='published', source='ai-seed'\n- games: id (auto), title, subject, difficulty, grade_level, game_type, html_code, css_code, js_code, status='published', source='ai-seed'\n\nReturn a summary of what was generated and inserted.","skills":["supabase"],"output":{"type":"object","properties":{"generated":{"type":"array","items":{"type":"object","properties":{"contentType":{"type":"string"},"title":{"type":"string"},"subject":{"type":"string"},"id":{"type":"string"},"status":{"type":"string"}}}},"totalGenerated":{"type":"number"},"errors":{"type":"array","items":{"type":"string"}}},"required":["generated","totalGenerated"]}},"validate":{"name":"Validate Content Quality","instruction":"Review the content that was just generated and inserted.\n\nFor each item, use supabase_query to fetch it back and verify:\n\n**Worksheets:**\n- Parse the problems JSON — are all answers correct?\n- Are problems diverse (not repetitive)?\n- Is difficulty appropriate for the stated grade level?\n- Are there the right number of questions?\n\n**Lessons:**\n- Is the HTML substantial (> 500 characters)?\n- Does it contain actual educational content (not just navigation shells)?\n- Are there interactive elements?\n\n**Games:**\n- Does the HTML contain a working game structure?\n\nFlag any issues. If critical issues are found (wrong answers, empty content),\nuse supabase_update to set status='draft' and add a note.\n\nReturn a quality report.","skills":["supabase"],"output":{"type":"object","properties":{"totalReviewed":{"type":"number"},"passed":{"type":"number"},"flagged":{"type":"number"},"issues":{"type":"array","items":{"type":"object","properties":{"id":{"type":"string"},"title":{"type":"string"},"issue":{"type":"string"},"severity":{"type":"string"},"action":{"type":"string"}}}},"summary":{"type":"string"}},"required":["totalReviewed","passed","flagged","summary"]}},"report":{"name":"Generate Report","instruction":"Compile a final report of the content generation run.\n\nInclude:\n- Total content generated by type and subject\n- Quality validation results\n- Any issues found and actions taken\n- Recommendations for next content generation run (what gaps remain)\n\nFormat as a clean markdown summary that a solo operator can scan in 30 seconds.","skills":[],"output":{"type":"object","properties":{"markdown":{"type":"string"},"nextPriorities":{"type":"array","items":{"type":"string"}}},"required":["markdown"]}}},"edges":[{"from":"audit","to":"generate"},{"from":"generate","to":"validate"},{"from":"validate","to":"report"}],"skills":{}};