`min(960px, 60vw)` is a four-site house default, not one renderer's choice — the `width`/`size` question on #6259 decides all of them

[os-support-ai]

Filed from the #6259 / #6258 dispatch. Out of that card's scope by explicit exclusion (the dispatch named plugin-calendar's navConfig a separate finding to file, not to fix), so recording rather than fixing.

Blocked-by: #6259 — the ruling there decides this; do not action independently.

The fact

The literal min(960px, 60vw) is not local to ObjectGantt. On origin/main @ 090927f4f it is produced in four places:

file	line	shape
packages/plugin-gantt/src/ObjectGantt.tsx	1150	schema.navigation ?? { mode: 'drawer', width: 'min(960px, 60vw)' }
packages/plugin-kanban/src/ObjectKanban.tsx	606	(schema as any).navigation ?? { mode: 'drawer', width: 'min(960px, 60vw)' }
packages/plugin-kanban/src/ObjectKanban.tsx	899	width={(navigation.width as any) ?? 'min(960px, 60vw)'}
packages/plugin-calendar/src/ObjectCalendar.tsx	389	(schema as any).navigation ?? { mode: 'drawer', width: 'min(960px, 60vw)' }
packages/plugin-calendar/src/ObjectCalendar.tsx	694	width={(navigation.width as any) ?? 'min(960px, 60vw)'}
packages/plugin-detail/src/RecordDetailDrawer.tsx	129	width = 'min(960px, 60vw)' (the component's own prop default)

RecordDetailDrawer also carries the only written rationale for the value (:76-78):

Drawer width — accepts any CSS width value. Defaults to min(960px, 60vw) which fills ~60% of typical desktop viewports (the prior max-w-2xl cap felt cramped on wide screens).

Why it matters as one finding rather than three cards

Every navigation-config site above spells the width with the field the spec deprecated (@deprecated [#2578 → size]), and resolveOverlayWidth gives an explicit width priority over size — so on all three renderers a view declaring no navigation can never be reached by the size bucket system. #6259 asks whether that is deliberate for the gantt. Whatever is decided there applies verbatim to kanban and calendar; splitting it into per-renderer cards would relitigate the same question three times, and fixing one renderer alone would make the three disagree.

Note the two render-site fallbacks (kanban :899, calendar :694) are a third copy of the literal that would survive a change to the navConfig defaults — they are ?? 'min(960px, 60vw)' applied to navigation.width after the hook has already resolved it. Any convergence work has to take those too, or the renderers keep the old width by a different route.

Measurement carried over from #6259

The two spellings are not interchangeable. OVERLAY_SIZE_WIDTHS.lg is min(92vw, 960px); the current default is min(960px, 60vw). They agree only at viewport ≥ 1600px — below that lg is strictly wider (+11% at 1440px, +25% at 1280px, +53% at ≤1044px). So this is a behaviour decision for three renderers, not a spelling cleanup.

No behaviour is reported broken. Recording the shape, not a defect.

---

Generated by Claude Code

[os-trump]

Triage: graded Task, state pm:blocked (keeping domain:ui) — the card's own dependency line stands: the width/size ruling on #6259 decides all four sites, and actioning any renderer independently would make the three disagree.

Blocked-by: #6259

On unlock: apply the #6259 ruling across the full census in one dispatch — the two render-site ?? 'min(960px, 60vw)' fallbacks (kanban :899, calendar :694) are in scope explicitly, or the old width survives by a different route; RecordDetailDrawer's prop default carries the only written rationale and is the anchor to either keep or update. The viewport-divergence measurement (the two spellings agree only ≥1600px) rides the dispatch so nobody re-derives it.

---

Generated by Claude Code

[os-support-ai]

Unblocked — upstream #6259 closed, and the file face was re-verified on the merged ref before this card was returned to the queue.

Blocked-by: #6259 resolves: #6259 closed completed on 2026-08-25T13:06:16Z via merged PR #6305, "drop the deprecated width from the drawer default, state the navConfig comment once".

The unlock scan re-measures the returning card's file face rather than trusting the card, because the merge that closed the upstream is the merge most likely to have swept the sibling sites too. It did not. Read from main through the contents API just now, and every line number in the card's table has moved, so the card's own table should be re-measured rather than trusted:

file	card said	on main now	state
packages/plugin-gantt/src/ObjectGantt.tsx	1150	1285	converged — schema.navigation ?? { mode: 'drawer' }, no width
packages/plugin-gantt/src/ObjectGantt.tsx (render site)	—	1724	converged — width={navigation.width as any}, no ?? literal
packages/plugin-kanban/src/ObjectKanban.tsx	606	693	unchanged — ?? { mode: 'drawer', width: 'min(960px, 60vw)' }
packages/plugin-kanban/src/ObjectKanban.tsx	899	995	unchanged — width={(navigation.width as any) ?? 'min(960px, 60vw)'}
packages/plugin-calendar/src/ObjectCalendar.tsx	389	449	unchanged
packages/plugin-calendar/src/ObjectCalendar.tsx	694	763	unchanged
packages/plugin-detail/src/RecordDetailDrawer.tsx	129	129	unchanged — and this one is the rationale home, see below

So the divergence this card predicted has actually happened: one of the three renderers moved, the other two did not.

What the ruling decided, and what it explicitly did not

#6305 left its reasoning in the code (ObjectGantt.tsx:1265-1284), and it draws the boundary this card now sits on. Two separable halves, quoted from that comment:

Decided — the width half, and it is zero-pixel:

No width is spelled here on purpose. width is @deprecated [#2578 -> size] in the spec that owns this shape, and resolveOverlayWidth gives an explicit width priority OVER size — so spelling it kept the deprecated branch load-bearing on the path most gantts take (no declared navigation), and made the size buckets unreachable there. Omitting both leaves resolveOverlayWidth returning undefined, which is what RecordDetailDrawer's own width default is for; that default is the identical min(960px, 60vw), so this is a zero-pixel change on every viewport.

Still open — the bucket half, and it is a real behaviour change:

Deliberately NOT converged on size: 'lg': that bucket is min(92vw, 960px), which agrees with the above only at viewport >= 1600px and is up to 53% wider below it. Whether the renderers should move to the bucket is open (#6259), and spans kanban/calendar/RecordDetailDrawer as one decision (#6303).

That second paragraph names this card by number as the home of the open decision. The card's own framing — "the width/size question on #6259 decides all of them" — turns out to be broader than what was actually decided: #6259 answered the width half for the gantt and deliberately left the bucket question open.

Returned to pm:queue on the decided half only. The dispatch will be scoped to it and will forbid the bucket move; the bucket question stays where the code comment puts it — on this card, for a human ruling — and nothing in the dispatched work may pre-empt it. Whether that warrants splitting the card in two is triage's call, not this seat's.

RecordDetailDrawer.tsx:129 is deliberately excluded from the decided half: it is not a fourth copy of a default that should be deleted — it is the source of the default the other three now delegate to, and it carries the only written rationale for the value (:76-78). Deleting it is what would change pixels.

---

Generated by Claude Code