Skip to content
AnchorsAnchors
EN · PT

Gate: identity-consistent

The spec’s code is the only identity across its surfaces: testID prefixes and visual baselines.

Property Value
Checker identity-consistent
Confronts spec
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 a unit’s declared identity against the external surfaces where it reappears: does the spec code agree with the testID prefix exposed in code and the visual regression baseline filename?

The spec code is the canonical identity of the unit. Other identity gates verify mere PRESENCE (whether a spec declares a code, or whether a scenario carries a code), never CONCORDANCE across surfaces. Under presence-only checking, a single unit could declare a spec code of BGET, expose testID=":bdge-screen", and store its visual regression baseline as BDEDX-VR-*.png — three conflicting identities for the exact same unit — while every pipeline gate remains green because each gate inspects its own surface in isolation.

The REAL COST of this discordance is not aesthetic. The project code dictionary consumed by spellcheck is AUTOMATICALLY GENERATED from the map. When an acronym exists only inside a testID, it is missing from the generated dictionary. Spellcheck immediately flags the acronym as a typo, and the natural developer workaround — adding the rogue acronym to the manual spelling dictionary — CRISTALLIZES the divergence. The symptom becomes permanent vocabulary while the underlying defect disappears from sight. This exact failure mode occurred in the reference application when bdgc and bdge entered the manual dictionary, motivating the creation of this gate.

The gate exercises crucial DISCERNMENT regarding what does NOT constitute divergence: a component may legitimately use the identity code of ANOTHER unit as its testID prefix when the testID designates WHERE the element appears. For instance, SpendingMonthCard (SMCD) exposes :home-spending-card because it lives inside HomeScreen (HOME), which is how end-to-end flows locate the element starting from the screen. Demanding strict local identity unification there would break end-to-end navigation flows.

The rule distinguishing the two cases is precise:

  1. A prefix that matches the code of ANY unit declared in the map represents a KNOWN IDENTITY (deliberate reuse).
  2. A prefix shaped like an identity code (4-5 letters) that belongs to NO unit in the map is an ORPHAN IDENTITY. Because it does not exist in the map, it cannot exist in the generated dictionary, making it the exact case that forces rogue acronyms into manual spelling dictionaries. Only orphan identities are rejected.

For visual regression baselines (<Unit>.<CODE>-VR-<variant>.png), cross-unit delegation is not permitted: a baseline is the physical proof of THIS specific unit, not a pointer to where it appears.

Declaring it

Section titled “Declaring it”
gates:
  - name: identity-consistent
    on: [spec]
    check: identity-consistent

Source: checker · its spec