Skip to content

Zero Config

Auto-detection

The CLI can infer most of what it needs so you can start with the deterministic impact → plan → gate loop before writing a config file.

Best fit

Zero-config shines in established test repos

The most battle-tested path is still a Playwright or Cypress repo with a recognizable tests root and a normal git remote.

Typical first run

Let the CLI discover the shape of the repo

npx impact-gate impact --path . --since origin/main npx impact-gate plan --path . --since origin/main
Reality check

Zero-config is great for first-pass orientation. The highest-confidence release decisions still come from a maintained route-families manifest in an app-shaped Playwright or Cypress repo.

What Gets Auto-Detected

Test Framework

The CLI reads your project files and package.json dependencies to detect:

  • Playwright if @playwright/test or playwright is present
  • Cypress if cypress is present
  • pytest if conftest.py, pytest.ini, or pytest config in pyproject.toml / setup.cfg is present
  • supertest if supertest is in your npm dependencies (runs via Vitest or Jest)
  • Selenium if selenium-webdriver or webdriverio is present

Tests Root

Tests root

Directory discovery follows common conventions

The first matching directory below becomes --tests-root.

e2e-tests/playwright, e2e-tests, e2e, tests/e2e test/e2e, tests, test, specs, playwright, cypress
Git base branch

Diff base is discovered from the remote

The CLI queries git remote show origin for the default HEAD branch and falls back to the current branch when needed.

Project Root

Walks up from the current directory until it finds package.json or .git.

When You Need a Config File

Use config when the repo needs stronger intent

Reach for config once heuristics are no longer enough

  • Set a profile such as strict for tighter gating
  • Configure dependency graph depth or traceability behavior
  • Enable the pipeline for test generation
  • Define policy enforcement such as advisory, warn, or block
  • Point to a separate server path for backend analysis
  • Override framework or tests-root detection when the repo is unusual

Create impact-gate.config.json in your project root when you need to:

If auto-detection gets it wrong, prefer explicit flags or a config file over guessing.

The CLI searches for impact-gate.config.json or .impact-gate.config.json starting from the current directory and walking upward.

Bootstrap: Alternative Setup with a Knowledge Graph

Knowledge graph

Bootstrap route families from existing project knowledge

If you already have an Understand-Anything knowledge graph, bootstrap can generate the manifest automatically instead of training from scratch.

Bootstrap

Generate the manifest directly

npx impact-gate bootstrap --path . npx impact-gate bootstrap --dry-run --max-families 30

If your project already has an Understand-Anything knowledge graph, the bootstrap command can generate your route-families manifest automatically instead of running train:

Terminal window
npx impact-gate bootstrap --path .

Bootstrap reads the knowledge graph, classifies your project (frontend, backend, or fullstack), and produces .e2e-ai-agents/route-families.json with prioritized families derived from the graph’s nodes and edges. It also auto-detects your test framework and test mode (ui, api, or both).

Use --dry-run to preview the manifest before writing, or --max-families 30 to limit the output. See the CLI reference for all flags.

Explicit Flags Always Win

Precedence

CLI flags override both config and heuristics

When the repo needs a one-off override, use flags directly. They win over auto-detected values and the config file.

Any CLI flag overrides both auto-detected values and config file settings:

Terminal window
npx impact-gate impact \
--path ./webapp \
--tests-root ./e2e-tests/playwright \
--framework playwright \
--since origin/release-9.0