Gallery captions render as stray text inside the grid rather than as a caption

[ptr727]

Found by the Copilot review on #51, and confirmed against the built site rather than read from the markup.

What it is

A gallery caption is written by appending the text to the same line as the last figure shortcode's closing }}:

{{< gallery cols="4" >}}
{{< figure src="…" alt="" caption="" >}}
{{< figure src="…" alt="" caption="" >}}FLAIR puck vs. my old Ecobee3
{{< /gallery >}}

Markdown renders that trailing text as a text node inside the .gallery container, so the emitted HTML is four <figure> elements and zero <figcaption> elements, with a bare string as a sibling of the figures. The grid treats it as another item.

The caption="" parameter on every one of those figures is empty, which is where the text was meant to go.

Scale, measured

Stray caption text nodes in the built site	12
Pages affected	2 — the FLAIR smart vents post (11) and the Supermicro backplane post (1)
Source files affected	1 — content/posts/2022/10/30/installing-flair-smart-vents-to-keep-room-temperatures-balanced.md

The counts differ because the second page reaches the same result through a different markup shape, so a fix that only rewrites the >}}text form will leave one behind. Check the built HTML, not the markdown.

Why it was not fixed in #51

It is a conversion artifact, not a regression from that promotion. main already carried the pattern; #44 restored dropped images into galleries that already ended this way and followed the convention already in the file, which added 3 of the 12.

What a fix has to decide

Not mechanical, which is why this is an issue rather than a commit:

• Which image owns the caption. The text sits after the last figure but reads as a caption for the set ("FLAIR puck vs. my old Ecobee3" describes a comparison across two images). Moving it into that figure's caption="" attributes it to one image and changes the meaning.
• Or the gallery gets a caption of its own, which the gallery shortcode does not currently take, so it would gain a parameter and a <figcaption>-equivalent wrapper.
• Whether the original post captioned it at all. The provenance capture is the only source for what the old platform displayed, per OPERATIONS.md "Rebuilding from the Exports". Settle it there before choosing, since the conversion may have flattened a real <figcaption> into text.

No gate catches this today: the URL contract checks that files resolve, not that markup nests as intended.

[ptr727]

Corroborated by a second Copilot review on #51 (review 4888018740, current head 09c8fe6), which generated no new threads but carried three suppressed low-confidence findings naming the same defect at lines 66, 110 and 175 of the same file, each with the same recommendation: move the trailing text into the caption parameter.

That is consistent with the measurement above rather than additive — those three are inside the eleven occurrences in that file (66, 77, 100, 110, 121, 136, 147, 162, 175, 221, 232). The twelfth is the Supermicro backplane post, which reaches the same rendered result through different markup and is the one a mechanical >}}text rewrite would miss.

Recording the provenance because those findings carried no review thread: a poll of unresolved threads reports a clean pass while they stand, so they have to be read from the review body.