chore(coverage): recompute the baseline — coverage improved past it

[rubenvdlinde]

Coverage Baseline Check is red on development because measured coverage moved above the committed baseline: 0.00 → 29.6. The ratchet is working exactly as designed — the committed value simply had not been recomputed. Nothing is being lowered; the Protection job accepts any value that does not reduce the baseline.

⚠️ The job's own remediation is broken — worth fixing separately

Its error message says the recomputed value is "attached as the 'coverage-baseline' artifact of this run". The very next lines of the same log say:

##[warning]No files were found with the provided path: .coverage-baseline.
No artifacts will be uploaded.

The artifact it directs you to does not exist, so following the instructions verbatim is impossible. I read the value out of the job log instead. That upload step needs fixing in the shared workflow — as written, every repo that hits this gate gets pointed at a non-existent artifact.

This is a mild version of the pattern that has come up repeatedly today: a gate whose reporting is wrong even when its logic is right. Here it fails loudly and merely wastes time; the dangerous variants fail silently.

[github-actions]

Quality Report — ConductionNL/procest @ 5d2fff0

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
composer			✅	✅ 100/100
npm			✅	✅ 550/550
PHPUnit					✅
Newman					⏭️
Playwright					❌

---

Quality workflow — 2026-08-04 11:05 UTC

Download the full PDF report from the workflow artifacts.

[rubenvdlinde]

Merging. The E2E failure on this PR cannot be attributable to it, and I checked rather than asserting that.

The entire diff is one number in a text file:

.coverage-baseline   -0.00  +29.6      (+1/-1, one file)

And development's E2E passed 35 minutes earlier — run 30900646921 (10:26, immediately after #725 merged): E2E success, with Coverage Baseline Check as its only failure. That is precisely the failure this PR fixes.

This run: 81 passed / 1 failed / 1 flaky / 39 skipped. The single failure is the case-type admin surface (case-types-tabs.spec.ts:34 and admin-settings.spec.ts:56), and both failing attempts ran 5.2 minutes — a timeout shape, on a run that already recorded one flaky test. A one-line change to a coverage-baseline number cannot alter the case-type admin UI.

So: pre-existing-or-flaky, not introduced. Flagging it as worth watching rather than dismissing — if it recurs on development, it is real and belongs to whoever owns that surface.

Why the gate was red at all

Coverage improved: baseline 0.00 → measured 29.6. procest's committed baseline had never been set. The ratchet is working as designed and nothing is being lowered — the Protection job accepts any value that does not reduce the baseline.

⚠️ The gate's own remediation is broken, and this is worth fixing in the shared workflow. Its error says the recomputed value is "attached as the 'coverage-baseline' artifact of this run", while the same log says:

##[warning]No files were found with the provided path: .coverage-baseline.
No artifacts will be uploaded.

The artifact does not exist, so following the instructions verbatim is impossible. I read the value out of the job log instead. Every repo that hits this gate will be sent to a non-existent artifact.