explore-ui

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 refs (old refs go stale).
• screenshot_page is for visual confirmation ONLY — it has no refs, 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.