chore(ci): stop pinning hydra-gates — track the package at @main

[rubenvdlinde]

What changed

This PR started life as a pin bump (hydra-gates-ref: v1.3.0 -> v1.4.0). It now removes the hydra-gates-ref line entirely so this caller inherits the shared workflow's default.

       enable-hydra-gates: true
-      hydra-gates-ref: v1.4.0

enable-hydra-gates: true is unchanged. enable-axe remains unset. The comment block that justified the pin is replaced with a short note explaining why there is deliberately no pin.

Why

ConductionNL/.github/.github/workflows/quality.yml already defaults hydra-gates-ref to main, and this repo consumes quality.yml at @main. Overriding the input was the only thing holding the gates package still. Drop the override and both sides move together — a gate fix reaches this repo without a commit in this repo.

Bumping the pin is a treadmill: it works until the next fix lands upstream, and between bumps the repo is running whatever the gates package looked like on the day someone last remembered.

A pin is a silent expiry date on every upstream fix. We have paid for that twice:

• .github#159 — 22 repos sat pinned on v1.0.1, which predated the gate fixes. 16 gates were dead fleet-wide and every one of them reported PASS. A gate that never runs emits a tick identical to one that did, so nothing in any repo's CI history showed it.
• .github#173 — the shared side flipped a default at @main while the package stayed pinned per caller. Old pinned runners did not carry the coverage accounting the new default assumed, so they went red on gates they had no subject matter for.

The two failures are opposite shapes of the same split: shared workflow at @main, package pinned. Removing the pin closes both.

Rollback

• For everyone: revert on ConductionNL/.github main. One commit reaches the whole fleet — which is the point.
• For this repo only: set hydra-gates-ref: explicitly again, with a comment saying why this repo needs to hold still. The input is still honoured; it just is not the default posture.

Safety net

ConductionNL/.github#177 adds the resolve probe plus the gates package suite gating .github main, so a broken package cannot reach main unnoticed now that consumers track it.

[github-actions]

Quality Report — ConductionNL/launchpad @ e5a5d70

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-manifest		✅
composer			✅	✅ 102/102
npm			✅	✅ 548/548
PHPUnit					✅
Newman					✅
Playwright					✅
Hydra gates					❌

---

Quality workflow — 2026-08-06 05:51 UTC

Download the full PDF report from the workflow artifacts.

[rubenvdlinde]

Closing as already landed — not rejected, superseded.

development no longer sets hydra-gates-ref at all. It was removed by
051d99b fix(ci): remove the hydra-gates-ref pin so the gates stop expiring,
which is this PR's exact intent, reached by a different commit.

Verified against the current tip (70420eb5), not by title search:

$ git grep -n '^\s*hydra-gates-ref' origin/development -- .github/workflows/
(no match, exit 1)

$ git log -S'hydra-gates-ref: v1.3.0' --oneline -- .github/workflows/code-quality.yml
051d99bb fix(ci): remove the hydra-gates-ref pin so the gates stop expiring
8b6d270d ci(quality): move hydra-gates-ref v1.0.1 -> v1.3.0, which is what is failing CI (#55)

051d99bb also carries a strictly better rationale than this branch does: this
branch's comment stops at the two earlier failure modes (#159 stale, #173
default-flip), while the landed comment adds the third — the one that actually
decided it — that quality.yml floats @main and executes gate scripts by
path inside the pinned package, so every gate added at @main is a path the
pin does not contain (scripts/axe-run.cjs, scripts/lib/check_spec_anchors.py,
check_form_labels.py, check_license_triangle.py). That is why the answer was
"remove the pin", not "bump it to v1.5.0" — v1.5.0 exits 99 on every mainline
push, and v1.5.1 would only have reset the same expiry clock a fourth time.

The branch is also CONFLICTING against that landed change, so there is nothing
here to rebase onto: the conflict is the same edit arriving twice.