How does NSPEC verify bugs?

An independent bug-verifier agent re-runs the repro in a fresh browser context, up to three times. Only bugs that reproduce, with a manual-grade confidence score, make it into the report.

Do you need access to my source code?

No. NSPEC tests the running UI. You give it a URL and optional login. It never reads your repo unless you opt in to git-diff based risk prioritization.

Which viewports are covered?

Six viewports at launch: desktop 1440, laptop 1280, tablet portrait and landscape, mobile portrait and landscape.

Yes, on Enterprise. Docker and Helm, with BYO LLM (OpenAI, Anthropic, or a local model). Artifacts never leave your network.

Features · NSPEC

Independent bug verification

A separate bug-verifier agent runs every finding through an isolated reproduction attempt, up to three times, with a manual-grade confidence score. Nothing ships unverified.

Agent network, 60+ QA tools

Today's specialist agents · orchestrator, ui-explorer, component-auditor, responsive-tester, performance-profiler, bug-verifier, test-case-designer, accessibility-reviewer · each run in their own browser context with no cross-contamination. Behind them sits a shared toolbox of 60+ QA primitives (click, fill, scroll, assert, probe, capture, diff, and growing). Standard runs finish in under four minutes.

Six-viewport coverage

Desktop 1440, laptop 1280, tablet portrait + landscape, mobile portrait + landscape. Every route audited at every size. Narrow the set per run if needed.

MCP tracker delivery

Verified bugs file as real tickets into Jira, Linear, or GitHub Issues over native MCP connectors. Title, repro, acceptance criteria, severity, owner, evidence bundle · all mapped to your tracker's fields. Notion support lands shortly after launch.

Full evidence bundle per bug

highlighted.png · screenshot with the offending element boxed
fullpage.png · full-page capture for context
dom.html · DOM snapshot at the moment of the issue
console.log · browser console for the test step
network.json · network trace including request/response metadata
verifier.json · reproduction outcome, attempts, confidence
bug.json · machine-readable summary
repro.md · numbered human repro

Server-side quality gates

Before a bug becomes a ticket it passes through these filters: empty-bug reject, third-party noise filter (GA, Sentry, fonts, ad-tech), duplicate merge across agents, contradiction detection, project-memory lookup for known false positives.

Project memory

NSPEC learns your app across runs. Flaky selectors stop getting re-reported. Known-stable patterns are trusted. Known false positives are suppressed until something actually changes. Every run gets sharper.

Risk-biased prioritization

Opt-in · NSPEC reads your git diff and weights attention toward the files and surfaces you just touched. Regressions get caught before PR review instead of after release.

HTML report artefact

Every run ships a self-contained HTML report (~1–2 MB) with embedded screenshots and full artefact links. Useful for audit, post-mortem, or sharing with a stakeholder who won't touch Jira. The report is an artefact, not the primary delivery channel · the tracker ticket is.

Tiered run modes

Quick · smoke-class, ~2 min.
Standard · comprehensive, ~4 min. Default.
Exhaustive · deep walk, ~15 min.

Single operator today, team-scale at launch

Pre-launch, we work with a tight early-access cohort to tune the verifier and MCP mappings for real apps. At launch, Team plans include workspaces, role-based access, and Slack notifications.

Related: How it works · Pricing · FAQ

Features.