kanban(gui): the board was 3px wide and its right-hand columns unreachable — measured, fixed, and the fix mutation-tested

[Yaraslaut]

The repository owner reported that the kanban board is not visible and that
Activity overlaps it. It reproduces, and it is worse than "too narrow": at the
shipped 1280×860 window the board area measured 3 px and the Activity panel
1237 px.

examples/ is a detector, not a product, so this is fixed in place and nothing
is filed. The cause is entirely the example's own QML — no morph forms/qt layer
behaviour and no framework sizing hint is involved, so there is no framework gap
to file against include/morph either.

The three causes, each confirmed

	Confirmed how	Before	After
No scroll container. grep -nE "ScrollView|Flickable|contentWidth|ScrollBar" BoardView.qml returned nothing; the test's findItem(boardArea, "boardFlickable") was nullptr.	grep + measured	columns past the edge drawn beyond clip: true, with nothing to reach them	strip in a Flickable with an always-on horizontal ScrollBar
No floor on boardRoot. grep -nE "Layout\.(minimumWidth|maximumWidth)" returned nothing across every kanban QML file.	grep + measured	board area 3 px	Layout.minimumWidth = one column + gaps (256)
Unbounded Activity panel. A ColumnLayout nested in a RowLayout fills width by default — Layout.preferredWidth: 280 does not stop it — and its implicit width is the widest unwrapped activity summary.	measured	activity 1237 px	fillWidth: false, 200…320 band → 280

Measured widths at the default window size, from the test's own INFO:

before: window 1280, board area 3,   activity 1237
after:  window 1280, board area 960, activity 280
        narrow window 500, board area 256, activity 280

960 is four columns short of five (1232) — which is why reachability, not just
width, is the property that matters.

The test, and the mutations that turn it red

examples/kanban/tests/test_board_layout.cpp runs offscreen
(QT_QPA_PLATFORM=offscreen). It loads Main.qml with both bridges attached
rather than BoardView as a bare root, so the widths it measures are the ones
the real shell produces, and reaches the board by evaluating
stack.push(boardPage) in Main's own context — verbatim the statement
onProjectOpened runs, so no input event is synthesized (presenter rule 6). Five
columns are created through BoardBridge::createColumn.

It asserts the sidebar stays a sidebar; the board holds at least one whole
column; the strip is genuinely wider than the area it is drawn in (so the
reachability check cannot pass vacuously); the scrollbar is on screen; and that
the last column — which starts outside the viewport — is wholly inside it after
scrolling to the end. The floor is then re-checked at a 500 px window, the only
size at which it, and not the sidebar's bound, is what decides the split.

Each of the three fixes was removed in turn and the test re-run:

remove the Flickable      REQUIRE( flick != nullptr )  →  nullptr != nullptr
drop boardRoot's floor    CHECK( boardArea->width() >= 256 )  →  180.0 >= 256.0
                          (narrow window 500, board area 180, activity 280)
drop the sidebar's bound  CHECK( activityPanel->width() <= 320 )  →  648.0 <= 320
                          (window 1280, board area 592, activity 648)

Other views

Checked ProjectListView.qml, MembersView.qml, RulesView.qml,
TaskDetailPopup.qml, LoginView.qml. None has this defect, and none is
changed here.

ProjectListView.qml's two-pane row has the same declaration shape — pane 1
is a nested ColumnLayout with Layout.preferredWidth: 420 and no
fillWidth: false, so both panes fill and split the row roughly evenly instead
of honouring the 420. It is not the same defect: neither pane holds
fixed-width content, nothing is clipped, and nothing becomes unreachable.
Pinning pane 1 to 420 would also leave dead space whenever the members pane is
hidden (it is visible: false until a project is selected), so it is left
alone deliberately rather than by omission. Everything else on these screens is
elastic — labels elide, list delegates take their view's width, forms wrap — and
the vertical ListViews are already flickable.

Gates

• clang-format --dry-run -Werror (22.1.8) over the one changed C++ file — clean.
• ctest -N -L ladder-kanban selects 182 tests (181 before, +1 here), so the
  filter is not matching nothing.
• ctest -L ladder-kanban -j6 → 100% tests passed out of 182, including both
  pre-existing QML engine-load smoke cases (no new QML warnings — the suite fails
  on any).
• ladder_kanban_qml_qmllint: 19 warnings before, 19 after, none of them in
  the changed block.
• No C++ header touched, so no Doxygen run.

Build: Clang 22.1.8, Release, MORPH_BUILD_LADDER=ON MORPH_LADDER_RUNGS=kanban MORPH_BUILD_QT=ON MORPH_BUILD_FORMS_QML=ON.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!