AI Configuration

Choose which AI model powers Resolue's diagnosis and fix generation. Bring your own API key, or use a self-hosted model for full data sovereignty.

Supported Models

Configuration

Set the AI provider in your resolue.yaml:

# resolue.yaml — this file is committed to your repo!
ai:
  provider: anthropic       # anthropic | openai | bedrock | azure | custom
  model: claude-sonnet-4    # Model identifier
  api_key_env: RESOLUE_AI_KEY # ← name of the env var, NOT the key itself

Bring Your Own Key (BYOK)

For SaaS users, you can use Resolue's default model allocation or bring your own API key for any supported provider:

# Vercel
vercel env add RESOLUE_AI_KEY preview production
# Cloudflare Pages
wrangler pages secret put RESOLUE_AI_KEY
# Or add directly in your platform's dashboard

ai:
  api_key_env: RESOLUE_AI_KEY

Self-Hosted LLM

For organizations that cannot send code to external APIs, Resolue supports connecting to a self-hosted model via an OpenAI-compatible endpoint:

# resolue.yaml
ai:
  provider: custom
  endpoint: https://llm.internal.company.com/v1
  model: llama-3.1-70b
  api_key_env: INTERNAL_LLM_KEY
  timeout: 120  # seconds — larger models may need more time

Model Selection Strategy

Resolue can use different models for different stages of the pipeline:

ai:
  diagnosis:
    model: claude-opus-4      # Deep reasoning for root cause
  fix_generation:
    model: claude-sonnet-4    # Fast, accurate patches
  confidence_scoring:
    model: claude-sonnet-4    # Evaluate fix quality

Preview Auth

Set up @resolue/auth to let Resolue test authenticated routes on preview deployments — securely, without real user credentials.

Why this is needed

When Resolue deploys a fix to a preview URL and runs Playwright tests, it needs to reach the authenticated pages where the bug lives — checkout flows, dashboards, admin panels. Without auth bypass, Playwright hits the login screen and can't verify the fix.

Installation

npm install @resolue/auth

Setup

# Vercel
vercel env add RESOLUE_SECRET preview
# Cloudflare Pages
wrangler pages secret put RESOLUE_SECRET
# Netlify
netlify env:set RESOLUE_SECRET --context deploy-preview
# Paste the secret from your Resolue dashboard

// middleware.ts
import { resolueAuth } from '@resolue/auth/next';

// Standalone:
export default resolueAuth();

// Or wrap your existing auth (Clerk, NextAuth, etc):
import { authMiddleware } from '@clerk/nextjs';
export default resolueAuth(authMiddleware());

import { resolueAuth } from '@resolue/auth/express';

// Add BEFORE your auth middleware
app.use(resolueAuth());
app.use(passport.authenticate('session'));

import { checkResolue } from '@resolue/auth/node';

const resolue = checkResolue(req);
if (resolue.isVerification) {
  req.user = resolue.testUser;
}

resolueAuth({
  testUser: {
    id: 'resolue-verify',
    email: 'verify@yourcompany.com',
    role: 'user',          // Use minimum required role
    orgId: 'test-org-123',
  }
});

Security Layers

Five independent safety layers protect against unauthorized access:

Secret Rotation

If you need to rotate the shared secret:

1. Generate a new secret in the Resolue dashboard
2. Update the RESOLUE_SECRET env var on your preview deployment
3. All old tokens fail validation immediately — no downtime, no redeployment

Error Replay

How Resolue reproduces the exact failure conditions from production — even when the preview environment's APIs work fine.

The Problem

A user hits a checkout error because Stripe returns a 500. Resolue generates a fix and deploys it to a preview. But on the preview, Stripe works fine — so the Playwright test passes without actually proving the fix handles the failure. The video shows a happy path, not a verified fix.

This happens with: external API failures (Stripe, geocoding, payment), database state issues (out of stock, duplicate records), race conditions, third-party timeouts, and edge cases triggered by specific user data.

How It Works

Setup: Browser-Level Mocking

This works automatically — no app-side code needed. Resolue sets up request interceptors before navigating to your preview.

Setup: Server-Level Mocking

For errors in API routes, server components, or SSR — where the failing fetch() runs on the server — you need to enable the fetch interceptor:

