Skip to content

gate-26/gate-25: two of the three uncovered 'page components' are dead, and gate-25's Newman route is switched off by design #478

Description

@rubenvdlinde

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions