/prepare-data

name: prepare-data
description: Standalone Phase 5 of SAP UI testing. Rediscovers the configured test folder, program, approved cases, and target system from the request and upstream artifacts; then resolves TC-XXX.data.md requirements into per-system data.json caches. Works in a new chat without prior conversation context. Use when the user asks to prepare data, resolve fixtures, or bootstrap TC-XXX for a specific system.

Prepare Data — Phase 5 (of 7)

For a cross-system staged scenario, also load `multi-system-workflows`. Do not cache a runtime-produced predecessor key in `data.json`; resolve only genuine pre-run inputs here.

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 reads the `TC-XXX.data.md` specs authored in Phase 4 and resolves them into per-system `data.json` caches.

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. Before Step 0, ensure `abapfs_get_test_folder`, `abapfs_get_connected_systems`, `abapfs_check_test_data`, `abapfs_verify_test_data_usage`, `abapfs_get_sql_syntax`, and `abapfs_run_sql_query` 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 5 prerequisite. The `abapfs_run_playwright_tests` tool verifies data preparation and **will reject every affected case** if preparation was skipped, deferred, incomplete, stale, or unverified. Complete each requirement now; runtime fallback, guessed values, and later phases cannot bypass the tool's validation.

Why

Tests that pass with the wrong data prove nothing. A material number that exists in DEV but was deleted in QAS turns a real regression into a spurious "data missing" error, and the actual bug slips through unnoticed. Preparing data honestly per landscape is what makes the entire suite trustworthy. Fabricating a value the SQL didn't return is worse than admitting the case is blocked — it lies to the audit trail.

Goal: turn a system-agnostic `TC-XXX.data.md` requirement spec into a connection-scoped `tests/<PROGRAM>/test-results/<connectionId>/TC-XXX/data.json` value cache. `generated` requirements are validated here but built fresh only at test-run time (Step 2a).

Why per-system

• Data valid in DEV is often absent in QAS/PRD (materials deleted, plants renamed, orders don't cross landscapes).
• One `.data.md` describes the SHAPE; each landscape needs its own resolved values.
• A later execution against a different system can repeat this phase without changing the case or spec.

Process

Step 0 — Standalone bootstrap and upstream 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 requested TC-IDs from the current request. If omitted, inspect `<TEST_FOLDER>/tests/*/test-cases/_index.md`. Auto-select only when exactly one program is a valid candidate; otherwise ask. Use `_index.md` runnable status, priorities, and `Data required?` column rather than conversation memory or rereading every TC file. 4. Enforce the upstream input gate. For the selected program, require:

• `test-cases/_index.md` and `test-cases/_findings.md` (from analyze-and-plan / design-cases)
• `test-cases/_screens.md` (from explore-ui)
• each selected `TC-XXX.md` (from design-cases)
• each selected `TC-XXX.data.md` whose `_index.md` row says `Data required? = yes` (from define-data)

If `_index.md` or `_findings.md` is missing/inconsistent, STOP and follow `design-cases` (or `analyze-and-plan` if `_findings.md` itself is missing). If `_screens.md` is missing, STOP and follow `explore-ui`. If an index row says `Data required? = yes` but the `.data.md` sidecar is missing, STOP and follow `define-data` to author it; if it says `no` but a sidecar exists, that is a case-design error — follow `design-cases`. 5. Call `abapfs_get_connected_systems` and confirm the target `connectionId`; ask only if ambiguous. 6. Confirm the ABAP-tools connection is the SAME physical system. Every query passes explicit `connectionId`; never rely on defaults. 7. Cache path is `<TEST_FOLDER>/tests/<PROGRAM>/test-results/<CONNECTION-ID>/<TC-ID>/data.json`, where `<CONNECTION-ID>` is the exact connectionId **in UPPERCASE**. This matters: at run time the framework derives the folder from the connectionId uppercased, so a hand-written lowercase folder is never found on a case-sensitive filesystem (Linux/macOS) — it only "works" on Windows by accident. Use the uppercased connectionId, and never a friendly environment label in its place.

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

> **Say before continuing:** "Step 0 completed. Evidence: test folder `<TEST_FOLDER>`, program `<PROGRAM>`, selected cases `<TC-IDs>`, and connection `<connectionId>` confirmed. Next: Step 1 — read every data specificat