// instrumentation.ts (Next.js) or app initialization
import { patchFetch } from '@resolue/auth/replay';

// Only patch on preview environments
if (process.env.RESOLUE_SECRET) {
  patchFetch();
}

What Gets Mocked

Resolue builds fixtures automatically from the error context:

Fixtures Format

// What Resolue sends in X-Resolue-Fixtures
{
  "apiMocks": [
    {
      "pattern": "https://api.stripe.com/v1/charges**",
      "method": "POST",
      "response": {
        "status": 500,
        "body": { "error": { "type": "api_error", "message": "Internal server error" } },
        "delay_ms": 0
      }
    }
  ],
  "replayRequest": {
    "method": "POST",
    "path": "/api/checkout",
    "body": { "cartId": "cart_abc", "userId": "usr_123" }
  },
  "userStateSeed": {
    "cartItems": 3,
    "accountAge": "returning"
  }
}

resolue.yaml Configuration

# resolue.yaml
verify:
  replay:
    enabled: true
    mock_external_apis: true      # Mock failing external APIs
    replay_request_body: true    # Use the original failing request
    seed_user_state: true        # Inject user state from error context
    mock_timeout_ms: 30000       # Max delay for timeout mocks

Security

The context and fixtures headers use the same security model as the auth token:

• HMAC-SHA256 signed with the same shared secret — cannot be forged
• Only parsed on preview environments — production ignores them
• Fixtures never contain real credentials — only request shapes and mock responses
• Mocks are scoped to the verification request — cleared immediately after

Supported Errors

Resolue is best at single-file bugs in TypeScript and JavaScript applications. Here's what it can fix today and what's coming next.

What Resolue Fixes Today

These error types have the highest fix rate and confidence scores:

What makes these fixable?

• Single file — the root cause and the fix are in one file
• Clear stack trace — Sentry points to the exact line
• Pattern-based — these are well-known error patterns with well-known fixes
• Small diff — typically 1–10 lines changed

Coming Soon

These error types are on the roadmap. Resolue can currently diagnose them but may not generate a verified fix:

Language & Framework Support

When Resolue Can't Fix It

Not every production error gets a fix PR. Here's what happens at each confidence level — and why even "failures" deliver value.

Confidence Tiers

Resolue assigns a confidence score to every incident based on: stack trace clarity, code complexity, number of files involved, and test pass rate on the preview.

High Confidence (80–99%): Verified Fix PR

The ideal path. Resolue understands the root cause, generates a minimal patch, deploys it to a preview, runs tests, and records video. A full evidence PR is opened on your repo.

What you get: code diff, root cause analysis, video proof, before/after screenshots, confidence breakdown, and BDD regression tests.

Medium Confidence (50–79%): Draft PR with Caveats

Resolue identified the root cause and generated a fix, but something prevented full verification — tests partially failed, the fix touches multiple files, or the preview didn't fully reproduce the error.

What you get: a draft PR (not ready to merge) with the patch, a clear list of what was verified vs. what wasn't, and flags for areas that need human review. Think of it as "here's 80% of the work done."

Low Confidence (<50%): Diagnostic Report

The bug is too complex for an automated fix — multi-service, infrastructure-related, or lacking code context. Resolue does NOT open a PR. Instead, it delivers a diagnostic report.

What you get:

• Root cause analysis with the AI's best theory
• Affected files and functions identified
• Related recent commits that may have introduced the bug
• User impact data (how many users, frequency, severity)
• Suggested approach for your team to fix it manually

Configuration

You control the thresholds in resolue.yaml:

# resolue.yaml
confidence:
  min_to_open_pr: 70      # Below this → diagnostic report only
  min_to_auto_merge: 101   # 101 = never auto-merge (default)
  draft_pr_threshold: 50   # 50–69 → draft PR, 70+ → ready PR

Why This Matters

Most AI coding tools only show you the success case. They demo a clean fix on a simple bug and imply everything works that way. We think that's dishonest.

Production bugs are messy. Context is missing. State is inconsistent. Services fail in weird ways. Resolue is designed to handle that reality — which means being transparent about when it can help and when it can't.

The confidence scoring, draft PRs, and diagnostic reports aren't failure modes — they're the product working as intended. A tool that says "I don't know" when it doesn't know is more valuable than one that silently pushes a wrong fix.

