Element Registry
The Element Registry is the knowledge AutoRunner builds about your application. Every screen an AI generation run observes, and every element it interacts with, is recorded here with a stable identity and a history of the locators that worked.
Scenarios reference registry elements rather than raw selectors. When the application changes, the registry is what lets AutoRunner repair a scenario instead of failing it.
Open the registry from AI Studio — the Element Repository and Screens tabs.
How Elements Are Identified
An element is not a selector. It is an identity made of:
| Part | Meaning |
|---|---|
| Platform | Web, Android, or iOS |
| Namespace | The application namespace the screen belongs to |
| Screen key | The observed screen the element lives on |
| Element key | The element's stable key within that screen |
| Node path | Its position in the screen's UI graph |
Locators hang off that identity as versions. Because identity is separate from locator, a changed selector does not create a new element — it creates a new locator version on the same element.
Element Repository
The Element Repository tab is scoped by platform — Android, iOS, or Web — and laid out in three columns.
Screens Column
The registry screens for the selected platform, each showing its namespace and element count.
Below them, an Observed, not registered section lists screen keys the generation runs have seen but that no registry screen owns yet. Select Register to promote one into the registry.
Elements Column
The active elements of the selected screen. Each row shows a category dot, the element name, and badges:
| Badge | Meaning |
|---|---|
| human | Authored by a person rather than by the engine |
| dormant | No live scenario binds this element |
| pending name | The element still has an engine-assigned name |
| green / red counters | How many runs succeeded and failed on this element |
Double-click a row to copy its step reference in the form <Screen.element>.
Element Detail
| Section | Content |
|---|---|
| Name | Editable inline. Rename applies it, uniquified within the screen. |
| Badges | Screen, category, kind, origin, and success/failure counters |
| Usage | The scenarios whose active revision binds this element |
| Identity keys | The identity keys the element claims |
| Observed behaviour | What interacting with the element did — effects and measured interaction recipes |
| Locator versions | The append-only version history |
| Events | Identity events recorded against the element |
An evidence badge summarizes the locator's standing:
| Badge | Meaning |
|---|---|
| proven | A run proved a locator of this element against the live target |
| failing | Every recorded attempt on this element failed |
| untried | No run has proven a locator yet, but the element is still selectable |
Editing a Locator
Select New HUMAN version to author a locator by hand. The editor prefills from the latest version.
Each candidate row has:
| Field | Notes |
|---|---|
| Locator strategy | The strategies available depend on the platform |
| Locator value | The selector itself |
| frames (outer >> inner) | The iframe chain, outermost first, separated by >> |
| Occurrence index | Leave empty when the locator is already unique |
Row order is the replay order — the first candidate that resolves uniquely wins. Use the move controls to rank them, then Save version.
Platform strategy vocabularies:
| Platform | Strategies |
|---|---|
| Web | css, xpath, id, testId, role, label, placeholder, altText, title, text, name |
| Android | id, xpath, accessibilityId, className, androidUiAutomator, text |
| iOS | xpath, accessibilityId, className, iosPredicateString, iosClassChain, name, label |
A strategy stored from another platform is marked "not executable" and must be replaced or removed.
Scope, arguments, and roles carry over read-only — they belong to the element contract, and a locator version cannot change them.
Locator versions are append-only. Elements are never deleted or re-keyed here, so a version you add sits alongside the engine's, ranked by the order you set.
Creating an Element
New element authors a synthetic element on the selected screen: a Name, a Category, a Kind, and its locator candidates.
If one of your locators is already owned by a registered element, the form names that element and offers to create yours anyway.
Coverage
The Coverage badge reports how many registry elements a live scenario actually references, with a per-category breakdown in its tooltip.
It has three states:
- A used-out-of-total count with a percentage.
- Coverage: index not built — the project's scenario reference index has not been built yet, so usage is unknown.
- Coverage — — coverage could not be read.
Coverage separates measured coverage from unmeasured targets, so missing evidence is never presented as covered.
Permissions
Viewing the registry needs no special permission. Creating elements, renaming, saving locator versions, and deciding proposals require scenario write permission. Without it the write controls are hidden.
Screens
The Screens tab is the same knowledge organized by screen.
The left panel lists registered screens with screenshot thumbnails, plus the same Observed, not registered section with Register actions.
With no screen selected, the right pane draws the application flow map — the transitions the generation runs observed between screens. Only the most frequent transitions are drawn.
Selecting a screen opens four sub-tabs:
| Sub-tab | Content |
|---|---|
| Overview | Screenshot, metadata, and the screen's observed screen keys |
| Knowledge | What AutoRunner has recorded about the screen |
| Elements | The screen's elements, with the same detail panel as the repository |
| Flows | Incoming and outgoing transitions for this screen |
Observed Screen Keys
A registry screen can own several observed keys, because AutoRunner merges keys it believes describe the same screen.
When a merge was wrong, select Detach on the key. It becomes a registry screen of its own; the elements stay on the original screen and scenarios re-link on regeneration.
A screen's only observed key cannot be detached.
Send to CaseWriter
Send to CaseWriter hands the selected screen knowledge and flows to CaseWriter as source context for test case generation. See CaseWriter.
Proposal Queue
The engine proposes; you decide. Registry proposals in the Element Repository header opens the queue.
Each proposal shows its kind, the element and screen it concerns, and the run that raised it.
| Proposal kind | Raised when |
|---|---|
| Duplicate candidate | A generation minted an element whose fingerprint matches an existing one, but no strong key proved it |
| Locator proposal | A replay found the element through new material |
| Screen twin candidate | Two registry screens share most of their strong anchors |
| Component candidate | The same element set appears under a landmark on several screens |
Screen twin and component candidates cannot be accepted yet — reject one, or leave it proposed.
Evidence shown per proposal:
- Shared keys and Vetoed by chips for duplicate candidates.
- The candidate locator chains, per role, for locator proposals.
- A contested badge when the existing element is itself claimed by more than one element.
For a duplicate, choose the Merge into target — either fold the proposed element into the existing one, or keep the proposed element and fold the existing one into it.
Add an optional decision note, then Accept or Reject. Accept is disabled, with the reason in its tooltip, when the proposal is stale, when no merge target is picked, or when that kind of acceptance is not yet available.
Self-Healing Review
When a scenario step fails and the agent repairs it during a run, AutoRunner records a heal event. Runtime-only repairs may be acknowledged automatically, but anything that changes a scenario or a locator needs your decision.
Where Heal Events Appear
| Surface | What you see |
|---|---|
| Run Detail | A Self-Healing strip with awaiting-review, applied, and rejected counts |
| Step rows | A heal badge on the affected step |
| Plan and run lists | A sparkle pill with the total heal count, pulsing when reviews are pending |
Heal Types
| Type | What was repaired |
|---|---|
| Locator update | A working locator replaced a broken one |
| Step retarget | The step was pointed at a different element |
| Step insert | A step was added |
| Step skip | A step was skipped |
| Step rewrite | The step was rewritten |
Reviewing a Proposal
Selecting a heal event opens the review dialog.
Authority — the scenario, run, attempt and result, source node, execution occurrence, base and current revision, and the evidence policy version. These pin the proposal to exactly one execution, so a proposal cannot be applied to a scenario that has since changed.
Runtime outcome — whether healing recovered the step during the run.
Proposed target locators — for each proposal, the platform, namespace, screen, element key, node path, and graph base checksum, then the locator evidence. Each candidate is marked either Current target proven or Not marked proven, with the iframe chain and evidence policy where they apply.
Original and Proposed snapshots side by side, comparing the BDD text, step key, element, parameters, and locators.
Healer reasoning — why the agent made the change.
Add an optional note, then Reject or Accept. The available decisions come from the server: a decision the server did not grant is disabled, with the reason shown. When authority is incomplete or stale, a Persistent Accept unavailable block explains why — for example, the active scenario changed after the run, so it must be replayed against the current revision.
Accepting or rejecting a proposal never rewrites the historical run's pass or fail result. Review controls only what future runs do.
Accepting a scenario change creates a new automation revision, and the dialog links to it so you can open it in AI Studio. Accepting a graph-only repair keeps the scenario revision unchanged and admits the repaired locator into the shared knowledge.
Next Steps
- AI Studio — Where the registry tabs live
- Run Detail — Where heal events surface after a run
- AI Editor — Editing repository-backed test code
