feat(repair): migrate softwarecatalog's Dutch columns to English

[rubenvdlinde]

What

Adds RenameDutchCatalogColumns — the data-migration half of softwarecatalog's English vocabulary slice — plus the canonical spec it anchors to.

No property is renamed in this PR. The migration lands first, because the app's spec requires it to exist before any rename merges.

Why a migration is needed at all

OpenRegister does not store an object as a JSON blob keyed by property name. Each schema property is a real, snake_cased column in oc_openregister_table_{register}_{schema}. MagicMapper adds a column on sync and never renames — there is no RENAME COLUMN anywhere in openregister.

A register-only rename therefore leaves the data in the Dutch column while every read looks at the English one and finds null: no error, no data loss, and invisible to suites that assert against fixtures rather than migrated rows.

Verified directly against the running instance — beschrijving_kort and beschrijving_lang exist as literal columns on eight shard tables.

Why this one is scoped by schema, not by register

The sibling steps in opencatalogi (#850) and decidesk (#467) scope by register, because everything under those registers is ours to rename. That is not true here. Five schemas hold externally standardised field names:

schema	why exempt
element, relation	GEMMA/GGM model imported from VNG — measured: of fourteen materialised shard tables, the only two carrying toelichting and bron are ids 44 and 49, exactly the GEMMA pair
view	holds gemma_status, gemma_thema, gemma_type, gemma_url, detailniveau, publiceren, titel_view_swc
model, property-definition	ArchiMate Open Exchange File Format containers — model carries xmlns, xsi, schema_location, identifier off the exchange root element

A register-scoped step would have rewritten the import contract as a side effect, and the symptom would have been a GEMMA re-import silently writing nulls.

model and property-definition hold no column this map targets today, so listing them changes nothing now — they are exempt so a property added later is exempt by default rather than migrated by omission.

Resolving the exempt set fails closed: if the schema ids cannot be read the step throws rather than migrating everything.

Ambiguous renames are refused, never merged

beschrijving, beschrijving_lang and omschrijving all mean description. They don't co-occur in any schema today — confirmed by the dry run, not assumed — but a later fragment could introduce a pair, and a silent merge would destroy one of two values. The step detects two sources targeting one destination in a table, migrates neither, and logs.

Verification

• php -l clean; info.xml parses; phpcs clean under this app's standard, including its named-parameter sniff and @spec anchor requirement
• Exclusion positive control, run against the live register: element, view, relation resolve as EXCLUDED and the other nineteen shard tables as in scope. This control caught view (schema 45) — a table absent from the column survey that suggested the exempt list in the first place
• Dry run of the step's exact resolution: 40 renames across 11 shard tables, zero GEMMA/ArchiMate tables touched, zero ambiguity

What is not verified

The spec asks for validation against copied production data, citing ~9,500 imported VNG records. This dev instance holds 50 rows across the whole register, 3 live, and exactly one non-null value in any mapped column.

The code paths are exercised. The production volume and variety are not. Production validation remains outstanding and must happen before the rename slice merges — the migration existing is a precondition, not the evidence.

[github-actions]

Quality Report — ConductionNL/softwarecatalog @ 2718417

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	❌
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-manifest		✅
check-vue-demi		✅
test-l10n		✅
composer			❌	✅ 128/128
npm			✅	✅ 718/718
PHPUnit					❌
Newman					⏭️
Playwright					✅
Hydra gates					❌

---

Quality workflow — 2026-08-11 19:59 UTC

Download the full PDF report from the workflow artifacts.

[github-actions]

Quality Report — ConductionNL/softwarecatalog @ 60fc8a5

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	❌
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-manifest		✅
check-vue-demi		✅
test-l10n		✅
composer			✅	✅ 128/128
npm			✅	✅ 718/718
PHPUnit					❌
Newman					⏭️
Playwright					❌
Hydra gates					❌

---

Quality workflow — 2026-08-11 23:23 UTC

Download the full PDF report from the workflow artifacts.

[github-actions]

Quality Report — ConductionNL/softwarecatalog @ 6a432c8

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-manifest		✅
check-vue-demi		✅
test-l10n		✅
composer			✅	✅ 128/128
npm			✅	✅ 718/718
PHPUnit					❌
Newman					⏭️
Playwright					✅
Hydra gates					❌

---

Quality workflow — 2026-08-11 23:39 UTC

Download the full PDF report from the workflow artifacts.

[github-actions]

Quality Report — ConductionNL/softwarecatalog @ e74776e

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-manifest		✅
check-vue-demi		✅
test-l10n		✅
composer			✅	✅ 128/128
npm			✅	✅ 718/718
PHPUnit					❌
Newman					⏭️
Playwright					❌
Hydra gates					❌

---

Quality workflow — 2026-08-11 23:52 UTC

Download the full PDF report from the workflow artifacts.

[github-actions]

Quality Report — ConductionNL/softwarecatalog @ 7637d85

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-manifest		✅
check-vue-demi		✅
test-l10n		✅
composer			✅	✅ 128/128
npm			✅	✅ 718/718
PHPUnit					❌
Newman					⏭️
Playwright					❌
Hydra gates					❌

---

Quality workflow — 2026-08-11 23:58 UTC

Download the full PDF report from the workflow artifacts.

[github-actions]

Quality Report — ConductionNL/softwarecatalog @ c74118f

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-manifest		✅
check-vue-demi		✅
test-l10n		✅
composer			✅	✅ 128/128
npm			✅	✅ 718/718
PHPUnit					✅
Newman					⏭️
Playwright					✅
Hydra gates					❌

---

Quality workflow — 2026-08-12 00:15 UTC

Download the full PDF report from the workflow artifacts.

[github-actions]

Quality Report — ConductionNL/softwarecatalog @ fd829aa

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-manifest		✅
check-vue-demi		✅
test-l10n		✅
composer			✅	✅ 128/128
npm			✅	✅ 718/718
PHPUnit					✅
Newman					⏭️
Playwright					✅
Hydra gates					✅

---

Quality workflow — 2026-08-12 07:12 UTC

Download the full PDF report from the workflow artifacts.

[rubenvdlinde]

Holding this one — the migration is not inert, and landing it before the rename inverts its own safety argument

The engineering here is careful and the schema-scoping argument is right. But the premise in "No property is renamed in this PR. The migration lands first" is that a migration without a rename is harmless. It is not. On the current tree it does the rename half without the register half, which is the exact failure this step exists to prevent, mirrored.

The register still declares the Dutch names

Measured on lib/Settings/softwarecatalogus_register.json at this PR's head, reading .components.schemas[].properties (positive control: the same extraction yields 220 distinct property keys, so it is finding things):

schema	declares
sector	naam, beschrijving
suite	naam, beschrijvingKort, beschrijvingLang, contactpersoon
dienst	naam, beschrijvingKort, beschrijvingLang, contactpersoon, publicatiedatum, depublicatiedatum
kwetsbaarheid, koppeling, beoordeeling, module, moduleVersie, organisatie, gebruik, bioMaatregel	the same family

And the destinations this step writes to — short_description, publication_date, depublication_date, contact_person — are declared nowhere in the register. name and description appear only on element, view, model, relation, property-definition, organization, sbomComponent — none of which is an in-scope schema.

What that means the step does today

run() renames precisely when the English column is absent (RenameDutchCatalogColumns.php:201). Absent is the current state for every in-scope schema. So on the next occ maintenance:repair or the next version bump:

1. sector.naam → sector.name, sector.beschrijving → sector.description, and the same across eleven shard tables.
2. The register still declares naam / beschrijving, so on the next schema sync MagicMapper finds naam missing and adds it back, empty.
3. Every read of naam returns null. No error, no data loss reported, invisible to the suites.

That is the file header's own paragraph — "Renaming naam to name in the register therefore leaves the data in naam while every read looks at name and finds null" — with the two halves swapped. Merging the migration first produces the identical symptom from the opposite direction, and it does so on the ~9,500 imported VNG records the description names as the population that was never validated.

Nothing enforces the ordering the code says it needs

appinfo/info.xml states the requirement plainly: "Must run AFTER the register sync that adds the English columns, so it can tell the rename case from the back-fill case." There is no mechanism behind that sentence. The step never reads the schema's declared properties — grep -c properties lib/Repair/RenameDutchCatalogColumns.php returns 0. It cannot distinguish "the register has been renamed and the mapper has not caught up" from "the register has not been renamed at all", and those two states are byte-identical in the column list it inspects.

The back-fill branch is the safe one and it is the branch that fires after the rename lands. The rename branch is the one that fires before. Landing this PR alone arms only the second.

The version is still 0.2.22 on both sides, so the step will not fire on merge. That is the only thing currently standing between this and the outcome above, and a forgotten version bump is not a safety mechanism.

The fix is small, and the sibling already shows it

Gate the rename on the destination actually being declared. The step already resolves the register id and the schema ids; reading each schema's declared properties from oc_openregister_schemas and migrating old → new only when new is a declared property of that schema turns the ordering assumption into a checked precondition. The step then becomes genuinely inert until the rename lands, safe in either merge order, and the description's "the migration lands first" argument becomes true rather than aspirational.

Worth noting the sibling did it the other way: decidesk #467 shipped the property rename and RenameDutchVocabularyColumns in one PR, so its register and its columns move together and the ordering question never arises. Either shape works — one PR, or a guarded step. What does not work is an unguarded step landing first.

Smaller points, none blocking on their own

• information_schema is not scoped to the current database. Both inScopeShardTables() (:298) and columnsOf() (:395) query information_schema filtered only on table_name. On MySQL that view spans every database on the server, so on a shared instance columnsOf() can return another database's column list for a same-named table and run() will act on it. Postgres scopes to the current database, which is why this does not show on the dev rig. Adding AND table_schema = DATABASE() / current_schema() closes it.
• $columns is read once per table (:184) and not refreshed after a rename. Safe today only because the collision guard already refuses the one many-to-one family (description); worth a comment saying so, since it is load-bearing.
• The phpunit.xml exclusion checks out, and I verified rather than assumed: doctrine/dbal is genuinely absent from composer.json, decidesk and portaliq do both exclude lib/Migration/, and this is genuinely the repo's first exclusion (0 on development). One caveat for the record — tests/Unit/Service/OrganizationSyncServiceDecompositionTest.php already references IDBConnection, so the blocker is specifically getDatabasePlatform(): AbstractPlatform, not IDBConnection as such. Narrowing the comment to that would keep the justification true.

What I did not verify

The production population. The description is straight about this and I am not adding to it: the code paths are exercised, the volume and variety are not.