/design-cases

name: design-cases
description: Standalone Phase 3 of SAP UI testing. Turns the _findings.md decision surface and the _screens.md control map into one tests/<PROGRAM>/test-cases/TC-XXX.md per candidate case — grounded in the actual code behaviour (overlap/dedup/boundary), with a per-case selection-screen state table and a mandatory post-test verification section (SQL the model runs, or manual checks the user runs) proving the object did its job. Enforces the target-minimum count, runs the adversarial reviewer, then builds the index. Use when the user asks to design or write test cases for an ABAP object.

Design Cases — Phase 3 (of 7)

If one business scenario has ordered stages on different SAP connections, load and follow `multi-system-workflows` alongside this skill. Split it into linked `TC-NNN` stage cases; never put multiple systems inside one case script.

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.md` files plus the rebuilt `_index.md`/`_index.docx`. It does NOT author `.data.md` files (Phase 4) and does NOT write specs (Phase 6). Each `TC-XXX.md` still DECLARES `dataRequired: yes|no`; the sidecar itself is written in Phase 4.

For bounded, self-contained support work, use `sap-task-helper` with explicit inputs, allowed writes, and an output contract. Never delegate the whole phase.

Non-negotiable execution gate

`abapfs_build_test_index` is GATED: it refuses to build unless you pass `reviewerConfirmation` certifying the `sap-test-plan-reviewer` agent already returned PASS. You cannot produce the index — and therefore cannot hand off — without the reviewer actually running. Downstream phases and `abapfs_run_playwright_tests` reject cases whose plan was never reviewed.

Why

The test case is the contract for everything after it: Phase 6 writes exactly what the case says, and Phase 7 proves exactly what the case claims. A case that buckets three validations into one, omits the overlapping-range scenario, or claims "records inserted correctly" without a verification step is a coverage hole dressed up as coverage. Because there are many cases to write, the temptation is to skim — which is precisely why this is its own phase and why an independent reviewer gates it. Write each case as if it is the only defence against a million-dollar defect, because it is.

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_split_test_cases`, and `abapfs_build_test_index` are available; if any is missing, search your available tools for it by name. If one cannot be found, tell the user which is missing.

Step 0 — Standalone bootstrap and input gate (mandatory)

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

1. Call `abapfs_get_test_folder` **before reading any artifact**. Treat the result as `<TEST_FOLDER>`; never infer it. 2. If unset, STOP and ask the user to run "ABAP FS: Enable SAP UI Testing Features". If not open in the workspace, STOP and ask them to add it. 3. Resolve `<PROGRAM>` from the request; if omitted, inspect `<TEST_FOLDER>/tests/*/test-cases/_findings.md`. Auto-select only when exactly one candidate matches; otherwise ask. 4. **Enforce the Phase 1 + Phase 2 input gate.** All of these must exist:

• `tests/<PROGRAM>/test-cases/_findings.md`, `_flow.md`, `_units.md` (from analyze-and-plan)
• `tests/<PROGRAM>/test-cases/_screens.md` (from explore-ui)

If any Phase 1 artifact is missing, STOP and follow `analyze-and-plan`. If `_screens.md` is missing, STOP and follow `explore-ui`. Never write cases from memory. 5. Read ALL of them fully:

• `_findings.md` — the de-bucketed candidate list, one row per branch/message/auth, the behavioural rules, background artifacts, input file format, and the final target minimum.
• `_flow.md` — the functional flow, so each case's steps follow a real trigger sequence.
• `_units.md` — the unit I/O inventory; the "Effective outputs" column tells you exactly which effects a case must verify (which DB tables, IDocs, jobs, spool, files) and therefore what its `## Post-test verification` rows are.
• `_screens.md` — the exact control labels for the state table.

6. **Read the actual source too — a summary is not enough.** `_findings.md` is a distilled map; the source snapshot (path recorded in `_findings.md`) is the ground truth. Before writing a case, read the relevant unit(s) in the snapshot (guided by `_units.md`) to get the EXACT message text, the exact condition that fires it, and the exact expected behaviour (e.g. that an overlap truncates rather than rejects). If while reading you find a branch or message that `_findings.md` missed, STOP and follow `analyze-and-plan` to fix `_findings.md` first — do not silently plan around a gap. 7. You pass the snapshot path to `abapfs_build_test_index` as `sourceSnapshot`. 8. Call `abapfs_get_connected_systems` and confirm the `connectionId` (used only if you need to re-verify a source fact live).

> **Say before continuing:** "Step 0 completed. Evidence: test folder, program, `_findings.md`/`_flow.md`/`_units.md`/`_screens.md` read, source snapshot read for the relevant units, and snapshot path confirmed. Next: Step 1 — category contract and count gate."

Step 1 — Category contract and count gate

> **Say before acting:** "Starting Step 1: state the category contract and read the target minimum."

**Category contract — say this before creating files:** "I will use only these exa