fix(dossier): address the schemas by slug — all five lookups 404'd

[rubenvdlinde]

Closes the last e2e failure on development, and it was not what I first said it was.

The bug

OpenRegister resolves a schema identifier by slugifying it and matching the slug. DossierNote slugifies to dossiernote; the declared slug is dossier-note.

Every one of the five schemas PupilDossierTimelineView.loadAll() requests is multi-word, so every one of them 404'd. The timeline could never populate for any learner.

Measured against a live instance:

request	result
.../objects/learniq/DossierNote	404
.../objects/learniq/dossier-note	200
.../objects/learniq/BehaviourIncident	404
.../objects/learniq/behaviour-incident	200

All five corrected slugs verified 200.

Why it looks fine elsewhere

A single-word title hides it. Course slugifies to course and happens to resolve, so the same PascalCase pattern reads as correct throughout the app. It only breaks where a title has two words.

A sweep of src/ found six such names. Five are here; the sixth is ExemptionCase in ExamCaseDossierView, which is already fixed — that view carries a detailed warning from when the identical bug was found there, with the same live measurements:

⚠️ ADDRESS THE SCHEMA BY ITS SLUG, NEVER BY ITS TITLE. … A single-word title hides this — Item slugifies to item and happens to resolve — which is why the same pattern looks fine elsewhere.

This is that same defect in the one view nobody had reached yet. The warning is now repeated here so the next person does not have to rediscover it a third time.

How it surfaced, and a correction

#610 made the e2e suite navigate honestly. #618 then quieted 404s in three views but deliberately left PupilDossierTimelineView loud, because its calls are list queries where absence is 200 + [] and a 404 means the schema did not resolve.

That decision is what found this. The remaining failure was a true report, and this is what it was reporting.

I initially mis-attributed it in #620 to the learniq register being absent during seeding, based on [RegisterMapper] Register does not exist … identifier=learniq in the CI server log. That log line is real, but it is a separate seed-time event and not the cause of this 404. #620 is corrected accordingly.

Verification

node --check on the extracted <script> block, and all five slugs confirmed 200 against a running instance before committing.

[github-actions]

Quality Report — ConductionNL/learniq @ 12d4c91

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-specs		✅
format		✅
check-l10n-js		✅
check-schema-l10n		✅
composer			✅	✅ 104/104
npm			✅	✅ 650/650
app:check-code	⏭️
info.xml	✅
REUSE	❌
PHPUnit					✅
Newman					⏭️
Playwright					✅
Hydra gates					❌

---

Quality workflow — 2026-08-26 14:38 UTC

Download the full PDF report from the workflow artifacts.

[github-actions]

Quality Report — ConductionNL/learniq @ 844cc67

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-specs		✅
format		✅
check-l10n-js		✅
check-schema-l10n		✅
composer			✅	✅ 104/104
npm			✅	✅ 650/650
app:check-code	⏭️
info.xml	✅
REUSE	❌
PHPUnit					✅
Newman					⏭️
Playwright					✅
Hydra gates					✅

---

Quality workflow — 2026-08-26 22:49 UTC

Download the full PDF report from the workflow artifacts.