Test Generation

Every Resolue fix PR includes AI-generated BDD tests — so the bug is fixed AND permanently covered by a regression test that didn't exist before.

What Gets Generated

When Resolue opens a fix PR, it commits four test files alongside the code patch:

All files are committed to tests/resolue/ on the fix branch. When you merge the PR, the tests become part of your codebase permanently.

Example: Checkout Null Check

For a TypeError: Cannot read property 'id' of null in checkout.tsx:

Generated Feature File

# Auto-generated by Resolue — incident inc_4821

Feature: Checkout handles type error correctly
  Regression test for incident inc_4821.
  Error originated in checkout.tsx:18.
  Triggered by POST /api/checkout.

  Scenario: TypeError in checkout.tsx is handled
    Given a user is on the application
    And the id may not be present
    When they submit a request to /api/checkout
    Then no TypeError should be thrown
    And the page should respond without a 500 error
    And the user should be redirected or see a graceful fallback

  Scenario: Application handles Stripe API failure gracefully
    Given a user is performing the action
    And the Stripe API returns a 500 error
    When they submit /api/checkout
    Then the user should see a meaningful error message
    And the application should not crash with a 500
    And the error should be recoverable

  Scenario: Normal flow still works after the fix
    Given a user is authenticated
    And all external services are responding normally
    When they use /api/checkout
    Then the page should load successfully
    And no errors should appear in the console

Generated Playwright Spec

// Auto-generated by Resolue — incident inc_4821
import { test, expect } from '@playwright/test';
import { fixtures } from './resolue-checkout-inc4821.fixtures';

test.describe('Checkout handles TypeError correctly', () => {

  // Scenario: TypeError in checkout.tsx is handled
  // Given: a user is on the application, the id may not be present
  // When: they submit a request to /api/checkout
  // Then: no TypeError, no 500, graceful fallback
  test('TypeError in checkout.tsx is handled', async ({ page }) => {
    await page.goto('/checkout');

    await expect(page).not.toHaveTitle(/error|500/i);
    const errors: string[] = [];
    page.on('pageerror', e => errors.push(e.message));
    expect(errors.filter(
      e => e.includes("Cannot read property 'id'")
    )).toHaveLength(0);
  });

  // Scenario: Stripe failure handled gracefully
  test('handles Stripe http error gracefully', async ({ page }) => {
    // Mock Stripe to return 500
    await page.route('https://api.stripe.com/v1/charges**', async route => {
      await route.fulfill({
        status: 500,
        contentType: 'application/json',
        body: JSON.stringify(fixtures.mocks['stripe']),
      });
    });

    await page.goto('/checkout');
    await expect(page.locator('body'))
      .not.toContainText('Internal Server Error');
  });

  // Scenario: Happy path regression
  test('normal flow still works after the fix', async ({ page }) => {
    await page.goto('/checkout');
    await expect(page).not.toHaveTitle(/error|500/i);
    await expect(page.locator('body'))
      .not.toContainText('Something went wrong');
  });
});

Generated Fixtures

// Auto-generated by Resolue — incident inc_4821
export const fixtures = {
  "incidentId": "inc_4821",
  "error": {
    "type": "TypeError",
    "message": "Cannot read property 'id' of null",
    "file": "checkout.tsx",
    "line": 18
  },
  "failingRequest": {
    "method": "POST",
    "path": "/api/checkout",
    "body": { "cartId": "cart_abc" },
    "headers": { "authorization": "[REDACTED]" }
  },
  "mocks": {
    "stripe": { "error": { "type": "api_error" } }
  }
} as const;

Three Scenarios Per Bug

Resolue always generates at least three BDD scenarios for every fix:

Configuration

# resolue.yaml
testgen:
  enabled: true
  output_dir: tests/resolue        # Where to put generated tests
  runner: playwright              # playwright | vitest | jest
  generate_feature: true         # Include .feature Gherkin files
  generate_api_test: true        # Include API-level tests
  generate_fixtures: true        # Include fixture data files
  sanitize_headers: true         # Redact auth headers in fixtures

How AI Writes the Tests

The test generator uses three inputs:

