fix(demo): demo data for the nine bare schemas that reads like a caseload

[rubenvdlinde]

What this changes

b321005 closed gate-101 by taking the generator's output for the nine schemas that had no demo data. The gate is green, and this is what it put in front of somebody who installs the demo dataset:

field	what ships today
stufEndpoint.municipalityCode	Voorbeeld Munici (truncated at maxLength: 16)
stufEndpoint.endpointUrl	https://example.invalid/resource/0
fieldInspection.caseRef	Voorbeeld Caseref 1
samenwerkverzoek.caseId	00000000-0000-4000-8000-000000000000

A gemeente code reading Voorbeeld Munici is not a demo of a StUF connection. The generator derives every value from the schema, which is exactly right for proving an object validates and no help at all in showing what a feature is for. These 27 objects are written by hand instead, and every reference in them points at something the app actually ships.

The nine, and the verdict on each

All nine are real. Each is named by a shipped spec and read by shipped code, so none is a schema to delete rather than populate. gate-101 has no waiver channel, so there was no honest exclusion to record either.

schema	verdict
fieldInspection	Demo data. Three inspections across two cases, one per offline lifecycle state.
checklistResult	Demo data. One result per inspection, answers taken from the shipped checklist templates.
fieldEvidence	Demo data. A photo, a voice memo with its transcription, and a sketch still waiting to upload.
syncQueue	Demo data. Infrastructure, but the queue is a screen: pending, syncing, and one in conflict.
conflictRecord	Demo data. One unresolved conflict is what the resolution UI needs to have anything to show.
stufEndpoint	Demo data. Two live endpoints and one retired, the transition scenario the schema names.
stufMessage	Demo data. Real SOAP envelopes: an Lk01, its Bv01, and an Lk02 that came back Fo02.
zaaksysteemMapping	Demo data. Two case mappings and a contact mapping, one of each sync state.
samenwerkverzoek	Was never bare. See below.

The story the data tells

A toezichtzaak-bouw at Zonnehof 12 in Amersfoort runs through the three inspection checklists vth_seed_data.json actually ships. The fundering round synced. The ruwbouw round collided with a colleague's answer, so it carries a queued mutation in conflict and an unresolved conflictRecord pointing at it. A second case on the Amsterdamseweg is still in progress with an upload waiting to go out.

Amersfoort runs Key2Zaken and Mozard side by side during a migration, with a retired Decos JOIN endpoint on actief: false. The message log holds a creeerZaak Lk01, the Bv01 that confirmed it, and an actualiseerZaak Lk02 that came back Fo02 and is waiting on a retry.

The checklist template slugs are the ones VthSeedDataRepairStep imports. The case type slugs are the ones vth_seed_data.json declares. Objects inside each cluster reference each other by @self.slug.

One of the nine was never bare, and the fix doubled it

samenwerkverzoek already had three good demo objects, in register.d/dso-omgevingsloket.json, which the app imports on install. gate-101 could not see them because it only counts objects in a descriptor marked x-openregister.type: mock.

Measured on a throwaway instance against development: importing the demo dataset produced six samenwerkverzoeken, the fragment's three plus three Voorbeeld Initiatorcompetentauthority.

Gemeente Amsterdam  | Waterschap Amstel, Gooi en Vecht    | accepted
Gemeente Rotterdam  | Provincie Zuid-Holland              | requested
Gemeente Utrecht    | Rijkswaterstaat                     | refused
Voorbeeld Initiat.. | Voorbeeld Requestedcompetentauth..  | requested
Voorbeeld Initiat.. | Voorbeeld Requestedcompetentauth..  | accepted
Voorbeeld Initiat.. | Voorbeeld Requestedcompetentauth..  | refused

The demo dataset now carries the fragment's three verbatim, slugs included, so the import updates the rows it already wrote instead of doubling them.

Two things a reviewer will ask about

Two conflictRecord rows name a syncQueue slug this file does not carry. That is the shape of the thing. The spec dismisses successful queue entries after seven days, and both of those conflicts are resolved and older than the ones still queued. A conflict log outlives its queue.

samenwerkverzoek.caseId stays unset. It is a uuid $ref to a case, and a static demo file cannot know the uuid a case gets at import, so the generator's zero uuid names nothing.

Proof

Not on the file. On a throwaway instance (dossiq 0.3.12-unstable.20260903174414, openregister 2.0.15-unstable.20260903172438, its own compose project and port) the nine magic tables were emptied, the demo dataset was imported over the same setup action the walkthrough calls, and every one of the nine came back with exactly three rows carrying these values:

checklistResult|3      stufEndpoint|3
conflictRecord|3       stufMessage|3
fieldEvidence|3        syncQueue|3
fieldInspection|3      zaaksysteemMapping|3
samenwerkverzoek|3

2026-0431 Nieuwbouw 24 appartementen Zonnehof 12 | bouwtoezicht-fase-1-fundering | synced
2026-0431 Nieuwbouw 24 appartementen Zonnehof 12 | bouwtoezicht-fase-2-ruwbouw   | conflict
2026-0448 Uitbreiding bedrijfshal Amsterdamseweg 41 | bouwtoezicht-fase-1-fundering | in_progress

stuf-ep-amersfoort-key2zaken  | Key2Zaken productie    | 0307 | actief
stuf-ep-amersfoort-mozard     | Mozard acceptatie      | 0307 | actief
stuf-ep-amersfoort-decos-join | Decos JOIN, uitgefaseerd | 0307 | inactief

Importing a second time left it at three, so the dataset is idempotent against itself.

Checks

• hydra-gates v1.11.1, full tree, base origin/development: 78 of 78 applicable gates ran, 0 failures. gate-101 demo-data-coverage: PASS.
• generate_mock_register.py . --check full tree: checked 152 schema(s), exit 0.
• npm run check:schema-l10n: 2825 uncovered, baseline 2825. No schema definitions moved, so no l10n key moves.
• npm run test:unit: 359 passed.
• composer test:unit: 3006 tests, 1 failure, StubApiDriftTest::FlowResumeState::storableWhen(). Pre-existing and reproduces on development; this change touches one JSON file and no PHP.

Only components.objects changed. components.schemas, components.registers, x-openregister and paths are byte-identical to development, and every object outside the nine schemas is untouched.

🤖 Generated with Claude Code

[github-actions]

Quality Report — ConductionNL/dossiq @ 44799c8

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 18:37 UTC

Download the full PDF report from the workflow artifacts.