Repository navigation
Gantt: header reads "January 2026" while showing late August, and task names truncate to ~7 characters #62
Description
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.
Activity
os-warren commentedon Sep 1, 2026
Claiming this.
session_01SqkTcrxUFci7nqXdbBSe2pclaude/issue-62-gantt-header-and-labels../duly-issue-62Browser-first card: I will reproduce both defects against a seeded app (
pnpm demo) with screenshots before changing anything, then establish per defect whether it is our view config orplugin-gantt's renderer (AGENTS.md rule 9), and file upstream rather than work around anything that turns out to be the renderer's.Generated by Claude Code
docs(views): record the two gantt rendering defects as the renderer's (…
os-warren commentedon Sep 1, 2026
{ "issue": 62, "status": "done", "branch": "claude/issue-62-gantt-header-and-labels", "pr": "https://github.com/objectstack-ai/duly/pull/95", "premise_still_valid": true, "summary": "Both defects are the renderer's, established in the browser before anything was changed, so nothing was worked around here. (1) The toolbar month label formats plugin-gantt's timeline RANGE START -- min(visible_from) minus 7 days over the whole result set -- and never the visible window, so it is pinned to January by our earliest seeded task (1/31) at every scroll position; the renderer's own band header one row lower reads 'Aug 2026'/'Sep 2026' off the same frame, which is how you can tell the columns are right and the label is wrong. Filed as objectstack-ai/objectui#7203. (2) The task-list panel is a fixed 320px at every viewport width and its Start/End sub-columns take 160px of it, leaving the title span 53px against the 260px a real task name needs; dragging the splitter to 580px renders every name in full, so it is width and nothing else. The width is not authorable (GanttConfigSchema declares 19 keys, none a width) and the block is passthrough, so an invented gantt.taskListWidth would validate clean and be read by nothing. Filed as objectstack-ai/objectui#7204. Both were re-checked against objectui main 84ffdbcb, so neither is our pinned console lagging a fix. The PR is 48 lines of comment on the schedule lens recording all of this plus the two traps a later reader would otherwise hit; it changes no rendering.", "tests": "Four gates green under the container's shared verify lock, on the tree that became a368cfa (the committed tree is the verified tree -- nothing changed between the run and the commit): `os-verify-lock: VERDICT command-exit 0 - held the lock 26s - waited 0s`, with `pnpm validate` -> `Validation passed (345ms)`, `pnpm typecheck` (tsc --noEmit) -> no diagnostics, `pnpm test` -> `Test Files 25 passed (25)` / `Tests 641 passed (641)`, `pnpm build` -> `Build complete (668ms)`. The expected hierarchy-security capability warning (AGENTS.md rule 7) is present and not silenced. No ablation was run: the change is comment-only, so there is no assertion whose failure could be demonstrated. The gates prove nothing about this card and are not the evidence -- both defects are invisible to all four. The real evidence is the browser: `pnpm demo` on a clean database (459 seeded rows), Chromium 1194, signed in as dev admin, Team -> Schedule, reproduced at 1440x900 and 1920x900 with DOM measurements (task-list panel 320px at both widths while the chart went 864 -> 1344px; title span clientWidth 53px vs scrollWidth 260px; toolbar 'January 2026' vs band header 'Aug 2026'/'Sep 2026' in one frame) and four screenshots published on the throwaway branch claude/issue-62-screenshots (b6c452d), embedded in the PR body and in both upstream issues.", "open_questions": [], "out_of_scope_findings": [ "NOT filed, deliberately: gantt.viewMode is dropped by the console pinned at framework 17.2.0, so the schedule lens renders day columns with the Day button pressed despite `viewMode: 'week'` being authored and present in dist/objectstack.json. Checked objectui main before filing -- already fixed there (objectui#5074, landed in objectui PR #5825 with its own pin test), in a build later than the objectui commit our console was cut from. Version lag, not a gap; no card needed. The key stays authored and the PR comment says why, because the Day button is exactly the evidence that would get it deleted as dead metadata.", "filed as duly#96: the schedule lens is page-scoped at 100 rows ('Showing first 100 records'), so the gantt's timeline range and its owner groups are both derived from a slice -- the same absent-group shape as #86 on the by_unit grid, on a lens whose whole purpose is spotting an overloaded period. Filed with the finding label and an explicit list of what I did not establish (whether pagination.pageSize reaches the gantt adapter; whether an owner is actually being dropped on today's seed).", "filed as objectstack-ai/objectui#7203: plugin-gantt's toolbar period label names the timeline range start rather than the visible window, and the Previous/Next period buttons beside it carry no onClick at all.", "filed as objectstack-ai/objectui#7204: plugin-gantt's task list caps at 320px and its Start/End columns take 160px of that, so titles get 53px -- the showStartEndColumns comment states the intent its own threshold inverts at the default width." ] }Generated by Claude Code
os-warren commentedon Sep 1, 2026
os-dev-report
Supersedes the previous comment, whose HTML-comment marker the body sanitizer stripped on save (verified by reading it back — it now begins with the fenced block). Same report, marker as literal text so it stays findable.
{ "issue": 62, "status": "done", "branch": "claude/issue-62-gantt-header-and-labels", "pr": "https://github.com/objectstack-ai/duly/pull/95", "premise_still_valid": true, "summary": "Both defects are the renderer's, established in the browser before anything was changed, so nothing was worked around here. (1) The toolbar month label formats plugin-gantt's timeline RANGE START -- min(visible_from) minus 7 days over the whole result set -- and never the visible window, so it is pinned to January by our earliest seeded task (1/31) at every scroll position; the renderer's own band header one row lower reads 'Aug 2026'/'Sep 2026' off the same frame, which is how you can tell the columns are right and the label is wrong. Filed as objectstack-ai/objectui#7203. (2) The task-list panel is a fixed 320px at every viewport width and its Start/End sub-columns take 160px of it, leaving the title span 53px against the 260px a real task name needs; dragging the splitter to 580px renders every name in full, so it is width and nothing else. The width is not authorable (GanttConfigSchema declares 19 keys, none a width) and the block is passthrough, so an invented gantt.taskListWidth would validate clean and be read by nothing. Filed as objectstack-ai/objectui#7204. Both were re-checked against objectui main 84ffdbcb, so neither is our pinned console lagging a fix. The PR is 48 lines of comment on the schedule lens recording all of this plus the two traps a later reader would otherwise hit; it changes no rendering.", "tests": "Four gates green under the container's shared verify lock, on the tree that became a368cfa (the committed tree is the verified tree -- nothing changed between the run and the commit): `os-verify-lock: VERDICT command-exit 0 - held the lock 26s - waited 0s`, with `pnpm validate` -> `Validation passed (345ms)`, `pnpm typecheck` (tsc --noEmit) -> no diagnostics, `pnpm test` -> `Test Files 25 passed (25)` / `Tests 641 passed (641)`, `pnpm build` -> `Build complete (668ms)`. The expected hierarchy-security capability warning (AGENTS.md rule 7) is present and not silenced. No ablation was run: the change is comment-only, so there is no assertion whose failure could be demonstrated. The gates prove nothing about this card and are not the evidence -- both defects are invisible to all four. The real evidence is the browser: `pnpm demo` on a clean database (459 seeded rows), Chromium 1194, signed in as dev admin, Team -> Schedule, reproduced at 1440x900 and 1920x900 with DOM measurements (task-list panel 320px at both widths while the chart went 864 -> 1344px; title span clientWidth 53px vs scrollWidth 260px; toolbar 'January 2026' vs band header 'Aug 2026'/'Sep 2026' in one frame) and four screenshots published on the throwaway branch claude/issue-62-screenshots (b6c452d), embedded in the PR body and in both upstream issues.", "open_questions": [], "out_of_scope_findings": [ "NOT filed, deliberately: gantt.viewMode is dropped by the console pinned at framework 17.2.0, so the schedule lens renders day columns with the Day button pressed despite `viewMode: 'week'` being authored and present in dist/objectstack.json. Checked objectui main before filing -- already fixed there (objectui#5074, landed in objectui PR #5825 with its own pin test), in a build later than the objectui commit our console was cut from. Version lag, not a gap; no card needed. The key stays authored and the PR comment says why, because the Day button is exactly the evidence that would get it deleted as dead metadata.", "filed as duly#96: the schedule lens is page-scoped at 100 rows ('Showing first 100 records'), so the gantt's timeline range and its owner groups are both derived from a slice -- the same absent-group shape as #86 on the by_unit grid, on a lens whose whole purpose is spotting an overloaded period. Filed with the finding label and an explicit list of what I did not establish (whether pagination.pageSize reaches the gantt adapter; whether an owner is actually being dropped on today's seed).", "filed as objectstack-ai/objectui#7203: plugin-gantt's toolbar period label names the timeline range start rather than the visible window, and the Previous/Next period buttons beside it carry no onClick at all.", "filed as objectstack-ai/objectui#7204: plugin-gantt's task list caps at 320px and its Start/End columns take 160px of that, so titles get 53px -- the showStartEndColumns comment states the intent its own threshold inverts at the default width." ] }Generated by Claude Code