From e5922f8dd649132f7bb12d090c650a70da7ecfb1 Mon Sep 17 00:00:00 2001
From: Ruben van der Linde <rubenvdlinde@gmail.com>
Date: Sat, 8 Aug 2026 13:09:19 +0200
Subject: [PATCH 1/2] fix(a11y): four widget icons rendered the wrong glyph,
 three controls were keyboard-dead
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Full-tree measurement of origin/development with the hydra-gates runner
from ConductionNL/.github@main. Four gates, eleven findings, all real —
plus two gates whose findings are false positives and are reported
rather than "fixed".

GATE-55 — FOUR WIDGET ICONS THAT DO NOT EXIST (detail-page-discipline).

  ModuleDetail.md-files    BookOpenVariantOutline -> BookOpenVariant
  ModuleDetail.md-versions ViewModule             -> SourceBranch
  SuiteDetail.suite-data   PackageVariant         -> Package
  BioMaatregelDetail.bm-data ShieldLockOutline    -> ShieldCheckOutline

CnWidgetGrid's resolveWidgetIcon() falls back to DEFAULT_ICON —
'ViewDashboard' — for any name not in its registry, so these four widgets
rendered a generic dashboard glyph. Silently: no console warning, no
build error, and `check:manifest` passes because the schema types `icon`
as a string.

Verified against the REAL registry, not the gate's copy of it.
hydra-gates gate-55 carries a hardcoded mirror and says so in its own
comments; a mirror is only as fresh as its last manual edit and fails in
both directions. Read from
node_modules/@conduction/nextcloud-vue/src/components/CnWidgetGrid/widgetIcons.js
at the pinned 2.2.0-vue3.3: all four flagged names are absent, and
`git log -S` over that file shows none of them was ever present. The
replacements are the nearest true members of the same glyph family.

GATE-32 — THREE CONTROLS NO KEYBOARD CAN REACH (semantic-controls).

  EmailConfiguration  the template-variable tags: a clickable <span> that
                      inserts a variable into the editor. Now a real
                      <button type="button">, with the UA chrome reset in
                      CSS so the rendering is unchanged.
  MergeObject         the merge-target rows: a click-only <div> choosing
                      which object survives a merge — the consequential
                      decision in that dialog. Now role="option" +
                      tabindex + Enter/Space, inside a role="listbox"
                      parent so the selected state reaches a screen
                      reader.
  OrganisatieCard     the whole card navigates to the organisation. Now
                      role="button" + tabindex + Enter/Space; the nested
                      .cardHeaderActions already stops propagation, so
                      the NcActions menu is unaffected.

GATE-39 — TWO ICON-ONLY BUTTONS WITH NO ACCESSIBLE NAME (button-name).

ViewObject's "cancel label editing" button sits directly beside a "save
labels" button that already carries an :aria-label — the sibling gave the
exact pattern. ArchiMateImportExport's error-details close button had
none either. v-tooltip is not an accessible name.

GATE-58 — TWO networkidle WAITS IN E2E (e2e-networkidle).

Nextcloud keeps long-lived connections open, so `waitUntil: 'networkidle'`
never settles; it can only time out or be satisfied by luck (ADR-074
rule 4). Both call sites already assert on a heading immediately
afterwards, which is the real readiness signal, so the wait was doing no
work it could reliably do. A third site in the same file already had the
right value and the comment explaining why.

Full-tree after: gate-32, gate-39, gate-55 and gate-58 all PASS.

EVIDENCE. tests/vitest/manifestWidgetIcons.spec.js asserts every widget
icon in src/manifest.json against the registry parsed out of the
installed dependency. Reverting src/manifest.json makes it name all four
sites by page and widget id.

It carries two positive controls on its INPUTS, and the second one earned
its place immediately: the first version of the manifest walker assumed
`page.widgets`, but widgets live under `config.widgets` and nested arrays
at a depth that varies by page type. It collected ZERO icons — and would
have reported a clean tree forever. The "finds widget icons to check"
control failed and caught it before the real assertion could pass
vacuously.

TWO FINDINGS DELIBERATELY NOT "FIXED", because the code is already right:

