Found in the first browser pass, on the schedule gantt view added in #49.
Two rendering defects, both cosmetic but both visible on the screen a manager is meant to use to spot an overloaded period.
1. The period header disagrees with the timeline. The header reads "January 2026" while the columns show 28 F · 29 S · 30 S · 31 M · 1 T · 2 W · 3 T · 4 F with the Today marker on 1 T — i.e. 28 Aug → 4 Sep 2026, which is correct for a run on 2026-09-01. The columns are right; the label is wrong.
2. The Task Name column truncates to about seven characters — Permi…, Emis…, Calib…, Chas…, Safet… — while roughly half the viewport to the right sits empty. Two rows reading Emis… and Emis… with different dates are not distinguishable, which defeats the view.
The substance underneath is correct, and worth recording because it is what the view exists for: bars run visible_from → due_date, so lead time shows as bar length (Permit renewal 2/7→2/14, Emissions return 6/28→7/5), grouping by owner works, and the status-derived palette comes through — which is the behaviour #49 deliberately preserved by omitting gantt.colorField (objectstack#14110: declaring it passes the raw field value into backgroundColor and un-colours every bar).
Next step
Establish whether either is ours or the renderer's before changing anything. The month label almost certainly belongs to plugin-gantt; the column width may be a default we can override from the view's gantt block, or may not be authorable at all. If it is the renderer, file upstream rather than working around it — a hand-tuned width that fights the renderer is the kind of workaround rule 9 exists to prevent.
Low priority relative to #60, but it is on a manager-facing screen and the wrong month label is the sort of thing that makes an evaluator distrust everything else on the page.
Found in the first browser pass, on the
schedulegantt view added in #49.Two rendering defects, both cosmetic but both visible on the screen a manager is meant to use to spot an overloaded period.
1. The period header disagrees with the timeline. The header reads "January 2026" while the columns show
28 F · 29 S · 30 S · 31 M · 1 T · 2 W · 3 T · 4 Fwith the Today marker on1 T— i.e. 28 Aug → 4 Sep 2026, which is correct for a run on 2026-09-01. The columns are right; the label is wrong.2. The Task Name column truncates to about seven characters —
Permi…,Emis…,Calib…,Chas…,Safet…— while roughly half the viewport to the right sits empty. Two rows readingEmis…andEmis…with different dates are not distinguishable, which defeats the view.The substance underneath is correct, and worth recording because it is what the view exists for: bars run
visible_from→due_date, so lead time shows as bar length (Permit renewal 2/7→2/14, Emissions return 6/28→7/5), grouping by owner works, and the status-derived palette comes through — which is the behaviour #49 deliberately preserved by omittinggantt.colorField(objectstack#14110: declaring it passes the raw field value intobackgroundColorand un-colours every bar).Next step
Establish whether either is ours or the renderer's before changing anything. The month label almost certainly belongs to
plugin-gantt; the column width may be a default we can override from the view's gantt block, or may not be authorable at all. If it is the renderer, file upstream rather than working around it — a hand-tuned width that fights the renderer is the kind of workaround rule 9 exists to prevent.Low priority relative to #60, but it is on a manager-facing screen and the wrong month label is the sort of thing that makes an evaluator distrust everything else on the page.