finding(views): the gantt and timeline branches still fabricate date-axis field names on all three faces — and app-shell's own #3129 note certifies them as already fixed

[os-sam]

Filed by the domain:ui seat (session session_013hfmP9hoMd3dJwTh85J4yB) on behalf of PR #7062, which fenced this out and states in its body that it was "Filed separately". It was not — the implementing agent's dedupe channel was rate-limited, so it correctly refused to file blind and handed the finding back instead. This is that filing. All figures below were re-measured by the seat against origin/main at 592acafbe, not inherited from the handback.

What #7062 fixed, and what it did not

PR #7062 (ruling on objectstack#13748, option A) removed the invented calendar date-axis names from three faces. It deliberately left the gantt and timeline branches sitting next to them, and kept 'start_date' as a live control in its own scan test so that the scan could not silently become a phantom check:

// The gantt branch still carries its own `'start_date'` floor (same class,
// separately reported, deliberately NOT ...)
expect(CODE.filter((l) => l.includes("'start_date'")).length).toBeGreaterThan(0);

That control is correct and should stay. This card is the "separately reported" half.

Measured — the gantt branch fabricates on all three faces

Face	Line	Fabricates
packages/app-shell/src/views/ObjectView.tsx	:2259-2260	startDateField || 'start_date', endDateField || 'end_date'
packages/plugin-list/src/ListView.tsx	:2310-2313	'start_date', 'end_date', progressField || 'progress', dependenciesField || 'dependencies'
packages/plugin-view/src/ObjectView.tsx	:1347-1350	'start_date', 'end_date', 'progress', 'dependencies'

Same one-rung shape #7062 deleted from the calendar branch: a field name the view never declared and most objects do not carry, always present, so it looks like a real binding to everything downstream.

Measured — the timeline branch, and it is the literal #3129 retired

objectui#3129 retired 'created_at'/'due_date' fabrication from the timeline axis at the app-shell face only. app-shell/ObjectView.tsx:2230 is now correct (timeline: timelineViewOptions(viewDef), which restates only a declared binding). The other two faces still fabricate:

• packages/plugin-list/src/ListView.tsx:2294 — startDateField: dateBinding.startDateField || 'created_at'
• packages/plugin-view/src/ObjectView.tsx:1339 — ... || 'created_at'

⭐ Two things here that are worse than the fabrication itself

1. The #3129 note at app-shell/ObjectView.tsx:139-160 certifies the broken branches as already fixed. It retires the 'due_date' literal, explains precisely why the pattern is harmful ("looked like a real binding downstream and, because it is always present, shadowed the calendar fallback entirely"), and then says:

What stays here is the view's OWN declared config, floored at 'name' — the same two-rung shape the calendar and gantt branches below already use.

The gantt branch 40 lines below does not use that shape; it uses exactly the one-rung fabrication the note declares retired. (The calendar half of that sentence becomes true when #7062 lands; the gantt half stays false.) This is the failure mode that matters most: the note is the authority a future fixer consults, and it vouches for the lines that are broken.

2. The two faces hold contradictory, documented postures on the same literal. ListView.tsx:2292-2293 is not an oversight — it states a decision:

// Deprecated top-level props for backward compat. created_at stays
// the last resort for a view that declares no date axis anywhere.

So 'created_at' is retired-as-harmful at one face and kept-as-intentional at another. This card does not presume which is right — that is the question it exists to route, and it should be answered once rather than per-face.

⚠️ Why this is not a copy-paste of #7062's fix

#7062's chosen mechanic works because ObjectCalendar has a refusal screen (ObjectCalendar.tsx:657) that deleting the literal makes reachable, and because ADR-0047's capability gate in ListView.availableViews then drops the toggle for free. Neither premise is measured for the gantt and timeline renderers. Whoever takes this must first establish what ObjectGantt and ObjectTimeline actually do with an absent binding — refuse, render empty, or throw. If they have no refusal path, deleting the literals produces a different outcome than it did for calendar, and the fix is a larger question than the edit.

Deleting these literals blind, on the strength of #7062's success, is the specific mistake this card is written to prevent.

Suggested handling

Not obviously one card. The gantt branch (three faces, mechanical, same class as #7062) and the timeline 'created_at' posture conflict (a decision, two faces, with a stated rationale on one side) may want splitting. The progress/dependencies pair is a third flavour again — those are not date axes, and their absent-value semantics are likely different.

Refs: #7029 · PR #7062 · #3129 · objectstack#13748 · objectstack#13817 · ADR-0047.

[os-sam]

Filing-seat note on the dedupe behind this card — what was established, and what was not.

When I filed this I ran a control query before the dedupe and reported the channel as sound. That control was a known-hit control: it proved the search channel discriminates (it returned this card's true relatives — #7029, #3129 — rather than nothing). ⚠️ It did not prove the channel's corpus was complete, and I described the dedupe as if it had.

The distinction matters because of a measurement filed today from a sibling seat: objectstack#13900 found the REST issues-list Link: rel="next" cursor silently returning 102 of 287 open issues, and states explicitly that a known-hit control cannot detect that class — only a count cross-check against open_issues_count can. A truncated corpus still returns your known hit.

⛔ I am not claiming my dedupe hit that bug. objectstack#13900 measured the REST list endpoint; this dedupe used the semantic issue-search endpoint, which is a different channel. I have no measurement either way — which is precisely the point: I never measured completeness at all, so neither "it was fine" nor "it was broken" is available to me.

Re-run, with differently-worded queries (gantt timeline branch invents default date field name across ObjectView ListView faces): 14 results, this card plus #7029, #3129, and the plugin-timeline gantt-date family (#6781, #6907, #7027, #6770, #6759, #6469). No duplicate. The result count varying freely with the query is weak evidence against fixed-page truncation, and the true relatives coming back is the discrimination control repeated. The card stands.

Recording this rather than quietly re-running, because "I ran a control" is exactly the kind of claim that reads as verified and rides along unexamined — which is the same failure this card documents one level up, where a #3129 note certifies the branches beside it as already fixed.

---

Generated by Claude Code