/explore-ui

name: explore-ui
description: Standalone Phase 2 of SAP UI testing. Opens the target transaction in a real browser (SAP WebGUI) and explores it live to produce tests/<PROGRAM>/test-cases/_screens.md — the authoritative map of every on-screen control, its accessible name/label as Playwright will see it, and its initial state. This is about how the UI renders in the browser, NOT the ABAP selection-screen source. Use when the user asks to explore the UI, map screens, or produce _screens.md for an ABAP object.

Explore UI — Phase 2 (of 7)

Phase order: analyze-and-plan (1) → **explore-ui (2)** → design-cases (3) → define-data (4) → prepare-data (5) → build-scripts (6) → run-scripts (7).

This phase produces ONE artifact: `tests/<PROGRAM>/test-cases/_screens.md`, and reconciles what you discover back into `_findings.md`. It does not write test cases or data specs.

For bounded, self-contained support work, use `sap-task-helper` with explicit inputs, allowed writes, and an output contract.

What `_screens.md` IS — read this before anything else

`_screens.md` is a map of the **live web UI as it renders in the browser** (SAP WebGUI, inside its ITS iframe). Phase 6 (`build-scripts`) turns each control it lists into a Playwright call — `sap.setField("File path", ...)`, `sap.clickButton("Execute")`, `sap.selectRadio("Report")` — using the EXACT accessible name / on-screen label you record here.

`_screens.md` is NOT a description of the ABAP selection screen from the source code. It contains no ABAP variable names (`p_file`, `r_upl`, `s_site`), no MODIF IDs, no `LOOP AT SCREEN`/`MODIFY SCREEN` snippets, no message-class listings, no method names or line numbers, and no screens you did not actually open and observe. If a line couldn't be used by Phase 6 to write a locator, it does not belong here.

You **must** produce this file by opening the browser and looking. A `_screens.md` derived from ABAP source instead of live observation is the specific failure this phase exists to prevent — it is worthless to Phase 6 because source-derived labels are not the browser's accessible names.

How to actually drive the WebGUI — read this, it is where runs fail

You explore with your interactive browser tool's **accessibility snapshot**, NOT with Playwright code. This is the single most common time-sink: agents try Playwright selectors, everything times out, and they give up and derive from source. Don't.

• **Snapshot with the accessibility-tree action, and act by `ref`.** In VS Code Copilot these are: `read_page` (returns the accessibility tree WITH element `ref` values — your PRIMARY tool), `click_element` with `ref=<ref>` (click a radio/button/cell), and `type_in_page` with `ref=<ref>` (enter text). Use your environment's equivalent snapshot/click-by-ref/type-by-ref actions if the names differ. `read_page` sees INSIDE the SAP ITS iframe automatically — you do NOT target the iframe yourself.
• **`read_page` before you act and after every server round-trip.** Clicking a radio or Execute triggers SAP's PBO round-trip and re-renders the screen; re-snapshot to get the new controls and fresh `ref`s (old refs go stale).
• **`screenshot_page` is for visual confirmation ONLY** — it has no `ref`s, so you cannot act from it, and it does not give you accessible names. Never write `_screens.md` from a screenshot alone.
• **Do NOT use Playwright during exploration.** `page.locator(...)`, `frameLocator(...)`, `getByRole(...)`, `page.evaluate(...)`, `text=...` do not reliably reach the ITS iframe from page level and will time out. Playwright runs only inside real specs (Phase 6/7 via `abapfs_run_playwright_tests`), never during exploration. If you catch yourself writing `page.locator`, stop and use `read_page` + `ref`.
• **Generic roles are normal — record the accessible NAME.** ITS renders many controls (radios, F4 triggers, ALV cells) with role `generic` rather than `radio`/`button`. That is fine and expected: capture the accessible name (e.g. `"Upload"`, `"Report"`), because the runtime helpers (`selectRadio`, `clickButton`) locate by name and handle the missing ARIA role. Do not get stuck hunting for a `radio` role ITS never emits.
• **If it seems stuck, VERIFY before reacting — and never shortcut.** SAP's PBO round-trip and the ITS "Please wait…" splash can look like a hang or a timeout when the page actually loaded fine. If an action seems to time out, re-run `read_page` and check whether the screen advanced (it usually did) before concluding anything failed. A perceived timeout is NEVER a reason to give up and write `_screens.md` from source. **Know your escape hatches from the start, so you reach for them instead of shortcutting:** if a control genuinely won't drive, or the browser is truly unreachable after a retry, STOP and either (a) ask the user for help/data, or (b) ask the user to record the flow via the `sap-webgui-recording` skill ("ABAP FS: Record SAP WebGUI Flow"). Asking is always allowed and always better than a source-derived guess — you were told this before you started precisely so you don't discover it only after cutting a corner.

Non-negotiable execution gate

The `abapfs_run_playwright_tests` tool (Phase 7) and `build-scripts` (Phase 6) reject cases whose controls are missing from `_screens.md` or were never observed live. Do not guess locators or fabricate a screen you didn't open.

Why

A wrong or invented label here becomes a broken locator in every spec that touches that control — the automation reports "element not found" or, worse, silently clicks the wrong thing and passes. The whole test suite's reliability rests on `_screens.md` matching what the browser actually renders.

Tool availability (read this if a tool seems missing)

**Naming:** when these docs say *call* `X`, `X` is a **tool** (you invoke it and get a result); *delegate to / invoke* `X` is an **agent** (a subagent you launch); *load / follow* `X` is a **skill** (a procedure you read). A name without a