Three gates fail on development and have done for some time. Surfaced while landing #732 — none is caused by that PR, and all three are visible on the development baseline run.
gate-5 route-auth
lib/Controller/CredentialVerifyController.php:85 method=verify rule=missing-auth-attribute
4 routed methods carry no auth attribute. Per the gate's own rationale, a missing #[PublicPage] / #[NoAdminRequired] / #[NoCSRFRequired] doesn't just skip a check — NC middleware rejects the request before the controller runs, so the endpoint is silently unreachable.
gate-62 store-plane (ADR-080)
FAIL lib/Service/WooPublication/OpenCatalogiApiClient.php: builds and fetches an
OpenRegister objects-API URL outside GenericStoreService — store discovery is
OpenRegister's (ADR-080 D2/D3)
gate-63 settings-surface (ADR-079)
FAIL src/manifest.json: page 'Settings' is a type:settings page claiming the
platform meaning of 'Settings'
FAIL src/manifest.json: settings-foldout entry is labelled 'Settings' — renders
Settings > Settings
WARN src/manifest.json: app ships an in-app type:settings page AND a
lib/Settings/*Admin.php section — two homes for one concern
This one needs a decision, not just a fix. The page at /settings is genuine app configuration ("Register and schema settings"), and ADR-079 D1 says that belongs at /settings/admin/<app> — i.e. the remedy is to delete the in-app page. That removes a surface admins currently use to configure register/schema, so it wants review rather than a quiet cleanup.
Blast radius is small if it goes ahead: only two references to the Settings route name (DoorlooptijdDashboard.vue:74 and the view itself), plus two menu entries pointing at the same page (CaseTypesMenu labelled "Case types" and SettingsMenu labelled "Settings" — which is where the Settings > Settings duplication comes from).
Filed rather than fixed overnight: deleting an admin configuration UI is user-visible and outward-facing, and was not part of the change that surfaced it.
Three gates fail on
developmentand have done for some time. Surfaced while landing #732 — none is caused by that PR, and all three are visible on the development baseline run.gate-5 route-auth
4 routed methods carry no auth attribute. Per the gate's own rationale, a missing
#[PublicPage]/#[NoAdminRequired]/#[NoCSRFRequired]doesn't just skip a check — NC middleware rejects the request before the controller runs, so the endpoint is silently unreachable.gate-62 store-plane (ADR-080)
gate-63 settings-surface (ADR-079)
This one needs a decision, not just a fix. The page at
/settingsis genuine app configuration ("Register and schema settings"), and ADR-079 D1 says that belongs at/settings/admin/<app>— i.e. the remedy is to delete the in-app page. That removes a surface admins currently use to configure register/schema, so it wants review rather than a quiet cleanup.Blast radius is small if it goes ahead: only two references to the
Settingsroute name (DoorlooptijdDashboard.vue:74and the view itself), plus two menu entries pointing at the same page (CaseTypesMenulabelled "Case types" andSettingsMenulabelled "Settings" — which is where the Settings > Settings duplication comes from).