Autonomous E2E QA

Tests every deploy. Trusts none of them.

When a commit lands on your DEV environment, qayaba reads the change, writes the Playwright tests for what could break, and runs them against the live site — before you've opened the PR.

triggers on merge to main PRs into your own git open source
01 · analysis Blast radius

It doesn't test everything. It tests what your change can break.

qayaba maps your code — across every repo, frontend to microservices — into a dependency graph. When a commit lands, it grows the blast radius through real relationships: a class you changed, injected three services away, still lights up. Then it writes a focused test plan — before running a single test.

Default: diff (blast radius of one change). Also: manual (test what you ask) · complete (audit the whole suite).

FIG. 01 · dependency graph
02 · the full flow Proof, not green

A test that runs green isn't proof. qayaba proves it.

It writes the spec, a different model reviews it for real assertions, and change-coverage confirms the test actually executes the lines you changed. Then it runs against your live DEV and tells you — in plain language — what broke. Green and approved → a PR into your repo. Broken → a GitHub Issue. Your tests, your git, no lock-in.

Ending:
FIG. 02 · generate → verify → record
03 · engine choice opencode · codex · dual

Pick your engine. Or run both.

Choose opencode or codex as your SDK and configure the model behind it. Flip on DUAL to run both inside one synchronized process, and swap engines hot, mid-run, with state carried over.

Hot-swappable: change SDK or model mid-run; state is preserved. DUAL runs both, synchronized, in one process.

FIG. 03 · engine runtime
04 · memory + chat Ask it anything

Your test suite, now something you can talk to.

qayaba remembers every run — fragile flows, flaky selectors, what fixed them last time — and answers from memory. Trigger runs, explain failures, onboard a repo: in plain language.

Live · switch channels or tap an action.

FIG. 04 · any channel
05 · recursive It tests itself

The first thing qayaba tests is qayaba.

Its agents report their own failures to a maintainer agent that fixes them and commits the change — with live log and status monitoring. The code that uses itself to get better, every day. (Like building git in git.)

FIG. 05 · self-fix loop
06 · learning The learning layer

Every failure becomes a rule it won't break twice.

qayaba doesn't just pass or fail a run, it learns from it. A labeler classifies the error, an oracle scores test quality with mutation testing, and a reflector traces the root cause to real artifacts. A distiller turns that into a reusable rule, injected into every future run. Attribution promotes the rules that lead to good outcomes; a curriculum keeps only the probes that have caught real bugs.

Deterministic where it counts: the labeler and oracle use zero LLM. Only the reflection step asks a model.

FIG. 06 · the learning loop
Live engine

Don't take our word for it. Run it.

Point it at a repo, pick how deep to look, and watch the whole pipeline work — live.

3
Demo mode is capped — a few commits, a handful of tests — so you get the feel in seconds, not an 80-test marathon.
configure a run and press play
Where it's different

Built for the part no one else proves.

Honest about what's table stakes — and where qayaba stands alone.

qayaba QA Wolf Octomind Meticulous Ranger