Quickstart

This is the fastest path to a first successful debug session with theORQL. If you want the full walkthrough videos, see Getting started.

1) Install

• Install the theORQL extension in VS Code (or OpenVSX-compatible editors like Cursor/Windsurf).
• Open the theORQL sidebar and sign in.

2) Choose your model (optional)

You can use the built-in agentic AI, or bring your own key (BYOK). If you’re evaluating quickly, start with the default.

3) Start a debugging session

1. Start your app locally (for example npm run dev).
2. In theORQL, start the debugger and enter your local URL (for example http://localhost:3000).
3. Use the launched Chrome instance (that’s the one capturing evidence).

4) Reproduce the issue

Trigger the bug the same way your users do.

theORQL is strongest when the failure is hard to reason about from code alone, like:

• Runtime errors (including async promise failures)
• UI state bugs and edge-case regressions
• API/network failures, auth/session issues, unexpected responses

5) Fix + verify (the bounded loop)

When the failure fires, theORQL collects the evidence (stack, console, network, relevant DOM/runtime state), proposes a small patch, and then you verify by re-running the repro or a targeted test.

If the fix doesn’t stick, keep the surface area small and iterate:

• Confirm the owning file/module
• Apply the smallest possible diff
• Re-verify

Quick videos (recommended next)

• Sign in to your account (0:06)
• Run your app (0:05)
• Start theORQL (0:05)
• BYOK (0:06)
• Fix errors with one click (0:05)
• Element selector (0:08)

Common questions

Does theORQL run in production?

Not as a full production monitoring/observability platform. theORQL is designed for local development and dev-like environments (dev/staging).

What data does theORQL capture?

At the moment of a runtime failure (or a triggered debugging flow), it captures the same signals you’d usually hunt for in DevTools: stack traces, console logs, relevant network requests/responses, URL/DOM context, and selected runtime values.

Will it slow down my dev environment?

In normal flows, overhead is small. theORQL focuses on targeted capture when the debugger is running, instead of constantly recording everything.