fix(app-shell,plugin-list,plugin-view): no invented gantt date field names, so the refusal screen becomes reachable

.changeset/7070-no-invented-gantt-date-fields.md

@@ -0,0 +1,53 @@
+---
+'@object-ui/app-shell': minor
+'@object-ui/plugin-list': minor
+'@object-ui/plugin-view': minor
+---
+
+Gantt views no longer render on invented date field names (objectui#7070).
+
+The half PR #7062 fenced out and reported separately. A view that carried no
+`gantt:` block used to have a complete-looking date axis synthesized for it:
+all three faces floored `startDateField` at `'start_date'` and `endDateField`
+at `'end_date'` — field names no view had written and most objects do not
+carry.
+
+`ObjectGantt.getGanttConfig` takes its flat branch as soon as BOTH date props
+are present, so the fabricated pair short-circuited the renderer's own refusal
+screen — "Gantt configuration required. Please specify startDateField,
+endDateField, and titleField." — which existed all along and was simply
+unreachable from every route. The same fabrication answered ADR-0047's
+capability gate in `ListView.availableViews`, so the Gantt toggle was live on
+every object view in the product.
+
+⚠️ The premise was MEASURED before anything was deleted, because #7029's
+mechanic is only correct where a refusal path exists and that had never been
+established for this renderer: on the unmodified tree, `ObjectGantt` REFUSES an
+absent binding — it does not render empty, and it does not throw.
+
+Three faces were fabricating, on two independent routes to the same renderer:
+
+- `app-shell/src/views/ObjectView.tsx` — the console object page. The inline
+ branch becomes `ganttViewOptions`, the sibling of `calendarViewOptions` and
+ `timelineViewOptions`: the declared block spread whole, title floored at
+ `'name'`, no date field invented.
+- `plugin-list/src/ListView.tsx` — the render branch AND the capability gate.
+- `plugin-view/src/ObjectView.tsx` — `generateViewSchema`, the authored
+ `object-view` element route, which bypasses `ListView` entirely.
+
+**What changes for an author.** A view that declared no gantt configuration is
+no longer offered the Gantt toggle, and one forced onto the renderer reaches
+the refusal screen instead of a plausible, fully wrong chart. A view that
+declared a binding is unaffected — the declared block is forwarded exactly as
+before, every spec key included.
+
+Also corrected: the objectui#3129 note at the top of `app-shell/ObjectView.tsx`
+certified the gantt branch below it as already using the safe two-rung shape.
+It did not. The note now states each sibling branch as measured, and says
+explicitly which fabrication REMAINS — the timeline `'created_at'` floor at the
+two plugin faces, which objectui#7070 routes to a ruling rather than settling
+per-face.
+
+Deliberately out of scope, and left in place: `progressField` / `dependenciesField`
+(not date axes, different absent-value semantics) and the timeline `'created_at'`
+posture conflict.

packages/app-shell/src/views/ObjectView.calendarBinding-7029.test.tsx

@@ -130,12 +130,44 @@ describe('no invented calendar field name survives in the source (objectui#7029)
  expect(CODE.filter((l) => /calendar\?\.titleField \|\| 'name'/.test(l))).toEqual([]);
  });
 
- it('CONTROL: the scan can still see a literal that IS there', () => {
- // Without this the two cases above are green on any tree where the filter
- // simply matches nothing — the failure mode that made the first spelling of
- // this scan a phantom check. The gantt branch still carries its own
- // `'start_date'` floor (same class, separately reported, deliberately NOT
- // touched by this card), so it is the honest positive control.
- expect(CODE.filter((l) => l.includes("'start_date'")).length).toBeGreaterThan(0);
+ /**
+ * ⭐ THE POSITIVE CONTROL — read this before changing either case below.
+ *
+ * Without a control the two cases above are green on any tree where the filter
+ * simply matches nothing: the failure mode that made the first spelling of
+ * this scan a phantom check. This control was originally a single case
+ * anchored on the gantt branch's own `'start_date'` floor ("same class,
+ * separately reported, deliberately NOT touched by this card").
+ *
+ * objectui#7070 is that separate report, and fixing it deleted the anchor —
+ * `'start_date'` is now absent from this face's CODE, so the original control
+ * would have gone red. ⛔ It was NOT simply removed: a scan whose last live
+ * control is dropped becomes a test that passes over nothing, which is the
+ * exact class this whole card family is about. It is re-expressed as TWO
+ * controls that answer two different questions:
+ */
+
+ it('CONTROL (machinery): the scan can see a literal that IS there', () => {
+ // Can this filter return a non-empty result at all? Anchored on `'name'`,
+ // which is DELIBERATELY permanent here — the display-name floor the
+ // objectui#3129 note above the seams describes as what stays. It is not a
+ // fabricated field name, so no future card of this family retires it, and
+ // this control cannot go red as a side effect of the next fix.
+ expect(CODE.filter((l) => l.includes("'name'")).length).toBeGreaterThan(0);
+ });
+
+ it('CONTROL (same class): the scan still sees a REMAINING fabricated field name', () => {
+ // Can this filter see the specific thing it exists to hunt — a one-rung
+ // `|| 'literal'` field-name floor? Anchored on the gallery branch's
+ // `imageField: … || 'image'`, which is the same class, is still there, and
+ // is out of scope for both objectui#7029 and objectui#7070.
+ //
+ // ⚠️ TO WHOEVER RETIRES `'image'`: this going red is the mechanic working,
+ // not a broken test. RE-ANCHOR it onto whatever fabrication legitimately
+ // remains in this file — do not delete it, and do not weaken it to the
+ // machinery control above. If nothing of this class remains anywhere in this
+ // face, say so in the PR body and convert this case into the assertion that
+ // NONE remains, so the scan keeps making a claim about the tree.
+ expect(CODE.filter((l) => l.includes("'image'")).length).toBeGreaterThan(0);
  });
 });

packages/app-shell/src/views/ObjectView.ganttBinding-7070.test.tsx

