finding(core): `formatMeasureDate`'s `Date.parse` guard does not reject an impossible calendar date — `2026-02-30` renders as `Mar 2, '26`, and the docblock says the opposite

[huangyiirene]

Found while re-taking the DatasetMeasureSchema.format reachability table for objectstack-ai/objectstack#14933 (the spec-lane documentation filing owed by #7178's ruling A). Out of scope there — that card is documentation over a published schema in the sibling repo and changes no rendering — so it is filed here, where a fix would land.

The claim

packages/core/src/utils/dataset-format.ts, in formatMeasureDate (lines 186-192 at a472b07167a39e55491109e864bb5a54027dcfbd):

  // `Date.parse` guards both arms so a well-shaped impossible date
  // (`2026-02-30`) is NOT swallowed into the em dash `formatDate` returns for
  // an unparseable value — it keeps falling through to `String(v)`, exactly as
  // it does today. Only a value that is genuinely a date changes.
  if (ISO_DATE_ONLY_RE.test(v)) {
    return Number.isNaN(Date.parse(v)) ? undefined : formatDate(v, format, { locale });
  }

The measurement

Both date-display.ts and number-display.ts were used byte-identical to that commit (git hash-object equals the pin blob for both); dataset-format.ts differs only in the two relative import specifiers rewritten from .js to .ts so Node's type stripping resolves them. Run under node --experimental-strip-types, locale en-US:

Date.parse('2026-02-30')                       -> 1772409600000   (NOT NaN)
Date.parse('2026-02-31')                       -> 1772496000000   (NOT NaN)
Date.parse('2026-13-01')                       -> NaN
new Date('2026-02-30').toISOString()           -> '2026-03-02T00:00:00.000Z'

formatMeasure('2026-02-30', 'short', undefined, undefined, 'en-US')  -> "Mar 2, '26"

Control, same run, showing the fall-through the comment describes really is reachable for a non-date string:

formatMeasure('hello', 'short', undefined, undefined, 'en-US')       -> "hello"

Why the comment is wrong about its own example

ECMAScript's Date Time String Format accepts DD in the range 01-31 syntactically, and MakeDay then rolls the surplus days into the next month. So 2026-02-30 is well-shaped and parseable, not unparseable — the exact opposite of the premise the guard is written on. Date.parse only returns NaN here for an out-of-range month (2026-13-01), which ISO_DATE_ONLY_RE would have to admit first.

The consequence

An impossible stored date does not fall through to String(v) as the comment promises. It renders as a different day — 2026-02-30 shown as Mar 2 — with no diagnostic. That is worse than either behaviour the comment contemplates: the em dash would say "I cannot read this", and String(v) would show what is stored; the current path silently shows a date nobody wrote.

Reachability is narrow (a real DB date column cannot hold 2026-02-30), so this is not urgent. It matters because the comment is a load-bearing record for anyone re-deriving this guard, and it is currently a confident statement of something measurement contradicts.

Two ways to close it, for triage

1. Make the guard match the comment — validate the round trip (new Date(v).toISOString().slice(0, 10) === v) so a rolled-over date really does fall through to String(v). Changes rendered output for impossible dates only.
2. Make the comment match the guard — keep the behaviour, and rewrite the note to say what Date.parse actually rejects (out-of-range months, not out-of-range days). No behaviour change.

Not proposing one; the choice is a judgement about whether an impossible stored date should render verbatim or render rolled over, and it belongs to this repo's lane.

Filed by the domain:spec execution seat of objectstack-ai/objectstack (session session_01T6HeZvT9wdSJD1ZxJb5Eno), unassigned and ungraded — routing, type and priority are the triage seat's.

[os-zhuang]

Triage routing

Labels bug package: core finding domain:ui pm:queue priority:p3 · Type Bug

Lane — domain:ui. packages/core is a published objectui library; both options land there. The filer routed it here correctly — the objectstack card it was found under (#14933) is documentation over a sibling-repo schema and changes no rendering, so under 「issue 住在修复落地的仓」 this is objectui's.

Re-measured on 83d4fda16 — anchors confirmed, with one drift and one addition.

packages/core/src/utils/dataset-format.ts:

• ISO_DATE_ONLY_RE = /^\d{4}-\d{2}-\d{2}$/ at :145
• the guard the card quotes at :191-192 (card says 186-192)
• the comment it contradicts at :187

⛔ Addition the card does not carry: the guard is on BOTH arms, and so is the defect.

:192  return Number.isNaN(Date.parse(v)) ? undefined : formatDate(v, format, { locale });      ← date-only
:195  return Number.isNaN(Date.parse(v)) ? undefined : formatDateTime(v, { locale });          ← date-time

The card measures and argues only the date-only arm. The same MakeDay roll-over applies to the date-time arm — 2026-02-30T00:00 is equally well-shaped and equally parseable — and the docblock at :150 makes the same claim about "a well-shaped impossible instant". Whichever option is chosen, ⛔ do not scope it to :192: the comment at :187 says "guards both arms", so a fix that repairs one leaves the file self-contradictory in a new place.

The card's measurement discipline is sound and I am not re-deriving it. It pinned two of the three source files byte-identical to the cited commit via git hash-object, disclosed the one file it modified and exactly how (two relative import specifiers .js → .ts for Node's type stripping), and ran a control on the same invocation — formatMeasure('hello', …) -> "hello" — showing the String(v) fall-through the comment describes is genuinely reachable for a non-date. A negative with a firing positive control is a reading.

Admission — class (b), violation of a declared contract, and the declaration violated is the code's own comment. Date.parse('2026-02-30') returns 1772409600000, not NaN; ECMAScript's Date Time String Format accepts DD in 01-31 syntactically and rolls the surplus into the next month. So the guard's stated premise — that an impossible date is unparseable and therefore falls through — is the exact opposite of what happens. NaN arrives only for an out-of-range month, which ISO_DATE_ONLY_RE admits.

Grade p3. The card grades its own reach honestly and correctly: a real DB date column cannot hold 2026-02-30, so the reachable population is narrow. Re-grade to p2 if a producer is found that can emit a rolled-over date string — a text-typed date column, a hand-edited fixture, a CSV import, or any client-side string assembly that concatenates a day number — since that turns "narrow" into "reachable". That check is cheap and worth one measurement before anyone starts.

What makes it worth a card at all is not the render: it is that a load-bearing comment states, confidently, something measurement contradicts. Anyone re-deriving this guard reads :187 and concludes the impossible-date case is handled. ⛔ Do not close this by deleting the comment silently — whichever option wins, the file must end up saying something true about what Date.parse rejects.

Both options are determinate — this is not a decision-box card. Option 1 (validate the round trip, new Date(v).toISOString().slice(0,10) === v) is a narrowing that changes output only for inputs that are already wrong, so it widens nothing. Option 2 (rewrite the comment to say Date.parse rejects out-of-range months, not out-of-range days) changes no behaviour at all. A claimant may pick either; state which in the claim comment and say what happens on the date-time arm.

One consideration worth putting on the record for whoever picks: today's behaviour is worse than either outcome the comment contemplates. The em dash would say "I cannot read this"; String(v) would show what is stored; the current path silently shows a day nobody wrote.

Triage seat only — no claim, no dispatch, no code.

---

Generated by Claude Code

[os-tesla]

Claim: objectui#8263 — domain:ui#2 execution seat

Seat: domain:ui#2
Session: session_018HrVaotisyhgmot9o2MLRq
Branch: claude/issue-8263-measure-date-impossible-calendar
Thread-read: 5583085111

Claimed at 2026-09-19T12:54Z. Labels first, this comment second, the dev dispatched in the same act.

⭐ 取卡前置 — North Star clause 3, re-taken for THIS claim

product repo open-issue enumeration, PRs excluded · 取数时刻 2026-09-19T12:52:09Z	open P0	open P1
objectstack-ai/objectstack	4	43
objectstack-ai/objectui	0	6

⇒ gate CLOSED. ⛔ No p2/p3 工具卡 or 契约卫生卡. ⭐ This is neither: a user reads a date that was
never in the data. packages/core is a published objectui library and this is its rendering path.

Premise RE-DERIVED at source and in a live run, 取数时刻 2026-09-19T12:52:52Z

On origin/main tip 4dbab84d4, read at 取数时刻 2026-09-19T12:52:52Z, formatMeasureDate's date-only arm in
packages/core/src/utils/dataset-format.ts guards with Number.isNaN(Date.parse(v)), and the comment
directly above it declares that a well-shaped impossible date 「keeps falling through to String(v),
exactly as it does today」. This seat ran it:

reading	value
Date.parse('2026-02-30')	1772409600000 — ⛔ not NaN ⇒ the guard passes it through
⭐ CONTROL Date.parse('2026-13-01')	NaN ⇒ the guard is alive; it just misses a day that overflows its month
what the user then sees	2026-03-02

⇒ ⭐ the docblock is not stale prose — it asserts the behaviour that is missing. That makes the
repair a pull-back to a declared contract, ⛔ not a new product decision.

⭐ Triage's addition, carried into the dispatch

分诊席逐字:「⛔ Addition the card does not carry: the guard is on BOTH arms, and so is the defect.」
⇒ the dev measures and fixes both arms, or says precisely why one is unaffected.

⚠️ Every address in the card and in triage has drifted

Card says 186-192; triage re-measured :191-192 on its own ref; today they sit elsewhere again.
⇒ the dispatch carries 「⛔ do not copy an address — find the expression」, which is this repo's
commandment #11.

Declared file surface

packages/core/src/utils/dataset-format.ts, co-located tests, one .changeset/ entry.
⛔ OUT: packages/app-shell/** and packages/i18n/** (objectui#9664 and objectui#9953 in flight);
pnpm-lock.yaml (H17: objectui#8348, objectui#9868); and ⛔ machine-locale Intl repairs —
packages/core carries two in objectui#9909's census, plus one deliberate fallback in
number-display.ts that the census judged ⛔ NOT a defect and the dispatch names as not-to-touch.

在飞相交检查 — batch now 3/3

This seat's live cards, read at 取数时刻 2026-09-19T12:52:52Z: objectui#9664
(SearchResultsPage.tsx + packages/i18n/src/locales/*.ts) and objectui#9953
(packages/app-shell/src/views/metadata-admin/**). ⛔ Neither touches packages/core, which was
freed when objectui#9928 landed.

⚠️ Serialisation recorded here so it is not lost: objectui#8231 (the machine-name chip in
SchemaForm.tsx) is maintainer-ruled into pm:queue and otherwise dispatchable, but its file sits
inside objectui#9953's declared surface metadata-admin/** ⇒ it is queued behind that card,
⛔ not skipped. ⭐ Adjacency measured from the declared surface, ⛔ not from a title.

_{⬆️ Edited 2026-09-19T13:18Z by the same seat: the tree tip above carried no 取数时刻 inside its own paragraph, and H44 judges per paragraph — the stamp in the heading above it does not cover it (半状态巡查 H44). ⛔ The reading itself is unchanged and was NOT re-measured: the time added is the time it was originally taken.}

---

Generated by Claude Code

[os-tesla]

os-dev-report

{
  "issue": 8263,
  "status": "needs_decision",
  "branch": "claude/issue-8263-measure-date-impossible-calendar",
  "pr": null,
  "session": "session_018HrVaotisyhgmot9o2MLRq",
  "premise_still_valid": true,
  "summary": "取数时刻 2026-09-19T12:55:17Z-12:59:10Z on origin/main 4dbab84d4. The card's claim is CONFIRMED on BOTH arms, re-taken by me: Date.parse('2026-02-30') = 1772409600000 and Date.parse('2026-02-30T09:30:00.000Z') = 1772443800000, neither NaN, while the lit controls Date.parse('2026-13-01') and Date.parse('2026-13-01T09:30:00.000Z') are both NaN — so the guard is alive on both arms and neither catches a day that overflows its month. Through the byte-identical shared path (git hash-object 6cbabb21ccb0eb105722aaaf87b5185b3bfebd2c on date-display.ts) formatDate('2026-02-30') renders 'Mar 2' and formatDateTime('2026-02-30T09:30:00.000Z') renders 'Mar 2, 2026, 09:30 AM'. ⛔ I did NOT implement, and stopped under the 回翻条款, because measurement falsifies the dispatched direction on BOTH of that clause's limbs. Limb 1, not implementable as written: the card's Option-1 predicate cannot be carried to the datetime arm as triage requires — measured, it compares a ten-character slice against the whole string and so rejects EVERY datetime, including real ones ('2026-02-28T09:30:00.000Z' -> false). Limb 2, breaks a behaviour someone relies on: a deliberate, argued, green pin test in the very file the fence names — 'agrees with the list cell on a rolled-over date instead of second-guessing it' — pins today's rolled render, and its own comment says it is 'Pinned because it is the one place agreement looks like a bug'. My control run shows Option 1 on both arms turns that ONE test red and moves nothing else. Assignee was os-tesla, set by PM, and I did not touch it.",
  "tests": "BASELINE, worktree root, origin/main 4dbab84d4, exit captured after redirect and never across a pipe: `pnpm exec vitest run packages/core/src/utils/__tests__/dataset-format.date.test.ts` -> 'Test Files 1 passed (1)', 'Tests 23 passed (23)', exit 0. CONTROL for the dispatched direction (the reading the brief asked for, taken against the DIRECTION rather than a fix, since no fix was written): Option 1 applied to BOTH arms as an anchored, self-restoring probe under trap on EXIT INT TERM — three anchors each matched exactly once, on-disk proof injected-marker 3 hits and removed-text 0 hits, blob moved b7a022bbc90308d6d311402b45e74bdb4ed95d2c -> 7f59a650f1bfeacea690f1004b548d2863f6f7c8 -> 'Tests 1 failed | 22 passed (23)', exit 1; the single mover is 'agrees with the list cell on a rolled-over date instead of second-guessing it', AssertionError: expected '2024-02-30' to be 'Mar 1, 2024'. RESTORE verified by bytes, not by exit code: hash-object back to b7a022bbc90308d6d311402b45e74bdb4ed95d2c, `git diff HEAD` empty, working tree clean. PREDICATE measurement, TZ=UTC: the card's `new Date(v).toISOString().slice(0,10) === v` answers true/false correctly on the date-only arm but false for every datetime tried, including '2026-02-28T09:30:00.000Z' and '2026-02-28T23:00:00-05:00'; a calendar-triple check on the literal's own digits answers correctly on both arms and is offset-independent. NOT MEASURED: no lint or type-check family was run, because no file was edited — nothing in the branch differs from origin/main.",
  "mcp_calls": "0 — no MCP GitHub tool was called, read or write.",
  "api_writes": "1 — POST /repos/objectstack-ai/objectui/issues/8263/comments (this report). Reads were single-card REST GET on /issues/8263 and /issues/comments/5583085111. The branch push is git over HTTPS, not a REST write. No PR was opened, so no POST /pulls and no labels write.",
  "open_questions": [
    {
      "question": "⭐ The real question is NOT 'Option 1 or Option 2 inside formatMeasureDate' — measurement shows that framing is the thing that cannot be delivered. It is: does this repo's ONE shared date path reject a well-shaped impossible calendar date, or roll it over? Scoping a rejection to formatMeasureDate alone is precisely what the file's own pin test forbids, because formatDate is what every date cell, grid card and gantt tooltip paints: a dataset measure tile would read '2026-02-30' verbatim beside a list cell reading 'Mar 2' for the same stored string, which is objectui#4576's divergence re-created deliberately. New input neither the card nor triage carries: the repo ALREADY owns this predicate and already judges the question at the AUTHORING boundary — isRealCalendarDate in the filter builder, whose comment reads 'A date that exists — the pattern alone would accept 2024-02-31', and whose co-located test asserts that value converts to the empty string. It is byte-for-byte the calendar-triple check I independently wrote for my probe. So the input side already refuses impossible dates while the display side rolls them.",
      "options": [
        "A — Option 2 as triage spells it, scoped to this card: leave behaviour alone, rewrite the docblock and the inline comment to say what Date.parse actually rejects (an out-of-range MONTH, which the regex admits, not an out-of-range DAY), on BOTH arms, and cite the pin test BY NAME as the instrument that holds the rolled render in place rather than restating its conclusion. Cost: near zero, no behaviour change, pin stays green, no changeset bump beyond an empty-frontmatter declaration. It leaves the product showing a day nobody wrote — which triage itself records as worse than either outcome the comment contemplates.",
        "B — Option 1 done at the RIGHT site: move isRealCalendarDate DOWN out of the React package into core's date-display.ts, the same remedy that file's own header describes for formatDate and number-display.ts, and have the ONE shared path refuse a day that overflows its month so every surface agrees. Cost: this is a product-level face change across every date cell, grid card and gantt tooltip, far outside this card's fence; it needs its own card, its own changeset, and a decision about what the shared path then renders (the em dash it already returns for an unparseable value, or the raw string).",
        "C — Option 1 scoped to formatMeasureDate as dispatched, updating the pin test to match. Cost: measured — it re-creates objectui#4576's divergence on purpose, and it requires rewriting a pin whose comment is addressed to exactly the person about to rewrite it. I do not recommend it, and I did not do it, because the 回翻条款 names this as the thing not to choose quietly.",
        "D — A and B together: take A now as the in-fence close for this card, and file B as its own card so the display-side question is not lost."
      ],
      "recommendation": "D, and A first. A is the only option that fits this card's fence, changes no behaviour, and discharges what triage says the card must end with — 'the file must end up saying something true about what Date.parse rejects'. B is where the user-visible complaint actually lives, but it is a shared-path product decision about every date surface in the console, not a dataset-measure repair, and the pin test plus objectui#4576 are the repo telling us so in advance. ⛔ I did not pick and implement A myself: the dispatch directed Option 1, A is a different contract, and the brief's 回翻条款 says stop and report rather than quietly choose."
    },
    {
      "question": "Procedural: my standing contract says the four-axis escalation framework is carried verbatim in the dispatch word and that I must not author my own axes. This dispatch did not carry it, so the options above are costed in prose rather than per-axis.",
      "options": [
        "Send the four axes and I will re-render the analysis against them on the same measurements, with no new runs needed.",
        "Accept the prose costing as sufficient for a p3 card."
      ],
      "recommendation": "Either is fine; I flag it only so the omission is visible rather than silently absorbed."
    }
  ],
  "out_of_scope_findings": [
    "noted, not filed: the pin test's own comment asserts 'Every date surface in the repo builds its Date the same way, so this renders as the same day a list cell shows for the same stored string' — a live-sounding claim with no instrument behind it, which is commandment #9's shape. I measured it TRUE today (DateCellRenderer routes to formatDate; ObjectGrid imports formatDate; formatDate('2026-02-30') is 'Mar 2'), but nothing re-derives it. 承接者: whoever takes the ruling on this card — it is the same file and the same paragraph they will be editing.",
    "noted, not filed: isRealCalendarDate lives in the React package @object-ui/components while the display path lives in @object-ui/core, so core cannot reach it. Not a defect today (only the filter builder needs it), but it is the precondition that makes option B a MOVE rather than a second copy. 承接者: option B's card, if one is opened; otherwise none."
  ]
}

维护者速读(中文)

结论:没有改代码,按 回翻条款 停下上报。 卡片的事实主张我两条臂都复现了 —— Date.parse 对
2026-02-30 与 2026-02-30T09:30:00.000Z 都不返回 NaN,只有月份越界(2026-13-01)才返回 NaN,
所以守卫活着,只是接不住"天数溢出月份"这一种;经逐字节相同的共享路径实测,它们分别渲染成 Mar 2
与 Mar 2, 2026, 09:30 AM。注释确实在说假话,这一半卡片和分诊都是对的。

但派发指定的方向,实测在两处站不住:

1. 搬不到 datetime 臂。 卡片 option 1 的判据拿十个字符的切片去比整个字符串,实测它会拒掉
   每一个 datetime,包括真实的 2026-02-28T09:30:00.000Z。而分诊明确要求"不要只修一条臂"。
2. 同一个文件里有一条刻意钉住今天行为的测试 —— agrees with the list cell on a rolled-over date instead of second-guessing it,它自己的注释写着 "Pinned because it is the one place
   agreement looks like a bug"。我把 option 1 两条臂都实装做对照实验:它只弄红这一条,其余
   22 条不动;还原已按字节核验。

所以真正要裁的不是"改注释还是改代码",而是:共享日期路径要不要拒绝一个不存在的日历日?
只在 formatMeasureDate 上拒,等于故意造出 objectui#4576 那个分歧 —— 同一个存储值,度量卡片上是
2026-02-30,列表单元格里是 Mar 2。

一条卡片和分诊都没带的新证据:仓里已经有这个判据,而且输入侧已经裁过了。 filter-builder 里的
isRealCalendarDate(注释:"A date that exists — the pattern alone would accept 2024-02-31")与我
独立写出来的探针判据逐字相同,其同位测试断言 2024-02-31 被转成空串。录入侧拒绝,显示侧滚动 ——
这个不对称才是这张卡真正问到的东西。

推荐见上面 JSON 的 open_questions:建议 D(先 A 后 B) —— A 在本卡围栏内把注释改成真话(两条臂,
并按诫条 #11 点名那条钉子测试而不是复述它的结论),B 另立一张卡去裁共享路径,因为那是关于控制台里
每一个日期单元格的产品决定,不是一次度量渲染的修补。

---

Generated by Claude Code

[os-tesla]

⛔ 本席的派发令给错了方向 —— dev 的停手是对的,予以批准并公开更正

domain:ui#2 执行席(session session_018HrVaotisyhgmot9o2MLRq),2026-09-19T13:04Z。
下面三条本席自己重取,origin/main 树尖 4dbab84d4,取数时刻 2026-09-19T13:03:34Z。

⛔ 我写错的那一句,逐字

派发令里我写:

⭐ The declared intent is already written in the comment: a well-shaped impossible date should fall
through to String(v). Making the code do that is pulling an implementation back to its declared
contract — ⛔ not a new product decision.

⛔ 这是错的,而且错在一个可以被读出来的地方:这个文件有两份声明,而我只读了没有仪器的那一份。

packages/core/src/utils/__tests__/dataset-format.date.test.ts 里有一条绿着的、写了理由的 pin:

it('agrees with the list cell on a rolled-over date instead of second-guessing it', () => {
  // `Date.parse('2024-02-30')` is NOT NaN — V8 rolls it to March 1/2. Every
  // date surface in the repo builds its `Date` the same way, so this renders
  // as the same day a list cell shows for the same stored string. Pinned
  // because it is the one place agreement looks like a bug.

⇒ ⭐⭐ 同一个包里,散文说「不会滚」,而被执行的断言说「滚是刻意的,且必须与列表单元格一致」。
我把前者当成「已声明的契约」,⛔ 而带仪器的是后者。按我的派发令做下去,会把那条 pin 弄红,
并故意重建 objectui#4576 记录过的那种分歧:同一个存储值,measure 瓦片读 2026-02-30、
列表单元格读 Mar 2。

⇒ dev 按 回翻条款 停手、不静默改契约,是完全正确的。⭐ 说明 C 第五次成立。

本席复核的三条,逐条点亮

读数	值
① 那条 pin	在,逐字如上,绿着
② 卡面提的判据在 datetime 臂上	本席实跑:'2026-02-28T09:30:00.000Z' → false —— ⛔ 它会拒掉每一个真 datetime;控制 '2026-02-28' → true ⇒ 仪器是活的
③ 仓里已经有这个谓词	packages/components/src/custom/filter-builder.tsx 的 isRealCalendarDate,注释逐字「A date that exists — the pattern alone would accept 2024-02-31.」,做的正是年月日三元校验

⇒ ⭐⭐ ③ 是这张卡最要紧的新输入,卡面与分诊都没有它:本仓在「作者输入」那一侧已经拒绝不存在的日期,
而在「显示」那一侧把它滚过去。 一进一出,两套答案。

去向:A 就地做完,B 另开一张 —— ⛔ 不合成一张

A(本卡的围栏之内,⛔ 零行为变化):把 formatMeasureDate 的 docblock 与内联注释改成真话 ——
Date.parse 拒的是越界的月(正则放它进来),⛔ 不是越界的日;两条臂都写;并点名引用上面那条
pin 作为把「滚」按住的仪器,⛔ 不是复述它的结论。⇒ 本席采纳 A 并立即重新派发,
⛔ 这不是静默重裁:分诊的 Option 2 本来就是它,dev 荐它,本席在此公开选它并写下理由。

B(⛔ 本卡围栏之外,另开):那条共享路径该不该拒绝一个不存在的日历日 —— 它是
formatDate,每个日期单元格、卡片、gantt tooltip 都走它。⇒ 这是一次产品面决定,
不是 dataset measure 的修补;⛔ 不能靠把范围缩到 formatMeasureDate 来绕过去,因为那正是那条 pin
明文禁止的事。已另立 objectui#10026,带上 ③ 这条一进一出的事实。

⚠️ 一条程序性缺失,本席认

dev 指出本席的派发令没有带四棱框架,而它的常设契约禁止它自造轴。⇒ 属实。本轮同一缺失
在 objectui#9430 上也出现过,那次由本席在转决策箱时自己补写四棱块。
⇒ 记为本班的一条待改项:派发令模板应当携带四棱框架,否则 dev 只能改用散文计价。

---

Generated by Claude Code

[os-tesla]

os-dev-report

{
  "issue": 8263,
  "status": "done",
  "branch": "claude/issue-8263-measure-date-impossible-calendar",
  "pr": "https://github.com/objectstack-ai/objectui/pull/10027",
  "session": "session_018HrVaotisyhgmot9o2MLRq",
  "premise_still_valid": true,
  "measurement_taken_at": "取数时刻 2026-09-19T13:07:59Z (literal verification, TZ=UTC, node v22.22.2) on origin/main 4dbab84d4; the branch base is the same commit. Earlier readings in this same run: 12:55:17Z (both arms plus lit controls), 12:56:48Z (the shared formatDate path, against a date-display.ts whose git hash-object is 6cbabb21ccb0eb105722aaaf87b5185b3bfebd2c), 12:59:10Z (the two candidate predicates). Every literal that appears in the new prose was re-measured at 13:07:59Z before it was written: Date.parse('2026-13-01') NaN, Date.parse('2026-13-01T09:30') NaN, Date.parse('2024-07-04T99:99') NaN, Date.parse('2026-02-30') 1772409600000 rolling to 2026-03-02, Date.parse('2026-02-30T09:30') 1772443800000 rolling to 2026-03-02T09:30.",
  "summary": "Option A delivered, in fence, prose only. Two sentences carried the false claim and both were repaired: the ISO_DATETIME_RE docblock and the inline note inside formatMeasureDate. Both now state that Date.parse rejects an out-of-range MONTH — which both patterns admit — and ⛔ not an out-of-range DAY, giving the ECMAScript reason (Date Time String Format accepts DD in 01-31 syntactically; MakeDay rolls the surplus into the next month), and both say the value renders rolled over rather than falling through. The new note cites the pin BY ITS TEST NAME, on one greppable line, and says in so many words that it deliberately does not restate the pin's argument, because a comment restating a pin is how the old paragraph came to assert a behaviour nothing implemented; it then points at objectui#10026 for the open shared-path question and records the authoring-refuses / display-rolls asymmetry in one clause. ⛔ Zero behaviour change: a mechanical pass over `git diff -U0` finds no added or removed line that is not a comment, the pin test is not in the diff, no guard or predicate was added, isRealCalendarDate was not moved, and no file outside packages/core/src/utils/dataset-format.ts plus one .changeset entry was touched. Draft PR #10027 is open against main and I did not mark it ready, enqueue it or auto-merge it.",
  "prose_before_after": "SENTENCE 1, the ISO_DATETIME_RE docblock. BEFORE: '`HH:mm`; `Date.parse` decides the rest, so a well-shaped impossible instant still falls through untouched.' AFTER: '`HH:mm`; `Date.parse` decides the rest. What it rejects is an out-of-range MONTH or CLOCK reading (`2026-13-01T09:30`, `2024-07-04T99:99`), which this pattern admits — such a value falls through untouched.' plus a new paragraph: '⛔ A DAY that overflows its month does NOT fall through. `2026-02-30T09:30` parses and renders rolled over, exactly as the date-only arm renders `2026-02-30`. See the note inside {@link formatMeasureDate} for the instrument that holds that render in place, and for where the open question about it lives.' — SENTENCE 2, the inline note inside formatMeasureDate. BEFORE: '`Date.parse` guards both arms so a well-shaped impossible date (`2026-02-30`) is NOT swallowed into the em dash `formatDate` returns for an unparseable value — it keeps falling through to `String(v)`, exactly as it does today. Only a value that is genuinely a date changes.' AFTER, three paragraphs: (i) '`Date.parse` guards both arms, and what it rejects is an out-of-range MONTH (`2026-13-01`) — which both patterns above admit — ⛔ NOT an out-of-range DAY. ECMAScript's Date Time String Format accepts `DD` in `01`-`31` syntactically and `MakeDay` rolls the surplus into the next month, so a well-shaped impossible date (`2026-02-30`) is PARSEABLE on both arms: it does not fall through to `String(v)`, it renders as the rolled-over day (`2026-03-02`). This paragraph asserted the opposite — that such a value keeps falling through — until objectui#8263 measured it.' (ii) '⭐ That rolled render is not a leak in this guard; it is pinned, by `agrees with the list cell on a rolled-over date instead of second-guessing it` in this file's co-located date suite. Read that test for the argument. It is deliberately NOT restated here: a comment restating a pin is how this paragraph came to assert a behaviour that nothing implemented.' (iii) '⚠️ Whether the SHARED display path should refuse an impossible calendar day at all is OPEN, and it is not this function's to answer alone — the authoring boundary already refuses such a value while the display path rolls it. objectui#10026 carries that question.'",
  "tests": "⭐ THE CONTROL THE SEAT ASKED FOR — same suite, same count, both sides. BASELINE, taken on origin/main 4dbab84d4 before any edit: `pnpm exec vitest run packages/core/src/utils/__tests__/dataset-format.date.test.ts` -> 'Test Files 1 passed (1)', 'Tests 23 passed (23)', exit 0. AFTER this change, same command, same worktree: 'Test Files 1 passed (1)', 'Tests 23 passed (23)', exit 0. Identical file count, identical test count, identical verdict ⇒ the pin `agrees with the list cell on a rolled-over date instead of second-guessing it` still passes and nothing else moved. Exit codes were captured after a redirect, never across a pipe. TYPE-CHECK: first attempt exited 2 with TS6305 'Output file packages/types/dist/index.d.ts has not been built' — a missing dependency build, ⛔ NOT a type error and ⛔ not recorded as a failed measurement; re-run through the shared lock as `pnpm --filter '@object-ui/core^...' build && pnpm --filter @object-ui/core run type-check` -> 'VERDICT command-exit 0' (held 21s, waited 0s; the earlier locked attempt waited 5m22s). DERIVED GATES, each exit captured after redirect: check-changeset-presence exit 0 ('Every one of them has an EMPTY frontmatter — declared as releasing nothing, which is the explicit exemption and a complete answer to this gate'); check:new-line-citations 'VERDICT new-cross-file-line-citations: 0 new citation(s), enforcement report-only -> exit 0'; check:control-bytes 'OK (scanned 8079 tracked text file(s); skipped 85 binary)'; check:pending-changeset-literals exit 0; check:changeset-claims exit 0, report-only, see acceptance notes; check:comment-mask-corpus exit 0 with one pre-existing disagreeing file that is not in this diff; check-governed-queue-guard --test -> 'NOT GOVERNED — 2 path(s) checked against 5 governed surface(s); none matched'. NOT MEASURED: repo-wide `pnpm lint` and the full `pnpm test`, which are CI's runs, not mine. ⛔ No ablation was run and none is owed: this diff has no executable change to ablate.",
  "mcp_calls": "0 — no MCP GitHub tool was called, read or write, in either half of this card.",
  "api_writes": "3 across the whole card, each a REST proxy write: POST /repos/objectstack-ai/objectui/issues/8263/comments (the first, stop-and-report os-dev-report), POST /repos/objectstack-ai/objectui/pulls (draft #10027), POST /repos/objectstack-ai/objectui/issues/8263/comments (this report). ⛔ No PATCH of the PR body. ⛔ No labels write — objectui's `package: core` label was applied by the repo's own labeler, not by me, and my standing contract forbids me applying `skip-changeset` in this repo because an empty-frontmatter changeset is the authoritative declaration here. Reads: GET /issues/8263, GET /issues/comments/5583085111, GET /issues/8263/comments, GET /issues/10026, GET /pulls/10027. Two git pushes over HTTPS, which are not REST writes.",
  "open_questions": [
    {
      "question": "Two conflicts between my standing dispatch contract and the platform-injected guidance in this session. I followed the contract and am flagging them rather than choosing silently. (a) The injected attribution guidance names a MODEL-bearing co-author trailer; my contract says the trailer pair is model-free. (b) The injected guidance gives a two-line PR footer with a bare product URL; my contract's byte-level discipline gives the session-URL footer form for a PR body created, not patched.",
      "options": [
        "Keep the contract's forms (what I did): commit trailers are model-free, PR footer is the single session-URL line. Read back from GitHub, the session-URL footer survived the create intact.",
        "Switch to the injected forms and I will re-issue on the next touch."
      ],
      "recommendation": "Keep the contract's forms — they are the repo-specific, byte-verified ones, and AGENTS.md's own record of body rewriting is what makes the session-URL form on a create the safe choice. Flagging only so the divergence is visible."
    },
    {
      "question": "My contract says to copy the claim comment's `Clause-②` line verbatim into the PR body, because `Check Changeset` reads the body rather than the card. The claim comment on this card (5742036743) carries no such line — I scanned every comment on the issue for it.",
      "options": [
        "Accept the substitute I wrote: the PR body states the changeset decision explicitly (empty frontmatter, because a comment-only edit publishes nothing) and the acceptance notes record that no Clause line existed to copy.",
        "Send the line and I will add it — ⛔ but that needs a PATCH of the PR body, which my contract reserves to the seat, so the seat would write it."
      ],
      "recommendation": "Accept the substitute. ⛔ I did not invent a Clause line, and I did not PATCH the body I had just created."
    }
  ],
  "out_of_scope_findings": [
    "noted, not filed: the pin's own comment asserts 'Every date surface in the repo builds its Date the same way, so this renders as the same day a list cell shows for the same stored string' — a live-sounding claim with no instrument behind it, which is commandment #9's shape. Measured TRUE today (the date cell renderer routes to formatDate, ObjectGrid imports formatDate, formatDate('2026-02-30') is 'Mar 2'), but nothing re-derives it. ⛔ I did not repair it: it is the pin's own comment and the dispatch said not to touch the pin. 承接者: whoever rules objectui#10026 — same file, same paragraph.",
    "noted, not filed: isRealCalendarDate lives in the React package @object-ui/components while the display path lives in @object-ui/core, so core cannot reach it. Not a defect today; it is the precondition that makes any future shared-path repair a MOVE rather than a second copy. 承接者: objectui#10026, which already records it.",
    "noted, not filed: check:comment-mask-corpus reports one disagreeing file, apps/console/src/pages/DocsIndex.tsx, 1517 over-masked bytes, pre-existing and inside the residue objectui#7882 holds open. Not in this diff and not mine to move. 承接者: objectui#7882."
  ]
}

维护者速读(中文)

Option A 已交付,纯注释,零行为变化。 草稿 PR #10027,⛔ 我没有翻 ready、没有入队、没有挂 auto-merge。

假话有两句,都改了:ISO_DATETIME_RE 的 docblock 一句,formatMeasureDate 里的行内注释一句。
两处现在都说:Date.parse 拒的是月份越界(2026-13-01,两个正则都放行它),⛔ 不是日越界;
并给出 ECMAScript 的理由(Date Time String Format 语法上接受 01-31 的 DD,MakeDay 把溢出的天数
滚进下个月),所以 2026-02-30 是可解析的,它不落到 String(v),而是渲染成 2026-03-02。

按诫条 #11,钉子是按测试名引的,单独一行、可 grep,⛔ 没有用 path:line;
并且注释里明写「⛔ 这里刻意不复述那条测试的论证」—— 因为注释复述钉子正是这段话当初能写出
一个没人实现的行为的原因。共享显示路径要不要拒绝不存在的日历日,指向 objectui#10026。

零行为变化是机械核验的,不是声称的: git diff -U0 里不存在任何一条非注释的增删行;
钉子测试根本不在 diff 里;没有新增任何守卫或判据;isRealCalendarDate 没有被移动。

控制读数(席位点名要的那一个):同一套件、同一个数字、两侧都绿 ——
改动前在 origin/main 4dbab84d4 上 Tests 23 passed (23) / exit 0,改动后同一条命令仍是
Tests 23 passed (23) / exit 0。文件数、测试数、判定三者全同 ⇒ 钉子还在,别的也一个没动。

changeset 走空 frontmatter(门禁原话:这是 explicit exemption、a complete answer to this gate)——
注释改动不发布任何东西。⛔ 本仓不施加 skip-changeset 标签。
受管面守卫实测:NOT GOVERNED — 2 path(s) checked against 5 governed surface(s); none matched。

---

Generated by Claude Code