1. Error context — what broke, what the user was doing, which APIs failed, the breadcrumb trail from Sentry/OTel
2. Code diff — what the fix changed. The AI reads the diff to understand what edge case was unhandled and writes tests that target that specific code path
3. Fixtures — the API mocks needed to reproduce the failure. These become the test's mock data

The AI doesn't write generic "page loads" tests. It writes targeted tests that exercise the exact failure mode — with the exact request payload, the exact API error, and the exact edge case data that triggered the bug in production.

Security

Generated test fixtures are automatically sanitized:

• Auth headers are replaced with [REDACTED]
• Real user data is never included — only the data shape (e.g., "3 cart items" not the actual cart contents)
• API keys in request bodies are stripped
• Fixture files are committed to your repo — review them in the PR diff before merging

CLI — resolue dev

Run Resolue locally during development. Auto-generate e2e tests for your code changes before you push — so you never write a Playwright test by hand again.

Install

npm install -D @resolue/auth
# or globally:
npm install -g @resolue/auth

Quick Start

resolue init

resolue test:gen

resolue test:run
# or directly:
npx playwright test tests/resolue/

Commands

Options

Watch Mode

Run resolue dev and it watches your source files. When you save a change, it tells you what changed and waits for your command:

$ resolue dev
─────────────────────────────────────────
  ❯❯ Resolue — Production Incident Autopilot
─────────────────────────────────────────

Watching: src, app
Save a file to see test suggestions.

Commands:
  Press 'g' + Enter → generate tests for current diff
  Press 'r' + Enter → run generated tests
  Press 'q' + Enter → quit

Changed: api/checkout/route.ts
  → Run 'g' + Enter to generate tests for these changes

> g
Generating tests...

Generated 4 files (3 scenarios)
  ✓ tests/resolue/api-checkout-route.feature
  ✓ tests/resolue/api-checkout-route.spec.ts
  ✓ tests/resolue/api-checkout-route.api.spec.ts
  ✓ tests/resolue/api-checkout-route.fixtures.ts

What Gets Generated

Resolue analyzes each changed file and generates different test types based on what it is:

CI Integration

Add Resolue test generation to your GitHub Actions workflow so every PR gets auto-generated tests:

