define-data

Define Data — Phase 4 (of 7)

For a cross-system staged scenario, also load multi-system-workflows: declare only pre-existing inputs here. A key produced by an earlier system at run time belongs in the workflow JSON handoff, not a prepared-data requirement.

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 TC-XXX.data.md requirement specs — the reusable, system-agnostic SHAPE of the data each case needs. It does NOT resolve concrete values (that is Phase 5, prepare-data) and does NOT write specs (Phase 6).

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

Why this is its own phase

Data specs written as an afterthought at the end of a big case-writing session come out as one-line stubs ("cache key + status") that Phase 5 then has to throw away and rewrite from scratch. That is exactly what happened before this was split out. A .data.md is a real contract: it decides which of four sources each value comes from, whether an upload fixture is Excel or CSV, and which keys the spec (Phase 6) will reference. Getting the format wrong here means the program silently rejects the upload at run time and the "test" proves nothing. This phase exists so every data requirement gets deliberate attention, once, in the right format.

Non-negotiable execution gate

prepare-data (Phase 5), build-scripts (Phase 6), and abapfs_run_playwright_tests (Phase 7) all reject cases whose .data.md is missing, malformed, or references undeclared keys. Author every required sidecar here, correctly, before handing off.

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.