fix(nav): stop the domain settings page claiming the platform's "Settings"

[rubenvdlinde]

gate-63 (ADR-079) blocks every procest manifest edit, not just one PR. It reports PASS on development only because it skips when the manifest is not in the diff — so the first PR to touch src/manifest.json inherits two failures it did not cause. #758 hit exactly that.

	finding
D1	page Settings is a type:settings page whose id and title claim the platform meaning of Settings, while app configuration belongs at /settings/admin/<app>
D4	a settings-foldout entry labelled Settings inside a foldout button already called Settings — the nav literally renders Settings > Settings

Renamed, not deleted — and the distinction matters

The gate's WARN suggests deleting the in-app page as a duplicate of lib/Settings/AdminSettings.php. It is not a duplicate. CaseTypesMenu routes to this same page, so it hosts the case-type management surface — the one admin-settings.spec.ts asserts renders "its management surface and add control". Deleting it would have removed a live surface to satisfy a lint.

D1's own wording allows the safe remedy: "a domain page that happens to be called settings must be renamed".

page id             Settings -> ProcestConfiguration
page title          Settings -> Configuration
section title       Settings -> Configuration
SettingsMenu label  Settings -> Configuration   (D4)

The route path /settings is deliberately unchanged — it is a bookmarkable URL, the gate keys on id/title rather than path, and pages.spec.ts navigates to it three times.

A page id is its vue-router route name, so the rename had real callers

• src/views/DoorlooptijdDashboard.vue pushed { name: 'Settings' } from the "Go to Settings" empty-state button. Updated — otherwise that button would have navigated nowhere.
• tests/e2e/navigation.spec.ts targets the gear foldout by testid and still passes: the foldout legitimately says "Settings". Its comment warned about colliding with the SettingsMenu entry — which is precisely the collision D4 describes and this PR removes. Comment updated to say so.

Also fixes the gate-45 finding this pulled into scope

Three skeleton loaders in DoorlooptijdDashboard.vue animate indefinitely with no prefers-reduced-motion fallback (WCAG 2.3.3). An indefinite pulse is what someone with vestibular sensitivity sets that preference to avoid. The animation is now dropped under the media query and replaced with a dimmed static state, so a skeleton still reads as "not real data yet" rather than becoming indistinguishable from a loaded card.

Verified

• ALL 59 APPLICABLE GATES GREEN — and all 59 ran.
• check:manifest passes (58 pages, 0 ajv errors).
• gate-63's remaining output is the non-blocking duplicate-home WARN. That stands as a genuine question for the PO — should the in-app configuration screen exist at all? — rather than something to silence by deleting a working screen.

Unblocks #758.

[github-actions]

Quality Report — ConductionNL/procest @ 7d06947

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

---

Quality workflow — 2026-08-07 11:20 UTC

Download the full PDF report from the workflow artifacts.