@piwitests/reporter 0.52.0 → 0.54.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@piwitests/reporter",
-  "version": "0.52.0",
+  "version": "0.54.0",
   "description": "Playwright reporter that streams results, traces and HTML reports to a Piwi Dashboard instance",
   "url": "https://github.com/PiwiTests/platform",
   "homepage": "https://piwitests.dev",

package/templates/skills/investigate-failure/SKILL.md

@@ -19,7 +19,7 @@ Prefer the **Piwi MCP server** if it is connected to this agent (tools named `li
 
 3. **Group by cause.** Call `get_failure_groups` (or `list_clusters` / `get_cluster`) — failures that share a root cause are clustered, so you fix one thing, not five. Work cluster by cluster.
 
-4. **Read the evidence per cluster.** Call `get_cluster_context` — the same SCM-grounded context the built-in diagnosis uses: representative errors, test steps, console logs, failing network requests, ARIA snapshots, and the **diff of files changed since the last green run**. If a diagnosis already exists, `get_cluster_diagnosis` returns its root cause and suggested fix.
+4. **Read the evidence per cluster.** Call `get_cluster_context` — the same SCM-grounded context the built-in diagnosis uses: representative errors, test steps, console logs, failing network requests, ARIA snapshots, and the **diff of files changed since the last green run**. If a diagnosis already exists, `get_cluster_diagnosis` returns its root cause and suggested fix. When the failure has no change behind it and the project records coverage, call `compare_coverage` with a failing execution's id: the code this run took that the last passing run did not (an error path, a fallback) is where to look.
 
 5. **Form the diagnosis.** Tie the failure to a cause with evidence: a selector that stopped matching, an assertion on changed copy, a slow/500 endpoint (`get_network_requests`), a race, a genuinely flaky test (check `get_test_stability_trend` — if it fails intermittently, treat it as flaky, not a regression). Point at the specific commit/file from the diff when the evidence supports it.
 

package/templates/skills/stabilize-flaky-tests/SKILL.md

@@ -15,7 +15,7 @@ Prefer the **Piwi MCP server** if it is connected (`list_flaky_tests`, `get_flak
 
 1. **Rank the flaky tests.** Call `list_flaky_tests` for the project and take the top few by impact. Do not try to fix the whole list at once.
 
-2. **Read the suspects.** For a chosen test, call `get_flake_profile`. Each suspect carries raw counts ("slow in 7 of 8 failures and 3 of 44 passes"), the condition that would test it, and, once the lab has run, its latest result (`lab`). `experiments` lists what the lab already found; if an experiment reproduced the test, skip to step 4. Read one failing execution (`get_test_run_case` / `explain_failure`) for the error at the moment it flaked.
+2. **Read the suspects.** For a chosen test, call `get_flake_profile`. Each suspect carries raw counts ("slow in 7 of 8 failures and 3 of 44 passes"), the condition that would test it, and, once the lab has run, its latest result (`lab`). `experiments` lists what the lab already found; if an experiment reproduced the test, skip to step 4. Read one failing execution (`get_test_run_case` / `explain_failure`) for the error at the moment it flaked. A test whose root cause is `order` depends on state an earlier test leaves behind: `compare_coverage` with its `testCaseId` names that test and the code whose path changes, so reproduce by running that test before this one in a single worker, and fix the shared state, not the wait.
 
 3. **Reproduce it.** Run the lab on the test (`plan_flake_experiment` gives the exact commands and the arms it will run, with an estimate):
 

package/templates/skills/write-the-missing-test/SKILL.md

@@ -14,7 +14,7 @@ drafts it from the graph, and opens it in the same change.
 ## How you reach Piwi
 
 Prefer the **Piwi MCP server** if it is connected (`list_scenario_gaps`,
-`draft_scenario`, `get_change_coverage`, `triage_gap`). Otherwise use the dashboard's **Gaps**
+`draft_scenario`, `get_change_coverage`, `get_coverage`, `triage_gap`). Otherwise use the dashboard's **Gaps**
 view, or the reporter CLI with `PIWI_DASHBOARD_URL` / `PIWI_API_KEY` /
 `PIWI_PROJECT_NAME` set.
 
@@ -38,7 +38,11 @@ view, or the reporter CLI with `PIWI_DASHBOARD_URL` / `PIWI_API_KEY` /
    skeleton: a title, `piwi:` annotations from the nearest test, the graph path
    from a reached page to the gap as the step list, the catalog page-object
    methods that match the page, and a `TODO` assertion naming what to check.
-   Nothing is committed — the skeleton is yours to finish.
+   Nothing is committed — the skeleton is yours to finish. When the gap points at
+   application code (an uncovered file, a handler, an error path), name the target
+   lines in it and call `get_coverage` with `projectId`, `file` and `lines`:
+   `nearest` is the existing test running most of the function around them, the
+   one whose setup to copy.
 
 4. **Finish the assertion.** The draft reaches the subject; you write the check.
    For a false-comfort gap, assert the effect the probe fault suppressed (the row
@@ -51,11 +55,33 @@ view, or the reporter CLI with `PIWI_DASHBOARD_URL` / `PIWI_API_KEY` /
    for the right reason: temporarily break the behavior it asserts and see it
    fail. Open it in the same pull request as the change that motivated it.
 
-6. **Report.** State which gap you closed (class, subject, score) and how the new
-   test asserts the missing behavior. If the gap had no reachable path, say so —
-   the draft cannot invent an entry point, and the gap may need a fixture.
+6. **Prove it reaches its target lines.** When the project records server
+   coverage (an ASP.NET Core backend in a coverage build), run the new test with
+   it on and reporting to Piwi:
 
-7. **Report back to Piwi.** Tell Piwi what you decided about the gap with
+   ```bash
+   PIWI_COVERAGE_SERVER=lines npx playwright test <file> -g "<title>"
+   ```
+
+   ```powershell
+   $env:PIWI_COVERAGE_SERVER='lines'; npx playwright test <file> -g "<title>"
+   ```
+
+   Then call `get_coverage` with `projectId`, `testFile`, `testTitle`, `file`
+   and `lines` (the target lines). `ran` lists the target lines it executed,
+   `notRan` those it did not, `notExecutable` those that cannot run (blank lines,
+   comments), and `unknown` those the capture could not tell: run it again, and
+   check the backend records `lines`, not only files. While a target line did not
+   run, compare your test with `nearest`, change the steps or the data that lead
+   to that code, and run again, until `allRan` is true. If `get_coverage` says the
+   project records no coverage, skip this step and say so in the report.
+
+7. **Report.** State which gap you closed (class, subject, score), how the new
+   test asserts the missing behavior, and which target lines it ran. If the gap
+   had no reachable path, say so — the draft cannot invent an entry point, and
+   the gap may need a fixture.
+
+8. **Report back to Piwi.** Tell Piwi what you decided about the gap with
    `triage_gap` (reporter or admin access): `verb: "accept"` for the gap you
    wrote the test for, `covered-by` with the covering test's id when a test you
    found already covers it, or `dismiss` with the reason (`not-worth-testing`,