Resemblance re-check: "Monsters' move-down arrow drifted ~67 px from
move-up because the last (auto) column absorbed the new width — add a
trailing filler column." docs/plugin-ui-markup.md's own "Width
semantics" rule makes the LAST <column> in a <list> ALWAYS treated as
auto, regardless of its own declared width — MonsterMoveDownIcons was
the grid's 23rd and, until this commit, LAST column, so it silently
absorbed every pixel of window growth instead of staying at its
declared 23px pitch. The gap was already wrong (89.5px) at the
authored 984-wide default, not just after a resize.
Adds a 24th, trailing <column type="text"> with empty items
(MonsterFillerColumn) so MoveDownIcons is no longer last and keeps its
own real width; the filler absorbs the remainder instead — the same
"fixed icon columns + trailing auto filler" shape lstMetaRules' three
16px icon columns + two auto text columns already prove out
(MarkupListColumnsTests.EndToEnd_MetaShapedSixColumnList_...). The
filler's onclick (MonsterFillerClick) is a real, bound no-op —
MossTankMarkupContractTests.EveryInteractiveControlDeclaresARealHandlerBinding
requires every <column> to declare SOME handler, so "no binding at all"
(the other option this item's own spec offered) is not actually legal
in this codebase; clicking blank filler space does nothing, but the
binding itself is real.
Mutation shown to fail first: the new
MonstersMoveUpAndMoveDownIconsStayAdjacentAtEveryWidth theory (984 and
1100, MarkupDocument.Build over the real mosstank.xml with a real
IMarkupIconResolver stub) failed at BOTH widths against the unmodified
markup — 89.5px apart at 984, 147.5px at 1100 — then passed (fixed
~23px gap at both) once the filler column was added.
MonstersGridHasVtanksTwentyThreeColumnsInOrderWithRetailHeaderTooltips'
23->24 column-count/type update is the other required change; VTank's
own 23-column shape is unchanged, only a MossTank-only 24th filler is
new.
MossTank suite 724/724 (one test's expectations updated, no net count
change); App markup/plugin filter 258 -> 260 (the new theory's two
InlineData cases).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
bae34aaa8b