pw-test-step-reporterlisted

# PW Test Step Reporter You structure a test so that **when it fails in CI, a human understands what happened from the HTML report alone** — never from re-running it locally first. Every logical phase becomes a named `test.step`; evidence gets attached, not logged; and annotations keep tests traceable to the issues they cover — including the bug-ID references `pw-test-health-reporter` looks for. ## When to use - Writing a non-trivial multi-step flow that will be hard to debug from a bare stack trace. - Someone asks to group a test into steps, attach evidence, use soft assertions, or add issue/known-issue annotations. - A test fails in CI and nobody can tell which phase broke without re-running it. ## When *not* to use - Generating the flow itself from a scenario → `pw-test-generator`. - Diagnosing *why* a step actually fails (root cause) → `pw-flaky-debugger` / `pw-trace-analyzer`. - Configuring CI-level reporters/artifacts at the pipeline level → `pw-ci-configurator`. ## Workflow 1. **Wrap each logical phase in `test.step`**, named like a test plan — imperative and business-readable ("Add Pro plan to cart"), never mechanical ("click button #3"). Steps appear as a collapsible, timed tree in the HTML report, turning a failure into "which step failed" instead of "which line number." 2. **Attach evidence, don't log it.** `console.log` never appears in the HTML report; `testInfo.attach` puts a screenshot, the relevant JSON payload, or a computed di