/build-scripts

name: build-scripts
description: Standalone Phase 6 of SAP UI testing. Rediscovers the configured test folder, program, approved cases, and primary system from disk; validates upstream inputs; then writes one tests/<PROGRAM>/test-scripts/TC-XXX.spec.ts per case using @sap-testing/runtime. Use when the user asks to write, generate, or convert Playwright scripts from test cases.

Build Scripts — Phase 6 (of 7)

If the scenario crosses SAP connections, load `multi-system-workflows` alongside this skill. Keep one system per script and implement only the documented explicit JSON handoff between linked stage cases.

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

For bounded, self-contained support work, use `sap-task-helper` with explicit inputs, allowed writes, and an output contract. **Never delegate the whole phase** (e.g. "write specs for all 30 cases") to `sap-task-helper` — it is a bounded per-file helper and will reject phase-scale work. Convert cases yourself, or delegate at most a small, explicitly-listed batch of disjoint files with a per-file write boundary.

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 verb: see the overview's "Skills, tools, and agents" list.

The editor may hide tools until searched for. Before Step 0, ensure `abapfs_get_test_folder`, `abapfs_get_connected_systems`, and `abapfs_verify_test_data_usage` are available; if any is missing, search your available tools for it by name. If one cannot be found, tell the user.

Non-negotiable execution gate

Every required step and artifact below is recorded as a Phase 6 prerequisite. The `abapfs_run_playwright_tests` tool verifies script generation and validation and **will reject every affected case** if anything was skipped, deferred, incomplete, stale, or unverified. A `.spec.ts` file existing by itself cannot bypass the tool's validation.

Why

The test case says what to verify; the spec is the ONLY thing SAP will actually be asked. If the spec drifts from the case — skips a control, ignores a default, uses a hardcoded value instead of the resolved data — the automation reports GREEN while the real bug lives on. Every deviation from the case's state table is a hole in coverage. Every hardcoded material or plant makes the spec unrunnable in the next system. Fidelity here is what turns a plan into protection.

Goal: 1:1 `.md` → `.spec.ts` conversion using only the helper API, with runtime data resolution.

Process

Step 0 — Standalone bootstrap and input gate (mandatory)

> **Say before acting:** "Starting Step 0: standalone bootstrap and upstream input gate."

Run these actions in this exact order in every chat:

1. Call `abapfs_get_test_folder` **before reading or writing any artifact**. Treat the returned absolute path as `<TEST_FOLDER>`; never infer it from the workspace or a prior chat. 2. If unset, STOP and ask the user to run "ABAP FS: Enable SAP UI Testing Features". If the folder is not open in the workspace, STOP and ask the user to add it via File > Add Folder to Workspace. 3. Resolve `<PROGRAM>` and selected TC-IDs from the current request. If omitted, inspect `<TEST_FOLDER>/tests/*/test-cases/_index.md`. Auto-select only when exactly one candidate exists; otherwise ask. Use `_index.md` approval, runnability, and `Data required?` state, not prior-chat memory. 4. Enforce the upstream input gate for the selected program: `_index.md`, `_screens.md`, and every selected `TC-XXX.md` must exist. If `_index.md`/`TC-XXX.md` is missing or inconsistent, STOP and follow `design-cases`; if `_screens.md` is missing, STOP and follow `explore-ui`. Read a matching `TC-XXX.data.md` only when the index says `Data required? = yes` (authored in define-data); `no` means no sidecar may exist. 5. Call `abapfs_get_connected_systems` and confirm the primary `connectionId`. Ask only if ambiguous. The spec remains system-agnostic; this identity is used to check readiness and verify source facts. 6. If a selected case has `Data required? = yes`, inspect `<TEST_FOLDER>/tests/<PROGRAM>/test-results/<connectionId>/<TC-ID>/data.json` or run the available readiness check. Missing prepared data does **not** prevent writing a structurally valid spec, but it must be reported in the handoff as a Phase 5 (prepare-data) blocker before execution. 7. Confirm ABAP tools are available if source verification is needed. Every ABAP-tool call passes explicit `connectionId`.

Do not continue to Step 1 until `<TEST_FOLDER>`, `<PROGRAM>`, selected TC-IDs, required upstream artifacts, and primary `connectionId` are known.

> **Say before continuing:** "Step 0 completed. Evidence: test folder, program, selected cases, required planning artifacts, and primary connection confirmed. Next: Step 1 — read source artifacts."

Step 1 — Read the test case, screens map, and helpers

> **Say before acting:** "Starting Step 1: read every source artifact required for script generation."

MANDATORY reads (parallel):

• `tests/<PROGRAM>/test-cases/<TC-XXX>.md` (frontmatter + steps + expected)
• `tests/<PROGRAM>/test-cases/<TC-XXX>.data.md` when `_index.md` says `Data required? = yes`
• `tests/<PROGRAM>/test-cases/_screens.md` — authoritative source of labels, groups, dialogs, buttons. If missing, STOP and follow `explore-ui` — no reliable way to write locators without it.
• `tests/<PROGRAM>/test-cases/_index.md` — the reviewer's map of all cases. If a case or its runnability must change, STOP and follow `design-cases` to update the TC source artifact, then rerun `abapfs_build_test_index`; never hand-edit the index tables.
• Every `<TEST_FOLDER>/recordings/*.recording.ts` path explicitly referenced b