E2E red on development: Standards index page is bound to a schema its register does not carry (element / voorzieningen vs vng-gemma)

[rubenvdlinde]

Summary

quality / E2E Tests (Playwright) has been red on development since at least
sha 68202d5b. One test fails, and it is a real product bug, not a flaky or
wrong test. quality / Quality Report is red only because it aggregates this.

Escalating rather than patching: the honest fix is a config-ownership
decision about which register owns the GEMMA standards, and it changes CI
provisioning. That is not a call to make inside a CI-clean-up sweep.

The failing test

[chromium] › tests/e2e/spec-coverage/index-pages.spec.ts:141:5 ›
index standards: nav entry reaches the CnIndexPage surface (toggle + add + list body)

1 failed / 3 skipped / 94 passed (11.7m)

Error: softwarecatalog console errors:
Error fetching 14-element collection: Proxy(Object)

expect(received).toEqual(expected)
- Array []
+ Array [ "Error fetching 14-element collection: Proxy(Object)" ]
   at expectNoAppErrors (tests/e2e/spec-coverage/_helpers.ts:84:4)
   at tests/e2e/spec-coverage/index-pages.spec.ts:147:19

Root cause

The page renders correctly — the trace artifact's snapshot shows the heading,
the Cards/Table toggle, "Add Element" and a No items found note. All three
surface assertions pass. The only failure is expectNoAppErrors.

The console error comes from nc-vue's object store
(src/store/useObjectStore.js:576). The key 14-element is register id 14
(the resolved voorzieningen register) + schema slug element. The fetch to
/apps/openregister/api/objects/14/element fails because element is not
attached to that register:

• lib/Settings/softwarecatalogus_register.json →
  components.registers.voorzieningen.schemas holds 15 schemas — sector, suite,
  module, service, vulnerability, contactPerson, organization, usage, contract,
  connection, assessment, compliancy, moduleVersion, sbomComponent, bioMeasure —
  and no element.
• element lives under components.registers.vng-gemma.schemas (with model,
  property-definition, relation, view).
• src/manifest.json, page Standaarden (/standaarden, type index) is
  configured {"register": "@resolve:voorzieningen_register", "schema": "element"}
  — a schema addressed under a register that does not carry it.
• @resolve:voorzieningen_register is the only sentinel in the manifest (34
  uses), and tests/e2e/ci-seed.sh:116 seeds 'registers': ['voorzieningen']
  only, so vng-gemma is never provisioned in CI at all.

User impact: the Standards page shows "No items found" where a failed fetch
actually occurred — an error rendered as an empty state.

Why the obvious fixes are wrong

• ❌ Adding element to registers.voorzieningen.schemas turns a visible
  error into a genuinely empty list — an invisible pass. The GEMMA elements
  were imported under vng-gemma; they would not appear.
• ❌ Repairing the noise filter. _helpers.ts:54 carries
  /Error fetching element collection/i, which does not match the real
  message because the store key is prefixed with the register id (14-element).
  That filter is dead in its current shape — and it must stay dead. Making it
  match would turn this real bug into a silent pass. Flagging it here so nobody
  "fixes" it later without realising what it suppresses.
• ❌ Skipping, relaxing, raising the timeout, or excluding the route.

The actual fix (needs a decision)

A second @resolve: sentinel pointing at the register that holds the GEMMA data,
the Standaarden page repointed at it, and ci-seed.sh extended to provision
that register. Which register owns GEMMA standards is a product decision —
hence this issue.

Provenance

• Pre-existing, not a regression from 68202d5b. That commit touched
  softwarecatalogus_register.json only for schema version bumps and Dutch to
  English enum defaults, nothing near the element binding.
• Both the push run and the pull_request run of the same sha fail on the same
  test, same file:line, same assertion — 98 test-identity lines, diff clean.
  So this is deterministic, not flake.
• The spec's own docblock (index-pages.spec.ts:92-140) already diagnoses this
  and explicitly says not to re-skip it. The test is correct.

Two side findings from the same logs

1. The coverage row is silently missing from every Quality Report, fleet-wide.
   In ConductionNL/.github quality.yml, TOTAL_STMTS=$(grep -oPm1 'statements="\K[0-9]+' coverage/clover.xml || echo "0") returns a
   multi-line value (-o prints every match on the matched line), so
   [ "$TOTAL_STMTS" -gt 0 ] errors with [: 512\n0: integer expression expected and the Coverage line is dropped. A measurement that quietly does
   not happen. Worth its own issue on .github.
2. quality / Hydra Gates disagreeing across the push/PR pair on this sha is
   structural, not flake. gate-16 (spec-coverage) is diff-scoped: the push run
   gets github.event.before (11 changed files, PASS) while the PR run gets
   origin/beta (736 changed files, FAIL on inherited @spec debt). Same
   sha, different subject — a rerun cannot change it. The 11 methods missing
   @spec were not introduced by this sha.