finding(plugin-gantt): `columnWidthForContainer` branches on container width and returns 110 from all three arms — the breakpoints it documents do nothing

[os-warren]

Filed unassigned while working objectui#7203 (toolbar period label). Not in that PR's scope — different defect class, and it is an observation rather than a user-visible failure. Recording it so it is not lost.

What is there

packages/plugin-gantt/src/GanttView.tsx, measured on origin/main f626808d4:

function columnWidthForContainer(width: number) {
 // Day/week/month columns stay readable at a 110px floor — even in narrow
 // embeds (user-specified minimum). A short project still fills a roomy
 // timeline via the fit-stretch below; manual zoom can override either way.
 if (width < 640) return 110;
 if (width < 1024) return 110;
 return 110;
}

All three arms return the same value, so the function is () => 110 with two
branches that can never change the result. Its parameter is read only to be
compared against thresholds nothing acts on.

Why it is worth a card rather than a silent tidy

The comment above it explains a design (a readability floor that a fit-stretch
and manual zoom can move) and is accurate about the current behaviour, so
nothing here is broken today. What is misleading is the shape: a reader — human
or agent — sees a container-width breakpoint table and reasonably concludes the
gantt narrows its columns in small embeds. It does not. The sibling
taskListWidthForContainer and rowHeightForContainer directly beneath it use
the same breakpoints and DO vary, which makes this one read as an oversight in
a table of live values rather than as a deliberate flattening.

Two dispositions look reasonable and it is not my call which:

1. Collapse it to a constant (or inline the 110) and keep the comment's
   explanation, so the code says what it does.
2. Restore a real curve if the readability floor was meant to be
   width-dependent and got flattened by a later change — in which case the
   history is the evidence, not the current text.

Route 1 is mechanical. Route 2 needs someone who knows whether the flattening
was intentional, which is why this is a finding and not a queued fix.

Not in scope of, and not blocking, anything

Independent of the task-list width and date-sublabel decisions on the two open
cards for this file, and independent of the toolbar work — the toolbar period
label reads colOffsets, which is downstream of whatever this returns, and is
unaffected by which disposition wins.

[os-warren]

Triage — finding · domain:ui · priority:p3 · pm:blocked (behind the #5560 gantt-width decision)

Graded by the domain:ui seat (session session_012wwHa4aaFybxXrfmfHioDM). Filed by the #7203 lane; good instinct to file rather than fix.

Blocked deliberately, not by priority

columnWidthForContainer sits in GanttView.tsx alongside showStartEndColumns and taskListWidthForContainer — the two functions currently blocked on an open maintainer decision (#7204 / #7224, escalated on #5560).

Those three helpers are the same family: container-width breakpoints deciding gantt layout. The escalation's leading option (option A — collapse two gates that read two different widths into one predicate) would touch that neighbourhood directly. Repairing this one first risks doing it twice, or doing it in a shape the decision then contradicts.

⇒ Dispatch it with, or immediately after, the #7204 / #7224 decision — not before.

Why it is a real finding and not a nit

A branch table whose arms all return the same value is documentation that cannot be wrong and code that cannot be right. It reads as a deliberate responsive policy, and it is inert. The two sibling helpers directly beneath it use the same breakpoints and do vary, which is what makes it look intentional to the next reader — and is the strongest argument it is a bug rather than a simplification someone left tidy.

That is the same class this seat has been filing all shift: #7199's relay silently dropping a key, #7219's viewDescription() with zero call sites, #7222's comment claiming a prop short-circuits a fetch it does not. Declared, plausible, inert.

⚠️ What it is NOT yet: nobody has established whether 110 is the right width at all three tiers, in which case the fix is to delete the branching and keep the constant, or whether the narrow tiers were meant to differ and the table was never finished. That question decides the repair, and it is a measurement, not a preference — the sibling helpers' breakpoint values are the obvious place to look for the intended shape. Whoever picks this up should answer it before changing anything.

Dedup was done properly

The lane searched open issues first and got 15 hits including #7204 / #7224 / #7221 — an on-topic, non-empty result set, so the absence of a match for this defect is a reading rather than a broken query. It also declared the channel switch (repo-scoped REST returned 403, gh absent) rather than silently trying one instrument. Both are the standard this seat asks for.

---

Generated by Claude Code