Analysis of the two remaining coverage gates on the full-scope dispatch (run 31416892690), so the work is not mistaken for "write three more tests".
gate-26 visual-coverage — 3 findings, only 1 is a real page
src/views/LifecycleRoadmapView.vue
src/views/gemmaviews/GemmaViewIndex.vue
src/views/organisaties/OrganisatieIndex.vue
src/customComponents.js is the component registry for type: "custom" manifest pages. Measured against it and against src/manifest.json + src/manifest.d/:
| component |
registered? |
manifest ref? |
other refs in src/ |
LifecycleRoadmapView |
yes (line 23) |
yes — page id LifecycleRoadmap, type: custom |
10 |
GemmaViewIndex |
no |
no |
0 |
OrganisatieIndex |
no |
no |
0 (only its own name: and passing mentions in comments) |
GemmaViewIndex.vue is a superseded orphan
It is the only file in src/views/gemmaviews/. The gemma-faceted-search capability is live, but through FacetedCatalogIndexView — that is what customComponents.js registers and what src/manifest.json _notes at lines 383 and 438 describe. GemmaViewIndex is referenced nowhere outside an archived change (2026-06-14-deelnames-gebruik). Nothing can route to it.
OrganisatieIndex.vue is superseded too, but the record still claims otherwise
src/manifest.json:186 _note records the supersession explicitly: "Decomposed from the bespoke OrganisatieIndexView to a standard type:index (Phase 8): renders organisatie OR objects as a card grid via config.cardComponent=OrganisatieCard." There is no OrganisatieIndexView.vue on disk and no registration of OrganisatieIndex.
But two live documents still describe it as the working surface, so it must not simply be deleted:
openspec/specs/application-lifecycle-tracking/spec.md:95 — a canonical spec: "Gebruik editing … goes through the OrganisatieIndex custom view's data layer."
openspec/changes/adopt-live-updates-ui/ — an active, unarchived change that lists OrganisatieIndex among the views subscribing to live updates.
Deleting the component silently invalidates both. Deciding whether the spec sentence is stale (and the in-flight change should drop the view) is a product call, not a gate fix.
Suggested resolution: delete GemmaViewIndex.vue as dead code; separately decide OrganisatieIndex.vue's fate together with adopt-live-updates-ui and the application-lifecycle-tracking sentence; and give LifecycleRoadmapView genuine coverage — a navigation test in tests/e2e/manifest-pages.spec.ts (which already drives manifest pages by hash route and carries // @e2e <spec>::<slug> annotations) is the established pattern here.
gate-25 contract-coverage — 41 endpoints, and the Newman route is deliberately closed
gate-25 accepts three proofs: a Postman request under tests/integration/, a PHPUnit controller test under tests/, or a reason-bearing @contract exclude.
The Postman route is not available in practice. .github/workflows/code-quality.yml sets enable-newman: false, and the comment block at lines 117-133 records why: the collection's requests hard-code /var/www/html/custom_apps/openregister/... paths that do not exist on a CI runner, and it assumes a seeded voorzieningen register / module schema.
That matters for how this gate gets closed. tests/integration/softwarecatalog.postman_collection.json exists, so adding requests to it would satisfy gate-25's file-based check while the Integration Tests (Newman) job continues to report skipping — a gate turning green over a suite that never executes. That is the exact failure mode the gate exists to prevent, so it should not be the route taken.
Suggested resolution: either (a) close the 41 with real PHPUnit controller tests, or (b) first do the collection rewrite the workflow comment already scopes ("flipped back on in the commit that rewrites the collection to the CI base_url and adds the seed step") and then extend the collection. Not (c) extend a collection nothing runs.
Same comment block also flags a live hazard worth keeping: the validator counts collections recursively while the run step globs them flat, so a newman-collection-path that satisfies validation can still run nothing.
Analysis of the two remaining coverage gates on the full-scope dispatch (run 31416892690), so the work is not mistaken for "write three more tests".
gate-26 visual-coverage — 3 findings, only 1 is a real page
src/customComponents.jsis the component registry fortype: "custom"manifest pages. Measured against it and againstsrc/manifest.json+src/manifest.d/:src/LifecycleRoadmapViewLifecycleRoadmap,type: customGemmaViewIndexOrganisatieIndexname:and passing mentions in comments)GemmaViewIndex.vueis a superseded orphanIt is the only file in
src/views/gemmaviews/. Thegemma-faceted-searchcapability is live, but throughFacetedCatalogIndexView— that is whatcustomComponents.jsregisters and whatsrc/manifest.json_notes at lines 383 and 438 describe.GemmaViewIndexis referenced nowhere outside an archived change (2026-06-14-deelnames-gebruik). Nothing can route to it.OrganisatieIndex.vueis superseded too, but the record still claims otherwisesrc/manifest.json:186_noterecords the supersession explicitly: "Decomposed from the bespoke OrganisatieIndexView to a standard type:index (Phase 8): renders organisatie OR objects as a card grid via config.cardComponent=OrganisatieCard." There is noOrganisatieIndexView.vueon disk and no registration ofOrganisatieIndex.But two live documents still describe it as the working surface, so it must not simply be deleted:
openspec/specs/application-lifecycle-tracking/spec.md:95— a canonical spec: "Gebruik editing … goes through the OrganisatieIndex custom view's data layer."openspec/changes/adopt-live-updates-ui/— an active, unarchived change that listsOrganisatieIndexamong the views subscribing to live updates.Deleting the component silently invalidates both. Deciding whether the spec sentence is stale (and the in-flight change should drop the view) is a product call, not a gate fix.
Suggested resolution: delete
GemmaViewIndex.vueas dead code; separately decideOrganisatieIndex.vue's fate together withadopt-live-updates-uiand theapplication-lifecycle-trackingsentence; and giveLifecycleRoadmapViewgenuine coverage — a navigation test intests/e2e/manifest-pages.spec.ts(which already drives manifest pages by hash route and carries// @e2e <spec>::<slug>annotations) is the established pattern here.gate-25 contract-coverage — 41 endpoints, and the Newman route is deliberately closed
gate-25 accepts three proofs: a Postman request under
tests/integration/, a PHPUnit controller test undertests/, or a reason-bearing@contract exclude.The Postman route is not available in practice.
.github/workflows/code-quality.ymlsetsenable-newman: false, and the comment block at lines 117-133 records why: the collection's requests hard-code/var/www/html/custom_apps/openregister/...paths that do not exist on a CI runner, and it assumes a seededvoorzieningenregister /moduleschema.That matters for how this gate gets closed.
tests/integration/softwarecatalog.postman_collection.jsonexists, so adding requests to it would satisfy gate-25's file-based check while theIntegration Tests (Newman)job continues to reportskipping— a gate turning green over a suite that never executes. That is the exact failure mode the gate exists to prevent, so it should not be the route taken.Suggested resolution: either (a) close the 41 with real PHPUnit controller tests, or (b) first do the collection rewrite the workflow comment already scopes ("flipped back on in the commit that rewrites the collection to the CI base_url and adds the seed step") and then extend the collection. Not (c) extend a collection nothing runs.
Same comment block also flags a live hazard worth keeping: the validator counts collections recursively while the run step globs them flat, so a
newman-collection-paththat satisfies validation can still run nothing.