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 |
How it measures
Section titled “How it measures”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:
- 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.
- Vacuum passing in negative assertions: In
assertNotVisible, an invented or non-existent handle causes the test to PASS immediately. InREVI-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.
Declaring it
Section titled “Declaring it”gates: - name: testid-queried-exists on: [test] check: testid-queried-exists