@@ -0,0 +1,161 @@
+/**
+ * ObjectUI
+ * Copyright (c) 2024-present ObjectStack Inc.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ */
+
+/**
+ * objectui#7070 — the object page must not invent a GANTT date binding.
+ *
+ * The sibling of `ObjectView.calendarBinding-7029` next door, and the half PR
+ * #7062 fenced out and reported separately. This face floored
+ * `startDateField` at `'start_date'` and `endDateField` at `'end_date'` for
+ * EVERY object view, declared or not. Downstream that is indistinguishable
+ * from a real binding: `ObjectGantt.getGanttConfig` takes its flat branch as
+ * soon as BOTH date props are present, so the fabrication made the renderer's
+ * own "Gantt configuration required" screen unreachable from this route, and it
+ * answered ADR-0047's capability gate (`options.gantt.startDateField`) so the
+ * Gantt toggle was live on every object view in the product.
+ *
+ * ⚠️ THE PREMISE WAS MEASURED BEFORE THE DELETION. #7029's mechanic — delete the
+ * literal, let the renderer's own refusal answer — is only correct where a
+ * refusal path exists, and that had never been established for gantt. It was,
+ * on the unmodified tree, before this file's fix was written: `ObjectGantt`
+ * REFUSES an absent binding (it does not render empty, and does not throw). The
+ * seam is pinned in `plugin-gantt/src/ObjectGantt.unconfiguredRefusal-7070`.
+ *
+ * REVERSE VERIFICATION — direction predicted before running, then observed:
+ * restore `startDateField: viewDef.gantt?.startDateField || 'start_date'` and
+ * its `endDateField` twin, and the "invents NO date field" cases below go RED
+ * (they read the fabricated names) while every declared-config CONTROL stays
+ * GREEN in either world — the fabricated value is only ever observable when the
+ * view declared nothing. That asymmetry is the point: a fix that emitted an
+ * empty config for EVERY view would also pass a refusal-only test.
+ */
+
+import { describe, it, expect } from 'vitest';
+import { readFileSync } from 'node:fs';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+import { ganttViewOptions } from './ObjectView';
+
+describe('ganttViewOptions — the object page forwards, it does not invent (objectui#7070)', () => {
+ it('invents NO date field for a view that declares no gantt config', () => {
+ // THE DEFECT. This used to return `{ startDateField: 'start_date',
+ // endDateField: 'end_date', titleField: 'name' }` — a complete-looking axis
+ // for a view that configured nothing, which is what short-circuited the
+ // renderer's refusal screen and lit the Gantt toggle everywhere.
+ expect(ganttViewOptions({})).toEqual({ titleField: 'name' });
+ expect(ganttViewOptions(undefined)).toEqual({ titleField: 'name' });
+ expect(ganttViewOptions({ label: 'All', columns: ['name'] })).toEqual({ titleField: 'name' });
+ });
+
+ it('invents no date field for a view whose neighbouring blocks ARE declared', () => {
+ // A view bound for kanban/calendar must not acquire a gantt axis by
+ // proximity — the Gantt toggle it would light up has nothing behind it.
+ const out = ganttViewOptions({
+ kanban: { groupByField: 'stage' },
+ calendar: { startDateField: 'start_date' },
+ });
+ expect(out).not.toHaveProperty('startDateField');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('invents no date field for an EMPTY gantt block', () => {
+ // The half-written declaration: `allowedVisualizations: ['gantt']` with
+ // nothing under `gantt:`. It must stay half-written all the way down.
+ const out = ganttViewOptions({ gantt: {} });
+ expect(out).not.toHaveProperty('startDateField');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('CONTROL: forwards a fully declared block verbatim — every spec key survives', () => {
+ // A bare whitelist here once dropped every field past `colorField` and
+ // flattened the chart, so the spread is load-bearing, not incidental.
+ const out = ganttViewOptions({
+ gantt: {
+ startDateField: 'planned_start',
+ endDateField: 'planned_end',
+ titleField: 'subject',
+ parentField: 'parent',
+ typeField: 'node_type',
+ baselineStartField: 'bl_start',
+ groupByField: 'owner',
+ tooltipFields: [{ field: 'owner' }],
+ },
+ });
+ expect(out).toMatchObject({
+ startDateField: 'planned_start',
+ endDateField: 'planned_end',
+ titleField: 'subject',
+ parentField: 'parent',
+ typeField: 'node_type',
+ baselineStartField: 'bl_start',
+ groupByField: 'owner',
+ tooltipFields: [{ field: 'owner' }],
+ });
+ });
+
+ it('CONTROL: a HALF-declared axis keeps its declared rung and only that', () => {
+ // One date field is not a gantt: `getGanttConfig`'s flat branch needs BOTH,
+ // so this shape reaches the refusal screen rather than rendering on a name
+ // nobody wrote.
+ const out = ganttViewOptions({ gantt: { startDateField: 'planned_start' } });
+ expect(out.startDateField).toBe('planned_start');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('keeps the `name` title floor — a display default is not a date axis', () => {
+ // Deliberately NOT removed by this card, and the same rung
+ // `timelineViewOptions` carries. `ObjectGantt` floors the title itself too.
+ expect(ganttViewOptions({}).titleField).toBe('name');
+ expect(ganttViewOptions({ gantt: { titleField: 'subject' } }).titleField).toBe('subject');
+ });
+});
+
+describe('no invented gantt date name survives in the source (objectui#7070)', () => {
+ const SOURCE = readFileSync(
+ path.join(path.dirname(fileURLToPath(import.meta.url)), 'ObjectView.tsx'),
+ 'utf8',
+ );
+
+ /**
+ * Executable lines only. The prose above this file's own seams names
+ * `'start_date'` / `'end_date'` repeatedly — that is the record of what was
+ * deleted, and a scan that counted it would be red on a correct tree. Same
+ * filter, and same reason, as the objectui#7029 scan next door.
+ */
+ const CODE = SOURCE.split('\n').filter((l) => !/^\s*(\*|\/\*|\/\/)/.test(l));
+
+ it("the fabricated 'start_date' / 'end_date' floors are gone from this face's CODE", () => {
+ // A structural tripwire, not a restatement of the cases above: these are
+ // what a future copy-paste from a sibling branch would reintroduce, and they
+ // are invisible to a behavioural test on any object that happens to carry
+ // real `start_date` / `end_date` fields — which is exactly how the defect
+ // survived (hotcrm's `crm_leave_request` carries both).
+ expect(CODE.filter((l) => l.includes("'start_date'"))).toEqual([]);
+ expect(CODE.filter((l) => l.includes("'end_date'"))).toEqual([]);
+ });
+
+ it('CONTROL: the scan can still see a literal that IS there', () => {
+ // Without this the case above is green on any tree where the filter simply
+ // matches nothing. `'image'` is the gallery branch's `imageField … ||
+ // 'image'` floor — the same one-rung class, still present, out of scope for
+ // this card. ⚠️ If you retire it, RE-ANCHOR this control onto whatever
+ // fabrication legitimately remains; do not delete it. (The twin of this
+ // control in `ObjectView.calendarBinding-7029.test.tsx` carries the same
+ // instruction, and explains why in full.)
+ expect(CODE.filter((l) => l.includes("'image'")).length).toBeGreaterThan(0);
+ });
+
+ it('CONTROL: the scan reads CODE, not the prose that records the deletion', () => {
+ // The filter's own correctness. The seam comments above `ganttViewOptions`
+ // name both deleted literals; if the filter ever stopped stripping comment
+ // lines, the case above would go red on a CORRECT tree and invite someone to
+ // weaken it.
+ expect(SOURCE.includes("`'start_date'`")).toBe(true);
+ expect(CODE.filter((l) => l.includes("'start_date'"))).toEqual([]);
+ });
+});

.changeset/7070-no-invented-gantt-date-fields.md

@@ -0,0 +1,53 @@
+---
+'@object-ui/app-shell': minor
+'@object-ui/plugin-list': minor
+'@object-ui/plugin-view': minor
+---
+
+Gantt views no longer render on invented date field names (objectui#7070).
+
+The half PR #7062 fenced out and reported separately. A view that carried no
+`gantt:` block used to have a complete-looking date axis synthesized for it:
+all three faces floored `startDateField` at `'start_date'` and `endDateField`
+at `'end_date'` — field names no view had written and most objects do not
+carry.
+
+`ObjectGantt.getGanttConfig` takes its flat branch as soon as BOTH date props
+are present, so the fabricated pair short-circuited the renderer's own refusal
+screen — "Gantt configuration required. Please specify startDateField,
+endDateField, and titleField." — which existed all along and was simply
+unreachable from every route. The same fabrication answered ADR-0047's
+capability gate in `ListView.availableViews`, so the Gantt toggle was live on
+every object view in the product.
+
+⚠️ The premise was MEASURED before anything was deleted, because #7029's
+mechanic is only correct where a refusal path exists and that had never been
+established for this renderer: on the unmodified tree, `ObjectGantt` REFUSES an
+absent binding — it does not render empty, and it does not throw.
+
+Three faces were fabricating, on two independent routes to the same renderer:
+
+- `app-shell/src/views/ObjectView.tsx` — the console object page. The inline
+ branch becomes `ganttViewOptions`, the sibling of `calendarViewOptions` and
+ `timelineViewOptions`: the declared block spread whole, title floored at
+ `'name'`, no date field invented.
+- `plugin-list/src/ListView.tsx` — the render branch AND the capability gate.
+- `plugin-view/src/ObjectView.tsx` — `generateViewSchema`, the authored
+ `object-view` element route, which bypasses `ListView` entirely.
+
+**What changes for an author.** A view that declared no gantt configuration is
+no longer offered the Gantt toggle, and one forced onto the renderer reaches
+the refusal screen instead of a plausible, fully wrong chart. A view that
+declared a binding is unaffected — the declared block is forwarded exactly as
+before, every spec key included.
+
+Also corrected: the objectui#3129 note at the top of `app-shell/ObjectView.tsx`
+certified the gantt branch below it as already using the safe two-rung shape.
+It did not. The note now states each sibling branch as measured, and says
+explicitly which fabrication REMAINS — the timeline `'created_at'` floor at the
+two plugin faces, which objectui#7070 routes to a ruling rather than settling
+per-face.
+
+Deliberately out of scope, and left in place: `progressField` / `dependenciesField`
+(not date axes, different absent-value semantics) and the timeline `'created_at'`
+posture conflict.

packages/app-shell/src/views/ObjectView.calendarBinding-7029.test.tsx

@@ -130,12 +130,44 @@ describe('no invented calendar field name survives in the source (objectui#7029)
  expect(CODE.filter((l) => /calendar\?\.titleField \|\| 'name'/.test(l))).toEqual([]);
  });
 
- it('CONTROL: the scan can still see a literal that IS there', () => {
- // Without this the two cases above are green on any tree where the filter
- // simply matches nothing — the failure mode that made the first spelling of
- // this scan a phantom check. The gantt branch still carries its own
- // `'start_date'` floor (same class, separately reported, deliberately NOT
- // touched by this card), so it is the honest positive control.
- expect(CODE.filter((l) => l.includes("'start_date'")).length).toBeGreaterThan(0);
+ /**
+ * ⭐ THE POSITIVE CONTROL — read this before changing either case below.
+ *
+ * Without a control the two cases above are green on any tree where the filter
+ * simply matches nothing: the failure mode that made the first spelling of
+ * this scan a phantom check. This control was originally a single case
+ * anchored on the gantt branch's own `'start_date'` floor ("same class,
+ * separately reported, deliberately NOT touched by this card").
+ *
+ * objectui#7070 is that separate report, and fixing it deleted the anchor —
+ * `'start_date'` is now absent from this face's CODE, so the original control
+ * would have gone red. ⛔ It was NOT simply removed: a scan whose last live
+ * control is dropped becomes a test that passes over nothing, which is the
+ * exact class this whole card family is about. It is re-expressed as TWO
+ * controls that answer two different questions:
+ */
+
+ it('CONTROL (machinery): the scan can see a literal that IS there', () => {
+ // Can this filter return a non-empty result at all? Anchored on `'name'`,
+ // which is DELIBERATELY permanent here — the display-name floor the
+ // objectui#3129 note above the seams describes as what stays. It is not a
+ // fabricated field name, so no future card of this family retires it, and
+ // this control cannot go red as a side effect of the next fix.
+ expect(CODE.filter((l) => l.includes("'name'")).length).toBeGreaterThan(0);
+ });
+
+ it('CONTROL (same class): the scan still sees a REMAINING fabricated field name', () => {
+ // Can this filter see the specific thing it exists to hunt — a one-rung
+ // `|| 'literal'` field-name floor? Anchored on the gallery branch's
+ // `imageField: … || 'image'`, which is the same class, is still there, and
+ // is out of scope for both objectui#7029 and objectui#7070.
+ //
+ // ⚠️ TO WHOEVER RETIRES `'image'`: this going red is the mechanic working,
+ // not a broken test. RE-ANCHOR it onto whatever fabrication legitimately
+ // remains in this file — do not delete it, and do not weaken it to the
+ // machinery control above. If nothing of this class remains anywhere in this
+ // face, say so in the PR body and convert this case into the assertion that
+ // NONE remains, so the scan keeps making a claim about the tree.
+ expect(CODE.filter((l) => l.includes("'image'")).length).toBeGreaterThan(0);
  });
 });

packages/app-shell/src/views/ObjectView.ganttBinding-7070.test.tsx

@@ -0,0 +1,161 @@
+/**
+ * ObjectUI
+ * Copyright (c) 2024-present ObjectStack Inc.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ */
+
+/**
+ * objectui#7070 — the object page must not invent a GANTT date binding.
+ *
+ * The sibling of `ObjectView.calendarBinding-7029` next door, and the half PR
+ * #7062 fenced out and reported separately. This face floored
+ * `startDateField` at `'start_date'` and `endDateField` at `'end_date'` for
+ * EVERY object view, declared or not. Downstream that is indistinguishable
+ * from a real binding: `ObjectGantt.getGanttConfig` takes its flat branch as
+ * soon as BOTH date props are present, so the fabrication made the renderer's
+ * own "Gantt configuration required" screen unreachable from this route, and it
+ * answered ADR-0047's capability gate (`options.gantt.startDateField`) so the
+ * Gantt toggle was live on every object view in the product.
+ *
+ * ⚠️ THE PREMISE WAS MEASURED BEFORE THE DELETION. #7029's mechanic — delete the
+ * literal, let the renderer's own refusal answer — is only correct where a
+ * refusal path exists, and that had never been established for gantt. It was,
+ * on the unmodified tree, before this file's fix was written: `ObjectGantt`
+ * REFUSES an absent binding (it does not render empty, and does not throw). The
+ * seam is pinned in `plugin-gantt/src/ObjectGantt.unconfiguredRefusal-7070`.
+ *
+ * REVERSE VERIFICATION — direction predicted before running, then observed:
+ * restore `startDateField: viewDef.gantt?.startDateField || 'start_date'` and
+ * its `endDateField` twin, and the "invents NO date field" cases below go RED
+ * (they read the fabricated names) while every declared-config CONTROL stays
+ * GREEN in either world — the fabricated value is only ever observable when the
+ * view declared nothing. That asymmetry is the point: a fix that emitted an
+ * empty config for EVERY view would also pass a refusal-only test.
+ */
+
+import { describe, it, expect } from 'vitest';
+import { readFileSync } from 'node:fs';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+import { ganttViewOptions } from './ObjectView';
+
+describe('ganttViewOptions — the object page forwards, it does not invent (objectui#7070)', () => {
+ it('invents NO date field for a view that declares no gantt config', () => {
+ // THE DEFECT. This used to return `{ startDateField: 'start_date',
+ // endDateField: 'end_date', titleField: 'name' }` — a complete-looking axis
+ // for a view that configured nothing, which is what short-circuited the
+ // renderer's refusal screen and lit the Gantt toggle everywhere.
+ expect(ganttViewOptions({})).toEqual({ titleField: 'name' });
+ expect(ganttViewOptions(undefined)).toEqual({ titleField: 'name' });
+ expect(ganttViewOptions({ label: 'All', columns: ['name'] })).toEqual({ titleField: 'name' });
+ });
+
+ it('invents no date field for a view whose neighbouring blocks ARE declared', () => {
+ // A view bound for kanban/calendar must not acquire a gantt axis by
+ // proximity — the Gantt toggle it would light up has nothing behind it.
+ const out = ganttViewOptions({
+ kanban: { groupByField: 'stage' },
+ calendar: { startDateField: 'start_date' },
+ });
+ expect(out).not.toHaveProperty('startDateField');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('invents no date field for an EMPTY gantt block', () => {
+ // The half-written declaration: `allowedVisualizations: ['gantt']` with
+ // nothing under `gantt:`. It must stay half-written all the way down.
+ const out = ganttViewOptions({ gantt: {} });
+ expect(out).not.toHaveProperty('startDateField');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('CONTROL: forwards a fully declared block verbatim — every spec key survives', () => {
+ // A bare whitelist here once dropped every field past `colorField` and
+ // flattened the chart, so the spread is load-bearing, not incidental.
+ const out = ganttViewOptions({
+ gantt: {
+ startDateField: 'planned_start',
+ endDateField: 'planned_end',
+ titleField: 'subject',
+ parentField: 'parent',
+ typeField: 'node_type',
+ baselineStartField: 'bl_start',
+ groupByField: 'owner',
+ tooltipFields: [{ field: 'owner' }],
+ },
+ });
+ expect(out).toMatchObject({
+ startDateField: 'planned_start',
+ endDateField: 'planned_end',
+ titleField: 'subject',
+ parentField: 'parent',
+ typeField: 'node_type',
+ baselineStartField: 'bl_start',
+ groupByField: 'owner',
+ tooltipFields: [{ field: 'owner' }],
+ });
+ });
+
+ it('CONTROL: a HALF-declared axis keeps its declared rung and only that', () => {
+ // One date field is not a gantt: `getGanttConfig`'s flat branch needs BOTH,
+ // so this shape reaches the refusal screen rather than rendering on a name
+ // nobody wrote.
+ const out = ganttViewOptions({ gantt: { startDateField: 'planned_start' } });
+ expect(out.startDateField).toBe('planned_start');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('keeps the `name` title floor — a display default is not a date axis', () => {
+ // Deliberately NOT removed by this card, and the same rung
+ // `timelineViewOptions` carries. `ObjectGantt` floors the title itself too.
+ expect(ganttViewOptions({}).titleField).toBe('name');
+ expect(ganttViewOptions({ gantt: { titleField: 'subject' } }).titleField).toBe('subject');
+ });
+});
+
+describe('no invented gantt date name survives in the source (objectui#7070)', () => {
+ const SOURCE = readFileSync(
+ path.join(path.dirname(fileURLToPath(import.meta.url)), 'ObjectView.tsx'),
+ 'utf8',
+ );
+
+ /**
+ * Executable lines only. The prose above this file's own seams names
+ * `'start_date'` / `'end_date'` repeatedly — that is the record of what was
+ * deleted, and a scan that counted it would be red on a correct tree. Same
+ * filter, and same reason, as the objectui#7029 scan next door.
+ */
+ const CODE = SOURCE.split('\n').filter((l) => !/^\s*(\*|\/\*|\/\/)/.test(l));
+
+ it("the fabricated 'start_date' / 'end_date' floors are gone from this face's CODE", () => {
+ // A structural tripwire, not a restatement of the cases above: these are
+ // what a future copy-paste from a sibling branch would reintroduce, and they
+ // are invisible to a behavioural test on any object that happens to carry
+ // real `start_date` / `end_date` fields — which is exactly how the defect
+ // survived (hotcrm's `crm_leave_request` carries both).
+ expect(CODE.filter((l) => l.includes("'start_date'"))).toEqual([]);
+ expect(CODE.filter((l) => l.includes("'end_date'"))).toEqual([]);
+ });
+
+ it('CONTROL: the scan can still see a literal that IS there', () => {
+ // Without this the case above is green on any tree where the filter simply
+ // matches nothing. `'image'` is the gallery branch's `imageField … ||
+ // 'image'` floor — the same one-rung class, still present, out of scope for
+ // this card. ⚠️ If you retire it, RE-ANCHOR this control onto whatever
+ // fabrication legitimately remains; do not delete it. (The twin of this
+ // control in `ObjectView.calendarBinding-7029.test.tsx` carries the same
+ // instruction, and explains why in full.)
+ expect(CODE.filter((l) => l.includes("'image'")).length).toBeGreaterThan(0);
+ });
+
+ it('CONTROL: the scan reads CODE, not the prose that records the deletion', () => {
+ // The filter's own correctness. The seam comments above `ganttViewOptions`
+ // name both deleted literals; if the filter ever stopped stripping comment
+ // lines, the case above would go red on a CORRECT tree and invite someone to
+ // weaken it.
+ expect(SOURCE.includes("`'start_date'`")).toBe(true);
+ expect(CODE.filter((l) => l.includes("'start_date'"))).toEqual([]);
+ });
+});

.changeset/7070-no-invented-gantt-date-fields.md

@@ -0,0 +1,53 @@
+---
+'@object-ui/app-shell': minor
+'@object-ui/plugin-list': minor
+'@object-ui/plugin-view': minor
+---
+
+Gantt views no longer render on invented date field names (objectui#7070).
+
+The half PR #7062 fenced out and reported separately. A view that carried no
+`gantt:` block used to have a complete-looking date axis synthesized for it:
+all three faces floored `startDateField` at `'start_date'` and `endDateField`
+at `'end_date'` — field names no view had written and most objects do not
+carry.
+
+`ObjectGantt.getGanttConfig` takes its flat branch as soon as BOTH date props
+are present, so the fabricated pair short-circuited the renderer's own refusal
+screen — "Gantt configuration required. Please specify startDateField,
+endDateField, and titleField." — which existed all along and was simply
+unreachable from every route. The same fabrication answered ADR-0047's
+capability gate in `ListView.availableViews`, so the Gantt toggle was live on
+every object view in the product.
+
+⚠️ The premise was MEASURED before anything was deleted, because #7029's
+mechanic is only correct where a refusal path exists and that had never been
+established for this renderer: on the unmodified tree, `ObjectGantt` REFUSES an
+absent binding — it does not render empty, and it does not throw.
+
+Three faces were fabricating, on two independent routes to the same renderer:
+
+- `app-shell/src/views/ObjectView.tsx` — the console object page. The inline
+ branch becomes `ganttViewOptions`, the sibling of `calendarViewOptions` and
+ `timelineViewOptions`: the declared block spread whole, title floored at
+ `'name'`, no date field invented.
+- `plugin-list/src/ListView.tsx` — the render branch AND the capability gate.
+- `plugin-view/src/ObjectView.tsx` — `generateViewSchema`, the authored
+ `object-view` element route, which bypasses `ListView` entirely.
+
+**What changes for an author.** A view that declared no gantt configuration is
+no longer offered the Gantt toggle, and one forced onto the renderer reaches
+the refusal screen instead of a plausible, fully wrong chart. A view that
+declared a binding is unaffected — the declared block is forwarded exactly as
+before, every spec key included.
+
+Also corrected: the objectui#3129 note at the top of `app-shell/ObjectView.tsx`
+certified the gantt branch below it as already using the safe two-rung shape.
+It did not. The note now states each sibling branch as measured, and says
+explicitly which fabrication REMAINS — the timeline `'created_at'` floor at the
+two plugin faces, which objectui#7070 routes to a ruling rather than settling
+per-face.
+
+Deliberately out of scope, and left in place: `progressField` / `dependenciesField`
+(not date axes, different absent-value semantics) and the timeline `'created_at'`
+posture conflict.

packages/app-shell/src/views/ObjectView.calendarBinding-7029.test.tsx

@@ -130,12 +130,44 @@ describe('no invented calendar field name survives in the source (objectui#7029)
  expect(CODE.filter((l) => /calendar\?\.titleField \|\| 'name'/.test(l))).toEqual([]);
  });
 
- it('CONTROL: the scan can still see a literal that IS there', () => {
- // Without this the two cases above are green on any tree where the filter
- // simply matches nothing — the failure mode that made the first spelling of
- // this scan a phantom check. The gantt branch still carries its own
- // `'start_date'` floor (same class, separately reported, deliberately NOT
- // touched by this card), so it is the honest positive control.
- expect(CODE.filter((l) => l.includes("'start_date'")).length).toBeGreaterThan(0);
+ /**
+ * ⭐ THE POSITIVE CONTROL — read this before changing either case below.
+ *
+ * Without a control the two cases above are green on any tree where the filter
+ * simply matches nothing: the failure mode that made the first spelling of
+ * this scan a phantom check. This control was originally a single case
+ * anchored on the gantt branch's own `'start_date'` floor ("same class,
+ * separately reported, deliberately NOT touched by this card").
+ *
+ * objectui#7070 is that separate report, and fixing it deleted the anchor —
+ * `'start_date'` is now absent from this face's CODE, so the original control
+ * would have gone red. ⛔ It was NOT simply removed: a scan whose last live
+ * control is dropped becomes a test that passes over nothing, which is the
+ * exact class this whole card family is about. It is re-expressed as TWO
+ * controls that answer two different questions:
+ */
+
+ it('CONTROL (machinery): the scan can see a literal that IS there', () => {
+ // Can this filter return a non-empty result at all? Anchored on `'name'`,
+ // which is DELIBERATELY permanent here — the display-name floor the
+ // objectui#3129 note above the seams describes as what stays. It is not a
+ // fabricated field name, so no future card of this family retires it, and
+ // this control cannot go red as a side effect of the next fix.
+ expect(CODE.filter((l) => l.includes("'name'")).length).toBeGreaterThan(0);
+ });
+
+ it('CONTROL (same class): the scan still sees a REMAINING fabricated field name', () => {
+ // Can this filter see the specific thing it exists to hunt — a one-rung
+ // `|| 'literal'` field-name floor? Anchored on the gallery branch's
+ // `imageField: … || 'image'`, which is the same class, is still there, and
+ // is out of scope for both objectui#7029 and objectui#7070.
+ //
+ // ⚠️ TO WHOEVER RETIRES `'image'`: this going red is the mechanic working,
+ // not a broken test. RE-ANCHOR it onto whatever fabrication legitimately
+ // remains in this file — do not delete it, and do not weaken it to the
+ // machinery control above. If nothing of this class remains anywhere in this
+ // face, say so in the PR body and convert this case into the assertion that
+ // NONE remains, so the scan keeps making a claim about the tree.
+ expect(CODE.filter((l) => l.includes("'image'")).length).toBeGreaterThan(0);
  });
 });

packages/app-shell/src/views/ObjectView.ganttBinding-7070.test.tsx

@@ -0,0 +1,161 @@
+/**
+ * ObjectUI
+ * Copyright (c) 2024-present ObjectStack Inc.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ */
+
+/**
+ * objectui#7070 — the object page must not invent a GANTT date binding.
+ *
+ * The sibling of `ObjectView.calendarBinding-7029` next door, and the half PR
+ * #7062 fenced out and reported separately. This face floored
+ * `startDateField` at `'start_date'` and `endDateField` at `'end_date'` for
+ * EVERY object view, declared or not. Downstream that is indistinguishable
+ * from a real binding: `ObjectGantt.getGanttConfig` takes its flat branch as
+ * soon as BOTH date props are present, so the fabrication made the renderer's
+ * own "Gantt configuration required" screen unreachable from this route, and it
+ * answered ADR-0047's capability gate (`options.gantt.startDateField`) so the
+ * Gantt toggle was live on every object view in the product.
+ *
+ * ⚠️ THE PREMISE WAS MEASURED BEFORE THE DELETION. #7029's mechanic — delete the
+ * literal, let the renderer's own refusal answer — is only correct where a
+ * refusal path exists, and that had never been established for gantt. It was,
+ * on the unmodified tree, before this file's fix was written: `ObjectGantt`
+ * REFUSES an absent binding (it does not render empty, and does not throw). The
+ * seam is pinned in `plugin-gantt/src/ObjectGantt.unconfiguredRefusal-7070`.
+ *
+ * REVERSE VERIFICATION — direction predicted before running, then observed:
+ * restore `startDateField: viewDef.gantt?.startDateField || 'start_date'` and
+ * its `endDateField` twin, and the "invents NO date field" cases below go RED
+ * (they read the fabricated names) while every declared-config CONTROL stays
+ * GREEN in either world — the fabricated value is only ever observable when the
+ * view declared nothing. That asymmetry is the point: a fix that emitted an
+ * empty config for EVERY view would also pass a refusal-only test.
+ */
+
+import { describe, it, expect } from 'vitest';
+import { readFileSync } from 'node:fs';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+import { ganttViewOptions } from './ObjectView';
+
+describe('ganttViewOptions — the object page forwards, it does not invent (objectui#7070)', () => {
+ it('invents NO date field for a view that declares no gantt config', () => {
+ // THE DEFECT. This used to return `{ startDateField: 'start_date',
+ // endDateField: 'end_date', titleField: 'name' }` — a complete-looking axis
+ // for a view that configured nothing, which is what short-circuited the
+ // renderer's refusal screen and lit the Gantt toggle everywhere.
+ expect(ganttViewOptions({})).toEqual({ titleField: 'name' });
+ expect(ganttViewOptions(undefined)).toEqual({ titleField: 'name' });
+ expect(ganttViewOptions({ label: 'All', columns: ['name'] })).toEqual({ titleField: 'name' });
+ });
+
+ it('invents no date field for a view whose neighbouring blocks ARE declared', () => {
+ // A view bound for kanban/calendar must not acquire a gantt axis by
+ // proximity — the Gantt toggle it would light up has nothing behind it.
+ const out = ganttViewOptions({
+ kanban: { groupByField: 'stage' },
+ calendar: { startDateField: 'start_date' },
+ });
+ expect(out).not.toHaveProperty('startDateField');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('invents no date field for an EMPTY gantt block', () => {
+ // The half-written declaration: `allowedVisualizations: ['gantt']` with
+ // nothing under `gantt:`. It must stay half-written all the way down.
+ const out = ganttViewOptions({ gantt: {} });
+ expect(out).not.toHaveProperty('startDateField');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('CONTROL: forwards a fully declared block verbatim — every spec key survives', () => {
+ // A bare whitelist here once dropped every field past `colorField` and
+ // flattened the chart, so the spread is load-bearing, not incidental.
+ const out = ganttViewOptions({
+ gantt: {
+ startDateField: 'planned_start',
+ endDateField: 'planned_end',
+ titleField: 'subject',
+ parentField: 'parent',
+ typeField: 'node_type',
+ baselineStartField: 'bl_start',
+ groupByField: 'owner',
+ tooltipFields: [{ field: 'owner' }],
+ },
+ });
+ expect(out).toMatchObject({
+ startDateField: 'planned_start',
+ endDateField: 'planned_end',
+ titleField: 'subject',
+ parentField: 'parent',
+ typeField: 'node_type',
+ baselineStartField: 'bl_start',
+ groupByField: 'owner',
+ tooltipFields: [{ field: 'owner' }],
+ });
+ });
+
+ it('CONTROL: a HALF-declared axis keeps its declared rung and only that', () => {
+ // One date field is not a gantt: `getGanttConfig`'s flat branch needs BOTH,
+ // so this shape reaches the refusal screen rather than rendering on a name
+ // nobody wrote.
+ const out = ganttViewOptions({ gantt: { startDateField: 'planned_start' } });
+ expect(out.startDateField).toBe('planned_start');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('keeps the `name` title floor — a display default is not a date axis', () => {
+ // Deliberately NOT removed by this card, and the same rung
+ // `timelineViewOptions` carries. `ObjectGantt` floors the title itself too.
+ expect(ganttViewOptions({}).titleField).toBe('name');
+ expect(ganttViewOptions({ gantt: { titleField: 'subject' } }).titleField).toBe('subject');
+ });
+});
+
+describe('no invented gantt date name survives in the source (objectui#7070)', () => {
+ const SOURCE = readFileSync(
+ path.join(path.dirname(fileURLToPath(import.meta.url)), 'ObjectView.tsx'),
+ 'utf8',
+ );
+
+ /**
+ * Executable lines only. The prose above this file's own seams names
+ * `'start_date'` / `'end_date'` repeatedly — that is the record of what was
+ * deleted, and a scan that counted it would be red on a correct tree. Same
+ * filter, and same reason, as the objectui#7029 scan next door.
+ */
+ const CODE = SOURCE.split('\n').filter((l) => !/^\s*(\*|\/\*|\/\/)/.test(l));
+
+ it("the fabricated 'start_date' / 'end_date' floors are gone from this face's CODE", () => {
+ // A structural tripwire, not a restatement of the cases above: these are
+ // what a future copy-paste from a sibling branch would reintroduce, and they
+ // are invisible to a behavioural test on any object that happens to carry
+ // real `start_date` / `end_date` fields — which is exactly how the defect
+ // survived (hotcrm's `crm_leave_request` carries both).
+ expect(CODE.filter((l) => l.includes("'start_date'"))).toEqual([]);
+ expect(CODE.filter((l) => l.includes("'end_date'"))).toEqual([]);
+ });
+
+ it('CONTROL: the scan can still see a literal that IS there', () => {
+ // Without this the case above is green on any tree where the filter simply
+ // matches nothing. `'image'` is the gallery branch's `imageField … ||
+ // 'image'` floor — the same one-rung class, still present, out of scope for
+ // this card. ⚠️ If you retire it, RE-ANCHOR this control onto whatever
+ // fabrication legitimately remains; do not delete it. (The twin of this
+ // control in `ObjectView.calendarBinding-7029.test.tsx` carries the same
+ // instruction, and explains why in full.)
+ expect(CODE.filter((l) => l.includes("'image'")).length).toBeGreaterThan(0);
+ });
+
+ it('CONTROL: the scan reads CODE, not the prose that records the deletion', () => {
+ // The filter's own correctness. The seam comments above `ganttViewOptions`
+ // name both deleted literals; if the filter ever stopped stripping comment
+ // lines, the case above would go red on a CORRECT tree and invite someone to
+ // weaken it.
+ expect(SOURCE.includes("`'start_date'`")).toBe(true);
+ expect(CODE.filter((l) => l.includes("'start_date'"))).toEqual([]);
+ });
+});

.changeset/7070-no-invented-gantt-date-fields.md

@@ -0,0 +1,53 @@
+---
+'@object-ui/app-shell': minor
+'@object-ui/plugin-list': minor
+'@object-ui/plugin-view': minor
+---
+
+Gantt views no longer render on invented date field names (objectui#7070).
+
+The half PR #7062 fenced out and reported separately. A view that carried no
+`gantt:` block used to have a complete-looking date axis synthesized for it:
+all three faces floored `startDateField` at `'start_date'` and `endDateField`
+at `'end_date'` — field names no view had written and most objects do not
+carry.
+
+`ObjectGantt.getGanttConfig` takes its flat branch as soon as BOTH date props
+are present, so the fabricated pair short-circuited the renderer's own refusal
+screen — "Gantt configuration required. Please specify startDateField,
+endDateField, and titleField." — which existed all along and was simply
+unreachable from every route. The same fabrication answered ADR-0047's
+capability gate in `ListView.availableViews`, so the Gantt toggle was live on
+every object view in the product.
+
+⚠️ The premise was MEASURED before anything was deleted, because #7029's
+mechanic is only correct where a refusal path exists and that had never been
+established for this renderer: on the unmodified tree, `ObjectGantt` REFUSES an
+absent binding — it does not render empty, and it does not throw.
+
+Three faces were fabricating, on two independent routes to the same renderer:
+
+- `app-shell/src/views/ObjectView.tsx` — the console object page. The inline
+ branch becomes `ganttViewOptions`, the sibling of `calendarViewOptions` and
+ `timelineViewOptions`: the declared block spread whole, title floored at
+ `'name'`, no date field invented.
+- `plugin-list/src/ListView.tsx` — the render branch AND the capability gate.
+- `plugin-view/src/ObjectView.tsx` — `generateViewSchema`, the authored
+ `object-view` element route, which bypasses `ListView` entirely.
+
+**What changes for an author.** A view that declared no gantt configuration is
+no longer offered the Gantt toggle, and one forced onto the renderer reaches
+the refusal screen instead of a plausible, fully wrong chart. A view that
+declared a binding is unaffected — the declared block is forwarded exactly as
+before, every spec key included.
+
+Also corrected: the objectui#3129 note at the top of `app-shell/ObjectView.tsx`
+certified the gantt branch below it as already using the safe two-rung shape.
+It did not. The note now states each sibling branch as measured, and says
+explicitly which fabrication REMAINS — the timeline `'created_at'` floor at the
+two plugin faces, which objectui#7070 routes to a ruling rather than settling
+per-face.
+
+Deliberately out of scope, and left in place: `progressField` / `dependenciesField`
+(not date axes, different absent-value semantics) and the timeline `'created_at'`
+posture conflict.

packages/app-shell/src/views/ObjectView.calendarBinding-7029.test.tsx

@@ -130,12 +130,44 @@ describe('no invented calendar field name survives in the source (objectui#7029)
  expect(CODE.filter((l) => /calendar\?\.titleField \|\| 'name'/.test(l))).toEqual([]);
  });
 
- it('CONTROL: the scan can still see a literal that IS there', () => {
- // Without this the two cases above are green on any tree where the filter
- // simply matches nothing — the failure mode that made the first spelling of
- // this scan a phantom check. The gantt branch still carries its own
- // `'start_date'` floor (same class, separately reported, deliberately NOT
- // touched by this card), so it is the honest positive control.
- expect(CODE.filter((l) => l.includes("'start_date'")).length).toBeGreaterThan(0);
+ /**
+ * ⭐ THE POSITIVE CONTROL — read this before changing either case below.
+ *
+ * Without a control the two cases above are green on any tree where the filter
+ * simply matches nothing: the failure mode that made the first spelling of
+ * this scan a phantom check. This control was originally a single case
+ * anchored on the gantt branch's own `'start_date'` floor ("same class,
+ * separately reported, deliberately NOT touched by this card").
+ *
+ * objectui#7070 is that separate report, and fixing it deleted the anchor —
+ * `'start_date'` is now absent from this face's CODE, so the original control
+ * would have gone red. ⛔ It was NOT simply removed: a scan whose last live
+ * control is dropped becomes a test that passes over nothing, which is the
+ * exact class this whole card family is about. It is re-expressed as TWO
+ * controls that answer two different questions:
+ */
+
+ it('CONTROL (machinery): the scan can see a literal that IS there', () => {
+ // Can this filter return a non-empty result at all? Anchored on `'name'`,
+ // which is DELIBERATELY permanent here — the display-name floor the
+ // objectui#3129 note above the seams describes as what stays. It is not a
+ // fabricated field name, so no future card of this family retires it, and
+ // this control cannot go red as a side effect of the next fix.
+ expect(CODE.filter((l) => l.includes("'name'")).length).toBeGreaterThan(0);
+ });
+
+ it('CONTROL (same class): the scan still sees a REMAINING fabricated field name', () => {
+ // Can this filter see the specific thing it exists to hunt — a one-rung
+ // `|| 'literal'` field-name floor? Anchored on the gallery branch's
+ // `imageField: … || 'image'`, which is the same class, is still there, and
+ // is out of scope for both objectui#7029 and objectui#7070.
+ //
+ // ⚠️ TO WHOEVER RETIRES `'image'`: this going red is the mechanic working,
+ // not a broken test. RE-ANCHOR it onto whatever fabrication legitimately
+ // remains in this file — do not delete it, and do not weaken it to the
+ // machinery control above. If nothing of this class remains anywhere in this
+ // face, say so in the PR body and convert this case into the assertion that
+ // NONE remains, so the scan keeps making a claim about the tree.
+ expect(CODE.filter((l) => l.includes("'image'")).length).toBeGreaterThan(0);
  });
 });

packages/app-shell/src/views/ObjectView.ganttBinding-7070.test.tsx

@@ -0,0 +1,161 @@
+/**
+ * ObjectUI
+ * Copyright (c) 2024-present ObjectStack Inc.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ */
+
+/**
+ * objectui#7070 — the object page must not invent a GANTT date binding.
+ *
+ * The sibling of `ObjectView.calendarBinding-7029` next door, and the half PR
+ * #7062 fenced out and reported separately. This face floored
+ * `startDateField` at `'start_date'` and `endDateField` at `'end_date'` for
+ * EVERY object view, declared or not. Downstream that is indistinguishable
+ * from a real binding: `ObjectGantt.getGanttConfig` takes its flat branch as
+ * soon as BOTH date props are present, so the fabrication made the renderer's
+ * own "Gantt configuration required" screen unreachable from this route, and it
+ * answered ADR-0047's capability gate (`options.gantt.startDateField`) so the
+ * Gantt toggle was live on every object view in the product.
+ *
+ * ⚠️ THE PREMISE WAS MEASURED BEFORE THE DELETION. #7029's mechanic — delete the
+ * literal, let the renderer's own refusal answer — is only correct where a
+ * refusal path exists, and that had never been established for gantt. It was,
+ * on the unmodified tree, before this file's fix was written: `ObjectGantt`
+ * REFUSES an absent binding (it does not render empty, and does not throw). The
+ * seam is pinned in `plugin-gantt/src/ObjectGantt.unconfiguredRefusal-7070`.
+ *
+ * REVERSE VERIFICATION — direction predicted before running, then observed:
+ * restore `startDateField: viewDef.gantt?.startDateField || 'start_date'` and
+ * its `endDateField` twin, and the "invents NO date field" cases below go RED
+ * (they read the fabricated names) while every declared-config CONTROL stays
+ * GREEN in either world — the fabricated value is only ever observable when the
+ * view declared nothing. That asymmetry is the point: a fix that emitted an
+ * empty config for EVERY view would also pass a refusal-only test.
+ */
+
+import { describe, it, expect } from 'vitest';
+import { readFileSync } from 'node:fs';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+import { ganttViewOptions } from './ObjectView';
+
+describe('ganttViewOptions — the object page forwards, it does not invent (objectui#7070)', () => {
+ it('invents NO date field for a view that declares no gantt config', () => {
+ // THE DEFECT. This used to return `{ startDateField: 'start_date',
+ // endDateField: 'end_date', titleField: 'name' }` — a complete-looking axis
+ // for a view that configured nothing, which is what short-circuited the
+ // renderer's refusal screen and lit the Gantt toggle everywhere.
+ expect(ganttViewOptions({})).toEqual({ titleField: 'name' });
+ expect(ganttViewOptions(undefined)).toEqual({ titleField: 'name' });
+ expect(ganttViewOptions({ label: 'All', columns: ['name'] })).toEqual({ titleField: 'name' });
+ });
+
+ it('invents no date field for a view whose neighbouring blocks ARE declared', () => {
+ // A view bound for kanban/calendar must not acquire a gantt axis by
+ // proximity — the Gantt toggle it would light up has nothing behind it.
+ const out = ganttViewOptions({
+ kanban: { groupByField: 'stage' },
+ calendar: { startDateField: 'start_date' },
+ });
+ expect(out).not.toHaveProperty('startDateField');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('invents no date field for an EMPTY gantt block', () => {
+ // The half-written declaration: `allowedVisualizations: ['gantt']` with
+ // nothing under `gantt:`. It must stay half-written all the way down.
+ const out = ganttViewOptions({ gantt: {} });
+ expect(out).not.toHaveProperty('startDateField');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('CONTROL: forwards a fully declared block verbatim — every spec key survives', () => {
+ // A bare whitelist here once dropped every field past `colorField` and
+ // flattened the chart, so the spread is load-bearing, not incidental.
+ const out = ganttViewOptions({
+ gantt: {
+ startDateField: 'planned_start',
+ endDateField: 'planned_end',
+ titleField: 'subject',
+ parentField: 'parent',
+ typeField: 'node_type',
+ baselineStartField: 'bl_start',
+ groupByField: 'owner',
+ tooltipFields: [{ field: 'owner' }],
+ },
+ });
+ expect(out).toMatchObject({
+ startDateField: 'planned_start',
+ endDateField: 'planned_end',
+ titleField: 'subject',
+ parentField: 'parent',
+ typeField: 'node_type',
+ baselineStartField: 'bl_start',
+ groupByField: 'owner',
+ tooltipFields: [{ field: 'owner' }],
+ });
+ });
+
+ it('CONTROL: a HALF-declared axis keeps its declared rung and only that', () => {
+ // One date field is not a gantt: `getGanttConfig`'s flat branch needs BOTH,
+ // so this shape reaches the refusal screen rather than rendering on a name
+ // nobody wrote.
+ const out = ganttViewOptions({ gantt: { startDateField: 'planned_start' } });
+ expect(out.startDateField).toBe('planned_start');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('keeps the `name` title floor — a display default is not a date axis', () => {
+ // Deliberately NOT removed by this card, and the same rung
+ // `timelineViewOptions` carries. `ObjectGantt` floors the title itself too.
+ expect(ganttViewOptions({}).titleField).toBe('name');
+ expect(ganttViewOptions({ gantt: { titleField: 'subject' } }).titleField).toBe('subject');
+ });
+});
+
+describe('no invented gantt date name survives in the source (objectui#7070)', () => {
+ const SOURCE = readFileSync(
+ path.join(path.dirname(fileURLToPath(import.meta.url)), 'ObjectView.tsx'),
+ 'utf8',
+ );
+
+ /**
+ * Executable lines only. The prose above this file's own seams names
+ * `'start_date'` / `'end_date'` repeatedly — that is the record of what was
+ * deleted, and a scan that counted it would be red on a correct tree. Same
+ * filter, and same reason, as the objectui#7029 scan next door.
+ */
+ const CODE = SOURCE.split('\n').filter((l) => !/^\s*(\*|\/\*|\/\/)/.test(l));
+
+ it("the fabricated 'start_date' / 'end_date' floors are gone from this face's CODE", () => {
+ // A structural tripwire, not a restatement of the cases above: these are
+ // what a future copy-paste from a sibling branch would reintroduce, and they
+ // are invisible to a behavioural test on any object that happens to carry
+ // real `start_date` / `end_date` fields — which is exactly how the defect
+ // survived (hotcrm's `crm_leave_request` carries both).
+ expect(CODE.filter((l) => l.includes("'start_date'"))).toEqual([]);
+ expect(CODE.filter((l) => l.includes("'end_date'"))).toEqual([]);
+ });
+
+ it('CONTROL: the scan can still see a literal that IS there', () => {
+ // Without this the case above is green on any tree where the filter simply
+ // matches nothing. `'image'` is the gallery branch's `imageField … ||
+ // 'image'` floor — the same one-rung class, still present, out of scope for
+ // this card. ⚠️ If you retire it, RE-ANCHOR this control onto whatever
+ // fabrication legitimately remains; do not delete it. (The twin of this
+ // control in `ObjectView.calendarBinding-7029.test.tsx` carries the same
+ // instruction, and explains why in full.)
+ expect(CODE.filter((l) => l.includes("'image'")).length).toBeGreaterThan(0);
+ });
+
+ it('CONTROL: the scan reads CODE, not the prose that records the deletion', () => {
+ // The filter's own correctness. The seam comments above `ganttViewOptions`
+ // name both deleted literals; if the filter ever stopped stripping comment
+ // lines, the case above would go red on a CORRECT tree and invite someone to
+ // weaken it.
+ expect(SOURCE.includes("`'start_date'`")).toBe(true);
+ expect(CODE.filter((l) => l.includes("'start_date'"))).toEqual([]);
+ });
+});

.changeset/7070-no-invented-gantt-date-fields.md

@@ -0,0 +1,53 @@
+---
+'@object-ui/app-shell': minor
+'@object-ui/plugin-list': minor
+'@object-ui/plugin-view': minor
+---
+
+Gantt views no longer render on invented date field names (objectui#7070).
+
+The half PR #7062 fenced out and reported separately. A view that carried no
+`gantt:` block used to have a complete-looking date axis synthesized for it:
+all three faces floored `startDateField` at `'start_date'` and `endDateField`
+at `'end_date'` — field names no view had written and most objects do not
+carry.
+
+`ObjectGantt.getGanttConfig` takes its flat branch as soon as BOTH date props
+are present, so the fabricated pair short-circuited the renderer's own refusal
+screen — "Gantt configuration required. Please specify startDateField,
+endDateField, and titleField." — which existed all along and was simply
+unreachable from every route. The same fabrication answered ADR-0047's
+capability gate in `ListView.availableViews`, so the Gantt toggle was live on
+every object view in the product.
+
+⚠️ The premise was MEASURED before anything was deleted, because #7029's
+mechanic is only correct where a refusal path exists and that had never been
+established for this renderer: on the unmodified tree, `ObjectGantt` REFUSES an
+absent binding — it does not render empty, and it does not throw.
+
+Three faces were fabricating, on two independent routes to the same renderer:
+
+- `app-shell/src/views/ObjectView.tsx` — the console object page. The inline
+ branch becomes `ganttViewOptions`, the sibling of `calendarViewOptions` and
+ `timelineViewOptions`: the declared block spread whole, title floored at
+ `'name'`, no date field invented.
+- `plugin-list/src/ListView.tsx` — the render branch AND the capability gate.
+- `plugin-view/src/ObjectView.tsx` — `generateViewSchema`, the authored
+ `object-view` element route, which bypasses `ListView` entirely.
+
+**What changes for an author.** A view that declared no gantt configuration is
+no longer offered the Gantt toggle, and one forced onto the renderer reaches
+the refusal screen instead of a plausible, fully wrong chart. A view that
+declared a binding is unaffected — the declared block is forwarded exactly as
+before, every spec key included.
+
+Also corrected: the objectui#3129 note at the top of `app-shell/ObjectView.tsx`
+certified the gantt branch below it as already using the safe two-rung shape.
+It did not. The note now states each sibling branch as measured, and says
+explicitly which fabrication REMAINS — the timeline `'created_at'` floor at the
+two plugin faces, which objectui#7070 routes to a ruling rather than settling
+per-face.
+
+Deliberately out of scope, and left in place: `progressField` / `dependenciesField`
+(not date axes, different absent-value semantics) and the timeline `'created_at'`
+posture conflict.

packages/app-shell/src/views/ObjectView.calendarBinding-7029.test.tsx

@@ -130,12 +130,44 @@ describe('no invented calendar field name survives in the source (objectui#7029)
  expect(CODE.filter((l) => /calendar\?\.titleField \|\| 'name'/.test(l))).toEqual([]);
  });
 
- it('CONTROL: the scan can still see a literal that IS there', () => {
- // Without this the two cases above are green on any tree where the filter
- // simply matches nothing — the failure mode that made the first spelling of
- // this scan a phantom check. The gantt branch still carries its own
- // `'start_date'` floor (same class, separately reported, deliberately NOT
- // touched by this card), so it is the honest positive control.
- expect(CODE.filter((l) => l.includes("'start_date'")).length).toBeGreaterThan(0);
+ /**
+ * ⭐ THE POSITIVE CONTROL — read this before changing either case below.
+ *
+ * Without a control the two cases above are green on any tree where the filter
+ * simply matches nothing: the failure mode that made the first spelling of
+ * this scan a phantom check. This control was originally a single case
+ * anchored on the gantt branch's own `'start_date'` floor ("same class,
+ * separately reported, deliberately NOT touched by this card").
+ *
+ * objectui#7070 is that separate report, and fixing it deleted the anchor —
+ * `'start_date'` is now absent from this face's CODE, so the original control
+ * would have gone red. ⛔ It was NOT simply removed: a scan whose last live
+ * control is dropped becomes a test that passes over nothing, which is the
+ * exact class this whole card family is about. It is re-expressed as TWO
+ * controls that answer two different questions:
+ */
+
+ it('CONTROL (machinery): the scan can see a literal that IS there', () => {
+ // Can this filter return a non-empty result at all? Anchored on `'name'`,
+ // which is DELIBERATELY permanent here — the display-name floor the
+ // objectui#3129 note above the seams describes as what stays. It is not a
+ // fabricated field name, so no future card of this family retires it, and
+ // this control cannot go red as a side effect of the next fix.
+ expect(CODE.filter((l) => l.includes("'name'")).length).toBeGreaterThan(0);
+ });
+
+ it('CONTROL (same class): the scan still sees a REMAINING fabricated field name', () => {
+ // Can this filter see the specific thing it exists to hunt — a one-rung
+ // `|| 'literal'` field-name floor? Anchored on the gallery branch's
+ // `imageField: … || 'image'`, which is the same class, is still there, and
+ // is out of scope for both objectui#7029 and objectui#7070.
+ //
+ // ⚠️ TO WHOEVER RETIRES `'image'`: this going red is the mechanic working,
+ // not a broken test. RE-ANCHOR it onto whatever fabrication legitimately
+ // remains in this file — do not delete it, and do not weaken it to the
+ // machinery control above. If nothing of this class remains anywhere in this
+ // face, say so in the PR body and convert this case into the assertion that
+ // NONE remains, so the scan keeps making a claim about the tree.
+ expect(CODE.filter((l) => l.includes("'image'")).length).toBeGreaterThan(0);
  });
 });

packages/app-shell/src/views/ObjectView.ganttBinding-7070.test.tsx

@@ -0,0 +1,161 @@
+/**
+ * ObjectUI
+ * Copyright (c) 2024-present ObjectStack Inc.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ */
+
+/**
+ * objectui#7070 — the object page must not invent a GANTT date binding.
+ *
+ * The sibling of `ObjectView.calendarBinding-7029` next door, and the half PR
+ * #7062 fenced out and reported separately. This face floored
+ * `startDateField` at `'start_date'` and `endDateField` at `'end_date'` for
+ * EVERY object view, declared or not. Downstream that is indistinguishable
+ * from a real binding: `ObjectGantt.getGanttConfig` takes its flat branch as
+ * soon as BOTH date props are present, so the fabrication made the renderer's
+ * own "Gantt configuration required" screen unreachable from this route, and it
+ * answered ADR-0047's capability gate (`options.gantt.startDateField`) so the
+ * Gantt toggle was live on every object view in the product.
+ *
+ * ⚠️ THE PREMISE WAS MEASURED BEFORE THE DELETION. #7029's mechanic — delete the
+ * literal, let the renderer's own refusal answer — is only correct where a
+ * refusal path exists, and that had never been established for gantt. It was,
+ * on the unmodified tree, before this file's fix was written: `ObjectGantt`
+ * REFUSES an absent binding (it does not render empty, and does not throw). The
+ * seam is pinned in `plugin-gantt/src/ObjectGantt.unconfiguredRefusal-7070`.
+ *
+ * REVERSE VERIFICATION — direction predicted before running, then observed:
+ * restore `startDateField: viewDef.gantt?.startDateField || 'start_date'` and
+ * its `endDateField` twin, and the "invents NO date field" cases below go RED
+ * (they read the fabricated names) while every declared-config CONTROL stays
+ * GREEN in either world — the fabricated value is only ever observable when the
+ * view declared nothing. That asymmetry is the point: a fix that emitted an
+ * empty config for EVERY view would also pass a refusal-only test.
+ */
+
+import { describe, it, expect } from 'vitest';
+import { readFileSync } from 'node:fs';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+import { ganttViewOptions } from './ObjectView';
+
+describe('ganttViewOptions — the object page forwards, it does not invent (objectui#7070)', () => {
+ it('invents NO date field for a view that declares no gantt config', () => {
+ // THE DEFECT. This used to return `{ startDateField: 'start_date',
+ // endDateField: 'end_date', titleField: 'name' }` — a complete-looking axis
+ // for a view that configured nothing, which is what short-circuited the
+ // renderer's refusal screen and lit the Gantt toggle everywhere.
+ expect(ganttViewOptions({})).toEqual({ titleField: 'name' });
+ expect(ganttViewOptions(undefined)).toEqual({ titleField: 'name' });
+ expect(ganttViewOptions({ label: 'All', columns: ['name'] })).toEqual({ titleField: 'name' });
+ });
+
+ it('invents no date field for a view whose neighbouring blocks ARE declared', () => {
+ // A view bound for kanban/calendar must not acquire a gantt axis by
+ // proximity — the Gantt toggle it would light up has nothing behind it.
+ const out = ganttViewOptions({
+ kanban: { groupByField: 'stage' },
+ calendar: { startDateField: 'start_date' },
+ });
+ expect(out).not.toHaveProperty('startDateField');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('invents no date field for an EMPTY gantt block', () => {
+ // The half-written declaration: `allowedVisualizations: ['gantt']` with
+ // nothing under `gantt:`. It must stay half-written all the way down.
+ const out = ganttViewOptions({ gantt: {} });
+ expect(out).not.toHaveProperty('startDateField');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('CONTROL: forwards a fully declared block verbatim — every spec key survives', () => {
+ // A bare whitelist here once dropped every field past `colorField` and
+ // flattened the chart, so the spread is load-bearing, not incidental.
+ const out = ganttViewOptions({
+ gantt: {
+ startDateField: 'planned_start',
+ endDateField: 'planned_end',
+ titleField: 'subject',
+ parentField: 'parent',
+ typeField: 'node_type',
+ baselineStartField: 'bl_start',
+ groupByField: 'owner',
+ tooltipFields: [{ field: 'owner' }],
+ },
+ });
+ expect(out).toMatchObject({
+ startDateField: 'planned_start',
+ endDateField: 'planned_end',
+ titleField: 'subject',
+ parentField: 'parent',
+ typeField: 'node_type',
+ baselineStartField: 'bl_start',
+ groupByField: 'owner',
+ tooltipFields: [{ field: 'owner' }],
+ });
+ });
+
+ it('CONTROL: a HALF-declared axis keeps its declared rung and only that', () => {
+ // One date field is not a gantt: `getGanttConfig`'s flat branch needs BOTH,
+ // so this shape reaches the refusal screen rather than rendering on a name
+ // nobody wrote.
+ const out = ganttViewOptions({ gantt: { startDateField: 'planned_start' } });
+ expect(out.startDateField).toBe('planned_start');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('keeps the `name` title floor — a display default is not a date axis', () => {
+ // Deliberately NOT removed by this card, and the same rung
+ // `timelineViewOptions` carries. `ObjectGantt` floors the title itself too.
+ expect(ganttViewOptions({}).titleField).toBe('name');
+ expect(ganttViewOptions({ gantt: { titleField: 'subject' } }).titleField).toBe('subject');
+ });
+});
+
+describe('no invented gantt date name survives in the source (objectui#7070)', () => {
+ const SOURCE = readFileSync(
+ path.join(path.dirname(fileURLToPath(import.meta.url)), 'ObjectView.tsx'),
+ 'utf8',
+ );
+
+ /**
+ * Executable lines only. The prose above this file's own seams names
+ * `'start_date'` / `'end_date'` repeatedly — that is the record of what was
+ * deleted, and a scan that counted it would be red on a correct tree. Same
+ * filter, and same reason, as the objectui#7029 scan next door.
+ */
+ const CODE = SOURCE.split('\n').filter((l) => !/^\s*(\*|\/\*|\/\/)/.test(l));
+
+ it("the fabricated 'start_date' / 'end_date' floors are gone from this face's CODE", () => {
+ // A structural tripwire, not a restatement of the cases above: these are
+ // what a future copy-paste from a sibling branch would reintroduce, and they
+ // are invisible to a behavioural test on any object that happens to carry
+ // real `start_date` / `end_date` fields — which is exactly how the defect
+ // survived (hotcrm's `crm_leave_request` carries both).
+ expect(CODE.filter((l) => l.includes("'start_date'"))).toEqual([]);
+ expect(CODE.filter((l) => l.includes("'end_date'"))).toEqual([]);
+ });
+
+ it('CONTROL: the scan can still see a literal that IS there', () => {
+ // Without this the case above is green on any tree where the filter simply
+ // matches nothing. `'image'` is the gallery branch's `imageField … ||
+ // 'image'` floor — the same one-rung class, still present, out of scope for
+ // this card. ⚠️ If you retire it, RE-ANCHOR this control onto whatever
+ // fabrication legitimately remains; do not delete it. (The twin of this
+ // control in `ObjectView.calendarBinding-7029.test.tsx` carries the same
+ // instruction, and explains why in full.)
+ expect(CODE.filter((l) => l.includes("'image'")).length).toBeGreaterThan(0);
+ });
+
+ it('CONTROL: the scan reads CODE, not the prose that records the deletion', () => {
+ // The filter's own correctness. The seam comments above `ganttViewOptions`
+ // name both deleted literals; if the filter ever stopped stripping comment
+ // lines, the case above would go red on a CORRECT tree and invite someone to
+ // weaken it.
+ expect(SOURCE.includes("`'start_date'`")).toBe(true);
+ expect(CODE.filter((l) => l.includes("'start_date'"))).toEqual([]);
+ });
+});

.changeset/7070-no-invented-gantt-date-fields.md

@@ -0,0 +1,53 @@
+---
+'@object-ui/app-shell': minor
+'@object-ui/plugin-list': minor
+'@object-ui/plugin-view': minor
+---
+
+Gantt views no longer render on invented date field names (objectui#7070).
+
+The half PR #7062 fenced out and reported separately. A view that carried no
+`gantt:` block used to have a complete-looking date axis synthesized for it:
+all three faces floored `startDateField` at `'start_date'` and `endDateField`
+at `'end_date'` — field names no view had written and most objects do not
+carry.
+
+`ObjectGantt.getGanttConfig` takes its flat branch as soon as BOTH date props
+are present, so the fabricated pair short-circuited the renderer's own refusal
+screen — "Gantt configuration required. Please specify startDateField,
+endDateField, and titleField." — which existed all along and was simply
+unreachable from every route. The same fabrication answered ADR-0047's
+capability gate in `ListView.availableViews`, so the Gantt toggle was live on
+every object view in the product.
+
+⚠️ The premise was MEASURED before anything was deleted, because #7029's
+mechanic is only correct where a refusal path exists and that had never been
+established for this renderer: on the unmodified tree, `ObjectGantt` REFUSES an
+absent binding — it does not render empty, and it does not throw.
+
+Three faces were fabricating, on two independent routes to the same renderer:
+
+- `app-shell/src/views/ObjectView.tsx` — the console object page. The inline
+ branch becomes `ganttViewOptions`, the sibling of `calendarViewOptions` and
+ `timelineViewOptions`: the declared block spread whole, title floored at
+ `'name'`, no date field invented.
+- `plugin-list/src/ListView.tsx` — the render branch AND the capability gate.
+- `plugin-view/src/ObjectView.tsx` — `generateViewSchema`, the authored
+ `object-view` element route, which bypasses `ListView` entirely.
+
+**What changes for an author.** A view that declared no gantt configuration is
+no longer offered the Gantt toggle, and one forced onto the renderer reaches
+the refusal screen instead of a plausible, fully wrong chart. A view that
+declared a binding is unaffected — the declared block is forwarded exactly as
+before, every spec key included.
+
+Also corrected: the objectui#3129 note at the top of `app-shell/ObjectView.tsx`
+certified the gantt branch below it as already using the safe two-rung shape.
+It did not. The note now states each sibling branch as measured, and says
+explicitly which fabrication REMAINS — the timeline `'created_at'` floor at the
+two plugin faces, which objectui#7070 routes to a ruling rather than settling
+per-face.
+
+Deliberately out of scope, and left in place: `progressField` / `dependenciesField`
+(not date axes, different absent-value semantics) and the timeline `'created_at'`
+posture conflict.

packages/app-shell/src/views/ObjectView.calendarBinding-7029.test.tsx

@@ -130,12 +130,44 @@ describe('no invented calendar field name survives in the source (objectui#7029)
  expect(CODE.filter((l) => /calendar\?\.titleField \|\| 'name'/.test(l))).toEqual([]);
  });
 
- it('CONTROL: the scan can still see a literal that IS there', () => {
- // Without this the two cases above are green on any tree where the filter
- // simply matches nothing — the failure mode that made the first spelling of
- // this scan a phantom check. The gantt branch still carries its own
- // `'start_date'` floor (same class, separately reported, deliberately NOT
- // touched by this card), so it is the honest positive control.
- expect(CODE.filter((l) => l.includes("'start_date'")).length).toBeGreaterThan(0);
+ /**
+ * ⭐ THE POSITIVE CONTROL — read this before changing either case below.
+ *
+ * Without a control the two cases above are green on any tree where the filter
+ * simply matches nothing: the failure mode that made the first spelling of
+ * this scan a phantom check. This control was originally a single case
+ * anchored on the gantt branch's own `'start_date'` floor ("same class,
+ * separately reported, deliberately NOT touched by this card").
+ *
+ * objectui#7070 is that separate report, and fixing it deleted the anchor —
+ * `'start_date'` is now absent from this face's CODE, so the original control
+ * would have gone red. ⛔ It was NOT simply removed: a scan whose last live
+ * control is dropped becomes a test that passes over nothing, which is the
+ * exact class this whole card family is about. It is re-expressed as TWO
+ * controls that answer two different questions:
+ */
+
+ it('CONTROL (machinery): the scan can see a literal that IS there', () => {
+ // Can this filter return a non-empty result at all? Anchored on `'name'`,
+ // which is DELIBERATELY permanent here — the display-name floor the
+ // objectui#3129 note above the seams describes as what stays. It is not a
+ // fabricated field name, so no future card of this family retires it, and
+ // this control cannot go red as a side effect of the next fix.
+ expect(CODE.filter((l) => l.includes("'name'")).length).toBeGreaterThan(0);
+ });
+
+ it('CONTROL (same class): the scan still sees a REMAINING fabricated field name', () => {
+ // Can this filter see the specific thing it exists to hunt — a one-rung
+ // `|| 'literal'` field-name floor? Anchored on the gallery branch's
+ // `imageField: … || 'image'`, which is the same class, is still there, and
+ // is out of scope for both objectui#7029 and objectui#7070.
+ //
+ // ⚠️ TO WHOEVER RETIRES `'image'`: this going red is the mechanic working,
+ // not a broken test. RE-ANCHOR it onto whatever fabrication legitimately
+ // remains in this file — do not delete it, and do not weaken it to the
+ // machinery control above. If nothing of this class remains anywhere in this
+ // face, say so in the PR body and convert this case into the assertion that
+ // NONE remains, so the scan keeps making a claim about the tree.
+ expect(CODE.filter((l) => l.includes("'image'")).length).toBeGreaterThan(0);
  });
 });

packages/app-shell/src/views/ObjectView.ganttBinding-7070.test.tsx

@@ -0,0 +1,161 @@
+/**
+ * ObjectUI
+ * Copyright (c) 2024-present ObjectStack Inc.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ */
+
+/**
+ * objectui#7070 — the object page must not invent a GANTT date binding.
+ *
+ * The sibling of `ObjectView.calendarBinding-7029` next door, and the half PR
+ * #7062 fenced out and reported separately. This face floored
+ * `startDateField` at `'start_date'` and `endDateField` at `'end_date'` for
+ * EVERY object view, declared or not. Downstream that is indistinguishable
+ * from a real binding: `ObjectGantt.getGanttConfig` takes its flat branch as
+ * soon as BOTH date props are present, so the fabrication made the renderer's
+ * own "Gantt configuration required" screen unreachable from this route, and it
+ * answered ADR-0047's capability gate (`options.gantt.startDateField`) so the
+ * Gantt toggle was live on every object view in the product.
+ *
+ * ⚠️ THE PREMISE WAS MEASURED BEFORE THE DELETION. #7029's mechanic — delete the
+ * literal, let the renderer's own refusal answer — is only correct where a
+ * refusal path exists, and that had never been established for gantt. It was,
+ * on the unmodified tree, before this file's fix was written: `ObjectGantt`
+ * REFUSES an absent binding (it does not render empty, and does not throw). The
+ * seam is pinned in `plugin-gantt/src/ObjectGantt.unconfiguredRefusal-7070`.
+ *
+ * REVERSE VERIFICATION — direction predicted before running, then observed:
+ * restore `startDateField: viewDef.gantt?.startDateField || 'start_date'` and
+ * its `endDateField` twin, and the "invents NO date field" cases below go RED
+ * (they read the fabricated names) while every declared-config CONTROL stays
+ * GREEN in either world — the fabricated value is only ever observable when the
+ * view declared nothing. That asymmetry is the point: a fix that emitted an
+ * empty config for EVERY view would also pass a refusal-only test.
+ */
+
+import { describe, it, expect } from 'vitest';
+import { readFileSync } from 'node:fs';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+import { ganttViewOptions } from './ObjectView';
+
+describe('ganttViewOptions — the object page forwards, it does not invent (objectui#7070)', () => {
+ it('invents NO date field for a view that declares no gantt config', () => {
+ // THE DEFECT. This used to return `{ startDateField: 'start_date',
+ // endDateField: 'end_date', titleField: 'name' }` — a complete-looking axis
+ // for a view that configured nothing, which is what short-circuited the
+ // renderer's refusal screen and lit the Gantt toggle everywhere.
+ expect(ganttViewOptions({})).toEqual({ titleField: 'name' });
+ expect(ganttViewOptions(undefined)).toEqual({ titleField: 'name' });
+ expect(ganttViewOptions({ label: 'All', columns: ['name'] })).toEqual({ titleField: 'name' });
+ });
+
+ it('invents no date field for a view whose neighbouring blocks ARE declared', () => {
+ // A view bound for kanban/calendar must not acquire a gantt axis by
+ // proximity — the Gantt toggle it would light up has nothing behind it.
+ const out = ganttViewOptions({
+ kanban: { groupByField: 'stage' },
+ calendar: { startDateField: 'start_date' },
+ });
+ expect(out).not.toHaveProperty('startDateField');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('invents no date field for an EMPTY gantt block', () => {
+ // The half-written declaration: `allowedVisualizations: ['gantt']` with
+ // nothing under `gantt:`. It must stay half-written all the way down.
+ const out = ganttViewOptions({ gantt: {} });
+ expect(out).not.toHaveProperty('startDateField');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('CONTROL: forwards a fully declared block verbatim — every spec key survives', () => {
+ // A bare whitelist here once dropped every field past `colorField` and
+ // flattened the chart, so the spread is load-bearing, not incidental.
+ const out = ganttViewOptions({
+ gantt: {
+ startDateField: 'planned_start',
+ endDateField: 'planned_end',
+ titleField: 'subject',
+ parentField: 'parent',
+ typeField: 'node_type',
+ baselineStartField: 'bl_start',
+ groupByField: 'owner',
+ tooltipFields: [{ field: 'owner' }],
+ },
+ });
+ expect(out).toMatchObject({
+ startDateField: 'planned_start',
+ endDateField: 'planned_end',
+ titleField: 'subject',
+ parentField: 'parent',
+ typeField: 'node_type',
+ baselineStartField: 'bl_start',
+ groupByField: 'owner',
+ tooltipFields: [{ field: 'owner' }],
+ });
+ });
+
+ it('CONTROL: a HALF-declared axis keeps its declared rung and only that', () => {
+ // One date field is not a gantt: `getGanttConfig`'s flat branch needs BOTH,
+ // so this shape reaches the refusal screen rather than rendering on a name
+ // nobody wrote.
+ const out = ganttViewOptions({ gantt: { startDateField: 'planned_start' } });
+ expect(out.startDateField).toBe('planned_start');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('keeps the `name` title floor — a display default is not a date axis', () => {
+ // Deliberately NOT removed by this card, and the same rung
+ // `timelineViewOptions` carries. `ObjectGantt` floors the title itself too.
+ expect(ganttViewOptions({}).titleField).toBe('name');
+ expect(ganttViewOptions({ gantt: { titleField: 'subject' } }).titleField).toBe('subject');
+ });
+});
+
+describe('no invented gantt date name survives in the source (objectui#7070)', () => {
+ const SOURCE = readFileSync(
+ path.join(path.dirname(fileURLToPath(import.meta.url)), 'ObjectView.tsx'),
+ 'utf8',
+ );
+
+ /**
+ * Executable lines only. The prose above this file's own seams names
+ * `'start_date'` / `'end_date'` repeatedly — that is the record of what was
+ * deleted, and a scan that counted it would be red on a correct tree. Same
+ * filter, and same reason, as the objectui#7029 scan next door.
+ */
+ const CODE = SOURCE.split('\n').filter((l) => !/^\s*(\*|\/\*|\/\/)/.test(l));
+
+ it("the fabricated 'start_date' / 'end_date' floors are gone from this face's CODE", () => {
+ // A structural tripwire, not a restatement of the cases above: these are
+ // what a future copy-paste from a sibling branch would reintroduce, and they
+ // are invisible to a behavioural test on any object that happens to carry
+ // real `start_date` / `end_date` fields — which is exactly how the defect
+ // survived (hotcrm's `crm_leave_request` carries both).
+ expect(CODE.filter((l) => l.includes("'start_date'"))).toEqual([]);
+ expect(CODE.filter((l) => l.includes("'end_date'"))).toEqual([]);
+ });
+
+ it('CONTROL: the scan can still see a literal that IS there', () => {
+ // Without this the case above is green on any tree where the filter simply
+ // matches nothing. `'image'` is the gallery branch's `imageField … ||
+ // 'image'` floor — the same one-rung class, still present, out of scope for
+ // this card. ⚠️ If you retire it, RE-ANCHOR this control onto whatever
+ // fabrication legitimately remains; do not delete it. (The twin of this
+ // control in `ObjectView.calendarBinding-7029.test.tsx` carries the same
+ // instruction, and explains why in full.)
+ expect(CODE.filter((l) => l.includes("'image'")).length).toBeGreaterThan(0);
+ });
+
+ it('CONTROL: the scan reads CODE, not the prose that records the deletion', () => {
+ // The filter's own correctness. The seam comments above `ganttViewOptions`
+ // name both deleted literals; if the filter ever stopped stripping comment
+ // lines, the case above would go red on a CORRECT tree and invite someone to
+ // weaken it.
+ expect(SOURCE.includes("`'start_date'`")).toBe(true);
+ expect(CODE.filter((l) => l.includes("'start_date'"))).toEqual([]);
+ });
+});

.changeset/7070-no-invented-gantt-date-fields.md

@@ -0,0 +1,53 @@
+---
+'@object-ui/app-shell': minor
+'@object-ui/plugin-list': minor
+'@object-ui/plugin-view': minor
+---
+
+Gantt views no longer render on invented date field names (objectui#7070).
+
+The half PR #7062 fenced out and reported separately. A view that carried no
+`gantt:` block used to have a complete-looking date axis synthesized for it:
+all three faces floored `startDateField` at `'start_date'` and `endDateField`
+at `'end_date'` — field names no view had written and most objects do not
+carry.
+
+`ObjectGantt.getGanttConfig` takes its flat branch as soon as BOTH date props
+are present, so the fabricated pair short-circuited the renderer's own refusal
+screen — "Gantt configuration required. Please specify startDateField,
+endDateField, and titleField." — which existed all along and was simply
+unreachable from every route. The same fabrication answered ADR-0047's
+capability gate in `ListView.availableViews`, so the Gantt toggle was live on
+every object view in the product.
+
+⚠️ The premise was MEASURED before anything was deleted, because #7029's
+mechanic is only correct where a refusal path exists and that had never been
+established for this renderer: on the unmodified tree, `ObjectGantt` REFUSES an
+absent binding — it does not render empty, and it does not throw.
+
+Three faces were fabricating, on two independent routes to the same renderer:
+
+- `app-shell/src/views/ObjectView.tsx` — the console object page. The inline
+ branch becomes `ganttViewOptions`, the sibling of `calendarViewOptions` and
+ `timelineViewOptions`: the declared block spread whole, title floored at
+ `'name'`, no date field invented.
+- `plugin-list/src/ListView.tsx` — the render branch AND the capability gate.
+- `plugin-view/src/ObjectView.tsx` — `generateViewSchema`, the authored
+ `object-view` element route, which bypasses `ListView` entirely.
+
+**What changes for an author.** A view that declared no gantt configuration is
+no longer offered the Gantt toggle, and one forced onto the renderer reaches
+the refusal screen instead of a plausible, fully wrong chart. A view that
+declared a binding is unaffected — the declared block is forwarded exactly as
+before, every spec key included.
+
+Also corrected: the objectui#3129 note at the top of `app-shell/ObjectView.tsx`
+certified the gantt branch below it as already using the safe two-rung shape.
+It did not. The note now states each sibling branch as measured, and says
+explicitly which fabrication REMAINS — the timeline `'created_at'` floor at the
+two plugin faces, which objectui#7070 routes to a ruling rather than settling
+per-face.
+
+Deliberately out of scope, and left in place: `progressField` / `dependenciesField`
+(not date axes, different absent-value semantics) and the timeline `'created_at'`
+posture conflict.

packages/app-shell/src/views/ObjectView.calendarBinding-7029.test.tsx

@@ -130,12 +130,44 @@ describe('no invented calendar field name survives in the source (objectui#7029)
  expect(CODE.filter((l) => /calendar\?\.titleField \|\| 'name'/.test(l))).toEqual([]);
  });
 
- it('CONTROL: the scan can still see a literal that IS there', () => {
- // Without this the two cases above are green on any tree where the filter
- // simply matches nothing — the failure mode that made the first spelling of
- // this scan a phantom check. The gantt branch still carries its own
- // `'start_date'` floor (same class, separately reported, deliberately NOT
- // touched by this card), so it is the honest positive control.
- expect(CODE.filter((l) => l.includes("'start_date'")).length).toBeGreaterThan(0);
+ /**
+ * ⭐ THE POSITIVE CONTROL — read this before changing either case below.
+ *
+ * Without a control the two cases above are green on any tree where the filter
+ * simply matches nothing: the failure mode that made the first spelling of
+ * this scan a phantom check. This control was originally a single case
+ * anchored on the gantt branch's own `'start_date'` floor ("same class,
+ * separately reported, deliberately NOT touched by this card").
+ *
+ * objectui#7070 is that separate report, and fixing it deleted the anchor —
+ * `'start_date'` is now absent from this face's CODE, so the original control
+ * would have gone red. ⛔ It was NOT simply removed: a scan whose last live
+ * control is dropped becomes a test that passes over nothing, which is the
+ * exact class this whole card family is about. It is re-expressed as TWO
+ * controls that answer two different questions:
+ */
+
+ it('CONTROL (machinery): the scan can see a literal that IS there', () => {
+ // Can this filter return a non-empty result at all? Anchored on `'name'`,
+ // which is DELIBERATELY permanent here — the display-name floor the
+ // objectui#3129 note above the seams describes as what stays. It is not a
+ // fabricated field name, so no future card of this family retires it, and
+ // this control cannot go red as a side effect of the next fix.
+ expect(CODE.filter((l) => l.includes("'name'")).length).toBeGreaterThan(0);
+ });
+
+ it('CONTROL (same class): the scan still sees a REMAINING fabricated field name', () => {
+ // Can this filter see the specific thing it exists to hunt — a one-rung
+ // `|| 'literal'` field-name floor? Anchored on the gallery branch's
+ // `imageField: … || 'image'`, which is the same class, is still there, and
+ // is out of scope for both objectui#7029 and objectui#7070.
+ //
+ // ⚠️ TO WHOEVER RETIRES `'image'`: this going red is the mechanic working,
+ // not a broken test. RE-ANCHOR it onto whatever fabrication legitimately
+ // remains in this file — do not delete it, and do not weaken it to the
+ // machinery control above. If nothing of this class remains anywhere in this
+ // face, say so in the PR body and convert this case into the assertion that
+ // NONE remains, so the scan keeps making a claim about the tree.
+ expect(CODE.filter((l) => l.includes("'image'")).length).toBeGreaterThan(0);
  });
 });

packages/app-shell/src/views/ObjectView.ganttBinding-7070.test.tsx

@@ -0,0 +1,161 @@
+/**
+ * ObjectUI
+ * Copyright (c) 2024-present ObjectStack Inc.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ */
+
+/**
+ * objectui#7070 — the object page must not invent a GANTT date binding.
+ *
+ * The sibling of `ObjectView.calendarBinding-7029` next door, and the half PR
+ * #7062 fenced out and reported separately. This face floored
+ * `startDateField` at `'start_date'` and `endDateField` at `'end_date'` for
+ * EVERY object view, declared or not. Downstream that is indistinguishable
+ * from a real binding: `ObjectGantt.getGanttConfig` takes its flat branch as
+ * soon as BOTH date props are present, so the fabrication made the renderer's
+ * own "Gantt configuration required" screen unreachable from this route, and it
+ * answered ADR-0047's capability gate (`options.gantt.startDateField`) so the
+ * Gantt toggle was live on every object view in the product.
+ *
+ * ⚠️ THE PREMISE WAS MEASURED BEFORE THE DELETION. #7029's mechanic — delete the
+ * literal, let the renderer's own refusal answer — is only correct where a
+ * refusal path exists, and that had never been established for gantt. It was,
+ * on the unmodified tree, before this file's fix was written: `ObjectGantt`
+ * REFUSES an absent binding (it does not render empty, and does not throw). The
+ * seam is pinned in `plugin-gantt/src/ObjectGantt.unconfiguredRefusal-7070`.
+ *
+ * REVERSE VERIFICATION — direction predicted before running, then observed:
+ * restore `startDateField: viewDef.gantt?.startDateField || 'start_date'` and
+ * its `endDateField` twin, and the "invents NO date field" cases below go RED
+ * (they read the fabricated names) while every declared-config CONTROL stays
+ * GREEN in either world — the fabricated value is only ever observable when the
+ * view declared nothing. That asymmetry is the point: a fix that emitted an
+ * empty config for EVERY view would also pass a refusal-only test.
+ */
+
+import { describe, it, expect } from 'vitest';
+import { readFileSync } from 'node:fs';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+import { ganttViewOptions } from './ObjectView';
+
+describe('ganttViewOptions — the object page forwards, it does not invent (objectui#7070)', () => {
+ it('invents NO date field for a view that declares no gantt config', () => {
+ // THE DEFECT. This used to return `{ startDateField: 'start_date',
+ // endDateField: 'end_date', titleField: 'name' }` — a complete-looking axis
+ // for a view that configured nothing, which is what short-circuited the
+ // renderer's refusal screen and lit the Gantt toggle everywhere.
+ expect(ganttViewOptions({})).toEqual({ titleField: 'name' });
+ expect(ganttViewOptions(undefined)).toEqual({ titleField: 'name' });
+ expect(ganttViewOptions({ label: 'All', columns: ['name'] })).toEqual({ titleField: 'name' });
+ });
+
+ it('invents no date field for a view whose neighbouring blocks ARE declared', () => {
+ // A view bound for kanban/calendar must not acquire a gantt axis by
+ // proximity — the Gantt toggle it would light up has nothing behind it.
+ const out = ganttViewOptions({
+ kanban: { groupByField: 'stage' },
+ calendar: { startDateField: 'start_date' },
+ });
+ expect(out).not.toHaveProperty('startDateField');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('invents no date field for an EMPTY gantt block', () => {
+ // The half-written declaration: `allowedVisualizations: ['gantt']` with
+ // nothing under `gantt:`. It must stay half-written all the way down.
+ const out = ganttViewOptions({ gantt: {} });
+ expect(out).not.toHaveProperty('startDateField');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('CONTROL: forwards a fully declared block verbatim — every spec key survives', () => {
+ // A bare whitelist here once dropped every field past `colorField` and
+ // flattened the chart, so the spread is load-bearing, not incidental.
+ const out = ganttViewOptions({
+ gantt: {
+ startDateField: 'planned_start',
+ endDateField: 'planned_end',
+ titleField: 'subject',
+ parentField: 'parent',
+ typeField: 'node_type',
+ baselineStartField: 'bl_start',
+ groupByField: 'owner',
+ tooltipFields: [{ field: 'owner' }],
+ },
+ });
+ expect(out).toMatchObject({
+ startDateField: 'planned_start',
+ endDateField: 'planned_end',
+ titleField: 'subject',
+ parentField: 'parent',
+ typeField: 'node_type',
+ baselineStartField: 'bl_start',
+ groupByField: 'owner',
+ tooltipFields: [{ field: 'owner' }],
+ });
+ });
+
+ it('CONTROL: a HALF-declared axis keeps its declared rung and only that', () => {
+ // One date field is not a gantt: `getGanttConfig`'s flat branch needs BOTH,
+ // so this shape reaches the refusal screen rather than rendering on a name
+ // nobody wrote.
+ const out = ganttViewOptions({ gantt: { startDateField: 'planned_start' } });
+ expect(out.startDateField).toBe('planned_start');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('keeps the `name` title floor — a display default is not a date axis', () => {
+ // Deliberately NOT removed by this card, and the same rung
+ // `timelineViewOptions` carries. `ObjectGantt` floors the title itself too.
+ expect(ganttViewOptions({}).titleField).toBe('name');
+ expect(ganttViewOptions({ gantt: { titleField: 'subject' } }).titleField).toBe('subject');
+ });
+});
+
+describe('no invented gantt date name survives in the source (objectui#7070)', () => {
+ const SOURCE = readFileSync(
+ path.join(path.dirname(fileURLToPath(import.meta.url)), 'ObjectView.tsx'),
+ 'utf8',
+ );
+
+ /**
+ * Executable lines only. The prose above this file's own seams names
+ * `'start_date'` / `'end_date'` repeatedly — that is the record of what was
+ * deleted, and a scan that counted it would be red on a correct tree. Same
+ * filter, and same reason, as the objectui#7029 scan next door.
+ */
+ const CODE = SOURCE.split('\n').filter((l) => !/^\s*(\*|\/\*|\/\/)/.test(l));
+
+ it("the fabricated 'start_date' / 'end_date' floors are gone from this face's CODE", () => {
+ // A structural tripwire, not a restatement of the cases above: these are
+ // what a future copy-paste from a sibling branch would reintroduce, and they
+ // are invisible to a behavioural test on any object that happens to carry
+ // real `start_date` / `end_date` fields — which is exactly how the defect
+ // survived (hotcrm's `crm_leave_request` carries both).
+ expect(CODE.filter((l) => l.includes("'start_date'"))).toEqual([]);
+ expect(CODE.filter((l) => l.includes("'end_date'"))).toEqual([]);
+ });
+
+ it('CONTROL: the scan can still see a literal that IS there', () => {
+ // Without this the case above is green on any tree where the filter simply
+ // matches nothing. `'image'` is the gallery branch's `imageField … ||
+ // 'image'` floor — the same one-rung class, still present, out of scope for
+ // this card. ⚠️ If you retire it, RE-ANCHOR this control onto whatever
+ // fabrication legitimately remains; do not delete it. (The twin of this
+ // control in `ObjectView.calendarBinding-7029.test.tsx` carries the same
+ // instruction, and explains why in full.)
+ expect(CODE.filter((l) => l.includes("'image'")).length).toBeGreaterThan(0);
+ });
+
+ it('CONTROL: the scan reads CODE, not the prose that records the deletion', () => {
+ // The filter's own correctness. The seam comments above `ganttViewOptions`
+ // name both deleted literals; if the filter ever stopped stripping comment
+ // lines, the case above would go red on a CORRECT tree and invite someone to
+ // weaken it.
+ expect(SOURCE.includes("`'start_date'`")).toBe(true);
+ expect(CODE.filter((l) => l.includes("'start_date'"))).toEqual([]);
+ });
+});

.changeset/7070-no-invented-gantt-date-fields.md

@@ -0,0 +1,53 @@
+---
+'@object-ui/app-shell': minor
+'@object-ui/plugin-list': minor
+'@object-ui/plugin-view': minor
+---
+
+Gantt views no longer render on invented date field names (objectui#7070).
+
+The half PR #7062 fenced out and reported separately. A view that carried no
+`gantt:` block used to have a complete-looking date axis synthesized for it:
+all three faces floored `startDateField` at `'start_date'` and `endDateField`
+at `'end_date'` — field names no view had written and most objects do not
+carry.
+
+`ObjectGantt.getGanttConfig` takes its flat branch as soon as BOTH date props
+are present, so the fabricated pair short-circuited the renderer's own refusal
+screen — "Gantt configuration required. Please specify startDateField,
+endDateField, and titleField." — which existed all along and was simply
+unreachable from every route. The same fabrication answered ADR-0047's
+capability gate in `ListView.availableViews`, so the Gantt toggle was live on
+every object view in the product.
+
+⚠️ The premise was MEASURED before anything was deleted, because #7029's
+mechanic is only correct where a refusal path exists and that had never been
+established for this renderer: on the unmodified tree, `ObjectGantt` REFUSES an
+absent binding — it does not render empty, and it does not throw.
+
+Three faces were fabricating, on two independent routes to the same renderer:
+
+- `app-shell/src/views/ObjectView.tsx` — the console object page. The inline
+ branch becomes `ganttViewOptions`, the sibling of `calendarViewOptions` and
+ `timelineViewOptions`: the declared block spread whole, title floored at
+ `'name'`, no date field invented.
+- `plugin-list/src/ListView.tsx` — the render branch AND the capability gate.
+- `plugin-view/src/ObjectView.tsx` — `generateViewSchema`, the authored
+ `object-view` element route, which bypasses `ListView` entirely.
+
+**What changes for an author.** A view that declared no gantt configuration is
+no longer offered the Gantt toggle, and one forced onto the renderer reaches
+the refusal screen instead of a plausible, fully wrong chart. A view that
+declared a binding is unaffected — the declared block is forwarded exactly as
+before, every spec key included.
+
+Also corrected: the objectui#3129 note at the top of `app-shell/ObjectView.tsx`
+certified the gantt branch below it as already using the safe two-rung shape.
+It did not. The note now states each sibling branch as measured, and says
+explicitly which fabrication REMAINS — the timeline `'created_at'` floor at the
+two plugin faces, which objectui#7070 routes to a ruling rather than settling
+per-face.
+
+Deliberately out of scope, and left in place: `progressField` / `dependenciesField`
+(not date axes, different absent-value semantics) and the timeline `'created_at'`
+posture conflict.

packages/app-shell/src/views/ObjectView.calendarBinding-7029.test.tsx

@@ -130,12 +130,44 @@ describe('no invented calendar field name survives in the source (objectui#7029)
  expect(CODE.filter((l) => /calendar\?\.titleField \|\| 'name'/.test(l))).toEqual([]);
  });
 
- it('CONTROL: the scan can still see a literal that IS there', () => {
- // Without this the two cases above are green on any tree where the filter
- // simply matches nothing — the failure mode that made the first spelling of
- // this scan a phantom check. The gantt branch still carries its own
- // `'start_date'` floor (same class, separately reported, deliberately NOT
- // touched by this card), so it is the honest positive control.
- expect(CODE.filter((l) => l.includes("'start_date'")).length).toBeGreaterThan(0);
+ /**
+ * ⭐ THE POSITIVE CONTROL — read this before changing either case below.
+ *
+ * Without a control the two cases above are green on any tree where the filter
+ * simply matches nothing: the failure mode that made the first spelling of
+ * this scan a phantom check. This control was originally a single case
+ * anchored on the gantt branch's own `'start_date'` floor ("same class,
+ * separately reported, deliberately NOT touched by this card").
+ *
+ * objectui#7070 is that separate report, and fixing it deleted the anchor —
+ * `'start_date'` is now absent from this face's CODE, so the original control
+ * would have gone red. ⛔ It was NOT simply removed: a scan whose last live
+ * control is dropped becomes a test that passes over nothing, which is the
+ * exact class this whole card family is about. It is re-expressed as TWO
+ * controls that answer two different questions:
+ */
+
+ it('CONTROL (machinery): the scan can see a literal that IS there', () => {
+ // Can this filter return a non-empty result at all? Anchored on `'name'`,
+ // which is DELIBERATELY permanent here — the display-name floor the
+ // objectui#3129 note above the seams describes as what stays. It is not a
+ // fabricated field name, so no future card of this family retires it, and
+ // this control cannot go red as a side effect of the next fix.
+ expect(CODE.filter((l) => l.includes("'name'")).length).toBeGreaterThan(0);
+ });
+
+ it('CONTROL (same class): the scan still sees a REMAINING fabricated field name', () => {
+ // Can this filter see the specific thing it exists to hunt — a one-rung
+ // `|| 'literal'` field-name floor? Anchored on the gallery branch's
+ // `imageField: … || 'image'`, which is the same class, is still there, and
+ // is out of scope for both objectui#7029 and objectui#7070.
+ //
+ // ⚠️ TO WHOEVER RETIRES `'image'`: this going red is the mechanic working,
+ // not a broken test. RE-ANCHOR it onto whatever fabrication legitimately
+ // remains in this file — do not delete it, and do not weaken it to the
+ // machinery control above. If nothing of this class remains anywhere in this
+ // face, say so in the PR body and convert this case into the assertion that
+ // NONE remains, so the scan keeps making a claim about the tree.
+ expect(CODE.filter((l) => l.includes("'image'")).length).toBeGreaterThan(0);
  });
 });

packages/app-shell/src/views/ObjectView.ganttBinding-7070.test.tsx

@@ -0,0 +1,161 @@
+/**
+ * ObjectUI
+ * Copyright (c) 2024-present ObjectStack Inc.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ */
+
+/**
+ * objectui#7070 — the object page must not invent a GANTT date binding.
+ *
+ * The sibling of `ObjectView.calendarBinding-7029` next door, and the half PR
+ * #7062 fenced out and reported separately. This face floored
+ * `startDateField` at `'start_date'` and `endDateField` at `'end_date'` for
+ * EVERY object view, declared or not. Downstream that is indistinguishable
+ * from a real binding: `ObjectGantt.getGanttConfig` takes its flat branch as
+ * soon as BOTH date props are present, so the fabrication made the renderer's
+ * own "Gantt configuration required" screen unreachable from this route, and it
+ * answered ADR-0047's capability gate (`options.gantt.startDateField`) so the
+ * Gantt toggle was live on every object view in the product.
+ *
+ * ⚠️ THE PREMISE WAS MEASURED BEFORE THE DELETION. #7029's mechanic — delete the
+ * literal, let the renderer's own refusal answer — is only correct where a
+ * refusal path exists, and that had never been established for gantt. It was,
+ * on the unmodified tree, before this file's fix was written: `ObjectGantt`
+ * REFUSES an absent binding (it does not render empty, and does not throw). The
+ * seam is pinned in `plugin-gantt/src/ObjectGantt.unconfiguredRefusal-7070`.
+ *
+ * REVERSE VERIFICATION — direction predicted before running, then observed:
+ * restore `startDateField: viewDef.gantt?.startDateField || 'start_date'` and
+ * its `endDateField` twin, and the "invents NO date field" cases below go RED
+ * (they read the fabricated names) while every declared-config CONTROL stays
+ * GREEN in either world — the fabricated value is only ever observable when the
+ * view declared nothing. That asymmetry is the point: a fix that emitted an
+ * empty config for EVERY view would also pass a refusal-only test.
+ */
+
+import { describe, it, expect } from 'vitest';
+import { readFileSync } from 'node:fs';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+import { ganttViewOptions } from './ObjectView';
+
+describe('ganttViewOptions — the object page forwards, it does not invent (objectui#7070)', () => {
+ it('invents NO date field for a view that declares no gantt config', () => {
+ // THE DEFECT. This used to return `{ startDateField: 'start_date',
+ // endDateField: 'end_date', titleField: 'name' }` — a complete-looking axis
+ // for a view that configured nothing, which is what short-circuited the
+ // renderer's refusal screen and lit the Gantt toggle everywhere.
+ expect(ganttViewOptions({})).toEqual({ titleField: 'name' });
+ expect(ganttViewOptions(undefined)).toEqual({ titleField: 'name' });
+ expect(ganttViewOptions({ label: 'All', columns: ['name'] })).toEqual({ titleField: 'name' });
+ });
+
+ it('invents no date field for a view whose neighbouring blocks ARE declared', () => {
+ // A view bound for kanban/calendar must not acquire a gantt axis by
+ // proximity — the Gantt toggle it would light up has nothing behind it.
+ const out = ganttViewOptions({
+ kanban: { groupByField: 'stage' },
+ calendar: { startDateField: 'start_date' },
+ });
+ expect(out).not.toHaveProperty('startDateField');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('invents no date field for an EMPTY gantt block', () => {
+ // The half-written declaration: `allowedVisualizations: ['gantt']` with
+ // nothing under `gantt:`. It must stay half-written all the way down.
+ const out = ganttViewOptions({ gantt: {} });
+ expect(out).not.toHaveProperty('startDateField');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('CONTROL: forwards a fully declared block verbatim — every spec key survives', () => {
+ // A bare whitelist here once dropped every field past `colorField` and
+ // flattened the chart, so the spread is load-bearing, not incidental.
+ const out = ganttViewOptions({
+ gantt: {
+ startDateField: 'planned_start',
+ endDateField: 'planned_end',
+ titleField: 'subject',
+ parentField: 'parent',
+ typeField: 'node_type',
+ baselineStartField: 'bl_start',
+ groupByField: 'owner',
+ tooltipFields: [{ field: 'owner' }],
+ },
+ });
+ expect(out).toMatchObject({
+ startDateField: 'planned_start',
+ endDateField: 'planned_end',
+ titleField: 'subject',
+ parentField: 'parent',
+ typeField: 'node_type',
+ baselineStartField: 'bl_start',
+ groupByField: 'owner',
+ tooltipFields: [{ field: 'owner' }],
+ });
+ });
+
+ it('CONTROL: a HALF-declared axis keeps its declared rung and only that', () => {
+ // One date field is not a gantt: `getGanttConfig`'s flat branch needs BOTH,
+ // so this shape reaches the refusal screen rather than rendering on a name
+ // nobody wrote.
+ const out = ganttViewOptions({ gantt: { startDateField: 'planned_start' } });
+ expect(out.startDateField).toBe('planned_start');
+ expect(out).not.toHaveProperty('endDateField');
+ });
+
+ it('keeps the `name` title floor — a display default is not a date axis', () => {
+ // Deliberately NOT removed by this card, and the same rung
+ // `timelineViewOptions` carries. `ObjectGantt` floors the title itself too.
+ expect(ganttViewOptions({}).titleField).toBe('name');
+ expect(ganttViewOptions({ gantt: { titleField: 'subject' } }).titleField).toBe('subject');
+ });
+});
+
+describe('no invented gantt date name survives in the source (objectui#7070)', () => {
+ const SOURCE = readFileSync(
+ path.join(path.dirname(fileURLToPath(import.meta.url)), 'ObjectView.tsx'),
+ 'utf8',
+ );
+
+ /**
+ * Executable lines only. The prose above this file's own seams names
+ * `'start_date'` / `'end_date'` repeatedly — that is the record of what was
+ * deleted, and a scan that counted it would be red on a correct tree. Same
+ * filter, and same reason, as the objectui#7029 scan next door.
+ */
+ const CODE = SOURCE.split('\n').filter((l) => !/^\s*(\*|\/\*|\/\/)/.test(l));
+
+ it("the fabricated 'start_date' / 'end_date' floors are gone from this face's CODE", () => {
+ // A structural tripwire, not a restatement of the cases above: these are
+ // what a future copy-paste from a sibling branch would reintroduce, and they
+ // are invisible to a behavioural test on any object that happens to carry
+ // real `start_date` / `end_date` fields — which is exactly how the defect
+ // survived (hotcrm's `crm_leave_request` carries both).
+ expect(CODE.filter((l) => l.includes("'start_date'"))).toEqual([]);
+ expect(CODE.filter((l) => l.includes("'end_date'"))).toEqual([]);
+ });
+
+ it('CONTROL: the scan can still see a literal that IS there', () => {
+ // Without this the case above is green on any tree where the filter simply
+ // matches nothing. `'image'` is the gallery branch's `imageField … ||
+ // 'image'` floor — the same one-rung class, still present, out of scope for
+ // this card. ⚠️ If you retire it, RE-ANCHOR this control onto whatever
+ // fabrication legitimately remains; do not delete it. (The twin of this
+ // control in `ObjectView.calendarBinding-7029.test.tsx` carries the same
+ // instruction, and explains why in full.)
+ expect(CODE.filter((l) => l.includes("'image'")).length).toBeGreaterThan(0);
+ });
+
+ it('CONTROL: the scan reads CODE, not the prose that records the deletion', () => {
+ // The filter's own correctness. The seam comments above `ganttViewOptions`
+ // name both deleted literals; if the filter ever stopped stripping comment
+ // lines, the case above would go red on a CORRECT tree and invite someone to
+ // weaken it.
+ expect(SOURCE.includes("`'start_date'`")).toBe(true);
+ expect(CODE.filter((l) => l.includes("'start_date'"))).toEqual([]);
+ });
+});