Using KwikQA
Configuration
Repairs need a reviewed kwikqa.config.json at the root of your project. It is plain JSON: loading it never runs any code. Create it with npx kwikqa init, then review and commit it.
Example
{
"schemaVersion": "1.0",
"editablePaths": [
{ "class": "spec", "pattern": "tests/**/*.spec.ts" },
{ "class": "page-object", "pattern": "tests/pages/**/*.ts" }
],
"generatedPaths": ["**/*.generated.ts", "**/__snapshots__/**"],
"budgets": { "maxFiles": 3, "maxChangedLines": 100 }
}
Fields
schemaVersion- Always
"1.0"for this version. editablePaths- The only files a repair may change. Each rule pairs a glob
patternwith aclassthat says what kind of test code it is. Anything that matches no rule, including all application code, is off limits. generatedPaths- Globs for generated files. A repair never edits them, even if an editable rule also matches.
budgets- The largest repair KwikQA may propose:
maxFilesfrom 1 to 3 andmaxChangedLinesfrom 1 to 100, counting added and removed lines. A cause that needs more becomes a manual recommendation.
Classes
| Class | For |
|---|---|
spec | Test files. |
page-object | Page objects and screen models. |
fixture | Playwright fixtures. |
test-data | Test data builders and factories. |
test-helper | Test-only helper modules. |
playwright-config | Playwright configuration. |
Page objects, fixtures, helpers, and configuration are shared by many tests, so a change has a larger blast radius. init only proposes spec rules on its own; add shared classes deliberately. In KwikQA 0.1, repairs to shared code are proposed but stop at validation-unavailable; see repair rules.
Local files
KwikQA writes run records, patch journals, and validation output to .kwikqa/ in your project. Keep it out of git; init offers to add it to .gitignore.