fix(schemas): the keys these seeds write that no schema declares

[rubenvdlinde]

What this fixes

OpenRegister gives a declared property a magic-table column and an undeclared one nothing at all. MagicMapper::prepareObjectDataForTable() is a whitelist by omission: it walks the schema's declared properties and copies those out of the payload, so a key the schema does not declare is never read, and there is no JSON blob column to fall back on. The save answers 200 and the value is gone.

Measured before changing anything

On the live dossiq-proof rig, in one command per side:

	case schema version	properties array	extends-form mode
dossiq source in the container	1.12.0	yes	array
the schema in its database	1.12.0	no	child-record

7882afd added case.properties and f7c9f87 switched the declaration to array mode. Neither bumped the version the importer gates on, so that instance still runs the old declaration against a file that no longer matches it. case goes to 1.13.0, which is the one thing that makes the update unconditional rather than dependent on schemaContentDiffers() as a fallback.

The three VTH checklist templates never installed

The seeds carried a flat items[]; the schema requires sections[]. Every save threw "The required property (sections) is missing", the step logged a warning, carried on, and reported success with zero rows. They are reshaped into sections, type becomes responseType, and photoRequired becomes the enum it was declared as instead of a boolean. caseTypeSlug is the only stable identifier a shipped file can carry, so the step resolves it to the caseType uuid rather than writing a key nothing stores.

Declared vs stopped writing

Property	Verdict	Why
roleType.genericRole	declared	editable from the Roles tab, specified in case-types and admin-settings, shipped by three seed files, discarded on every write
caseType.mandateGuard	removed	no reader anywhere; follows the dossiq#1782 precedent for catalog
caseType.catalog	already gone	dossiq#1782 removed it; the sweep keeps it gone
slug	kept	SaveObject::setSelfMetadata() reads it and stores it on @self, which is where existingSlugs() reads it back
uuid	not allowed	nothing reads it: the uuid comes from the $uuid parameter or from id

Three more families the sweep found

Not in the original report, found by pointing the sweep at every shipped seed:

• extensionDuration where the schema says extensionPeriod, in two seed files.
• type / enum on VTH property definitions where the schema says propertyType / enumValues, 17 sites. integer is not in the propertyType enum either, so those become number.
• Three VTH templates shipped statusTypes, documentTypes and roleTypes as bare strings. seedSubObjects() skips any record that is not an array, so those templates seeded nothing at all while reporting success.

The sweep

SeedPayloadSchemaConformanceTest reads the same merged configuration the installer imports, through the real RegisterFragmentMerger rather than the monolith alone. It checks nested objects as well as top-level keys, and allows only the two keys OpenRegister genuinely consumes.

Its first version passed a mutation that should have failed it: it only compared top-level keys, so a type planted back inside sections[].items[] went unseen. That hole is closed, and the mutation now produces two findings and a red run.

Verified locally

phpunit (138 Settings tests), phpcs, psalm, phpstan, phpmd, check:schema-l10n at baseline, npm run l10n:build, and hydra-gates v1.11.1: all 75 applicable gates passed, and all 75 ran.

🤖 Generated with Claude Code

[github-actions]

Quality Report — ConductionNL/dossiq @ 47a5e78

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-manifest		✅
check-vue3-compile		✅
test-l10n		✅
format		✅
check-schema-l10n		✅
check-l10n-js		✅
composer			✅	✅ 106/106
npm			✅	✅ 540/540
app:check-code	⏭️
info.xml	✅
REUSE	❌
PHPUnit					❌
Newman					⏭️
Playwright					⏭️ deferred — runs on the promotion into beta/main, not on a pull request into development
Hydra gates					✅

---

Quality workflow — 2026-09-03 19:46 UTC

Download the full PDF report from the workflow artifacts.