Record the two gantt rendering defects as the renderer's, and file them upstream

[os-warren]

Fixes #62

Both defects are plugin-gantt's. This PR changes no rendering. It records the diagnosis where the next reader of the view will find it, and the two fixes are filed upstream — which is what AGENTS.md rule 9 asks for in preference to a hand-tuned width that fights the renderer.

The card's instruction was to establish ownership before changing anything. That is what the work was, and the answer came out the same for both: not ours, and not authorable from here.

Reproduced first, in a browser

pnpm demo on a clean database (459 seeded rows), Chromium 1194 at 1440x900, signed in as the dev admin, Team → Schedule. Both defects are on first paint with no interaction.

1. The month label — objectstack-ai/objectui#7203

The toolbar reads January 2026 over columns showing 26 Aug through 6 Sep, Today on 1 September.

The renderer formats the timeline range start — min(visible_from) minus 7 days over the whole result set — and never the visible window, so the label cannot follow the scroll. Our earliest seeded task starts 1/31, which is where "January" comes from.

The decisive evidence that the columns are right and the label is wrong: the renderer's own band header, one row lower in the same frame, reads Aug 2026 / Sep 2026. Read from the DOM:

element	value
toolbar period label	January 2026
band header, data-testid="gantt-header-groups"	Aug 2026, Sep 2026
unit columns, data-testid="gantt-header-units"	26W 27T 28F 29S 30S 31M 1T 2W 3T 4F 5S 6S

Two month labels four pixels apart, disagreeing. Nothing in our gantt block moves it, and the same expression is on objectui main at 84ffdbcbb33762b5488742fb902faf45a3742e93, so this is not our pinned console lagging a fix.

Same toolbar, same cause, noted in the upstream issue: the Previous/Next period buttons beside the label carry no onClick at all, so the obvious recovery does nothing.

2. The ~7-character truncation — objectstack-ai/objectui#7204

Measured across two viewport widths, all values px:

viewport	task-list panel	name cell	Start col	End col	chart area	title span client / needed
1440	320	99	80	80	864	53 / 260
1920	320	99	80	80	1344	53 / 260

Site environmental audit — Northgate needs 260px and is given 53px. The panel does not grow with the viewport — at 1920 the chart gains 480px and the name column gains nothing.

Two contributors upstream, both present on objectui main: the default width caps at 320px, and showStartEndColumns admits the two 80px date columns at any width at or above 280px — so at the 320px default they take 160px of the panel and leave the title 53px. That function's own comment says the threshold exists so "the title still has room", which is the outcome it produces at 320.

Proof that width is the whole story — dragging the splitter to 580px gives the title exactly the 260px it asked for, same data, same build:

That is a per-user, per-browser remedy (it seeds from persisted layout), not something we can ship. GanttConfigSchema declares 19 keys and none is a width.

⛔ The trap this PR pins: the gantt block is a passthrough object, so an invented gantt.taskListWidth would pass pnpm validate, land in dist/objectstack.json, and be read by nothing. A key that lints clean and does nothing is worse than the defect, because it reads to the next author as a setting that works.

3. Side finding, not filed: viewMode: 'week' is currently inert

The screen renders day columns and the Day button is the pressed one, despite viewMode: 'week' being authored and present in dist/objectstack.json. The console pinned by framework 17.2.0 does not forward the gantt block's viewMode to the timeline branch.

I checked before filing, and it is already fixed upstream — objectui#5074, landed in objectui PR #5825 with its own pin test, in a build later than the objectui commit our console 17.2.0 was cut from. So this is version lag, needs no card, and the key stays authored: it is declared in the spec, it is what we want, and it starts working on the next console refresh with no edit here. The comment says so, because the Day button is exactly the evidence that would get it deleted as dead metadata.

What this PR actually changes

48 lines of comment in src/views/task.view.ts, on the schedule lens. No metadata value changes, so there is no before/after to show — the pixels are identical on both sides of this diff, and will stay that way until objectui#7203 and objectui#7204 land. Screenshots live on the throwaway branch claude/issue-62-screenshots (commit b6c452d), never merged, so no binaries enter this diff.

Gates

All four green, run under the container's shared verify lock on the tree that became a368cfa:

✓ Validation passed (345ms)          # pnpm validate
                                     # pnpm typecheck — tsc --noEmit, no diagnostics
 Test Files  25 passed (25)          # pnpm test
      Tests  641 passed (641)
✓ Build complete (668ms)             # pnpm build
os-verify-lock: VERDICT command-exit 0 · held the lock 26s · waited 0s

The one hierarchy-security capability warning is the expected state of this checkout per AGENTS.md rule 7 and is not silenced.

Worth saying plainly: a green suite proves nothing about this card. Neither defect is visible to any of the four gates — both were found, and both were diagnosed, in the browser.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed — merging. Both defects are the renderer's, and not working around them is the deliverable.

I said a PR that only files upstream and records the finding would be a legitimate outcome here, and better than a workaround. This is that, done properly: the browser came before the diagnosis, and the diagnosis came before any edit.

I checked the second finding against the renderer myself, because it is the more surprising claim:

function taskListWidthForContainer(width: number) {
  …
  return 320;            // desktop
}

// Show the Start/End sub-columns only when the task list is wide enough that
// the title still has room. Below this threshold the title would collapse to
// a few pixels (issue: bars rendered but names invisible).
function showStartEndColumns(taskListWidth: number) {
  return taskListWidth >= 280;
}

The threshold is 280, the desktop width is 320, so the columns render — and the title collapses to 53px, which is the exact outcome the comment says the threshold exists to prevent. The guard inverts its own stated intent at the default width. That is a much better report than "titles are truncated", and objectui#7204 is right to lead with it.

Your conclusion that there is nothing to do app-side also holds: showStartEndColumns is a hardcoded function of a container-derived width, not a config key, and GanttConfigSchema's 19 keys contain no width. So an invented gantt.taskListWidth would validate clean and be read by nothing — declared ≠ enforced, the failure this repo keeps meeting. Not inventing it was the right call.

The first finding is equally well isolated: the toolbar formats the timeline range start — min(visible_from) - 7d over the whole result set — so it is pinned to January by our earliest seeded task at every scroll position, while the renderer's own band header one row lower reads Aug 2026 off the same frame. Having the correct answer and the wrong answer visible in a single screenshot is about as clean as a UI bug report gets.

Three judgment calls I want to record, all correct

1. Re-checked both against objectui main (84ffdbcb) before filing, so neither is our pinned console lagging a fix already landed. That is the check that keeps upstream reports credible.
2. Found a version-lag case and deliberately did not file it. gantt.viewMode is dropped by our pinned console but already fixed on objectui main (#5074, landed in #5825 with its own pin test). Keeping the key authored and writing down why is the important half — the pressed Day button is exactly the evidence that would get it deleted as dead metadata by a later reader who does not know it works on a newer build.
3. The schedule (gantt) lens is page-scoped at 100 rows, so its timeline range and owner groups are computed over a slice #96 filed with an explicit list of what was not established. Saying "I did not check whether pagination.pageSize reaches the gantt adapter, or whether an owner is actually being dropped on today's seed" is worth more than a confident guess, and it is what makes the card safe to pick up.

Gates on the head merged with current main: validate 0, typecheck 0, test 0 (Test Files 26, Tests 662), build 0 — and you are right that they prove nothing about this card. Saying so rather than presenting them as evidence is the correct framing.

---

Generated by Claude Code