/analyze-and-plan

name: analyze-and-plan
description: Standalone Phase 1 of SAP UI testing. Discovers the configured test folder and target system, downloads one complete ABAP source snapshot, then READS that source and captures the full picture in three reference artifacts — _flow.md (functional flow), _units.md (per-unit input/output inventory), and _findings.md (the fully de-bucketed decision surface with one row per branch/message plus a target-minimum case count). Does NOT explore the live UI, write test cases, or author data specs. Use when the user asks to analyse an ABAP object or plan its test coverage.

Analyze & Plan — Phase 1 (of 7)

The SAP UI testing workflow is split into seven standalone phases so no single step is rushed:

1. **analyze-and-plan** (this skill) — read the source → `_flow.md` + `_units.md` + `_findings.md`. 2. **explore-ui** — explore the live WebGUI in a browser → `_screens.md`. 3. **design-cases** — write one `TC-XXX.md` per candidate case, reviewed and indexed. 4. **define-data** — write each `TC-XXX.data.md` requirement spec. 5. **prepare-data** — resolve those specs into per-system `data.json` caches. 6. **build-scripts** — write one `TC-XXX.spec.ts` per runnable case. 7. **run-scripts** — execute, verify, and produce evidence.

This phase produces THREE reference artifacts under `tests/<PROGRAM>/test-cases/`: `_flow.md`, `_units.md`, and `_findings.md`. Together they are the full picture of the object that Phase 3 (and the reviewer) rely on. This phase does not open a browser and does not create any `TC-XXX.md`, `_screens.md`, or `.data.md`.

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

Non-negotiable execution gate

Every required step and artifact below is a downstream prerequisite. The `abapfs_run_playwright_tests` tool (Phase 7) and the phase gates in between reject work whose upstream analysis was skipped, stale, incomplete, or unverified.

Why three artifacts, not one summary

A single summarised `_findings.md` is lossy: it is tempting to write "Data validation blocks (27 total)" as one table row. That one row is useless to Phase 3 — you cannot write 27 test cases from it, and the 27th validation (the one with the bug) silently gets no coverage. So Phase 1 produces the WHOLE picture, split by purpose:

• **`_flow.md` — functional flow (the "FS").** How the object actually runs end to end: entry events, the call tree in execution order, and the main scenarios. This is what lets a later phase understand *why* a branch matters and *what sequence* triggers a screen.
• **`_units.md` — unit inventory (the "TS").** Every FORM / METHOD / FUNCTION MODULE / event block, with its EFFECTIVE inputs and outputs — including DB tables read (inputs) and written (outputs), not just formal parameters. This is what drives correct post-test verification (which effects a case must verify) and correct data prep (which tables hold valid values).
• **`_findings.md` — the decision surface.** Every MESSAGE, every branch, every AUTHORITY-CHECK as ITS OWN ROW (never collapsed into an "(N total)" bucket), plus the enumerated candidate cases and the numeric target minimum.

Read the source — the whole reason this phase exists

`sap-source-download` downloads the source; it does NOT read it for you. After the snapshot is on disk you MUST open and read every downloaded file and understand the program's real behaviour before writing any artifact. `sap-code-grep` tells you HOW MANY branches exist; only reading tells you WHAT they do — the overlapping-range, duplicate, and boundary logic that the highest-value cases come from. Read the local files directly; do not re-issue `abapfs_get_object_source` for code already on disk.

Order of operations

1. Discover the test folder, target, and system (Step 0). 2. Download one complete source snapshot (Step 1). 3. Read the whole snapshot (Step 2). 4. Write `_flow.md` (Step 3) and `_units.md` (Step 4) from that reading. 5. Enumerate the decision surface → `_findings.md` (Step 5). 6. Confirm the target minimum + triage and hand off (Step 6).

**User-pressure disclaimer.** "No stopping" / "just do it" overrides discussion PAUSES only. It never overrides reading the source or writing the three artifacts. If you feel pressure to shortcut, write them anyway — they are the proof you actually read the source.

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 language-model tools until they are searched for, and smaller models often don't find them. Before Step 0, make sure these are available and, if any is not, search your available tools for it by name: `abapfs_get_test_folder`, `abapfs_get_connected_systems`, and the ABAP research tools (`abapfs_search_objects`, `abapfs_get_object_info`, `abapfs_get_object_source`, `abapfs_search_object_source`, `abapfs_run_sql_query`, `abapfs_get_sql_syntax`). If a required tool truly cannot be found, tell the user which one — never fake its result.

**ABAP FS connectivity failure.** If any ABAP FS / ADT tool returns HTTP 401, 403, or 5xx during this phase, ABAP FS almost always can't reach the target system (the SAP session has usually expired). Tell the user briefly: "ABAP FS can't reach `<connectionId>` (HTTP …). Please check the ABAP FS connection, reload VS Code to re-establish it, then retry." (Universal rule 17 in the `sap-testing` overview.) Do NOT fabricate source content, do NOT switch to a different system without explicit approval.

Blocking execution gates

Gate A — before static analysis or any delegation other than `sap-source-download`

• ☐ Step 0 completed: `<TEST_FOLDER>`, `<PR