finding(plugin-timeline): two more unusable gantt date ranges — a malformed date still throws, and an inverted author-pinned range silently draws a negative-width bar on no axis

[os-sales]

Filed unassigned, found while implementing #6750 (the empty items guard, PR #6758). Neither case is fixed by that card, and both were deliberately left out of it — see "Why #6750 does not cover this" below.

Measured on a04c3cac2 (the #6750 branch head, i.e. with that card's guards already in the tree), with a throwaway probe since no pin covers either case.

Case 1 — a malformed date still throws

calculateDateRange guards the EMPTY list, but not a list whose dates do not parse. new Date('not-a-date').getTime() is NaN, Math.min(NaN) is NaN, and new Date(NaN).toISOString() throws the same RangeError #6750 was about:

CASE-1 malformed date -> RangeError: Invalid time value

Input: variant: 'gantt' with one row, items: [{ title: 'T', startDate: 'not-a-date', endDate: 'also-bad' }]. Hard render crash, same signature and same crash site as #6750, different input class.

Case 2 — an inverted author-pinned range renders silent nonsense

An author who pins minDate later than maxDate gets no error and no diagnostic. generateTimeScaleHeaders refuses an inverted range by returning no headers, so the axis has zero columns — but the row loop below it still runs, and calculateBarDimensions happily divides by a negative totalDuration:

CASE-2 inverted pinned range -> axis: [] bars: ["left: 157.9250720461095%; width: -4.322766570605188%;"]

Input: variant: 'gantt', one legitimate row spanning 2024-01-01 to 2024-03-01, with minDate: '2030-01-01' and maxDate: '2026-03-15'. A bar positioned off-canvas at 158% with a negative width, hanging under a header row that has no cells. Nothing anywhere says the range was rejected.

Why #6750 does not cover this

#6750's triage split the card deliberately and scoped it to the empty list — the ordinary empty state of a valid schema. Both cases here are a different input class: a date the author got wrong, not a collection that is legitimately empty. Extending #6750's sentinel to swallow them would have been consumer-side tolerance that hides an author error behind a plausible-looking render, which is a policy decision rather than a mechanical fix, so it was filed rather than taken.

The two cases belong together because a fixer decides one policy for both — the same "decide it once for the whole branch" reasoning #6750's triage applied to the empty case. They fail in opposite directions today, which is itself the argument that no policy exists yet: case 1 crashes loudly, case 2 renders confidently wrong.

Directions, not a recommendation

1. Refuse loudly, the way finding(plugin-timeline): an object-bound timeline with variant: "gantt" throws — calculateDateRange reads a row shape ObjectTimeline never composes #6655 refuses the object-bound gantt: an unusable range renders a diagnostic naming the offending value. Consistent with the neighbouring ruling, and it keeps a wrong date from ever looking like a right one.
2. Validate at the authoring boundary so the renderer never sees an unusable range, if the date keys can be constrained where they are declared rather than where they are read.

Both touch what an author should be told, which is why this is filed rather than fixed.

Where it lives

packages/plugin-timeline/src/renderer.tsx — calculateDateRange for case 1; for case 2, the interaction between the gantt branch's schema.minDate || dateRange.minDate resolution, generateTimeScaleHeaders's inverted-range refusal, and calculateBarDimensions. Line numbers deliberately omitted: re-derive them on your base, since #6758 moves this file.

[huangyiirene]

定级：pm:queue · domain:ui · priority:p1 · type Bug（立卡人已判 Bug，保留）。

p1，与 #6750 同级：case 1 是同一个崩溃点、同一个 RangeError 签名，只是输入类别不同——作者写错一个日期就硬崩。这不是边缘输入，是最普通的一种作者错误。

⭐ 我把"要不要裁"这件事拆开：两个 case 都是缺陷，只有措辞才是政策

卡写"Both touch what an author should be told, which is why this is filed rather than fixed"，态度很对。但我判它可派，理由是这两件事分属不同层：

	状态	是不是政策问题
case 1 崩溃	new Date(NaN).toISOString() 抛 RangeError	⛔ 不是。"不要崩"是正确性下限，与 #6750 同
case 2 静默乱画	轴 0 列，bar left: 157.9% / width: -4.3%	⛔ 不是。自信地画出错误结果，比崩溃更糟
究竟告诉作者哪句话	——	✅ 是政策，但已有先例

⭐ 而那个先例就在隔壁：#6655 对 object-bound gantt 就是"大声拒绝"。⇒ 方向 1（渲染一个点名违规值的诊断）是本仓已确立的做法，⛔ 不需要新裁决，照抄邻居即可。

⛔ 派发围栏

1. ✅ 两个 case 一次做完，一个政策。 卡说得对：它们今天朝相反方向失败（一个大声崩、一个自信错），这本身就是"还没有政策"的证据。⛔ 只修 case 1 会把不一致固化。
2. ⛔ 不要把 finding(plugin-timeline): a gantt timeline with an EMPTY literal items array throws — calculateDateRange reduces an empty list #6750 的哨兵区间扩大来吞掉这两个。 卡已经明确拒绝过这条路，理由正确：那是消费者侧的容忍，会把作者的错误藏在一个看起来合理的渲染后面——正好是 case 2 现在的病。
3. ⛔ 方向 2（在编写边界做校验）不在本卡范围内。 那要约束 minDate/maxDate 被声明的地方，属 schema 侧、且跨仓（objectstack packages/spec）。⇒ 若实施者认为非做不可，停下回填，⛔ 不要自己跨仓改 schema。
4. ⚠️ 行号自己在 base 上重新推导——卡已提醒 fix(plugin-timeline): render an empty gantt as a zero-row grid instead of throwing #6758 会移动这个文件。⛔ 不要照抄卡里的行号，卡自己也故意没写。

⭐ 一条值得记的方法

立卡人是在 #6750 的分支头 a04c3cac2（即带着那张卡的守卫）上测的，所以"#6750 没有覆盖这两个"是测出来的，不是推出来的。⇒ 接手人不必重新验证 #6750 是否顺手修了它们。

这与我在 #6750 上写的范围切分是一致的：那张卡我明确只派"不要崩"，把"空 gantt 该长什么样"留空；这张卡补上的正是**"作者写错时该看到什么"**——两张卡合起来才把这条分支的策略补完整。⚠️ 所以接手 #6759 的人请先看 #6750 的落地结果，⛔ 两张卡不要并行改同一个文件。

---

Generated by Claude Code

[os-sales]

Claim: domain:ui execution seat, PM session session_01CRJge11jso9TpXRWFt1Z49, round R12. Branch: claude/issue-6759-gantt-unusable-date-ranges.

Scope — both cases, one policy

Triage already answered the question the card left open, so no new adjudication is needed. Quoting its ruling verbatim rather than paraphrasing it:

⭐ 而那个先例就在隔壁：#6655 对 object-bound gantt 就是"大声拒绝"。⇒ 方向 1（渲染一个点名违规值的诊断）是本仓已确立的做法，⛔ 不需要新裁决，照抄邻居即可。

| case 1 崩溃 | new Date(NaN).toISOString() 抛 RangeError | ⛔ 不是。"不要崩"是正确性下限，与 #6750 同 |
| case 2 静默乱画 | 轴 0 列，bar left: 157.9% / width: -4.3% | ⛔ 不是。自信地画出错误结果，比崩溃更糟 |

Implement direction 1 for both cases: an unusable range renders a diagnostic that names the offending value, in the same shape #6655 established for the object-bound gantt (role="alert").

Fences

1. ✅ Both cases in one pass, one policy. Fixing only case 1 freezes the inconsistency in place — they fail in opposite directions today, and that is the evidence no policy exists yet.
2. ⛔ Do not widen finding(plugin-timeline): a gantt timeline with an EMPTY literal items array throws — calculateDateRange reduces an empty list #6750's empty-range sentinel to swallow these. The card rejected that path for the right reason: it is consumer-side tolerance that hides an author's error behind a plausible-looking render, which is exactly case 2's present disease.
3. ⛔ Direction 2 (validate at the authoring boundary) is out of scope. It would constrain where minDate/maxDate are declared — schema side, and cross-repo into objectstack packages/spec. If you conclude it is unavoidable, stop and report; do not change spec from this repo.
4. ⚠️ Re-derive line numbers on your own base. PR fix(plugin-timeline): render an empty gantt as a zero-row grid instead of throwing #6758 (finding(plugin-timeline): a gantt timeline with an EMPTY literal items array throws — calculateDateRange reduces an empty list #6750) has landed and moved this file. The card deliberately omitted line numbers for this reason — do not copy any from it.
5. Your file surface is packages/plugin-timeline/ and its tests. Four sibling devs are in flight this round on packages/components/src/renderers/, packages/react/src/, apps/console/, and packages/fields/src/widgets/. Stay out of those.

Note on the base

The finding was measured on a04c3cac2 — #6750's branch head, i.e. with that card's guards already present. So "these two are not covered by #6750" is measured, not inferred; you do not need to re-verify it.

Escape hatch

If measurement shows either case is infeasible or already fixed on your base, stop with zero changes and report the measurement. A dev that measures a direction infeasible and stops is a good outcome, not a failure — that has happened twice this session and both times the measurement was the deliverable.

---

Generated by Claude Code

[os-sales]

os-dev-report

{
  "issue": 6759,
  "status": "done",
  "branch": "claude/issue-6759-gantt-unusable-date-ranges",
  "pr": "https://github.com/objectstack-ai/objectui/pull/6772",
  "premise_still_valid": true,
  "summary": "Both cases reproduced on my base b98352a15 and fixed under one policy, copying #6655's neighbouring shape: an unusable gantt date range now renders a role=alert diagnostic naming the offending value and the authored path, instead of throwing (case 1) or drawing left:157.9%/width:-4.3% under a zero-column axis (case 2). The guard sits ABOVE calculateDateRange and generateTimeScaleHeaders in the gantt branch, so neither is relaxed and #6750's emptyGanttDateRange sentinel is NOT widened; generateTimeScaleHeaders is byte-unchanged and its #6750 verdict stands. Probing found two sub-cases the card did not name, both inside case 1's class and both fixed: an ABSENT endDate crashed identically (new Date(undefined) is NaN), and an unparseable PINNED minDate failed the OTHER way -- axis [] with a bar carrying no style attribute at all (the exact silent-NaN trap the dispatch warned about), so every new pin counts bar ELEMENTS and never reads a style attribute. File surface is packages/plugin-timeline/ as fenced, plus packages/i18n/src/locales/*.ts: the ten locale packs are a mechanical consequence of copying #6655 (check:i18n-keys requires the key in en, all-locales-key-parity requires all ten). None of the four sibling surfaces was touched. Per the coordinator's mid-task note, #6750's pin file timeline-gantt-empty-items.test.tsx is proven byte-identical to base -- blob acd00f3b5 at base, at HEAD and on disk, 30 assertions both sides -- and was neither modified nor weakened; my new pins are additive and re-hold its invariants from the other side (empty-list sentinel intact, degenerate min===max still renders, its axis guard not relaxed). Whole diff is 731 insertions, 0 deletions. Following #6655's own precedent, no docs change.",
  "tests": "All runs serialized through the shared verify lock; exit codes captured by redirecting BEFORE any pipe, never off a tail. Union re-run on the FINAL commit a64e96ca8 with a clean worktree: `pnpm exec vitest run packages/plugin-timeline/ packages/i18n/` VITEST_EXIT=0, Test Files 73 passed (73), Tests 1049 passed (1049) -- includes the 20 new pins, #6750's 13, all-locales-key-parity, de-quote-pairing-3876 and fallback-placeholder-spelling-3512. Gates, each exit code its own line: check:i18n-keys=0 (its own verdict line: 'Every in-scope call-site key resolves against the en pack (2834 keys)...'), check:i18n-drift=0 ('2 key(s) added, 0 en value(s) changed' -- adds are the parity test's business, not its own), check:control-bytes=0 (5631 tracked text files), check-changeset-presence.mjs=0 (13 source files of 2 released packages, 1 changeset), changeset:check=0, plugin-timeline lint=0 / type-check=0, i18n lint=0 / type-check=0. PRE-FIX MEASUREMENT on base b98352a15 via a throwaway probe, all five inputs: CASE-1 malformed startDate -> RangeError: Invalid time value; CASE-1b malformed endDate -> same; CASE-1c ABSENT endDate -> same; CASE-2 minDate 2030-01-01/maxDate 2026-03-15 -> axis [] bars ['left: 157.9250720461095%; width: -4.322766570605188%;']; CASE-2b minDate 'whenever' -> axis [] bars [null]. ABLATION, on the COMMITTED fix (renderer.tsx reverted to the base blob while the new pins and i18n keys stayed, isolating the guard): NO REBUILD LEG APPLIES OR WAS SKIPPED -- the pins import '../renderer' by relative source path, so vitest resolves source and no dist/ sits in the resolution path; there is nothing a stale build could make falsely green. The mutation was confirmed ON DISK before the run by blob hash plus an independent marker count (AFTER_MUTATE_ON_DISK=683aee563... equal to BASE_BLOB, GUARD_MARKER_COUNT_AFTER_MUTATE=0), never off an editor exit code. Result: Test Files 1 failed (1), Tests 13 failed | 7 passed (20), first failure 'expected [Function] to not throw an error but RangeError: Invalid time value was thrown'. Predicted direction was RED and red is what happened. The 7 that stayed green are the unchanged-behaviour pins (healthy chart's exact float geometry, #6750's empty sentinel, degenerate min===max, generateTimeScaleHeaders' own refusal, gantt-only scoping) -- they are supposed to be insensitive to the ablation. Restore leg given equal treatment: restored with `git checkout HEAD -- ABSOLUTE_PATH` (never a bare checkout, which reads the polluted index), proven landed by AFTER_RESTORE_ON_DISK=c4a6b301f... equal to HEAD_BLOB, GUARD_MARKER_COUNT_AFTER_RESTORE=3 and GIT_DIFF_HEAD_EMPTY=yes; the script carried a trap with absolute paths throughout. LINT NARROWING, declared: repo-wide `pnpm lint` was not run; the two touched packages got the exact per-package invocation turbo run lint makes (eslint . from the package root), 0 errors in both. (1) population read from eslint's own config, not my guess; (2) 22 and 84 files counted from --format json output; (3) invariance -- eslint.config.js extends tseslint.configs.recommended with no parserOptions.project or projectService, so type-aware linting is OFF and my diff cannot move the verdict of any file it does not touch. NO DOWNSTREAM TYPE SWEEP, and why it is a measurement not an omission: the i18n edit WIDENS TranslationKeys = typeof en by two nested string properties; nothing in the repo consumes that type structurally (sole reference outside packages/i18n/src is a bare type re-export in packages/react/src/index.ts) and the other nine packs are plain object literals, not annotated, so pack parity is runtime-held by all-locales-key-parity (green above). A widening with no structural consumer cannot change a downstream verdict.",
  "mcp_calls": "5 -- issue_read get, issue_read get_comments, issue_write (filing #6770), create_pull_request, add_issue_comment (this report). Issue/PR reads and the duplicate search went through repo-scoped REST, which is reachable from this seat; the REST /search/issues path is NOT (it returns 'sessions are bound to their configured repositories'), so duplicate-checking used a repo-scoped list endpoint plus local grep rather than a search call.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #6770: a `null` gantt date is silently coerced to the epoch -- new Date(null).getTime() is 0, not NaN, so it passes every parse check; measured with #6759's guards in the tree, `endDate: null` renders a 649-column 1970-2024 axis and a bar with `left: 100%; width: -100%;` and no diagnostic. Same disease as case 2 through a different door. Deliberately NOT fixed here: whether null means refuse / open-ended / absent is a policy choice like the wording #6759's triage adjudicated, so it fails the in-place-fix exemption's condition that the correct form already be pinned by existing evidence. My guard leaves its behaviour byte-unchanged (measured: no diagnostic fires). No duplicate: all 156 open domain:ui issues were listed and grepped."
  ]
}

---

Generated by Claude Code