fix(e2e): the Organisations index filtered on values #520 deleted, and the SBOM provenance line read a name that no longer existed

[rubenvdlinde]

Five of the six E2E failures on development came from two renames that moved
one half of a pair and left the other behind. Neither raised an error, which is
why both survived: one produced an empty list, the other produced an element
that never rendered.

1. THE ORGANISATIONS INDEX WAS EMPTY FOR EVERY USER.
   src/manifest.json's Organisaties page filtered on
   status: ["Concept", "Actief", "Deactief"]. refactor(softwarecatalog): translate the stored enum values, and migrate them #520 translated that enum to
   Draft/Active/Inactive/merged and migrated the stored rows, but not this
   filter — so the page filtered on three values no row can hold. OpenRegister
   answers such a filter 200 {"total": 0}, so the index rendered
   "No items found" and read as an empty catalogue: no console error, no failed
   request, nothing in the log.

   Measured on a running instance, positive and negative control:
   ?status[]=Draft&status[]=Active -> total 1 (the seeded row)
   ?status[]=Concept&status[]=Actief&... -> total 0
   and reproduced in the browser: one organisation exists, the index shows
   "No items found".

   The same commit missed organization.status's default ("Concept", not a
   member of its own enum, so every newly created organisation lands outside
   this filter) and the whole x-openregister-lifecycle block, whose
   initial, final and every from/to still named the Dutch values — a
   lifecycle whose transitions match no row simply offers nothing. Both are
   fixed here, with the schema version bumped: a deployed version >= the
   declared one makes the import SKIP, and OpenRegister's
   schemaContentDiffers() escape hatch compares only properties/required/
   authorization — never configuration — so a lifecycle-only edit would never
   have deployed.

2. THE SBOM PROVENANCE LINE COULD NEVER RENDER.
   SbomComponentsPanel's producer computed is moduleVersie(); when the
   schema slug was translated the CONSUMER was renamed to this.moduleVersion
   and the producer was not. Vue resolves the unknown property to undefined,
   moduleVersionData returned {}, and every derived value went empty:
   lastImportedLabel returned '' so the v-if-gated
   data-testid="sbom-provenance" never mounted, and parentModuleId returned
   '' so the vulnerability-match heuristic ran with an empty scope. "No import
   yet" is a legitimate state, so the broken build was indistinguishable from an
   unimported module version.

3. Three e2e tests asserted a surface the product stopped rendering. Organisations
   was decomposed from a bespoke type: custom OrganisatieIndexView to a
   standard type: index page; the tests still looked for that view's
   "Add organisation" button and its "No organisations" empty state. The empty-
   state assertion was the worse half: toHaveCount(0) against a string nothing
   renders passes unconditionally, so the guard meant to catch an empty list said
   nothing while the list really was empty. They now assert the CnIndexPage
   surface — heading, Cards/Table toggle, create action, list body — which is
   strictly more than before.

4. gemma-faceted-search still named the pre-refactor(softwarecatalog): translate eight schema slugs, and migrate them #518 Dutch slug dienst in three
   places: the message assertion, the 200 control, and a
   supportedSchemas.sort() compared against an UNSORTED literal, which could
   not have held for any naming.

5. index-pages' "index standards" test.fixme claimed "blocked: missing
   standaard schema". The page is bound to "schema": "element", which the CI
   seed enumerates among the 36 schemas present, and a running instance renders
   the index with an "Add Element" action and no app-origin error. A skip whose
   reason has stopped being true reads exactly like a passing test, so it is put
   back to work rather than re-worded.

BEFORE / AFTER (local, same command both sides)

tests/vitest/sbomProvenanceLabel.spec.js (new, 4 tests)
on HEAD: 2 failed / 2 passed (both failures are the defect; both passes
are the negative controls, so the
assertions discriminate)
after: 4 passed / 0 failed

tests/vitest/manifestFilterEnumParity.spec.js (new, 3 tests)
on HEAD: 1 failed / 2 passed — reporting exactly the three stale filter
values, with its positive control passing on both sides
after: 3 passed / 0 failed

full vitest suite, run from git archive HEAD with the same node_modules:
HEAD: 22 files, 21 passed / 1 failed, 226 tests passed
branch: 23 files, 22 passed / 1 failed, 230 tests passed
The one failing file is adminApi.spec.js (ReferenceError: window is not defined); it fails identically on pristine HEAD and this change does not
touch it or anything it imports.

eslint on the changed component: clean.
node tests/validate-manifest.js: PASS (0 errors), 29 pages, schema 2.22.0.

FILES MEASURED: 11 changed (2 config/JSON, 1 component, 5 e2e specs + 1 e2e
helper, 2 new vitest specs + 1 stub).

NOT DONE, DELIBERATELY — recorded on the fleet board:

• Five more schemas carry the same refactor(softwarecatalog): translate the stored enum values, and migrate them #520 miss: usage.status default
  'In productie', connection.status and moduleVersion.status default
  'in gebruik', module.type default 'Applicatie',
  connection.integrationType default template emitting 'extern'/'intern' —
  every one outside its own enum — plus four more Dutch
  x-openregister-lifecycle blocks (usage 'Verwerving', contract
  'In onderhandeling', connection and moduleVersion 'in ontwikkeling'). They
  are the same class of bug on surfaces this change does not measure, so they
  belong to whoever owns refactor(softwarecatalog): translate the stored enum values, and migrate them #520 rather than to an E2E repair.
• The schema title is authored "Organization" while every other string in the
  app is British, and a deployed instance can still serve the older
  "Organisation" because a title change never redeploys. Rather than rename a
  schema title from an E2E fix, the affected assertions accept either spelling
  of that one word.
• organisatie-crud's UI-create test.fixme is NOT re-enabled. Its stated
  reason (an ObjectModal Catalogus cascade) describes a removed surface, so
  the reason is corrected to "unverified" rather than restated — the body has
  never been re-authored against the dialog that replaced it, and guessing
  which fields that dialog exposes is exactly the kind of assertion that
  passes without testing anything.

[github-actions]

Quality Report — ConductionNL/softwarecatalog @ 7a22545

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-manifest		✅
check-vue-demi		✅
test-l10n		✅
format		❌
composer			✅	✅ 130/130
npm			✅	✅ 704/704
app:check-code	⏭️
info.xml	✅
REUSE	❌
PHPUnit					✅
Newman					⏭️
Playwright					❌
Hydra gates					❌

---

Quality workflow — 2026-08-16 23:21 UTC

Download the full PDF report from the workflow artifacts.

[github-actions]

Quality Report — ConductionNL/softwarecatalog @ b07e758

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-manifest		✅
check-vue-demi		✅
test-l10n		✅
format		❌
composer			✅	✅ 130/130
npm			✅	✅ 704/704
app:check-code	⏭️
info.xml	✅
REUSE	❌
PHPUnit					❌
Newman					⏭️
Playwright					❌
Hydra gates					❌

---

Quality workflow — 2026-08-16 23:25 UTC

Download the full PDF report from the workflow artifacts.

[github-actions]

Quality Report — ConductionNL/softwarecatalog @ 7993a3e

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-manifest		✅
check-vue-demi		✅
test-l10n		✅
format		✅
composer			✅	✅ 130/130
npm			✅	✅ 704/704
app:check-code	⏭️
info.xml	✅
REUSE	❌
PHPUnit					✅
Newman					⏭️
Playwright					❌
Hydra gates					❌

---

Quality workflow — 2026-08-16 23:42 UTC

Download the full PDF report from the workflow artifacts.