fix(register): gate-54 — three x-relation-filter tokens still name the pre-rename aanbieder property

[rubenvdlinde]

What

Three x-relation-filter tokens in lib/Settings/softwarecatalogus_register.json still name @object.aanbieder, a property that no longer exists. Repointed to @object.provider.

These three are INTRODUCED, not legacy debt

The CI verdict said "this run knew no base, so NONE of these could be classified as introduced or inherited", so the first job was to find out which they were. git log -S answers it:

aab66d52 — refactor(softwarecatalog): translate Dutch vocabulary to English (#506), 2026-08-14 — renamed the property key aanbieder → provider everywhere, including the filter KEY side ({ "aanbieder": … } → { "provider": … }), but its value-side rule never matched the compound token "@object.aanbieder". The three findings are two days old, not historical backlog.

This is the known codemod failure shape, in its mirror image: a rename that reaches bare identifier keys but not a quoted compound token that embeds the same name behind an @object. prefix.

Effect of the defect (it was not cosmetic)

ADR-062 rule 6: "Unresolved tokens drop their entry: an unfiltered picker beats an empty one." So since #506 these three pickers have been rendering unscoped — every contactPerson / module in the instance rather than only the ones belonging to the object's provider.

Not a data migration

x-relation-filter is picker-scoping metadata naming a property of the same schema. No property is renamed and no stored value changes. The stored data was already migrated by lib/Repair/RenameDutchCatalogColumns.php:179 ('aanbieder' => 'provider').

Both sides of every token verified by hand

Gate check (d) validates only the value side (@object.<field> must exist on the same schema). The key side (must be a property of the target schema) is unchecked, so it was verified manually:

property	filter	key resolves on target	token resolves on self
service.contactPerson	{organization: @object.provider}	contactPerson.organization ✔	service.provider ✔
service.modules	{provider: @object.provider}	module.provider ✔	service.provider ✔
module.contactPerson	{organization: @object.provider}	contactPerson.organization ✔	module.provider ✔

Also swept for other survivors of the same miss: zero live reads of an aanbieder key remain in lib/, src/, tests/ or src/manifest*.json (only prose in comments, error strings and a _note). The rename itself is otherwise complete.

Evidence — gate-54's own script, on its own paths

Instrument: check_relation_dialect.py from the vendored conduction/hydra-gates package, blob 3d4c81ca — byte-identical to ConductionNL/.github@main, i.e. the copy CI actually runs (openregister's vendored copy is v1.7.0 and stale; this is v1.7.3).

File enumeration reproduces the runner's own _enum_tracked exactly: git ls-files -- lib/Settings filtered to (register[^/]*\.json|/register\.d/[^/]*\.json)$.

BEFORE:  FILES_IN_SCOPE=3   FAIL=3  WARN=0   HELPER_EXIT=0
AFTER:   FILES_IN_SCOPE=3   FAIL=0  WARN=0   HELPER_EXIT=0

3 findings over 3 files → 0 findings over 3 files. The 3 reproduce baseline run 31929364918 exactly, so the instrument is measuring the same thing CI did. The gate is shown to both fail and pass on this repo, so a zero here is a verdict and not an unopened scope.

JSON re-parsed clean after the edit. No test in tests/ asserts x-relation-filter.

Checks

• composer check:strict — not run, and it cannot be affected: this PR changes one .json file and zero PHP. PHPCS/PHPMD/Psalm/PHPStan have no input here, so there is no L10 debt to inherit.
• Edits made with the Edit tool, one token at a time. No sed, no codemod — this whole finding is what a codemod did.

Baseline parity

Baseline for this repo (§1) is run 31929364918, which is red on Hydra Gates, Quality Report and E2E. This PR should clear gate-54 and change nothing else; E2E is a pre-existing red owned by S20.

[github-actions]

Quality Report — ConductionNL/softwarecatalog @ 7d81213

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	❌
phpmd	❌
psalm	❌
phpstan	❌
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-manifest		✅
check-vue-demi		✅
test-l10n		✅
format		✅
composer			✅	✅ 130/130
npm			✅	✅ 704/704
app:check-code	⏭️
info.xml	✅
REUSE	❌
PHPUnit					❌
Newman					⏭️
Playwright					❌
Hydra gates					❌

---

Quality workflow — 2026-08-16 09:16 UTC

Download the full PDF report from the workflow artifacts.

[rubenvdlinde]

CI verdict — gate-54 PASS, and zero new failures vs the base

Read from the Hydra Gates job logs of both runs (echoed step-source lines stripped first — GitHub Actions echoes the step's own script into the log, and a ::warning:: it could emit reads exactly like one it did).

This PR — run 31938160656:

[gate-54] relation-dialect: PASS

Gate-by-gate parity (base = development @ 0335cb20, run 31937314279 — not the §1 baseline d6393972, see below):

	failing gates
base 0335cb20	gate-7, gate-16, gate-25, gate-26, gate-54, gate-57, gate-66
this PR	gate-7, gate-25, gate-26, gate-57, gate-66
failing here but not on base	none

• gate-54: FAIL → PASS. That is this PR's job, done.
• gate-16 also flips, and I am not claiming it: gate-16 is diff-scoped per ADR-020 and this PR's diff contains no spec-annotated code, so it has nothing to measure. It will come back the moment a PR touches PHP. Not a fix.
• The five remaining gates are untouched pre-existing debt owned by other slots (gate-7 → S12, gate-57 → S8, gate-66 → S18, gate-25/26 → the ratchet tails).

⚠️ The four red PHP Quality legs are NOT from this PR — and are newer than the plan's baseline

This PR changes one .json file and zero PHP, yet phpcs, phpmd, phpstan and psalm are all red. They are red on the base commit too, verified by reading 0335cb20's own check-runs rather than assuming.

Worth flagging separately, because it happened this morning: between d6393972 (05:35Z) and 0335cb20 (08:46Z) — one merge, #519 refactor/adr-084-type-hint-the-contract — development gained 10 new failing jobs:

• PHP Quality × 4 — phpcs, phpmd, phpstan, psalm (phpcs dies at step Run phpcs, exit 2)
• PHPUnit × 6 — every cell (8.3/8.4 × stable32/33/34, pgsql), at step Run PHPUnit tests

Failing-job diff, ?per_page=100, reading each run's own conclusion:

31929364918 (d6393972):  E2E, Hydra Gates, Quality Report                          = 3
31937314279 (0335cb20):  the same 3 + 4x PHP Quality + 6x PHPUnit                  = 13

So anyone branching softwarecatalog after ~08:46Z inherits ten reds that aren't theirs. Raised on the fleet board as its own slot.

Instrument note

Measured with check_relation_dialect.py blob 3d4c81ca, confirmed byte-identical to ConductionNL/.github@main — i.e. the code CI actually ran above, not a local approximation. openregister's vendored copy is v1.7.0 and stale (it lacks the whole INHERITED/INTRODUCED block); this came from a v1.7.3 vendor tree.