/run-scripts

name: run-scripts
description: Standalone Phase 7 of SAP UI testing. Rediscovers the configured test folder, program/specs, test cases, prepared data, and target system from disk; then runs Playwright via SAP Testing tools, generates .docx evidence, and diagnoses test script failures. Use when the user asks to execute tests, run TC-XXX, generate evidence, or debug a failed test.

Run Scripts — Phase 7 (of 7)

If selected cases are linked stages across SAP connections, load `multi-system-workflows` alongside this skill and execute separate connection-specific tool calls in stage order. Never put dependent stages in one parallel invocation.

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.

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, and this is exactly where it bites: `abapfs_run_playwright_tests` is frequently NOT in the default active toolset, and smaller models fail to find it and waste turns trying `run_in_terminal`/`runTests` instead. Before Step 0, make sure `abapfs_run_playwright_tests`, `abapfs_get_test_folder`, `abapfs_get_connected_systems`, `abapfs_check_test_data`, and `abapfs_build_evidence_report` are available; if any is missing, search your available tools for it by name. **Never use VS Code's generic `runTests` tool for SAP specs** — it expects Vitest/Jest and returns "No tests found" for Playwright specs. If `abapfs_run_playwright_tests` cannot be found after searching, tell the user rather than improvising.

The `abapfs_run_playwright_tests` prerequisite gate

`abapfs_run_playwright_tests` is a GATED tool: it refuses to run unless you pass the mandatory `prerequisiteConfirmation` field. Only pass it after you have completed Step 0 (artifacts present AND `abapfs_check_test_data` clean for the selected cases). The exact text to pass is: `I verified all upstream phase gates and test data readiness for this program`. It is valid only once that gate is genuinely complete; the run is rejected otherwise.

Non-negotiable execution gate

The `abapfs_run_playwright_tests` tool gates the run on all required upstream steps and artifacts from `analyze-and-plan`, `explore-ui`, `design-cases`, `define-data`, `prepare-data`, and `build-scripts`. It **will reject the run** if you have not completed the Step 0 readiness gate (it enforces this through the mandatory `prerequisiteConfirmation` field). Before calling it, complete every prerequisite; calling it early cannot bypass validation.

Why

A test run is only useful if its results are trusted. Rerunning until green, silently retrying flaky tests, or dismissing failures as "environmental" is how bugs reach prod with a passing test suite behind them. Diagnose every failure. A red result is a signal — either the code is wrong, the test is wrong, or the environment is wrong. All three matter. The docx evidence is what auditors, business owners, and post-mortems will look at; if it's incomplete or misleading, the whole exercise was for nothing.

Goal: execute tests, produce one aggregated evidence `.docx` per program and connection, and turn failures into actionable diagnoses.

Tools this phase uses

| Task | Tool | | ----------------------------------------- | ------------------------------------------------------------------------------ | | Run one spec | `abapfs_run_playwright_tests` with `program`, `tcIds: ["TC-001"]` | | Run an exact subset | `abapfs_run_playwright_tests` with `program`, `tcIds: ["TC-001", "TC-004"]` | | Run every spec in a program | `abapfs_run_playwright_tests` with `program` only; omit `tcIds` | | Run spec files concurrently | add `runInParallel: true`, optionally `maxTasks: 1..5` (default 3) | | Watch it run visibly | `abapfs_run_playwright_tests` with `headed: true` — do this the first time a new spec runs | | Pre-flight data readiness | `abapfs_check_test_data` with `program`, `connectionId` | | Build the .docx report | `abapfs_build_evidence_report` with `program`, `connectionId` | | Override one data value for this run only | not a tool — re-run `prepare-data` to fix the underlying cache instead |

There is no terminal command for SAP Testing execution or evidence generation — no `npx playwright test`, no `npm run`. Use the tools below. Optional external trace viewing is the only terminal exception described later.

Process

Step 0 — Standalone bootstrap and execution gate (mandatory)

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

Run these actions in this exact order in every chat:

1. Call `abapfs_get_test_folder` **before reading any test artifact or invoking another SAP Testing tool**. 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 requested TC-IDs from the request. If omitted, inspect `<TEST_FOLDER>/tests/*/test-cases/_index.md` and `test-scripts/*.spec.ts`. Auto-select only when exa