# .github/workflows/resolue-tests.yml
name: Resolue Tests
on: [pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # Full history for diff

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - run: npm ci

      - name: Generate & run Resolue tests
        run: npx resolue test:ci
        env:
          RESOLUE_AI_KEY: ${{ secrets.RESOLUE_AI_KEY }}

How It Differs from Production Fix Tests

resolue.yaml

Configuration file reference. Place resolue.yaml in your repository root to control how Resolue operates on your project.

Full Example

# resolue.yaml — committed to your repo (no secrets here!)
version: 1

# AI model — api_key_env is the NAME of the env var, not the key
ai:
  provider: anthropic
  model: claude-sonnet-4
  api_key_env: RESOLUE_AI_KEY  # ← reads from $RESOLUE_AI_KEY at runtime

# Repository settings
repo:
  base_branch: main
  ignore_paths:
    - node_modules/**
    - dist/**
    - .next/**
    - *.test.ts
    - *.spec.ts

# Branch strategy for production auto-fixes
branches:
  prefix: fix/resolue-        # Branch name: fix/resolue-{incident_id}
  target: main                # PR targets this branch
  auto_delete: true           # Delete branch after merge

# Confidence thresholds
confidence:
  min_to_open_pr: 70         # Below this → diagnostic report only
  draft_pr_threshold: 50     # 50–69 → draft PR, 70+ → ready PR
  min_to_auto_merge: 101     # 101 = never auto-merge (safest default)
  require_video: true

# Verification
verify:
  playwright: true
  smoke_checks: true         # Auto-generate if no Playwright config
  timeout: 180

# Test generation
testgen:
  enabled: true
  output_dir: tests/resolue
  runner: playwright
  generate_feature: true    # BDD .feature files
  generate_api_test: true
  generate_fixtures: true

# Notifications
notify:
  slack_channel: #incidents
  on_pr_opened: true
  on_fix_failed: true

Field Reference

ai

repo

branches

Controls how Resolue creates branches for production auto-fix PRs. Does not apply to CLI test generation (which works on your current branch).

confidence

Integrations

Per-integration setup guides for each tool in the Resolue pipeline.

Vercel

What Resolue uses: Log Drain for runtime error streaming, preview deployments for fix verification.

Sentry

What Resolue uses: Exception webhooks, stack traces, breadcrumbs, user impact data.

GitHub

What Resolue uses: Code read access for diagnosis, PR write access for fix delivery.

Playwright

What Resolue uses: Test suite execution against preview, video recording.

OpenTelemetry

What Resolue uses: Distributed traces, metrics, and logs from any OTel-compatible source.

# In your OTel Collector config, add Resolue as an exporter:
exporters:
  otlphttp:
    endpoint: https://ingest.resolue.ai/v1
    headers:
      Authorization: Bearer ${RESOLUE_INGEST_KEY}

service:
  pipelines:
    traces:
      exporters: [otlphttp, your-existing-exporter]

Works with HyperDX, Grafana, Jaeger, SigNoz, Honeycomb, and any OTLP exporter.

Security

How Resolue protects your code, credentials, and production environment.

Threat Model

Attacker sends forged X-Resolue-Verify header

Blocked by: HMAC-SHA256 signature validation. Without the shared secret (256-bit keyspace), the attacker cannot produce a valid signature.

Attacker intercepts a valid token and replays it

Mitigated by: 5-minute token expiry. Each token also contains a unique run ID that can be monitored for duplicates.

Attacker gains access to RESOLUE_SECRET

Impact: The attacker could forge tokens to access preview deployments (never production) as the test user (never admin, unless misconfigured). Mitigation: Rotate the secret immediately in the Resolue dashboard.

Middleware accidentally deployed to production

Blocked by: Hardcoded environment check. The middleware is a complete no-op when NODE_ENV=production or VERCEL_ENV=production. This cannot be overridden by configuration.

Token Format

base64({ ts, rid, iid, v }).hmac_sha256_hex(secret)

What Resolue Never Accesses

• Your real user passwords or credentials
• Your session tokens or JWTs
• Your OAuth tokens
• Your database credentials or connection strings
• Your .env files (only RESOLUE_SECRET is shared)

Audit Logging

resolueAuth({
  onVerify: (info) => {
    logger.info('Resolue verification', {
      runId: info.runId,
      incidentId: info.incidentId,
      timestamp: info.timestamp,
    });
  }
});

Self-Hosted

Deploy Resolue on your own infrastructure for full data sovereignty. Your code never leaves your network.

Overview

Self-hosted Resolue runs inside your infrastructure — VPC, Kubernetes, or on-premise. It connects to your internal GitHub Enterprise, error tracking, and deploy pipeline. Same functionality as the cloud version, fully air-gapped.

What's included

• Full Resolue engine — diagnosis, fix generation, verification, PR creation
• Browser verification — runs in isolated containers within your network
• Pluggable AI backend — use any OpenAI-compatible endpoint (vLLM, Ollama, AWS Bedrock, Azure OpenAI, or your own model server)
• Dashboard — same dashboard, hosted on your domain

Deployment options

API Reference

Webhooks, REST endpoints, and event types for integrating Resolue into your workflow programmatically.

Webhook Events

Configure a webhook URL in the Resolue dashboard to receive events:

Webhook Payload Example

{
  "event": "pr.opened",
  "timestamp": "2026-03-29T14:22:00Z",
  "incident_id": "inc_4821",
  "data": {
    "pr_url": "https://github.com/acme/web-app/pull/248",
    "pr_number": 248,
    "confidence": 94,
    "video_url": "https://resolue.ai/v/run_abc123",
    "files_changed": ["src/checkout.tsx"],
    "lines_changed": 3,
    "tests_passed": 47,
    "tests_total": 47,
    "regressions": 0
  }
}

REST API

List incidents

GET /api/v1/incidents
Authorization: Bearer {api_key}

Get incident detail

GET /api/v1/incidents/{incident_id}

Retry a failed fix

POST /api/v1/incidents/{incident_id}/retry

Trigger manual scan

POST /api/v1/scan
{
  "repo": "acme/web-app",
  "error_url": "https://sentry.io/issues/4821"
}

Authentication

All API requests require a Bearer token. Generate one in the Resolue dashboard under Settings → API Keys.

curl -H "Authorization: Bearer rsl_live_abc123..." \
  https://api.resolue.ai/v1/incidents