@sweny-ai/core 0.1.90 → 0.1.92

package/dist/cli/cloud-lifecycle.d.ts

@@ -0,0 +1,161 @@
+/**
+ * Lifecycle-endpoint reporter for SWEny Cloud.
+ *
+ * Posts run lifecycle events (start, finish, optional per-node updates) to
+ * cloud's universal ingest API at `${cloudUrl}/api/runs[/:id/...]`. Auth via
+ * the same `SWENY_CLOUD_TOKEN` that the legacy /api/report flow uses.
+ *
+ * This reporter is CI-agnostic: it works from GitHub Actions, GitLab CI,
+ * CircleCI, a developer's laptop — anywhere a workflow runs and a token is
+ * configured. The legacy `reportToCloud` (in cloud-report.ts) keeps working
+ * for back-compat; new code paths should prefer this lifecycle flow.
+ *
+ * Source proposal: cloud/docs/proposals/02-cloud-architecture-for-any-run.md
+ * (task 05).
+ *
+ * All errors are swallowed: cloud reporting MUST NEVER block the workflow.
+ */
+import type { NodeResult, Observer, Workflow } from "../types.js";
+export type TriggerSource = "github_action" | "gitlab_ci" | "circleci" | "buildkite" | "other_ci" | "manual" | "cron" | "mcp" | "unknown";
+export interface CloudReportConfig {
+    cloudToken: string;
+    cloudUrl?: string;
+    repository?: string;
+}
+export interface StartRunInput {
+    workflow_id: string;
+    workflow_type?: string;
+    trigger_source?: TriggerSource;
+    trigger_metadata?: Record<string, unknown>;
+    metadata?: Record<string, unknown>;
+    run_uuid?: string;
+}
+export interface StartRunResult {
+    run_id: string;
+    dashboard_url?: string;
+    stream_url?: string;
+    idempotent_replay?: boolean;
+}
+export interface FinishRunInput {
+    status: "success" | "failed" | "skipped" | "completed" | "partial";
+    metrics?: Record<string, unknown>;
+    duration_ms?: number;
+    error?: string;
+}
+/**
+ * Detect the CI trigger source from environment variables. Best-effort;
+ * returns "unknown" if no signal is present.
+ */
+export declare function detectTriggerSource(env?: NodeJS.ProcessEnv): TriggerSource;
+/**
+ * Build the trigger_metadata blob from env. Each CI provider exposes a
+ * different set of variables; pick the ones that are useful for debugging
+ * a specific run later (run id, actor, ref).
+ */
+export declare function buildTriggerMetadata(source: TriggerSource, env?: NodeJS.ProcessEnv): Record<string, unknown>;
+/**
+ * Generate a run UUID. Each call to startRun() should generate exactly one
+ * and reuse it for the matching finishRun() — this is the idempotency key.
+ */
+export declare function newRunUuid(): string;
+/**
+ * Build a run-start payload from a Workflow + env. Pure function; the caller
+ * is responsible for passing it to `startRun()`.
+ */
+export declare function buildStartRunPayload(workflow: Pick<Workflow, "id" | "workflow_type">, options: {
+    runUuid: string;
+    env?: NodeJS.ProcessEnv;
+}): StartRunInput;
+/**
+ * POST /api/runs — start a run, returning the run id (or null on failure).
+ * Failure is silent: cloud reporting must not block workflow execution.
+ */
+export declare function startRun(config: CloudReportConfig, payload: StartRunInput): Promise<StartRunResult | null>;
+/**
+ * POST /api/runs/:id/finish — record the final outcome + metrics.
+ */
+export declare function finishRun(config: CloudReportConfig, runId: string, payload: FinishRunInput): Promise<boolean>;
+/**
+ * POST /api/runs/:id/node — record a node lifecycle event. Optional helper
+ * for callers that want streaming updates; safe to skip if you only need
+ * start + finish. Fire-and-forget.
+ */
+export declare function postNodeEvent(config: CloudReportConfig, runId: string, event: {
+    event: "enter" | "exit" | "progress";
+    node: string;
+    timestamp?: string;
+    status?: "success" | "failed" | "skipped";
+    duration_ms?: number;
+    data?: Record<string, unknown>;
+}): Promise<void>;
+/**
+ * Derive a `metrics` blob from the executor's NodeResult map.
+ *
+ * For now this is intentionally minimal: total node count, failed-node
+ * count, success rate. Per-workflow-type metric extraction (Caught /
+ * Calibration / Missed for pr_review, flake rate for e2e_test, etc.) is
+ * the renderer's job; the engine just ships what it has.
+ */
+export declare function deriveGenericMetrics(results: Map<string, NodeResult>, durationMs: number): {
+    duration_ms: number;
+    node_count: number;
+    failed_nodes: number;
+    success_rate: number;
+};
+export interface CloudLifecycleHandle {
+    runUuid: string;
+    runId: string;
+    dashboardUrl?: string;
+}
+/**
+ * Open a cloud lifecycle session for an upcoming workflow run.
+ *
+ * Returns a handle if the cloud token is set AND `startRun()` succeeds; null
+ * otherwise. Callers should ALWAYS handle the null case — cloud reporting
+ * is opt-in and best-effort, the workflow must run regardless.
+ *
+ * Pair every successful call with `finishCloudLifecycle(handle, …)` once the
+ * workflow completes (success or failure).
+ */
+export declare function beginCloudLifecycle(config: {
+    cloudToken?: string;
+    repository?: string;
+}, workflow: Pick<Workflow, "id" | "workflow_type">): Promise<CloudLifecycleHandle | null>;
+/**
+ * Close a cloud lifecycle session opened by `beginCloudLifecycle`.
+ *
+ * No-op when handle is null (cloud reporting was disabled or startRun
+ * failed). Status maps the engine's `success | failed | partial` outcome
+ * onto the cloud's accepted enum. Failure is silent — the workflow's
+ * exit code already reflects the truth.
+ */
+export declare function finishCloudLifecycle(config: {
+    cloudToken?: string;
+}, handle: CloudLifecycleHandle | null, results: Map<string, NodeResult>, durationMs: number, status?: "success" | "failed" | "partial"): Promise<void>;
+/**
+ * Build an Observer that ships per-node lifecycle events to cloud.
+ *
+ * Maps the engine's ExecutionEvent stream onto `POST /api/runs/:id/node`:
+ *   node:enter   → { event: "enter",  node }
+ *   node:exit    → { event: "exit",   node, status, duration_ms }
+ *   node:progress → { event: "progress", node, data: { message } }
+ *   node:retry   → { event: "progress", node, data: { retry: true, attempt, reason } }
+ * Other events (workflow:start, tool:*, route, workflow:end) are dropped.
+ *
+ * Returns undefined when the handle is null (no cloud session) or the
+ * token is missing. The observer captures `node:enter` timestamps in a
+ * closure-scoped Map so it can compute duration_ms on the matching exit
+ * without depending on any external state.
+ *
+ * Hot-path safety contract:
+ *   1. The observer never throws synchronously. The whole body is
+ *      wrapped in try/catch — any future ExecutionEvent shape change
+ *      that breaks a field access cannot crash the engine.
+ *   2. The observer never awaits. postNodeEvent is fired with .catch
+ *      to swallow any rejection so node never sees an unhandledRejection.
+ *   3. The Map is keyed by node id; collisions only happen if the same
+ *      node id runs concurrently, which the engine does not do today.
+ */
+export declare function createCloudStreamObserver(config: {
+    cloudToken?: string;
+}, handle: CloudLifecycleHandle | null): Observer | undefined;

