Keep a board tile's miniature inside its slot, however many columns #247
No reviewers
Labels
No labels
No milestone
No project
No assignees
5 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Grandiras/Ponente!247
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/home-mini-many-columns"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What
A board tile's miniature on Home now draws at most five column tracks and fades a sixth (
board-mini-column-more), the same way a full column already draws five dashes and fades a sixth (MiniCardCap). Boards with 3–5 columns look exactly as before.Why
Each
.board-mini-columnhas fixed horizontal padding (14px, 10px on a phone) and the tracks are 6px apart, and neither can shrink. On a phone the picture's slot is 104px, so eight columns needed 122px and ran 3.6px onto the board's name (measured at 390px). On desktop the same happens past about 11 columns, where the tracks spill out of the tile. Six tracks need 90px on a phone and 114px on desktop, so the picture always fits.I capped the tracks instead of letting them shrink. Shrinking would need gaps and padding that depend on the column count, and by six columns a phone's dashes are already down to dots, so more tracks would add nothing a member could read.
Checks
tools/verify.sh: build and 584 unit tests pass.home.spec.jsandboard-entrance.spec.jspass on an isolated stack (13/13). The phone tile test now gives its board eight columns (by SQL) and asserts six tracks, the last one faded, all inside the picture.docs/boards-and-permissions.md(the miniature bullet) says why.No changelog line:
Changelog.Unreleasedis at its 7-bullet cap (ChangelogTests), and this falls under the existing "A fresh look" bullet.🤖 Generated with Claude Code
🤖 Reviewing this PR — the review will link the full session transcript.
📜 Live transcript — updating every ~5 minutes while the review runs.
🤖 Reviewing this PR — follow along in the action run; the reply will link the full session transcript.
📜 Live transcript — updating every ~5 minutes while the task runs.
✅ Verdict: approve — no blocking issues found.
The change is correct and small. The
forloop renders at mostMiniColumnCap + 1tracks, which is six. The sixth getsboard-mini-column-more, and the CSS shares the 0.4 opacity rule with the faded card dash. Boards with 5 or fewer columns render as before.The e2e SQL insert matches the
BoardColumnentity (BoardId,NameandPositionare the only columns). The test checks the count, the faded class and containment in the picture. The docs bullet explains the reason.Two small notes, neither blocking:
home.spec.jstitles the block "Phone (375px)", while the PR description says it measured at 390px.🧠 claude-sonnet-5-5 · ⏱ 0m 12s · 4 turns · tokens: 24.9k in / 759 out (+48.0k cache-read)
📜 Full session transcript
✅ Verdict: approve — no blocking issues found.
Good to merge. The cap mirrors the existing
MiniCardCappattern exactly: a fifth-plus-one loop bound, a faded sixth track via.board-mini-column-moresharing the.board-mini-card-moreopacity rule. Boards with 3–5 columns render identical markup to before (the class only lands at index 5). The loop is safe for anyColumnCardCounts.Countthanks toMath.Min. The e2e test strengthens the phone assertions (six tracks, last faded, contained within the picture's box) rather than just relaxing the old fit assertion, and the doc bullet explains the why in the repo's own voice. No issues found.⏱ 1m 14s · 3 steps · $0.0035 · tokens: 21.1k in / 397 out (+0 cache-read) · Go: 5h 0% · wk 10% · mo 87%
📜 Full session transcript