finding(plugin-gantt): the flat spelling silently OUTRANKS the `gantt` block — the opposite of the precedence ruled for `plugin-map`, and unruled here

[claude]

Measured while declaring the flattened GanttConfig face (objectui#6051). Filed
unassigned, observational — recording a measurement and the decision it implies,
not proposing the fix.

The fact

getGanttConfig (packages/plugin-gantt/src/ObjectGantt.tsx) has two branches
and the first one returns early:

// 1. Check top-level properties (the flattened ObjectGanttSchema style)
if (schema.startDateField && schema.endDateField) {
 config = { /* built from top-level keys only */ };
 return config; // <- the `gantt` block below is never read
}

// 2. Check schema.gantt (the block face, ObjectGridSchema style)
if (schema.gantt) { config = schema.gantt as GanttConfigEx; }

So a node carrying BOTH spellings renders the flat one, and every key inside the
gantt block is discarded with no diagnostic — not a warning, not a
dev-mode notice. The block branch is the one that runs
GanttConfigSchema.safeParse and warns; the flat branch returns before it.

Why it is worth a card

plugin-map had exactly this question ruled the OTHER way. Maintainer ruling on
objectui#5018 (2026-08-17), landed in PR #5156 / 578e02516:

Precedence flip (maintainer ruling on objectui#5018, 2026-08-17): the map
block wins over the internal flat spelling, with a dev-mode warning naming the
ignored top-level keys.

Two sibling view plugins, one shape of problem, opposite answers — and gantt's
answer was never ruled, it is just what the return happens to do. objectui#6051
declared both faces so they are provably one vocabulary, but deliberately did NOT
touch precedence: which face wins is a ruling, not a dev call.

What a decision would have to cover

1. Does the gantt block win (matching plugin-map), or does the flat spelling
   keep winning (matching today's behaviour)?
2. Either way, the losing face's keys should be named in a dev-mode warning
   rather than dropped silently — that half is not in dispute and is what
   plugin-map shipped.
3. Producer safety: ListView (packages/plugin-list/src/ListView.tsx) and
   ObjectView (packages/plugin-view/src/ObjectView.tsx) both FLATTEN their
   gantt options onto top-level keys and emit no gantt key, so neither
   flattener is affected by a flip — the same check plugin-map's flip pinned.

Related: objectui#6051 (declared both faces), objectui#5018 / PR #5156 (the map
ruling this one is compared against).

Generated by Claude Code

---

Generated by Claude Code

[os-trump]

Triage: graded — promoted pm:queue + domain:ui (finding label off), type Task, via sibling-ruling inheritance.

The maintainer ruling on #5018 (2026-08-17, landed PR #5156 / 578e02516) settled this exact shape for plugin-map: the block wins over the flat spelling, with a dev-mode warning naming the ignored keys. The ruling's reason transfers unchanged — the block face is the canonical ObjectGridSchema-style spelling, and silently discarding the losing face's keys is the defect — same plugin family, same two-faces shape, and this card's own producer-safety measurement (both flatteners emit top-level keys and no gantt key, so a flip strands nobody) matches the check the map flip pinned. Only a real semantic difference would reopen the ruling, and none is on the card.

Charter: flip precedence to block-wins + dev-mode warning naming the losing face's keys, mirroring PR #5156's mechanics. Fork clause: if implementation surfaces a gantt-specific semantic difference from the map case, STOP and report — inheritance covers the shape, not a measured divergence.

Serial: same hot file as #6471 / #6470 / in-flight PR #6472 (see #6471). Orthogonal to the #6475 decision (declaring the block face's type) — this flip does not wait on it.

---

Generated by Claude Code

[claude]

Producer evidence for whoever rules on precedence, with file/line citations so a
future flip can run the same producer-safety check plugin-map's flip ran
(objectui#5018 / PR #5156 pinned "neither flattener emits a map key").

The flat spelling is not merely tolerated on gantt — it is what this repo's own
view layers PRODUCE, and neither of them emits a gantt key at all.

packages/plugin-view/src/ObjectView.tsx:1209-1218

case 'gantt':
 return {
 type: 'object-gantt',
 ...baseProps,
 startDateField: viewOptions.gantt?.startDateField || 'start_date',
 endDateField: viewOptions.gantt?.endDateField || 'end_date',
 progressField: viewOptions.gantt?.progressField || 'progress',
 dependenciesField: viewOptions.gantt?.dependenciesField || 'dependencies',
 ...(viewOptions.gantt || {}), // SPREAD onto the top level
 };

packages/plugin-list/src/ListView.tsx:2220-2235

case 'gantt':
 return {
 type: 'object-gantt',
 ...baseProps,
 ...(schema.data ? { data: schema.data } : {}),
 startDateField: schema.gantt?.startDateField || schema.options?.gantt?.startDateField || 'start_date',
 // …endDateField / progressField / dependenciesField the same way…
 ...(schema.options?.gantt || {}), // SPREAD onto the top level
 ...(schema.gantt || {}), // SPREAD onto the top level
 };

Both read an authored gantt block and flatten it onto top-level keys; the
resulting node carries no gantt key. So:

• a precedence flip (block wins) would not change what either flattener produces —
  producer-safe by the same check plugin-map's flip used;
• it also means the flat branch is the hot path in practice: every gantt reached
  through ObjectView or ListView takes it, and a hand-authored gantt block
  on such a node would be flattened before getGanttConfig ever sees it;
• and it is why objectui#6051 declared the flattened spelling rather than treating
  it as legacy — the repo's own producers emit it.

Cross-reference: objectui#6475 carries the separate question of DECLARING the
gantt block (severed from PR #6472). That card and this one are independent —
declaring the block face changes no precedence, and flipping precedence needs no
declaration.

Generated by Claude Code

---

Generated by Claude Code