gate-55's hardcoded icon mirror has drifted from nc-vue: it accepts ClipboardList (renders '?') and rejects ClipboardListOutline (correct)

[rubenvdlinde]

Summary

check_detail_page_discipline.py hardcodes ICON_REGISTRY as a mirror of nc-vue's src/components/CnWidgetGrid/widgetIcons.js. The mirror has drifted by one entry, and it drifted in the direction that makes the gate wrong in both directions at once.

	in nc-vue registry	in gate mirror
ClipboardList	❌ no	✅ yes
ClipboardListOutline	✅ yes	❌ no

So gate-55 accepts ClipboardList, which renders the ? fallback in the running app, and rejects ClipboardListOutline, which is the correct name.

Measured

Against @conduction/nextcloud-vue as installed (pipelinq's node_modules):

real registry count: 55
mirror count: 55
real NOT in mirror: ClipboardListOutline
mirror NOT in real: ClipboardList

Extracted from the real file by its import statements (vue-material-design-icons/<Name>.vue), which is how the registry is actually built — each icon is imported individually, no barrel.

Why it matters beyond one name

The gate's own comment says the mirror is "a hardcoded mirror — when the registry changes, replace the names below". Nothing enforces that, so the mirror is a silent expiry date, the same shape as the pinned-callee problem. There is no test asserting mirror == registry.

There is a second registry, and gate-55 does not know about it

An icon must be in two places to render:

1. nc-vue's widgetIcons.js — what gate-55 checks.
2. The app's own src/icons.js (ADR-077) — what gate-60 checks.

An icon in (1) but not (2) renders with no icon at all — worse than the ? fallback. Measured on pipelinq: Timeline is in nc-vue's registry and in gate-55's mirror, but not in pipelinq's src/icons.js. gate-55 was green on it; only gate-60 caught it.

⚠️ And gate-60 is easy to lose: it reports SKIPPED (wiring) when vue-material-design-icons is absent, which is the default in a fresh worktree without npm ci. In that state gate-55 is the only icon check running, and it is the one with the stale mirror. A broken icon ships under a green board.

Suggested fix

1. Re-sync the mirror (ClipboardList → ClipboardListOutline).
2. Add a test that parses nc-vue's widgetIcons.js and asserts set equality with ICON_REGISTRY, so drift fails loudly instead of silently inverting the verdict.
3. Consider having gate-55 state in its output that it checks the lib vocabulary only, and that app-level registration is gate-60's job — so a green gate-55 is not read as "this icon renders".

Workaround used in pipelinq#742

Every replacement icon was chosen from the intersection of all three sets (nc-vue registry ∩ gate mirror ∩ src/icons.js), verified before commit.

[rubenvdlinde]

⚠️ Correction — the suggested fix (1) would invert the gate. Please do not apply it as written. PR #324 fixes the real drift instead.

The measurement was an extraction artifact

CnIcon resolves a name by key lookup, not by filename:

_registry[name] || DASHBOARD_ICONS[name] || ... || HelpCircleOutline

Two DASHBOARD_ICONS keys deliberately differ from the file they import — the key is the concept, the file is just the glyph chosen for it:

ClipboardList: ClipboardListIcon   // <- 'vue-material-design-icons/ClipboardListOutline.vue'
Map:           MapIcon             // <- 'vue-material-design-icons/MapOutline.vue'

Extracting "by its import statements" therefore yields ClipboardListOutline / MapOutline — names that are not registry keys and do render ? — while dropping the two that work.

So the table in the issue is the wrong way round: ClipboardList is valid and renders correctly, and ClipboardListOutline is not. Swapping them, as suggested fix (1) proposes, would make the gate reject the only working name and accept the broken one — wrong in both directions at once.

What the drift actually is

Comparing against the real keys:

mirror count: 55 | real KEY count: 56
real NOT in mirror: ['Map']
mirror NOT in real: []

One entry, Map, added upstream with the Map dashboard widget. The mirror falsely rejects a valid icon; it never accepted a broken one. Latent today (no app uses Map yet).

Verified against nc-vue beta and feat/vue-3 (56 keys each) and against the exact build the issue measured — pipelinq's installed 1.0.0-beta.197 — all three carry ClipboardList: and Map: as keys.

Suggestions 2 and 3 stand

(2) is now in place: PR #324 adds test_check_detail_page_icon_registry.py (auto-discovered by run-helper-suites.sh), asserting the working keys are present and the filename-derived spellings are absent — so a future resync done by grepping imports fails loudly instead of silently inverting the gate. It fails on origin/main with 'Map' not found and passes with the fix.

(3) is a real gap and worth doing separately.

One more thing measured here

The related report that decidesk has 28 icons rendering ? does not reproduce. decidesk's manifests use 101 distinct icon values across 330 occurrences, and all of them resolve — its own src/icons.js registers exactly those 101 (ADR-077, decidesk#363/#364). Both gates agree:

gate-55 on decidesk : exit 0, no findings
gate-60 on decidesk : checked 49 manifest(s): 0 failure(s), 0 warning(s)

No icons need adding to nc-vue's registry.

[rubenvdlinde]

Measured on ConductionNL/decidesk at gate package 5907a4d, NODE_PATH set, 0-byte .err. Three findings, two of which are traps rather than icon questions.

1. The gate-55 helper EXITS 0 EVEN WITH FINDINGS — its exit code is not its verdict

This is the important one. Invoked the way the runner invokes it:

python3 lib/check_detail_page_discipline.py <logfile> <24 manifest files>
  EXIT=0
  stderr: 0 bytes
  findings written to the log: 28

The helper writes findings to the log file and returns 0 regardless; the runner decides FAIL by counting log lines. So "the gate-55 helper exits 0" is not evidence of a clean result — it is the expected exit code either way. Anyone triaging by exit status will read 28 real findings as a pass.

2. Calling it with --app-dir silently inspects NOTHING

I made this mistake myself before catching it:

python3 lib/check_detail_page_discipline.py --app-dir .
  EXIT=0    stdout: 0 lines    stderr: 0 bytes     <-- inspected nothing

versus the runner's actual contract, <logfile> <files...>, which reports 28 on the same tree. --app-dir is not this helper's interface, so it produces a perfect, silent false green. Combined with (1), two independent routes to "looks clean".

3. The finding message names the wrong symptom

The message says an unregistered icon "renders the '?' fallback". Read from nc-vue src/components/CnWidgetGrid/widgetIcons.js:

export const DEFAULT_ICON = 'ViewDashboard'
export function getIconComponent(name) {
  …
  return DASHBOARD_ICONS[name] || DASHBOARD_ICONS[DEFAULT_ICON]
}

An unknown name resolves to ViewDashboard, not a ? glyph. The finding is still real — a page asking for CalendarMonthOutline, EmailArrowLeftOutline or ShieldLockOutline silently gets a generic dashboard icon, so the author's semantic intent is lost — but it is lost invisibly, which is worse to triage than a ? and worth saying accurately.

4. Two different registries are being conflated

decidesk reports gate-60 PASS and gate-55 FAIL(28) in the same run, and both are correct, because they check different things:

	registry	size	decidesk
gate-60 icon-vocabulary	the app's own src/icons.js via registerIcons()	101 imports	PASS — all resolve
gate-55 rule 8	nc-vue CnWidgetGrid/widgetIcons.js	55 keys	FAIL — 28 widget icons absent

So "101 distinct icons, all resolving" and "28 widget icons unregistered" are both true statements about decidesk; they are simply about different registries. A report that cites the first as refuting the second has changed the subject.

Confirming the point already made on this issue: DASHBOARD_ICONS is keyed explicitly (ClipboardList: ClipboardListIcon at line 115), so the mirror must be built from object keys, not import filenames.

[rubenvdlinde]

Correcting my own comment above, and confirming the Map drift independently.

My previous comment cited "55 keys" in CnWidgetGrid/widgetIcons.js. I read that from the shared apps-extra/nextcloud-vue checkout, which turns out to sit on branch wip/cnindexpage-export-action — 332 commits behind origin/feat/vue-3 and 32 behind origin/main. That was the stale-checkout trap, and citing it was my error.

Re-measured against the only authority that matters — the published package decidesk actually installs and runs, @conduction/nextcloud-vue@2.2.0-vue3.3, read out of node_modules/.../dist/nextcloud-vue.cjs.js after a clean npm ci on origin/development:

shipped DASHBOARD_ICONS keys : 56
gate ICON_REGISTRY mirror    : 55
DEFAULT_ICON                 : ViewDashboard

in shipped but NOT in gate mirror : ["Map"]      <- gate falsely REJECTS a valid icon
in gate mirror but NOT shipped    : []           <- no false accepts

So the Map drift reported on this issue reproduces exactly, and it is the only divergence in either direction. ClipboardList is present in both, confirming again that the mirror must track object keys.

Does that change decidesk's 28 findings? No. They span 21 distinct icons, and Map is not among them:

AccountKeyOutline, AccountMultiplePlusOutline, AccountPlusOutline, AccountQuestionOutline,
AccountRemoveOutline, AccountVoice, BookOpenVariantOutline, BriefcaseAccountOutline,
CalendarCheckOutline, CalendarClock, CalendarClockOutline, CalendarMonthOutline,
ClipboardTextClockOutline, CommentQuestionOutline, CommentQuoteOutline, EmailArrowLeftOutline,
EmailArrowRightOutline, FileDocumentOutline, GiftOutline, OfficeBuildingOutline, ShieldLockOutline

All 21 are absent from the shipped 56-key registry, so all 28 findings are genuine and none is the known false positive. The correction to make is Map (one entry), not the mirror wholesale.

The other three points in my earlier comment are unaffected by the stale read, since they were measured from the gate package and the runner directly: the helper exits 0 even with findings (the runner counts log lines, so exit status is not the verdict), invoking it with --app-dir inspects nothing and exits 0 silently, and the finding text should say the icon falls back to ViewDashboard rather than "renders the '?' fallback".

[rubenvdlinde]

Map merged via #324. Two further points from this thread are now also fixed, and I re-measured the registry independently first.

Re-measured against the shipped packages, not a checkout

Extracted the DASHBOARD_ICONS object keys from dist/esm/components/CnWidgetGrid/widgetIcons.js in four installed versions:

app	version	shipped keys	mirror	falsely REJECTS	falsely ACCEPTS
decidesk	1.0.0-beta.220	56	55	Map	—
openregister	2.2.0-vue3.6	56	55	Map	—
procest	2.2.0-vue3.3	56	55	Map	—
pipelinq	1.0.0-beta.197	55	55	—	—

ClipboardList is a key in all four; ClipboardListOutline is a key in none. So the correction stands: the mirror was right, the original table was inverted, and Map is the single genuine drift.

⚠️ My own first extractor reported a spurious "mirror falsely accepts Email" — a regex artefact that silently dropped one key (55 instead of 56). Reading the shipped file directly showed Email: Email, on line 122. Same class of error as the one this issue reports, so: derive the keys line-by-line from inside the Object.freeze({…}) block, and check your key count against the file.

2. The message named the wrong symptom

DEFAULT_ICON = 'ViewDashboard' in every shipped build checked, and getIconComponent() returns DASHBOARD_ICONS[name] || DASHBOARD_ICONS[DEFAULT_ICON]. The finding now reads:

…is not in the shared icon registry, so it silently renders the DEFAULT icon ('ViewDashboard') instead — the intent is lost with no visible breakage… NOTE: this checks the nextcloud-vue widget vocabulary only; the app's own src/icons.js registration is gate-60's subject, and an icon must be in BOTH to render

That last clause is suggestion (3) from this issue — a green gate-55 should not read as "this icon renders".

3. --app-dir no longer produces a silent false green

main() began if len(argv) < 3: return 0, so any malformed call printed nothing and exited 0 — indistinguishable from a clean run. It now rejects options and a missing log path with exit 2 and a usage message that states, in the text itself, that this helper always exits 0 when it runs, so the exit status is not the verdict — read the log.

The runner already checks _dpd_rc, so this surfaces as SKIPPED (wiring) — "no verdict was produced" — rather than PASS.

decidesk unchanged, as expected

Invoked exactly as the runner does (<logfile> <24 manifests>): 28 findings, 0-byte stderr. Map is not among the 21 icons, so all 28 remain genuine.

4 new arms in test_check_detail_page_icon_registry.py; 3 fail on origin/main, and there is a positive control so that "reject everything" cannot satisfy them.