What's That: illustration questions render every candidate in a group instead of one representative image (first group also hidden)

[WilfordGrimley]

Part of #704.

Reported symptom

Owner: "We are displaying multiple images per illustration when passing a user a question specifically about which illustration. we only need 1 image per illustration in that case. The first row of illustrations (shouldnt even been a row, just a single image) is hidden on this page."

Code evidence

Multi-image rendering. QuestionFeed.tsx:1148-1162 groups visible candidates by shared illustrationId into illustrationGroupsById, then keeps any cluster with group.length > 1 in illustrationGroups. So far this correctly identifies "this question is about one illustration shared by N printings." But the render path at QuestionFeed.tsx:1615-1657 does:

illustrationGroups.map((group) => ... group.map((candidate) => renderCandidateTile(candidate, ...)) ...)

group.map(...) at line 1640 renders EVERY member of the cluster as its own tile — for a 4-printing illustration group, that's 4 separate images shown for what the grouping logic itself already knows is one artwork. The tap handler (selectIllustrationGroup, QuestionFeed.tsx:929-957) already only submits ONE illustrationId to /2/submitIllustrationVote/ (comment at lines 918-928 confirms the backend treats the whole cluster as one vote target) - the vote-submission side already treats the group as a single answerable unit; only the render side still shows one tile per candidate instead of one representative tile per group.

"First group hidden." No code was found that suppresses, filters, or conditionally hides the first entry of illustrationGroups specifically - the .map() at line 1615 iterates the full array with no slice(1), no index check, and no display:none. IllustrationGroup (QuestionFeed.tsx:325-331) and IllustrationGroupLabel (QuestionFeed.tsx:333-340) carry no conditional visibility logic either. The most plausible non-code explanation found: the group's own visual chrome is very subdued relative to everything around it - IllustrationGroupLabel is 10px, uppercase, muted-color text with no background/border on the surrounding IllustrationGroup box (contrast with NegWrap/OpenWrap elsewhere in the file, which both get a coloured border+background), so a group sitting directly under the "Filter by attribute" toggle could easily read as absent/blank space rather than a rendered illustration cluster, without being programmatically hidden.

Confirmed / Refuted / Inconclusive

Partially confirmed. The "displaying multiple images per illustration" symptom is directly confirmed in the render path (group.map over every candidate, line 1640). The "first row is hidden" symptom is inconclusive from static code alone - no suppression logic exists in the render path, so this is likely NOT the same root cause as the multi-image issue (refuting the "one root cause" hypothesis at the code level); it is more likely a visual-perception issue from the group's own subdued styling, or requires live-browser reproduction to confirm. Recommend the owner re-check this specific symptom once the multi-image fix ships, since a single representative tile per group may resolve the "looks empty" perception as a side effect even without a separate fix.

Scope

Touches QuestionFeed.tsx's illustrationGroups render block (currently line 1615-1657) - change group.map(...) to render one representative tile per group (e.g. group[0], or the highest-confidence member) while keeping selectIllustrationGroup's existing one-illustrationId submission contract unchanged (it already doesn't care which specific candidate was tapped). Separately, if the "first group hidden" symptom survives a live check, that's IllustrationGroup/IllustrationGroupLabel styling - which is layout/visual, not this issue's rendering-logic root cause.

Layout-pass coupling

Not part of the six layout items (Track B - question content, not Track A - layout/space, per the epic). No dependency on the layout repass; can ship independently. If the "first group hidden" half turns out to be a styling problem after live verification, that half would join the layout repass - flagged here for visibility, not filed as a separate issue per the task's "ten issues only" constraint.

---

Owner decisions (2026-08-05 review)

Prior finding reiterated. Multi-image rendering is CONFIRMED (QuestionFeed.tsx:1640, group.map renders every cluster member as its own tile, though the vote path — selectIllustrationGroup, QuestionFeed.tsx:929-957 — already treats the whole group as one answer/one illustrationId submission).

"First group hidden" sub-symptom remains INCONCLUSIVE in code — no suppression, filter, slice, or conditional-visibility logic was found in the render path (QuestionFeed.tsx:1615 onward) or in IllustrationGroup/IllustrationGroupLabel's styling. This needs live-browser reproduction, not further static code review, to confirm or refute.

Record: these are likely TWO problems, not one. The multi-image rendering defect is a confirmed, code-level root cause (fix: render one representative tile per group instead of group.map over every member). The "first group hidden" symptom is either a genuine separate bug requiring live reproduction to locate, or a visual-perception artifact of the group's subdued styling (as already hypothesized above) that may resolve as a side effect of the multi-image fix. Treat them as two independently-trackable outcomes when verifying any fix here — do not assume closing one closes the other.

[WilfordGrimley]

Residual for owner verification after PR #730 deploys — this issue should stay open until then.

PR #730 fixes the first symptom: illustration questions now render one representative tile per group (group.find((c) => c.artCropUrl) ?? group[0]) instead of one tile per group member. Verified in a real browser against a mock backend — a 4-member group rendered a single tile, and the submitted illustrationId payload was unchanged.

The second symptom — "the first row of illustrations is hidden" — did not reproduce and is not fixed. Two independent passes found no suppression mechanism anywhere in the render path: no slice, no filter, no display: none. In live browser verification the group rendered clearly and visibly directly below the "Filter by attribute" toggle, with its label, printing count, artist credit and tile all legible.

So it is unverified rather than resolved. Three possibilities remain open:

1. It resolves as a side effect of rendering one tile instead of several — fewer, less visually noisy tiles.
2. It is a styling issue that only appears under real backend data shapes the mock did not reproduce.
3. It was a perception artifact of the duplicate-tile rendering rather than a distinct defect.

What to check on the live site once #730 is deployed: open a question about an illustration where the card has several printings sharing one illustration, and confirm the first illustration group is visible without scrolling or interaction. If it is, close this issue citing #730. If it is not, re-scope this issue to the remaining styling defect with a screenshot — the render path has been ruled out, so the cause is elsewhere.

[WilfordGrimley]

Verification pass against live production (deployed commit 425fab94): the "invisible suggested printing at Level 2" symptom is now fully explained as the intentional rejectedCandidateIds no-re-presentation behaviour, not a render bug.

Source-confirmed in QuestionFeed.tsx: rejecting a candidate at Level 1 ("No, different printing") adds it to rejectedCandidateIds, and nonRejectedCandidates filters it out before the Level 2 grid ever renders — by design (the file's own header comment names this "no-re-presentation"). Live-confirmed on "Lotus Petal (2)": the Level 1 suggestion (MPS 15) was genuinely absent from the 7-printing Level 2 grid after rejection, with no pagination/hidden-count control shown.

This makes it a product decision, not a defect: whether a user should be able to reconsider a rejected Level 1 suggestion once at Level 2. Full writeup with options (left open, not prescribed): #748.