Quell reads your docstrings, Pydantic models, and type annotations, extracts every testable requirement, finds which ones have no test, generates pytest tests via a rule engine, verifies each test through a 5-gate pipeline, and writes only proven tests to disk.

Does Quell require an LLM API key?

The rule engine runs entirely in-process — no source code is ever transmitted. ~75% of edge cases are handled with no network call and no API key. LLM fallback is opt-in and only sends the function signature, never the full body.

What is the 5-gate pipeline?

Every generated test must pass: Gate 1 (AST valid Python), Gate 2 (not already in a test file), Gate 3 (no shell calls or file writes), Gate 4 (passes against original code), Gate 5 (fails when the requirement is violated). Only gate-5-verified tests are written to disk.

What is the Production Readiness Score (PRS)?

PRS = (WRITTEN × 1.0 + SCAFFOLDED × 0.5) / total_requirements × 100. Tiers: 80-100 Production Ready, 60-79 Review Needed, 0-59 Needs Work.

How is Quell different from GitHub Copilot or Qodo for test generation?

Quell reads specifications that already exist in your code — it does not generate tests from scratch. It finds requirements already documented in your docstrings, Pydantic models, and type annotations that have no test. The 5-gate pipeline, especially Gate 5 (violation injection), verifies each test actually catches the bug it claims to catch. This verification step is not present in Copilot, Qodo, or Hypothesis.

Can Quell be used in CI pipelines?

Yes. Run quell ci src/ --threshold 80 to fail CI if PRS falls below 80. Set prs_threshold in pyproject.toml under [tool.quell]. Works with GitHub Actions, GitLab CI, and any system that checks exit codes.

Three-Bucket Output

Every edge case Quell finds lands in exactly one bucket. Nothing is silently dropped.

✓ WRITTEN

All 5 gates passed. Test written to disk.

The test was generated by the rule engine (or LLM fallback)
It passed the AST, originality, and security gates (1–3)
It passed on correct code (gate 4)
It failed when the requirement was violated (gate 5)
Written to your test file using libcst — AST-safe injection, never string concatenation
Source file was restored immediately after gate 5 verification

✓  WRITTEN  test_payment_rejects_zero_amount  [5/5 gates]

~ SCAFFOLDED

Gates 1–3 passed. Stub written with a clear TODO.

Gates 4 or 5 couldn't be verified — usually because:

The function has external state (database, file system)
The requirement involves non-deterministic behavior
The test couldn't be run in isolation

Quell writes a stub that is valid Python and runs immediately (and fails). You fill in the logic.

def test_refund_idempotency():
    # TODO: verify idempotent refund behavior
    # Quell: external state makes gate 5 unprovable
    pass  # complete me

~  SCAFFOLDED  test_refund_idempotency  [1-3 gates — external state]

✗ FLAGGED

Cannot auto-test. Documented with exact reason.

The requirement exists and is valid, but no automatable test path exists. Quell documents:

The requirement name
The exact reason it can't be tested (side effect, external service, non-determinism)
The file and line number

✗  FLAGGED  test_external_payment_gateway
   Reason: calls stripe.Charge.create()
   Side effect detected — cannot inject violation

This is a feature, not a failure. You now know exactly what gaps exist and why.

Why this matters

Coverage tools report lines executed. They don't tell you whether your tests catch bugs.

A test that calls a function and checks assert result is not None might hit 100% line coverage while catching zero bugs.

Quell's three-bucket output tells you which requirements are genuinely proven, which need your help, and which are documented gaps — so you can make an informed decision about each one.