gate-12 (nc-input-labels, 2) is a false positive. Both <NcSelect> tags in
EmailConfiguration.vue DO carry input-label — "Transport Type" and
"Encryption". The gate extracts the tag with `grep -oE '<NcSelect[^>]*>'`,
and `[^>]*` stops at the first `>`, which is the arrow in
`:reduce="option => option.value"`. The extracted "tag" therefore ends
before input-label can appear. Same shape as the gate-9 admin rule's
`[^)]*` (.github#198). Filed upstream.

gate-38 (skip-link, 1) is a false positive. templates/settings/admin.php
is a Nextcloud admin-settings section, registered via
lib/Settings/SoftwareCatalogAdmin.php and rendered INSIDE core's settings
frame, which already provides the skip link and the <NcContent> shell.
It is not a root component; adding a second skip target would be a
regression. Filed upstream.

Also measured, and worth knowing: gate-32's remaining three findings
after the fix were matching the explanatory COMMENTS this commit added,
because those comments contained the literal text of the markup they
describe. Rewording them to prose cleared the gate — confirming the
mechanism. Filed upstream too; the same class as .github#184.

Checks: eslint 0 errors, stylelint 0 errors, check:manifest Ajv PASS,
vitest 213 green (210 before, 3 added).
---
 src/components/cards/OrganisatieCard.vue      |  13 +-
 src/manifest.json                             |   8 +-
 src/modals/object/MergeObject.vue             |  17 ++-
 src/modals/object/ViewObject.vue              |   1 +
 .../sections/ArchiMateImportExport.vue        |   1 +
 .../settings/sections/EmailConfiguration.vue  |  15 +-
 tests/e2e/org-archimate-export.spec.ts        |   7 +-
 .../e2e/workflows/org-export-workflow.spec.ts |   7 +-
 tests/vitest/manifestWidgetIcons.spec.js      | 144 ++++++++++++++++++
 9 files changed, 202 insertions(+), 11 deletions(-)
 create mode 100644 tests/vitest/manifestWidgetIcons.spec.js

diff --git a/src/components/cards/OrganisatieCard.vue b/src/components/cards/OrganisatieCard.vue
index 5e18ba2f..771e784a 100644
--- a/src/components/cards/OrganisatieCard.vue
+++ b/src/components/cards/OrganisatieCard.vue
@@ -11,7 +11,18 @@
  */
 
 <template>
-	<div class="organisatieCard" @click="handleCardClick">
+	<!-- role/tabindex/keydown rather than a click-only div: the whole card
+	     navigates to the organisation detail page, so it is the primary control
+	     in this component and a keyboard user could not activate it at all
+	     (WCAG 2.1.1). The nested .cardHeaderActions already stops propagation,
+	     so the NcActions menu is unaffected. -->
+	<div class="organisatieCard"
+		role="button"
+		tabindex="0"
+		:aria-label="`Open ${getOrganisatieTitle(item)}`"
+		@click="handleCardClick"
+		@keydown.enter.prevent="handleCardClick"
+		@keydown.space.prevent="handleCardClick">
 		<div class="cardHeader">
 			<h2 v-tooltip.bottom="getOrganisatieSummary(item)">
 				<component :is="cardIcon" :size="20" />
diff --git a/src/manifest.json b/src/manifest.json
index fb91c318..f162c430 100644
--- a/src/manifest.json
+++ b/src/manifest.json
@@ -292,10 +292,10 @@
 				"_note": "bio-compliance-assessment: catalog archetype (an offered application). Body: application data 8-wide top-left (naam, descriptions, website, contactpersoon, hosting/licence fields, then the new BBN level and DPIA status/dates/document-reference/verwerkingsregister fields) with a Documentation files panel 4-wide top-right. Below, a Related panel surfaces the vendor (aanbieder) and linked services/couplings, then two object-lists: compliance claims (compliancy records — both GEMMA standards and, since this change, BIO measures — filtered by module=@objectId) and application versions (moduleVersie filtered by module=@objectId). An application does not communicate, so per the comms hard-rule NO Emails/Meetings widgets appear. Audit trail stays a sidebar tab.",
 				"widgets": [
 					{ "id": "md-data", "type": "data", "title": "Application", "icon": "Package", "content": { "columns": 2, "include": [ "naam", "beschrijvingKort", "beschrijvingLang", "website", "aanbieder", "contactpersoon", "cloudDienstverleningsmodel", "hostingJurisdictie", "hostingLocatie", "licentietype", "licentie", "bbnLevel", "dpiaStatus", "dpiaDate", "dpiaVolgendeBeoordeling", "dpiaDocumentRef", "verwerkingsregisterRef" ] } },
-					{ "id": "md-files", "type": "integration", "integrationId": "files", "title": "Documentation", "icon": "BookOpenVariantOutline" },
+					{ "id": "md-files", "type": "integration", "integrationId": "files", "title": "Documentation", "icon": "BookOpenVariant" },
 					{ "id": "md-related", "type": "related", "title": "Vendor & services", "icon": "LinkVariant" },
 					{ "id": "md-compliance", "type": "object-list", "title": "Compliance claims", "icon": "ClipboardCheckOutline", "content": { "register": "@resolve:voorzieningen_register", "schema": "compliancy", "filter": { "module": "@objectId" }, "columns": [ { "key": "standaardversie", "label": "Standard" }, { "key": "bioMaatregel", "label": "BIO measure" }, { "key": "url", "label": "Evidence" } ], "limit": 50, "rowRoute": "KompliantieDetail", "allowCreate": false, "emptyText": "No compliance claims yet" } },
-					{ "id": "md-versions", "type": "object-list", "title": "Application versions", "icon": "ViewModule", "content": { "register": "@resolve:voorzieningen_register", "schema": "moduleVersie", "filter": { "module": "@objectId" }, "columns": [ { "key": "versie", "label": "Version" }, { "key": "status", "label": "Status" } ], "limit": 25, "rowRoute": "ModuleversieDetail", "allowCreate": false, "emptyText": "No versions registered yet" } }
+					{ "id": "md-versions", "type": "object-list", "title": "Application versions", "icon": "SourceBranch", "content": { "register": "@resolve:voorzieningen_register", "schema": "moduleVersie", "filter": { "module": "@objectId" }, "columns": [ { "key": "versie", "label": "Version" }, { "key": "status", "label": "Status" } ], "limit": 25, "rowRoute": "ModuleversieDetail", "allowCreate": false, "emptyText": "No versions registered yet" } }
 				],
 				"layout": [
 					{ "id": "1", "widgetId": "md-data", "gridX": 0, "gridY": 0, "gridWidth": 8, "gridHeight": 8 },
@@ -474,7 +474,7 @@
 				"schema": "suite",
 				"_note": "suite-wizard: catalog archetype (a bundled product made up of one or more existing applications). Body: suite data 8-wide (naam, beschrijvingKort, beschrijvingLang, website, logo, contactpersoon) with a Related panel 4-wide surfacing both the contact person and the attached applications (`applicaties`) — the latter via the platform's generic bidirectional relation index (the same `/uses`+`/used` mechanism `md-related` on ModuleDetail already relies on, which is also how a module's own detail page surfaces which suite(s) include it, with no ModuleDetail change needed). A suite does not communicate, so per the comms hard-rule NO Emails/Meetings widgets appear. Audit trail stays a sidebar tab.",
 				"widgets": [
-					{ "id": "suite-data", "type": "data", "title": "Suite", "icon": "PackageVariant", "content": { "columns": 2, "include": [ "naam", "beschrijvingKort", "beschrijvingLang", "website", "logo", "contactpersoon" ] } },
+					{ "id": "suite-data", "type": "data", "title": "Suite", "icon": "Package", "content": { "columns": 2, "include": [ "naam", "beschrijvingKort", "beschrijvingLang", "website", "logo", "contactpersoon" ] } },
 					{ "id": "suite-related", "type": "related", "title": "Applications & contact", "icon": "LinkVariant" }
 				],
 				"layout": [
@@ -578,7 +578,7 @@
 				"schema": "bioMaatregel",
 				"_note": "Catalog archetype (a BIO 2.0 measure), mirroring StandaardDetail's shape for the parallel bioMaatregel relation (design.md Decision 1: compliancy links to a standaardversie OR a bioMaatregel, never a third parallel model). Body: measure data 8-wide (code, naam, omschrijving, thema, bioVersie, bbnNiveau, bron). Below, a compliancy object-list shows every compliance claim referencing this measure (compliancy.bioMaatregel = @objectId), mirroring how StandaardDetail's st-compliance widget shows claims for a standard.",
 				"widgets": [
-					{ "id": "bm-data", "type": "data", "title": "BIO measure", "icon": "ShieldLockOutline", "content": { "columns": 2 } },
+					{ "id": "bm-data", "type": "data", "title": "BIO measure", "icon": "ShieldCheckOutline", "content": { "columns": 2 } },
 					{ "id": "bm-compliance", "type": "object-list", "title": "Compliance claims for this measure", "icon": "ClipboardCheckOutline", "content": { "register": "@resolve:voorzieningen_register", "schema": "compliancy", "filter": { "bioMaatregel": "@objectId" }, "columns": [ { "key": "module", "label": "Module" }, { "key": "url", "label": "Evidence URL" } ], "limit": 50, "rowRoute": "KompliantieDetail", "allowCreate": false, "emptyText": "No compliance claims yet" } }
 				],
 				"layout": [
diff --git a/src/modals/object/MergeObject.vue b/src/modals/object/MergeObject.vue
index 0caa05c4..42eb8118 100644
--- a/src/modals/object/MergeObject.vue
+++ b/src/modals/object/MergeObject.vue
@@ -44,12 +44,25 @@ import { objectStore, navigationStore, catalogStore } from '../../store/store.js
 				<p>Loading objects...</p>
 			</div>
 
-			<div v-else-if="availableObjects.length" class="object-list">
+			<div v-else-if="availableObjects.length"
+				class="object-list"
+				role="listbox"
+				aria-label="Merge target">
+				<!-- role/tabindex/keydown rather than a click-only div: picking the
+				     merge target is the consequential choice in this dialog, and a
+				     keyboard user could not make it at all. role="option" inside the
+				     listbox above carries the selected state to a screen reader
+				     (WCAG 2.1.1, 4.1.2). -->
 				<div v-for="obj in availableObjects"
 					:key="obj['@self'].id"
 					class="object-item table-row-selectable"
+					role="option"
+					tabindex="0"
+					:aria-selected="selectedTargetObject?.['@self']?.id === obj['@self'].id"
 					:class="{ 'table-row-selected': selectedTargetObject?.['@self']?.id === obj['@self'].id }"
-					@click="selectTargetObject(obj)">
+					@click="selectTargetObject(obj)"
+					@keydown.enter.prevent="selectTargetObject(obj)"
+					@keydown.space.prevent="selectTargetObject(obj)">
 					<div class="object-info">
 						<strong>{{ obj['@self']?.name || obj.name || obj.title || obj['@self']?.title || obj['@self']?.id }}</strong>
 						<p class="object-id">
diff --git a/src/modals/object/ViewObject.vue b/src/modals/object/ViewObject.vue
index a82b1835..0e6e1fce 100644
--- a/src/modals/object/ViewObject.vue
+++ b/src/modals/object/ViewObject.vue
@@ -680,6 +680,7 @@ import { objectStore, navigationStore, catalogStore } from '../../store/store.js
 																</NcButton>
 																<NcButton
 																	v-tooltip="'Cancel'"
+																	:aria-label="`cancel editing labels for ${attachment.name ?? attachment?.title ?? 'file'}`"
 																	variant="secondary"
 																	size="small"
 																	@click="cancelFileLabelEditing">
diff --git a/src/views/settings/sections/ArchiMateImportExport.vue b/src/views/settings/sections/ArchiMateImportExport.vue
index f4a16efd..33284518 100644
--- a/src/views/settings/sections/ArchiMateImportExport.vue
+++ b/src/views/settings/sections/ArchiMateImportExport.vue
@@ -173,6 +173,7 @@
 									<h5>Import Errors Details</h5>
 									<NcButton
 										variant="tertiary-no-background"
+										aria-label="Close import error details"
 										@click="hideErrorDetails">
 										<template #icon>
 											<Close :size="20" />
diff --git a/src/views/settings/sections/EmailConfiguration.vue b/src/views/settings/sections/EmailConfiguration.vue
index 1fa4cd53..2c6a4dc7 100644
--- a/src/views/settings/sections/EmailConfiguration.vue
+++ b/src/views/settings/sections/EmailConfiguration.vue
@@ -301,13 +301,20 @@
 								<div class="available-variables">
 									<h5>Available Variables:</h5>
 									<div class="variables-list">
-										<span
+										<!-- A real button rather than a clickable span: this inserts a
+										     template variable into the editor, so it is a control, and
+										     a keyboard or screen-reader user could not reach it at all
+										     while it was a span (WCAG 2.1.1). type="button" keeps it
+										     from submitting the settings form. -->
+										<button
 											v-for="(description, variable) in getActiveTemplateVariables()"
 											:key="variable"
+											type="button"
 											class="variable-tag"
+											:title="description"
 											@click="insertVariable(variable)">
 											{{ formatTemplateVariable(variable) }}
-										</span>
+										</button>
 									</div>
 								</div>
 							</div>
@@ -848,6 +855,10 @@ export default {
 
 .variable-tag {
 	display: inline-block;
+	/* The element is now a <button>; reset the UA chrome so the visual
+	   result is byte-for-byte what the <span> rendered. */
+	border: none;
+	appearance: none;
 	padding: 0.25rem 0.5rem;
 	background: var(--color-primary-light);
 	color: var(--color-primary-text);
diff --git a/tests/e2e/org-archimate-export.spec.ts b/tests/e2e/org-archimate-export.spec.ts
index f0b9fae0..de512621 100644
--- a/tests/e2e/org-archimate-export.spec.ts
+++ b/tests/e2e/org-archimate-export.spec.ts
@@ -188,7 +188,12 @@ async function seedOrganization(): Promise<void> {
  * Auth is injected from storageState (see playwright.config.ts).
  */
 async function goToArchiMateSettings(page: Page): Promise<void> {
-	await page.goto('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/settings/admin/softwarecatalog', { waitUntil: 'networkidle' })
+	// `domcontentloaded`, not `networkidle`: Nextcloud keeps long-lived
+	// connections open (notifications polling, dashboard widgets), so the
+	// network never goes idle and this wait can only ever time out or be
+	// satisfied by luck (ADR-074 rule 4). The real readiness signal is the
+	// heading assertion below, which waits for the SPA to actually mount.
+	await page.goto('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/settings/admin/softwarecatalog', { waitUntil: 'domcontentloaded' })
 	await expect(
 		page.getByRole('heading', { name: 'ArchiMate Import/Export' }),
 	).toBeVisible({ timeout: 30000 })
diff --git a/tests/e2e/workflows/org-export-workflow.spec.ts b/tests/e2e/workflows/org-export-workflow.spec.ts
index 4278a4de..00b163ac 100644
--- a/tests/e2e/workflows/org-export-workflow.spec.ts
+++ b/tests/e2e/workflows/org-export-workflow.spec.ts
@@ -79,7 +79,12 @@ test.afterAll(async () => {
 
 /** Open the ArchiMate Import/Export admin section and wait for it to mount. */
 async function goToArchiMateSettings(page: Page): Promise<void> {
-	await page.goto('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/settings/admin/softwarecatalog', { waitUntil: 'networkidle' })
+	// `domcontentloaded`, not `networkidle`: Nextcloud keeps long-lived
+	// connections open (notifications polling, dashboard widgets), so the
+	// network never goes idle and this wait can only ever time out or be
+	// satisfied by luck (ADR-074 rule 4). The real readiness signal is the
+	// heading assertion below, which waits for the SPA to actually mount.
+	await page.goto('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/settings/admin/softwarecatalog', { waitUntil: 'domcontentloaded' })
 	await expect(
 		page.getByRole('heading', { name: 'ArchiMate Import/Export' }),
 	).toBeVisible({ timeout: 30000 })
diff --git a/tests/vitest/manifestWidgetIcons.spec.js b/tests/vitest/manifestWidgetIcons.spec.js
new file mode 100644
index 00000000..b43d407b
--- /dev/null
+++ b/tests/vitest/manifestWidgetIcons.spec.js
@@ -0,0 +1,144 @@
+/**
+ * Every widget icon named in src/manifest.json must exist in the shared
+ * CnWidgetGrid icon registry.
+ *
+ * THE DEFECT UNDER TEST. Four widget icons named MDI glyphs that the registry
+ * does not contain: BookOpenVariantOutline, ViewModule, PackageVariant and
+ * ShieldLockOutline. `resolveWidgetIcon()` falls back to DEFAULT_ICON for any
+ * unknown name, so those four widgets rendered a generic dashboard glyph —
+ * silently, with no console warning and no build error. The manifest schema
+ * validates the icon field as a string, so `check:manifest` passed too.
+ *
+ * WHY THIS READS THE INSTALLED PACKAGE RATHER THAN A COPY OF THE LIST.
+ * hydra-gates gate-55 carries a hardcoded mirror of the registry and says so
+ * in its own comments. A mirror can only ever be as fresh as its last manual
+ * edit, and a stale mirror fails in both directions — inventing findings for
+ * icons that were added upstream, and passing icons that were removed. This
+ * test parses the registry out of the dependency this app actually resolves
+ * at build time, so it moves when the dependency moves.
+ *
+ * SPDX-FileCopyrightText: 2026 Conduction B.V. <info@conduction.nl>
+ * SPDX-License-Identifier: EUPL-1.2
+ */
+
+import { describe, it, expect } from 'vitest'
+import fs from 'fs'
+import path from 'path'
+import { fileURLToPath } from 'url'
+
+const here = path.dirname(fileURLToPath(import.meta.url))
+const repoRoot = path.resolve(here, '../..')
+
+const REGISTRY_FILE = path.join(
+	repoRoot,
+	'node_modules/@conduction/nextcloud-vue/src/components/CnWidgetGrid/widgetIcons.js',
+)
+
+/**
+ * Extract the registry keys from the installed widgetIcons.js.
+ *
+ * The registry is an object literal mapping `Name: NameIcon`, so the keys are
+ * the lines of the form `\tFoo: FooIcon,`. Anything that does not match that
+ * shape is not a registry entry.
+ *
+ * @return {Set<string>} the icon names the registry recognises.
+ */
+function readRegistry() {
+	const source = fs.readFileSync(REGISTRY_FILE, 'utf8')
+	const names = new Set()
+	for (const m of source.matchAll(/^\s*([A-Z][A-Za-z0-9]*)\s*:\s*[A-Za-z0-9]+Icon\s*,/gm)) {
+		names.add(m[1])
+	}
+	return names
+}
+
+/**
+ * Collect every icon named on a widget, with the page it belongs to.
+ *
+ * Only widget icons are in scope. Page-level icons are rendered by
+ * vue-material-design-icons directly and are not looked up in this registry,
+ * and URL-valued icons (`/`, `http`, `data:`) are rendered as <img> — see
+ * isCustomIconUrl() in the same module.
+ *
+ * @param {object} manifest the parsed src/manifest.json.
+ * @return {Array<{page: string, widget: string, icon: string}>} the widget icons.
+ */
+function collectWidgetIcons(manifest) {
+	const found = []
+
+	// Widgets live under `config.widgets`, `config.tabs[].widgets` and nested
+	// `widgets` arrays, at a depth that varies by page type — so recurse for
+	// any `widgets` array rather than hardcoding the path. The first version
+	// of this walker assumed `page.widgets` and returned zero, which the
+	// "finds widget icons to check" control below caught before the real
+	// assertion could pass vacuously.
+	const walk = (node, pageId) => {
+		if (Array.isArray(node)) {
+			for (const item of node) {
+				walk(item, pageId)
+			}
+			return
+		}
+		if (node === null || typeof node !== 'object') {
+			return
+		}
+		for (const [key, value] of Object.entries(node)) {
+			if (key === 'widgets' && Array.isArray(value)) {
+				for (const widget of value) {
+					const icon = widget?.icon
+					if (typeof icon === 'string'
+						&& icon.length > 0
+						&& !icon.startsWith('/')
+						&& !icon.startsWith('http')
+						&& !icon.startsWith('data:')) {
+						found.push({ page: pageId, widget: widget.id ?? '?', icon })
+					}
+				}
+			}
+			walk(value, pageId)
+		}
+	}
+
+	for (const page of manifest.pages ?? []) {
+		walk(page, page.id ?? page.route ?? '?')
+	}
+	return found
+}
+
+describe('manifest widget icons resolve in the shared registry', () => {
+	it('reads a plausible registry from the installed dependency', () => {
+		// POSITIVE CONTROL ON THE INPUT. If the registry file moves or its
+		// shape changes, readRegistry() returns an empty set and every
+		// assertion below passes vacuously — "I found nothing" and "my parser
+		// is broken" are the same output otherwise.
+		expect(fs.existsSync(REGISTRY_FILE)).toBe(true)
+		const registry = readRegistry()
+		expect(registry.size).toBeGreaterThan(30)
+		// Spot-check both a name that must be there and one that must not.
+		expect(registry.has('ViewDashboard')).toBe(true)
+		expect(registry.has('ThisIconDoesNotExist')).toBe(false)
+	})
+
+	it('finds widget icons to check', () => {
+		const manifest = JSON.parse(
+			fs.readFileSync(path.join(repoRoot, 'src/manifest.json'), 'utf8'),
+		)
+		// Same reasoning: a manifest walk that returns nothing would make the
+		// real assertion below meaningless.
+		expect(collectWidgetIcons(manifest).length).toBeGreaterThan(20)
+	})
+
+	it('names no icon the registry does not contain', () => {
+		const registry = readRegistry()
+		const manifest = JSON.parse(
+			fs.readFileSync(path.join(repoRoot, 'src/manifest.json'), 'utf8'),
+		)
+
+		const unknown = collectWidgetIcons(manifest)
+			.filter(({ icon }) => !registry.has(icon))
+			.map(({ page, widget, icon }) => `${page}.${widget}: ${icon}`)
+
+		expect(unknown, 'These widget icons fall back to DEFAULT_ICON and render the wrong glyph')
+			.toEqual([])
+	})
+})

From adf353dd0709dbb1bd8ee049012a2d0c7a4a9d35 Mon Sep 17 00:00:00 2001
From: Ruben van der Linde <rubenvdlinde@gmail.com>
Date: Sat, 8 Aug 2026 13:29:18 +0200
Subject: [PATCH 2/2] fix(icons): register BookOpenVariant and SourceBranch in
 src/icons.js
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

There are TWO icon registries and an icon must be in both.

CnWidgetGrid resolves widget icons through nc-vue's widgetIcons.js;
CnAppNav, CnIcon and the Cn*Page headers resolve through this app's own
src/icons.js (ADR-077). The lists overlap but are not equal, and the
failure modes differ: an unknown name in the widget registry renders
DEFAULT_ICON, while an unknown name in the app registry renders NO ICON
AT ALL — src/icons.js says exactly that in its own header.

The first pass of this branch replaced four unknown widget icons with
names taken from the widget registry alone. Two of them, BookOpenVariant
and SourceBranch, were absent from src/icons.js, so the repair traded a
wrong glyph for no glyph. hydra-gates checks the two registries in two
different gates — 55 and 60 — so neither on its own would have said so,
and my local baseline run had reported gate-60 PASS while printing
'vue-material-design-icons is not installed — could not verify that icon
names exist upstream'. A caveated pass is not a pass.

Both names are verified present in vue-material-design-icons (the .vue
files exist in the installed package, and nc-vue imports them).

The vitest spec now checks BOTH registries, with its own positive control
on each. Reverting src/icons.js alone turns the new arm red and names
both icons.
---
 src/icons.js                             |  4 ++
 tests/vitest/manifestWidgetIcons.spec.js | 57 ++++++++++++++++++++++++
 2 files changed, 61 insertions(+)

diff --git a/src/icons.js b/src/icons.js
index 4af7cd22..414fa06b 100644
--- a/src/icons.js
+++ b/src/icons.js
@@ -18,6 +18,7 @@ import AccountMultiple from 'vue-material-design-icons/AccountMultiple.vue'
 import AlertCircle from 'vue-material-design-icons/AlertCircle.vue'
 import ApplicationOutline from 'vue-material-design-icons/ApplicationOutline.vue'
 import ArrowRight from 'vue-material-design-icons/ArrowRight.vue'
+import BookOpenVariant from 'vue-material-design-icons/BookOpenVariant.vue'
 import BookOpenVariantOutline from 'vue-material-design-icons/BookOpenVariantOutline.vue'
 import BriefcaseOutline from 'vue-material-design-icons/BriefcaseOutline.vue'
 import ChartBar from 'vue-material-design-icons/ChartBar.vue'
@@ -56,6 +57,7 @@ import ShieldAlertOutline from 'vue-material-design-icons/ShieldAlertOutline.vue
 import ShieldCheckOutline from 'vue-material-design-icons/ShieldCheckOutline.vue'
 import ShieldLockOutline from 'vue-material-design-icons/ShieldLockOutline.vue'
 import ShieldOutline from 'vue-material-design-icons/ShieldOutline.vue'
+import SourceBranch from 'vue-material-design-icons/SourceBranch.vue'
 import Star from 'vue-material-design-icons/Star.vue'
 import ViewDashboardOutline from 'vue-material-design-icons/ViewDashboardOutline.vue'
 import ViewGridOutline from 'vue-material-design-icons/ViewGridOutline.vue'
@@ -68,6 +70,7 @@ export default {
 	AlertCircle,
 	ApplicationOutline,
 	ArrowRight,
+	BookOpenVariant,
 	BookOpenVariantOutline,
 	BriefcaseOutline,
 	ChartBar,
@@ -106,6 +109,7 @@ export default {
 	ShieldCheckOutline,
 	ShieldLockOutline,
 	ShieldOutline,
+	SourceBranch,
 	Star,
 	ViewDashboardOutline,
 	ViewGridOutline,
diff --git a/tests/vitest/manifestWidgetIcons.spec.js b/tests/vitest/manifestWidgetIcons.spec.js
index b43d407b..05b7a55e 100644
--- a/tests/vitest/manifestWidgetIcons.spec.js
+++ b/tests/vitest/manifestWidgetIcons.spec.js
@@ -34,6 +34,23 @@ const REGISTRY_FILE = path.join(
 	'node_modules/@conduction/nextcloud-vue/src/components/CnWidgetGrid/widgetIcons.js',
 )
 
+// THERE ARE TWO REGISTRIES AND AN ICON MUST BE IN BOTH.
+//
+// CnWidgetGrid resolves widget icons through nc-vue's widgetIcons.js above;
+// CnAppNav, CnIcon and the Cn*Page headers resolve through THIS app's own
+// src/icons.js (ADR-077). The two lists overlap but are not equal, and the
+// failure modes differ: an unknown name in the widget registry renders
+// DEFAULT_ICON, while an unknown name in the app registry renders NO ICON AT
+// ALL — which src/icons.js says in its own header.
+//
+// This was learned the hard way. A first pass replaced four unknown widget
+// icons with names taken from the widget registry alone; two of them —
+// BookOpenVariant and SourceBranch — were absent from src/icons.js, so the
+// repair traded a wrong glyph for no glyph. hydra-gates checks the two
+// registries in two different gates (55 and 60), so neither gate on its own
+// would have said so.
+const APP_REGISTRY_FILE = path.join(repoRoot, 'src/icons.js')
+
 /**
  * Extract the registry keys from the installed widgetIcons.js.
  *
@@ -52,6 +69,23 @@ function readRegistry() {
 	return names
 }
 
+/**
+ * Extract the icon names this app registers via src/icons.js.
+ *
+ * The default export is a shorthand object of imported components, so the
+ * registered names are the bare identifiers inside it.
+ *
+ * @return {Set<string>} the icon names the app registry recognises.
+ */
+function readAppRegistry() {
+	const source = fs.readFileSync(APP_REGISTRY_FILE, 'utf8')
+	const names = new Set()
+	for (const m of source.matchAll(/^import\s+([A-Z][A-Za-z0-9]*)\s+from\s+'vue-material-design-icons\//gm)) {
+		names.add(m[1])
+	}
+	return names
+}
+
 /**
  * Collect every icon named on a widget, with the page it belongs to.
  *
@@ -141,4 +175,27 @@ describe('manifest widget icons resolve in the shared registry', () => {
 		expect(unknown, 'These widget icons fall back to DEFAULT_ICON and render the wrong glyph')
 			.toEqual([])
 	})
+
+	it('reads a plausible app registry from src/icons.js', () => {
+		// Same positive control, for the second registry.
+		expect(fs.existsSync(APP_REGISTRY_FILE)).toBe(true)
+		const appRegistry = readAppRegistry()
+		expect(appRegistry.size).toBeGreaterThan(30)
+		expect(appRegistry.has('AccountGroup')).toBe(true)
+		expect(appRegistry.has('ThisIconDoesNotExist')).toBe(false)
+	})
+
+	it('names no icon this app has not registered in src/icons.js', () => {
+		const appRegistry = readAppRegistry()
+		const manifest = JSON.parse(
+			fs.readFileSync(path.join(repoRoot, 'src/manifest.json'), 'utf8'),
+		)
+
+		const unregistered = collectWidgetIcons(manifest)
+			.filter(({ icon }) => !appRegistry.has(icon))
+			.map(({ page, widget, icon }) => `${page}.${widget}: ${icon}`)
+
+		expect(unregistered, 'These icons are not in src/icons.js and render NO icon at all, not a fallback')
+			.toEqual([])
+	})
 })