package/dist/cli/cloud-lifecycle.js

@@ -0,0 +1,328 @@
+/**
+ * Lifecycle-endpoint reporter for SWEny Cloud.
+ *
+ * Posts run lifecycle events (start, finish, optional per-node updates) to
+ * cloud's universal ingest API at `${cloudUrl}/api/runs[/:id/...]`. Auth via
+ * the same `SWENY_CLOUD_TOKEN` that the legacy /api/report flow uses.
+ *
+ * This reporter is CI-agnostic: it works from GitHub Actions, GitLab CI,
+ * CircleCI, a developer's laptop — anywhere a workflow runs and a token is
+ * configured. The legacy `reportToCloud` (in cloud-report.ts) keeps working
+ * for back-compat; new code paths should prefer this lifecycle flow.
+ *
+ * Source proposal: cloud/docs/proposals/02-cloud-architecture-for-any-run.md
+ * (task 05).
+ *
+ * All errors are swallowed: cloud reporting MUST NEVER block the workflow.
+ */
+import { randomUUID } from "node:crypto";
+const CLOUD_URL_DEFAULT = "https://cloud.sweny.ai";
+const TIMEOUT_MS = 10_000;
+// startRun runs on the critical path BEFORE execute(), so a slow cloud
+// would delay every workflow start. Cap it tighter than the general
+// timeout — if cloud can't accept the run-start in 3s, skip and run
+// uninstrumented rather than make the user wait.
+const START_TIMEOUT_MS = 3_000;
+/**
+ * Detect the CI trigger source from environment variables. Best-effort;
+ * returns "unknown" if no signal is present.
+ */
+export function detectTriggerSource(env = process.env) {
+    if (env.GITHUB_ACTIONS === "true")
+        return "github_action";
+    if (env.GITLAB_CI === "true")
+        return "gitlab_ci";
+    if (env.CIRCLECI === "true")
+        return "circleci";
+    if (env.BUILDKITE === "true")
+        return "buildkite";
+    if (env.CI === "true" || env.CI === "1")
+        return "other_ci";
+    return "manual";
+}
+/**
+ * Build the trigger_metadata blob from env. Each CI provider exposes a
+ * different set of variables; pick the ones that are useful for debugging
+ * a specific run later (run id, actor, ref).
+ */
+export function buildTriggerMetadata(source, env = process.env) {
+    switch (source) {
+        case "github_action":
+            return {
+                runner_id: env.RUNNER_NAME,
+                workflow_run_id: env.GITHUB_RUN_ID,
+                workflow_run_attempt: env.GITHUB_RUN_ATTEMPT,
+                actor: env.GITHUB_ACTOR,
+                event_name: env.GITHUB_EVENT_NAME,
+                ref: env.GITHUB_REF,
+                sha: env.GITHUB_SHA,
+            };
+        case "gitlab_ci":
+            return {
+                pipeline_id: env.CI_PIPELINE_ID,
+                job_id: env.CI_JOB_ID,
+                actor: env.GITLAB_USER_LOGIN,
+                ref: env.CI_COMMIT_REF_NAME,
+                sha: env.CI_COMMIT_SHA,
+            };
+        case "circleci":
+            return {
+                build_num: env.CIRCLE_BUILD_NUM,
+                actor: env.CIRCLE_USERNAME,
+                sha: env.CIRCLE_SHA1,
+            };
+        default:
+            return {};
+    }
+}
+/**
+ * Generate a run UUID. Each call to startRun() should generate exactly one
+ * and reuse it for the matching finishRun() — this is the idempotency key.
+ */
+export function newRunUuid() {
+    return randomUUID();
+}
+/**
+ * Build a run-start payload from a Workflow + env. Pure function; the caller
+ * is responsible for passing it to `startRun()`.
+ */
+export function buildStartRunPayload(workflow, options) {
+    const env = options.env ?? process.env;
+    const trigger_source = detectTriggerSource(env);
+    const trigger_metadata = buildTriggerMetadata(trigger_source, env);
+    const metadata = {};
+    if (env.GITHUB_REF)
+        metadata.branch = env.GITHUB_REF.replace(/^refs\/heads\//, "");
+    if (env.GITHUB_SHA)
+        metadata.commit_sha = env.GITHUB_SHA;
+    if (env.GITHUB_ACTOR)
+        metadata.actor = env.GITHUB_ACTOR;
+    return {
+        workflow_id: workflow.id,
+        workflow_type: workflow.workflow_type ?? "generic",
+        trigger_source,
+        trigger_metadata,
+        metadata,
+        run_uuid: options.runUuid,
+    };
+}
+/**
+ * POST /api/runs — start a run, returning the run id (or null on failure).
+ * Failure is silent: cloud reporting must not block workflow execution.
+ */
+export async function startRun(config, payload) {
+    const cloudUrl = config.cloudUrl ?? process.env.SWENY_CLOUD_URL ?? CLOUD_URL_DEFAULT;
+    try {
+        const res = await fetch(`${cloudUrl}/api/runs`, {
+            method: "POST",
+            headers: {
+                "Content-Type": "application/json",
+                Authorization: `Bearer ${config.cloudToken}`,
+            },
+            body: JSON.stringify(payload),
+            signal: AbortSignal.timeout(START_TIMEOUT_MS),
+        });
+        if (!res.ok)
+            return null;
+        const data = (await res.json().catch(() => ({})));
+        if (!data.run_id)
+            return null;
+        return data;
+    }
+    catch {
+        return null;
+    }
+}
+/**
+ * POST /api/runs/:id/finish — record the final outcome + metrics.
+ */
+export async function finishRun(config, runId, payload) {
+    const cloudUrl = config.cloudUrl ?? process.env.SWENY_CLOUD_URL ?? CLOUD_URL_DEFAULT;
+    try {
+        const res = await fetch(`${cloudUrl}/api/runs/${encodeURIComponent(runId)}/finish`, {
+            method: "POST",
+            headers: {
+                "Content-Type": "application/json",
+                Authorization: `Bearer ${config.cloudToken}`,
+            },
+            body: JSON.stringify(payload),
+            signal: AbortSignal.timeout(TIMEOUT_MS),
+        });
+        return res.ok;
+    }
+    catch {
+        return false;
+    }
+}
+/**
+ * POST /api/runs/:id/node — record a node lifecycle event. Optional helper
+ * for callers that want streaming updates; safe to skip if you only need
+ * start + finish. Fire-and-forget.
+ */
+export async function postNodeEvent(config, runId, event) {
+    const cloudUrl = config.cloudUrl ?? process.env.SWENY_CLOUD_URL ?? CLOUD_URL_DEFAULT;
+    try {
+        await fetch(`${cloudUrl}/api/runs/${encodeURIComponent(runId)}/node`, {
+            method: "POST",
+            headers: {
+                "Content-Type": "application/json",
+                Authorization: `Bearer ${config.cloudToken}`,
+            },
+            body: JSON.stringify({ ...event, timestamp: event.timestamp ?? new Date().toISOString() }),
+            signal: AbortSignal.timeout(TIMEOUT_MS),
+        });
+    }
+    catch {
+        // Silent — never block the workflow.
+    }
+}
+/**
+ * Derive a `metrics` blob from the executor's NodeResult map.
+ *
+ * For now this is intentionally minimal: total node count, failed-node
+ * count, success rate. Per-workflow-type metric extraction (Caught /
+ * Calibration / Missed for pr_review, flake rate for e2e_test, etc.) is
+ * the renderer's job; the engine just ships what it has.
+ */
+export function deriveGenericMetrics(results, durationMs) {
+    const nodeCount = results.size;
+    const failedNodes = [...results.values()].filter((r) => r.status === "failed").length;
+    return {
+        duration_ms: durationMs,
+        node_count: nodeCount,
+        failed_nodes: failedNodes,
+        success_rate: nodeCount > 0 ? (nodeCount - failedNodes) / nodeCount : 0,
+    };
+}
+/**
+ * Open a cloud lifecycle session for an upcoming workflow run.
+ *
+ * Returns a handle if the cloud token is set AND `startRun()` succeeds; null
+ * otherwise. Callers should ALWAYS handle the null case — cloud reporting
+ * is opt-in and best-effort, the workflow must run regardless.
+ *
+ * Pair every successful call with `finishCloudLifecycle(handle, …)` once the
+ * workflow completes (success or failure).
+ */
+export async function beginCloudLifecycle(config, workflow) {
+    if (!config.cloudToken)
+        return null;
+    const runUuid = newRunUuid();
+    const payload = buildStartRunPayload(workflow, { runUuid });
+    const reportConfig = {
+        cloudToken: config.cloudToken,
+        repository: config.repository,
+    };
+    const result = await startRun(reportConfig, payload);
+    if (!result)
+        return null;
+    return {
+        runUuid,
+        runId: result.run_id,
+        dashboardUrl: result.dashboard_url,
+    };
+}
+/**
+ * Close a cloud lifecycle session opened by `beginCloudLifecycle`.
+ *
+ * No-op when handle is null (cloud reporting was disabled or startRun
+ * failed). Status maps the engine's `success | failed | partial` outcome
+ * onto the cloud's accepted enum. Failure is silent — the workflow's
+ * exit code already reflects the truth.
+ */
+export async function finishCloudLifecycle(config, handle, results, durationMs, status = "success") {
+    if (!handle || !config.cloudToken)
+        return;
+    const reportConfig = { cloudToken: config.cloudToken };
+    await finishRun(reportConfig, handle.runId, {
+        status,
+        duration_ms: durationMs,
+        metrics: deriveGenericMetrics(results, durationMs),
+    });
+}
+/**
+ * Build an Observer that ships per-node lifecycle events to cloud.
+ *
+ * Maps the engine's ExecutionEvent stream onto `POST /api/runs/:id/node`:
+ *   node:enter   → { event: "enter",  node }
+ *   node:exit    → { event: "exit",   node, status, duration_ms }
+ *   node:progress → { event: "progress", node, data: { message } }
+ *   node:retry   → { event: "progress", node, data: { retry: true, attempt, reason } }
+ * Other events (workflow:start, tool:*, route, workflow:end) are dropped.
+ *
+ * Returns undefined when the handle is null (no cloud session) or the
+ * token is missing. The observer captures `node:enter` timestamps in a
+ * closure-scoped Map so it can compute duration_ms on the matching exit
+ * without depending on any external state.
+ *
+ * Hot-path safety contract:
+ *   1. The observer never throws synchronously. The whole body is
+ *      wrapped in try/catch — any future ExecutionEvent shape change
+ *      that breaks a field access cannot crash the engine.
+ *   2. The observer never awaits. postNodeEvent is fired with .catch
+ *      to swallow any rejection so node never sees an unhandledRejection.
+ *   3. The Map is keyed by node id; collisions only happen if the same
+ *      node id runs concurrently, which the engine does not do today.
+ */
+export function createCloudStreamObserver(config, handle) {
+    if (!handle || !config.cloudToken)
+        return undefined;
+    const reportConfig = { cloudToken: config.cloudToken };
+    // Single-threaded-per-node assumption: the engine doesn't run the
+    // same node id twice concurrently, so node id alone is enough as a
+    // key. A future parallelizing executor change would need to revisit.
+    const enterTimes = new Map();
+    const fire = (event) => {
+        postNodeEvent(reportConfig, handle.runId, event).catch(() => {
+            // Cloud reporting must never bubble — postNodeEvent already
+            // swallows internally, but this is belt-and-suspenders.
+        });
+    };
+    return (event) => {
+        try {
+            switch (event.type) {
+                case "node:enter": {
+                    enterTimes.set(event.node, Date.now());
+                    fire({ event: "enter", node: event.node });
+                    break;
+                }
+                case "node:exit": {
+                    const enter = enterTimes.get(event.node);
+                    const duration_ms = typeof enter === "number" ? Date.now() - enter : undefined;
+                    enterTimes.delete(event.node);
+                    fire({
+                        event: "exit",
+                        node: event.node,
+                        status: event.result.status,
+                        duration_ms,
+                    });
+                    break;
+                }
+                case "node:progress": {
+                    fire({
+                        event: "progress",
+                        node: event.node,
+                        data: { message: event.message },
+                    });
+                    break;
+                }
+                case "node:retry": {
+                    fire({
+                        event: "progress",
+                        node: event.node,
+                        data: { retry: true, attempt: event.attempt, reason: event.reason },
+                    });
+                    break;
+                }
+                default:
+                    // Drop workflow:start, sources:resolved, tool:*, route,
+                    // workflow:end. Cloud only models the per-node lifecycle today.
+                    break;
+            }
+        }
+        catch {
+            // Hot-path defense: an unexpected event shape must not crash
+            // the engine. Silent swallow is the correct behavior here.
+        }
+    };
+}

package/dist/cli/main.js

@@ -32,6 +32,7 @@ import { registerSetupCommand } from "./setup.js";
 import { registerPublishCommand } from "./publish.js";
 import { registerSkillCommand } from "./skill.js";
 import { reportToCloud } from "./cloud-report.js";
+import { beginCloudLifecycle, finishCloudLifecycle, createCloudStreamObserver } from "./cloud-lifecycle.js";
 import { runUpgrade, fetchLatestFromNpm } from "./upgrade.js";
 import { maybeNudge, defaultCachePath } from "./version-check.js";
 import { spawnSync } from "node:child_process";
@@ -313,7 +314,6 @@ triageCmd.action(async (options) => {
                     break;
             }
         };
-    const observer = composeObservers(progressObserver, config.stream ? createStreamObserver() : undefined);
     // ── Build workflow input from config ──────────────────────
     const providerCtx = buildProviderCtx(config, mcpServers);
     const { rules, context } = await resolveRulesAndContext(config);
@@ -348,6 +348,15 @@ triageCmd.action(async (options) => {
         rules,
         context: fullContext,
     };
+    // Open the cloud lifecycle session BEFORE composing observers so the
+    // node-streaming observer can attach events to the correct runId.
+    // Null when the token is unset or startRun fails — cloud reporting
+    // must never block the workflow.
+    const cloudHandle = await beginCloudLifecycle(config, triageWorkflow);
+    if (cloudHandle?.dashboardUrl) {
+        console.log(c.subtle(`  cloud: ${cloudHandle.dashboardUrl}`));
+    }
+    const observer = composeObservers(progressObserver, config.stream ? createStreamObserver() : undefined, createCloudStreamObserver(config, cloudHandle));
     try {
         const { results, trace } = await execute(triageWorkflow, workflowInput, {
             skills,
@@ -381,7 +390,19 @@ triageCmd.action(async (options) => {
                 console.error(c.subtle(`  ⚠ could not write GITHUB_STEP_SUMMARY: ${err instanceof Error ? err.message : err}`));
             }
         }
-        // Report to SWEny Cloud (best-effort, never block the run)
+        // Close the cloud lifecycle session opened above. Status reflects
+        // whether any node failed — cloud's runs.status enum accepts the
+        // same vocabulary the engine uses.
+        const triageHasFailed = [...results.values()].some((r) => r.status === "failed");
+        try {
+            await finishCloudLifecycle(config, cloudHandle, results, durationMs, triageHasFailed ? "failed" : "success");
+        }
+        catch {
+            // silent
+        }
+        // Report to SWEny Cloud (best-effort, legacy /api/report path for
+        // back-compat with cloud builds that haven't deployed lifecycle
+        // endpoints yet — runs through both paths so neither side breaks).
         try {
             await reportToCloud(results, durationMs, config, "triage");
         }
@@ -481,7 +502,6 @@ implementCmd.action(async (issueId, options) => {
                 break;
         }
     };
-    const observer = composeObservers(implProgressObserver, Boolean(options.stream) ? createStreamObserver() : undefined);
     // Resolve rules/context from .sweny.yml (same as triage path)
     const providerCtx = buildProviderCtx(config, mcpServers);
     const { rules, context } = await resolveRulesAndContext(config);
@@ -502,6 +522,14 @@ implementCmd.action(async (issueId, options) => {
         rules,
         context: fullImplContext,
     };
+    // Open cloud lifecycle session BEFORE composing observers so the
+    // node-streaming observer can attach to the correct runId. See
+    // triage path for rationale.
+    const implCloudHandle = await beginCloudLifecycle(config, implementWorkflow);
+    if (implCloudHandle?.dashboardUrl) {
+        console.log(c.subtle(`  cloud: ${implCloudHandle.dashboardUrl}`));
+    }
+    const observer = composeObservers(implProgressObserver, Boolean(options.stream) ? createStreamObserver() : undefined, createCloudStreamObserver(config, implCloudHandle));
     try {
         const { results } = await execute(implementWorkflow, workflowInput, {
             skills,
@@ -514,6 +542,16 @@ implementCmd.action(async (issueId, options) => {
             offline: config.offline,
         });
         const hasFailed = [...results.values()].some((r) => r.status === "failed");
+        const implDurationMs = Date.now() - implRunStart;
+        // Close the cloud lifecycle session. We do this BEFORE the early
+        // process.exit(1) on failure so cloud sees the final status — a
+        // crashed-without-finish run would stay stuck at "started" forever.
+        try {
+            await finishCloudLifecycle(config, implCloudHandle, results, implDurationMs, hasFailed ? "failed" : "success");
+        }
+        catch {
+            // silent
+        }
         if (hasFailed) {
             console.error(chalk.red(`\n  Implement workflow failed\n`));
             process.exit(1);
@@ -526,9 +564,9 @@ implementCmd.action(async (issueId, options) => {
         else {
             console.log(chalk.green(`\n  Implement workflow completed\n`));
         }
-        // Report to SWEny Cloud (best-effort)
+        // Legacy /api/report back-compat — see triage path.
         try {
-            await reportToCloud(results, Date.now() - implRunStart, config, "implement");
+            await reportToCloud(results, implDurationMs, config, "implement");
         }
         catch {
             // silent
@@ -676,7 +714,6 @@ export async function workflowRunAction(file, options) {
                     break;
             }
         };
-    const observer = composeObservers(wfProgressObserver, options.stream ? createStreamObserver() : undefined);
     // Build workflow input — prefer --input JSON if provided, else fall back to config-derived input
     let workflowInput;
     if (options.input && typeof options.input === "string") {
@@ -709,6 +746,14 @@ export async function workflowRunAction(file, options) {
             context: buildProviderCtx(config, mcpServers),
         };
     }
+    // Open cloud lifecycle session BEFORE composing observers so the
+    // node-streaming observer can attach to the correct runId. See
+    // triage path for rationale.
+    const wfCloudHandle = await beginCloudLifecycle(config, workflow);
+    if (wfCloudHandle?.dashboardUrl && !isJson) {
+        console.log(c.subtle(`  cloud: ${wfCloudHandle.dashboardUrl}`));
+    }
+    const observer = composeObservers(wfProgressObserver, options.stream ? createStreamObserver() : undefined, createCloudStreamObserver(config, wfCloudHandle));
     try {
         const { results, trace } = await execute(workflow, workflowInput, {
             skills,
@@ -720,10 +765,20 @@ export async function workflowRunAction(file, options) {
             fetchAuth: config.fetchAuth,
             offline: config.offline,
         });
+        const wfDurationMs = Date.now() - runStart;
+        const wfHasFailed = [...results.values()].some((r) => r.status === "failed");
+        // Close the cloud lifecycle session BEFORE the JSON early-exit so
+        // every workflow run reports a terminal status, regardless of how
+        // the CLI returns (json, mermaid, or normal stdout).
+        try {
+            await finishCloudLifecycle(config, wfCloudHandle, results, wfDurationMs, wfHasFailed ? "failed" : "success");
+        }
+        catch {
+            // silent
+        }
         if (isJson) {
             process.stdout.write(JSON.stringify(Object.fromEntries(results), null, 2) + "\n");
-            const hasFailed = [...results.values()].some((r) => r.status === "failed");
-            process.exit(hasFailed ? 1 : 0);
+            process.exit(wfHasFailed ? 1 : 0);
             return;
         }
         // Mermaid diagram with execution state
@@ -734,15 +789,14 @@ export async function workflowRunAction(file, options) {
             }
             process.stdout.write(toMermaidBlock(workflow, { state, trace, title: workflow.name }) + "\n");
         }
-        // Report to SWEny Cloud (best-effort)
+        // Legacy /api/report back-compat — see triage path.
         try {
-            await reportToCloud(results, Date.now() - runStart, config, workflow.id);
+            await reportToCloud(results, wfDurationMs, config, workflow.id);
         }
         catch {
             // silent
         }
-        const hasFailed = [...results.values()].some((r) => r.status === "failed");
-        if (hasFailed) {
+        if (wfHasFailed) {
             console.error(chalk.red(`  Workflow failed\n`));
             process.exit(1);
             return;

package/dist/schema.d.ts

@@ -1375,10 +1375,25 @@ export declare const edgeZ: z.ZodObject<{
     when?: string | undefined;
     max_iterations?: number | undefined;
 }>;
+/**
+ * Workflow type discriminator. Cloud uses this to route runs to a
+ * type-specific renderer (Caught/Calibration/Missed for `pr_review`, flake
+ * heatmap for `e2e_test`, source coverage delta for `monitor`, etc.).
+ *
+ * The field is optional on the workflow YAML; absence defaults to `generic`,
+ * which gets a baseline renderer. Marketplace templates published in v1+
+ * are required to declare it.
+ *
+ * Adding a new value here is a deliberate spec change: it requires a new
+ * cloud renderer + metric schema. Don't extend casually.
+ */
+export declare const workflowTypeZ: z.ZodEnum<["pr_review", "e2e_test", "content_generation", "monitor", "data_sync", "generic"]>;
+export type WorkflowType = z.infer<typeof workflowTypeZ>;
 export declare const workflowZ: z.ZodObject<{
     id: z.ZodString;
     name: z.ZodString;
     description: z.ZodDefault<z.ZodString>;
+    workflow_type: z.ZodOptional<z.ZodEnum<["pr_review", "e2e_test", "content_generation", "monitor", "data_sync", "generic"]>>;
     nodes: z.ZodRecord<z.ZodString, z.ZodObject<{
         name: z.ZodString;
         instruction: z.ZodUnion<[z.ZodString, z.ZodObject<{
@@ -2250,6 +2265,7 @@ export declare const workflowZ: z.ZodObject<{
         type?: string | undefined;
     })[] | undefined;
     judge_model?: string | undefined;
+    workflow_type?: "pr_review" | "e2e_test" | "content_generation" | "monitor" | "data_sync" | "generic" | undefined;
     judge_budget?: number | undefined;
 }, {
     id: string;
@@ -2381,6 +2397,7 @@ export declare const workflowZ: z.ZodObject<{
         type?: string | undefined;
     })[] | undefined;
     judge_model?: string | undefined;
+    workflow_type?: "pr_review" | "e2e_test" | "content_generation" | "monitor" | "data_sync" | "generic" | undefined;
     judge_budget?: number | undefined;
 }>;
 /** Parse + validate a raw object as a Workflow. Throws on invalid input. */
@@ -2514,6 +2531,7 @@ export declare function parseWorkflow(raw: unknown): {
         type?: string | undefined;
     })[] | undefined;
     judge_model?: string | undefined;
+    workflow_type?: "pr_review" | "e2e_test" | "content_generation" | "monitor" | "data_sync" | "generic" | undefined;
     judge_budget?: number | undefined;
 };
 export interface WorkflowError {
@@ -2767,6 +2785,11 @@ export declare const workflowJsonSchema: {
             };
             readonly description: "Background knowledge prepended to every node's instruction.";
         };
+        readonly workflow_type: {
+            readonly type: "string";
+            readonly enum: readonly ["pr_review", "e2e_test", "content_generation", "monitor", "data_sync", "generic"];
+            readonly description: "Workflow type discriminator. Cloud uses this to route runs to a type-specific renderer. Optional; absence defaults to 'generic'.";
+        };
         readonly judge_model: {
             readonly type: "string";
             readonly minLength: 1;

package/dist/schema.js

@@ -209,6 +209,19 @@ export const edgeZ = z
     max_iterations: z.number().int().min(1).optional(),
 })
     .strict();
+/**
+ * Workflow type discriminator. Cloud uses this to route runs to a
+ * type-specific renderer (Caught/Calibration/Missed for `pr_review`, flake
+ * heatmap for `e2e_test`, source coverage delta for `monitor`, etc.).
+ *
+ * The field is optional on the workflow YAML; absence defaults to `generic`,
+ * which gets a baseline renderer. Marketplace templates published in v1+
+ * are required to declare it.
+ *
+ * Adding a new value here is a deliberate spec change: it requires a new
+ * cloud renderer + metric schema. Don't extend casually.
+ */
+export const workflowTypeZ = z.enum(["pr_review", "e2e_test", "content_generation", "monitor", "data_sync", "generic"]);
 // Fix #4 gap — workflowZ is intentionally NOT .strict(). The published
 // JSON Schema's `additionalProperties: false` only scopes the properties
 // block, but marketplace workflows routinely carry top-level metadata
@@ -219,6 +232,7 @@ export const workflowZ = z.object({
     id: z.string().min(1),
     name: z.string().min(1),
     description: z.string().default(""),
+    workflow_type: workflowTypeZ.optional(),
     nodes: z.record(nodeZ),
     edges: z.array(edgeZ),
     entry: z.string().min(1),
@@ -541,6 +555,11 @@ export const workflowJsonSchema = {
             items: { $ref: "#/$defs/Source" },
             description: "Background knowledge prepended to every node's instruction.",
         },
+        workflow_type: {
+            type: "string",
+            enum: ["pr_review", "e2e_test", "content_generation", "monitor", "data_sync", "generic"],
+            description: "Workflow type discriminator. Cloud uses this to route runs to a type-specific renderer. Optional; absence defaults to 'generic'.",
+        },
         judge_model: {
             type: "string",
             minLength: 1,

package/dist/types.d.ts

@@ -287,11 +287,18 @@ export interface Edge {
     /** Max times this edge can be followed (enables retry loops). Default: unlimited. */
     max_iterations?: number;
 }
+/**
+ * Workflow type discriminator. Cloud uses this to render runs in a
+ * type-specific way. Adding a value requires a corresponding renderer.
+ */
+export type WorkflowType = "pr_review" | "e2e_test" | "content_generation" | "monitor" | "data_sync" | "generic";
 /** A complete workflow definition. Pure data, fully serializable. */
 export interface Workflow {
     id: string;
     name: string;
     description: string;
+    /** Optional. Defaults to "generic" when absent. Required on marketplace templates. */
+    workflow_type?: WorkflowType;
     nodes: Record<string, Node>;
     edges: Edge[];
     entry: string;

package/dist/workflows/browser.js

@@ -1,3 +1,3 @@
-export const triageWorkflow = {"id":"triage","name":"Alert Triage","description":"Investigate a production alert, determine root cause, create an issue, implement a fix, and notify the team","entry":"gather","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 — the investigation step depends on complete context. Use every tool available to you.","skills":["github","sentry","datadog","betterstack","linear"]},"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"],"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**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 (using `linear_add_comment` or `github_add_comment`).\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, create a new one with a clear, actionable title by invoking `linear_create_issue` or `github_create_issue`. You MUST actually call the tool — do NOT synthesize an identifier from an alert ID, commit SHA, or your own imagination. If the tool errors, stop and report the failure; do not invent a fallback identifier. **Use the exact tool names above** — do NOT use generic alternatives like `create_issue` or `create_pull_request` from ToolSearch. The eval check requires the specific tool names listed here.\n3. Include: root cause, severity, affected services, reproduction steps, and recommended fix.\n4. Add appropriate labels (bug, severity level, affected service).\n5. Link to relevant commits, PRs, or existing issues.\n6. Copy the identifier returned by the tool verbatim into the `issueIdentifier` output field. The identifier must match `^[A-Z][A-Z0-9]*-\\d+$` (e.g. `OFF-1234`) — do not prefix it with anything else.\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: \"+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/done, reopen it.\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 created/updated issue identifiers.\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- DO NOT call `create_pull_request`, `github_create_pr`, or any PR/branch tools.\n- Your job is issue creation and duplicate management ONLY.","skills":["linear","github"],"eval":[{"name":"issue_tracker_tool_was_called","kind":"function","rule":{"any_tool_called":["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). MUST be the identifier returned by `linear_create_issue` / `github_create_issue` — do NOT invent a value from a Sentry short-ID or commit SHA. Used by downstream nodes for branch naming and PR linking."},"issueTitle":{"type":"string","description":"Title of the primary issue created"},"issueUrl":{"type":"string","pattern":"^https?://","description":"URL of the primary issue created, as returned by the create-issue tool"},"issues":{"type":"array","minItems":1,"description":"All issues created or updated during this step","items":{"type":"object","properties":{"identifier":{"type":"string"},"title":{"type":"string"},"url":{"type":"string"},"action":{"type":"string","enum":["created","updated","reopened"]}},"required":["identifier","action"]}}},"required":["issueIdentifier","issueTitle","issueUrl","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: \"+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/done, reopen it.\n\nFor **low priority** findings, log a brief note about why they were skipped.","skills":["linear","github"]},"implement":{"name":"Implement Fix","instruction":"Implement the fix identified during investigation, plus the tests that pin\nit as a regression guard. The issue created in the previous step is in your\ncontext — use its identifier for branch naming and commit messages.\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 — verify context.create_issue.issueIdentifier 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; the workflow will route to notify and a human will pick it up.\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 provided in `context.create_issue.issueIdentifier`.\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   `context.create_issue.issueIdentifier`, 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## 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"],"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"],"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"},"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"]}]}},{"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 \"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","instruction":"Open a pull request for the fix. The issue identifier and URL are in your context from the create_issue step.\n\n1. Push the branch to the remote.\n2. Create the PR using the `github_create_pr` tool. **Use this exact tool name** — do NOT use `create_pull_request` or any other variant from ToolSearch. The eval check requires `github_create_pr` specifically.\n3. PR title MUST start with the issue identifier in brackets. Format: `[{context.create_issue.issueIdentifier}] fix: {short description}`.\n4. In the PR body, include: summary of the bug, what the fix does, and a link to the issue (context.create_issue.issueUrl). If the investigation found a Sentry issue, include \"Fixes {sentryShortId}\" in the PR body so Sentry auto-resolves on merge.\n5. Add appropriate labels if available.\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 PR URL and number.","skills":["github"],"eval":[{"name":"pr_was_created","kind":"function","rule":{"any_tool_called":["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.\n2. For critical/high severity, make the notification urgent.\n3. For medium/low, a standard notification is fine.\n\nUse whichever notification channel is available to you.","skills":["slack","notification"]}},"edges":[{"from":"gather","to":"investigate"},{"from":"investigate","to":"create_issue","when":"novel_count is greater than 0 AND highest_severity is medium or higher"},{"from":"investigate","to":"skip","when":"novel_count is 0, OR highest_severity is 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":"create_pr"},{"from":"create_pr","to":"notify"}],"skills":{}};
-export const implementWorkflow = {"id":"implement","name":"Implement Fix","description":"Implement a code fix for an issue and open a pull request","entry":"analyze","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. Read the relevant source files to understand the current code.\n3. Identify the exact files and lines that need to change.\n4. Plan the fix approach.\n\nOutput a clear analysis of what needs to change and why.","skills":["github","linear"],"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"]}},"required":["issue_summary","fix_plan"]}},"implement":{"name":"Implement Fix","instruction":"Implement the planned fix:\n\n1. Create a feature branch.\n2. Make the necessary code changes.\n3. Ensure changes are minimal and focused — fix the bug, nothing more.\n4. Stage and commit with a clear commit message referencing the issue.\n\nIf the fix is too risky or complex, explain why and skip.","skills":["github"]},"create_pr":{"name":"Open Pull Request","instruction":"Open a pull request for the fix:\n\n1. Push the branch to the remote.\n2. Create a PR with a clear title and description.\n3. Reference the original issue in the PR body.\n4. Add appropriate reviewers or labels if possible.\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 PR URL.","skills":["github"]},"notify":{"name":"Notify","instruction":"Send a notification about the implementation result:\n\n1. Include: issue reference, PR link, brief summary of changes.\n2. Keep it concise — one message, not a wall of text.","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.","skills":["github","linear"]}},"edges":[{"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":{}};
-export const seedContentWorkflow = {"id":"seed-content","name":"Content Generation Pipeline","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":{}};
+export const triageWorkflow = {"id":"triage","name":"Alert Triage","workflow_type":"pr_review","description":"Investigate a production alert, determine root cause, create an issue, implement a fix, and notify the team","entry":"gather","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 — the investigation step depends on complete context. Use every tool available to you.","skills":["github","sentry","datadog","betterstack","linear"]},"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"],"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**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 (using `linear_add_comment` or `github_add_comment`).\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, create a new one with a clear, actionable title by invoking `linear_create_issue` or `github_create_issue`. You MUST actually call the tool — do NOT synthesize an identifier from an alert ID, commit SHA, or your own imagination. If the tool errors, stop and report the failure; do not invent a fallback identifier. **Use the exact tool names above** — do NOT use generic alternatives like `create_issue` or `create_pull_request` from ToolSearch. The eval check requires the specific tool names listed here.\n3. Include: root cause, severity, affected services, reproduction steps, and recommended fix.\n4. Add appropriate labels (bug, severity level, affected service).\n5. Link to relevant commits, PRs, or existing issues.\n6. Copy the identifier returned by the tool verbatim into the `issueIdentifier` output field. The identifier must match `^[A-Z][A-Z0-9]*-\\d+$` (e.g. `OFF-1234`) — do not prefix it with anything else.\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: \"+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/done, reopen it.\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 created/updated issue identifiers.\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- DO NOT call `create_pull_request`, `github_create_pr`, or any PR/branch tools.\n- Your job is issue creation and duplicate management ONLY.","skills":["linear","github"],"eval":[{"name":"issue_tracker_tool_was_called","kind":"function","rule":{"any_tool_called":["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). MUST be the identifier returned by `linear_create_issue` / `github_create_issue` — do NOT invent a value from a Sentry short-ID or commit SHA. Used by downstream nodes for branch naming and PR linking."},"issueTitle":{"type":"string","description":"Title of the primary issue created"},"issueUrl":{"type":"string","pattern":"^https?://","description":"URL of the primary issue created, as returned by the create-issue tool"},"issues":{"type":"array","minItems":1,"description":"All issues created or updated during this step","items":{"type":"object","properties":{"identifier":{"type":"string"},"title":{"type":"string"},"url":{"type":"string"},"action":{"type":"string","enum":["created","updated","reopened"]}},"required":["identifier","action"]}}},"required":["issueIdentifier","issueTitle","issueUrl","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: \"+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/done, reopen it.\n\nFor **low priority** findings, log a brief note about why they were skipped.","skills":["linear","github"]},"implement":{"name":"Implement Fix","instruction":"Implement the fix identified during investigation, plus the tests that pin\nit as a regression guard. The issue created in the previous step is in your\ncontext — use its identifier for branch naming and commit messages.\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\n0a. **Precondition — verify context.create_issue.issueIdentifier 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; the workflow will route to notify and 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 provided in `context.create_issue.issueIdentifier`.\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   `context.create_issue.issueIdentifier`, 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## 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"],"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. Today the only\n  accepted reason is `open-pr-exists` (Step 0b found an\n  open PR with the issue identifier in its title).\n  `skipped_reason` and `existing_pr_url` MUST be populated.\n  Downstream `create_pr` is bypassed and the workflow\n  routes to `notify`.\n"},"skipped_reason":{"type":"string","description":"Why the node short-circuited. Only set when `test_status` is\n`skipped`. Today the only valid value is `open-pr-exists`.\n","enum":["open-pr-exists"]},"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 (Step 0b\n  found an open PR for the issue). `skipped_reason` and\n  `existing_pr_url` MUST be populated; if they are missing,\n  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","instruction":"Open a pull request for the fix. The issue identifier and URL are in your context from the create_issue step.\n\n1. Push the branch to the remote.\n2. Create the PR using the `github_create_pr` tool. **Use this exact tool name** — do NOT use `create_pull_request` or any other variant from ToolSearch. The eval check requires `github_create_pr` specifically.\n3. PR title MUST start with the issue identifier in brackets. Format: `[{context.create_issue.issueIdentifier}] fix: {short description}`.\n4. In the PR body, include: summary of the bug, what the fix does, and a link to the issue (context.create_issue.issueUrl). If the investigation found a Sentry issue, include \"Fixes {sentryShortId}\" in the PR body so Sentry auto-resolves on merge.\n5. Add appropriate labels if available.\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 PR URL and number.","skills":["github"],"eval":[{"name":"pr_was_created","kind":"function","rule":{"any_tool_called":["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.\n2. For critical/high severity, make the notification urgent.\n3. For medium/low, a standard notification is fine.\n\nUse whichever notification channel is available to you.","skills":["slack","notification"]}},"edges":[{"from":"gather","to":"investigate"},{"from":"investigate","to":"create_issue","when":"novel_count is greater than 0 AND highest_severity is medium or higher"},{"from":"investigate","to":"skip","when":"novel_count is 0, OR highest_severity is 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":"implement.test_status is \"skipped\" (Step 0b found an open PR already exists for the issue identifier)"},{"from":"implement","to":"create_pr","when":"implement.test_status is \"pass\" or \"no-framework\" (no existing PR; fix was implemented or there is no test framework)"},{"from":"create_pr","to":"notify"}],"skills":{}};
+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","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"],"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.\n2. Make the necessary code changes.\n3. Ensure changes are minimal and focused — fix the bug, nothing more.\n4. Stage and commit with a clear commit message referencing the issue.\n\nIf the fix is too risky or complex, explain why and skip.","skills":["github"]},"create_pr":{"name":"Open Pull Request","instruction":"Open a pull request for the fix:\n\n1. Push the branch to the remote.\n2. Create a PR with a clear title and description.\n3. Reference the original issue in the PR body.\n4. Add appropriate reviewers or labels if possible.\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 PR URL.","skills":["github"]},"notify":{"name":"Notify","instruction":"Send a notification about the implementation result:\n\n1. Include: issue reference, PR link, brief summary of changes.\n2. Keep it concise — one message, not a wall of text.","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.","skills":["github","linear"]}},"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":{}};
+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":{}};

package/dist/workflows/implement.yml

@@ -1,5 +1,6 @@
 id: implement
 name: Implement Fix
+workflow_type: pr_review
 description: Implement a code fix for an issue and open a pull request
 entry: analyze
 nodes:
@@ -9,9 +10,25 @@ nodes:
       Read the issue details and understand what needs to be fixed:
 
       1. Fetch the issue from the tracker (GitHub or Linear).
-      2. Read the relevant source files to understand the current code.
-      3. Identify the exact files and lines that need to change.
-      4. Plan the fix approach.
+      2. **Check for an existing open PR for this issue.** Call
+         `github_search_issues` (GitHub's `/search/issues` endpoint returns
+         both issues and PRs) with `type:pr state:open` and the issue
+         identifier wrapped in brackets — e.g. query
+         `[OFF-1234] in:title type:pr state:open`. If the response contains
+         one or more PRs whose title starts with `[<issueIdentifier>]`,
+         STOP analysis. Output `existing_pr_url`
+         (the URL of the open PR) and a short `issue_summary` noting the
+         skip; leave `fix_plan` set to a one-line "Skip: open PR
+         <url> already exists". The workflow will route to `notify` and
+         the team will be told the prior PR is still pending.
+         Rationale: re-implementing while an open PR exists produces a
+         duplicate (or worse, the agent closes its own prior PR mid-run
+         and opens a new one — exactly the thrash seen in
+         `letsoffload/permit-service` PR #81 → #82 and
+         `letsoffload/offload` PR #572 → #573).
+      3. Read the relevant source files to understand the current code.
+      4. Identify the exact files and lines that need to change.
+      5. Plan the fix approach.
 
       Output a clear analysis of what needs to change and why.
     skills:
@@ -34,6 +51,14 @@ nodes:
             - low
             - medium
             - high
+        existing_pr_url:
+          type: string
+          description: |
+            URL of an open PR found in step 2 whose title starts with the
+            issue identifier in brackets. Set ONLY when a prior PR exists
+            and the analyze node is short-circuiting. Triggers the
+            `analyze → notify` edge.
+          pattern: "^https?://"
       required:
         - issue_summary
         - fix_plan
@@ -95,6 +120,9 @@ nodes:
       - github
       - linear
 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

package/dist/workflows/seed-content.yml

@@ -1,5 +1,6 @@
 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:

package/dist/workflows/triage.yml

@@ -1,5 +1,6 @@
 id: triage
 name: Alert Triage
+workflow_type: pr_review
 description: Investigate a production alert, determine root cause, create an issue, implement a fix, and notify the team
 entry: gather
 nodes:
@@ -360,13 +361,45 @@ nodes:
 
       ## Steps
 
-      0. **Precondition — verify context.create_issue.issueIdentifier is well-formed.**
+      0a. **Precondition — verify context.create_issue.issueIdentifier is well-formed.**
          The identifier MUST match `^[A-Z][A-Z0-9]*-\d+$` (e.g. `OFF-1234`). If it
          is missing, empty, or matches a Sentry short-ID / slug / any other shape,
          STOP immediately — do NOT invent a branch name from the Sentry event,
          commit SHA, or alert payload. Return a failed status with a clear message
          instead; the workflow will route to notify and a human will pick it up.
 
+      0b. **Precondition — check for an existing open PR for this issue.** Call
+         `github_search_issues` (which hits GitHub's `/search/issues` endpoint
+         and returns both issues and PRs) with `type:pr state:open` and the
+         issue identifier wrapped in brackets — e.g. query
+         `[OFF-1234] in:title type:pr state:open` and pass `repo` for scoping.
+         If the response contains one or more PRs whose title starts with
+         `[<issueIdentifier>]`, STOP. Do NOT create a branch, commit, or any
+         new PR. Output:
+
+         ```
+         test_status: "skipped"
+         skipped_reason: "open-pr-exists"
+         existing_pr_url: "<url of the existing PR>"
+         test_files_changed: []
+         files_changed: []
+         branch: ""
+         commit_sha: ""
+         ```
+
+         The downstream `create_pr` node will be bypassed and the workflow will
+         route to `notify` so the team is told the prior PR is still pending.
+
+         Rationale: re-implementing a fix while an open PR already exists
+         produces a duplicate (or worse, the agent closes its own prior PR
+         mid-run and opens a new one with a different approach — exactly the
+         thrash observed in `letsoffload/permit-service` PR #81 → #82 and
+         `letsoffload/offload` PR #572 → #573, where two PRs for the same
+         identifier were opened-and-closed 12 to 16 seconds apart inside a
+         single workflow run).
+
+         Only proceed to Step 1 if no open PR exists for the identifier.
+
       1. Create a feature branch from the base branch (check context for
          baseBranch, default `main`). **Branch name MUST include the issue
          identifier** exactly as provided in `context.create_issue.issueIdentifier`.
@@ -459,7 +492,7 @@ nodes:
           description: Exact command run to validate (e.g. `npx nx test server`).
         test_status:
           type: string
-          enum: [pass, fail, no-framework, not-run]
+          enum: [pass, fail, no-framework, not-run, skipped]
           description: |
             Outcome of running the test suite.
             - `pass` — tests ran end-to-end and every assertion passed.
@@ -474,6 +507,26 @@ nodes:
               a broken fix. Return this status, retry will fire once.
             - `not-run` — tests exist but the environment couldn't
               execute them. Explain in `test_notes`. Retry will fire.
+            - `skipped` — the node short-circuited before running tests
+              because a precondition was not met. Today the only
+              accepted reason is `open-pr-exists` (Step 0b found an
+              open PR with the issue identifier in its title).
+              `skipped_reason` and `existing_pr_url` MUST be populated.
+              Downstream `create_pr` is bypassed and the workflow
+              routes to `notify`.
+        skipped_reason:
+          type: string
+          description: |
+            Why the node short-circuited. Only set when `test_status` is
+            `skipped`. Today the only valid value is `open-pr-exists`.
+          enum: [open-pr-exists]
+        existing_pr_url:
+          type: string
+          description: |
+            URL of the open PR that triggered the skip. Set when
+            `skipped_reason` is `open-pr-exists` so the notify node
+            can link to the prior PR.
+          pattern: "^https?://"
         test_notes:
           type: string
           description: One-paragraph explanation of which tests were added and what they assert.
@@ -484,14 +537,18 @@ nodes:
         - test_files_changed
         - test_status
     eval:
-      # `pass` and `no-framework` both clear the gate. `fail` and `not-run`
-      # trigger retry.
+      # `pass`, `no-framework`, and `skipped` clear the gate. `fail` and
+      # `not-run` trigger retry. `skipped` is the Step 0b short-circuit
+      # (open PR already exists for the issue identifier) — see the
+      # implement instruction for the driving incidents
+      # (letsoffload/permit-service #81 → #82,
+      # letsoffload/offload #572 → #573).
       - name: test_status_is_pass_or_no_framework
         kind: value
         rule:
           output_matches:
             - path: test_status
-              in: [pass, no-framework]
+              in: [pass, no-framework, skipped]
       # Conditional: when test_status is pass, test_files_changed MUST contain
       # at least one real test file path. Empty array with status pass is a
       # contract violation (the agent claimed it ran tests without actually
@@ -517,6 +574,11 @@ nodes:
             (README.md, package.json, source files), is a contract violation.
           - If test_status is "no-framework": test_files_changed MAY be empty.
             Pass vacuously.
+          - If test_status is "skipped": test_files_changed MAY be empty.
+            The node short-circuited before writing any code (Step 0b
+            found an open PR for the issue). `skipped_reason` and
+            `existing_pr_url` MUST be populated; if they are missing,
+            return no.
           - If test_status is "fail" or "not-run": this evaluator should not
             run (the prior value evaluator catches that). Pass vacuously.
 
@@ -599,7 +661,11 @@ edges:
     when: all novel findings have fix_complexity complex, OR no clear fix_approach
   - from: skip
     to: notify
+  - from: implement
+    to: notify
+    when: implement.test_status is "skipped" (Step 0b found an open PR already exists for the issue identifier)
   - from: implement
     to: create_pr
+    when: implement.test_status is "pass" or "no-framework" (no existing PR; fix was implemented or there is no test framework)
   - from: create_pr
     to: notify

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sweny-ai/core",
-  "version": "0.1.90",
+  "version": "0.1.92",
   "type": "module",
   "bin": {
     "sweny": "./dist/cli/main.js"