Skip to content

EdgeSpecUntested code, tested.

Scan a GitHub repository, generate a test with the model you choose, validate it honestly, and open a pull request.

Start here ​

DocumentWhat it answers
ArchitectureHow the pieces fit, what happens during a run, where the security boundaries are
APIEvery route, header, payload and SSE event
CLIScan, generate, run and open PRs from a terminal
MCP serverExpose EdgeSpec tools to Claude Desktop, Cursor and other agents
ConfigurationBrowser settings, providers, pipeline knobs, sandbox runner, deployment secrets
DeploymentD1, R2, secrets, Worker deployment, CI
UIWorkspace steps, pipeline states, settings, theme and layout rules

The repository also carries README.md for setup, PLAN.md for requirements and AGENTS.md for conventions.

The mental model ​

  1. The deployment stores no user configuration. Settings live in the browser. Keys are sent as headers on each request and forwarded to the chosen provider. Run history, the backlog, policies and audit are optional shared D1 state; they never hold source text, prompts or keys.
  2. One pipeline, two transports. runPipeline() streams the interactive run over SSE (POST /api/run). GitHub webhooks use the durable TestGenerationWorkflow with deployment-owned credentials.
  3. Validation is honest. Without a sandbox runner, a test is reported as static check only — never as passing. Gap risk is a path heuristic, not a coverage percentage.
  4. The repository is always supplied by the caller. There is no default repository on the server.

Quick start ​

bash
bun install
bun run dev:worker     # API + built assets on http://127.0.0.1:8787
bun run dev            # Vite dashboard on http://127.0.0.1:5173
bun run dev:all        # both

Open the dashboard, enter owner/name in 01 Repository (or a folder path), pick a provider in Settings, then scan and start a run. For a private repository or to open a pull request, add a GitHub token in Settings. On localhost you can also enter a local folder path such as ./examples/missing-openapi; the dev server scans it read-only, so you can generate and validate tests without a GitHub repository. A folder path is only available through the Vite dev server.

CLI and MCP clients use the same Worker API:

bash
bun --silent run cli -- scan owner/repo --limit 20
bun --silent run cli -- --help
bun run mcp -- --help

Checks:

bash
bun run verify          # format, lint, types, tests
bun run build          # dist/web + dist/worker
bun run deploy -- --dry-run

Repository map ​

text
packages/core/src/   pure pipeline logic (scanner, AI, GitHub, validation)
packages/client/src/ Worker API client shared by the CLI and MCP server
packages/ui/src/     shared React primitives and theme tokens
packages/cli/src/    terminal client
packages/mcp/src/    stdio MCP server
packages/sandbox/src/ self-hosted sandbox runner
apps/worker/src/     Hono routes, bindings, durable Workflow
apps/web/src/        React dashboard
apps/docs/           this documentation site
evals/               golden-scan harness and optional provider scoring

Tests live in each workspace's test/ directory. Deployment steps are in Deployment.

Limits at a glance ​

LimitValue
Repository inputowner/name, GitHub URL, folder path, or localhost filesystem path
Scan results in the dashboard25 gaps, first 8 enriched with exported symbols
Pipeline targetfirst gap only, per run
Self-correction retries0–5, default 2
Coverage target0–100, default 90 (advisory to the model)
Provider / sandbox timeout120 seconds per call
Generated test sizeup to 4096 output tokens
Pull request list20 most recent, all states

Generated tests are a draft, not a proof.