Skip to content
EN · PT

Gate: testid-queried-exists

Every handle an end-to-end flow queries is exposed somewhere in the code.

Property Value
Checker testid-queried-exists
Confronts test
Blocking by default — new project yes
Blocking by default — existing project no — informs
Presupposes derived.test_handle — until these are declared in anchors.yaml, the gate is pending and asks nothing

Confronts the end-to-end execution surface against the application code: does an automated flow query a test handle that no code file exposes?

This gate closes the fourth edge of the testID contract. The sibling gate testid-consistent starts from a single spec and confronts inventory coherence; however, the E2E surface encompasses the entire tree of flows across the whole project. Charging an individual screen’s spec for an external flow handle would accuse innocent specs of foreign handles (measured when attempted: 829 findings in a single spec, all belonging to other screens). Therefore, the question belongs to the PROJECT scope, confronting both sides collectively.

The measured defect in the reference application (2026-08-25) revealed 13 invented IDs in flows, frequently caused by incorrect screen prefixes (review-* where the component actually emits revi-*). The assumption that “an invalid ID will simply fail at runtime in the test runner” is FALSE for two independent reasons:

  1. Flow execution reachability: The runner must reach the step. In a test suite where step 3 fails, phantom IDs in subsequent steps remain completely hidden — surfacing one per run across seven iterations.
  2. Vacuum passing in negative assertions: In assertNotVisible, an invented or non-existent handle causes the test to PASS immediately. In REVI-R03, asserting :review-edit-controls (which never existed) proved the exact opposite of reality: green by VACUITY. This is the most dangerous defect, and the test runner can never catch it.

The gate enforces a STRICT SINGLE DIRECTION (flow → code). The reverse (code exposing a handle not queried by any flow) is not an issue: not every marked UI element requires an automated scenario, and testid-consistent governs spec-level declaration.

gates:
- name: testid-queried-exists
on: [test]
check: testid-queried-exists

Source: checker · its spec