Compact Mode

[kitikonti]

First of all i don't know if this is the best name for this feature, so this should also be part of the job to answer.

Currently we use the well know gantt display for the charts. This feature is meant to implement another way to display the charts in a more compact way and to solve all related issues/challanges resulting from this feature.

The current status basically looks like this:

The new feature should implement a representation close to this:

So basically vertically compress the chart as far as possible so we have one line with all bars collapsed but not overlapping.
Maybe even think about another mode where the bars also overlapp so its really just one line -> i am not sure today if we need this because thats basically what the summary feature already does.

This comes with a lot of problems we need to cover. So the first main task is to finde a solution or multiple solutions how to deal with all these prolbems. The progress in the concepts or the final concept should be documented in this Issue.

The list of Problems is a work in progress so here is the start of a not complete list:

• We loose the methodes how new items are created today because everything generates a new line and it is all coupled to the table view
• We need a different display also for the table view because we dont have a line per item anymore
• Every crud operation we have today which is based on a new line per item needs a different UI/UX (for example i cant type the task name in this view in the task table, because there is no task table)
• The alternative UI/UX should extend the existing UI/UX and not replace or be a complete alternative and i have to choose ever this or that. Its just a different display and independent in which display i am i need all features.

[kitikonti]

Concept A — Naming & Layout/Packing Algorithm

Phase 1 of 3. This comment covers (1) what to call the thing and (2) exactly how bars get assigned to shared rows, grounded in real OwnChart source and in prior art from calendars, timeline libraries and Gantt products. Later agents: everything below is numbered so you can cite it.

---

0. TL;DR — the eight decisions

#	Decision	Recommendation
D1	Feature name	Row Packing (docs/changelog/help topic)
D2	UI control	View tab → Row Layout: One per Row (default) · Packed
D3	Code identifier	ViewSettings.rowLayout: "single" | "packed". The word compact is banned in this feature — it belongs to density.
D4	Algorithm	First-fit in document order (not start-time order), per band
D5	Collision unit	Date units only. pixelsPerDay is never an input to packing. Lane assignment is zoom-invariant.
D6	Hierarchy	Summary keeps its own row; descendants pack into lanes inside the parent's band. Collapsed summary ⇒ children roll up onto the band instead of vanishing (MS Project / DHTMLX precedent).
D7	Milestones	Pack in the same lanes with a 1-day footprint; overlap solved at render time by clustering, not by lane assignment.
D8	"True single line with overlapping bars"	Don't ship it. D6's collapse-with-rollup delivers the same outcome and stays clickable. Details in §7.

---

PART 1 — NAMING

1.1 The collision is real and worse than it looks

src/config/densityConfig.ts defines compact / normal / comfortable, surfaced in src/config/preferencesOptions.ts as:

Compact      — "Shows more tasks on screen"   28px rows
Normal       — "Balanced view (recommended)"  36px rows
Comfortable  — "Easier to read, more spacing" 44px rows

Note the description of Compact: "Shows more tasks on screen." That is verbatim the value proposition of the new feature. Two different settings, same name, same promise, different mechanism. This is not a mild collision — a user who wants more tasks on screen would set Density = Compact and reasonably conclude the feature is already there.

Words that are already spoken for in OwnChart's vocabulary and must be avoided:

Word	Already means
Compact / Normal / Comfortable	UiDensity — row height
Expanded / Collapsed	Task.open — summary disclosure
Hidden	chartSlice.hiddenTaskIds — Excel-style row hiding
Group	groupingActions — the indent/summary operation
Column	hiddenColumns / columnActions — table columns

1.2 What comparable products actually call it

Product	Name it uses	What it actually does	Borrow?
DHTMLX Gantt — Split Tasks	Split task + split_placement: "inline" | "subrow" | "auto"	Set a parent's render: "split" and its children draw on the parent's own row; auto = inline when collapsed, subrows when expanded	Mechanism yes (see §6), name no — "split" reads as "interrupted task" (which MS Project also uses that word for)
MS Project — Rollup task field / Layout ▸ "Always roll up Gantt bars", "Hide rollup bars when summary expanded"	Roll up	Projects child bars/milestones onto the summary bar's row	Both — this is the closest, most battle-tested precedent, and the option pair maps 1:1 to D6
Bryntum Gantt — forum	Rollup (rollup: true on a milestone)	Milestone renders inside its parent's row. Bryntum is otherwise explicitly one-task-per-row	Confirms "rollup" is industry-standard for the hierarchy case
vis.js Timeline — Stack.js	Stacking (stack, stackSubgroups)	performStacking() moves each item down until it clears all horizontally-colliding items	Algorithm yes, name no — "stacked" in a charting product means stacked bar chart (cumulative), which OwnChart may want later
react-calendar-timeline	stackItems (per-group override)	Same idea, per-group opt-in	Confirms per-group granularity is expected
Highcharts Gantt — forum	yAxis.uniqueNames: true	Multiple series share one category row	Not a user-facing name
OnePager / Office Timeline / Smartsheet community — swimlanes	Swimlane	Collects many tasks into one horizontal lane, usually grouped by a semantic attribute (team, project, phase)	Reject the name. In every product that uses it, a swimlane means something (a team, a phase). OwnChart's lanes would be meaningless artefacts of a packing algorithm. Calling them swimlanes promises semantics we don't deliver.
Smartsheet community (thread)	users say "condensed into one row"	—	"Condensed" is how users describe it unprompted. Worth noting, but see below.

1.3 Candidate shortlist

Candidate	Pros	Cons	Verdict
Compact Mode	Author's instinct; plain English	Head-on collision with UiDensity.compact, whose own description is "shows more tasks on screen". Untenable.	❌ Reject
Condensed	What users say spontaneously (Smartsheet thread); no code collision	Semantically indistinguishable from "Compact" for a non-native speaker; a Compact/Condensed pair in one product is a usability bug	❌ Reject
Swimlanes	Familiar to PM audience; strong visual metaphor	Every product using it means semantic lanes. Our lanes are derived and unnamed. Actively misleading, and it burns the word we'd want if we ever add real grouping-by-attribute.	❌ Reject — reserve this word for a future group-by feature
Stacked / Stacking	vis.js + react-calendar-timeline precedent; accurate	Collides with "stacked bar chart" in a charting product. Also implies vertical accumulation, which is the opposite of what happens.	⚠️ Third choice
Roll-up / Rolled-up bars	Strongest industry precedent (MS Project, Bryntum)	In MS Project it means specifically children onto their parent, not arbitrary tasks onto a shared lane. Using it for global packing would misinform the exact users who know the term.	✅ Use it — but only for the hierarchy sub-behaviour (D6), where it means exactly what MS Project means
Row Packing (Row Layout: One per Row / Packed)	Zero collisions. Literally describes the mechanism. Extends the existing vocabulary cleanly: Density = how tall a row is, Row Layout = how tasks map onto rows. Parallel structure makes both settings easier to learn. packed is unambiguous in code.	"Packed" is not a term the PM industry uses; needs a one-line tooltip	✅ Recommend
Lane View / Tracks	"Track" is exactly right by analogy to DAWs/video editors (clips packed onto tracks)	Wrong audience — PMs don't have that reference. And "lane" collides conceptually with the swimlane expectation.	❌ Reject as user-facing; do use lane as the internal term for an individual packed row

1.4 Recommendation

(a) Feature name — "Row Packing".
Changelog: feat: add row packing (multiple tasks per row). Help topic in src/config/helpContent.ts: "Row Packing".

(b) Internal / code identifiers.

// src/utils/fileOperations/types.ts  → ViewSettings
rowLayout: "single" | "packed";        // default "single"
packingGapDays: number;                // default 0
rollupCollapsedSummaries: boolean;     // default true

// new module
src/utils/rowPacking/packRows.ts       // packBand(), toDayInterval(), fits()
src/hooks/useRowPacking.ts             // returns LaneLayout
// types: LaneLayout, LanePlacement, Band, Interval
// vocabulary: "band" = a summary's territory;  "lane" = one packed row inside a band

Grep-guard worth adding to lint:colors-style CI: the string compact must not appear in src/utils/rowPacking/ or in any rowLayout value.

(c) UI label. View ribbon tab (useViewTabActions), a dropdown sitting next to the existing density control so the parallel is visible:

Row Layout  ▾
  ● One per Row     Classic Gantt — every task gets its own row
  ○ Packed          Tasks that don't overlap in time share a row

Tooltip on Packed: "Fits tasks that don't overlap in time onto shared rows. Nothing is hidden — the same tasks, fewer rows." (The second sentence pre-empts the #1 fear: "did it hide my data?")

(d) Name for the inverse / today's view — "One per Row".
It must be named, it must be the default, and it must not be called Normal (collides with density), Standard (vague), Expanded (collides with Task.open), or Classic (implies deprecated). "One per Row" in the UI, "single" in code, "the classic one-task-per-row layout" in prose.

This framing also directly serves the author's non-negotiable constraint. Row Layout is a display setting alongside density, not a Mode. The word "Mode" is what creates either/or silos; a setting in the View tab next to Density does not.

---

PART 2 — THE PACKING ALGORITHM

2.1 What the code currently assumes

The coupling is narrower than the brief implies, which is good news. Every y-coordinate in the chart funnels through one function:

// src/utils/timelineUtils.ts:349
export function getTaskBarGeometry({ task, scale, rowIndex, densityConfig, headerHeight }) {
  ...
  return { x, y: headerHeight + rowIndex * rowHeight + taskBarOffset, width, ... };
}

Plus three direct index * rowHeight sites: ChartCanvas.tsx:168, SelectionRows inside ChartCanvas.tsx, and GridLines.tsx:190 (horizontalLines = Array.from({length: taskCount + 1}, (_, i) => ({y: i * rowHeight})), gridHeight = taskCount * rowHeight).

So the whole change is: replace the number passed as rowIndex. Not a rewrite — a substitution of one integer, plus making taskCount mean "row count" rather than "task count".

Two more findings that de-risk this:

1. src/utils/arrowPath/elbowPath.ts already handles same-row dependencies — isSameRow(from, to) at line 74, used at lines 102, 423 and 431, feeding buildSameRowHookPath(). The hardest-sounding consequence of packing (two dependent tasks landing in the same lane) already has a rendering path. It will need stress-testing, not inventing.
2. getTaskBarGeometry already special-cases milestones (const endDate = task.endDate || task.startDate), so a milestone's date interval is already well-defined.

2.2 Prior art for the algorithm itself

• Google Calendar / interval partitioning. Laying out overlapping events is the classic interval-partitioning problem: sort by start, greedily assign to the first free column. Because interval graphs are perfect, greedy-by-start uses exactly ω columns — the maximum number of events overlapping at any instant — which is provably optimal. (interval coloring, worked write-up)
• vis.js Timeline Stack.js. orderByStart() then performStacking(), which pushes each item down until it clears every horizontally-colliding item. Collisions use margin.item.horizontal / margin.item.vertical and an EPSILON = 0.001 fudge to survive float rounding. Notably, issue #343 is precisely "items that abut but don't overlap should be in a continuous row" — i.e. the touching case is a real, shipped bug in the reference implementation. We must define it explicitly (§5).
• FullCalendar exposes slotEventOverlap: true = deliberate partial overlap (at most half obscured), false = strict side-by-side columns. Two named behaviours, one setting — the shape of a good API.
• First-fit is not optimal, but it is provably close. For online colouring of interval graphs, first-fit uses at most 8ω colours (Brightwell–Kierstead–Trotter, and Narayanaswamy & Babu), with a known lower bound of ≥5ω. In practice on project data it lands at or within one of ω. This is the licence to trade optimality for stability — the penalty is bounded by a small constant, never unbounded.

2.3 The algorithm: first-fit in document order

The critical, non-obvious choice: do not sort by start date.

Sorting by start date gives the provably minimal number of lanes. It also means that changing one task's start date changes its position in the sort, which can cascade lane reassignments through the entire chart — including tasks above the edit. That is the "user drags X, Y teleports" failure, and it is inherent to start-order packing.

Instead, iterate in the order the user already sees and controls: the flattened document order from buildFlattenedTaskList() (src/utils/hierarchy.ts), driven by Task.order and Task.parent.

// PROPOSED: src/utils/rowPacking/packRows.ts

/** A closed day-number interval [start, end]. Milestones have start === end. */
interface Interval { start: number; end: number; taskId: TaskId }

function toDayInterval(t: Task): Interval {
  const start = toDayNumber(t.startDate);
  const end = t.type === "milestone"
    ? start                                          // point in time
    : toDayNumber(t.endDate || t.startDate);         // inclusive, mirrors getTaskBarGeometry
  return { start, end, taskId: t.id };
}

/**
 * Can `iv` join `lane`? `lane` is kept sorted by start, so we only need to
 * check the two neighbours around the insertion point.
 * gapDays === 0 means back-to-back bars (A ends Mar 20, B starts Mar 21) may share a lane.
 */
function fits(iv: Interval, lane: Interval[], gapDays: number): boolean {
  const i = lowerBoundByStart(lane, iv.start);      // binary search, O(log k)
  const left = lane[i - 1];
  const right = lane[i];
  if (left  && left.end + gapDays >= iv.start) return false;
  if (right && iv.end  + gapDays >= right.start) return false;
  return true;
}

/** Returns lane index per task, parallel to `tasks`. */
export function packBand(tasks: Task[], gapDays: number): number[] {
  const lanes: Interval[][] = [];
  const assigned: number[] = [];

  for (const task of tasks) {              // ← DOCUMENT ORDER. Never re-sorted.
    const iv = toDayInterval(task);
    let placed = -1;
    for (let l = 0; l < lanes.length; l++) {        // ← FIRST fit, not best fit
      if (fits(iv, lanes[l], gapDays)) { placed = l; break; }
    }
    if (placed === -1) { lanes.push([]); placed = lanes.length - 1; }
    insertSortedByStart(lanes[placed], iv);
    assigned.push(placed);
  }
  return assigned;
}

First-fit, not best-fit. Best-fit (pick the lane whose last bar ends closest to this one) packs marginally tighter, but "closest" flips on a one-day edit, so bars swap lanes constantly. First-fit is also visually better: it biases everything toward low lane indices, giving a dense top and a ragged bottom — the layout equivalent of left-aligned text.

2.4 Complexity, and whether it can run every render

packBand is O(n · L · log k) where L = lanes in the band and k = bars per lane. For n = 500 with a realistic L ≈ 10–20: ~50k comparisons, comfortably sub-millisecond — an order of magnitude cheaper than the buildFlattenedTaskList() traversal that already runs in useFlattenedTasks. Even at n = 5000 it is a few milliseconds.

So raw cost is a non-issue. The real cost is re-running it for the wrong reasons. useFlattenedTasks memoizes on tasks identity, and with Immer that identity changes on any task mutation — renaming a task, nudging progress, picking a colour. None of those affect packing, but all of them would invalidate the memo and force a full repack plus a full chart re-render.

Recommendation: a layoutEpoch counter in taskSlice, incremented only by mutations that touch startDate, endDate, order, parent, type, or open:

const layout = useMemo(
  () => buildLaneLayout(flattenedTasks, { gapDays, rollupCollapsed }),
  [layoutEpoch, hiddenTaskIds, gapDays, rollupCollapsed, rowLayout]
);

O(1) to check, and it makes the invalidation rule explicit and testable rather than emergent.

Incremental update — not needed now, but free later. Document-order first-fit is prefix-stable (§2.5), so lanes for t₀…tᵢ₋₁ are unaffected by any change at tᵢ. Checkpoint the lane arrays every 256 tasks and a repack restarts from the last checkpoint before the lowest changed index. Note this and move on; do not build it for v1.

Derived, never persisted. The brief is right that there is no lane field on Task, and there should not be one. Because buildLaneLayout is a pure function of (flattened tasks, gapDays, rollupCollapsed), it can be called identically from the screen renderer and from prepareExportTasks.ts / svgExport / pdfExport. Export and screen agree by construction — no cache to invalidate, no migration to write, and the CLAUDE.md rule about export filtering being a single source of truth is satisfied for free. Persisting lane hints would forfeit all of that in exchange for solving a problem (§2.5) that has a better solution.

2.5 Stability — the biggest UX risk, head-on

Prefix-stability invariant. With first-fit in document order, lane(tᵢ) is a function of (t₀ … tᵢ) only. Therefore an edit to tᵢ can never move any tⱼ with j < i. Nothing above the edited row moves.

That is a guarantee you can put in the help text: "Editing a task can only affect rows below it." Start-order packing cannot make that promise.

The remaining failure modes and their answers:

Failure mode	Answer
Bars below the edit reflow.	Accepted, bounded, and explainable. Mitigate with a 150ms SVG y transition (prefers-reduced-motion: reduce ⇒ no transition) so the eye can follow rather than being teleported.
The bar you are dragging jumps lanes mid-drag. The worst one — the bar moves out from under the cursor.	Freeze the layout for the duration of the gesture. chartSlice already owns drag state; gate the memo on it, so buildLaneLayout is not recomputed between mousedown and mouseup. The dragged bar stays on its original lane's y while its x follows the pointer. On release, recompute once and animate. This preserves purity (no path-dependent state, so export still equals screen) while removing all in-gesture motion.
Reorder / indent / outdent moves lots of bars.	Expected — the user just changed the document order, which is the packing input. No mitigation needed beyond the transition.
Unhide / expand causes a large reflow.	Same category. Worth scrolling the affected band into view.
Ties. Two tasks with identical dates.	Never ambiguous: document order is a total order (order is unique per parent), so first-fit is deterministic. No tie-break rule is required at all — a quiet benefit of not sorting.
Persisted lane hints as an alternative	Rejected. Hints go stale, need a migrate.ts step, need conflict resolution when a hinted lane is occupied, and break export/screen equality. The freeze-during-gesture rule solves the same problem with zero persisted state.

Optional escape hatch (default off): a Minimize rows toggle that switches to start-order first-fit, guaranteeing the theoretical minimum ω lanes. Label it honestly: "Uses the fewest possible rows. Bars may move between rows when you edit dates." Ship it only if users ask.

2.6 Gaps, padding, and the zoom trap

The trap, stated plainly: a 1px gap is one month at year zoom and a fraction of a day at day zoom. Any pixel-based collision test makes lane assignment a function of scale.pixelsPerDay, which means:

• the chart's height changes while you zoom — scroll position becomes meaningless, and OwnChart's infinite-scroll machinery (INFINITE_SCROLL_THRESHOLD, FIT_TO_VIEW_BLOCK_MS in layoutConstants.ts) is fighting a moving target;
• worse, exports would disagree with the screen. The export renderers use their own scale (src/utils/export/renderConstants.ts, calculations.ts). A pixel-based packer would produce a different lane count, different row count and different image height depending on what zoom the user happened to be at when they hit Export. That is a silent-wrong-output bug, and CLAUDE.md explicitly requires the export path to agree with the screen.

Rule: packing is computed in date units and is invariant under zoom. pixelsPerDay is not an input to packBand.

Collision rule, with the touching case defined explicitly (vis.js #343 shows what happens when you don't):

• Dates are inclusive days; a bar occupies [start, end] and renders across [start, end+1) in pixels.
• Two tasks may share a lane iff A.end + gapDays < B.start.
• packingGapDays default 0 — back-to-back tasks (A ends Mar 20, B starts Mar 21) do share a lane. This is the whole appeal: a dependency chain collapses onto one line. Offer 0 / 1 / 2 in preferences for users who want breathing room.
• Working-day awareness: OwnChart has always-on working-day arithmetic (workingDaysConfig). gapDays > 0 should be counted in working days for consistency with duration semantics.

The visual consequences of a zoom-independent packer are then fixed at render time, where they belong:

1. Hairline separation. Give every bar a 1px stroke in the grid background colour. Abutting bars in one lane never visually merge, at any zoom, at zero packing cost. (Same trick vis.js needs margin.item.horizontal for, but zoom-independent.)
2. Minimum bar width. Clamp rendered width to ~3px so a 1-day task at 5% zoom (MIN_ZOOM = 0.05, timelineUtils.ts:32) does not disappear. Milestones already do this — MILESTONE_SIZE_MIN = 6, MAX = 10, TaskBar.tsx:38-40.
3. Labels. TaskLabelPosition is "before" | "inside" | "after" | "none" (preferences.types.ts:28). In packed layout, before / after labels of neighbours in the same lane will collide, and the collision is zoom-dependent. Do not add label width to the packing extent — that would drag pixelsPerDay back into the packer through the back door. Instead: in packed layout force inside with clipping, and suppress the label below ~24px of bar width. Consider a title/tooltip fallback so nothing is lost.

2.7 Hierarchy — bands, and rollup on collapse

Three possible policies:

• (A) Ignore hierarchy, pack globally. Maximum compression; annihilates the outline and any hope of a comprehensible table. Reject as default.
• (B) Band per summary (recommended default). Every summary keeps its own row, exactly as today, rendering its bracket over the full child span. Its descendants pack into lanes inside its band — a contiguous run of rows belonging to that summary. Tasks with no parent pack into a root band. Compression comes from the leaves, which is where the row count actually lives; the outline survives; the table↔chart correspondence survives at summary level. This also matches how react-calendar-timeline scopes stackItems per group, and how vis.js scopes stackSubgroups.
• (C) Rollup on collapse (recommended, additive). When Task.open === false, instead of hiding the children, pack them onto the summary's band. This is precisely MS Project's "Always roll up Gantt bars" + "Hide rollup bars when summary expanded" pair, and precisely DHTMLX's split_placement: "auto" ("inline when the parent is collapsed, subrows when expanded").

Recommendation: B for expanded summaries, C for collapsed ones — i.e. DHTMLX auto, with MS Project's naming (rollupCollapsedSummaries, default true).

Why this is the important recommendation and not a detail: it means the "collapse everything into one line" outcome the issue author wants is reached through a control that already exists — the collapse chevron — with no new interaction model, no new CRUD story, and no new keyboard shortcut. It also converts collapse from a lossy operation (children disappear) into a lossless one (children are still there, on fewer rows). That is a strict improvement to an existing feature, delivered as a side effect.

Nesting: bands nest. A collapsed summary inside an expanded summary rolls its own subtree up into a sub-band. packBand is called recursively per band; lanes never cross a band boundary.

2.8 Milestones

Milestones are points, and they break in the opposite direction from bars:

• A bar's date interval is wider than its rendered pixels at low zoom → looks fine, packs fine.
• A milestone's date interval is 1 day, but the diamond is 2 × size wide with size = clamp(pixelsPerDay / 2, 6, 10) (TaskBar.tsx:452-457) — 12–20px regardless of zoom. At 5% zoom (pixelsPerDay ≈ 0.9), a 20px diamond spans ~22 days of timeline. Two milestones three days apart pack happily into one lane and then draw right on top of each other.

You cannot fix this in the packer without making it zoom-dependent, which §2.6 forbids. So:

1. Pack milestones in the same lanes as bars, footprint [d, d], same document-order first-fit. Full compression; and it matches the rollup precedent — Bryntum's rollup: true and MS Project's Rollup field are both best known for putting milestones on a summary bar.
2. Solve overlap at render time by clustering. When two diamonds in the same lane would overlap at the current pixelsPerDay, draw a single cluster glyph (diamond with a count badge, ◆3) that opens a popover listing the members on hover/click. This is the map-marker clustering pattern. Crucially it is zoom-dependent but height-neutral: clustering changes only what is drawn inside a lane, never the number of lanes, so the chart never reflows vertically as you zoom.
3. Because a milestone's endDate may be empty, reuse the existing task.endDate || task.startDate fallback so toDayInterval cannot produce a NaN interval.
4. Variant worth prototyping but not recommended as default: a dedicated milestone lane at the top of each band (created only when the band contains milestones). Cleaner-looking, but costs a row per band and separates a milestone from the work it terminates, which is usually exactly the adjacency the user wants to see.

---

PART 3 — THE AUTHOR'S "TRUE SINGLE LINE" QUESTION

Direct answer: do not ship it, and the author's suspicion is right — but for a sharper reason than they gave.

1. It is not a feature, it is a constant. With the pipeline above, "everything on one line, overlapping" is lane = 0 for every task — a three-line branch in packBand. The engineering question is not build vs. don't, it is expose vs. don't.
2. It produces a display you cannot edit in. Overlapping bars have no unambiguous hit target. useTaskBarInteraction (drag/resize), useDependencyDrag (connection handles), useProgressDrag and ConnectionHandles all assume you can point at a bar. An overlay mode needs a whole z-order + hit-priority story, and even with one, "click the bar you can't see" is not a solvable interaction. This collides directly with the author's non-negotiable constraint that all features work in every display. An overlay mode is the one display where feature parity is structurally impossible — which is by itself sufficient grounds to reject it.
3. On "does it duplicate the summary feature": not exactly. A summary bar draws one continuous span from min-start to max-end — it is lossy in a specific way: it hides the gaps. Overlapping bars keep the gaps but lose the identities. Both are lossy; they lose different things.
4. But the product answer is the same as the author's instinct. The genuinely useful "one line" is collapse-with-rollup (§2.7 C): it shows the real gaps, keeps every bar individually clickable, draggable and connectable, and reuses a control that already exists. Ship that instead.
5. If it ever comes back, ship it as a read-only Overview toggle in the export dialog only, where nothing is clickable anyway and the cost is zero.

---

PART 4 — ZOOM

Recommendation: lane assignment does not change on zoom. Ever.

Justification, in order of weight:

1. Export correctness. Export renders at its own scale via renderConstants.ts / calculations.ts. Zoom-dependent packing means the PNG/PDF/SVG has a different row count and a different height than the screen the user was looking at — silent, and it violates the CLAUDE.md rule that the export path must reflect on-screen filtering.
2. Vertical reflow while zooming is intolerable. Zoom is a high-frequency, continuous gesture (PRESET_ZOOM_LEVELS = [5,10,25,50,75,100,150,200,300], MIN_ZOOM 0.05, MAX_ZOOM 3.0). If the chart's height changes on every zoom step, scroll anchoring, fitToView and infinite scroll all fight each other. The chart growing taller as you zoom out is a particularly bad look.
3. It is a cheap invariant to hold. Everything zoom actually breaks — merged-looking abutting bars, unreadable labels, colliding diamonds — is a rendering problem with a rendering fix (hairline stroke, label suppression, milestone clustering). Each of those is zoom-dependent by design and height-neutral by construction.

So the split is: lane assignment = f(dates, order, gap) — zoom-invariant. Glyph rendering inside a lane = f(lane assignment, pixelsPerDay) — zoom-dependent, height-neutral.

---

PART 5 — PIPELINE

flowchart TD
  A["taskSlice.tasks<br/>order · parent · dates · type · open"] --> B["buildFlattenedTaskList()<br/>src/utils/hierarchy.ts"]
  C["chartSlice.hiddenTaskIds"] --> B
  B --> D["flattenedTasks / allFlattenedTasks<br/>src/hooks/useFlattenedTasks.ts"]
  D --> E{"viewSettings.rowLayout"}

  E -->|"single"| F["row = array index<br/>today's behaviour, untouched"]
  E -->|"packed"| G["groupIntoBands()<br/>band = summary subtree | root"]
  G --> H["packBand() per band<br/>first-fit · DOCUMENT order<br/>date-unit collision · packingGapDays"]

  P["chartSlice drag state"] -.->|"freeze memo<br/>during gesture"| H
  Q["layoutEpoch<br/>(dates/order/parent/type/open only)"] -.->|"memo key"| H

  F --> I["LaneLayout<br/>Map&lt;TaskId, {band, lane, row}&gt;<br/>+ bandOffsets + totalRows"]
  H --> I

  I --> J["getTaskBarGeometry({ rowIndex: row })<br/>src/utils/timelineUtils.ts:349"]
  I --> K["GridLines · SelectionHighlight<br/>rowCount = totalRows, not taskCount"]
  I --> L["DependencyArrow → calculateArrowPath()<br/>same lane ⇒ buildSameRowHookPath()<br/>elbowPath.ts:74,423,431"]
  I --> M["TaskTable — lane-grouped rows<br/>(Concept B/C territory)"]
  I --> N["prepareExportTasks + svg/pdf/png<br/>same pure fn ⇒ export ≡ screen"]

  Z["scale.pixelsPerDay (zoom)"] -.->|"render only:<br/>hairline · label clip · ◆ clustering"| J
  Z -.->|"NEVER an input"| H

  style H fill:#1e40af,color:#fff
  style Z fill:#7c2d12,color:#fff

Loading

---

PART 6 — WIREFRAMES

Eight items, same data in every panel.

DATA
  Delivery       summary, parent of all below
    ◆ Kickoff    milestone   Mar 3
    Requirements Mar 3  – Mar 10
    Design       Mar 11 – Mar 20
    Backend      Mar 21 – Apr 10
    Frontend     Mar 21 – Apr 5
    QA           Apr 6  – Apr 15
    ◆ Launch     milestone   Apr 16

(1) Row Layout: One per Row — today. 8 rows.

 #  │ Task            │ Mar 3     Mar 13    Mar 23    Apr 2     Apr 12
────┼─────────────────┼───────────────────────────────────────────────
 1  │ ▾ Delivery      │ ▐███████████████████████████████████████████▌
 2  │    ◆ Kickoff    │ ◆
 3  │    Requirements │ ▓▓Reqs▓▓
 4  │    Design       │         ▓▓Design▓▓
 5  │    Backend      │                   ▓▓▓▓▓▓Backend▓▓▓▓▓▓▓▓
 6  │    Frontend     │                   ▓▓▓▓Frontend▓▓▓▓
 7  │    QA           │                                   ▓▓▓▓QA▓▓▓▓
 8  │    ◆ Launch     │                                             ◆

(2) Row Layout: Packed, summary expanded — 8 rows → 3.

Band = Delivery. Summary keeps its own row; the seven leaves first-fit into two lanes.

 #  │ Task            │ Mar 3     Mar 13    Mar 23    Apr 2     Apr 12
────┼─────────────────┼───────────────────────────────────────────────
 1  │ ▾ Delivery      │ ▐███████████████████████████████████████████▌
 ·  │  ⤷ 7 tasks in   │ ◆       ▓▓Design▓▓▓▓▓▓▓▓Backend▓▓▓▓▓▓▓▓     ◆
 ·  │    2 lanes      │ ▓▓Reqs▓▓          ▓▓▓▓Frontend▓▓▓▓▓▓▓▓QA▓▓▓▓

Trace of packBand in document order, gapDays = 0:

step	task	dates	lane 0 occupied to	lane 1 occupied to	→ lane
1	◆ Kickoff	Mar 3	—	—	0 (new)
2	Requirements	Mar 3–10	Mar 3	—	1 (new — overlaps Kickoff)
3	Design	Mar 11–20	Mar 3	Mar 10	0
4	Backend	Mar 21–Apr 10	Mar 20	Mar 10	0
5	Frontend	Mar 21–Apr 5	Apr 10	Mar 10	1
6	QA	Apr 6–15	Apr 10	Apr 5	1
7	◆ Launch	Apr 16	Apr 10	Apr 15	0

Two things this trace makes concrete:

• Design→Backend abut (Mar 20 / Mar 21) and share lane 0 with gapDays = 0. Without the hairline stroke from §2.6 they render as one continuous bar and the user loses a task boundary. This is exactly vis.js issue #343.
• Frontend→QA abut in lane 1 and are a real FS dependency — the arrow between them is now a same-lane arrow, handled by buildSameRowHookPath() (elbowPath.ts:423). Worth an explicit E2E case.

(3) Row Layout: Packed, Delivery collapsed with rollupCollapsedSummaries — 8 rows → 2.

Children are not hidden. They roll up onto the parent's band. This is the "one line" the issue asks for, reached by clicking the chevron that already exists.

 #  │ Task            │ Mar 3     Mar 13    Mar 23    Apr 2     Apr 12
────┼─────────────────┼───────────────────────────────────────────────
 1  │ ▸ Delivery      │ ◆       ▓▓Design▓▓▓▓▓▓▓▓Backend▓▓▓▓▓▓▓▓     ◆
 ·  │    (rolled up)  │ ▓▓Reqs▓▓          ▓▓▓▓Frontend▓▓▓▓▓▓▓▓QA▓▓▓▓

Compare today's collapse, which yields one row and shows nothing but a bracket — the children are simply gone:

 1  │ ▸ Delivery      │ ▐███████████████████████████████████████████▌

The table column above is deliberately sketchy (⤷ 7 tasks in 2 lanes) — how the left panel represents a lane is Concept B/C's problem. My only constraint on them: LaneLayout must be the single shared source for both panels, or the two scroll containers that useSyncScroll keeps aligned will drift.

---

PART 7 — PACKING-SPECIFIC PROBLEMS NOT IN THE ISSUE

Within my scope only; UX/CRUD consequences are for Concepts B and C.

1. globalRowNumber stops meaning "row". FlattenedTask.globalRowNumber (hierarchy.ts:32) is a 1-based position used for Excel-style gap numbering. In packed layout it is no longer a y-coordinate. Keep it as a stable task ordinal and introduce a separate row in LaneLayout; do not overload it.
2. SelectionHighlight prev/next-sibling merging breaks. SelectionRows in ChartCanvas.tsx merges selection borders by checking tasks[index-1] / tasks[index+1]. Adjacent in the array ≠ adjacent on screen once packed. Selection highlighting has to become per-bar, or per-lane-run.
3. GridLines taskCount is now a row count. gridHeight = taskCount * rowHeight and horizontalLines (length taskCount + 1) must switch to LaneLayout.totalRows. Band boundaries probably want a heavier rule than lane boundaries.
4. Chart height changes when the layout toggles, which interacts with useInfiniteScroll, fitToView and FIT_TO_VIEW_BLOCK_MS. Preserve the anchor task across the switch, not scrollTop.
5. Marquee selection changes meaning. useMarqueeSelection currently sweeps rows; over a lane it sweeps a time range across unrelated tasks. Arguably an improvement, definitely a behaviour change with test coverage implications.
6. Vertical cell navigation has no target. useCellNavigation walks EDITABLE_FIELDS up/down by row. In a lane, "down" is ambiguous.
7. VRT baselines. Every packed-layout screenshot needs a Docker-generated baseline (npm run test:vrt:update), and the default must stay single so existing baselines don't churn.
8. File format + migration. Three new ViewSettings fields ⇒ entries in applyViewSettingsDefaults() (src/config/viewSettingsDefaults.ts), serialize.ts, validate.ts, and multiTabStorage.ts. All default to today's behaviour, so old files are unaffected.

---

PART 8 — WHERE I'M UNCERTAIN

• How many lanes real charts actually produce. If a typical OwnChart project yields ω ≈ 8, packing saves little and the whole feature underdelivers. Resolution: run packBand over a handful of real .ownchart files and report totalRows / taskCount. This should be the gate on the whole feature — cheap to measure, and it decides whether any of this is worth building.
• Whether document-order first-fit is meaningfully worse than optimal on real data. Theory bounds it at 8ω, practice is usually ≈ω, but I have not measured it on project-shaped data. Same experiment answers it: report both first-fit-document-order and greedy-by-start lane counts side by side.
• Same-lane dependency arrow legibility. buildSameRowHookPath() exists and handles the geometry, but it was written for the rare case, not the common one. Once a whole FS chain lands in one lane, every arrow in the chain is same-lane. Resolution: render wireframe (2) with real arrows before committing to D6.
• Milestone clustering thresholds. Whether ◆3 reads as helpful or as data loss is a judgement call I would want to see rendered.

---

Agent: Concept A — Naming & Layout/Packing Algorithm

[kitikonti]

Concept D — Architecture, Dependencies, Export & Test Strategy

Phase 1 contribution. I own the "how does this actually ship inside this codebase" half: state placement, the y = index * rowHeight refactor, dependency-arrow routing, export parity, file format, performance, tests, rollout. Everything below is written against files I read at dd0165e (v1.7.9). Line numbers are from that commit.

Throughout I use the neutral term packed for the new layout and list for today's classic one-row-per-task layout. Naming the feature is A/B's job — but I argue in §5 that the persisted key must be rowLayoutMode regardless of the marketing name, because compact is already taken by densityConfig.

---

TL;DR — the eight decisions

#	Question	Decision
1	Where does lane assignment live?	Pure src/utils/layout/packRows.ts + useRowLayout(flattenedTasks, mode, opts) hook, computed in GanttLayout and drilled. Not in chartSlice, not inside useFlattenedTasks.
2	y = index * rowHeight	Replace with one RowResolver interface. List mode is packRows with strategy "list" — a single code path, not two.
3	Dependency arrows	No product solves this — Syncfusion and DHTMLX both abandon same-row links. Reuse the packing algorithm a second time for arrow channels in a per-lane gutter; add badge degradation + dim-and-focus. Reject edge bundling and A* routing.
4	Auto-scheduling / cascade	Unchanged. Verified: src/utils/graph/* is index-free. Add an explicit invariant test.
5	Export	prepareExportTasks needs one change — and it is not about packing (§7). The real bug is that ExportRenderer ignores collapse state, which in packed mode silently changes lane assignment.
6	File format	Additive optional ViewSettings.rowLayoutMode. No migration. But ViewSettings has no unknown-field preservation — a pre-existing forward-compat hole worth closing.
7	Performance	Packing is trivially fast. The trap is not per-frame re-packing (drag is local state — verified), it is the lane snap on mouseup. Freeze lanes during a gesture.
8	Rollout	Phase 0 = resolver refactor with zero VRT baseline changes as the acceptance gate. Then packed behind a dev flag.

---

1. Where lane assignment lives

Recommendation

A pure module + a thin hook, computed once in GanttLayout and drilled as a prop — exactly like orderedTasks is today.

src/utils/layout/packRows.ts     ← NEW, pure, zero React, zero store
src/hooks/useRowLayout.ts        ← NEW, ~15 lines of useMemo

GanttLayout.tsx:57 already does const { flattenedTasks, orderedTasks } = useFlattenedTasks(); and drills orderedTasks down through TimelinePanel into ChartCanvas. The row layout follows the same wire.

Why not the three alternatives

Not a memoized field on chartSlice. Three concrete reasons, all grounded in this repo:

1. chartSlice state is serialized wholesale into multi-tab storage (useMultiTabPersistence.ts:164-196 reads useChartStore.getState() field by field, but the pattern invites accidental inclusion). Derived layout is not state and must never round-trip to disk.
2. Invalidation would have to be wired into every task mutation across taskSlice, insertionActions, groupingActions, indentOutdentActions, clipboardSlice, and the historySlice undo/redo path. That is six places to forget one.
3. historySlice uses the Command Pattern over task state. A derived cache in a sibling slice is invisible to it — undo would restore dates but not lanes.

Not an extension of useFlattenedTasks. That hook feeds three consumers: GanttLayout (canvas), useTaskRowData:231 (the table), and useHideOperations:82 (unhide-by-range). The table and the hide logic must stay strictly one-row-per-task. Adding a stage 3 there couples the table to a concern it must not have. Compose instead of extend.

Not a new selector on the store. Zustand selectors re-run on every store change; packing must be memoized on a content key, not on object identity (see §6).

Data shape

// src/utils/layout/packRows.ts

import type { TaskId } from "@/types/branded.types";
import type { FlattenedTask } from "@/utils/hierarchy";

/** Vertical layout strategy for the timeline panel. */
export type RowLayoutMode = "list" | "packed";

/** Placement of one task in the timeline's vertical coordinate system. */
export interface RowPlacement {
  taskId: TaskId;
  /** 0-based visual row ("lane"). In "list" mode this always equals `listIndex`. */
  lane: number;
  /** 0-based index in the flattened *visible* list — today's row index. */
  listIndex: number;
  /** 1-based number from the full list, preserving Excel-style gaps for hidden rows. */
  globalRowNumber: number;
  /** Left-to-right position within the lane. Drives tab order and arrow disambiguation. */
  slot: number;
}

export interface RowLayout {
  mode: RowLayoutMode;
  /** The only lookup renderers need. */
  byTaskId: ReadonlyMap<TaskId, RowPlacement>;
  /** lanes[i] = task ids in lane i, sorted by start date then `order`. */
  lanes: ReadonlyArray<ReadonlyArray<TaskId>>;
  /** Visual rows the canvas must draw (excludes the +1 placeholder row). */
  laneCount: number;
  /**
   * Bumped only when placement actually changes. Lets `React.memo` compare a
   * number instead of deep-comparing a Map. Renaming a task does not bump it.
   */
  revision: number;
}

export interface PackOptions {
  /** Minimum horizontal gap, in days, required between two bars in one lane. */
  minGapDays: number;
  /** Prefer keeping same-parent tasks in the same lane. */
  groupByParent: boolean;
  /** Summary tasks are not packed — see "Open questions". */
  summaryHandling: "excluded" | "ownLane";
}

/**
 * Assign every visible task to a lane.
 * `previous` enables lane stability: a task that still fits its previous lane
 * keeps it, so the user's mental map survives an edit (see §6).
 */
export function packRows(
  flattened: ReadonlyArray<FlattenedTask>,
  mode: RowLayoutMode,
  options: PackOptions,
  previous?: RowLayout
): RowLayout;

The resolver — the abstraction the renderers see

export interface RowResolver {
  readonly mode: RowLayoutMode;
  readonly laneCount: number;
  readonly rowHeight: number;
  /** Lane index, or null when the task is not laid out (hidden / collapsed away). */
  laneOf(taskId: TaskId): number | null;
  /** Top edge y of the task's lane, in canvas coordinates. Null when not laid out. */
  yOf(taskId: TaskId): number | null;
  /**
   * Inverse mapping. Needs BOTH coordinates: in packed mode a lane holds many
   * tasks, so y alone cannot identify one. Used by the timeline context menu
   * and, later, by virtualization.
   */
  taskAtPoint(x: number, y: number): TaskId | null;
}

export function createRowResolver(layout: RowLayout, rowHeight: number): RowResolver;

taskAtPoint is not speculative. src/hooks/useTimelineAreaContextMenu.ts:84-87 currently does:

const rowIndex = Math.floor(svgY / rowHeight);
if (rowIndex >= 0 && rowIndex < tasks.length) {
  const taskId = tasks[rowIndex].id;

That is the y→task inverse, and it is wrong by construction in packed mode. It needs x. Putting taskAtPoint on the interface from day one forces every inverse-mapping site to be found and fixed rather than silently mis-hitting.

Composition with the existing two-stage pipeline

Stage 1  buildFlattenedTaskList(tasks, collapsedIds)  → allFlattenedTasks  (globalRowNumber assigned)
Stage 2  filter(hiddenTaskIds)                        → flattenedTasks     (row-number gaps preserved)
Stage 3  packRows(flattenedTasks, mode, opts, prev)   → RowLayout          ← NEW, additive

Stage 3 consumes stage 2's output and never mutates it. globalRowNumber is carried through into RowPlacement untouched, so Excel-style gaps, hide/unhide-by-range, and the row-number column keep working with zero changes. listIndex is the stage-2 array index — i.e. today's rowIndex — which is precisely why list mode is the identity case.

Files that change, and what changes in each

File	Change
src/utils/layout/packRows.ts	NEW. Pure packing + createRowResolver.
src/hooks/useRowLayout.ts	NEW. useMemo over packRows, keyed on a content key (§6), plus a useRef holding the previous layout for stability.
src/components/Layout/GanttLayout.tsx	Call useRowLayout(flattenedTasks, mode, opts); pass resolver into TimelinePanel; layoutCalculations input taskCount → max(flattenedTasks.length, resolver.laneCount).
src/components/Layout/TimelinePanel.tsx	Pass resolver through to ChartCanvas.
src/components/GanttChart/ChartCanvas.tsx	:168 SelectionRows y from resolver.yOf(task.id); :321 geometry loop rowIndex: index → resolver.laneOf(task.id); :413/:417 height math from laneCount; :480 <TaskBar rowIndex={index}> → lane.
src/components/GanttChart/GridLines.tsx	:188-193 taskCount prop is already just a number — pass laneCount. Zero code change, only a different value. Nicest file in the whole refactor.
src/components/GanttChart/TaskBar.tsx	:90/:283/:319 rename prop rowIndex → lane (semantic clarity only; the value flows straight to getTaskBarGeometry).
src/components/GanttChart/DependencyArrows.tsx	:75-95 tasks.forEach((task, index) => … rowIndex: index) → resolver.laneOf(task.id). Add resolver prop.
src/utils/timelineUtils.ts	getTaskBarGeometry at :349-372 needs no signature change — it already takes rowIndex. Optionally rename the field to lane.
src/hooks/useTimelineAreaContextMenu.ts	:84-87 → resolver.taskAtPoint(svgX, svgY).
src/hooks/useMarqueeSelection.ts	No change. It already works off taskGeometriesArray (ChartCanvas.tsx:305-356), which becomes lane-correct automatically. Nice payoff of the existing design.
src/utils/layoutCalculations.ts	LayoutDimensionsInput.taskCount → add laneCount; totalContentHeight uses max(taskCount, laneCount).
src/components/Export/ExportRenderer.tsx	:459 taskCount, :472 DependencyArrows, :481-483 rowIndex={index} — same three edits as ChartCanvas (§4).
src/utils/export/taskTableRenderer.ts	:478 rowY = startY + rowIndex * rowHeight — stays as-is, the left table is never packed (§4).
src/utils/export/exportLayout.ts	:128 contentHeight = taskSize.count * rowHeight → lane-aware.
src/utils/export/pdfLayout.ts	:410 flattenedTasks.length * rowHeight → lane-aware.
src/store/slices/chartSlice.ts	Add rowLayoutMode, rowLayoutOptions, setRowLayoutMode, toggleRowLayoutMode next to showDependencies / hiddenTaskIds.
src/hooks/useFileOperations.ts	useFeatureViewSettings:369 must emit the new field — save rebuilds ViewSettings from the store, so a field missed here is silently never written (§5).

Correction to the shared brief: it lists SelectionHighlight as containing y = index * rowHeight. It does not — src/components/GanttChart/SelectionHighlight.tsx is a date-range vertical band with y=0 and a full-height rect. The row math is in the SelectionRows sub-component inside ChartCanvas.tsx:154-205. Worth fixing in the synthesis so nobody hunts the wrong file.

---

2. Killing y = index * rowHeight

The proposal: one path, not two

// Classic mode is not a branch. It is a strategy value.
const layout   = packRows(flattenedTasks, "list", opts);   // lanes[i] = [tasks[i]]
const resolver = createRowResolver(layout, rowHeight);
// resolver.laneOf(id) === listIndex, resolver.yOf(id) === listIndex * rowHeight

Every renderer takes resolver: RowResolver and asks for a y. Nobody computes index * rowHeight. The index from Array.prototype.map is used for React keys and nothing else — and even that should become task.id.

Rendering becomes:

{tasks.map((task) => {
  const lane = resolver.laneOf(task.id);
  if (lane === null) return null;          // not laid out — skip
  return <TaskBar key={task.id} task={task} scale={scale} lane={lane} … />;
})}

Why classic-as-a-special-case beats two parallel render paths

For.

1. It is the author's constraint, mechanically enforced. "Independent of which display I am in, I need all features." Two render paths make parity a matter of discipline. One path makes it a matter of arithmetic. Every feature added to ChartCanvas after this lands works in both modes for free, forever.
2. This repo already has receipts on what parallel paths cost. ExportRenderer.tsx is a second render path that duplicates ChartCanvas's row math — and it has already drifted: it calls buildFlattenedTaskList(tasks, new Set<TaskId>()) (ExportRenderer.tsx:264, svgExport.ts:504), i.e. it ignores collapse state entirely, so exports show rows the screen hides. That drift is invisible today because both paths use the same formula. In packed mode it becomes structural (§4). One divergent path is already one too many; adding a third would be reckless.
3. The identity case is provably free. packRows in list mode is a single O(n) map. No heap, no sort. The resolver is a Map.get. Nothing measurable.
4. It buys a free regression gate. If list mode is genuinely the identity case, then after the Phase-0 refactor npm run test:vrt must pass with zero baseline changes and all ~190 E2E must pass untouched. That is a pixel-exact proof of "no behaviour change" that a two-path design cannot give you.

Against — stated honestly.

1. A resolver bug breaks classic mode too. Blast radius goes from "new feature" to "the whole product". Mitigated by (a) the property test mode === "list" ⇒ lane === listIndex for all inputs, (b) the zero-VRT-diff gate, (c) shipping Phase 0 as its own refactor: release so a regression bisects to one commit.
2. Prop-drilling tax: resolver threads GanttLayout → TimelinePanel → ChartCanvas → TaskBar. Four files carry a prop they did not need. Acceptable — it mirrors how orderedTasks and rowHeight already travel, so it introduces no new pattern.
3. A shared abstraction can get over-general. Countered by keeping RowResolver to four members and refusing to add a fifth without a caller.

Verdict: single path. The parity constraint is non-negotiable and two paths cannot honour it.

---

2b. Lanes must be zoom-invariant — a hard constraint on the packing algorithm

The algorithm is Agent A's, but one property of it is architectural, not algorithmic, and I want it nailed down before A finalises: packRows must consume dates, never pixels. scale must not be an input.

Why it is tempting to pack in pixel space

Two things in the code make date-space packing look insufficient:

1. Milestones have a pixel footprint, not a date footprint. TaskBar.tsx:451-456:

   const size = Math.min(MILESTONE_SIZE_MAX, Math.max(MILESTONE_SIZE_MIN, scale.pixelsPerDay / 2));
   const centeredX = geometry.x + scale.pixelsPerDay / 2 - size;

   The diamond is clamped to a min/max pixel size. At low zoom a one-day milestone can render 24 px wide while occupying one day of a 2 px/day timeline — a 12-day visual footprint. Two milestones a week apart do not overlap in date space but visibly collide.
2. Labels render outside the bar. taskLabelPosition supports "before" / "after" (chartSlice:108), and TaskShapeLabel anchors at x + size*2. A bar's label can extend a couple of hundred pixels to its right, over whatever the packer put there.

Why packing in pixel space would nevertheless be a mistake

If RowLayout depends on scale, four things break, and the fourth is decisive:

1. useZoom fires continuously on wheel — packing would re-run every zoom frame, and RowLayout.revision would churn, invalidating every memo boundary in §6.
2. Lanes would visibly reflow while zooming. Zoom is a navigation gesture; content must not rearrange under it.
3. VRT baselines become zoom-sensitive, i.e. flaky.
4. Export would disagree with the screen. ExportOptions.zoomMode supports "fitToWidth" (exportLayout.ts:118-127), which computes a different scale than the screen's. Pixel-space packing means the exported chart has a different lane assignment than the chart the user is looking at — precisely the silent divergence §4 exists to prevent, reintroduced through the front door.

Recommendation

Lanes are computed in date space and are zoom-invariant. Visual collisions from labels and milestone diamonds are solved by rendering rules, not by the packer.

• In packed mode, force taskLabelPosition to "inside" (or suppress labels and move them to hover). Outside labels are incompatible with row packing by construction — no packing scheme survives an arbitrary-length overlay that is not part of the interval.
• Give milestones a packing span of [start, start + 1 day] and default minGapDays to 1 in packed mode. Since the diamond is capped at pixelsPerDay / 2 per side, one day of gap covers the diamond at any zoom ≥ ~2 px/day; below that, bars are sub-pixel and legibility is already lost for other reasons.
• If a residual pixel-space collision ever matters, fix it with a rendering tweak (clamp the diamond, elide the label), never by feeding scale into packRows.

Hand-off to A: treat "scale is not an input to packing" as a fixed requirement rather than a design option.

---

3. Dependency arrows — the genuinely hard part

Prior art first: everyone who tried this gave up

This is worth stating bluntly, because it reframes the problem. I looked for a product that packs multiple bars per row and draws dependency arrows between them properly. I did not find one.

• Syncfusion Gantt is the closest analogue — enableMultiTaskbar puts child bars on the collapsed parent row. With allowTaskbarOverlap: true (default, standard row height) it claims full dependency support. But with allowTaskbarOverlap: false — i.e. actual vertical stacking, our case — the docs state plainly: "Dependencies between tasks of the same resource are not supported due to vertical stacking, though inter-resource dependencies work." They removed the feature rather than route the edges. https://ej2.syncfusion.com/react/documentation/gantt/multi-taskbar
• DHTMLX Gantt split tasks (render: "split", split_placement: auto|inline|subrow) put subtasks inline on the parent row. Links in that mode are a known unsolved problem; the official support answer is "there is no way to change how the links are rendered", with a workaround of hiding the default links via CSS and re-rendering them yourself through addTaskLayer. https://docs.dhtmlx.com/gantt/guides/split-tasks/ · https://forum.dhtmlx.com/t/how-to-display-task-links-clearly-in-split-gantt-view/78561
• Bryntum Scheduler has the packing (eventLayout: 'stack' | 'pack' | 'mixed' | 'none', plus barMargin) and has dependencies, but its obstacle-avoiding option drawAroundParents is flagged experimental with a documented "negative impact on performance". https://bryntum.com/products/scheduler/docs-llm/api/Scheduler/view/mixin/SchedulerEventRendering.md · https://bryntum.com/products/gantt/docs-llm/api/Scheduler/feature/Dependencies.md

So there is a genuine gap here, and doing this well would be a differentiator. It also means: budget real effort, and do not expect to copy a solution.

Two side notes from that survey worth carrying elsewhere:

• Bryntum's four eventLayout values are useful vocabulary for the naming debate — and none ("allows events to overlap") is exactly the "really just one line" mode the author speculated about, shipped by a real product. Evidence that the question is legitimate rather than redundant with summaries.
• Bryntum's stack mode grows the row height to fit; pack shrinks the bars. OwnChart should pick stack semantics (lanes, uniform bar height) — shrinking bars fights the density presets.

What the code does today

src/utils/arrowPath/elbowPath.ts is a well-built orthogonal router. It already has a same-row concept: isSameRow() with SAME_ROW_THRESHOLD_PX = 2. Today that fires only for milestone/rounding coincidences. In packed mode it becomes the common case, and the current behaviour is:

• FS same-lane → buildElbowAtTurnX short-circuits to buildStraightLine (:102-104). A flat horizontal segment at bar-centre height, in the gap between two bars.
• SS / FF same-lane → buildSameRowHookPath → a U-shaped dip below the lane, offset by max(4·r, rowHeight·0.4) (ROUTING_OFFSET_RATIO = 0.4).
• SF same-lane → falls into the S-curve branch.

So SS/FF/SF already route out of the lane; FS does not. With fifteen bars in one lane you get fifteen collinear horizontal stubs at identical y, plus a pile of U-hooks all using the same middleY. Unreadable, and worse, ambiguous — you cannot tell which stub belongs to which pair.

Recommendation, in priority order

(a) Reserve a routing gutter per lane, and route same-lane FS into it.

In packed mode set laneHeight = taskBarHeight + taskBarOffset*2 + gutter, where gutter ≈ 0.5 × taskBarHeight. Extend calculateArrowPath so that same-row FS with a small horizontal gap uses buildSCurvePath into the gutter instead of buildStraightLine. This is a ~10-line change to one if in elbowPath.ts:411-419, gated on a new optional routing?: { channelY?: number } argument so list-mode behaviour is byte-identical.

(b) Channel assignment — reuse the packing algorithm a second time.

This is the piece I want to argue hardest for. The problem "N horizontal segments in one gutter, some overlapping in x, minimise vertical space with no two overlapping segments sharing a y" is the same interval-packing problem as lane assignment. Same function, different input:

/** Shared primitive — used for BOTH task lanes and arrow channels. */
export function packIntervals<T>(
  items: ReadonlyArray<T>,
  getSpan: (item: T) => { start: number; end: number },
  minGap: number
): ReadonlyArray<number>;   // index-aligned track assignment

Then:

const channel = channelOf(dep.id);                       // 0, 1, 2, …
const middleY = laneBottom + (channel + 1) * CHANNEL_PITCH;

One tested primitive, two uses. This is the strongest argument for building packIntervals as a standalone generic rather than baking lane logic into packRows.

(c) Degrade to a badge, gated on rendered length — not on zoom.

Do not hide arrows below a zoom threshold. Zoom is the wrong signal: a six-month FS link is perfectly legible at 10% zoom, while two adjacent one-day tasks are illegible at 100%. Gate on the rendered geometry:

const dx = Math.abs(to.x - from.x);
const dy = Math.abs(to.y - from.y);
if (dx < MIN_ARROW_PX && dy < rowHeight) → render a small chevron badge on the bar edge instead of a path

Prior art validates the badge specifically: Jira Plans / Advanced Roadmaps offers a global Dependency style setting with exactly two values, Badges and Lines, and substitutes a badge whenever a line cannot usefully be drawn. https://support.atlassian.com/jira-software-cloud/docs/change-how-advanced-roadmaps-displays-dependencies/ The badge keeps the information ("this bar is linked, click to see to what") without the ink. Hover or select expands it to the full path.

(d) Focus mode — the cheapest big win, ship it first.

When the visible arrow count exceeds a threshold (start at ~150, tune against real projects), drop all arrows to ~15% opacity and render at full opacity only those incident to the current selection or hover set. DependencyArrows.tsx already has selectedDependencyId and ChartCanvas already tracks hoveredTaskId (:235) — an opacity pass over existing components, no routing change, no new geometry. Independently useful in list mode for dense projects, so it can ship on its own merits.

Honest calibration from the survey: no shipping product hides dependency lines unless selected. The closest precedents are highlight, not gate: Bryntum's highlightDependenciesOnEventHover ("highlight incoming and outgoing dependencies when hovering an event"), and Frappe Gantt's hover highlight of an arrow plus its two bars. Graph tools do ship real neighbour-focus (Gephi "autoselect neighbors", Cytoscape.js view-utilities highlightNeighbors()), and the underlying theory is degree-of-interest edge filtering (van Ham & Perer, InfoVis 2009, https://perer.org/papers/adamPerer-DOIGraphs-InfoVis2009.pdf). So: dim-and-focus, not hide. Never let the user reach a state where a dependency is invisible with no affordance.

Related and directly applicable: Syncfusion renders dependency lines only for tasks currently in the viewport when virtualization is on (https://ej2.syncfusion.com/react/documentation/gantt/task-dependency), and DHTMLX's smart_rendering explicitly covers links, not just tasks — "only the tasks and links visible on the screen at the moment are being rendered" (https://docs.dhtmlx.com/gantt/guides/performance/). Viewport culling of arrows is the industry-standard first move and is cheap here: DependencyArrows.tsx:110-121 already filters visibleDependencies; adding an x/y viewport test to that same useMemo is a handful of lines and needs no new architecture.

(e) Adopt Highcharts' API shape, not its algorithm. Highcharts Gantt is the only mainstream Gantt with a real pathfinder, and it exposes three named strategies — straight ("does not avoid other points"), simpleConnect (the Gantt default, "right angles only… will not avoid other points"), and fastAvoid ("will attempt to avoid other points, but its focus is performance over accuracy") — pluggable via Highcharts.Pathfinder.prototype.algorithms. https://api.highcharts.com/gantt/connectors.type That split is exactly right: cheap elbows by default, avoidance opt-in. Structure calculateArrowPath the same way — a routing: "elbow" | "gutter" parameter — so packed mode selects a strategy rather than adding branches inside the existing router, and list mode provably keeps today's path byte-for-byte.

(f) Reject: edge bundling. Hierarchical (Holten 2006, https://doi.org/10.1109/TVCG.2006.147) and force-directed (Holten & van Wijk 2009, https://doi.org/10.1111/j.1467-8659.2009.01450.x) bundling are built for node-link diagrams where edge identity matters less than aggregate flow. Here every edge carries semantics the user must read individually: type (FS/SS/FF/SF, encoded in which bar edges it touches) and lag (encoded in the gap). Bundling destroys both. It is also curve-based (d3.curveBundle, beta 0.85), fighting the orthogonal grid the whole chart is built on. d3 has no built-in bundling anyway — you assemble it from d3-hierarchy + d3-shape, which is a lot of new surface for a worse read.

(g) Reject: obstacle-avoiding A* / libavoid-style routing. This is available in JS today — libavoid-js is a WASM port of Adaptagrams' libavoid, whose three-stage pipeline (orthogonal visibility graph by line sweep → A* on length+bends → shared-path ordering and VPSC nudging) is the state of the art (Wybrow/Marriott/Stuckey, GD 2009, https://users.monash.edu/~mwybrow/papers/wybrow-gd-2009.pdf). Four disqualifiers for this product:

1. Licence. libavoid-js is LGPL-2.1+. OwnChart currently ships 10 runtime dependencies, all permissive. Adding a copyleft WASM blob to a privacy-first offline app is a decision far larger than Compact Mode #88.
2. Payload. A WASM module in an offline-first app that people install as a PWA.
3. Non-determinism across re-layouts. A VRT baseline that shifts a pixel when an unrelated task moves is a test suite you will end up deleting. Determinism is load-bearing here (§7, invariant I5).
4. Orthogonal-with-gutters already solves the great majority of it.

Revisit only if (a)–(d) measurably fail on real data. Bryntum's own experience is the tell: their equivalent (drawAroundParents) is still experimental and documented as slow.

Does auto-scheduling / cascade change?

No. Confirmed by reading the code. src/utils/graph/ contains topologicalSort.ts, dateAdjustment.ts, cycleDetection.ts, graphHelpers.ts, computeWorkingDaysRecalc.ts. Grepping these for rowIndex returns nothing; the only order hits are the word "order" in comments about topological order. Scheduling is a pure function of Dependency[] + task dates + working-day config. Packing is a pure view transform that changes no task field — it does not touch order, parent, startDate, or endDate.

Lag semantics are likewise untouched: Dependency.lag is always working days (epic #79 D1), computed from dates, never from geometry.

Make it a guarded invariant rather than a claim:

it("scheduling is invariant under row layout mode", () => {
  const listResult   = runCascade(tasks, deps, { rowLayoutMode: "list" });
  const packedResult = runCascade(tasks, deps, { rowLayoutMode: "packed" });
  expect(packedResult).toEqual(listResult);
});

The one place to watch is useTaskBarInteraction → executeDragMoveCommit/executeResizeCommit: those already work in date space (pixelsToDeltaDays on deltaX only, useTaskBarInteraction.ts:455). Vertical drag is not a scheduling input today and must not become one in packed mode — dragging a bar up or down must never be interpreted as a lane reassignment, because lanes are derived. Worth stating as an explicit non-goal so nobody "helpfully" adds it.

---

4. Export pipeline

What I found

The export path is: useExportDialog:243 calls prepareExportTasks(tasks, hiddenTaskIds, {workingDays}) → ExportRenderer renders offscreen React → PNG via html-to-image (captureChart.ts), SVG via DOM extraction + native-SVG table (svgExport.ts + taskTableRenderer.ts), PDF via the same SVG through svg2pdf.js (pdfExport.ts:785 buildCompleteSvg).

So there are two places row geometry is computed for export: ExportRenderer.tsx (the timeline SVG, shared by all three formats) and taskTableRenderer.ts (the native-SVG left table, used by SVG and PDF only — PNG gets the table from ExportRenderer's HTML).

Required changes

1. ExportRenderer.tsx — the same three edits as ChartCanvas:

   • :459 <GridLines taskCount={orderedTasks.length}> → laneCount
   • :472 <DependencyArrows tasks scale rowHeight> → add resolver
   • :481-483 orderedTasks.map((task, index) => <TaskBar rowIndex={index}>) → resolver.laneOf(task.id)
   • It has no store access (it renders offscreen), which is exactly why packRows/useRowLayout must take the task list as an argument rather than reading useTaskStore. If the hook were store-coupled, export parity would be impossible without duplicating the algorithm — the single worst outcome available.

2. exportLayout.ts:128 contentHeight = taskSize.count * taskSize.rowHeight → max(taskCount, laneCount) * rowHeight. TaskSizeInput gains laneCount.

3. pdfLayout.ts:410 flattenedTasks.length * densityConfig.rowHeight + contentHeaderHeight → same treatment. Miss this one and the PDF page-fitting math silently over-allocates height, producing a chart floating in whitespace with no error.

4. taskTableRenderer.ts:478 rowY = options.startY + rowIndex * rowHeight — leave it. The left table stays one row per task in both modes. What changes is the panel heights disagree: table = N·rowHeight, timeline = L·rowHeight, L ≤ N. Decide and document: top-align, total canvas height = max(N, L) · rowHeight. (Whether the exported table should even be included in packed mode is a UX call for C; the layout math must support both.)

5. ExportOptions needs rowLayoutMode. Without it the export silently uses whatever the chart is currently in, which breaks the perfectly reasonable "I work in packed but export the classic chart for the steering committee" workflow — and, worse, it is invisible. Add:

   • the field to src/utils/export/types.ts
   • a toggle in src/components/Export/SharedExportOptions.tsx
   • VALID_EXPORT_ROW_LAYOUT_MODES + enumOr(obj.rowLayoutMode, …, "list") in deserialize.ts's normalizeExportSettings (it is persisted in GanttFile.chart.exportSettings)
   • a line in DEFAULT_EXPORT_OPTIONS

The thing that will silently diverge (and already does)

ExportRenderer.tsx:264 and svgExport.ts:504 both call buildFlattenedTaskList(tasks, new Set<TaskId>()) — an empty collapsed set. Export ignores task.open === false entirely.

Today this is a mild, arguably-intentional divergence: collapsed summaries render expanded in the export, so you get extra rows. In packed mode it becomes structural: lane assignment is computed over the visible task set, so an export that includes N extra tasks produces a completely different lane layout. Not "same picture plus rows" — a different picture. Bars the user saw in lane 0 land in lane 3. Nobody will understand why.

Fix, and fix it in the place CLAUDE.md mandates. Collapse is a visibility filter, so it belongs in prepareExportTasks:

export interface PrepareExportTasksContext {
  workingDays?: { mode: boolean; config: WorkingDaysConfig; region?: string };
  /**
   * IDs of collapsed summary tasks. Their descendants are removed from the
   * export, matching what the screen shows. Same all-descendants contract as
   * `fullyResolvedHiddenTaskIds`: the caller resolves the hierarchy.
   */
  collapsedTaskIds?: ReadonlyArray<TaskId>;
}

This is the one prepareExportTasks change the feature requires — and note it is not about packing at all. Packing removes no tasks, so it is correctly not a prepareExportTasks concern. To keep the single-source-of-truth rule honest in spirit, add a @see src/utils/layout/packRows.ts note to its doc block saying that vertical placement is decided there while membership is decided here.

Second divergence risk, cheap to guard: add a test that computes lane count from the screen pipeline and from calculateExportDimensions on the same fixture and asserts equality. That single assertion catches every future "somebody added a filter on one side only".

---

5. Persistence & file format

New ViewSettings fields

// src/utils/fileOperations/types.ts — appended to ViewSettings
  /**
   * Vertical layout of the timeline panel.
   * "list"   — classic one row per task (default; behaviour of all files ≤ 1.7.9)
   * "packed" — non-overlapping tasks share a row
   * Named `rowLayoutMode`, NOT `compactMode`: `compact` already denotes the
   * 28px density preset in `densityConfig.ts` / `preferencesOptions.ts`.
   */
  rowLayoutMode?: RowLayoutMode;

  /** Tuning; only meaningful when rowLayoutMode === "packed". */
  rowLayoutOptions?: {
    /** Min gap in days between two bars sharing a lane. 0–365. Default 0. */
    minGapDays?: number;
    /** Prefer same-parent tasks in the same lane. Default false. */
    groupByParent?: boolean;
  };

On the key name: whatever the feature ends up being called, the persisted key should be rowLayoutMode. compactMode in a file next to a density: "compact" preference is a support nightmare and a permanent source of "why does compact mode not make it compact".

Migration: none

fileVersion stays 1.0.0. The migrations Map in migrate.ts:28 stays empty. Justification: the field is additive, optional, and changes the semantics of no existing field. schemaVersion also stays at 2 — that bump (#82) was for dependency-lag unit semantics; this changes no stored semantics.

The mechanism that makes migration unnecessary is applyViewSettingsDefaults in src/config/viewSettingsDefaults.ts. Add one line:

rowLayoutMode: loaded.rowLayoutMode ?? "list",
rowLayoutOptions: loaded.rowLayoutOptions ?? { minGapDays: 0, groupByParent: false },

Backward compatibility — both directions

Old file → new app: safe. Field absent → ?? "list" → pixel-identical to today.

New file → old app: safe to render, but it silently drops the field. Here is a real pre-existing hole worth naming:

• SerializedTask has __unknownFields round-trip preservation (serialize.ts:126-137).
• SerializedDependency has it too (serialize.ts:161-176).
• GanttFile has [key: string]: unknown (types.ts:64) with the comment "CRITICAL: Preserve unknown fields from future versions".
• ViewSettings has neither, and the loss happens on save, not on load. normalizeViewSettings does spread ...raw (deserialize.ts:490) so unknown keys survive parsing; applyViewSettingsDefaults (loadFromFile.ts:78) then enumerates fields explicitly and drops the rest. But the decisive step is that on save, useFileOperations.ts rebuilds ViewSettings from scratch out of the store (useViewSettings → useLayoutViewSettings:298 + useFeatureViewSettings:369). The store never held the unknown field, so it cannot be written back. An older app that opens a newer file and re-saves it silently erases rowLayoutMode.
• Practical consequence for implementation: adding a ViewSettings field requires an edit in useFileOperations.ts's useFeatureViewSettings too — easy to miss, and its own doc comment at :367 warns about exactly this.

Consequence for #88: user in v1.9 saves a packed chart, a colleague on v1.7 opens and saves it, the original user reopens it in list mode with no explanation. Low-severity in isolation; it is a class of bug that will recur with every future ViewSettings field.

Recommendation: close it in a separate small hardening PR (independent of #88 — it is a bug fix on its own merits): give ViewSettings a __unknownViewSettings?: Record<string, unknown> collected in applyViewSettingsDefaults and re-emitted by serializeToGanttFile, mirroring the task/dependency pattern already in the codebase. Ship it before #88 so rowLayoutMode is the first field that benefits.

Validation rules

In deserialize.ts normalizeViewSettings, following the file's existing "clamp, never reject" doctrine:

const VALID_ROW_LAYOUT_MODES = new Set<RowLayoutMode>(["list", "packed"]);

rowLayoutMode: enumOr<RowLayoutMode>(raw.rowLayoutMode, VALID_ROW_LAYOUT_MODES, "list"),
rowLayoutOptions: sanitizeRowLayoutOptions(raw.rowLayoutOptions),

function sanitizeRowLayoutOptions(raw: unknown) {
  if (!isPlainObject(raw)) return undefined;
  return {
    minGapDays: clampInt(raw.minGapDays, 0, 365, 0),   // NaN/Infinity/negative → 0
    groupByParent: optionalBoolean(raw.groupByParent),
  };
}

No new failure mode is introduced: a malformed value can never reject a file, only fall back to "list". Structure validation (validate.ts layer 3) needs no change — it only checks that chart.viewSettings exists and is an object.

Multi-tab

src/utils/multiTabStorage.ts ChartState (:48-77) — add rowLayoutMode?: RowLayoutMode and rowLayoutOptions?. Every field there is already optional-with-default, so old localStorage entries load unchanged and the storage version needs no bump.

src/hooks/useMultiTabPersistence.ts — two edits, matching the existing pattern exactly:

• restoreChartState (~:82-115): applyIfDefined(chartState.rowLayoutMode, store.setRowLayoutMode);
• the save block (~:170-196): rowLayoutMode: chartState.rowLayoutMode,

Note the per-tab consequence: two tabs can be in different modes on the same chart. That is correct and consistent with how zoom and hiddenColumns already behave.

Undo/redo

View-mode toggles are not undoable today (showWeekends, showDependencies, hiddenColumns are all outside historySlice). Keep rowLayoutMode consistent: not undoable. Say it in the help topic so it is a documented choice rather than an oversight.

---

6. Performance

The packing itself is a non-issue

Greedy sweep: sort by start date, then for each task assign the first lane whose last end ≤ this start − minGap (min-heap over lane end times, or a linear scan while laneCount is small). O(n log n). And it is not merely a heuristic — this is interval partitioning / interval-graph colouring, where the greedy left-to-right sweep is optimal: it uses exactly max simultaneous overlap lanes, which equals the chromatic number (https://ti.inf.ethz.ch/ew/lehre/CG10/lecture/ln3.pdf). That optimality is a property test, not a hope.

A correction to the brief's research pointers: Google, Outlook and Apple Calendar have published no overlap-packing algorithm — the "calendar packing" framing is textbook theory attributed to them after the fact. The genuinely documented open-source implementations are worth reading instead:

• react-big-calendar overlap.js — sort by start (end descending on ties), then a three-level containers → rows → leaves hierarchy, "Every event is always one of: container, row or leaf." https://github.com/jquense/react-big-calendar/blob/master/src/utils/layout-algorithms/overlap.js
• vis.js Timeline Stack.js — the greedy shift-down: for each item, loop over horizontally-colliding items and set item.top = otherItem.top + otherItem.height + margins.vertical. Worst case O(n²), mitigated by sorted arrays and a resumed index search. https://github.com/visjs/vis-timeline/blob/master/lib/timeline/Stack.js A useful counter-example: do not copy this shape. The heap-based sweep is both simpler and asymptotically better.
• FullCalendar exposes knobs rather than an algorithm — eventMaxStack ("for timeline view, the maximum number of events that stack top-to-bottom") is a good precedent for a future "max lanes, then overflow" affordance. https://fullcalendar.io/docs/eventMaxStack

n	packing	validate.ts MAX_TASKS = 10000 is the hard ceiling
500	well under 1 ms	fine
2 000	~1 ms	fine
10 000	~5–10 ms (sort-dominated)	fine as a memoized computation; never per frame

The actual bottleneck is elsewhere, and it is pre-existing

There is no virtualization anywhere in this codebase. Verified: no react-window, no react-virtual/TanStack Virtual, no hit for virtualiz* in src/ or package.json. ChartCanvas renders every TaskBar, GridLines renders taskCount + 1 <line> elements, DependencyArrows renders every arrow — always, regardless of viewport. At 2000 tasks that is already the dominant cost today, independent of #88.

Arrows are the worst offender, and OwnChart already pays the standard tax. DependencyArrow.tsx:120-155 renders two <path> elements per dependency — the visible one plus a stroke="transparent" hit area at HIT_AREA_STROKE_WIDTH = 14 — plus an arrowhead <polygon>, plus a third dashed overlay path when selected. So ≈3 SVG nodes per dependency, 4 when selected. This twin-path hitbox is universal prior art (Bryntum clickWidth, DHTMLX link_wrapper_width: 20, SVAR Gantt's 20px pointer-events: stroke polyline), and Bryntum's docs name the cost outright: "twice as many SVG lines will be drawn, which can affect performance with many visible dependencies." Their radius option (rounded joints — which OwnChart uses by default via getScaledCornerRadius) is likewise documented to "slightly degrade dependency rendering performance."

For calibration: a rough SVG ceiling is a few thousand individual marks per chart, and ApexCharts auto-promotes to canvas at 8 000 points (https://apexcharts.com/blog/svg-vs-canvas-charts/). At 2 000 tasks with 1 500 dependencies OwnChart is already emitting ~4 500 nodes for arrows alone. Real datapoint from Bryntum's tracker: 800 same-date events in a single row lagged badly with eventLayout: 'none' and was fixed by switching to stack (bryntum/support#9340) — i.e. packing helps, overlap hurts.

Packed mode is a net help: GridLines drops from N+1 to L+1 lines and SelectionRows from N rects to ≤ L. It does not reduce TaskBar count — that is bounded by task count, not lane count.

Do not bundle virtualization into #88. But RowResolver is precisely the seam that makes it possible later. Two implementation notes for whoever does it:

• The standard technique is a lazily-materialised prefix sum plus binary search. react-window's VariableSizeList keeps itemMetadataMap: {index → {offset, size}} with a lastMeasuredIndex watermark, and looks up via "exponential search with an inner binary search… overall complexity O(log n)" (https://github.com/bvaughn/react-window/blob/1.8.11/src/VariableSizeList.js). TanStack Virtual v3 has the nicer data structure — a flat Float64Array of [start₀, size₀, start₁, size₁, …] with a monomorphic binary search (https://github.com/TanStack/virtual/blob/main/packages/virtual-core/src/index.ts). Worth stealing that typed-array store. Notably, none of react-window, TanStack, virtua or react-virtuoso uses a Fenwick tree — do not over-engineer.
• Virtualizing an SVG scene specifically is essentially undocumented. The practical prior art is domain-specific culling, not generic windowing: Syncfusion renders dependency lines only for viewport-visible tasks, DHTMLX's smart_rendering culls tasks and links. Start there — cull arrows and bars by viewport inside the existing useMemos — before reaching for a virtualization library.

Designing taskAtPoint into RowResolver from the start (§1) is what keeps that door open.

Memoization boundaries

The subtle one: flattenedTasks identity changes on any task mutation (Immer produces a new array), so a naive useMemo(() => packRows(flattenedTasks, …), [flattenedTasks]) re-packs on every keystroke of an inline name edit and every colour change.

Key on a content key built from only the fields packing actually consumes:

// One pass, no allocations beyond the string. `hashUtils.ts` already exists in the repo.
const packKey = useMemo(
  () => flattenedTasks.map(f =>
        `${f.task.id}:${f.task.startDate}:${f.task.endDate}:${f.task.type ?? ""}`
      ).join("|"),
  [flattenedTasks]
);
const layout = useMemo(
  () => packRows(flattenedTasks, mode, opts, prevRef.current),
  [packKey, mode, opts]           // deliberately NOT flattenedTasks
);

Two wins at once: renaming a task never reflows lanes (perf), and renaming a task never visibly moves anything (UX — lanes must not jump while you type). RowLayout.revision then lets React.memo on TaskBar/DependencyArrows compare an integer instead of a Map.

Boundaries, top to bottom: useFlattenedTasks (existing, on tasks + hiddenTaskIds) → packKey (on flattenedTasks) → packRows (on packKey) → createRowResolver (on layout + rowHeight) → per-bar geometry useMemo in TaskBar (existing, :316-323).

The drag trap — and the good news

Does packing invalidate every drag frame? No — verified in the code. useTaskBarInteraction holds the preview in local component state (dragState.currentPreviewStart/currentPreviewEnd, :490-512), throttled through requestAnimationFrame, and only calls updateTask in executeDragMoveCommit / executeResizeCommit on mouseup (:252, :364, :555-565). The store's tasks array does not change during a gesture. Therefore flattenedTasks does not change, therefore packKey does not change, therefore packing does not run per frame. The architecture already protects us.

But that is exactly what creates the worse problem: the mouseup lane snap.

During the drag the bar moves horizontally in its current lane. On release, dates commit, packKey changes, lanes reflow — and the bar teleports to a different y, possibly several lanes away, possibly off-screen. Other, untouched bars move too. Discontinuous, unexplained, and it will feel broken.

Recommendation — freeze, then animate:

1. On drag start, snapshot the current RowLayout and pin it for the gesture (chartSlice.dragState already exists at :139 and :1183; add a frozenLayout alongside deltaDays/sourceTaskId).
2. During the gesture the dragged bar moves in x only; every lane stays put.
3. On commit, recompute and transition y for every bar whose lane changed over ~150 ms. Users must see where things went — an instant jump destroys the mental map, an animated one rebuilds it.
4. If the dragged bar's new lane is outside the viewport, scroll it into view (useScrollToDate / scrollTargetDate machinery already exists).

Rejected alternative: live re-packing per frame with the dragged bar excluded and re-inserted. It makes y a function of x mid-gesture, so the bar climbs and drops under a horizontally-moving cursor, and every other bar thrashes. Also reintroduces the per-frame cost we currently get for free.

Prior art backs the freeze: Bryntum's dependency feature ships drawOnScroll: false and drawOnEventInteraction: false — skip redraws during the gesture, redraw on settle — and buffers refresh by 10 ms by default (immediateRefresh). https://bryntum.com/products/gantt/docs-llm/api/Scheduler/feature/Dependencies.md Same principle: quiesce during interaction, reconcile after.

Lane stability across ordinary edits

Greedy first-fit is not stable: inserting one early task can cascade every subsequent assignment. Fix with a hint — if a task still fits its previous lane, keep it there, otherwise first-fit. Costs one Map lookup per task, preserves optimality in the common case (and where it does not, prefer stability; the user's mental map is worth more than one saved lane). This is why packRows takes previous?: RowLayout.

Other interactions

• useInfiniteScroll is horizontal only — verified, it works on scrollLeft and extends the date range. Packed mode changes only vertical extent. No interaction.
• scrollTop restore is in pixels (ViewSettings.scrollTop, chartSlice.pendingScrollTop). A pixel offset means something different in each mode. On mode switch, keep the selected task (or the topmost visible task) in view rather than the pixel offset.

---

7. Test strategy

Martin's stated preference — E2E over unit tests for user-facing behaviour — maps cleanly here: the packing core is not user-facing behaviour, it is a pure function, so it gets heavy unit coverage; everything a user can see or do goes to Playwright.

Unit (Vitest) — the pure core, target 100% not 80%

Packing is beautifully unit-testable. packRows / packIntervals invariants:

#	Invariant
I1	No overlap. No two placements in the same lane have overlapping [start, end) spans (+ minGapDays).
I2	Optimality. laneCount === max simultaneous overlap depth.
I3	Identity. mode === "list" ⇒ lane === listIndex for every task.
I4	Totality. Every input task appears exactly once across all lanes.
I5	Determinism. Same input ⇒ byte-identical output. (VRT depends on this.)
I6	Stability. Re-packing after a non-date edit yields an identical layout.
I7	Order preservation. Within a lane, slot is monotonic in start date, ties broken by order.

I1/I2/I4 are ideal property-based tests. The repo has no fast-check dependency, and dependencies here are deliberately lean (10 runtime deps). Two options:

• Recommended: a ~30-line seeded LCG generator in tests/unit/helpers/randomTasks.ts producing random task sets with a fixed seed. Deterministic, reproducible in CI, zero new deps, and prints the seed on failure.
• Alternative: add fast-check as a devDependency. Better shrinking, more idiomatic. Martin's call — it is dev-only, so the privacy argument does not apply, only the dependency-surface one.

Edge cases: milestones (zero-width — must still consume a slot, otherwise two milestones on the same day stack invisibly), summary tasks (see open questions), zero-duration tasks, identical start+end across many tasks, a single task, zero tasks, all tasks hidden, and a 10 000-task perf smoke asserting < 20 ms.

Also unit:

• createRowResolver — laneOf/yOf/taskAtPoint, including taskAtPoint returning the correct task when a lane holds several.
• Arrow channel assignment — same I1/I2/I4 invariants on x-spans (free, it is the same packIntervals).
• Scheduling invariance (§3) — cascade output identical in both modes.
• normalizeViewSettings: rowLayoutMode invalid enum → "list"; minGapDays of NaN / -1 / 1e9 → clamped; rowLayoutOptions non-object → undefined.
• applyViewSettingsDefaults round-trip: absent → "list"; present → preserved.
• exportLayout / pdfLayout height math with laneCount < taskCount.

Integration (Vitest + RTL)

• ChartCanvas with a stub resolver renders bars at the expected y attributes.
• GridLines receives laneCount, not taskCount.
• Mode toggle in chartSlice propagates to a re-render.

E2E (Playwright) — where user-facing behaviour lives

Following the existing tests/e2e/ conventions (40 spec files today):

1. Toggle to packed from the View ribbon → chart height shrinks, bar count unchanged.
2. Create a task while in packed mode → it appears and receives a lane. (The author's problem Undo/Redo not working for Indent/Outdent operations #1 — this is the flow most likely to be quietly broken.)
3. Select a bar in packed mode → correct bar highlights and the correct table row highlights.
4. Marquee-select across a lane → selects the bars actually inside the rectangle.
5. Right-click a bar in a shared lane → context menu targets the bar under the cursor, not the first task in the lane. (Direct regression test for useTimelineAreaContextMenu.ts:84-87.)
6. Drag a bar past another in the same lane → on drop, lanes reflow, the bar stays selected and visible.
7. Undo after a packed-mode drag → dates and lane restored.
8. A dependency arrow still connects the right two bars after a reflow.
9. Save → reload → mode persists (.ownchart round-trip).
10. Open a pre-feature fixture from tests/e2e/fixtures/ → opens in list mode.
11. Export PNG / SVG / PDF in packed mode → file downloads, dimensions match packed height. (Pattern exists in export-png.spec.ts / export-svg.spec.ts / export-pdf.spec.ts.)
12. Multi-tab: packed in tab A, open tab B → independent per-tab state.
13. Keyboard: arrow-key cell navigation and all shortcuts still work in packed mode (the parity constraint, tested).

VRT — Docker only

There are 9 committed baselines today in tests/e2e/visual-regression.spec.ts-snapshots/. This feature implies:

Baseline	Action
ribbon-view-tab-chromium-linux.png	UPDATE — the View tab gains the mode control
packed-mode-chart-chromium-linux.png	NEW
packed-mode-dense-overlap-chromium-linux.png	NEW — many bars per lane + arrows; the one that will actually catch routing regressions
packed-mode-with-dependencies-chromium-linux.png	NEW (optional)

So +2 to +3 new, 1 updated. All must be generated inside Docker via npm run test:vrt:update (CI runs Linux; locally-taken screenshots will not match), then verified deterministic by re-running npm run test:vrt, then committed. This is also why packing determinism (I5) and lane stability (I6) are load-bearing, not nice-to-have — a non-deterministic packer produces a flaky baseline that someone will eventually delete.

Phase-0 gate: the resolver refactor must produce ZERO baseline changes. If npm run test:vrt demands even one update after Phase 0, the "list is the identity case" claim is false and the refactor is wrong. That is a pixel-exact proof of no-behaviour-change and it is free.

---

8. Rollout

Phase 0 — Resolver refactor, zero user-visible change · refactor:

Introduce packRows + RowResolver supporting only mode: "list". Rewire ChartCanvas, GridLines, TaskBar, DependencyArrows, useTimelineAreaContextMenu, layoutCalculations, ExportRenderer, exportLayout, pdfLayout.

Acceptance: npm run ci:local green · npm run test:vrt passes with zero baseline updates · all ~190 E2E pass untouched.
Value: de-risks everything after it, ships and releases on its own, and bisects cleanly if anything regresses. A refactor: commit means no version bump.

Phase 1 — Packed timeline behind a flag · smallest shippable slice

rowLayoutMode in chartSlice + a View-tab toggle, gated. Table stays one-row-per-task; the two panels top-align with different heights. Arrows get focus-mode dimming only (§3d) — the cheapest large legibility win. No table redesign, no in-lane creation, no channel routing.

Value: the author can see screenshot #2 in the real product and react. Everything downstream is cheaper once there is something concrete to argue about. Deliberately deferred: table redesign, creation affordances, channel routing, export parity, persistence.

Phase 2 — Interaction parity

Selection, marquee, context menu (taskAtPoint), keyboard nav in packed mode. Frozen lanes during drag + animated reflow on commit (§6). Lane-stability hint.

Phase 3 — Arrow routing

Lane gutter, packIntervals-based channel assignment, length-based degradation with chevron stubs.

Phase 4 — Export + persistence + docs

ExportOptions.rowLayoutMode + the collapsedTaskIds fix in prepareExportTasks (§4). ViewSettings.rowLayoutMode + applyViewSettingsDefaults + normalizeViewSettings + multi-tab. New HelpTopic in src/config/helpContent.ts (project rule). Manual PNG/PDF/SVG verification (project rule).

Phase 5 — Table-side redesign & creation affordances

A/B/C's territory. Depends on the naming and UX answers, not on architecture.

Feature flag

There is no feature-flag infrastructure in this repo (src/config/ has no featureFlags.ts). Do not build one. The lightest thing that works:

// src/config/appConfig.ts — one added constant, no framework
export const ROW_LAYOUT_FLAG_KEY = "ownchart:ff:rowLayout";
export const isRowLayoutEnabled = (): boolean =>
  import.meta.env.DEV || localStorage.getItem(ROW_LAYOUT_FLAG_KEY) === "1";

Gate only the Ribbon control's visibility. chartSlice always carries the field, persistence always writes it, and packRows always exists — so a flagged-off build still round-trips a packed file without data loss (it just renders it as a list). Remove the flag at the end of Phase 4. This deliberately avoids prepareExportTasks-style branching on the flag, which would be exactly the "silent divergence" trap this whole concept is trying to avoid.

---

Pipeline

flowchart TD
  subgraph Store["Zustand store"]
    T["taskSlice.tasks"]
    H["chartSlice.hiddenTaskIds"]
    M["chartSlice.rowLayoutMode<br/>+ rowLayoutOptions"]
    D["dependencySlice.dependencies"]
    S["chartSlice.scale (zoom, dateRange)"]
  end

  T --> F1
  subgraph Pipe["useFlattenedTasks — existing"]
    F1["Stage 1 buildFlattenedTaskList(tasks, collapsedIds)<br/>→ allFlattenedTasks + globalRowNumber"]
    F2["Stage 2 filter(hiddenTaskIds)<br/>→ flattenedTasks (row-number gaps)"]
    F1 --> F2
  end
  H --> F2

  F2 --> KEY["packKey = id:start:end:type per task<br/>(memo boundary — name/colour edits do NOT reflow)"]
  KEY --> PACK
  M --> PACK
  PREV["previous RowLayout (useRef)<br/>lane-stability hint"] --> PACK

  subgraph New["NEW — src/utils/layout/packRows.ts (pure)"]
    PACK["packRows(flattened, mode, opts, previous)"]
    PI["packIntervals&lt;T&gt; — shared primitive"]
    PACK --> PI
    PACK --> RL["RowLayout { byTaskId, lanes, laneCount, revision }"]
    RL --> RES["createRowResolver(layout, rowHeight)<br/>laneOf · yOf · taskAtPoint · laneCount"]
  end

  RES --> SCREEN
  RES --> EXPORT
  D --> CH["arrow channel assignment<br/>(same packIntervals, x-spans)"]
  CH --> SCREEN
  CH --> EXPORT

  subgraph SCREEN["Screen — GanttLayout"]
    GL["GanttLayout → TimelinePanel → ChartCanvas"]
    GLI["GridLines taskCount = laneCount"]
    SR["SelectionRows y = resolver.yOf(id)"]
    TB["TaskBar lane = resolver.laneOf(id)"]
    DA["DependencyArrows resolver + channels"]
    GL --> GLI & SR & TB & DA
    TT["TaskTable — 1 row per task, UNCHANGED"]
    GL --> TT
  end

  subgraph EXPORT["Export — offscreen, same resolver"]
    PET["prepareExportTasks(tasks, hidden, {workingDays, collapsedTaskIds})<br/>MEMBERSHIP only"]
    ER["ExportRenderer (offscreen React)"]
    PET --> ER
    ER --> PNG["PNG · html-to-image"]
    ER --> SVGX["SVG · svgExport + taskTableRenderer"]
    SVGX --> PDF["PDF · svg2pdf.js"]
    EL["exportLayout / pdfLayout<br/>height = max(taskCount, laneCount) × rowHeight"]
    EL --> ER
  end

  S --> GL
  S --> ER

  subgraph PERSIST["Persistence"]
    VS["ViewSettings.rowLayoutMode<br/>additive · optional · NO migration"]
    MT["multiTabStorage.ChartState.rowLayoutMode"]
  end
  M --> VS
  M --> MT

  GT["utils/graph — topologicalSort · dateAdjustment · cycleDetection<br/>INDEX-FREE · UNAFFECTED by packing"]
  D --> GT
  T --> GT

  style New fill:#dbeafe,stroke:#2563eb
  style PACK fill:#bfdbfe,stroke:#2563eb
  style RES fill:#bfdbfe,stroke:#2563eb
  style GT fill:#dcfce7,stroke:#16a34a
  style KEY fill:#fef3c7,stroke:#d97706
  style PET fill:#fef3c7,stroke:#d97706

Loading

---

Open questions I could not resolve from the code

1. Do summary tasks participate in packing? A summary spans all its children, so it overlaps every one of them and will always claim a lane of its own — which defeats the compression precisely where hierarchy is deepest. Three candidate answers: (a) exclude summaries from packed mode entirely, (b) give summaries a dedicated top band above the packed lanes, (c) pack children inside the summary's band. This materially changes packRows's contract and I would rather A/B/C decide it than guess. It also interacts with the author's own observation that a fully-overlapping single line "is basically what the summary feature already does".
2. What happens vertically when the table has N rows and the timeline has L lanes? I have specified the layout math (max(N, L) · rowHeight, top-aligned) so the architecture supports any answer, but which panel scrolls, and whether the table is even shown, is a UX decision.
3. The focus-mode arrow threshold (~150) is a guess. Resolve by profiling a real dense project rather than by argument.
4. fast-check vs. a hand-rolled seeded generator for the property tests — a dependency-surface preference, Martin's call.

---

Agent: Concept D — Architecture, Dependencies, Export, Persistence & Test Strategy

[kitikonti]

Concept B — Left Panel / Table Redesign

Phase 1 of the #88 concept effort. Scope: what happens to the left task table when the
timeline packs N tasks onto L < N shared rows, so 1:1 vertical alignment becomes
mathematically impossible.

TL;DR recommendation: keep the table exactly as it is — one row per task, all columns, all
cell editing — and decouple it from lane geometry, replacing positional alignment with
bidirectional cross-highlighting plus a reveal action. Add a Task Inspector panel
(additive, available in both modes) as the second editing surface, and a bar-anchored quick
edit as the third. Do not collapse the table to lane rows, do not replace it with an
inspector, do not hide it by default.

The decisive argument is not aesthetic, it is diff size and parity: with this option
almost nothing in src/components/TaskList/ changes, so feature parity in the new mode is
true by construction rather than by re-implementation. Every other option requires
re-building the spreadsheet's capabilities somewhere else.

---

0. Three corrections to the shared brief (read these first)

Grounding first, because later phases will cite these.

1. The two panes are not two vertically synced scroll containers. There is exactly one
   vertical scroll driver. src/components/Layout/GanttLayout.tsx renders
   outerScrollRef (overflow-y-auto, data-scroll-driver) sized to totalContentHeight,
   and its scroll handler writes transform: translateY(-scrollTop) directly onto both
   taskTableTranslateRef and chartTranslateRef. The table pane itself is overflowY: "clip".
   useSyncScroll is used only horizontally (chart ↔ timeline header, table ↔ table header).
   So "vertical scroll sync" = one scrollbar + two panes translated by the same delta.
   That is much better news than the brief implies — see §5.

2. SelectionHighlight.tsx is not the row-selection component. It is the date-range
   selection band (a vertical <rect> spanning height, used by both TimelineHeader and
   ChartCanvas). The row-band selection with the prev/next-sibling border-merge logic is the
   inline SelectionRows sub-component inside ChartCanvas.tsx (≈ lines 142–200):
   const y = index * rowHeight; with prevSelected / nextSelected merge. Its table-side
   twin is src/components/TaskList/RowOverlays.tsx (selectionPosition.isFirstSelected /
   isLastSelected). Two different files, two different fixes.

3. The SVG chart has essentially no accessibility surface today. A grep for role= /
   aria-label across src/components/GanttChart/*.tsx returns exactly two hits:
   DependencyPropertiesPanel (role="dialog") and DependencyArrow
   (role="graphics-symbol"). TaskBar.tsx has no role and no aria-label.
   Meanwhile TaskTable is role="grid" aria-label="Task spreadsheet", rows are role="row"
   with aria-selected and aria-rowindex. The task table is currently the only
   screen-reader-navigable representation of the task set. Any option that hides or replaces
   it is an accessibility regression, not a display preference. This single fact eliminates
   options (b), (c)-as-replacement and (d)-as-default on its own.

---

1. The design options, honestly

First, name what the 1:1 alignment actually buys, because "alignment" is four jobs, not one:

Job the alignment does today	Lost when packing?
J1 — identity: "this row is that bar"	yes
J2 — locate a bar when you know the task	yes
J3 — identify a task when you see its bar	yes
J4 — read a task's attributes (dates, %, colour) beside its bar	yes

Any option must answer all four, not just J1.

(a) One row per task, alignment simply abandoned

The table stays byte-identical; the panes just stop lining up. Everything keeps working —
cells, editors, navigation, marquee, DnD reorder, column config, the placeholder row.

What actually breaks:

• Scroll: translateY(-scrollTop) applied to both panes with totalContentHeight derived
  from taskCount * rowHeight (src/utils/layoutCalculations.ts). In packed mode the chart is
  ~3 lanes tall but would still be translated by up to N * rowHeight, i.e. it would scroll
  clean off the top of the viewport while the list is still on row 4. This is a real bug, not
  a cosmetic one, and it is the only genuinely broken piece.
• Selection continuity: SelectionRows merges borders across adjacent selected rows.
  In packed mode "adjacent" is meaningless — two selected tasks in the same lane are
  horizontally adjacent, not vertically.
• The belonging affordance (J1–J4): gone, with nothing in its place.

Verdict: (a) is not a design, it is (e) with the compensation removed. (e) strictly dominates it.

(b) One row per lane, each row summarising the packed tasks

Reject, firmly. A lane is not a semantic object. It is a bin index produced by an
interval-packing pass over derived state (Task in src/types/chart.types.ts has no
lane/track/row field — Concept A's packing output is ephemeral). Consequences:

• A lane row cannot be edited. There is no lane name, no lane start date, no lane progress.
  "Summary of tasks packed into it" would read Lane 2 — 4 tasks, 12 Mar – 30 Jun and would be
  useless for every CRUD operation the author lists.
• Lane membership reshuffles on every date edit. Drag one bar three days right and half the
  tasks change lane. A left panel whose rows renumber themselves when you touch an unrelated
  task is actively hostile.
• Where do you type a task name? Nowhere. This option makes the author's headline complaint
  permanent.

(b′) — the salvageable variant. If the lanes are semantic rather than packed —
group-by summary parent, or a future group-by-owner — then a left "group header row" is
correct and standard. But that is a different feature (grouping/swimlanes), not the answer
to "pack non-overlapping bars onto shared rows". Keep it on the roadmap; do not conflate it
with #88. It composes cleanly with the recommendation below: group bands on the outside,
packing inside each band.

(c) Inspector replaces the table (master/detail)

As a replacement, reject:

• Loses bulk/spreadsheet editing, useMarqueeSelection, multi-row DnD reorder, tab-through
  cell entry, copy/paste of cell ranges, and — importantly — the entire column system
  (hiddenColumns, columnWidths, ColumnResizer, useAutoColumnWidth,
  useTableDimensions, SplitPane maxLeftWidth). All of it becomes dead code in one mode and
  live in the other, which is exactly the "either/or silo" the author forbids.
• Loses the a11y surface (§0.3).

As an addition, adopt — see §3. An inspector is genuinely the right answer to "how do I
edit when I can't see a row", and OwnChart already ships the pattern: DependencyPropertiesPanel
is a portal-rendered, viewport-clamped, scroll-anchored properties panel that appears when you
select a dependency arrow. A TaskInspectorPanel is that component's sibling.

(d) Hide the table; edit in popovers on the bars

Reject as the mode's default; keep as a user choice, because it already exists.
chartSlice.isTaskTableCollapsed + setTaskTableCollapsed are already wired through
SplitPane (snap-to-collapse below an 80 px COLLAPSE_THRESHOLD) and exposed in the View
ribbon tab via useViewTabActions.toggleTaskTableCollapsed. So "no table" is already a
supported state today in classic mode. Making it the forced state in packed mode would
be a regression (§0.3) and would strand discoverability: a first-time user opening the new
mode would see no way to create or name a task.

(e) Decoupled list + cross-highlighting — recommended

The left panel keeps one row per task, in flattened hierarchy order, with the full column
set and the full editing model. It stops pretending its y-coordinates mean anything about the
chart, and instead binds to the chart by identity (highlight, focus, reveal) rather than by
position.

Everything in the brief's "hooks that assume one row per task" list — useCellNavigation,
useCellEdit, useNewTaskCreation, usePlaceholderNameEdit, useTableDimensions,
useHideOperations, useTaskRowData, useRowSelectionHandler — continues to be true,
because the list still has one row per task. They only assumed the table has one row per
task; they never depended on the chart.

Decision matrix

Scored 1–5, 5 = best. "Cost" is inverted (5 = cheapest to build).

	Feature parity	Cost (5 = cheap)	Discoverability	Accessibility	Extends ≠ replaces	Total
(a) unaligned table, no compensation	5	5	2	4	4	20
(b) one row per packed lane	1	2	3	2	1	9
(b′) semantic group rows (different feature)	3	2	4	3	3	15
(c) inspector replaces table	2	3	3	4	1	13
(d) table hidden, popover-only editing	1	4	1	1	2	9
(e) decoupled list + cross-highlight	5	4	4	5	5	23
(e) + (c) additive + (d) optional — RECOMMENDED	5	3	5	5	5	23

Rationale for the two cells most likely to be argued:

• (e) parity = 5 because parity is inherited, not rebuilt. Zero features are re-implemented.
• (e) cost = 4 because the diff is dominated by one scroll-math change and one new
  overlay; see §6. Adding (c) drops it to 3 — that is the price of a genuinely better answer
  to the author's "I can't type the name" problem, and it pays for itself because the
  Inspector improves classic mode too.

---

1B. Prior art — what other products actually do with the left panel

Two clean families emerge, and they answer different questions.

Family 1 — "the left row is a container, not a task." Every tool that puts many bars on one
row makes that row a semantic owner (a resource, a person, a group), never a packing bin.

• Bryntum Scheduler — the left side is a full Grid of resources with ordinary
  configurable columns; each resource row holds many event bars, and an eventLayout config
  (values including stack / pack / none) decides how overlapping events share the row,
  with the resource row growing to fit under stack.
  https://bryntum.com/products/scheduler/docs/ · https://bryntum.com/products/scheduler/examples/
  (Docs are client-rendered and I could not fetch the exact config page in this pass — treat
  the enum values as indicative and verify before citing them in an implementation plan.)
  Borrow: row-grows-to-fit as the graceful-degradation story when packing cannot find a
  lane. Reject: treating the left row as the editing surface for individual events —
  Bryntum edits events in an event editor popup, not in the resource grid. That is exactly
  the master/detail split, and it corroborates §3's tiering.
• DHTMLX Scheduler, Timeline view (verified against the docs) — the y-axis rows are
  defined by y_unit (an array of {key, label} section objects) and y_property (the data
  field that assigns an event to a section). render: "bar" draws events as horizontal bars
  and one section row holds many events, stacking vertically within the row; render: "tree"
  adds multi-level folder grouping. Row height is dy per view with an optional per-section
  height override, and event_dy sizes the events inside it.
  http://docs.dhtmlx.com/scheduler/views/timeline/
  Same lesson: rows are sections, not tasks; per-event editing happens in the lightbox.
  Borrow: the explicit dy (row) vs event_dy (bar) separation — OwnChart's
  densityConfig already has exactly this pair (rowHeight vs taskBarHeight +
  taskBarOffset), so lane height can reuse the existing token structure unchanged.
• vis.js Timeline (verified against the docs) — groups supply the left-panel rows; each
  group row contains only a content label (text/HTML), never an editable record. With
  stack: true (the default) items are stacked so they do not overlap, and the group row
  expands vertically to fit them. groupHeightMode selects 'auto' (label + visible items),
  'fitItems', or 'fixed'. https://visjs.github.io/vis-timeline/docs/timeline/
  This is the cleanest reference implementation of "left label + N packed items", and it makes
  the point sharply: the left row degenerates to a label the moment it stops being 1:1.
  If OwnChart chose option (b), that is what the task table would become. Borrow:
  groupHeightMode as the shape of the eventual setting if lane heights ever need to vary;
  reject 'fixed' as a default because a clipped lane hides tasks.
• Microsoft Project — Team Planner — one row per resource, many task bars per row,
  unassigned tasks in a separate bottom pane. There is no per-task grid row in this view at all;
  you switch to Gantt Chart view or open Task Information to edit fields.
  https://support.microsoft.com/en-us/office/add-tasks-to-your-project-1f0bcd67-8fdd-4b04-adfc-6d92b74d0ac2
  The closest analogue to Compact Mode #88, and it is a cautionary tale: Team Planner is a separate
  view, not an extension of the Gantt — exactly the "either/or silo" the author forbids.

Conclusion from Family 1: every product that packs bars onto shared rows does so around a
semantic grouping key, and none of them tries to make the packed row an editable per-task
row. That is direct empirical support for rejecting option (b), and for §1's (b′) note that
group-by swimlanes are a different, complementary feature.

Family 2 — "keep one row per item; edit in a detail surface." The mainstream roadmap tools
overwhelmingly keep 1:1 rows and add a detail panel.

• Notion Timeline (verified against the docs) — the left "table" half is a toggleable
  pane: "to show or hide table in any timeline, click the >> or << on the left". Which
  properties appear as columns is controlled by Property visibility (eye icon) with drag
  handles for order, and columns can be reordered by dragging. Each table row represents one
  item, staying aligned with the timeline bars. https://www.notion.com/help/timelines
  Borrow three things directly: (1) the collapse control as a visible, first-class,
  always-present affordance — OwnChart already has the state (isTaskTableCollapsed,
  COLLAPSE_THRESHOLD) and the ribbon action, but the >>/<< chevron on the divider is a
  better discoverability story than snap-drag alone; (2) per-column visibility as the column
  model — OwnChart's hideable + hiddenColumns is already the same design, which is one more
  reason not to touch it (§4); (3) the fact that Notion keeps 1:1 rows even though it owns
  both halves of the layout and could have done otherwise.
• Jira Plans / timeline — the left is a hierarchical scope tree; grouping (by team, sprint,
  assignee, …) inserts group header rows, and the bars still line up 1:1 beneath them.
  Detail opens in a side panel. https://support.atlassian.com/jira-software-cloud/docs/
• Linear — list on the left, detail in a slide-over/right pane, keyboard-first editing.
  https://linear.app/docs
• Asana Timeline, Monday timeline, Smartsheet Gantt, Airtable Timeline — all
  keep a left list/grid and open a record/row detail panel for editing. Smartsheet is the
  closest to OwnChart in spirit (spreadsheet grid + Gantt, resizable split) and it never
  breaks the 1:1 row mapping.

Conclusion from Family 2: nobody ships a packed timeline whose left panel is also the
per-item editor. They either keep 1:1 rows (Family 2) or make the left panel a container label
plus a detail surface (Family 1). Option (e) + Inspector is the intersection of both
families — 1:1 rows and a detail surface — which is why it can honour "all features in both
modes" where the pure forms cannot.

Pattern guidance. The Inspector is a supporting pane, not a list-detail master pane, and
the distinction matters for layout. Material 3 / Android canonical layouts define list-detail
as "list drives detail, list has fixed width, detail is flexible" and supporting pane as
"primary content ~70 %, supporting content ~30 %, secondary content is meaningful only in
relation to the primary". OwnChart's primary content is the timeline; the Inspector is
supporting content. https://developer.android.com/develop/ui/views/layout/canonical-layouts
· https://m3.material.io/foundations/adaptive-design/canonical-layouts
Practical consequence: below a width threshold the Inspector should become an overlay/sheet
rather than steal width from the timeline — the same rule Android applies at the medium
window-size class.

Calendars are the wrong model to copy wholesale. Google/Outlook day view packs overlapping
events into columns with no left item list at all, and edits via a quick popover that
escalates to a full editor. The popover→full-editor escalation is worth borrowing (it is
exactly §3's Tier 3 → Tier 2). The "no list at all" part is not: a calendar's items are
homogeneous and time-addressable, whereas a project plan's tasks are ordered, hierarchical and
named — the list is the plan.

---

2. The alignment substitute

Recommendation, in priority order:

Primary — bidirectional cross-highlighting (brushing & linking). This is the standard
solution in coordinated-multiple-views information visualisation: brush in one view, linked
items highlight in every other view. Three states, deliberately distinct:

State	List row	Bar in chart
hover (either side)	1 px inner outline + slate-50 wash, no layout shift	2 px outline in brand-600, +2 % lightness on fill
selected	existing RowOverlays band (unchanged)	per-bar brand-600 ring, 2 px, radius matched to bar
active cell	existing active-cell box (unchanged)	subtle 1 px dashed ring — signals "keyboard focus is here"

Hover must be driven by a shared, cheap store field (hoveredTaskId in chartSlice) and
applied via data-task-id attributes and a CSS attribute selector so that a hover does not
re-render 500 memoised TaskTableRows. This matters: TaskTableRow is React.memo'd
precisely to avoid that, and a naive isHovered prop would defeat it.

Secondary — colour as the persistent shared key. The colour swatch column already renders
the same computed colour (useComputedTaskColor) that fills the bar. In packed mode that
becomes the always-on, no-interaction-required binding cue, so promote it: in packed mode the
colour column should not be hideable, and bars should always carry their colour even under
colorMode schemes that would otherwise flatten them.

Tertiary — a single transient leader line, optional and off by default. Griffin & Robinson
(IEEE TVCG 21(3), 2015, "Comparing Color and Leader Line Highlighting Strategies in Coordinated
View Geovisualizations", https://doi.org/10.1109/TVCG.2014.2371858) found with eye-tracking
that participants extracted information as efficiently from leader-line linking as from
colour highlighting — and specifically recommend leader lines when colour is already carrying a
data attribute. OwnChart is exactly that case: colour is a data channel (color,
colorOverride, colorMode). So a leader line is evidence-supported here.

But ship it second, and constrain it hard:

• exactly one line at a time (the hovered or singly-selected task), never N;
• drawn in a portal overlay above the SplitPane divider, since the two panes have independent
  horizontal scroll and clipping — a line inside either pane would be cut off;
• suppressed entirely when the table is collapsed, when > 1 task is selected, or when the row
  is scrolled out of view;
• it must not be confusable with a dependency arrow. Dependency arrows are already the
  established line vocabulary in the chart. Use a different treatment (thin, dotted, slate-400,
  no arrowhead) or drop the feature. If in doubt, drop it — cross-highlighting alone is
  sufficient; this is the one piece I'd cut first under time pressure.

Reject: persistent connector lines for all tasks. N lines fanning across the divider is
spaghetti at N > 8, and it collides visually with dependency arrows.

Reject: lane-index colour coding of table rows. It would fight the task-colour channel, and
lane indices churn on every edit (see §1b).

Add — reveal, the answer to J2/J3. Highlighting only works for what is on screen.

• Click a row (or Ctrl/Cmd+Shift+L, "locate") → chart scrolls horizontally to bring the bar
  into view and the bar pulses once. useScrollToDate already exists and does exactly this
  for newly created tasks; reuse it.
• Click a bar → the list scrolls that row into view (scrollIntoView({ block: "nearest" }))
  and the row takes the selection band.
• Both are the same code path in both modes, so classic mode gains "locate" for free — a small
  but real win that helps justify the work.

---

3. Editing task properties without a row

The premise in the issue — "I can't type the task name in this view in the task table, because
there is no task table" — is dissolved rather than answered by the recommendation: in
packed mode there is still a task table, with a row for every task, and you type the name
into it exactly as today. That is the point of choosing (e).

What we add is a second and third surface so that the workflow also works when the table is
collapsed (option (d) as a user choice) or when the user's attention is on the chart.

Tier 1 — the list (unchanged). Primary surface. Full spreadsheet editing.

Tier 2 — Task Inspector (new, available in both modes). A docked/floating properties
panel for the current selection. Built on the existing DependencyPropertiesPanel pattern:
createPortal, role="dialog", viewport-edge clamping (VIEWPORT_EDGE_MARGIN_PX),
re-anchoring on scroll of [data-scroll-driver] and .gantt-chart-scroll-container,
Z_INDEX from design tokens, and the existing FieldLabel / SegmentedControl / Button
primitives. Contents: name, type (SegmentedControl: Task / Summary / Milestone, reusing
getNextTaskType semantics), start, end, duration, progress, colour (reusing
CellEditors/ColorPickerPopover verbatim), and dependency list. Multi-select: shared values
shown, mixed values shown as —, editing applies to all selected — this is genuinely new
capability that classic mode does not have today.

Tier 3 — bar-anchored quick edit. Double-click a bar → an input overlays the bar rect and
you type the name in place, Enter commits, Esc cancels. Right-click → the existing
useTimelineBarContextMenu. Drag/resize/progress-drag unchanged
(useTaskBarInteraction, useProgressDrag).

Task creation (the author's first listed problem) has three paths, all live in both modes:

1. NewTaskPlaceholderRow at the bottom of the list — unchanged, still the primary path.
   This alone answers "task creation is lost": it isn't, because the list isn't.
2. Existing insert affordances: RowNumberCell hover InsertRowButton → insertTaskAbove /
   insertTaskBelow, and useNewTaskCreation keyboard paths.
3. New: drag on empty timeline space → creates a task spanning the dragged dates
   (calendar-style). The task's lane is then derived by the packing pass, not chosen by the
   user — worth stating explicitly in help, because a user who drags in lane 3 may see the bar
   land in lane 1.

Component-by-component fate — the parity proof:

File	Fate in packed mode
TaskList/TaskTable.tsx	unchanged — still role="grid", still N rows
TaskList/TaskTableRow.tsx	+ data-task-id attribute for the CSS cross-highlight hook. No prop/logic change; React.memo preserved
TaskList/TaskDataCells.tsx	unchanged
TaskList/Cell.tsx	unchanged
TaskList/CellEditors/*	unchanged; ColorPickerPopover additionally reused by the Inspector
TaskList/RowNumberCell.tsx	unchanged (optional lane pip, see §4)
TaskList/NewTaskPlaceholderRow.tsx	unchanged — remains the primary create path
TaskList/RowOverlays.tsx	unchanged — list-side selection band stays as-is
TaskList/TaskTableHeader.tsx, ColumnResizer.tsx	unchanged
TaskList/HiddenRowIndicator.tsx, InsertLine, InsertRowButton	unchanged
hooks/useCellEdit, useCellNavigation, useTaskRowData, useHideOperations, useTableDimensions, useAutoColumnWidth	unchanged
hooks/useMarqueeSelection	unchanged — see note below
GanttChart/ChartCanvas.tsx → SelectionRows	mode-aware: row band (classic) vs per-bar ring (packed)
GanttChart/TaskBar.tsx	+ data-task-id, + hover/selection ring, + role="button" and aria-label (an a11y improvement to both modes)
Layout/GanttLayout.tsx	clamped dual translate (§5)
utils/layoutCalculations.ts	calculateLayoutDimensions gains laneCount, returns two pane heights (§5)
new GanttChart/TaskInspectorPanel.tsx	new, ~200 LOC, mirrors DependencyPropertiesPanel
new hooks/useTaskLinking.ts	hoveredTaskId, reveal, cross-highlight wiring

Fourteen "unchanged" rows is the argument.

A pleasant surprise worth flagging to Concept A: useMarqueeSelection is already
geometry-based, not index-based. It takes taskGeometries: TaskGeometry[]
({ id, x, y, width, height }) and hit-tests with rectsIntersect / findIntersectingTaskIds
— it never computes index * rowHeight. The array is built in ChartCanvas.tsx at
taskGeometriesMap / taskGeometriesArray (≈ lines 305–355). So taskGeometries is the
single natural injection point for packed y-coordinates: feed it lane-derived y values and
rubber-band selection, hit-testing and bar rendering all follow, with marquee itself untouched.
That is a much smaller blast radius than "index * rowHeight recurs throughout" suggests.

It gets better. Inside that useMemo, bar geometry is produced by a single call:

const geo = getTaskBarGeometry({
  task, scale,
  rowIndex: index,          // ← the ONLY place a task's y is decided
  densityConfig: densityGeometry,
  headerHeight: 0,
});

…and getTaskBarGeometry (src/utils/timelineUtils.ts:349) resolves it with a single line:

y: headerHeight + rowIndex * rowHeight + taskBarOffset,

rowIndex: index is the entire coupling for bar placement. Replacing index with
laneIndex from the packing pass places every bar, every connection handle
(taskGeometriesMap), and every marquee hit-test correctly in one edit. The brief's cited
ChartCanvas.tsx:168 const y = index * rowHeight is not bar layout — it is inside the
SelectionRows sub-component (§0.2). GridLines and DependencyArrow remain genuinely hard
(Concept A's territory), but bar placement itself is one token.

---

4. Column system

Read: src/config/tableColumns.ts. TASK_COLUMNS = rowNumber, color, name, startDate,
endDate, duration, progress. Only the last four carry hideable: true.
getVisibleColumns(hiddenColumns) filters; buildGridTemplateColumns +
getDensityAwareWidth + getColumnPixelWidth produce the CSS grid template; consumers are
TaskTable, TaskTableHeader, TaskTableRow (via prop), NewTaskPlaceholderRow,
useTableDimensions, and — indirectly — taskSlice.navigateCell, which filters
EDITABLE_FIELDS by hiddenColumns at ≈ line 767.

Recommendation: the column system is untouched. Because the left panel remains a CSS grid
with one row per task, hiddenColumns, columnWidths, resizing, auto-fit and the
SplitPane maxLeftWidth = totalColumnWidth constraint all keep working with zero changes.
This is the single largest cost saving in the whole proposal, and it is only available under
option (e).

Three specific answers:

• Hideable columns: unchanged behaviour, unchanged persistence in ViewSettings. One
  policy change: in packed mode the color column should be pinned visible (it is already
  non-hideable, so this needs no code — just don't add hideability to it later). It is the
  always-on binding cue from §2.
• Column widths: unchanged. useTableDimensions.totalColumnWidth is derived only from
  visible columns and density; lanes never enter the calculation.
• Row-number column: keep its current meaning — globalRowNumber from
  useFlattenedTasks, 1-based over the full flattened list with Excel-style gaps for hidden
  rows. It is not a claim about the chart's geometry; it is the list's ordinal, and it is
  load-bearing for row selection, the drag handle, insert-above/below and aria-rowindex.
  Renumbering it to lane indices would break all of those. Leave it.

Optional, default-off: a lane column. A read-only, hideable: true column showing the
computed lane index (L1, L2, …). Fits the existing idiom exactly — rowNumber is already
editable: false, renderer: "custom", and because it would have no field,
TaskDataCells.isDataColumn() filters it out of cell rendering and
navigateCell's EDITABLE_FIELDS filter never sees it. So the incremental cost is genuinely
small.

I recommend shipping it hidden by default and flagging the caveat loudly in help: lane
indices are derived and reshuffle when dates change, so the column will appear to "jump" during
editing. It earns its place for auditing the packing and for users who want to reason about
lane occupancy — not for daily use.

Persistence is already prepared for this: ViewSettings.hiddenColumns?: string[]
(src/utils/fileOperations/types.ts:131) is typed as string[], not as ColumnId[] — and
tableColumns.ts says so deliberately: "Store/file-format boundaries use string for forward
compatibility." So adding a lane member to the ColumnId union needs no file-format
migration; only the default-hidden seeding needs care so files saved before the feature
don't silently show the column.

Explicitly rejected: making getVisibleColumns mode-aware (getVisibleColumns(hidden, mode)).
It would force edits at all five call sites plus the store, for no user-visible benefit, and it
would make the persisted hiddenColumns mean different things in different modes.

---

5. Scroll architecture

Today (GanttLayout.tsx):

outerScrollRef            overflow-y: auto   height = totalContentHeight
└─ pseudo-row spacer      height = totalContentHeight
   └─ sticky container    height = viewportHeight, overflow hidden
      └─ SplitPane
         ├─ left   taskTableScrollRef   overflow-x: auto, overflow-y: CLIP
         │         └─ taskTableTranslateRef   transform: translateY(-scrollTop)
         └─ right  chartContainerRef    overflow-x: auto
                   └─ chartTranslateRef       transform: translateY(-scrollTop)

totalContentHeight = (taskCount + PLACEHOLDER_ROW_COUNT) * rowHeight
                     + HEADER_HEIGHT + SCROLLBAR_HEIGHT      (layoutCalculations.ts)

Both panes are translated by the same scrollTop. Alignment is therefore not "two
scrollbars kept in step" — it is one scrollbar and a shared transform, and it holds only while
both panes are the same height.

Proposed model: one scrollbar, two independently clamped translates.

listContentHeight  = (taskCount + PLACEHOLDER_ROW_COUNT) * rowHeight + HEADER + SCROLLBAR
chartContentHeight = (laneCount  + LANE_PADDING)         * laneHeight + HEADER + SCROLLBAR
totalContentHeight = max(listContentHeight, chartContentHeight)

maxScroll(pane)    = max(0, paneContentHeight - contentAreaHeight)
translate(pane)    = -clamp(scrollTop, 0, maxScroll(pane))

Properties, in plain words:

• Classic mode is provably unchanged. laneCount === taskCount and
  laneHeight === rowHeight ⇒ both pane heights are equal ⇒ both clamps are identical ⇒
  translate = -scrollTop for both, exactly today's behaviour. Zero regression risk on the
  existing mode, which is the "extend, not replace" constraint expressed in arithmetic.
• The common packed case needs no scrolling at all on the right. With 3 lanes,
  maxScroll(chart) === 0, so the chart never translates: it stays pinned at the top while
  the list scrolls beneath the shared scrollbar. This is the correct behaviour and it falls out
  of the formula rather than needing a special case.
• The tall-chart case degrades gracefully. If the chart is taller than the viewport but
  shorter than the list (many group bands), it scrolls until it bottoms out, then pins while
  the list continues. Predictable, one scrollbar, no racing.
• One persisted scroll position. setViewport(scrollLeft, width, scrollTop),
  pendingScrollTop restore after file load, and multi-tab persistence all keep working
  untouched, because there is still exactly one scrollTop. This matters concretely:
  ViewSettings.scrollTop?: number (src/utils/fileOperations/types.ts:101) is a single
  scalar in the saved file format. Any design that gives the two panes independent scroll
  positions forces a file-format change plus a migration. The clamped model does not.
• Horizontal is entirely unaffected: useSyncScroll(chartContainerRef, timelineHeaderScrollRef)
  and useSyncScroll(taskTableScrollRef, taskTableHeaderScrollRef) stay as they are, as does
  usePreventVerticalScroll(taskTableScrollRef).

Explicitly rejected alternative: giving the left pane its own overflow-y: auto. It
produces two scrollbars, breaks usePreventVerticalScroll, forks the persisted scroll position
(file format + multi-tab storage), and makes "reveal" ambiguous. The clamped shared driver gets
independent effective scrolling with none of that.

Open question I cannot resolve alone: whether laneHeight should equal rowHeight (reuse
density) or be its own token. That is Concept A's call, but note the dependency: whatever it
decides feeds calculateLayoutDimensions, which is a pure, unit-tested function — so it should
become a parameter, not a constant.

---

6. Wireframes

6.1 Full app, packed mode

┌─ Ribbon ──────────────────────────────────────────────────────────────────────────────┐
│  Home │ Insert │ VIEW │ Help                                                           │
│  Timeline layout:  ( ) Rows   (•) Lanes        [▣ Inspector]  [⇲ Fit]  [◧ Hide list]   │
├──────────────────────────────────┬────────────────────────────────────────────────────┤
│  Task list      (N rows)         │  Timeline      (3 lanes — packed)                   │
│┌──┬─┬────────────┬───────┬─────┐ │      Mar          Apr          May          Jun     │
││ #│▮│ Name       │ Start │ Dur │ │  ├───────────┼───────────┼───────────┼───────────┤  │
│├──┼─┼────────────┼───────┼─────┤ │                                                     │
││ 1│▮│▾ Phase 1   │ 01 Mar│ 62d │ │  ▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁ (summary)     │
││ 2│▮│   Design   │ 01 Mar│ 20d │ │L1 ▐██ Design ██▌ ▐████ Build ████▌ ▐ QA ▌            │
││ 3│▮│   Build    │ 24 Mar│ 30d │ │L2 ▐█ Research █▌        ▐███ Docs ███▌               │
││ 4│▮│   QA       │ 05 May│ 12d │ │L3      ◆ Kickoff          ▐██ Hiring ██▌             │
││ 5│▮│   Research │ 01 Mar│ 15d │ │                                                     │
││ 6│▮│   Docs     │ 14 Apr│ 18d │ │   ╎ chart is 3 lanes tall → shorter than viewport    │
││ 7│▮│▾ Phase 2   │ 02 Jun│ 40d │ │   ╎ ⇒ maxScroll(chart) = 0 ⇒ pinned, never translates│
││ 8│▮│   Rollout  │ 02 Jun│ 25d │ │                                                     │
││ …│ │            │       │     │ │                                                     │
││  │ │ Add new... │       │     │ │                                                     │
│└──┴─┴────────────┴───────┴─────┘ │                                                     │
│  ▲ full spreadsheet: all columns,│                                                     │
│    all cell editing, placeholder │                                                     │
│    row, insert, DnD — unchanged  │                                                     │
└──────────────────────────────────┴────────────────────────────────────────────────────┘
   ▲ one shared vertical scrollbar on the right edge of the window (not drawn)

Note what is not in this wireframe: no lane column, no summarised rows, no missing name cell.
The left panel is the panel you already have.

6.2 Editing — Inspector open, task "Build" selected

┌──────────────────────────────────┬─────────────────────────────┬─────────────────────┐
│  Task list                       │  Timeline (3 lanes)         │  ▣ TASK INSPECTOR   │
│┌──┬─┬────────────┬───────┬─────┐ │                             │ ┌─────────────────┐ │
││ 1│▮│▾ Phase 1   │ 01 Mar│ 62d │ │ L1 ▐█Design█▌╔═Build═╗▐QA▌  │ │ Name            │ │
││ 2│▮│   Design   │ 01 Mar│ 20d │ │              ╚═══════╝      │ │ ┌─────────────┐ │ │
│╔═╤═╤════════════╤═══════╤═════╗ │ L2 ▐█Research█▌ ▐██Docs██▌   │ │ │Build       ▌│ │ │
│║ 3│▮│   Build    │ 24 Mar│ 30d ║ │ L3    ◆Kickoff  ▐█Hiring█▌   │ │ └─────────────┘ │ │
│╚═╧═╧════════════╧═══════╧═════╝ │                             │ │ Type            │ │
││ 4│▮│   QA       │ 05 May│ 12d │ │  ▲ selected bar carries a   │ │ [Task|Summ|Mile]│ │
││ 5│▮│   Research │ 01 Mar│ 15d │ │    2px brand ring — NOT a   │ │ Start   End     │ │
││ …│ │            │       │     │ │    full-width row band      │ │ [24 Mar][22 Apr]│ │
│└──┴─┴────────────┴───────┴─────┘ │                             │ │ Duration  %     │ │
│  ▲ same task, same brand ring    │                             │ │ [30 d  ] [ 45 ] │ │
│    via RowOverlays (unchanged)   │                             │ │ Colour  ▮ ▾     │ │
│                                  │                             │ │ Depends on:     │ │
│  You can still just click the    │                             │ │  • Design (FS)  │ │
│  Name cell and type. The         │                             │ │ [Delete task]   │ │
│  Inspector is a second surface,  │                             │ └─────────────────┘ │
│  not the only one.               │                             │ multi-select shows  │
│                                  │                             │ mixed values as "—" │
└──────────────────────────────────┴─────────────────────────────┴─────────────────────┘

  With the list collapsed (◧ Hide list — already supported today via isTaskTableCollapsed):

┌──────────────────────────────────────────────────────────────┬─────────────────────┐
│  Timeline (3 lanes, full width)                              │  ▣ TASK INSPECTOR   │
│ L1 ▐█Design█▌ ╔══ Build ══╗ ▐QA▌      ┌────────────────────┐ │  … same panel …     │
│ L2 ▐█Research█▌ ▐██Docs██▌            │ Build            ▌ │ │                     │
│ L3    ◆Kickoff   ▐█Hiring█▌           └────────────────────┘ │  Editing still has  │
│                                        ▲ double-click a bar  │  two surfaces, so   │
│                                          → inline name edit  │  nothing is lost.   │
└──────────────────────────────────────────────────────────────┴─────────────────────┘

6.3 Cross-highlighting on hover (pointer over the bar "Docs")

┌──┬─┬────────────┬───────┬─────┐   │                                        │
│ 1│▮│▾ Phase 1   │ 01 Mar│ 62d │   │ L1 ▐██ Design ██▌ ▐████ Build ████▌     │
│ 2│▮│   Design   │ 01 Mar│ 20d │   │ L2 ▐█ Research █▌      ┌───────────┐    │
│ 3│▮│   Build    │ 24 Mar│ 30d │   │ L3    ◆ Kickoff        │▐██ Docs ██▌│◄──╂── pointer
│ 4│▮│   QA       │ 05 May│ 12d │   │                        └───────────┘    │
│ 5│▮│   Research │ 01 Mar│ 15d │   │                                         │
│┌─────────────────────────────┐│   │  hoveredTaskId = "docs" in chartSlice   │
││ 6│▮│   Docs     │ 14 Apr│18d││···│  applied by CSS attribute selector on    │
│└─────────────────────────────┘│ ▲ │  [data-task-id="docs"] — no React       │
│ 7│▮│▾ Phase 2   │ 02 Jun│ 40d │ ╎ │  re-render, React.memo stays effective  │
└──┴─┴────────────┴───────┴─────┘ ╎ │                                         │
   ▲ 1px outline + slate-50 wash  ╎                                           │
     no layout shift              ╎                                           │
                                  └── OPTIONAL leader line (off by default):  │
                                      exactly one, thin dotted slate-400,     │
                                      no arrowhead (must not read as a        │
                                      dependency arrow), drawn in a portal    │
                                      overlay above the SplitPane divider.    │
                                      Cut this first if time is short.        │

Off-screen case (row 6 scrolled out of the list): no line is drawn; instead the list edge shows
a 2 px brand-600 tick at the top or bottom edge indicating the direction of the linked row,
and clicking the bar scrolls it into view.

6.4 Selection / edit flow

flowchart TD
    subgraph LIST["Left panel — Task list (N rows, unchanged)"]
      A1["Click row / row-number cell"]
      A2["Click cell → active cell"]
      A3["Type / F2 / Enter → useCellEdit"]
      A4["Placeholder row → create task"]
    end

    subgraph CHART["Right panel — packed timeline (L lanes)"]
      B1["Click bar"]
      B2["Double-click bar → inline name edit"]
      B3["Drag / resize / progress-drag"]
      B4["Drag empty lane space → create task"]
    end

    SEL(["selectedTaskIds — single source of truth<br/>taskSlice / selectionActions"])

    A1 --> SEL
    A2 --> SEL
    B1 --> SEL

    SEL --> H1["RowOverlays band on the list row"]
    SEL --> H2["brand-600 ring on every bar of the selection<br/>(replaces SelectionRows' full-width band)"]
    SEL --> H3["Reveal: scroll row into view · pan chart to bar"]
    SEL --> INS["Task Inspector<br/>(available in BOTH modes)"]

    A3 --> MUT(["updateTask / historySlice command"])
    B2 --> MUT
    B3 --> MUT
    INS --> MUT
    A4 --> MUT
    B4 --> MUT

    MUT --> REPACK["repack lanes (derived, not persisted)"]
    REPACK --> CHART
    MUT --> LIST

    HOV(["hoveredTaskId — chartSlice"])
    LIST -. "mouseenter" .-> HOV
    CHART -. "mouseenter" .-> HOV
    HOV -. "CSS [data-task-id] — no re-render" .-> LIST
    HOV -. "CSS [data-task-id] — no re-render" .-> CHART

Loading

---

7. Accessibility

• The list stays the accessible source of truth. role="grid", role="row",
  aria-selected, aria-rowindex are all preserved because the DOM row structure is preserved.
  A screen-reader user navigating packed mode has an identical experience to classic mode. This
  is the strongest reason not to pick (b), (c)-as-replacement or (d)-as-default.
• aria-rowindex remains truthful because it describes the grid, not the chart. Packing
  is a visual property of a different region.
• Bars gain semantics they don't have today. Give TaskBar role="button" and
  aria-label={${name}, ${start} to ${end}, ${progress}% complete, lane ${laneIndex} of ${laneCount}},
  plus aria-describedby pointing at the corresponding row's id. This is a net a11y improvement
  to both modes (see §0.3) and is worth doing regardless of Compact Mode #88's outcome.
• Never make packed mode the only route to a task. If the list is collapsed, keyboard focus
  must still be able to reach every task via the chart's bar sequence and the Inspector.
• The Inspector must be role="dialog" with a focus trap and Escape-to-close, matching
  DependencyPropertiesPanel, and must not steal focus on selection change (announce via
  aria-live="polite" instead) — otherwise arrow-key cell navigation becomes unusable.
• useHighContrast must cover the new hover/selection rings; a 1 px slate wash is invisible
  in high-contrast mode, so the hover state needs a high-contrast variant (outline weight, not
  fill).

---

8. Naming (a note, deferring to Concept A)

The brief is right that "Compact" is taken: DENSITY_CONFIG.compact (28 px rows) is surfaced in
preferences as "Compact / Normal / Comfortable". From the left panel's point of view the useful
distinction is what a chart row means: one task, or one lane. So I'd name the setting after
that, e.g. Timeline layout: Rows / Lanes, and refer to "lane view". It reads correctly
in the ribbon next to a density setting that says "Compact", and it gives the packing unit a
name the help text and the optional lane column can both use. Concept A owns the final call.

For the panel itself: it is already role="region" aria-label="Task list" in GanttLayout, and
"list" is the more honest word once it stops being positionally bound to the chart. Prefer
Task list over "task table" in new UI copy; leave the component names alone.

---

9. Uncertainties, stated plainly

1. Leader lines across a resizable divider with two independently horizontally-scrolled panes
   are fiddly. I recommend building cross-highlighting first and treating the leader line as an
   experiment behind a preference. What would resolve it: a throwaway prototype measuring
   whether a portal overlay line stays glued during split-pane drag and horizontal scroll.
2. Whether the Inspector should be docked (third pane) or floating (like
   DependencyPropertiesPanel). Floating is cheaper and matches existing code; docked is better
   for sustained editing and multi-select. What would resolve it: which one the author expects
   to use for bulk edits. I lean floating-first, docked as a follow-up, because it reuses an
   existing component wholesale.
3. Whether users will accept a scrollbar that moves the two panes at different rates. The
   clamped model is principled but I have no user evidence. What would resolve it: a quick
   Playwright-driven prototype of the clamp in GanttLayout.tsx (~10 lines) and a look at it.
4. The lane column's churn. I recommend default-off; if it turns out lane indices are
   stable enough in practice (Concept A's packing may use a stable-assignment heuristic), it
   could reasonably default on. That depends on Concept A's algorithm choice.

---

10. What Concept C / the synthesiser should take from this

1. Do not redesign the left panel. Decouple it. The table's survival is what makes feature
   parity free.
2. The only genuinely broken thing is scroll math, and it is ~10 lines in GanttLayout.tsx
   plus a signature change in the already-pure calculateLayoutDimensions.
3. Cross-highlighting + reveal is the alignment substitute. Colour is the always-on cue;
   the leader line is optional and cuttable.
4. The Inspector is additive and belongs in both modes — that is what keeps it out of
   silo territory and what pays for its cost.
5. Fix the brief's factual slips (§0.1 scroll model, §0.2 SelectionRows vs
   SelectionHighlight) before anyone plans against them — and note that
   useMarqueeSelection needs no work at all (§3).
6. ChartCanvas.taskGeometries is the injection point for packed y-coordinates. Design the
   packing pass to produce that array and most of the chart follows.

---

Agent: Concept Agent B — Left Panel / Table

[kitikonti]

Concept C — CRUD, Interaction & Keyboard Model

Phase 1 concept, Agent C. Scope: every create/read/update/delete/navigate operation, redesigned for the packed display, at parity with the classic display. I read the actual code rather than the docs; every claim about today's behaviour below is cited to a file and line so later agents can check me.

Terminology note: I use "packed" for the new display and "classic" for today's one-row-per-task display, because compact is already taken by DENSITY_CONFIG.compact (28px rows, src/config/densityConfig.ts:9). Final naming is Concept A/B's call — substitute freely.

---

0. The one structural idea everything else hangs off

The author's complaint is "I can't type a task name in the task table, because in this view there is no task table." My answer is that the table never goes away — it changes granularity, and it gains a second surface.

Three surfaces exist in packed mode, and every CRUD operation maps onto one of them:

Surface	Classic mode	Packed mode
Left panel	Task table: 1 row per task	Lane Ledger: 1 row per lane, expandable ("explode") to reveal its tasks
Detail strip	(does not exist — cells live in each row)	One pinned row of the same cells, bound to the focused task
Timeline	1 bar per row	N bars per lane

Two consequences, and they are the load-bearing ones:

(a) Vertical alignment survives, at lane granularity. Ledger row i ↔ lane i, same y, same height. useSyncScroll and the whole SVAR sticky-scroll layout keep working untouched; the row count simply becomes laneCount + 1 instead of tasks.length + 1 (ChartCanvas.tsx:410). No new alignment mechanism is needed.

(b) Classic mode is packed mode with every lane exploded. "Explode lane 3" un-packs that one lane back into per-task sub-rows in both panels simultaneously. "Explode all" is, definitionally, the classic view. This is not a metaphor — it should be the literal implementation, and it is the strongest possible answer to the author's non-negotiable constraint that the new display extend rather than replace: the two modes are the endpoints of one continuum, not two silos.

(c) Cell editing is preserved wholesale. The Detail Strip renders real TaskDataCells / Cell / CellEditors/ components. So useCellEdit, activeCell, isEditingCell, startCellEdit, cell-level copy/cut/paste (COPY_CELL/PASTE_CELL), and EDITABLE_FIELDS tab order (src/types/task.types.ts:54) all survive unchanged. The 2D cell grid does not disappear; it collapses from N × 7 to 1 × 7, and the row axis is replaced by a focused-task pointer. Arrow-Up/Down in the strip re-binds the strip to a different task instead of moving to a different DOM row. That is a small, surgical change to navigateCell (taskSlice.ts:764), not a rewrite.

CLASSIC                                    PACKED
┌──────────────┬─────────────────┐        ┌──────────────┬─────────────────┐
│ # Name  S  E │ timeline        │        │ Lane  n  ⌄   │ timeline        │
├──────────────┼─────────────────┤        ├──────────────┼─────────────────┤
│ 1 Design ... │  ▓▓▓▓            │       │ ▸ Lane 1  4  │ ▓▓▓  ▓▓▓▓  ▓▓   │
│ 2 Build  ... │       ▓▓▓▓▓      │       │ ▸ Lane 2  3  │   ▓▓▓▓   ▓▓▓▓▓  │
│ 3 Test   ... │            ▓▓▓   │       │ ▸ Lane 3  2  │ ▓▓▓▓▓▓▓▓        │
│ 4 Ship   ... │  ▓▓▓             │       │ + Add task…  │                 │
│ + Add task…  │                  │       ├──────────────┴─────────────────┤
└──────────────┴──────────────────┘       │ DETAIL STRIP (focused task)    │
  cells live in every row                 │ ■ │Design rev.│▾│03-12│03-19│6│40%│
                                          └────────────────────────────────┘
                                            cells live once, bound to focus

---

1. Create

1.1 What exists today

Path	Code	Behaviour
Placeholder row	NewTaskPlaceholderRow.tsx, usePlaceholderNameEdit	Type into the last row → task created
Ribbon / Alt+N	useNewTaskCreation.createTask	Appends after the latest-ending task, order = maxOrder + 1, then requestScrollToDate
Row-number hover "+"	InsertRowButton + InsertLine	Insert above/below the hovered row
Context menu	contextMenuItemBuilders.ts:155,162	"Insert Task Above" / "Insert Task Below"
Ctrl +	useKeyboardShortcuts.ts:291	Insert n tasks above (n = selection size)
Store	insertionActions.ts → computeInsertionDates	Dates derived from the reference task (±DEFAULT_TASK_DURATION), order = refOrder ± 0.001·i, then normalizeTaskOrder

Note what computeInsertionDates already does: "insert below" already means "start the day after the reference task ends". Insertion in OwnChart is already a date operation as much as a row operation. That is the hinge for packed mode.

1.2 Packed mode: four creation paths, all live in both modes

(A) Double-click empty timeline space → create. Creates a task of DEFAULT_TASK_DURATION starting at the clicked date, in the clicked lane, and opens the inline name editor on the new bar. Zero-mode, zero-modifier, no drag → this is the WCAG 2.5.7 non-drag path and the mouse-only default. It matches what Bryntum and DHTMLX Scheduler ship (see §9 research).

(B) Draw-to-create (D tool, or hold D and drag). Cursor becomes a crosshair; drag horizontally in a lane to draw the bar; the ghost snaps to the current timeline unit and shows a live "12 Mar – 19 Mar · 6 wd" tooltip; release commits and opens the inline name editor. A drag shorter than 4px degrades to (A). Drag right-to-left is normalised. This is the Google-Calendar gesture and it is the fastest way to enter a plan by hand.

Why a tool/quasimode instead of a bare drag — this is settled prior art, not a preference. Bryntum encodes the conflict as a hard feature incompatibility: EventDragSelect is documented as mutually exclusive with EventDragCreate and Pan, and Bryntum's own example turns drag-create off in order to turn drag-select on (EventDragSelect docs). The industry-leading scheduler library concluded that drag-on-empty-space cannot mean both things. In OwnChart, bare drag on empty SVG is already useMarqueeSelection (ChartCanvas.tsx:463), and packed mode makes marquee more valuable, not less (§2.1) — so I keep marquee and gate create behind a tool. Alt+drag is unavailable too: Alt+Shift+Arrow is indent/outdent (useKeyboardShortcuts.ts:315) and altKeyHeld is an auto-scheduling override flag (ViewTabContent.tsx:40). D is free.

Why (A) is the primary path and (B) the power path. Every mainstream calendar makes the cheap gesture create at a default duration and the drag an optional precision refinement — never the reverse. Google Calendar: "Click any time on the calendar that doesn't already have an event scheduled", with "To create a longer event, drag your mouse down the page" as the tip (support); its bare-click default is 30 min, admin-configurable (Workspace admin). Apple Calendar: "drag from the event's start time to its end time… You can also double-click next to a specific time" (Apple). Fantastical: "double-click on a day in the week or month view, or on a specific time in the day view" (Flexibits). DEFAULT_TASK_DURATION is OwnChart's equivalent of Google's 30-minute default and already exists.

The 4px threshold has precedent. FullCalendar exposes selectMinDistance — "the minimum distance the user's mouse must travel after a mousedown, before a selection is allowed" — defaulting to 0, with non-zero values existing specifically "to distinguish between a selection action and a date click event" (docs). Bryntum's DragHelper#dragThreshold is "the amount of pixels to move mouse before it counts as a drag operation" (docs). FullCalendar also splits dateClick (tap) from select (drag-range) into two separate callbacks — the distinction is formalised, not implicit. Show a selectMirror-style ghost during the drag (docs).

A Gantt-specific caution I want on the record. Bryntum ships EventDragCreate enabled by default in Scheduler, but deliberately did not do the same in Gantt: TaskDragCreate there is only "used to schedule tasks, meaning it's only relevant for tasks without start / end date" (Bryntum support). The reason is exactly our issue: in a classic Gantt a row is a task, so "drag in the empty part of a row" is ambiguous. In packed mode a lane is not a task — so the Scheduler precedent applies and drag-create becomes coherent. This is a real argument that drag-create is a packed-mode-native feature rather than something we should also bolt onto classic mode.

(C) Placeholder row → "Add task…" row at the bottom of the Lane Ledger. Unchanged semantics: type a name, useNewTaskCreation.createTask appends at maxOrder + 1 after the latest-ending task, requestScrollToDate brings it into view. It lands in whatever lane fits — almost always lane 0, since by construction it starts after everything else ends. This is the direct answer to "task creation is lost": it is not lost, it is one row further down.

(D) Keyboard. Ctrl+Enter (or Insert) creates a default-duration task starting at the time cursor — a persistent, keyboard-movable date caret rendered as a thin vertical line in the timeline (moved with Ctrl+←/→ when no bar is focused, or set by clicking the ruler). Alt+N keeps its current append-at-end meaning. Ctrl + keeps inserting into the outline.

1.3 Which lane does it land in? — lane is an outcome, never an input

There is no lane field in Task (src/types/chart.types.ts) and there must not be one. Packing is pack(visibleTasks) → laneIndex[], a pure function of dates. Therefore:

• The lane you drew in is a hint for the dates only. On commit, the packer runs. If the drawn span fits the drawn lane, it stays there (a stable packer must guarantee this — see §8.3). If it collides, it goes to the first lane that fits, with a 150 ms slide animation plus a toast: "Placed in lane 2."
• A user cannot pin a task to a lane. I recommend keeping it that way for v1. If pinning is ever wanted, metadata.lanePin?: number is the escape hatch (metadata is already free-form) — but it makes packing non-deterministic under undo and I would fight it. Open question flagged.

1.4 order vs. packing — the reconciliation

Firm position: order is untouched by packing, and packing never reads it except as a tie-break.

Two orderings co-exist and own disjoint responsibilities:

	Document order (order + parent)	Chronological layout (derived laneIndex)
Persisted?	Yes — it is the file format	No — recomputed every render/commit
Owns	outline, row numbers, indent/outdent, group, insert before/after, paste position, export order, hierarchy	y position only
Changed by	insertionActions, indentOutdentActions, groupingActions, prepareRowPaste	nothing — it is derived
Read by packer	only as the final tie-break when two tasks could occupy the same lane	—

Consequences:

1. "Insert above/below" still means something exact — it means before/after in the outline, which computeInsertionDates already turns into earlier/later in time. So the operation is not only well-defined in packed mode, it is arguably more meaningful there, because you can see the date shift happen.
2. But the labels lie. In packed mode the new task will very often not appear above or below anything. Rename in packed mode to "Insert Task Before" / "Insert Task After" (outline language, not spatial language). Same action ids, same store calls — a label swap in contextMenuItemBuilders.ts:155-165.
3. Keep the outline readable inside the picture. Render globalRowNumber as a small badge at the left end of each bar (View-tab toggle, on by default in packed mode). Without it the outline becomes invisible and the author's "I need all features in both displays" promise breaks.
4. Drop the hover + / InsertLine affordance from the packed timeline. A full-width insert line across a packed lane is meaningless (it would sit between two lanes, which are not outline-adjacent). It survives inside an exploded lane in the ledger, where rows are outline-adjacent again. In the packed timeline, insert-before/after lives in the context menu and on Ctrl + only.
5. order gets a new, cheap visual affordance in packed mode: the dependency arrows already show real sequence. Where users used to read sequence from row order, packed mode makes them read it from arrows and dates — which is more truthful anyway.

1.5 Create-by-drag wireframe

        Mar 10   Mar 11   Mar 12   Mar 13   Mar 14   Mar 15   Mar 16
       ┌────────┬────────┬────────┬────────┬────────┬────────┬────────┐
Lane 1 │ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ │        │ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ │        │
       │  Kickoff        │        │  Vendor review          │        │
       ├────────┴────────┼────────┴────────┴────────┴────────┴────────┤
Lane 2 │        │ ╔═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═╗ │        │  ← drag
       │        │ ║  ┌──────────────────────────────┐   ║ │        │
       │        │ ║  │ 11 Mar – 14 Mar · 4 d / 4 wd │   ║ │        │
       │        │ ╚═ ═└──────────────────────────────┘═ ═╝ │        │
       ├────────┼────────┬────────┬────────┬────────┬───────┴────────┤
Lane 3 │ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ │        │        │        │
       └────────┴────────┴────────┴────────┴────────┴────────┴────────┘
         ↑ press-and-drag with the D tool active (crosshair cursor)

on release ──────────────────────────────────────────────────────────►

Lane 2 │        │ ▓▓▓▓[ New task…                    ]▓▓▓ │        │
                     └── inline name editor, text pre-selected,
                         min 160px wide even if the bar is 3px,
                         Enter = commit · Tab = Detail Strip · Esc = undo create

1.6 Create interaction — state machine

stateDiagram-v2
    [*] --> Idle

    Idle --> Drawing: pointerdown on empty lane<br/>(D tool active)
    Idle --> QuickCreate: dblclick on empty lane
    Idle --> QuickCreate: Ctrl+Enter / Insert<br/>(at time cursor)
    Idle --> AppendCreate: Alt+N · Ribbon "New Task"<br/>· type in "Add task…" row
    Idle --> OutlineInsert: Ctrl++ · menu "Insert Before/After"
    Idle --> Marquee: pointerdown on empty lane<br/>(no D tool) — selection, not create

    Drawing --> Drawing: pointermove<br/>snap ghost to unit · live date tooltip
    Drawing --> QuickCreate: pointerup, |dx| < 4px<br/>(degrade to default duration)
    Drawing --> Committing: pointerup, |dx| >= 4px<br/>normalise reversed drag
    Drawing --> Idle: Escape (abort, nothing created)

    QuickCreate --> Committing: dates = clicked date<br/>+ DEFAULT_TASK_DURATION
    AppendCreate --> Committing: computeAppendDates()<br/>after latest-ending task
    OutlineInsert --> Committing: computeInsertionDates()<br/>relative to reference task

    Committing --> Committing: snapForwardToWorkingDay()<br/>if WD mode enabled
    Committing --> Packing: addTask() · order = maxOrder+1<br/>or refOrder ± 0.001·i<br/>recordCommand(ADD_TASK)

    state Packing {
        [*] --> Rederive
        Rederive --> KeptLane: drawn lane still free
        Rederive --> MovedLane: collision -> first free lane
        MovedLane --> Announce: toast "Placed in lane N"<br/>+ aria-live announcement
        KeptLane --> [*]
        Announce --> [*]
    }

    Packing --> NamingBar: select new task · focus it<br/>· requestScrollToDate()<br/>· open inline name editor
    NamingBar --> Idle: Enter / blur -> commit name
    NamingBar --> DetailStrip: Tab
    NamingBar --> Reverting: Escape
    Reverting --> Idle: delete the just-created task<br/>(single undo step, not two)

    DetailStrip --> Idle: Escape / click away
    Marquee --> Idle: pointerup -> setSelectedTaskIds()

Loading

Two details in there matter.

Escape during naming deletes the task rather than leaving a "New Task" ghost. Otherwise packed mode fills with untitled noise and every abort costs a Ctrl+Z.

The inline name editor must not be the only editing surface — and this is a documented, recent industry failure, not a hypothetical. In release 20250918044.05 (Sept 2025) Microsoft shipped, verbatim, "Calendar: Replace quick compose pop-up with inline appointment creation"; users pushed back hard because the inline chip cannot capture the secondary fields the popover could — "It requires an extra step after the event is created… the record is having to be modified twice" (Microsoft Q&A). Google went the opposite direction, deliberately migrating guest permissions, attachments, colour, notifications and visibility into the quick-create popover so users would not have to click "More options" (Workspace Updates). The Detail Strip (§3.1) is OwnChart's answer to this failure mode: the inline chip takes the name, and all seven EDITABLE_FIELDS are simultaneously visible and editable one Tab away, with no second gesture and no modal.

---

2. Read & Select

2.1 Good news first: the marquee already works

useMarqueeSelection does not hit-test rows. findIntersectingTaskIds (useMarqueeSelection.ts:127) intersects the marquee rect against TaskGeometry[] — actual bar rectangles — via rectsIntersect. Those geometries come from getTaskBarGeometry({ rowIndex: index, … }) in ChartCanvas.tsx:320. Swap index for laneIndex and marquee selection is packed-mode-correct with zero further change. That is the single cheapest win in this whole concept and it should be stated in the sprint plan so nobody rewrites it.

It also gets better: a tall thin marquee in packed mode is now a time-range selection — "select everything happening in Q3" — across all lanes at once. That capability does not exist in classic mode at all. Keep intersection semantics (touch = select), not containment; containment would make thin marquees useless against 3px bars.

onSelectionChange already takes (taskIds, addToSelection) and is wired straight to setSelectedTaskIds (ChartCanvas.tsx:369), so Shift+marquee = add to selection is a one-line wiring change.

2.2 Bad news: SelectionRows must be replaced

ChartCanvas.tsx:151-196 draws, per selected task, a full-width band y = index * rowHeight, width = timelineWidth, plus top/bottom 2px brand lines suppressed when the previous/next index is also selected (border merging across adjacent rows). In packed mode this is wrong twice over: (1) a full-width band would highlight every unrelated bar sharing that lane; (2) "previous index" and "next index" have no meaning — adjacency in a packed lane is chronological, not selectional, so the merge logic is not just useless, it is actively misleading.

Replacement: bar-hugging selection. Delete the merge logic entirely; it has no packed-mode analogue.

CLASSIC (today)                        PACKED (proposed)
┌──────────────────────────────┐      ┌──────────────────────────────────┐
│▒▒▒▒▒ ▓▓▓▓ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒│      │ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ │ lane tint
│▒▒▒ full-width band, merged ▒▒│      │ ▓▓▓  ╔══════╗   ▓▓▓▓   ╔════╗    │
│▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒│      │      ║▓▓▓▓▓▓║          ║▓▓▓▓║    │ ring
├──────────────────────────────┤      │ ▐    ╚══════╝          ╚════╝  ▐ │ end caps
│      ▓▓▓▓▓▓                  │      ├──────────────────────────────────┤
└──────────────────────────────┘      │   ▓▓▓▓▓▓▓   ▓▓   ╔╗              │
   neighbours in the same row          │                  ║║ ← 2px bar,  │
   are dragged into the highlight      │                  ╚╝   still     │
                                       │                       visible   │
                                       └──────────────────────────────────┘
   ruler:  ┄┄┄┄┄┃┄┄┄┄┄┄┄┄┄┃┄┄┄┄┄┄┄┃┄┄  ← selection ticks on the header,
                                          so off-screen / hairline
                                          selections are still findable

Concretely, per selected bar:

1. Ring — rounded rect inset −3px around the bar, 2px COLORS.brand[600] stroke, TASK_BAR_RADIUS + 3 corner radius.
2. Fill — brand fill at COLORS.chart.selectionFillOpacity clipped to the bar only, not the lane.
3. End caps — a 4px-wide solid brand tick flush at each end of the bar, drawn outside the ring. This is what keeps a 2px-wide bar legibly selected; a ring alone on a 2px bar is a smudge.
4. Lane tint — every lane containing ≥1 selected task gets a very low-opacity brand wash across its full width, no border. This restores the "which lane am I in" cue that the band used to give, without implying the whole lane is selected. Different opacity from the marquee wash so the two never read as the same thing.
5. Ruler ticks — a 2px brand tick in the TimelineHeader at each selected task's start date. Cheap, and it is the only way to find a selected 2px bar that has scrolled off-screen.
6. Ledger echo — the lane's ledger row shows 2 / 7 selected; an exploded lane shows the classic row highlight unchanged.

Do not rely on colour alone (there is a useHighContrast hook): the ring must remain a shape change (inset + caps) that survives high-contrast and colour-blind modes.

2.3 Click selection

useRowSelectionHandler (plain / Ctrl / Shift) and selectionActions (toggleTaskSelection, setSelectedTaskIds, selectAllTasks, clearSelection) are all ID-based and completely order-agnostic — they need no change. The only question is Shift+click semantics.

selectTaskRange today builds buildFlattenedTaskList and selects the index range — i.e. an outline range (selectionActions.ts:31-56). In packed mode two tasks that look adjacent may be 40 outline positions apart, and the resulting selection will look arbitrary.

Recommendation: keep Shift+click = outline range (unchanged, consistent with the ledger, consistent with the table, one code path). Add Ctrl+Shift+click = chronological range — "select everything that starts between these two bars", which is the selection the packed picture visually promises. Both are useful; only the second is new.

There is a third option worth knowing about: vis.js Timeline's multiselectPerGroup — "if true, selecting multiple items using shift+click will only select items residing in the same group as the first selected item" (vis.js docs). Translated to OwnChart that is "Shift+click selects a range within the current lane only". I reject it as a default (it silently drops half the user's intended range) but it is the right behaviour for a lane-scoped variant, and it is what the "Select all in this lane" context item does anyway (§7).

Open question I cannot resolve from the code: which of the three should be the default gesture in packed mode is a genuine user-research question. Resolve it with a two-variant Playwright click-through on a 40-task chart, not by argument.

One more thing worth protecting. No mainstream calendar app has multi-select at all — Google Calendar has no shift-click or ctrl-click for events and the gap is filled by a third-party extension (Google support thread); DHTMLX Scheduler's API is strictly singular (select(id) / unselect(), and onEventUnselected fires "when the user unselects an event by selecting some other event" — docs); Apple Calendar's own help contains no multi-select instructions. Only Bryntum ships both multi-select (multiEventSelect, off by default — EventSelection docs) and marquee (EventDragSelect, also off by default). OwnChart already has both, on by default. That is a genuine differentiator and packed mode must not regress it.

2.4 Hover & focus

hoveredTaskId (ChartCanvas.tsx:222) already gates ConnectionHandles visibility. In packed mode hover must additionally: raise the hovered bar's z-order above its neighbours' padded hit rects (§3.4), and show a hover card after 400 ms with name / dates / progress / dependencies — because in packed mode the bar label often does not fit. The hover card is the read affordance that replaces "just look at the row".

---

3. Update

3.1 Editing name / dates / progress / colour without a row — the Detail Strip

Everything in EDITABLE_FIELDS (color, name, type, startDate, endDate, duration, progress — src/types/task.types.ts:54) is edited in the Detail Strip: a single pinned row of real Cell components under the ledger header, bound to the focused task. It reuses TaskDataCells, Cell, CellEditors/*, useCellEdit, useIsCellEditing, getCellStyle / getActiveCellStyle, and it respects hiddenColumns and columnWidths exactly like the table does.

Reuse ledger:

• activeCell: { taskId, field } — unchanged shape. In packed mode taskId is simply always the focused task.
• navigateCell (taskSlice.ts:764) — left/right unchanged (walk visibleFields). up/down change from "previous/next in buildFlattenedTaskList" to "previous/next task in the current traversal axis" (§5). Same function, different index source.
• COPY_CELL / CUT_CELL / PASTE_CELL and cutCell state — unchanged.
• The strip has an outline breadcrumb on the left (Phase 2 › Vendors › Design review · #17) so hierarchy and row number are never lost.

Second editing path: inline on the bar. Enter / F2 / double-click on a bar opens a foreignObject text input over the bar, minimum 160px wide regardless of bar width, anchored to the bar's start and allowed to overflow the lane. Enter commits, Tab hands off to the Detail Strip, Escape reverts (and deletes if the task was created in this gesture, §1.6).

Third path: context menu. Colour and type are already context-menu items (contextMenuItemBuilders.ts:287) and need no change.

3.2 Bar drag & resize — already packing-safe, with one hard rule

useTaskBarInteraction converts deltaX to deltaDays (pixelsToDeltaDays(deltaX, pixelsPerDay)); y is never read and vertical drag never reorders anything. So dragging a bar in packed mode already does the right thing: it changes dates, and the lane re-derives. No behaviour change needed.

Hard rule: pack on commit, never during a live drag. During drag/resize the dragged bar stays at its original lane y with the existing dashed preview outline; the packer runs once on pointerup, and the bar animates to its new lane over ~150 ms. Without this rule the bar hops between lanes under the cursor as it crosses other bars, which is unusable. Same rule for multi-drag (MULTI_DRAG_TASKS) and for auto-scheduling cascades: one re-pack per committed command.

3.3 Resize edges vs. small bars

EDGE_THRESHOLD = 8 (src/utils/taskBarDragHelpers.ts:27); detectInteractionZone classifies relativeX < 8 as left-edge and > width − 8 as right-edge. On a 20px bar the edges eat 16px and leave 4px of move zone. On a 12px bar the two edge zones overlap and the move zone is gone. On a 3px bar the whole thing is one ambiguous smear. This is already latently broken today at low zoom; packed mode makes it the common case.

Rules:

• effectiveEdge = min(EDGE_THRESHOLD, floor(width / 3)) — the move zone can never vanish.
• Below MIN_MANIPULABLE_WIDTH = 12px: disable edge resize entirely. The whole bar becomes a move target, cursor stays grab, and resizing goes through the Detail Strip's endDate/duration cell or keyboard nudge (§5.5). A "zoom in to resize" hint appears in the hover card.
• Keep PROGRESS_HANDLE.minBarWidth = 30 (TaskBar.tsx:69) as-is — it is already the correct instinct, applied to progress. Generalise the pattern.

3.4 The hit-target problem — the honest version

At MIN_ZOOM = 0.05 (timelineUtils.ts:32) a one-day task is a fraction of a pixel wide. Today that is survivable because you can always click the row in the table instead. In packed mode the row is gone, so the bar is the only pointer target — the hit-target problem is promoted from a nuisance to a blocker. WCAG 2.2 SC 2.5.8 wants ≥24×24 CSS px targets.

The libraries that solved this converged on four distinct strategies, and OwnChart should use three of them:

Strategy	Who ships it	Verdict for OwnChart
Clamp the item to a floor	FullCalendar eventMinHeight: 15 ("the minimum height an event is allowed to be", docs); DHTMLX event_min_dy (timeline docs)	Adopt
Grow the container instead of shrinking further	Bryntum minPackSize: "if packing leads to any event being smaller than this value, the row will grow in height instead to maintain this minimum size" (docs)	Not applicable on the x-axis (bar width is the duration; growing it would lie) — but it is the right instinct and §6.5's lane explode is our y-axis equivalent
Style hook, don't resize	Bryntum narrowEventWidth: below it the bar gets class b-sch-event-narrow "you may apply custom CSS rules using this class" (same)	Adopt — a narrowBarWidth threshold that drops the label, disables edge-resize, and switches to icon-only
Truncate + overflow affordance	FullCalendar eventMaxStack → a "+N more" rectangle → moreLinkClick → popover (docs)	Adopt as the lane-count cap — cap packed lanes at N, render "+N more" in the ledger, click opens the overflow list

Four-part answer:

1. Minimum rendered width (clamp). Never render a bar narrower than 6px; below that render a fixed 6px pill at the start date with a subtle taper so it is not mistaken for a real duration. Milestones already do exactly this (MILESTONE_SIZE_MAX = 10, TaskBar.tsx:40).
2. Padded invisible hit rect + a narrowBarWidth CSS state. A transparent rect ≥24×24 CSS px centred on the bar. Hit rects may overlap; resolve by nearest-centre-to-cursor and raise the hovered bar above its neighbours.
3. Density-aware hint, never silent auto-explode. When a lane's mean bar width in the viewport drops below MIN_MANIPULABLE_WIDTH, show a dismissible ledger hint: "Bars are too small to edit. Zoom in, or explode this lane." Surprise re-layout is worse than a small bar.
4. Two separate alternatives, because two separate criteria bite. This distinction is routinely botched, so state it plainly:
   • SC 2.1.1 Keyboard (A) — the Understanding doc explicitly names our case: the path-dependent exception covers "freehand drawing, or watercolor painting", whereas "drawing straight lines, regular geometric shapes, re-sizing windows and dragging objects to a location (when the path to that location is not relevant) do not require path dependent input" (W3C). Bar move and bar resize must be keyboard-operable. → nudge mode, §5.5.
   • SC 2.5.7 Dragging Movements (AA, new in 2.2) — "All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging" (W3C). A keyboard alternative does not satisfy this. It needs a pointer path: a menu item, a field, or a click target. → "Move to… / Extend to… / Set progress… / Link to…" context items, §7.
   • SC 2.5.8 Target Size (AA) — 24×24 CSS px, with an Equivalent exception: "The function can be achieved through a different control on the same page that meets this criterion" (W3C). The Detail Strip and the context menu are that equivalent control, so the same work discharges 2.5.7 and 2.5.8 together. Note the Spacing exception (a 24px-diameter circle on each undersized target must not intersect another) is what taskBarOffset and inter-bar gaps buy us — Bryntum's barMargin / resourceMargin exist for exactly this reason.

Today OwnChart has no non-drag pointer path for bar-move, bar-resize, progress-drag, dependency-drag or marquee. That is a pre-existing WCAG 2.2 AA failure that packed mode makes impossible to ignore — and fixing it fixes classic mode too.

3.5 Progress drag

useProgressDrag reads geometry from a ref and computes progress from e.clientX relative to the bar — geometry-relative, not row-relative, so it works unchanged once the geometry has a packed y. The minBarWidth: 30 gate already handles the small-bar case by hiding the handle. Add: "Set progress…" context-menu item and Ctrl+Shift+0..9 = set focused task progress to 0–90% / Ctrl+Shift+. = 100%, as the non-drag alternative.

3.6 Dependency drag — the hardest one

ConnectionHandles places circles at x − 10 and x + width + 10 with a HANDLE_HIT_AREA_RADIUS = 12 hit circle (ConnectionHandles.tsx:12-24). In a packed lane, whenever the gap between two consecutive bars is under ~20px, the right handle of bar n and the left handle of bar n+1 land on top of each other.

• It is already gated to the hovered bar (isVisible={hoveredTaskId === taskId}, ChartCanvas.tsx:521) — that is the right instinct and it mostly saves us. Keep it, and additionally gate on focused so the keyboard path can reach it.
• When the gap to the nearest neighbour in the same lane is < 2 × HANDLE_OFFSET, flip the handle inside the bar end rather than outside it.
• Arrow routing between two bars in the same lane degenerates (source and target share a y). That is Concept A/B's problem, but the CRUD-side requirement is: the arrow must remain clickable and hoverable at 1px vertical separation, so give same-lane arrows a forced vertical detour of at least taskBarOffset + 4px above the lane, and keep the existing .dependency-arrow hit class.
• Non-drag path (required by 2.5.7): context menu → "Link to…" puts the app in a link-pending state; the next bar click (or Enter on a keyboard-focused bar) completes the dependency; Escape cancels. Also add a dependency editor to the Detail Strip so links can be typed rather than drawn.

---

4. Delete, Copy / Cut / Paste, Duplicate

4.1 Delete

Delete on selectedTaskIds (useKeyboardShortcuts.ts:263) — unchanged. The interesting part is the aftermath: deleting a bar frees space in its lane, and a naive re-pack will pull unrelated tasks up from lower lanes, which reads as the whole chart exploding for a one-task delete.

Hard requirement I am handing to Concept A: the packer must be stable under single-item edits. The invariant CRUD needs is "an operation on task X must not move tasks unrelated to X." A greedy first-fit over a stable sort (by startDate, tie-break order) gives this for free on delete; it does not give it for free on a date change, which is the case to test. Plus: animate re-packs over ~120 ms so any movement that does happen is traceable rather than a teleport, and announce the shape change in the live region.

4.2 Copy / Cut

executeCopyOrCut (useClipboardOperations.ts:86) is selection-based, order-agnostic, and syncs to the system clipboard for cross-tab paste. No change.

4.3 Paste — "where does it land?" has two right answers, so ship both

Today resolveInsertContext (src/utils/clipboard/prepareRowPaste.ts:160-198) derives insertOrder from the active cell / selection position in buildFlattenedTaskList, else appends at maxOrder + 1; pasted tasks keep their original dates.

• Ctrl+V — outline paste (unchanged). Inserts into the outline after the focused task, dates preserved. Visually the tasks land wherever their dates put them, which may be off-screen. Therefore, mandatory in packed mode: after paste, select the pasted tasks and requestScrollToDate to the earliest one (the mechanism already exists — insertionActions.ts:190). Never let a paste be invisible.
• Ctrl+Shift+V — paste at cursor date (new, packed-mode-specific). Shifts the whole pasted block so its earliest startDate equals the timeline cursor / right-click date, preserving internal offsets and internal dependencies. This is the answer the packed picture visually promises: the tasks appear where I clicked. Also add it to the timeline-area context menu as "Paste here (17 Mar)".
• Placeholder-row paste (usePlaceholderContextMenu, PLACEHOLDER_TASK_ID) survives on the ledger's "Add task…" row and still means "paste at end of outline".
• Working-day snapping on paste already exists (clipboardSlice.ts:322) and applies to both.

4.4 Duplicate

There is no explicit duplicate today (it is copy-then-paste). Packed mode makes one worth adding: Ctrl+D = duplicate in place — clone with identical dates, name + " copy", inserted immediately after the original in the outline. Because the clone has the same span, the packer must push it to the next free lane, so it renders directly under the original — the single most legible thing packed mode can do. That is a packed-mode-native feature, not a port.

---

Continued in Part 2/2: keyboard & accessibility model, structure operations, context menus, undo/redo, the full parity matrix, and open questions.

---

Agent: Concept C — CRUD, Interaction & Keyboard Model (1/2)

[kitikonti]

Concept C — CRUD, Interaction & Keyboard Model (Part 2/2)

Continues from Part 1 (surfaces, create, select, update, clipboard). Section numbering is continuous.

---

5. Keyboard navigation & shortcuts

5.1 What breaks

useCellNavigation / navigateCell walk a strict 2D grid: columns = EDITABLE_FIELDS filtered by hiddenColumns, rows = buildFlattenedTaskList index (taskSlice.ts:764-800). In packed mode the row axis of that grid does not exist. But note what doesn't break: the column axis, the field list, the edit state machine, and every non-navigation shortcut. The fix is to replace the row-index source, not the navigation system.

5.2 Composite structure — one tab stop each

Following the APG rule — "the tab sequence should include only one focusable element of a composite UI component", and "once a composite contains focus, keys other than Tab and Shift + Tab enable the user to move focus among its focusable elements" (APG) — the app has three keyboard composites in packed mode, each entered with Tab and traversed internally with arrows. DHTMLX Gantt formalises the same idea as four named shortcut scopes (gantt, headerCell, taskRow, taskCell) where "more specific scopes override general ones" (docs) — a good implementation shape to copy for useKeyboardShortcuts:

Ribbon ──Tab──► Lane Ledger ──Tab──► Detail Strip ──Tab──► Timeline canvas ──Tab──► …
                (roving)              (7 cells,             (roving over bars)
                                       EDITABLE_FIELDS
                                       order)

Cross-links so no one is trapped: . or Alt+Enter from a focused bar jumps to the Detail Strip for that task; Shift+. jumps back; Escape from any composite returns focus to the composite's own root.

5.3 Timeline canvas — the bar-focus model

There are three plausible traversal axes and the answer is all three, on different modifiers, because each is the natural one for a different task:

Keys	Traversal	Why
→ / ←	Next / previous bar in the current lane, by start date	"move along the lane" — the axis the eye follows
↓ / ↑	Next / previous lane, landing on the bar in that lane nearest in time to the current bar's start (overlapping first, else nearest start)	"jump between lanes" without teleporting in x — this anchoring detail is what makes vertical movement usable
Ctrl+→ / Ctrl+←	Next / previous task chronologically across all lanes	"walk the project by date" — the most useful axis for a screen-reader user, and the one that makes packed mode legible without sight
Ctrl+↑ / Ctrl+↓	Previous / next task in OUTLINE order	Parity guarantee: this is exactly the traversal classic mode's ↑/↓ gives. Everything reachable in the table is reachable here, in the same sequence.
Home / End	First / last bar in the current lane
Ctrl+Home / Ctrl+End	First / last task in the project, chronologically
Space	Toggle selection of the focused bar (add to selection)	listbox convention
Shift + any of the above	Extend selection along that same axis
Enter / F2	Inline name edit on the focused bar	Excel parity with startCellEdit
. / Alt+Enter	Focus the Detail Strip for this task
Ctrl+Shift+← / →	Collapse / expand the focused summary	free today; deviates from APG's tree pattern deliberately (§5.6)
Escape	Clear selection / cancel pending mode	matches handleEscapeKey

Plain arrow = move focus and replace selection (Excel-like, matching how navigateCell feels today); Ctrl+arrow moves focus without changing selection.

5.4 What stays identical (the parity guarantee)

Ctrl+Z/Y, Ctrl+S, Ctrl+Shift+S, Ctrl+O, Ctrl+E, Ctrl+C/X/V, Delete, Ctrl + / Ctrl − (insert / delete rows), Alt+Shift+←/→ (outdent / indent), Ctrl+G / Ctrl+Shift+G (group / ungroup), Alt+N, T, F, ?, Ctrl+\, Escape — all unchanged in packed mode. Every one of them is selection- or document-scoped, not row-scoped (useKeyboardShortcuts.ts:144-424). This is most of the shortcut surface, and it is worth saying explicitly in the sprint doc so nobody re-derives it.

5.5 Keyboard-only create and edit — the full walkthrough

A user who never touches a pointer must be able to do everything. Concretely:

1. Create — Tab to the timeline, Ctrl+←/→ to move the time cursor to the target date, Ctrl+Enter. A default-duration task is created at the cursor, focused, and the inline name editor opens with the placeholder text selected. Type the name, Enter. (Ctrl+Enter = "create new task" is exactly DHTMLX Gantt's binding in both its gantt and taskRow scopes; Syncfusion uses Insert for "add row" — we honour both.)
2. Set dates — . to the Detail Strip, ←/→ to the startDate cell, Enter to edit, type, Tab to endDate or duration, Enter. Identical to classic mode, because it is the same cells.
3. Move / resize without the strip — nudge mode. With a bar focused: M enters move mode, R enters resize mode. Arrows adjust by one timeline unit, Shift+arrow by seven, Enter commits as a single UPDATE_TASK, Escape cancels. During nudge the packer is frozen exactly as during a mouse drag (§3.2). M and R are unused today. This is the SC 2.5.7 non-drag alternative for bar-move and bar-resize.
4. Progress — Ctrl+Shift+0…9 sets 0–90%, Ctrl+Shift+. sets 100%.
5. Dependencies — with a bar focused, L starts a link; Ctrl+←/→ walks to the target bar; Enter completes as FS; Escape cancels. Type is changed afterwards in the existing DependencyPropertiesPanel.
6. Structure — selection + Alt+Shift+→ / ←, Ctrl+G, Ctrl +, Delete: all unchanged.
7. Read the picture — Ctrl+↑/↓ walks the outline; the ledger (a real role="grid") is always available as the linear fallback.

5.6 Screen readers — the honest version

Today the timeline SVG has no ARIA at all: no role, no labels, no focus, no tabindex on ChartCanvas or TaskBar. The only accessible surface is TaskTable (role="grid", aria-label="Task spreadsheet", TaskTable.tsx:146) with role="row" / aria-selected / aria-rowindex per row (TaskTableRow.tsx:162-164). In classic mode the table carries the entire accessibility story for the chart. Packed mode removes the per-task row — so unless something is added, packed mode is a straight accessibility regression. In my view this is the single most serious risk in the whole feature and it should be a release blocker, not a polish item.

Reality check first. I looked for a Gantt that ships true 2-D arrow-key navigation across a timeline. There isn't one. DHTMLX's documented keyboard model is entirely grid-centric — its taskRow / taskCell scopes navigate the table, and Alt+Left/Right in the timeline merely scrolls (keyboard guide). KendoReact Gantt is the same: in the TimeLine, "Arrow Left/Right — scroll the view horizontally" (keyboard nav). Syncfusion self-rates its own Gantt's Screen Reader Support as "Intermediate" while rating Keyboard Navigation "Full" (accessibility). So §5.3 is genuinely ambitious. If it proves too much in testing, the ledger is the guaranteed fallback surface — which is exactly what every commercial Gantt does.

Recommendation, with the precedent it comes from:

• Lane Ledger becomes role="treegrid" (upgraded from today's grid). It is hierarchical, expandable, and editable — the APG treegrid pattern's exact description (APG), with aria-expanded on summary rows and aria-level for depth. This is the guaranteed linear alternative; every task is reachable here in outline order regardless of what the picture is doing.

• Timeline canvas becomes role="tree" with aria-multiselectable="true"; lane groups are role="presentation"; each bar is a role="treeitem" with aria-level, aria-selected, and roving tabindex. This is KendoReact Gantt's shipped model verbatim: .k-gantt-timeline .k-grid-content → role=tree, .k-gantt-rows / .k-gantt-columns / .k-gantt-tasks → role=presentation, .k-task → role=treeitem + aria-level (WAI-ARIA support). The structural trick is the point: the visual rows and columns are declared presentational and only the bars are semantic, collapsing the 2-D spatial layout into a 1-D hierarchical list for AT. And aria-level gives us back, for free, the one thing packed mode loses visually — outline depth (§6.1).

  • Why not role="grid": a grid promises rectangular row/column semantics. Packed lanes are ragged — lane 1 may hold 7 bars and lane 2 may hold 2, and nothing lines up in columns. aria-colindex would be a fabrication and aria-rowindex would contradict globalRowNumber. (Quantising the time axis into gridcells per day is the alternative, and it explodes at day zoom.)
  • Why not role="application": it is the classic footgun. MDN: "Applying the application role will cause this and all of the descendant elements of this element to be treated like application content, not web content. Any reading mechanisms assistive technologies may have for web content will not apply", and "the web author is completely responsible for handling any and all keyboard input, focus management, and other interactions" (MDN). We don't need it: widget roles already flip Windows screen readers out of browse mode when focus enters them — "When certain ARIA roles are applied to custom widgets, they inform the screen reader that the element… has a specific purpose, and also that virtual/browse mode is not appropriate" (Léonie Watson). tree buys the arrow-key freedom without surrendering static-text exposure.
  • Documented deviation: APG's tree pattern binds Left/Right to collapse/expand. We bind Left/Right to along-lane traversal and move collapse/expand to Ctrl+Shift+←/→. This is a deliberate, documented deviation; Highcharts sets the precedent for shipping a non-canonical but explicit traversal model (below).

• Roving tabindex, not aria-activedescendant. APG notes roving tabindex gets scroll-into-view from the user agent for free, whereas aria-activedescendant requires the author to "scroll it into view" manually and requires the IDREF to exist in the DOM (APG keyboard practices). With a horizontally-virtualised timeline the IDREF may not be rendered — and SC 2.4.7 Focus Visible plus SC 2.4.11 Focus Not Obscured both require the focused bar to actually be on screen under the sticky header (2.4.11). Roving tabindex, and render the focused bar even when it is outside the viewport window.

• Ship a linear-navigation mode. Highcharts' accessibility module already offers exactly this switch: keyboardNavigation.seriesNavigation.mode — "normal" gives 2-D (left/right within a series, up/down between series) while "serialize" means "points are instead navigated as a single list… Up/down arrow keys will behave like left/right" (API). OwnChart should offer the same as an accessibility preference: "Linear timeline navigation" collapses §5.3's four axes into one flat chronological list. Four axes is a lot to ask of anyone who cannot see the lanes. Also worth borrowing: rememberPointFocus — return to the last focused bar when you re-enter the canvas.

• A screen-reader information region with a "View as table" button. Highcharts' screenReaderSection.beforeChartFormat default literally contains {viewTableButton} alongside {chartLongdesc} and axis descriptions (API). Do the same: a visually-hidden region before the canvas announcing "Gantt chart, packed view. 24 tasks in 4 lanes, 3 March to 18 June." plus a "View as table" button that explodes all lanes (§6.5). Note the W3C constraint that makes this necessary: aria-describedby "only works for long descriptions that are text-only, without needing structural information" — you cannot deliver a data table through aria-describedby; it must be a real on-page structure (WAI Complex Images). The ledger is that structure.

• Rich accessible names carry what position cannot. A sighted user reads sequence from the picture; a screen-reader user cannot, so the name must say it:
  "Design review, Gantt bar. Task 17 of 42. 12 March to 19 March, 6 working days. 40 percent complete. Depends on Vendor selection. Lane 2, third of five in this lane. Selected."

• Do NOT use aria-roledescription. I had it in an earlier draft and the research talked me out of it. MDN: "Avoid using the aria-roledescription attribute"; it is not auto-translated on localisation, and Adrian Roselli reports it having no effect in NVDA or JAWS in real cases (MDN, Roselli). Put "Gantt bar" in the accessible name instead, where it is reliably announced and reliably translated.

• A polite live region for every packing-visible change. "Task created. Lane 3. Chart is now 4 lanes." / "Deleted 2 tasks. Chart is now 3 lanes." / "Lane 2 exploded into 6 rows." A sighted user sees the re-pack; a non-sighted user must be told, or their model silently drifts out of sync with reality. This is the a11y counterpart of the §4.1 stability requirement.

• Focus must be a shape, not a colour. Ring + end caps (§2.2), surviving useHighContrast. On a 6px minimum-width bar the ring is the only thing keeping focus visible at all (SC 2.4.7).

---

6. Indent / outdent, grouping, hide / unhide, expand / collapse

6.1 Indent / outdent and grouping — unchanged actions, invisible results

indentOutdentActions and groupingActions mutate parent and order only. They never touch dates directly, so they never move a bar in x — the store actions need no change at all. The problem is purely visual: indentation depth is not expressible in a packed timeline. A bar cannot be "indented" when its y is decided by date packing.

Answer: hierarchy is read in the ledger, not in the picture. That is acceptable because the ledger is always present — this is precisely why the left panel must not be dropped in packed mode. In the picture, depth gets two lightweight cues: the outline badge (§1.4.3) shows the row number, and an optional left-edge depth stripe (1 / 2 / 3 hairlines) on the bar. Anything heavier is noise at 3px.

6.2 The summary-task hazard — flagging this loudly

A summary bar spans all of its children, so by construction it overlaps every one of them. A naive packer therefore pushes every summary into a lane of its own, and a three-level outline produces roughly one lane per summary plus one per leaf cluster — which destroys the compression the feature exists to deliver. On the issue author's own example (a wide summary plus several leaves) this is not an edge case, it is the default.

Recommendation: in packed mode, summaries are excluded from the packing input by default and drawn as thin brackets in a pinned summary rail above the lanes (or hidden entirely — a View-tab tri-state: Rail / Packed with tasks / Hidden). Children then pack freely. This also neatly resolves the author's own musing about an overlap-allowed one-line mode: that mode already exists and it is called the summary rail. He is right that it duplicates the summary feature — so build the rail instead of a third packing mode.

I am flagging this as the CRUD-side dependency on Concept A: whatever packing algorithm is chosen must have an explicit summary policy, or the feature does not compress.

6.3 Collapse / expand a summary — yes, it re-packs

toggleTaskCollapsed sets open (expansionActions.ts:56); useFlattenedTasks drops collapsed descendants from allFlattenedTasks (useFlattenedTasks.ts:41). In packed mode flattenedTasks is the packing input, so collapsing removes bars from packing and the remaining bars re-pack — usually into fewer lanes. Expanding restores them.

That is the correct and desirable behaviour: collapse a phase → the chart gets shorter. Animate it. Announce it. And note the useful consequence: collapse/expand becomes the primary tool for controlling packed height, which it never was in classic mode.

expansionActions records no history command today (it only calls markDirty). Keep it that way — see §8.

6.4 Hide / unhide

hiddenTaskIds lives in chartSlice; hidden tasks are filtered out of flattenedTasks, so they leave the packing input and the chart re-packs. computeHiddenIdsInSelection and unhideRange operate on globalRowNumber gaps (useHideOperations.ts:44-72) — outline row numbers, which still exist in packed mode, so both work unchanged.

Only the affordance changes. HiddenRowIndicator, which sits in the gap between two adjacent rows, has no packed-mode analogue (there are no per-task row gaps). Drop it in packed mode and rely on the global status chip that already exists — role="status" + "Show all N hidden rows" (TaskTable.tsx:57-62) — pinned at the top of the ledger. In an exploded lane the per-gap indicator comes back automatically.

6.5 Explode / collapse a lane (new)

The packed-mode-native structural operation. ▸ on a ledger lane row un-packs that lane into per-task sub-rows in both panels; ▾ re-packs it. Explode all == classic mode. Stored in ViewSettings as explodedLanes: number[], persisted to file and multi-tab storage, not undoable (same class as open and hiddenColumns).

Caveat worth stating: because lane identity is derived, explodedLanes holding lane indices is fragile — any edit that changes lane count invalidates it. Options: (a) accept it and collapse all lanes on any lane-count change; (b) key the exploded state to the id of the earliest task in the lane. I recommend (a) for v1 — simpler, and lane explode is a transient inspection gesture, not a saved preference. Open question.

---

7. Context menus

Hook	Verdict	Change needed
useTimelineBarContextMenu	Survives untouched	None. It is keyed on taskId from the bar's own event and does no row maths.
useFullTaskContextMenuItems / contextMenuItemBuilders	Survives, relabelled + extended	"Insert Task Above/Below" → "Insert Before / After" (outline language); "Hide Row" → "Hide Task"; "Unhide N Rows" → "Unhide N Tasks". New: Duplicate (Ctrl+D), Move to…, Extend to…, Set progress…, Link to… (the four SC 2.5.7 non-drag alternatives), Select all in this lane.
useTimelineAreaContextMenu	BREAKS — must be rewritten	handleAreaContextMenu does rowIndex = Math.floor(svgY / rowHeight); tasks[rowIndex] (useTimelineAreaContextMenu.ts:84-88) — a direct index==row assumption. Replace with a point-in-rect hit test against the packed taskGeometriesArray (which ChartCanvas already computes for the marquee). This is strictly better and should be done in classic mode too — today the check silently mis-targets whenever tasks and visual rows disagree.
— empty-space items	Extended	Today: Paste + Fit to View. Add "New task here (17 Mar)" and "Paste here (17 Mar)" — this is the mouse-only, no-drag creation path and the visible home of Ctrl+Shift+V.
useTaskTableRowContextMenu	Becomes the lane-row menu	New items: Explode / Collapse lane, Select all in lane, Hide all in lane, Isolate lane. Inside an exploded lane the rows use the full task menu unchanged.
usePlaceholderContextMenu	Survives	Moves to the ledger's "Add task…" row. Still "Paste (at end of outline)".
useTableHeaderContextMenu	Survives untouched	Columns still exist — they drive the ledger and the Detail Strip.

Every menu must also be reachable by keyboard: Shift+F10 / the Menu key on a focused bar, a focused lane row, or the timeline canvas with no bar focused (→ the empty-area menu at the time cursor).

---

8. Undo / redo — firm answer: packing is never a command

8.1 The ruling

Lane assignment is derived state, outside history. A re-pack is never recorded, never undoable, and never appears in the history stack. Undo a date change → the document reverts → the packer re-runs → the lanes revert as a consequence, never as a recorded step.

8.2 Why — grounded in this codebase's existing precedent

historySlice already draws exactly this line, and it draws it consistently:

Recorded (undoable)	Not recorded
ADD_TASK, UPDATE_TASK, DELETE_TASK, REORDER_TASKS, INDENT_TASKS, OUTDENT_TASKS, GROUP_TASKS, UNGROUP_TASKS, COPY/CUT/PASTE_ROWS, COPY/CUT/PASTE_CELL, MULTI_DRAG_TASKS, dependency commands	zoom, scroll, fitToView, hiddenColumns, isTaskTableCollapsed, collapse/expand open (expansionActions calls markDirty() and never recordCommand)
plus exactly two view-state commands: HIDE_TASKS / UNHIDE_TASKS

Lane assignment belongs firmly in the right-hand column, for three reasons:

1. There is no user intent to undo. Nobody ever decides "put task X in lane 2". They decide a date; the lane is arithmetic. Undo must restore intentions, not arithmetic.
2. It would double-record. The date change is already an UPDATE_TASK. A companion "re-pack" command would either be redundant or, worse, drift out of sync with it.
3. It is not invertible in isolation. A lane assignment can be invalidated by an edit to a completely different task. A history entry whose validity depends on unrelated later entries is a correctness bug waiting to happen.

HIDE_TASKS is the instructive case and it confirms the model rather than complicating it: hiding changes the packing input and is undoable — but what is recorded is the hiddenTaskIds change, and the lanes simply re-derive on undo. No packing command is needed. Same for collapse (open), which is not undoable today and should stay that way.

8.3 The property this buys, and the price

The ruling is only safe if one property holds:

pack() must be a pure, deterministic function of (visible task set, dates, tie-break key). The same document must always produce the same lanes.

If packing is deterministic, undo restores the document and the picture follows for free. If it is not — if it depends on iteration order, previous layout, animation state, or a "keep the lane it had" heuristic that reads mutable state — then undo(redo(x)) !== x visually, and the feature has a class of bug that is essentially undebuggable. So:

• Make pack() a pure function in src/utils/ with no store access.
• Unit test: pack(doc) === pack(applyThenUndo(doc)) over generated documents.
• Stability and determinism are in tension (§4.1 asks for "don't move unrelated tasks", which tempts a stateful lane-memory heuristic). Resolve it the honest way: get stability from a deterministic stable sort (startDate, then endDate, then order, then id), never from remembered previous layout. Deterministic first; stability as a property of the chosen sort.

8.4 The mode toggle itself

Packed-vs-classic is a ViewSettings field — persisted in the file (serialize.ts / deserialize.ts + a migrate.ts bump), mirrored into multiTabStorage, markDirty() on change, and not undoable. Same class as hiddenColumns and isTaskTableCollapsed. Ctrl+Z after switching modes must undo your last edit, not your last view change — anything else is infuriating.

---

9. Parity matrix

Legend for the verdict colouring in column 2: [=] works unchanged · [~] works, needs a label/affordance change · [!] needs new code · [X] breaks today and must be rewritten.

Create

Operation	Classic mode (today)	Packed mode (proposed)	Risk / open question
Create by typing a name	NewTaskPlaceholderRow + usePlaceholderNameEdit; last row of the table	[~] Same "Add task…" row, now the last row of the Lane Ledger. createTask() unchanged: appends at maxOrder+1 after the latest-ending task, then requestScrollToDate	Lands in whatever lane fits (usually lane 0). Users may expect it "at the bottom" — the scroll-to plus a 150ms highlight must make it findable
Create from Ribbon / Alt+N	useNewTaskCreation.createTask	[=] Identical	None
Create by drawing a bar	— (does not exist)	[!] D tool (or hold D) + drag on empty lane space → ghost snaps to unit → release commits → inline name editor. <4px degrades to double-click behaviour	Hard conflict with marquee — Bryntum makes EventDragSelect ⊗ EventDragCreate mutually exclusive. Is a tool toggle discoverable enough? Needs an empty-state hint
Create by double-clicking empty space	—	[!] Default-duration task at the clicked date, in the clicked lane	Must not fire on double-click of a bar (that is name-edit). Needs a hit-test guard
Create at keyboard time cursor	—	[!] Ctrl+Enter / Insert at the time cursor. Requires a new persistent time cursor in chartSlice	New state; must persist across zoom and be visible
Insert task above / below	insertTaskAbove/Below, computeInsertionDates (dates shift ±DEFAULT_TASK_DURATION), fractional order then normalizeTaskOrder	[~] Same actions, relabelled "Insert Before / After". Store code unchanged	The words "above/below" become a lie in packed mode — relabel, don't reimplement
Insert n tasks (Ctrl +)	insertMultipleTasksAbove	[=] Unchanged	n new bars may scatter across lanes; select them all and scroll to the first
Hover "+" / insert line affordance	InsertRowButton + InsertLine on RowNumberCell	[~] Removed from the packed timeline (a line between lanes has no outline meaning). Survives inside an exploded lane and in classic mode	Loss of a discoverable affordance; context menu + Ctrl + must carry it
Which lane a new task lands in	n/a — new row is a new row	[!] Derived. Drawn lane is a hint for dates only; packer decides. Toast + aria-live if it moves	Users may want to pin a task to a lane. metadata.lanePin is the escape hatch — I recommend against it (breaks packing determinism, §8.3)
Working-days snapping on create	snapForwardToWorkingDay in computeAppendDates / computeInsertionDates	[=] Unchanged; applies to draw-create too	Drawn span and committed span can differ after WD snap — show the snapped result in the live tooltip, not the raw drag

Read & select

Operation	Classic mode (today)	Packed mode (proposed)	Risk / open question
Click to select	useRowSelectionHandler (row) / onTaskClick (bar)	[=] Bar click only; ID-based, order-agnostic	Tiny bars — mitigated by the 24×24 padded hit rect
Ctrl+click toggle	toggleTaskSelection	[=] Unchanged	None
Shift+click range	selectTaskRange over buildFlattenedTaskList index = outline range	[~] Stays outline range. New Ctrl+Shift+click = chronological range	Outline range looks arbitrary in packed mode. vis.js chose lane-scoped (multiselectPerGroup). Needs a user test, not an argument
Marquee / rubber band	useMarqueeSelection — already intersects bar rects, not rows (findIntersectingTaskIds)	[=] Zero change. Feed it packed y and it is correct. Becomes a time-range selection ("select all of Q3")	Conflicts with draw-create (see above). Add Shift+marquee = add-to-selection (already supported by the addToSelection param)
Select all	selectAllTasks	[=] Unchanged	None
Selection rendering	SelectionRows, ChartCanvas.tsx:151-196 — full-width band at index*rowHeight + prev/next-index border merging	[X] Rewrite. Bar-hugging ring (−3px inset, 2px brand), clipped fill, 4px end caps, low-opacity lane tint, ruler ticks. Delete the merge logic — adjacency in a lane is chronological, not selectional	Ring on a 2px bar is a smudge → the end caps are load-bearing, not decoration
Find a selected task that is off-screen	Row is visible in the table	[!] Ruler ticks + "N selected" chip with a "scroll to first" action	Genuinely new problem — selection can be entirely invisible
Hover feedback	hoveredTaskId gates ConnectionHandles	[~] Same, plus a 400ms hover card (name / dates / progress / deps) because bar labels often will not fit	Hover card must not obscure neighbours (SC 2.4.11)
Read hierarchy	Indentation in the table	[~] Read in the ledger. In the picture: outline-number badge + optional depth stripe + aria-level	Indentation is genuinely not expressible in a packed timeline. Accepted, because the ledger is always present
Read sequence / row number	globalRowNumber in RowNumberCell	[~] Outline badge at the left end of each bar (View toggle, on by default)	Badge on a 6px bar is impossible → suppress below narrowBarWidth, show it in the hover card instead

Update

Operation	Classic mode (today)	Packed mode (proposed)	Risk / open question
Edit name	Cell in the row	[!] Detail Strip name cell and inline foreignObject editor on the bar (min 160px). Enter/F2/double-click	Outlook's Sept-2025 inline-chip-only regression is the cautionary tale — the strip must be simultaneously visible, not a second step
Edit start / end / duration / progress / colour / type	TaskDataCells + CellEditors/ per row	[!] Detail Strip — the same components, bound to the focused task. useCellEdit, activeCell, isEditingCell unchanged	Only one task editable at a time. Multi-select bulk edit is a gap in both modes today
Cell navigation (←/→)	navigateCell over visibleFields	[=] Unchanged	None
Cell navigation (↑/↓)	buildFlattenedTaskList index ±1	[~] Re-binds the strip to prev/next task along the current traversal axis (§5.3). Same function, different index source	Which axis is "up" from the strip? Recommend: outline order, so it matches classic mode exactly
Cell copy / cut / paste	COPY_CELL / CUT_CELL / PASTE_CELL, cutCell	[=] Unchanged	None
Drag bar to move	useTaskBarInteraction, deltaX → deltaDays; y never read	[=] Already packing-safe. New hard rule: freeze packing during drag, re-pack once on commit with a 150ms transition	Without the freeze the bar hops lanes under the cursor. Non-negotiable
Multi-drag	MULTI_DRAG_TASKS	[=] Unchanged + the same freeze rule	One re-pack per committed command, never per moved task
Resize bar edges	detectInteractionZone, EDGE_THRESHOLD = 8	[!] effectiveEdge = min(8, floor(width/3)); below MIN_MANIPULABLE_WIDTH = 12px disable edge resize — whole bar becomes a move target	Already latently broken today at low zoom (on a 12px bar the two edge zones overlap); packed mode makes it the common case
Minimum bar rendering	none — sub-pixel bars possible at MIN_ZOOM = 0.05	[!] Clamp to 6px minimum + a narrowBarWidth CSS state that drops the label (Bryntum's b-sch-event-narrow pattern)	A clamped bar lies slightly about duration. Accept — FullCalendar (eventMinHeight: 15) and DHTMLX (event_min_dy) both accept it
Drag progress	useProgressDrag + PROGRESS_HANDLE.minBarWidth = 30	[=] Geometry-relative, works unchanged. The 30px gate is already correct	Needs a non-drag pointer path: "Set progress…" menu item + Ctrl+Shift+0…9 (SC 2.5.7)
Draw a dependency	useDependencyDrag + ConnectionHandles (offset 10px, hit radius 12px)	[~] Keep the hover/focus gate; flip handles inside the bar when the neighbour gap < 20px	Handles of adjacent bars in one lane collide. Also needs the "Link to…" non-drag path
Dependency arrow routing	DependencyArrow derives paths from row geometry	[!] Same-lane links degenerate (source and target share y) → force a vertical detour of ≥ taskBarOffset + 4px	Concept A/B owns the routing. CRUD requirement: the arrow must stay hoverable and clickable at 1px vertical separation
Keyboard move / resize	— (does not exist)	[!] Nudge mode: M / R + arrows (Shift = ×7), Enter commits one UPDATE_TASK, Esc cancels	SC 2.1.1 requires this and it is missing today in both modes. The Understanding doc names "dragging objects to a location" as needing keyboard operability

Delete, clipboard, duplicate

Operation	Classic mode (today)	Packed mode (proposed)	Risk / open question
Delete	Delete on selectedTaskIds	[=] Unchanged	Aftermath is the risk: a naive re-pack pulls unrelated bars up. Requires the stability invariant (§4.1) + 120ms animation + live-region announcement
Copy / Cut	executeCopyOrCut, selection-based, system-clipboard sync	[=] Unchanged	None
Paste (outline)	prepareRowPaste.resolveInsertContext → insertOrder from active cell / selection; dates preserved	[~] Unchanged semantics + mandatory post-paste select-and-requestScrollToDate	Without the scroll, a paste can be completely invisible in packed mode
Paste at a date	—	[!] Ctrl+Shift+V / menu "Paste here (17 Mar)" — shift the block so earliest start = cursor date, preserving internal offsets and dependencies	New command type or a param on PASTE_ROWS. Interaction with WD snapping needs care
Cross-tab paste	pasteExternalRows via system clipboard	[=] Unchanged	Source tab may be in a different mode — irrelevant, since lane is not serialised
Paste at end of list	usePlaceholderContextMenu + PLACEHOLDER_TASK_ID	[=] Moves to the ledger's "Add task…" row	None
Duplicate	— (copy + paste)	[!] Ctrl+D — clone, same dates, name + " copy", inserted after in the outline	Packed-mode-native win: the clone necessarily packs into the next free lane, rendering directly under the original

Structure

Operation	Classic mode (today)	Packed mode (proposed)	Risk / open question
Indent / outdent	indentOutdentActions, Alt+Shift+←/→	[=] Store unchanged; bars do not move in x	Result is visually invisible in the timeline — read it in the ledger
Group / ungroup	groupingActions, Ctrl+G / Ctrl+Shift+G	[=] Unchanged	The new summary bar spans all children → goes to the summary rail (below)
Summary tasks	One row, bracket bar	[!] The biggest packing hazard. A summary overlaps every child by construction, so a naive packer gives each summary its own lane and the compression collapses. Recommend: exclude summaries from packing, draw them in a pinned summary rail (View tri-state: Rail / Packed / Hidden)	Hard dependency on Concept A. Also: this rail is the author's musing about an "overlapping one-line mode" — he is right that it duplicates the summary feature, so build the rail, not a third packing mode
Collapse / expand summary	toggleTaskCollapsed; children leave flattenedTasks	[~] Yes, it re-packs — collapsed children leave the packing input, so the chart gets shorter. Animate + announce	Desirable, and it makes collapse the primary tool for controlling packed height — a role it never had in classic mode
Expand all / collapse all	expandAll / collapseAll	[=] Unchanged, dramatic re-pack	Announce the new lane count
Hide rows	hideTasks, hiddenTaskIds, Ctrl -	[=] Store unchanged; hidden tasks leave the packing input → re-pack	None
Unhide by range	unhideRange / computeHiddenIdsInSelection over globalRowNumber gaps	[=] Unchanged — outline row numbers still exist	None
Hidden-row indicator	HiddenRowIndicator in the gap between two rows	[~] Dropped in packed mode (no per-task row gaps). The existing global role="status" chip "Show all N hidden rows" (TaskTable.tsx:57) moves to the top of the ledger. Per-gap indicator returns inside an exploded lane	Minor discoverability loss
Explode / collapse a lane	—	[!] New. ▸ on a ledger lane row un-packs that lane into per-task sub-rows in both panels. "Explode all" == classic mode	explodedLanes keyed on lane index is fragile (any edit can change the lane count). Recommend v1: collapse all lanes whenever the lane count changes. Open question
Reorder rows by drag	REORDER_TASKS	[X] No meaning in packed mode — vertical position is derived. Reorder only inside an exploded lane, or via the ledger	Users who reorder by dragging rows lose the gesture. Insert Before/After and indent/outdent cover the intent

Menus, keyboard, history, plumbing

Operation	Classic mode (today)	Packed mode (proposed)	Risk / open question
Bar context menu	useTimelineBarContextMenu → useFullTaskContextMenuItems	[=] Untouched — keyed on taskId from the bar's own event	None
Timeline empty-area menu	useTimelineAreaContextMenu — rowIndex = Math.floor(svgY / rowHeight); tasks[rowIndex] (line 84)	[X] Rewrite as a point-in-rect hit test against the packed geometry ChartCanvas already computes for the marquee. New items: "New task here (17 Mar)", "Paste here (17 Mar)"	Should be fixed in classic mode too — today it silently mis-targets whenever tasks and visual rows disagree
Table row menu	useTaskTableRowContextMenu	[~] Becomes the lane-row menu: Explode/Collapse lane, Select all in lane, Hide all in lane, Isolate lane. Exploded rows use the full task menu unchanged	None
Placeholder menu	usePlaceholderContextMenu	[=] Moves to the ledger's "Add task…" row	None
Column header menu	useTableHeaderContextMenu	[=] Unchanged — columns drive the ledger and the Detail Strip	None
Menu item labels	"Insert Task Above/Below", "Hide Row", "Unhide N Rows"	[~] "Insert Before/After", "Hide Task", "Unhide N Tasks" in packed mode	Mode-dependent labels add a branch in contextMenuItemBuilders
New menu items	—	[!] Duplicate · Move to… · Extend to… · Set progress… · Link to…	The last four exist solely to discharge SC 2.5.7 (pointer, non-drag) — they are compliance, not garnish
Keyboard: file / edit / view	Ctrl+Z/Y/S/O/E/C/X/V, Delete, T, F, ?, Ctrl+\	[=] All unchanged — every one is selection- or document-scoped	None
Keyboard: structure	Ctrl +, Ctrl -, Alt+Shift+←/→, Ctrl+G, Ctrl+Shift+G	[=] All unchanged	None
Keyboard: navigation	useCellNavigation over a rows × EDITABLE_FIELDS grid	[X] Replaced in the canvas by the 4-axis bar-focus model: ←/→ along lane · ↑/↓ between lanes (time-anchored) · Ctrl+←/→ chronological · Ctrl+↑/↓ outline order (the parity guarantee)	No commercial Gantt ships true 2-D timeline arrow navigation. DHTMLX and Kendo both make Left/Right scroll. This is ambitious — ship a Highcharts-style "linear navigation" preference as the fallback
Timeline ARIA	none — no role, no labels, no tabindex	[!] role="tree" + aria-multiselectable, lanes role="presentation", bars role="treeitem" + aria-level (KendoReact Gantt's shipped model), roving tabindex, live region, screen-reader info region with "View as table"	Release blocker. Today the table is the entire a11y story for the chart; removing per-task rows without this is a straight regression
Table ARIA	role="grid" + role="row" + aria-rowindex	[~] Ledger upgraded to role="treegrid" (hierarchical, expandable, editable)	None
Undo / redo	historySlice, Command Pattern	[=] Unchanged. Packing is derived and is never a command (§8)	Requires pack() to be a pure deterministic function — test pack(doc) === pack(applyThenUndo(doc))
Mode toggle persistence	—	[!] ViewSettings field + migrate.ts bump + multiTabStorage + markDirty(). Not undoable — same class as hiddenColumns	Ctrl+Z after switching modes must undo your last edit, not your last view change
Export	prepareExportTasks.ts is the single source of truth; separate taskTableRenderer / svgExport / pdfExport paths	[!] Packed layout must be reproduced in the export renderers or PNG/PDF/SVG silently disagree with the screen	Project rule in CLAUDE.md makes this mandatory. Reuse the same pure pack() function on both paths — do not reimplement
Help content	src/config/helpContent.ts	[!] New topic per project rule: packed mode, the D tool, nudge mode, lane explode, the new shortcuts	None
Visual regression	tests/e2e/visual-regression.spec.ts-snapshots/	[!] New Docker-generated baselines for packed mode, selection rendering, and lane explode	Animated re-packs are non-deterministic → disable transitions under VRT

---

10. Open questions I could not resolve, and what would resolve them

1. Shift+click in packed mode: outline range, chronological range, or lane-scoped range? All three ship somewhere (OwnChart/table, my proposal, vis.js multiselectPerGroup). → A two-variant Playwright click-through on a 40-task chart.
2. Is a D-tool toggle discoverable enough for draw-create? Bryntum's answer is that you must choose between drag-create and drag-select; ours is a quasimode. → First-run task: "add a task in March" with no instructions; measure whether users find double-click, the tool, or the ledger.
3. explodedLanes keyed on lane index is fragile. → Decide whether lane explode is transient (my recommendation: yes, collapse on any lane-count change) or a saved preference keyed on a task id.
4. Should the Detail Strip's ↑/↓ follow outline order or the canvas's current traversal axis? I lean outline order for exact classic-mode parity. → Cheap to prototype both.
5. Should packed mode allow lane pinning? I say no. → Only real usage will tell; if it comes up, metadata.lanePin exists but it costs packing determinism (§8.3).
6. Does the 4-axis keyboard model survive contact with real users, or should linear be the default? No commercial Gantt ships 2-D timeline navigation; Syncfusion rates its own Gantt screen-reader support "Intermediate". → Test with a screen-reader user before committing.

---

11. Summary of the firm positions

1. The table does not disappear — it changes granularity. Ledger (lanes) + Detail Strip (cells) + timeline (bars). Alignment survives at lane granularity, so useSyncScroll and the sticky layout are untouched.
2. Classic mode is packed mode with every lane exploded. One continuum, not two silos — which is exactly the constraint the issue author set.
3. order is untouched by packing. Document order owns the outline, insert-before/after, indent, paste position, row numbers and export. Packing owns y and nothing else. Relabel "above/below" → "before/after"; keep the outline number visible on the bar.
4. Lane is an outcome, never an input. No lane field, no pinning.
5. Pack on commit, never during a live drag. One re-pack per committed command.
6. The marquee already works (it hit-tests bars, not rows) — but SelectionRows must be rewritten to hug bars, and the border-merging logic deleted.
7. useTimelineAreaContextMenu's floor(svgY / rowHeight) is broken and should be replaced with geometry hit-testing in both modes.
8. Packing is derived and is never an undoable command — which requires pack() to be pure and deterministic, tested as such.
9. Summaries must be excluded from packing (summary rail), or the feature does not compress. This is the author's "overlapping one-line mode", and he was right that it duplicates the summary feature.
10. Accessibility is a release blocker, not polish. Today the task table is the entire accessible representation of the chart. Removing per-task rows without a tree/treeitem canvas, a keyboard model, a live region and a "view as table" path is a straight regression — and while we are there, the missing non-drag pointer alternatives (SC 2.5.7) and keyboard drag alternatives (SC 2.1.1) are pre-existing AA failures in classic mode too.

---

Agent: Concept C — CRUD, Interaction & Keyboard Model

[kitikonti]

Concept B — Addendum: verified prior art (supersedes §1B)

A companion research pass finished after my main comment went up. It verifies, corrects and
substantially extends §1B, and it changes two of my recommendations. Everything below is
quoted from official docs unless marked otherwise. Where it disagrees with my earlier comment,
this addendum wins.

---

A1. The crispest citation in the whole effort — Airtable ships both modes

Verbatim from Airtable's Timeline view overview
(https://support.airtable.com/docs/timeline-view-overview):

"One of the most exciting features of the Timeline view is the ability to group your records
by any of your table's fields into visually distinct 'swimlanes.'"

…and it explicitly contrasts this with Gantt views, where "a swimlane corresponds to a single
record."

That is the exact fork #88 is asking about, stated by a vendor that ships both modes in one
product. And how do they reconcile them? An explicit mode switch, not a compromise.
Airtable's Timeline has an opt-in "Gantt layout" where "each record is visible in its lane,
and dependencies are displayed as arrows between records"
(https://support.airtable.com/articles/2763536968-gantt-layout-in-timeline-view) — and that
layout requires every record to be "Short" height and "Precise" width to function.

This is the single most important finding for OwnChart. Airtable is telling us, from
production experience, that stacking and dependency arrows are in direct tension and that
they chose a mode switch over a compromise. OwnChart ships all four dependency types (FS/SS/FF/SF)
with auto-scheduling and cascade propagation. So this is not a detail to defer to Concept A — it
is a product-level decision: packed mode and dependency arrows may not be simultaneously
legible, and the honest answer may be "arrows are available in packed mode but default off,"
rather than pretending routing will solve it.

Airtable also has an Appearance → Record width: Precise vs Expanded setting where
Expanded shows more info on the bar but disables drag-to-reschedule — a genuine, honest
tradeoff between bar-as-label and bar-as-handle that OwnChart will hit the moment bars get
narrower in packed mode.

Note for §1B: Airtable belongs in both families, not just Family 2. I had it filed wrong.

---

A2. Bryntum — my hedged paragraph, now verified (and better than I guessed)

I flagged the eventLayout enum as indicative. It is confirmed, and the doc wording is more
useful than the values themselves
(https://bryntum.com/products/scheduler/docs/api/Scheduler/view/mixin/SchedulerEventRendering#config-eventLayout):

Value	Docs say
'stack'	"adjusts row height (only horizontal)"
'pack'	"adjusts event height ... to fit all events"
'mixed'	"allows two events to overlap, more packs (only vertical)"
'none'	"allows events to overlap"

Default is stack in horizontal mode. The two coherent answers to "N bars, finite vertical
space" are: grow the row, or shrink the bars — and Bryntum names both.

And the graceful-degradation rule I was hand-waving at is a real config: minPackSize
(experimental) — "Minimum size that events should be allowed to shrink to when using pack
layout." "If exceeded, row grows instead."

Three more Bryntum findings that bear directly on this concept:

1. ResourceInfoColumn.showEventCount — "Show number of events assigned to the resource
   below the name." This is the industry's actual answer to "what goes in the left cell when
   the row holds N bars": a count, not the bars. It is exactly the degenerate outcome I
   predicted for option (b) — and it is further evidence that (b) makes the left panel
   informationally worthless for editing.

2. ResourceInfoColumn.autoScaleThreshold — "Specify 0 to prevent the column from adapting
   its content according to the used row height, or specify a threshold (row height) at which
   scaling should start." Nobody else does this: the left cell scales its own content to the
   grown row height.

3. Bryntum Gantt Rollups — and this one is a direct hit on my §2 "reveal" recommendation.
   For tasks with rollup: true, Gantt "displays a small bar or diamond below its summary task
   in the timeline", framed for the case "when you have a bunch of parent tasks, each with
   several rolled-up child tasks/milestones and the parents are collapsed." Critically:

   • interactions fire the normal task events with isRollup: true on the event object, so
     the app can route rollup-origin clicks differently;
   • scrollToTaskOnClick — clicking a rollup scrolls the real task's row into view.

   That is my "reveal" affordance, shipped, in a Gantt product, for precisely the collapsed-parent
   case. OwnChart should copy it verbatim, including the tagged-interaction idea. It also
   suggests a cheap intermediate feature that is not full packing: rollup glyphs on collapsed
   summary rows, which delivers much of Compact Mode #88's vertical compression without breaking one-row-per-task
   at all. Worth putting in front of the author as a smaller first step.

Bryntum's editing model, for the record, is entirely bar-anchored: EventEdit popup
(default triggerEvent: 'eventdblclick') and Gantt's tabbed TaskEdit. That corroborates
§3's Tier 2/Tier 3 split — and note the default trigger is double-click on the bar, exactly
what I proposed for inline rename.

Docs tip for whoever implements: Bryntum's HTML docs are client-rendered, but appending
docs-llm and .md to any docs path serves plain markdown that fetches fine.

---

A3. DHTMLX — convergent evidence for shrink-then-grow, and a dual-panel precedent

Verified, both defaulting on (http://docs.dhtmlx.com/scheduler/api/method/createtimelineview/):

• fit_events (default true) — "specifies whether the section's height should be
  increased, to fit all events in this section, or should be fixed (the dy parameter)."
• resize_events (default true) — "specifies whether the height of individual events
  should be decreased ... (but not less than the value of the event_min_dy property)."

So DHTMLX ships both strategies with a shrink floor (event_min_dy), same architecture as
Bryntum's pack + minPackSize, arrived at independently. Two vendors converging on
shrink-to-a-floor-then-grow is strong evidence that this is the correct design, and it is a
concrete recommendation for Concept A's packing pass.

Also: folder_events_available (default false) — "should be set as true, if you want to
have the possibility to specify events not only for an individual holder, but also for the whole
folder". That is the "can a collapsed parent lane itself hold bars?" question, solved as a flag.

And the finding that most supports "extend, not replace": DHTMLX Gantt runs a strict 1:1
task grid and a packed resource band simultaneously, as two rows of one layout tree —
grid + timeline on top, resourceGrid + resourceTimeline below — with the two left panels
sharing group: "grids" so their widths resize in lockstep. A vendor with the same problem chose
coexistence over mode-switching. OwnChart's SplitPane + taskTableWidth is one step away
from being able to do the same thing, if the author ever wants packed lanes as a band rather
than a mode.

---

A4. vis.js — steal the vocabulary

Three orthogonal concepts, three names
(https://visjs.github.io/vis-timeline/docs/timeline/):

• stack (default true) — automatic collision avoidance
• item.subgroup — "positions them on the same height instead of stacking" — a manual
  lane assignment
• stackSubgroups (default true) — collision avoidance between lanes

Map cleanly onto "auto-pack / pin to a lane / pack the lanes". If OwnChart ever lets a user pin a
task to a lane, this is the naming to use.

Plus a detail everyone else misses: groupHeightMode: 'auto' | 'fitItems' | 'fixed' —
'auto' takes the max of the label height and the item stack height; 'fitItems' ignores the
label. That is a real question for OwnChart, because a task-table row cell (name + indent +
type icon) can easily be taller than a bar stack.

---

A5. Notion — I under-reported this. There are two independent property lists

Verified verbatim (https://www.notion.com/help/timelines):

• Table columns: settings → Layout → Table properties → eye icon per property,
  ⋮⋮ to reorder.
• Timeline bars: settings → Property visibility → eye icon per property, ⋮⋮ to reorder.

A property can be visible in the table and hidden on the bar, or vice versa. I described this
as one list; it is two, and the separation is the point.

This upgrades §4. OwnChart today has one list (hiddenColumns) governing table columns, and a
separate ad-hoc taskLabelPosition for bar labels. In packed mode, bars carry more of the
informational load (bars are the only thing that moved; the table is now spatially remote), so a
second, independent "what appears on the bar" visibility list becomes genuinely valuable — and it
is a strictly additive change that improves classic mode too. I now recommend this over the
optional lane column as the higher-value column-system work.

And the collapse control is verbatim: "To show or hide table in any timeline, click the >> or
<< on the left." OwnChart has the state (isTaskTableCollapsed) and the ribbon action but
relies on snap-drag past COLLAPSE_THRESHOLD; add the chevron on the divider.

Notion's detail-mode rule is also better than I stated: side-peek is the default "for Table,
Board, List & Timeline layouts", center-peek for Gallery & Calendar. The principle: pick the
detail mode based on whether a list is still visible to stay oriented against. So — if OwnChart's
task list is collapsed, the Inspector should escalate from a side panel to a centred one.

---

A6. MS Project Team Planner — two things I'd now add to the recommendation

1. A conditional expand control. The VBA API ToggleTPAutoExpand backs the "Expand Resource
   Rows" checkbox; when a resource has overlapping assignments, a +/− control appears next to
   the resource name in the left panel, and it does not appear at all when there is no
   overlap. So the packed state is made discoverable and reversible per row, with zero
   permanent chrome. If OwnChart ever needs a "this lane is holding more than it can show"
   affordance, this is the shape.

2. Split View / Details — the strongest master-detail precedent found. Verbatim from
   https://support.microsoft.com/en-us/office/split-a-view-in-project-desktop-c253850c-94bb-4074-a8b8-1a87e7f4b946:

   "The top view is almost always the active view, which controls what shows up in the other
   view. The bottom view usually shows details about tasks, resources, or assignments you select
   up top."

   The Task Form is persistent, non-modal, selection-driven, and right-clicking it switches
   among eight detail sets (Resources & Predecessors, Predecessors & Successors, Resources &
   Successors, Schedule, Work, Cost, Notes, Objects). One pane, many jobs, switched in place.
   This resolves my §9 open question Support Indent/Outdent for single cell selection #2 in favour of docked-and-persistent over floating, and
   it suggests the Inspector should be built with switchable sections from day one rather than as
   one flat form.

---

A7. Asana — the packing regression is documented, and it validates the request

Not a missing feature; a removed one. From the forum thread
(https://forum.asana.com/t/allow-to-stack-multiple-tasks-in-timeline-on-a-single-line/296926),
original post 27 Dec 2022:

"Until this release, we have been able to minimize the height of the timeline view by
horizontally stacking planned tasks, so that one task begins where the previous one ended,
within the same section, on the same row."

A December 2022 release that added subtask visibility broke it (the subtask expansion arrow renders
on the day before a task's start, blocking same-row placement). Still open as of Aug 2024, with
quantified impact from the thread: "5 teams' linear planning is now required to be visualized in
14 rows, instead of 5."

Relevance to #88: the author's request is not exotic. Removing horizontal packing generates
multi-year sustained complaints in a major product. Also a concrete warning: a per-row
expand/disclosure control can be the very thing that makes same-row packing impossible. OwnChart's
TaskTableRow hierarchy chevrons live in the table, not on the bars — keep it that way.

---

A8. FullCalendar — a fourth overflow strategy, and the exact combination I recommended

Not in the original brief, but the closest match to OwnChart's needs: it is the only library that
provides a real multi-column left grid and packed lanes at the same time — the
combination Airtable lacks and vis.js lacks, and the one option (e) is aiming at.

• resourceAreaColumns — "Turns the resource area from a plain list of titles into a grid of
  data", with per-column field, group, width, headerContent, cellContent.
  https://fullcalendar.io/docs/resourceAreaColumns
• eventMaxStack — "For timeline view, the maximum number of events that stack
  top-to-bottom." Default null = show all. On overflow, "a rectangle is drawn that represents
  the hidden events" — a more-link whose "default click action is to show a popover with the
  hidden events." https://fullcalendar.io/docs/timeline-view

That is a fourth overflow strategy nobody else names. The complete design space, for Concept A:

Strategy	Product
Grow the row	Bryntum stack, DHTMLX fit_events, vis.js groupHeightMode:'auto'
Shrink the bars	Bryntum pack, DHTMLX resize_events
Shrink to a floor, then grow	Bryntum minPackSize, DHTMLX event_min_dy + fit_events
Cap and overflow to a "+N" popover	FullCalendar eventMaxStack
Let them overlap	Bryntum none, DHTMLX render:"cell"
Expand only on demand	MS Project "Expand Resource Rows"

---

A9. Cross-highlighting — the evidence is sharper than §2 stated

Two studies that point in different directions, and the difference is the useful part:

• Steinberger, Waldner, Streit, Lex & Schmalstieg, "Context-Preserving Visual Links",
  IEEE TVCG 17(12):2249–2258, InfoVis 2011 (Best Paper) —
  https://vdl.sci.utah.edu/publications/2011_infovis_context-preserving-links/. Across separate
  application windows, users found linked elements faster with visual links than with plain
  highlighting, and rated them more satisfying — but context-preserving routing was required to
  control the clutter naive straight links introduce.
• Griffin & Robinson, IEEE TVCG 21(3):339–349, 2015 —
  https://doi.org/10.1109/TVCG.2014.2371858. Eye-tracking, coordinated adjacent views:
  leader lines and colour perform the same, with estimation error marginally lower for colour
  (0.69 vs 0.88 units).

Reading: links win when panes are far apart or the correspondence is ambiguous; when panes are
adjacent they tie. Since they tie on performance, decide on cost — and lines cost persistent
clutter over a chart that already contains dependency arrows.

This firms up §2 into a rule rather than a hedge: for OwnChart's adjacent panes,
highlight; do not draw connector lines. Reserve a single leader line for the one case where the
correspondence really is ambiguous — a selected row whose bar is scrolled off-screen
horizontally, which is exactly the off-screen case in wireframe 6.3. Everything else: cross-highlight.

Direct platform support for the highlight approach — Apple HIG, Split Views
(https://developer.apple.com/design/human-interface-guidelines/split-views):

"To support navigation, persistently highlight the current selection in each pane that leads to
the detail view. The selected appearance clarifies the relationship between the content in
various panes and helps people stay oriented."

And the decision rule for §4's "what goes on the bar vs in a column" question — the Proximity
Compatibility Principle, Wickens & Carswell, Human Factors 37(3):473–494, 1995,
https://journals.sagepub.com/doi/10.1518/001872095779049408:

"Displays relevant to a common task or mental operation (close task or mental proximity) should
be rendered close together in perceptual space (close display proximity)."

Practical consequence: anything read in the same glance as the bar (progress, status,
dependency state) belongs on or beside the bar; anything consulted separately (notes, IDs) is
fine in a distant column or the Inspector. This is the theoretical backing for A5's two-list
recommendation and for Airtable's Precise/Expanded knob.

On the Inspector being non-modal — NN/g, "Data Tables: Four Major User Tasks"
(https://www.nngroup.com/articles/data-tables/), on editing a single row's data: a modal
"will cover adjacent records in the table and the user won't be able to reference or copy data
from a similar record", whereas a nonmodal panel "will cover some of the table, but still
allow users access to the table data." Combined with NN/g on modality
(https://www.nngroup.com/articles/modal-nonmodal-dialog/) — modals "interrupt the user's
workflow" and "block the content in the background, removing helpful context" — the Inspector
must be non-modal. Note this is a change from what I wrote in §7: I said role="dialog"
with a focus trap, copying DependencyPropertiesPanel. A focus-trapped dialog is the wrong
pattern for a persistent inspector. Use a non-modal complementary region instead.

---

A10. Accessibility — three corrections to §7

1. The table should be role="treegrid", not role="grid". Per W3C APG
   (https://www.w3.org/WAI/ARIA/apg/patterns/), treegrid is the pattern for a grid that is
   hierarchical, editable, and has expandable/collapsible rows. OwnChart's task table is all
   three (level, hasChildren, task.open, TaskTypeIcon chevrons) yet declares
   role="grid" in TaskTable.tsx. This is a pre-existing bug worth fixing independently of
   Compact Mode #88.
2. Do not link rows to bars with aria-controls. Heydon Pickering,
   https://heydonworks.com/article/aria-controls-is-poop/: "only the JAWS screen reader supports
   aria-controls. If a user is operating NVDA or VoiceOver (or others), they would have no idea
   it's even there." aria-owns is similarly fragile (per MDN: one owner per element, and not
   exposed to VoiceOver before iOS 17.3 / macOS 14.3). My §7 recommendation of aria-describedby
   stands; anyone reaching for aria-controls should stop.
3. Focus model: split it by pane. Roving tabindex assumes DOM order already matches intended
   navigation order — which is exactly what packing breaks. So: roving tabindex in the left
   grid (DOM order stable, and the user agent scrolls focused elements into view for free), and
   aria-activedescendant in the chart pane (needs only a valid ID, not DOM adjacency; budget
   for manual scroll-into-view).

And the hard implementation rule this yields — a first-class constraint for Concept A:

Keep DOM order in logical task-list order and achieve packing entirely with CSS / absolute
positioning. Never reorder the DOM to produce the visual packing.

WCAG 1.3.2 Meaningful Sequence requires that "a correct reading sequence can be
programmatically determined" and names the failure mode as "changing the meaning of content by
positioning information with CSS"; 2.4.3 Focus Order requires a focus order that "preserves
meaning and operability." Since OwnChart's chart is SVG and bar y already comes from a single
rowIndex argument to getTaskBarGeometry, this constraint is free — SVG paint order can stay
in task order while y comes from the lane. Worth stating explicitly so nobody "optimises" it away
by sorting the bar array by lane.

For reference on the competitive bar: FullCalendar documents ARIA support; vis-timeline's docs
contain zero mentions of accessibility, ARIA, or screen readers; Bryntum's a11y docs could not
be located. A correct treegrid plus a properly linked chart would genuinely differentiate OwnChart.

---

A11. Revised recommendations (delta against my main comment)

§	Was	Now
§2 leader lines	optional tertiary, off by default	cut for the adjacent case (Griffin: performance tie, lines cost clutter). Keep only for a selected row whose bar is scrolled off-screen
§4 column work	optional lane column	prefer a second, independent "what appears on the bar" visibility list (Notion's two-list model) — higher value, additive, improves classic mode too. lane column drops to nice-to-have
§7 Inspector	role="dialog" + focus trap, like DependencyPropertiesPanel	non-modal complementary region, no focus trap (NN/g). Docked-and-persistent with switchable sections (MS Project Task Form's 8 detail sets), escalating to centred only when the list is collapsed (Notion's rule)
§7 a11y	role="grid" retained	role="treegrid" — pre-existing bug; never aria-controls; roving tabindex left / aria-activedescendant right
§9 open q. 2	"I lean floating-first"	resolved: docked, on MS Project's precedent
—	(new)	Bryntum Rollups as a smaller first step: glyphs on collapsed summary rows with scrollToTaskOnClick, delivering much of #88's compression without breaking one-row-per-task. Put this to the author before committing to full packing
—	(new, for Concept A)	Dependency arrows and stacking are in tension — Airtable ships a mode switch rather than solving it. Decide deliberately; "arrows default-off in packed mode" is a legitimate answer
—	(new, for Concept A)	Shrink-to-a-floor, then grow the lane (Bryntum minPackSize + DHTMLX event_min_dy/fit_events, convergent)
—	(new, hard constraint)	DOM order stays logical; packing is CSS/geometry only (WCAG 1.3.2 / 2.4.3)

Everything else in the main comment stands — in particular §0's three corrections to the shared
brief, §1's decision matrix, §3's component-fate table, and §5's clamped dual-translate scroll model.

---

A12. Explicitly unverified

• monday.com: nothing verified. support.monday.com returned HTTP 403 on every attempt.
  Treat my §1B monday claims as unsourced.
• Apple HIG /inspectors genuinely 404s through every access method; it may have been folded
  into Split Views in the 2025 HIG redesign. The Split Views quote above is the verified substitute.
• Bryntum eventLayout 'mixed' semantics and Bryntum Gantt's default rowHeight — partially
  verified only. Scheduler's 60px default is confirmed.
• Exact Material 3 list-detail pane ratios — m3.material.io is JS-rendered; the 50/50 (medium)
  and ~70/30 (expanded) figures come from Android's supporting pane docs, not list-detail.
• Jira Plans (as distinct from the simple Timeline): whether clicking a bar opens a side panel
  is not documented — only inline cell editing is.
• Google Calendar: no official page enumerates the event popover's contents, and no official
  documentation of the day-view packing algorithm exists. Do not cite either as documented.
• Airtable stack-ordering rule ("older records on top") — secondary sources only.
• DHTMLX Scheduler's left columns API changed materially between v4.4.4 and v5.x —
  version-check before copying any of it.

---

Agent: Concept Agent B — Left Panel / Table (addendum)

[kitikonti]

Review R4 — Devil's Advocate: Scope, Value & Risk

My lens is the one nobody else was given: should this be built at all, in this form, at this cost. Everyone else optimised for making it work. I ran the one measurement Concept A itself named as "the gate on the whole feature" — and the result changes the argument.

Headline: I measured it. The recommended default design compresses a real OwnChart project by 1.9×. A store action that already exists in this codebase, and is wired to nothing, compresses the same project by 4.1×.

---

0. Summary of findings

#	Severity	Finding
R4-1	BLOCKER	The value premise is now measured and it is weak. Concept A's recommended default (§2.7 policy B, band-per-summary) yields 15 rows from 29 tasks = 1.93× on the repo's own reference project. Concept A named this measurement the gate; the gate does not open.
R4-2	BLOCKER	collapseAll / expandAll exist in src/store/slices/expansionActions.ts:82,90, are unit-tested, and are exposed in zero UI surfaces. Wiring them delivers 29→7 rows (4.1×) — better compression than the entire four-concept program — for roughly one afternoon. No concept mentions this.
R4-3	BLOCKER	Concepts B and C propose mutually exclusive left panels. B scores C's design 9/25, its worst option. Phase 3 cannot synthesise both; one of them is ~2–4 weeks of work that gets thrown away.
R4-4	MAJOR	Compression is inversely proportional to how far you are zoomed out — i.e. weakest exactly in the fit-on-one-screen case the feature exists to serve. Measured: 9 lanes at 25 px/day, 13 lanes at fit-to-1200px, 17 at fit-to-600px. Concept A §2.6 forbids label-aware packing precisely to avoid this, which means the rendered result degrades instead of the lane count.
R4-5	MAJOR	Summary rows can never pack (a summary spans its children by construction). In the reference project they are 24% of all rows, so any design keeping a summary row has a hard floor of 7 rows — exactly what collapse-all already gives. Packing's best case equals the free option's actual case.
R4-6	MAJOR	"Fit on one page for print" — the most plausible underlying job — is already solved. pdfLayout.ts:294-297 computes scale = Math.min(scaleX, scaleY), fitting both dimensions on one page today.
R4-7	MAJOR	Honest cost of A+B+C+D synthesised: 8–14 weeks of solo evenings ≈ one quarter, displacing all three remaining V1.1 items and the four infra issues, including #84 (coverage gate silently inert — the 80% floor in CLAUDE.md is fiction right now).
R4-8	MAJOR	Permanent mode tax is real and quantified below (§5). It is also avoidable: B's own addendum (A3) found DHTMLX shipping packed lanes as a coexisting band, not a mode. That option is in nobody's concept and it dissolves most of B and C.
R4-9	MINOR	n=1. One real .ownchart file exists in the repo. My numbers are real but they are a sample of one — which is itself an argument for DEFER-and-measure, not for BUILD.

---

1. The unmeasured premise — now measured

Concept A, Part 8, first bullet:

"How many lanes real charts actually produce. If a typical OwnChart project yields ω ≈ 8, packing saves little and the whole feature underdelivers. Resolution: run packBand over a handful of real .ownchart files and report totalRows / taskCount. This should be the gate on the whole feature."

There is exactly one real .ownchart file in the repo: examples/mars-colony.ownchart — 29 tasks, 7 summaries, 22 leaves (5 milestones), 115-day span, mean leaf duration 5.5 days, mean task-name length 20 chars. It is hand-authored as a plausible project, with phases, dependencies and nesting. I implemented document-order first-fit and exact ω (max clique on the interval graph) and ran them.

1.1 Pure interval packing, date units (Concept A's D5 rule)

Population	gap	first-fit rows	ω (optimal)	compression
All 29 tasks	0d	7	7	4.1×
All 29 tasks	3d	9	9	3.2×
All 29 tasks	10d	12	12	2.4×
22 leaves only	0d	3	3	7.3×
22 leaves only	3d	5	5	4.4×
22 leaves only	10d	8	8	2.8×

Good news for Concept A's D4: document-order first-fit hit the optimum ω in 7 of 8 configurations (the one miss was 10 vs 9). A §2.3's choice is empirically vindicated — first-fit-in-document-order costs essentially nothing versus optimal on project-shaped data. Keep D4. That is a real result and Phase 3 should bank it.

1.2 …but the recommended default is the worst-performing variant

Concept A §2.7 recommends policy B — band per summary as the default: every summary keeps its own row, descendants pack into lanes inside the parent's band. Measured on the same file:

summary header rows      7      (irreducible — a summary bar spans all its children)
packed child rows        7      (each phase's children pack to exactly ONE lane)
orphan rows              1
                        ──
TOTAL                   15  rows   vs  29 today   =  1.93×

Every one of the six phases packed to exactly one lane, because that is what a phase is: a sequence of tasks that follow each other. Banding by summary therefore throws away almost all the packing opportunity — the overlap in a real plan is between phases, not within them, and bands forbid crossing exactly there.

1.3 The comparison that decides the issue

Option	Rows	Ratio	Lossless?	Cost
Today	29	1.00×	✅	—
Density preset compact (28px) — ships today	29 rows / 812px vs 1044px	1.29× vertical	✅	0
collapseAll() — code exists, UI does not	7	4.14×	❌ children hidden	~1 ribbon button
Collapse-all + Bryntum-style rollup glyphs	7	4.14×	✅ children visible	days
Concept A §2.7-C rollup-on-collapse (measured)	7	4.14×	✅	A only, no B/C
Concept A's recommended default (band model)	15	1.93×	✅	A+B+C+D
Concept C §11.9 summary-rail model	10	2.90×	✅	A+B+C+D
Global pack, leaves only, no labels	3	7.3×	hierarchy lost	A+B+C+D

Read the two bold rows together. The design the four concepts are built around compresses 1.93×. A dead store action in this repo compresses 4.14×. That is the whole review in one line.

R4-2 in detail — the dead code

$ grep -rn "collapseAll|expandAll" src/ | grep -v store/slices
(no output)

expansionActions.ts:82-97 implements both. tests/unit/store/taskSlice.test.ts:1425-1505 tests both. useViewTabActions.ts (172 LOC, the entire View ribbon binding) exposes Today Marker, Weekends, Holidays, Dependencies, Progress, Auto-scheduling, Zoom, Fit-to-view, Task-table collapse, High Contrast, Hide UI — and no Expand/Collapse All. There is no keyboard shortcut and no context-menu entry either.

So the cheapest available answer to #88 is not even a feature request — it is a wiring bug. Nobody can honestly evaluate whether packed mode is worth a quarter of work until the author has used a Collapse All button for a week. Resolution: ship the button, then re-open #88.

1.4 The zoom trap, quantified (R4-4)

Concept A §2.6 rules that packing is zoom-invariant and labels must not enter the packer. Correct rule — but it relocates the problem rather than solving it, and the relocation is measurable. Here is label-aware packing (12px font, name rendered outside the bar when it does not fit inside, 8px gap) at the zoom levels a user would actually pick to see the whole project:

Timeline width	px/day	packed rows, all tasks	packed rows, leaves	rows today
600px	5.2	17	13	29
900px	7.8	13	9	29
1200px	10.4	12	9	29
1600px	13.9	10	7	29
2400px	20.9	10	6	29
2875px (100% zoom)	25.0	9	5	29

The pattern is the point: compression collapses as you zoom out. At the "show me the whole 115-day project in one 1200px panel" setting — the literal fit-on-one-screen job — packing all tasks is a 2.4× win, and it is a 2.4× win bought at the price of unreadable labels, because A's zoom-invariant packer will place bars that visually collide. Concept A §2.6 point 3 acknowledges this and prescribes "force inside with clipping, suppress the label below ~24px." At 10.4 px/day, a 5.5-day mean task is a 57px bar; a 20-char name needs ~140px. The median bar in the reference project cannot show its own name in packed mode at fit-to-screen zoom. A packed chart of anonymous rectangles is not an overview; it is a heat map.

The analytic form, for whoever wants to generalise beyond n=1:

rows ≈ max( n·L̄/S ,  n·w_label/W )     compression ≈ min( S/L̄ , W/w_label )

For mars-colony: S/L̄ = 115/5.5 = 20.7×; W/w_label = 1200/140 = 8.6×. Model says ≤8.6×; measured 2.4×. The ~3× gap is phase clumping — real plans bunch work into phases, so the uniform model overstates achievable compression by roughly 3×. Treat any theoretical compression estimate as ~3× optimistic.

---

2. Does it solve a real problem, or a stated outcome?

The issue states a visual outcome ("vertically compress the chart"), never a job. Four candidate jobs, each with a cheaper answer:

Job	Cheapest existing answer	Does packing beat it?
Fit the chart on one screen	compact density (28px, densityConfig.ts:9) + Collapse All → 7 rows × 28px = 196px. Trivially fits.	No. Packing gives 15 rows × 36px = 540px. Loses on its own metric.
Print / export to one page	Already shipped: pdfLayout.ts:297 scale = min(scaleX, scaleY) fits both dimensions on one page today.	Only on legibility — fewer rows = larger scale factor = bigger text. Real, but narrow, and served just as well by collapse-all.
Executive overview	Collapse All → six phase bars. This is the executive view; nobody briefing an exec wants 22 anonymous leaf rectangles.	No. Packing actively hurts here — it preserves detail the exec doesn't want.
See utilisation / where the work piles up	Nothing today.	Yes — uniquely. Lane count over time literally is a concurrency histogram. This is packing's one unshared job.
Fit vertically via "Fit to view"	Doesn't exist — fitToView is horizontal-only (chartSlice.ts:520-600 computes zoom from container width).	A genuine gap, but the fix is a vertical fit (auto-pick density + collapse depth), not a layout engine.

Honest conclusion: of five candidate jobs, packing wins one — utilisation/concurrency reading — and that job is a read job, not an edit job. Everything in Concepts B and C exists to support editing in a mode whose only unique value is looking at it. That is the core misallocation in this design.

---

3. Extending the author's own doubt

The author suspected the overlay mode duplicates summaries. Concept A §Part 3 agrees and rejects overlay — correctly, and §Part 3 point 2 ("an overlay mode is the one display where feature parity is structurally impossible") is the single best-argued paragraph in the four concepts. Keep it.

But the suspicion generalises further than A took it. Measured above: collapse-all already delivers 7 rows; the recommended packed default delivers 15. The author's instinct was not just right about overlay mode — it was right about the whole feature, for the hierarchical charts this product produces.

The honest rebuttal, which I'll make for the other side: collapse-all is lossy — the 22 leaf bars vanish, gaps inside a phase disappear, nothing is individually clickable. Packing keeps every bar real, draggable, connectable. That difference is genuine.

But it is exactly the difference Concept A §2.7-C already fixes, and which B's addendum A2 independently found shipped in a real Gantt product (Bryntum Rollups: for rollup: true tasks Gantt "displays a small bar or diamond below its summary task in the timeline", interactions fire with isRollup: true, and scrollToTaskOnClick scrolls the real row into view). I measured A §2.7-C's rollup-on-collapse on the reference file:

band Mission Planning        3 leaves → 1 lane
band Rocket & Spacecraft     4 leaves → 1 lane
band Supply & Logistics      3 leaves → 1 lane
band Training & Simulation   4 leaves → 1 lane
band Launch & Transit        3 leaves → 1 lane
band Colony Construction     4 leaves → 1 lane
top-level milestone          1 row
                            ───
ROLLUP-ON-COLLAPSE          7 rows   (all 22 leaves still visible and clickable)

7 rows, lossless, 4.14×, using a control that already exists. Concept A wrote this idea down as an "additive" side note (D6-C) and then recommended a different, worse-performing thing as the default. Phase 3 should promote §2.7-C from side note to the whole deliverable.

The one case where this reasoning fails, and it matters: a flat chart with no summaries. Collapse-all does nothing there; packing gives 3 lanes from 22 leaves. So the decision genuinely forks on whether the author's real charts use hierarchy. mars-colony is 100% hierarchical (zero orphan leaf tasks). That is the second thing to measure, and it is one grep over the author's own files.

---

4. Cost (R4-7)

Synthesising A+B+C+D at face value. I am counting solo-maintainer evenings, not idealised person-days.

Phase (Concept D §8 numbering)	Contents	Estimate
0. Resolver refactor	18 files (D §1 table): ChartCanvas, GridLines, TaskBar, DependencyArrows, GanttLayout, TimelinePanel, layoutCalculations, timelineUtils, useTimelineAreaContextMenu, ExportRenderer, exportLayout, pdfLayout, chartSlice, useFileOperations + 2 new modules. Gate: zero VRT baseline churn.	3–5 d
1. Packed timeline behind flag	packRows, useRowLayout, View-tab control, divergent pane heights (cheaper than feared given the corrected single-scroll-driver model), arrow dimming	4–6 d
2. Interaction parity	Rewrite inline SelectionRows (ChartCanvas ~142-200) + RowOverlays.tsx; geometry hit-testing for context menu; frozen lanes during drag + animated reflow; keyboard nav	8–12 d
3. Arrow routing	Lane gutter, channel assignment, degradation. Airtable's evidence (B addendum A1) is that this may not converge: their Gantt layout requires one record per lane, i.e. they refused to combine stacking with arrows. OwnChart has four dependency types + cascade.	8–15 d, uncertain
4. Export + persistence + docs	ExportOptions.rowLayoutMode, prepareExportTasks (CLAUDE.md hard rule), ViewSettings + applyViewSettingsDefaults + normalizeViewSettings + validate.ts + multiTabStorage, a HelpTopic in the 1,264-line helpContent.ts, manual PNG/PDF/SVG verification	5–8 d
5. Left panel (B or C)	B: decoupled list + hoveredTaskId cross-highlight + scroll clamp + Inspector. Or C: Lane Ledger + Detail Strip + explode/collapse + rebound navigateCell. Not both.	10–20 d
6. A11y	Per C §11.10 an explicit release blocker: TaskBar has no role and no aria-label today; the table is the only screen-reader route to tasks (CONTEXT late correction 3). Any design that stops the table being 1:1 must build a canvas ARIA model + live region + keyboard model from zero.	6–12 d
7. Test estate	5,239 unit tests kept green; packed variants for the ~60–80 interaction-relevant E2E specs of ~190; VRT baselines 9 → 18, Docker-only regeneration	6–10 d

Total: 50–88 evenings ≈ 8–14 weeks ≈ one quarter.

What it displaces

gh issue list — 14 open issues. This one consumes the capacity of essentially all of them:

• Coverage thresholds are silently not enforced, and coverage scope includes stale worktrees #84 (bug, priority: high) — coverage thresholds are in the wrong config key and silently inert; npm run test:unit reports 33.09% and exits 0 against a documented 80% floor. The project's stated quality gate is currently fiction. Adding ~5k LOC of new mode-dependent behaviour on top of an unenforced coverage gate is the wrong order of operations, and this is the single strongest process argument in my review.
• npm audit: 2 vulnerabilities from transitive js-yaml@4.1.1 #85, Dependency drift: 29 outdated packages, toolchain a full major behind #86, Repo housekeeping: 44 merged branches and 3 stale agent worktrees #87 — audit vulns, 29 outdated packages / toolchain a major behind, 44 stale branches + 3 stale worktrees (which Coverage thresholds are silently not enforced, and coverage scope includes stale worktrees #84 notes are also polluting coverage scope).
• V1.1 roadmap remainder (ROADMAP.md:24-27): Named snapshots, Custom fields UI, Multi-project management. These are the stated path to V1.1. Each is plausibly 2–3 weeks. Compact Mode #88 costs more than all three combined and is not on the roadmap.
• Make tasktable optional #6 "Make tasktable optional" — note isTaskTableCollapsed already exists in chartSlice; Make tasktable optional #6 is nearly done and directly overlaps Concept B's territory. Doing Make tasktable optional #6 first would cost days and would tell you a lot about whether a chart without a 1:1 table is even pleasant.
• Bulk editing for multi-selected tasks #32 bulk editing, Multi-select drag and drop #20 multi-select drag, Context Menu V2 — Timeline Enhancements #52 context menu V2, Dependencies: research behavior and plan improvements #22 dependency research — all cheaper, all requested, all made harder by shipping a second layout first (each then needs two-mode handling).

---

5. The permanent complexity tax (R4-8)

Every mode multiplies the state space of everything after it. Concretely, and forever:

Surface	Tax
E2E	~60–80 interaction specs need a packed variant. Grows with every future feature.
VRT	9 baselines → 18. Docker-only regeneration; every visual change now costs two rounds.
Persistence	rowLayoutMode must be written in four places (ViewSettings/serialize, validate.ts, multiTabStorage, ExportOptions). D §5 already notes useFileOperations:369 silently drops fields not explicitly emitted — a permanent trap with a permanent test obligation.
Export	CLAUDE.md's "any visibility/filtering change must be mirrored in prepareExportTasks" rule gains a second axis. Every future filtering feature × 2.
Bug triage	Every report needs "which layout?". For a solo maintainer this is the tax that actually hurts.
Feature design	Every future feature must answer "what does this mean when four tasks share a row?" — including the three remaining V1.1 items. Custom fields on a shared row. Snapshots of a packed layout.

And the mode is avoidable. This is R4-8's real content and it comes from B's own addendum (A3), which no concept incorporated: DHTMLX Gantt runs a strict 1:1 task grid and a packed resource band simultaneously, as two rows of one layout tree (grid+timeline above, resourceGrid+resourceTimeline below, left panels sharing group: "grids"). A vendor facing this exact problem chose coexistence over mode-switching. Meanwhile Airtable (A1) chose the mode switch — and paid for it by making their Gantt layout mutually exclusive with stacking.

Two vendors, two answers, and the coexistence answer costs OwnChart far less because it never obliges parity.

---

6. The counter-proposal: "Overview Band" — coexistence, not a mode

Concrete enough to build. Three steps, shippable independently, each with its own release.

Step 1 — Wire the dead code (hours)

collapseAll / expandAll into the View ribbon next to Fit-to-view, plus shortcuts and a HelpTopic. 29 → 7 rows, 4.14×, today. Then use it for two weeks before deciding anything else. This step alone may close #88.

Step 2 — Lossless collapse via rollups (days)

Concept A §2.7-C / Bryntum Rollups. A collapsed summary draws its descendants as small bars/diamonds on its own band instead of hiding them; click scrolls the real row into view (scrollToTaskOnClick). Same 7 rows, now lossless. Row count is unchanged, so y = index * rowHeight survives, the table stays 1:1, ARIA is untouched, exports need only the extra glyphs. Concepts B, C and most of D are not needed.

Step 3 — Overview Band, read-only (1–2 weeks), only if Steps 1–2 prove insufficient

A packed, read-only lane band pinned above the normal 1:1 grid, in the timeline pane only, sharing the x-scale:

┌───────────────────────┬───────────────────────────────────────────────────┐
│  ▾ Overview  3 lanes  │  ▓▓▓▓  ▓▓▓▓▓▓   ▓▓▓   ▓▓▓▓▓▓▓▓▓    ◆   ▓▓▓▓        │
│         [Fit] [×]     │    ▓▓▓▓▓▓   ▓▓▓▓▓▓▓▓     ▓▓▓▓  ▓▓▓▓▓▓▓             │
│                       │        ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓          ▓▓▓  ◆           │
├───────────────────────┼───────────────────────────────────────────────────┤
│ # Name       S    E   │  (the existing chart, 1 row per task, untouched)   │
│ 1 Mission P. ...  ... │  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓                                  │
│ 2 Crew Sel.  ...  ... │  ▓▓▓▓                                             │
│ 3 Mission A. ...  ... │      ▓▓▓▓▓▓▓                                      │
│ + Add task…           │                                                   │
└───────────────────────┴───────────────────────────────────────────────────┘
   click a band bar → selects the task + scrolls its real row into view

Why this dissolves the hard problems:

Problem the concepts spent weeks on	Under Overview Band
Create/edit without a per-task row (C §1, §3)	Gone. The 1:1 table is right there.
Left panel redesign, B-vs-C conflict (R4-3)	Gone. No redesign.
New keyboard model (C §5)	Gone. Band is aria-hidden, one tab stop, "Overview, 22 tasks in 3 lanes".
ARIA regression (C §11.10)	Gone. Table remains the accessible representation.
Dependency arrows in lanes (D §3, Airtable's warning)	Gone. Band shows no arrows; the real chart still does.
Undo/redo, clipboard, drag semantics in lanes	Gone. Read-only.
Two-baseline VRT, two-variant E2E, "which layout?"	Gone. One layout with an optional band.
Export	One extra band, same resolver.
ViewSettings	One boolean showOverviewBand.

Cost: Concept D Phase 0 only (the resolver refactor, which is independently good — it kills y = index * rowHeight and D's zero-VRT-churn gate proves it), plus a subset of Phase 1. It also delivers the one job packing uniquely serves (§2: reading concurrency/utilisation), because a 3-lane band at a glance says "at most three things run at once."

And it satisfies the author's non-negotiable constraint better than any mode does: there is no "which display am I in", so "independent of which display I am in, I need all features" is trivially true — there is only one display, with an extra readout.

Explicitly rejected from the concepts

• Concept A §2.7 policy B as the default — measured at 1.93×, the weakest lossless option.
• Concept C's Lane Ledger + Detail Strip — B scored this 9/25 and B's addendum (A2) found Bryntum's real-world answer to "what goes in the left cell when a row holds N bars" is showEventCount: a number. A left panel showing "Lane 2 · 3 tasks" is informationally worthless for editing, which is exactly B's prediction, now corroborated by a vendor.
• Concept B's decoupled list with divergent scroll rates — B's own uncertainty Evaluate switch to Cloudflare hosting #3 admits no user evidence, and it breaks the one invariant every Gantt user relies on.
• A true single-line overlay mode — A §Part 3 is right, for the right reason.

---

7. Steelman — the strongest case FOR building it

I owe this section honesty, so here it is as strongly as I can put it.

1. First-fit-in-document-order is empirically optimal on real data. My own measurement (§1.1) shows it hitting exact ω in 7/8 configurations. The algorithm is not the risk; it is ~80 lines of pure, trivially testable code. Concept A §2.3–2.5 is genuinely good work.
2. Concept D Phase 0 is worth doing regardless of Compact Mode #88. y = index * rowHeight scattered across ChartCanvas, GridLines, DependencyArrows, ExportRenderer, exportLayout and pdfLayout is real architectural debt. A RowResolver with a list-mode identity case and a zero-VRT-baseline-churn acceptance gate is a clean, self-proving refactor that makes any future non-1:1 rendering cheap — banded resource views, snapshots overlay, multi-project. This is the part of the program I would keep even under DON'T BUILD.
3. Flat charts are the real use case and I cannot rule them out. Every argument in §3 depends on the chart having summaries. A flat 40-task list gets nothing from collapse-all and 4–8× from packing. If the author works flat, my recommendation inverts.
4. Utilisation reading is unserved (§2) and is a legitimately valuable capability — packing is the only thing that shows it.
5. Category-adjacent products ship it: vis.js stack, Bryntum eventLayout: 'pack' with minPackSize, DHTMLX fit_events/resize_events with event_min_dy, Airtable timeline swimlanes, Google Calendar. Two vendors independently converging on shrink-to-a-floor-then-grow is strong design evidence.
6. But — and this is the load-bearing qualification — no mainstream Gantt ships packed-and-editable. Bryntum's pack lives in Scheduler (resource rows), not the Gantt task view. Airtable's Gantt layout requires one record per lane. DHTMLX packs the resource band, not the task grid. The absence in OwnChart is therefore not a competitive gap in the Gantt category — it is a gap versus roadmap/timeline tools. Which is precisely the read-only overview affordance of §6 Step 3, not a full editable second layout.
7. Evidence of user demand: n=1. Compact Mode #88 is the only issue referencing this; the requester is the maintainer. That is legitimate — it is his product — but it is not a signal that justifies a quarter.

---

8. Cross-concept contradictions (R4-3 and friends)

#	Sev	Contradiction	Resolution
X1	BLOCKER	B §1(e): "left panel keeps one row per task, decoupled." C §0: "left panel becomes the Lane Ledger, one row per lane." B explicitly scores C's design as its worst option (9/25, parity 1/5). Directly incompatible; one is 10–20 evenings of throwaway work.	Neither. §6 Step 3 keeps the table 1:1 and keeps alignment, because the band is a separate surface.
X2	MAJOR	A D6: summaries keep their own row, children pack into the parent's band. C §11.9: "summaries must be excluded from packing (summary rail), or the feature does not compress." Measured: A's model = 15 rows, C's = 10. C is right on the numbers; A is right that the outline survives.	Both lose to collapse-all (7). Resolve by not choosing.
X3	MAJOR	A §2.6: labels must never enter the packer (zoom-invariance). B addendum A5 / Notion: bars should carry more properties in packed mode. These fight: more label content ⇒ more collisions ⇒ A's answer is to suppress labels.	Read-only band ⇒ no labels at all on band bars; identity via colour + hover + click-to-reveal.
X4	MAJOR	D §8 Phase 3 plans channel-routed arrows. B addendum A1: Airtable, in production, made stacking and dependency arrows mutually exclusive. D's Phase 3 may be unshippable.	Band shows no arrows. Removes the highest-uncertainty phase from the plan entirely.
X5	MINOR	C §8: packing is never an undoable command (correct). B §2: hoveredTaskId in chartSlice. Neither says who owns lane stability across an undo that changes dates.	Non-issue under §6; the band re-packs from scratch, nothing to stabilise.

---

9. What Phase 3 should keep from Phase 1

Not padding — these are load-bearing and I want them preserved even under my recommendation:

• A §2.3–2.5 — first-fit in document order. Measured optimal here. Keep.
• A §2.6 D5 — packing is zoom-invariant, pixelsPerDay is never an input. The export-divergence argument is correct and decisive.
• A §Part 3 — the rejection of overlay mode, and specifically the reason ("the one display where feature parity is structurally impossible").
• A §2.7-C — rollup-on-collapse. Promote it from side note to the deliverable.
• D §1 + §2 + §8 Phase 0 — the RowResolver with a list-mode identity case and a zero-VRT-churn gate. Worth doing on its own merits.
• D's correction that SelectionHighlight.tsx is not row math. Correct; the brief has been patched.
• B §10.6 / CONTEXT correction 5 — ChartCanvas.taskGeometries is the injection point. Right, and it is what makes §6 Step 3 cheap.
• C §11.10 — a11y as a release blocker, and the observation that TaskBar has no role/aria-label today. That debt is real and predates Compact Mode #88; it should become its own issue rather than being smuggled into this one's cost.

---

10. Recommendation

DEFER — and ship the two cheap wins first.

Unhedged, in order:

1. Ship the Collapse All / Expand All ribbon button + shortcut this week. The store actions exist and are tested; they are wired to nothing. Measured 4.14× on the reference project — better than the entire proposed program's 1.93×.
2. Measure two things before writing another line of Compact Mode #88 design:
   • totalRows / taskCount and hierarchy depth across the author's own .ownchart files. My numbers are n=1. If his charts are flat, this recommendation inverts and I will say so.
   • Whether Collapse All, used for two weeks, actually closes the itch.
3. Then ship Concept D Phase 0 (the RowResolver refactor) regardless of the outcome — with the zero-VRT-baseline-churn gate. It is a refactor: commit, no version bump, and it de-risks every future non-1:1 rendering.
4. Then, only if 2 says the itch remains: build the read-only Overview Band (§6 Step 3), not a mode. 1–2 weeks. It dissolves Concept B, Concept C, D Phase 3 and the entire parity obligation, and it delivers the one job packing uniquely serves.
5. Do Coverage thresholds are silently not enforced, and coverage scope includes stale worktrees #84 before any of this. Building a quarter-sized feature while the coverage gate silently reports 33% and exits 0 is the wrong order.

Do not build: packed mode as a full second editable layout with feature parity, a redesigned left panel, a new keyboard model and channel-routed arrows. Measured 1.93× on real data, costs a quarter, taxes every feature after it forever, and its central promise — fit the chart on one screen — is beaten today by a button that already exists in the codebase and has never been wired up.

---

Reviewer: R4 — Devil's Advocate: Scope, Value & Risk

[kitikonti]

Review R2 — UX, Product Coherence & Accessibility

Adversarial Phase-2 review. My lens is the person using this. I read Concepts A, B (main +
addendum #issuecomment-5355106823), C (Parts 1/2 and 2/2) and the relevant parts of D, and I
verified every claim below against the source at main @ v1.7.9. Line references are mine
unless attributed.

Headline: Concept B's left-panel recommendation is right and Concept C's is wrong, and they
are not mergeable — Phase 3 must pick one, not blend them. C's central claim ("classic mode is
literally packed mode with every lane exploded") is false as specified, and C's own accessibility
fallback contradicts C's own design. Separately, three factual premises that Phase 3 would
otherwise build on are wrong: Density is not in the View tab, classic mode does not
currently fail SC 2.5.7/2.1.1 for bar move/resize/progress, and colour cannot serve as the
row↔bar binding key in this product.

---

0. Findings, ranked

#	Sev	Finding	Where
R2-1	BLOCKER	C's "classic = packed with every lane exploded" continuum is not real. Explode-all yields lane-grouped, chronologically-ordered rows without summaries; classic is outline order with indentation and summary rows. It is a rebranded either/or.	C §0(b), §6.5
R2-2	BLOCKER	C's Lane Ledger re-creates the author's own headline complaint: by default no task name is visible for any task. The issue says "I can't type the task name because there is no task table"; C's answer is a panel of rows labelled "Lane 1 · 4 tasks".	C §0 wireframe
R2-3	BLOCKER	C's declared accessibility fallback does not deliver what C claims. Ledger rows are lanes; tasks appear only when a lane is exploded, and within a lane they are in chronological, not outline, order. C §5.6's "every task is reachable here in outline order" is false by C's own design.	C §5.6 vs C §0/§6.5
R2-4	BLOCKER	B and C propose mutually exclusive left panels, mutually exclusive second editing surfaces, mutually exclusive scroll models and mutually exclusive chart focus models. Blending them produces an incoherent product. Table in §2.	B §1(e)/§5/A10, C §0/§5
R2-5	MAJOR	C's claim that classic mode already fails SC 2.5.7 and 2.1.1 for bar-move/resize/progress is wrong. Both SCs are functionality-scoped; startDate/endDate/duration/progress are all editable table cells today. The genuine failure is narrower: dependency creation (addDependency is referenced only by dependencySlice, command.types and useDependencyDrag). This inverts C's argument: the table is the compliance mechanism, so removing per-task rows creates the failure.	C §3.4, §5.6
R2-6	MAJOR	No concept addresses that packing communicates false grouping. GridLines.tsx:188-194 draws a horizontal rule per row; kept as-is those rules become lane borders and visually assert that a lane is a container. C then names the artifacts ("Lane 1", "Lane 2") in the left panel, reifying a bin index as a project object.	A §2.7, B §6.1, C §0
R2-7	MAJOR	A's naming argument rests on a false premise. Density lives in the Format tab (FormatTabContent.tsx, ToolbarGroup label="Display" → "UI Density"), not the View tab. Worse, the View tab already has ToolbarGroup label="Layout" (ViewTabContent.tsx:213), so "Row Layout" collides with an existing group name at exactly the place it would be installed.	A §1.4(c)
R2-8	MAJOR	Persistence-tier mismatch. uiDensity is a device preference (userPreferencesSlice); all four concepts put rowLayout in ViewSettings (the saved file). So opening a colleague's file silently changes your display, and the setting A calls "a display setting alongside density" is scoped differently from density.	A D3, C §8.4, D §5
R2-9	MAJOR	"Dependency arrows default-off in packed mode" (B addendum A11) is a literal violation of the author's constraint. So is any answer of the form "the feature is available but illegible".	B addendum A11
R2-10	MAJOR	B's "colour as the persistent shared key" (§2 Secondary, not revised in the addendum) is falsified by the code: 4 of the 5 ColorModes (theme, summary, taskType, hierarchy) assign colour by group, so colour identifies a category, not a task. With colour out and leader lines cut (addendum A11), the design has no always-on binding cue at all.	B §2, colorMode.types.ts:11-16
R2-11	MAJOR	The Detail Strip is a real regression for comparative and bulk work, and C concedes it ("only one task editable at a time") without costing it. Scanning 30 start dates for the wrong one is a core Gantt workflow and a 1×7 strip cannot do it.	C §3.1, §9 Update
R2-12	MAJOR	Contradiction between concepts on whether anything is hidden. A's tooltip copy promises "Nothing is hidden — the same tasks, fewer rows"; A §2.8 then hides milestones behind a ◆3 cluster glyph, and C §3.4 adopts FullCalendar's eventMaxStack "+N more" lane cap. Both hide tasks.	A §1.4(c) vs A §2.8, C §3.4
R2-13	MINOR	A §2.6 forces TaskLabelPosition to inside in packed mode. That is a persisted ViewSettings field with a Format-tab control (FormatTabContent.tsx "Labels"). A mode that silently disables a user setting is a parity break by the author's own definition.	A §2.6
R2-14	MINOR	If lane height ≠ rowHeight (B §5 open question; B addendum A8's "shrink to a floor, then grow"), the user's Density choice is partly overridden by the layout mode. Two settings fighting over one number.	B §5, addendum A8
R2-15	MINOR	Mode-dependent menu labels ("Insert Above/Below" vs "Insert Before/After", "Hide Row" vs "Hide Task") teach two vocabularies for one action.	C §7
R2-16	MINOR	"Explode" is the wrong verb for a planning tool, and it competes with Task.open ("expand") and with hiddenTaskIds ("show").	C §6.5

---

1. Parity audit against the author's non-negotiable constraint

The constraint, literally: "It's just a different display and independent of which display I am
in, I need all features." That is stronger than "no feature is deleted". It means no feature
may become materially harder, and no existing setting may quietly stop working. I audited both
proposals against that bar.

1.1 Concept C — where parity actually breaks

Feature (verified in code)	Classic today	Packed per C	Verdict
Every task's name visible without interaction	yes, name column	no — ledger rows are lanes; names require explode or focus	BREAK — and it is the author's own complaint
Every task's dates/duration/progress visible together	yes, 4 columns × N rows	1 task at a time in the Detail Strip	BREAK
Row drag-reorder, incl. keyboard (TaskTable.tsx:112-127, PointerSensor + KeyboardSensor, undoable REORDER_TASKS)	yes	C §9 marks it [X] "no meaning in packed mode"	BREAK (and it silently removes a keyboard-operable operation)
Hover InsertRowButton / InsertLine	yes	C §1.4.4 drops it from the packed timeline	BREAK (C concedes)
HiddenRowIndicator per-gap affordance	yes	C §6.4 drops it	BREAK (C concedes)
Column hide / resize / auto-fit semantics	governs N×7 grid	governs a 1×7 strip	DEGRADED — same control, different meaning
Screen-reader traversal of the task set in outline order	role="grid", role="row", aria-rowindex per task	ledger rows are lanes; task order within a lane is chronological	BREAK (see §4)
aria-rowindex truthfulness	truthful	describes lanes	BREAK

Eight breaks, three of them conceded in C's own matrix. That is not "just a different display".

1.2 Concept C's continuum claim is not real (R2-1)

C §0(b): "Classic mode is packed mode with every lane exploded… not a metaphor — it should be
the literal implementation." It cannot be, for three independent reasons:

1. Order. Explode-all produces rows grouped by lane, and inside a lane ordered by date.
   Classic produces rows in order/parent outline sequence with indentation. Same tasks,
   different sequence — so "explode all" lands you in a third view, not in classic mode.
2. Summaries. C §6.2 recommends excluding summaries from packing entirely and drawing them in
   a pinned rail. There is no lane to explode them out of, so explode-all cannot reconstruct the
   classic summary rows.
3. Hierarchy. C §6.1 concedes indentation depth is not expressible in the packed timeline.
   Exploding a lane does not restore parentage, because lane membership crosses subtrees.

what C claims                          what C's design actually produces
─────────────────                      ────────────────────────────────
classic ◄── explode all ──► packed     classic ──(mode switch)──► packed
   one continuum, no silo                              │
                                                   explode all
                                                       ▼
                                              a THIRD view: lane-grouped,
                                              chronological, no summary rows,
                                              no indentation

Resolution. Stop trying to make the two views endpoints of one axis; that framing is what
produced the ledger. The author's constraint is satisfied by orthogonality, not by a continuum:
one outline, one set of operations, one left panel, and a display switch that changes only
y. That is exactly B's option (e), and it is the reason B's parity claim is credible while C's
is not — B inherits parity, C re-implements it.

1.3 Concept B — where parity breaks, honestly

B is much closer to the bar but is not free:

Item	Status
1:1 alignment (B's J1–J4)	genuinely lost; compensated by highlight + reveal. This is inherent to the feature, not a design fault
SelectionRows full-width band → per-bar ring	visual change only, no capability lost
Panes scrolling at different rates (B §5 clamped translate)	new, unfamiliar mental model. Nobody has looked at it. B's own uncertainty #3
TaskLabelPosition before/after in a packed lane	collides with neighbours; A's fix is to force inside → a Format setting stops working (R2-13)
Lane height vs Density (R2-14)	unresolved; two controls over one number
Dependency arrows (R2-9)	B addendum floats "default off in packed mode" — not acceptable as specified

On R2-9 specifically: showDependencies is already a global ViewSettings toggle. Giving it a
different default per display mode means an existing user setting silently changes meaning when
you switch views — precisely the "either/or" the author forbade. If arrows genuinely cannot be
routed legibly through packed lanes, that is an argument about the packing policy (bands,
summary rail, lane count cap), not a licence to turn a feature off. Recommended stance for
Phase 3: arrows stay on in both modes; if routing fails, the packer is wrong.

---

2. B vs C — the two left-panel designs do not agree

They were written in parallel and they collide on every load-bearing decision. This is the single
most important thing for Phase 3 to resolve before synthesis.

Question	Concept B	Concept C	Compatible?
Left panel row granularity	one row per task, unchanged	one row per lane ("Lane Ledger")	No
Where you type a task name	the name cell, as today	Detail Strip / inline on bar	No
Second editing surface	docked, non-modal Inspector, switchable sections, present in both modes (addendum A11)	pinned 1×7 Detail Strip bound to the focused task	No — same screen slot, same keyboard slot
Vertical alignment	abandoned; replaced by identity binding	"survives at lane granularity"	No
Scroll model	one driver, two independently clamped translates (§5)	"useSyncScroll and the whole SVAR sticky-scroll layout keep working untouched" (§0a)	No — and C is factually wrong: useSyncScroll is horizontal-only; vertical is one driver writing translateY onto both panes (GanttLayout.tsx:94-108, 163-200)
Column system	untouched; governs the table	"columns drive the ledger and the Detail Strip"	No — a ledger row has no startDate cell to hide
Summaries	band per summary (with A)	excluded from packing, pinned rail (§6.2)	No
Chart focus model	aria-activedescendant in the chart pane (addendum A10.3)	roving tabindex, explicitly argued against activedescendant (§5.6)	No
Table ARIA	treegrid (addendum A10.1)	treegrid	Yes
DOM order = logical order, packing via geometry only	explicit hard constraint (addendum A10)	implied, never stated	Yes, once stated
Naming of the control	"Timeline layout: Rows / Lanes" (§8)	defers	vs A's "Row Layout: One per Row / Packed" — three different labels in play

My ruling: take B's left panel, take C's interaction inventory. C's genuine value is not the
ledger; it is the CRUD/keyboard/a11y audit around it — the non-drag pointer paths, nudge mode,
Ctrl+D duplicate, paste-at-cursor, the useTimelineAreaContextMenu hit-test bug
(rowIndex = Math.floor(svgY / rowHeight)), the "freeze packing during drag" rule, the stability
invariant, and the "packing is never a command" ruling. Every one of those survives on B's
panel. The ledger is the only part that must be dropped, and dropping it removes eight parity
breaks at once.

2.1 Is a Detail Strip a regression from a table? Yes.

Even if you keep B's table, C's Detail Strip question deserves a straight answer, because Phase 3
may be tempted to add it as a "packed-mode row".

A spreadsheet's value is not that you can edit one cell; it is that thirty rows are legible
simultaneously. The real workflows that need this:

• "Which of these ends in March?" — visual scan of one column, N rows. Strip: N focus changes.
• "Why is this task 12 days when its sibling is 3?" — side-by-side comparison. Strip: impossible.
• "Fix the five tasks I typed the wrong year into." — scan, then edit in place. Strip: 5 × (focus, read, edit).
• "Copy this date to the next four tasks." — cellClipboard is single-cell today
  (clipboardSlice.ts:55-172), so this is already 4 paste operations; the strip adds 4 focus
  changes on top.

So: a Detail Strip is a fine third surface and a poor first one. B's Inspector is the better
shape for the same job because it is additive (present in classic mode too, where it is a net
gain), non-modal (B addendum A9, on NN/g's data-table guidance), and does not claim to replace
the grid. Recommendation: ship B's Inspector, do not ship a Detail Strip, and do not remove
the table in either mode.

---

3. Discoverability and the mental model

3.1 Packing is a lie about relatedness, and nobody said so

In a Gantt, vertical adjacency means something: it is outline sequence, and indentation is
parentage. That is the entire premise of the left-to-right/top-to-bottom reading. Packed mode
puts unrelated tasks on one line — and every visual convention in the current renderer will
insist that line is a container:

• GridLines.tsx:188-194 draws taskCount + 1 horizontal rules at i * rowHeight. Reused as-is,
  those become lane borders: boxes around groups of unrelated tasks.
• C then labels the boxes "Lane 1 / Lane 2 / Lane 3" in the left panel. Naming a bin index
  turns an artifact into an apparent project object. Users will ask "what's in lane 2?" and there
  is no answer.
• B §4 proposes an optional lane column (L1, L2) — same reification, but at least default-off,
  and B's addendum demotes it. Good.

None of the four concepts proposes a visual treatment that prevents the false-grouping read.
Concrete recommendation, cheap:

1. Suppress per-row horizontal rules in packed mode. Draw the packed area as one continuous
   field. The correct metaphor is text wrapping, not rows: the plan is one long strip that
   wrapped because the viewport is narrow. Wrapped lines of a paragraph carry no grouping meaning
   and readers know it.
2. Keep exactly one horizontal partition, and make it semantic: the summary band boundary
   (A §2.7 B). Those lines do mean something, so they are the only ones allowed.
3. Never name or number a lane in user-facing UI. No "Lane 2" labels, no lane column on by
   default, no "Placed in lane 2" toast (C §1.3). Say "Moved to make room" if anything.
4. Announce nothing about lanes to assistive tech (see §4.4).

3.2 What a first-time user thinks

Under B: they see the same table they had, and a timeline that got shorter. The only novel
question is "which bar is my row?" — answered by hover/selection highlight and by the bar's own
name label. Recoverable in one second.

Under C: they see this —

┌──────────────────┬──────────────────────────────────┐
│ Lane   n    ⌄    │  ▓▓▓   ▓▓▓▓▓   ▓▓                │
│ ▸ Lane 1   4     │    ▓▓▓▓▓   ▓▓▓▓▓▓                │
│ ▸ Lane 2   3     │  ▓▓▓▓▓▓▓▓                        │
│ ▸ Lane 3   2     │                                  │
│ + Add task…      │                                  │
└──────────────────┴──────────────────────────────────┘

— a project management tool that has stopped showing them the names of their tasks. This is worse
than the problem in the issue, and it is worth noting the current onboarding literally contradicts
it: WelcomeTour.tsx:52 tip #1 is "Click the empty row to add tasks", and helpContent.ts
gs-create-task says "Click the empty placeholder row at the bottom of the task table".
Under B those sentences stay true in both modes. Under C both have to be rewritten and the tour's
first promise becomes conditional on which mode you are in.

3.3 Is "Row Layout: One per Row / Packed" discoverable in the View tab?

Partly, and it has a placement bug. Verified ribbon structure:

• View tab (ViewTabContent.tsx): groups Show/Hide · Scheduling · Zoom · Layout
  (currently one control: Table show/hide) · Display (Contrast, Hide UI).
• Format tab (FormatTabContent.tsx): Labels (Task label position) · Calendar ·
  Display (UI Density, Date format, Week numbering).

So A §1.4(c)'s pitch — "a dropdown sitting next to the existing density control… the parallel
structure makes both settings easier to learn" — cannot be built as described (R2-7). Density
is one tab away. And a control literally named "Row Layout" inside a group literally named
"Layout" is a naming collision at the point of use.

Where it should go: View › Layout, next to the Table toggle. Both are "how is the workspace
arranged" controls, and that group is currently under-populated. Do not move Density to match —
Density is device-scoped (R2-8) and moving it would churn an existing habit.

---

4. Accessibility

4.1 The premise: verified

I re-ran the greps myself. Across src/components/GanttChart/*.tsx, role= and aria-label
appear exactly twice: DependencyPropertiesPanel (role="dialog") and DependencyArrow
(role="graphics-symbol", and note it also has tabIndex={0} and an aria-label, which both
B and C missed — dependency arrows are the one focusable thing in the chart today).
TaskBar.tsx has no role, no label, no tabindex. TaskTable.tsx:146-147 is
role="grid" aria-label="Task spreadsheet".

So B §0.3 is correct: the task table is currently the entire screen-reader representation of the
task set. I accept the argument's force but state it more precisely than B does — it is not a
law that eliminates option (c), it is a statement about cost and risk:

Removing the per-task table is only survivable if the chart's full ARIA model ships in the same
release. C proposes exactly that model. But C §5.6 also concedes that no commercial Gantt
ships true 2-D timeline arrow navigation and that Syncfusion self-rates its own screen-reader
support "Intermediate". Betting the product's only accessible surface on an unshipped-anywhere
model is not a risk worth taking when the alternative (B) keeps a known-good surface for free.

4.2 C's "SC 2.5.7 / 2.1.1 are already failing today" claim — mostly false (R2-5)

C §3.4 asserts: "Today OwnChart has no non-drag pointer path for bar-move, bar-resize,
progress-drag, dependency-drag or marquee. That is a pre-existing WCAG 2.2 AA failure."

Checked against the code and against the SC text:

• SC 2.5.7 requires the functionality to be achievable by a single pointer without dragging.
  SC 2.1.1 requires the functionality to be keyboard-operable. Neither requires the specific
  gesture to be replicated.
• TASK_COLUMNS (tableColumns.ts:141-209) makes startDate, endDate, duration and
  progress editable cells, reachable by pointer click and by useCellNavigation keyboard
  traversal over EDITABLE_FIELDS (task.types.ts:54-63). Changing a task's dates is bar-move
  and bar-resize; setting the progress field is progress-drag.
• Row reorder is keyboard-operable via dnd-kit's KeyboardSensor (TaskTable.tsx:112-115).

So in classic mode these SCs are met, via the table, under 2.5.8's own "Equivalent" exception.
The genuine gap is narrower and C should get credit for finding it: dependency creation.
addDependency is referenced by exactly three files — dependencySlice.ts, command.types.ts
and useDependencyDrag.ts. There is no menu item, no field, no keyboard path. That is a real
SC 2.5.7 and 2.1.1 failure today and C's "Link to…" + L proposals fix it. Ship those
regardless of #88.

Why this correction matters strategically: C used the "already broken" framing to argue the
packed mode's a11y cost is not a new debt. The opposite is true. The table is what makes
OwnChart compliant. Take the per-task rows away and you convert three passing criteria into
failures. This is the strongest single argument against the Lane Ledger, and it is stronger than
the argument B actually made.

4.3 C's ARIA model against the RESEARCH_PEER constraints

C's decision	Verdict
Ledger → role="treegrid"	Right, and it converges with B addendum A10.1 and with APG. Also fix TaskTable's role="grid" → treegrid today: it is hierarchical (level, hasChildren), expandable (task.open) and editable. Pre-existing bug, worth its own commit
Bars → role="treeitem" + aria-level, lanes role="presentation"	Sound in principle (KendoReact precedent), but see below — with B's panel it is a supplement, not the only surface, which de-risks it enormously
Reject role="application"	Correct, and RESEARCH_PEER backs it: it suspends browse mode and shifts total responsibility to the author
Reject aria-roledescription	Correct
Roving tabindex over aria-activedescendant	Correct — and this settles the B/C conflict. B addendum A10.3 argues the reverse ("activedescendant needs only a valid ID, not DOM adjacency"), but activedescendant also requires the element to exist in the DOM, so it buys nothing against virtualisation while additionally requiring manual scroll-into-view and having weaker SVG support. C wins this one
Deviating APG's tree Left/Right (collapse/expand) to along-lane traversal	Acceptable if documented, but it is a real cost: tree is the pattern users' muscle memory maps to. Prefer a model where Left/Right keeps its APG meaning in the ledger and the canvas is where the deviation lives
No concept proposes aria-owns	Good. RESEARCH_PEER is decisive here: aria-owns can only append to accessible-tree order, MDN explicitly says "avoid using aria-owns to match reordering from the CSS order property", and it was not exposed to VoiceOver before iOS 17.3 / macOS 14.3. Anyone in Phase 3 who reaches for it to bind a table row to its packed bar must be stopped

The rule that makes all of this tractable, and only B stated it (addendum A10): keep DOM order
in logical task order; achieve packing entirely through geometry. For an SVG chart this is free —
y already comes from a single rowIndex argument into getTaskBarGeometry — so nothing forces
the bar array to be sorted by lane. Make it a hard, tested constraint (WCAG 1.3.2 Meaningful
Sequence, 2.4.3 Focus Order), because it is exactly the kind of thing a later performance
"optimisation" would break. Phase 3 must promote this to a first-class requirement.

flowchart LR
  subgraph DOM["DOM / accessibility tree — ALWAYS outline order"]
    d1["task 1"] --> d2["task 2"] --> d3["task 3"] --> d4["task 4"]
  end
  subgraph VIS["Visual — packed, geometry only"]
    v["lane 0: t1 · t3<br/>lane 1: t2 · t4"]
  end
  DOM -- "y = laneOf(task) * rowHeight<br/>(an attribute, never a reorder)" --> VIS
  X["aria-owns to 'fix' the order"]:::bad -.->|"append-only · not for CSS reorder<br/>· broken pre iOS 17.3 / macOS 14.3"| VIS
  classDef bad fill:#7f1d1d,color:#fff

Loading

4.4 Should packing be exposed to AT at all? No.

The brief asks the right question, and the answer is: packing is a purely visual affordance and
should be exposed as nothing.

C §5.6 proposes accessible names like "…Lane 2, third of five in this lane." That is noise:

• A lane index is a bin number from a first-fit pass. It carries no project meaning, is not
  something the user chose, and changes when an unrelated task's date changes.
• It is unverifiable and unactionable for a non-sighted user — there is no operation whose
  outcome depends on knowing it.
• It lengthens every single focus announcement, which is a measurable cost on every bar visited.

Recommendation:

• Lanes are role="presentation" — C already has this right.
• Accessible names carry project facts, not layout facts: name, type, dates, working days,
  progress, dependencies, outline position ("task 17 of 42"), selection state. Drop lane.
• C's live-region announcements should describe document changes ("Task created", "2 tasks
  deleted"), not shape changes ("chart is now 4 lanes"). A blind user's model does not contain
  lanes and does not need to.
• Offer lane information on demand only, if at all (e.g. a "describe layout" command), the way
  a chart's long description is opt-in.

The corollary is comforting: because packing is invisible to AT by design, the AT experience in
packed mode is identical to classic mode — which is the author's constraint, satisfied exactly.
That is only true if the per-task rows survive. Under C, it is false.

---

5. Cross-view linking — what the evidence actually says

The evidence base (RESEARCH_PEER §B), stated precisely because the two headline papers differ:

• Griffin et al. 2015 (IEEE TVCG 21(3), eye-tracking, coordinated adjacent views): leader
  lines and colour highlighting perform equivalently for information extraction (mean estimation
  error 0.69 colour vs 0.88 leader lines — not meaningfully different). Leader lines are "a viable
  alternative to color-based highlighting", and their advantage is that they free the colour
  channel to encode data.
• Steinberger et al. 2011 (IEEE TVCG 17(12), InfoVis Best Paper): visual links beat plain
  highlighting on speed and subjective satisfaction — but the setting was complex visualisations
  across separate windows, and context-preserving routing was needed to control clutter.

B's addendum A9 reconciles these correctly: links win when panes are far apart or the mapping is
ambiguous; adjacent panes tie. I agree with that reading and with the resulting rule
(highlight, don't draw persistent connectors, reserve one leader line for the genuinely
ambiguous case). That part of B's addendum is the best-argued paragraph in the whole Phase 1 set.

But B's linking model still has a hole, and it is the important one (R2-10). B §2 lists three
tiers: hover/selection highlight (transient), colour as the "always-on, no-interaction-required
binding cue", and an optional leader line (now cut). Verified against
src/types/colorMode.types.ts:11-16, OwnChart has five colour modes:

Mode	What colour identifies
manual	per task — only mode where colour can be an identity key, and only if the user picked distinct colours
theme	palette-assigned; repeats across tasks
summary	children inherit the parent's colour — colour = group
taskType	three colours total for the whole project
hierarchy	one hue lightened by depth — colour = depth

In four of five modes colour is a category channel. It cannot bind row↔bar. And B's own §2
Tertiary cites Griffin's "use leader lines when colour already carries a data attribute" — which
is an admission that colour is spent. B cannot simultaneously spend the colour channel on data
and use it as the identity key.

With colour out and the leader line cut, B has no always-on binding cue left, only transient
hover/selection. That is a real gap in the recommended design.

What it should be (my recommendation for Phase 3):

1. The always-on binding key is the task's own name on the bar. It is unique-ish, it is what
   the user searches for, it survives every colour mode and high-contrast, and it costs nothing
   new — TaskLabelPosition already exists. Corollary: in packed mode the label must be reliably
   present, which makes A §2.6's "suppress the label below ~24px" a bigger deal than A treats it,
   and makes B's addendum A5 (Notion's separate "what appears on the bar" visibility list) the
   right column-system investment.
2. Transient binding: bidirectional cross-highlight on hover and selection, driven by
   hoveredTaskId + data-task-id CSS so React.memo on TaskTableRow survives. B §2 has this
   right, and Apple HIG's split-view guidance (RESEARCH_PEER §A) endorses persistent selection
   highlight in every pane as the orientation mechanism.
3. Leader line: keep it, for exactly one case — the selected/focused task whose counterpart is
   off-screen or whose correspondence is otherwise ambiguous. B's addendum lands here; I'd only
   add that this is the Steinberger case (ambiguous correspondence, high clutter), so the
   evidence supports it rather than merely tolerating it.
4. Reveal (B §2 "Add — reveal") is the strongest single item in B's linking section and
   Bryntum's scrollToTaskOnClick is direct production precedent (B addendum A2.3). It also
   improves classic mode. Ship it early.

---

6. Naming: "Row Packing" / "Row Layout: One per Row / Packed"

A's analysis of what to reject is excellent and should be preserved wholesale: the
UiDensity.compact collision is real and made worse by the fact that its own description string
is "Shows more tasks on screen" (preferencesOptions.ts:59-63) — verbatim the new feature's
value proposition. "Swimlanes" correctly rejected and reserved. "Stacked" correctly rejected.
Using "Roll up" only for the hierarchy sub-behaviour, where it matches MS Project exactly, is
precisely right.

What I do not buy:

1. The placement premise is wrong (R2-7) — Density is in Format, so the "parallel structure
   next to Density" learning argument does not exist, and "Row Layout" collides with the View
   tab's existing Layout group.
2. "Packed" is jargon. A concedes PMs don't use it. Would a project manager reading
   Row Layout ▾ ( ) One per Row (•) Packed predict what happens? They will guess something
   compresses; they will not predict which thing, and "Packed" gives no clue that the compression
   is horizontal-by-time rather than vertical-by-height — which is exactly the confusion with
   Density that A is trying to prevent.
3. "One per Row" is under-specified — one what? The issue author's own phrasing is better:
   "one task per row".

Test against the density collision. The two settings must be distinguishable in one glance,
in one sentence each:

Setting	Sentence a PM would accept
Format › Display › Density	"How tall each row is."
View › Layout › Timeline rows	"Whether tasks that don't overlap in time can share a row."

Proposal:

View  ▸  Layout
  Timeline rows  ▾
    ● One task per row      Classic Gantt. Every task gets its own row.
    ○ Shared rows           Tasks that don't overlap in time share a row.
                            24 tasks fit in 4 rows.        ← live outcome

• Feature name in docs/changelog/help: Shared rows (with "row packing" as the internal /
  technical term; keep A's rowLayout: "single" | "packed" code identifiers and A's grep-guard
  banning compact in the packing module — both good).
• "Shared" is ordinary English, describes the mechanism truthfully, has zero collisions in this
  product's vocabulary, and — usefully — implies nothing about grouping, which directly serves
  §3.1. "Packed" implies containment; "shared" implies co-tenancy.
• The live outcome string is the important part, and no concept proposed it. It pre-empts A's
  own gate question (Part 8: "how many lanes do real charts produce?") at the point of use: if
  the answer is "24 tasks fit in 21 rows", the user sees that before switching and is not
  disappointed. When lanes == tasks, say "No rows can be shared in this project" and disable.

---

7. What all four concepts collectively missed

Gap	Why it matters	Proposed resolution
Touch / large tablets	The app blocks mobile at ≤768px AND coarse pointer (useDeviceDetection.ts:25-30) with a "Continue anyway" escape hatch — so wide touch devices (landscape iPad Pro, touch laptops) run the full app today. C's packed design leans hard on hover: the 400 ms hover card is "the read affordance that replaces looking at the row" (§2.4) and ConnectionHandles are hover-gated. On touch there is no hover → a packed-mode touch user has no read path for a narrow bar at all. Add the D-tool drag-create competing with touch panning.	Every hover-only affordance needs a tap equivalent in packed mode. Long-press → the same card. Do not make hover the primary read channel for anything
Undo discoverability	C §8's ruling (packing is never a command) is correct, but its consequence is unhandled: after a date drag that re-packs six unrelated bars, the user's first instinct is Ctrl+Z to "put the layout back". They will get their date back and a still-different layout, and conclude undo is broken	On any commit that relocates > N unrelated bars, show a toast: "Moved Design. 3 other tasks shifted to make room." + inline Undo. Names the cause, gives one obvious escape
Printing	There is no @media print anywhere in the codebase — verified. Export is the print path, so packed layout has to be right in PNG/PDF/SVG. Nobody covered the UX: at A4 width a packed chart's bars are far narrower than on a 2560px screen, so the label-suppression threshold fires and the export loses every label	The export preview must render the packed layout at export scale (not screen scale) so the user sees the label loss before exporting. Reuse the same pure pack() on both paths (D is right about that)
A third layout that only exists in export	A §3.5 suggests shipping overlap mode "as a read-only Overview toggle in the export dialog only". That is a display the user cannot see, edit, or verify on screen — a parity break by construction	Reject. If it cannot exist on screen, it should not exist in the export
Onboarding / help copy	WelcomeTour.tsx:52 ("Click the empty row to add tasks") and helpContent.ts gs-create-task / gs-move-tasks are written against the classic table. No concept drafted the replacement copy, and CLAUDE.md makes a help topic mandatory	Under B's panel both stay true — another point for B. Add one feat-view-shared-rows topic + one gs- mention. If a first-run user can land in shared rows (see below), the tour needs a mode-aware tip
A file can change your view (R2-8)	All concepts persist the mode in ViewSettings. Opening a shared .ownchart file therefore switches your display without asking — while the setting it claims to parallel (Density) is device-scoped in userPreferencesSlice. This directly touches "extend, don't replace": the app choosing your display for you is the silo feeling the author objects to	Persist as a user preference, with the file carrying an optional hint. If the file's hint differs, show a dismissible bar: "This project was saved in Shared rows. [Switch] [Keep One task per row]"
Empty state	There is no empty-state component. With 0 tasks, packed mode has 0 lanes and 0 chart height. C's flagship create paths ("double-click empty lane space", "drag in a lane") require a lane to exist, so the new mode's primary create gesture is unavailable in exactly the state where a new user starts	Define the empty state explicitly: at least one empty lane rendered, with an inline "Click anywhere to add your first task" hint. Or keep the placeholder row as the only create path at N=0 (another argument for B keeping the table)
Single-task / non-compressible charts	If every task overlaps every other, lanes == tasks and the mode does literally nothing. A flags this as the feature's gate (Part 8) — correct — but no concept makes the control honest about it	The live outcome string in §6 plus a disabled state with a reason
Error / overflow states	C §3.4 adopts FullCalendar's eventMaxStack "+N more" cap; A's tooltip promises "Nothing is hidden"; A §2.8 hides milestones behind ◆3. Three concepts, three different answers to "what if it doesn't fit", and they contradict (R2-12)	Pick one and make the copy match. My recommendation: never hide a task in an editing view. Prefer B addendum A8's shrink-to-a-floor-then-grow: shrink lane height to a floor, then add lanes. Clustering/+N belongs in export or an explicit overview, not in the editable chart
Very large charts, felt behaviour	There is no row virtualisation — TaskTable.tsx:159 maps every row. With B's clamped scroll, a 500-task project scrolls a 500-row list against a 4-lane chart that never moves. That is correct per B §5's arithmetic, but nobody has looked at whether it feels right	Prototype it (B's own uncertainty #3). It is ~10 lines. This should be resolved before Phase 3 commits
The "does this even compress?" gate	A Part 8 asks for totalRows / taskCount measured on real files and calls it "the gate on the whole feature". Nobody ran it	Run it before Phase 3. It is the cheapest decision-relevant measurement available and it can kill or confirm the feature in an afternoon

---

8. What to keep — the parts Phase 3 should not re-litigate

Not padding; these are the load-bearing correct decisions.

1. A's naming rejections (Compact / Condensed / Swimlanes / Stacked) and reserving
   "Swimlane" for a future semantic group-by. Also A's compact-is-banned-in-this-module lint
   guard.
2. A's D5: lane assignment is zoom-invariant. The three arguments (export correctness,
   intolerable reflow during a continuous gesture, cheap invariant) are all correct, and the
   "layout = f(dates); rendering = f(layout, zoom), height-neutral" split is the right shape.
3. A's D6 rollup-on-collapse — and note A and B converged on it independently (A §2.7 C
   via MS Project/DHTMLX auto; B addendum A2.3 via Bryntum Rollups + scrollToTaskOnClick).
   Independent convergence from two directions is the strongest signal in Phase 1. B's addendum
   goes further and is right: rollup glyphs on collapsed summary rows deliver much of Compact Mode #88's
   compression without breaking one-row-per-task at all. That is a genuinely smaller first step
   and it should be put to the author before committing to full packing.
4. A's rejection of a true overlapping single-line mode, on the grounds that it is the one
   display where feature parity is structurally impossible. That argument is exactly the right
   shape and it directly applies the author's own constraint.
5. B's option (e) and its parity-by-construction argument (fourteen "unchanged" rows).
6. B's §0 corrections to the shared brief — all three verified by me independently.
7. B's addendum A9 rule (adjacent panes → highlight, not connectors) and A10's DOM-order
   constraint — the latter should be promoted to a hard, tested requirement.
8. C's CRUD inventory: non-drag pointer paths (Move to… / Extend to… / Set progress… /
   Link to…), nudge mode, the freeze-packing-during-drag rule, the single-edit stability
   invariant, "packing is never an undoable command" with the purity test
   pack(doc) === pack(applyThenUndo(doc)), post-paste scroll-to, and the
   useTimelineAreaContextMenu Math.floor(svgY / rowHeight) bug (which should be fixed in
   classic mode today, independent of Compact Mode #88).
9. C's a11y framing as a release blocker, minus the incorrect "already failing" premise
   (R2-5) and minus the lane announcements (§4.4).
10. C's summary-overlap hazard (§6.2) — the observation that a summary overlaps every child by
    construction, so a naive packer gives each summary its own lane and the compression collapses.
    This is the single most important algorithmic warning in Phase 1. The rail is one answer;
    A's bands are another; they must be reconciled explicitly.

---

9. Recommended resolutions, in the order Phase 3 should decide them

1. Drop the Lane Ledger. Left panel = one row per task, always, in both modes (B option (e)).
   This removes eight parity breaks, keeps the WCAG compliance path intact, keeps the onboarding
   copy true, and makes the author's constraint achievable by construction.
2. Drop the Detail Strip; ship B's Inspector — docked, non-modal, no focus trap, switchable
   sections, present in both modes.
3. State the DOM-order constraint as a hard requirement and test it.
4. Expose nothing about lanes to AT; lanes are role="presentation", names carry project
   facts only, live regions announce document changes only.
5. Fix the three factual premises before planning: Density is in Format; classic mode passes
   2.5.7/2.1.1 for move/resize/progress but fails for dependency creation; colour is a category
   channel in 4 of 5 modes.
6. Rename: View › Layout › Timeline rows — "One task per row" / "Shared rows", with a
   live outcome string and a disabled state when nothing can be shared.
7. Suppress per-row grid rules in packed mode; keep only summary-band boundaries.
8. Never hide a task in an editing view. Reconcile A's "Nothing is hidden" promise with A's
   milestone clustering and C's +N more cap — my recommendation is shrink-to-floor-then-grow.
9. Resolve mode persistence as a user preference with a file hint and an explicit prompt.
10. Run A's compression measurement on real .ownchart files before building anything.

---

Reviewer: R2 — UX, Product Coherence & Accessibility

[kitikonti]

Review R3 — Codebase Ground Truth & Integration Feasibility

I am the fact-checker. I did not evaluate whether the designs are good; I checked whether they
are true about this repository. Every claim below was read out of main @ dd0165e (v1.7.9).

Headline results:

Claims checked	41
CONFIRMED	28
FALSE	4
PARTLY / imprecise	7
UNVERIFIABLE	2
New defects found while checking	3 (one live data-loss bug, two latent)

The two findings Phase 3 must not miss:

1. Concept D §4's central export claim is FALSE. Export does not ignore collapse state.
   There is an existing unit test that proves the opposite. The remediation D proposes
   (collapsedTaskIds in prepareExportTasks) is unnecessary and would add dead API surface.
2. Concept A's blast-radius estimate is wrong by roughly an order of magnitude. "A
   substitution of one integer" across "four sites" is really ~14 rendering/layout sites plus
   ~8 persistence sites plus new files — and A's own persistence file list omits the one file
   without which the feature silently never persists at all.

Concept C is the most factually accurate document of the four: I checked 11 of its file:line
citations and all 11 resolved within ±5 lines. Concept D is the most accurate on persistence and
performance and the least accurate on export. Concept B's corrections to the shared brief are
both right — and one of B's own claims is wrong in a way that matters for sizing.

---

1. Verification table

Source column: A / B / B-add (addendum) / C / D / brief (= the orchestrator's shared
CONTEXT.md, included because two of its claims were disputed).

1.1 The y = index * rowHeight coupling

#	Claim	Source	Verdict	Evidence
1	Every y funnels through getTaskBarGeometry at timelineUtils.ts:349	A	CONFIRMED	src/utils/timelineUtils.ts:349-372; y: headerHeight + rowIndex * rowHeight + taskBarOffset at :368
2	…plus three direct index * rowHeight sites: ChartCanvas.tsx:168, SelectionRows inside ChartCanvas, GridLines.tsx:190	A	FALSE (double-count + undercount)	ChartCanvas.tsx:168 is the SelectionRows line — SelectionRows spans :154-205 and const y = index * rowHeight at :168 is inside it. A counted one site twice. Meanwhile A misses layoutCalculations.ts:59, ChartCanvas.tsx:414, ChartCanvas.tsx:419, exportLayout.ts:128, pdfLayout.ts:410, ExportRenderer.tsx:388/:614, taskTableRenderer.ts:478/:663, useTimelineAreaContextMenu.ts:84. Full inventory in §3.
3	"The whole change is a substitution of one integer, not a rewrite"	A	FALSE	See §3. Even the minimal packing change touches ~14 render/layout files and ~8 persistence files.
4	elbowPath.ts:74 already has isSameRow / buildSameRowHookPath	A, D	CONFIRMED	isSameRow at elbowPath.ts:74, SAME_ROW_THRESHOLD_PX = 2 at :38, buildSameRowHookPath defined :144, called at :424 and :432 (A said 423/431 — those are the path = isSameRow(...) lines; effectively right). Also used at :102 inside buildElbowAtTurnX.
5	Same-row FS currently degenerates to buildStraightLine	D	CONFIRMED	buildElbowAtTurnX :100-102: if (isSameRow(from,to)) return buildStraightLine(from,to). FS with gap >= minGapForElbow goes to buildTwoCornerPath (:418), which shares the same degeneracy. D's diagnosis that this becomes the common case under packing is correct.
6	ROUTING_OFFSET_RATIO = 0.4 scales the SS/FF hook dip	D	CONFIRMED	elbowPath.ts:201: rowHeight * ROUTING_OFFSET_RATIO.
7	useTimelineAreaContextMenu does Math.floor(y / rowHeight) and breaks under packing	C, D	CONFIRMED	src/hooks/useTimelineAreaContextMenu.ts:84: const rowIndex = Math.floor(svgY / rowHeight); then tasks[rowIndex].id at :88.
8	…and it is also wrong today ("silently mis-targets whenever tasks and visual rows disagree")	C (concept C2, rows table)	FALSE — it is correct today	svgY = e.clientY - svgRef.getBoundingClientRect().top and every bar is placed with headerHeight: 0 (ChartCanvas.tsx:331), so row i occupies exactly [i·rowHeight, (i+1)·rowHeight) inside that same SVG. tasks here is orderedTasks — the same visible list the bars are drawn from. There is no disagreement to exploit. C's fix (point-in-rect against taskGeometriesArray) is still the right call, but the justification "already broken" is not true and Phase 3 should not sell it as a bug fix.
9	ChartCanvas.taskGeometries is the injection point for packed y	B, brief	PARTLY — there are three, not one	Bar y is computed independently in three places: ChartCanvas.tsx:325 (marquee + connection handles only), TaskBar.tsx:316 (the bar that is actually drawn), DependencyArrows.tsx:81 (arrow endpoints). Patching only taskGeometries would move the hit-testing and the handles while leaving the bars where they are. This is a real sizing error, not a nitpick.
10	SelectionRows (ChartCanvas.tsx:151-196) must be rewritten, border-merge logic deleted	C	CONFIRMED (line range off by ~3/9)	Actual span :154-205; prevSelected/nextSelected merge logic at :166-169, borders at :177-202. C's substantive point stands: lane adjacency is chronological, not selectional, so the merge is meaningless under packing.
11	SelectionHighlight.tsx is the date-range band, not row selection; row-band logic is inline SelectionRows with a table twin at RowOverlays.tsx	B (correcting brief)	CONFIRMED — B is right, the brief was wrong	SelectionHighlight.tsx:1-5 docblock: "Shared SVG overlay for header date range selection… Used in both TimelineHeader (GanttLayout) and ChartCanvas"; it draws one <rect x={rect.x} y={0} height={height}> — a vertical band, no row concept. Table twin confirmed: RowOverlays.tsx:37-38 (showTopBorder/showBottomBorder) fed by useTaskRowData.ts:68-69 (isFirstSelected: !prevTaskId || !selectedSet.has(prevTaskId)). Two files, two fixes, and the table-side twin is a third.
12	Scroll model: ONE vertical driver + translateY on both panes; useSyncScroll horizontal-only	B (correcting brief)	CONFIRMED — B is right, the brief was wrong	GanttLayout.tsx:159 <div ref={outerScrollRef} data-scroll-driver className="flex-1 overflow-y-auto…">; :100-115 scroll handler writes transform: translateY(-${top}px) to both taskTableTranslateRef and chartTranslateRef; :93-95 useSyncScroll(chartContainerRef, timelineHeaderScrollRef) and useSyncScroll(taskTableScrollRef, taskTableHeaderScrollRef) — both horizontal; usePreventVerticalScroll(taskTableScrollRef) at :95 (usePreventVerticalScroll.ts:23 forces scrollTop = 0).

Consequence of #12 that no concept drew out — see MAJOR-1 in §4. One scroll height, two
panes of different content height, is a new problem, not a solved one.

1.2 Selection, interaction, density

#	Claim	Source	Verdict	Evidence
13	useMarqueeSelection hit-tests bar rects, not rows → works packed for free	B, C	CONFIRMED	useMarqueeSelection.ts:131-138 findIntersectingTaskIds → tasks.filter(t => rectsIntersect(normalized, t)) over TaskGeometry[]; geometries supplied from ChartCanvas.tsx:369-374 = taskGeometriesArray built at :317-353. Independently confirmed for both B and C.
14	…caveat neither concept states	R3	—	taskGeometriesArray skips tasks failing if (!task.startDate || (!task.endDate && task.type !== "milestone")) (ChartCanvas.tsx:319-321), so date-less tasks are already unmarquee-able. Under packing this becomes visible ("why can't I rubber-band that bar"). Worth one line in the sprint doc.
15	EDGE_THRESHOLD = 8 already fails on bars under 24px	C	PARTLY — the real cliff is 16px	taskBarDragHelpers.ts:27 EDGE_THRESHOLD = 8; detectInteractionZone :98-102 returns left-edge for relativeX < 8, right-edge for relativeX > width - 8. At width ≤ 16 the centre zone is empty (left-edge wins outright); at 16–24 it exists but is 0–8px. C's own prose at concept_C1:271 gets this right ("on a 12px bar the two edge zones overlap"); the 24px figure in the summary table is the loose one. Fix effectiveEdge = min(8, floor(width/3)) is sound.
16	This is an existing latent bug that packing makes common	C	PARTLY	Existing: yes, at low zoom (MIN_ZOOM = 0.05, timelineUtils.ts:32 — confirmed). But EDGE_THRESHOLD is a horizontal threshold on bar width; packing changes only vertical placement. Packing does not make narrow bars more common. What makes it more common is that packing removes the vertical excuse for horizontal zoom-out. Real but indirect — Phase 3 should not book it as caused by #88.
17	PROGRESS_HANDLE.minBarWidth = 30 gate is already correct, progress drag is geometry-relative	C	CONFIRMED	TaskBar.tsx:69 minBarWidth: 30, gate at :603; useProgressDrag.ts:27-42,:69 reads geometryRef.current.{x,width} only — no row/index.
18	Density naming collision: compact = 28px preset, labelled "Compact / Shows more tasks on screen"	brief, A, D	CONFIRMED	densityConfig.ts:9-10 compact: { rowHeight: 28 }, :33-34 normal: 36, :57-58 comfortable: 44; preferencesOptions.ts:59-62 label: "Compact", description: "Shows more tasks on screen". D's recommendation to persist the key as rowLayoutMode regardless of the marketing name is well-founded.
19	Alt+Shift+Arrow = indent/outdent, so Alt+drag is unavailable	C	CONFIRMED	useKeyboardShortcuts.ts:311-320 handleIndentShortcuts — if (!e.altKey || !e.shiftKey …) return false.
20	EDITABLE_FIELDS at src/types/task.types.ts:54; navigateCell at taskSlice.ts:764	C	CONFIRMED	Both exact. (Aside: the project's own MEMORY.md still says EDITABLE_FIELDS is at taskSlice.ts:134. C is right and the memory file is stale — worth fixing separately.)
21	selectTaskRange selects an outline index range (selectionActions.ts:31-56)	C	CONFIRMED	selectionActions.ts:31-51. C's Ctrl+Shift+click = chronological-range proposal addresses a real gap. Note also selectAllTasks (:53-56) uses state.tasks and ignores hiddenTaskIds — pre-existing, unrelated.
22	contextMenuItemBuilders.ts:155-165 holds the "Insert Task Above/Below" labels	C	CONFIRMED	src/hooks/contextMenuItemBuilders.ts:152-168. Label swap is genuinely a one-file change.
23	Milestone diamond is 2 × clamp(pixelsPerDay/2, 6, 10) px regardless of zoom	A	CONFIRMED	TaskBar.tsx:39-40 MILESTONE_SIZE_MIN = 6 / MAX = 10. A's derived point — at 5% zoom a 20px diamond spans ~22 days — is arithmetically right and is a genuine packing hazard nobody else raised.

1.3 Export pipeline

#	Claim	Source	Verdict	Evidence
24	ExportRenderer calls buildFlattenedTaskList(tasks, new Set())	D	CONFIRMED (the code)	ExportRenderer.tsx:264 and :524; also svgExport.ts:504, pdfLayout.ts:409, pdfExport.ts:858, exportLayout.ts:256.
25	"Export ignores task.open === false entirely" / "export already ignores collapse state"	D (§4, and summary row 5)	FALSE	buildFlattenedTaskList (hierarchy.ts:419-449) decides collapse at :440: const isCollapsed = task.open === false || collapsedTaskIds.has(task.id); — the open === false half is unconditional. Passing an empty Set changes nothing. There is a dedicated unit test asserting exactly this: tests/unit/utils/hierarchy.test.ts:811-822 — "should respect task.open === false" — calls buildFlattenedTaskList(tasks, new Set()) and expects the child absent. Corroborating: useFlattenedTasks.ts:40-44 builds collapsedIds as precisely {t : t.open === false}, i.e. the parameter is redundant at every call site in the codebase. Screen and export apply identical collapse rules today.
26	Therefore prepareExportTasks needs a collapsedTaskIds context field	D	FALSE (follows from #25)	Would be a no-op filter over an already-collapsed set. Adds API surface, tests, and a doc contract for nothing. Delete this from Phase 3.
27	ExportRenderer is the timeline SVG shared by all three formats	D	CONFIRMED	PNG: captureChart over the offscreen container. SVG: svgExport.ts:226 container.querySelector('svg.' + EXPORT_CHART_SVG_CLASS) then cloneSvgIntoGroup at :395. PDF: pdfExport.ts:412 same selector → buildCompleteSvg(:427). All three read the offscreen ExportRenderer output.
28	exportLayout.ts:128 and pdfLayout.ts:410 compute height from task count	D	CONFIRMED	exportLayout.ts:128 taskSize.count * taskSize.rowHeight; pdfLayout.ts:410 flattenedTasks.length * densityConfig.rowHeight + contentHeaderHeight. D is the only concept that found pdfLayout.ts — and its warning ("miss this one and the PDF silently over-allocates height, chart floating in whitespace, no error") is exactly right.
29	taskTableRenderer.ts:478 rowY = startY + rowIndex * rowHeight — leave it	D	CONFIRMED as code; the decision is contested — see CONTRADICTION-2
30	"prepareExportTasks / svgExport / pdfExport can call buildLaneLayout identically, so the CLAUDE.md single-source rule is satisfied for free"	A	FALSE (category error)	prepareExportTasks.ts is a pure membership filter — Task[] → Task[], with an optional working-days duration transform. It has no rendering role and no y-coordinate concept; calling a lane-layout function from it is meaningless. The CLAUDE.md rule is satisfied vacuously for packing (packing removes no tasks), which is what D says correctly at concept_D:409. A reaches the right conclusion from a wrong premise.
31	Concept B honours the CLAUDE.md prepareExportTasks rule	—	FALSE — B never mentions it	grep -c prepareExportTasks concept_B.md → 0. B also never mentions multiTabStorage. Concept C1: 0 mentions, C2: 1 (adequate). A: 2 (but see #30). D: 7 (thorough).

1.4 Persistence & file format

#	Claim	Source	Verdict	Evidence
32	ViewSettings has no unknown-field preservation, unlike SerializedTask / SerializedDependency / GanttFile	D	CONFIRMED	types.ts:63-65 GanttFile: "CRITICAL: Preserve unknown fields from future versions" + [key: string]: unknown. types.ts:88-90 SerializedTask: same. ViewSettings types.ts:92-141 ends at projectLogo?: ProjectLogo; — no index signature. Re-emission machinery exists only for tasks (serialize.ts:126-137) and deps (serialize.ts:158-176).
33	…and save rebuilds ViewSettings from the store, so newer fields are erased on old-app round-trip	D	CONFIRMED — this is a live bug	deserialize.ts:490 return { ...raw, … } does preserve unknown keys through parsing, but applyViewSettingsDefaults (loadFromFile.ts:78) enumerates explicitly, and the decisive step is the save side: useFileOperations.ts:440-450 useViewSettings = { ...useLayoutViewSettings, ...useFeatureViewSettings }, each a closed Pick<> literal (:298-360, :369-433). The store never held the field, so it cannot be written back.
34	A live instance of #33 exists today	R3 (new finding)	CONFIRMED	ViewSettings.workingDaysMode (types.ts:117) is read by deserialize.ts:511 but appears in neither Pick<> on the save side, and grep workingDaysMode src/store/slices/chartSlice.ts → nothing. So any v1.7.9 open-then-save of an older file drops workingDaysMode from the file. Benign now (WD arithmetic is always-on since b644186), but it is a working demonstration that D's mechanism is real, not theoretical.
35	New ViewSettings fields require touching viewSettingsDefaults.ts, serialize.ts, validate.ts, multiTabStorage.ts	A	PARTLY — 2 of 4 right, and the critical file is missing	serialize.ts needs no change (it does viewSettings: { ...viewSettings } at :60). validate.ts needs no per-field change. What A omits is fatal: useFileOperations.ts (useFeatureViewSettings, :369) — without it the field is never written to any file, so the feature appears to work in-session and silently loses state on save/reload; and deserialize.ts normalizeViewSettings — without it the field is unvalidated. Also missing: loadFromFile.ts, chartSlice SettableViewFields, useMultiTabPersistence.ts.
36	D's persistence file list (types.ts, deserialize.ts, viewSettingsDefaults.ts, useFileOperations.ts, multiTabStorage.ts:48-77, useMultiTabPersistence.ts)	D	CONFIRMED, complete	All exist and all are correct targets. useFileOperations.ts:367 even carries the warning comment D cites ("The dep array necessarily mirrors the factory object keys — both must be kept in sync when a new ViewSettings field is added"). D's §5 is the single most implementation-ready section in the four concepts.
37	No migration needed; migrations Map stays empty	D	UNVERIFIABLE at the line level, sound in principle	I did not open migrate.ts:28. The reasoning (additive, optional, changes no existing field's semantics, applyViewSettingsDefaults supplies the default) matches how hiddenTaskIds / hiddenColumns were added.

1.5 Scheduling, performance, accessibility

#	Claim	Source	Verdict	Evidence
38	src/utils/graph/* is index-free, so auto-scheduling is unaffected	D	CONFIRMED	src/utils/graph/{cycleDetection,dateAdjustment,graphHelpers,topologicalSort,computeWorkingDaysRecalc,index}.ts. Every index hit is a Map-lookup index or topological ordering; zero references to rowIndex, rowHeight, or array-position-as-row. D's proposed invariant test is cheap and worth having.
39	Drag preview is local component state; packing does not re-run per frame	D	CONFIRMED, with one caveat	useTaskBarInteraction.ts:411 useState<DragState | null> + :412 dragStateRef; commits only in executeDragMoveCommit (:304) / executeResizeCommit (:357) on mouseup. state.tasks is untouched during the gesture ⇒ flattenedTasks identity stable ⇒ no re-pack. Caveat: there is a per-frame store write — setSharedDragState(deltaDays, task.id) at :478 → chartSlice.setDragState (:1183-1187). It does not change dates, so packing is safe, but any component that both subscribes to dragState and derives lanes would re-pack. Phase 3 should state the rule explicitly: lane derivation must not read chartSlice.dragState. D's "freeze the layout on mousedown" recommendation (§ mouseup lane snap) needs to store the frozen layout somewhere that is not re-derived — its suggestion to hang it off dragState is in tension with the rule it just relied on.
40	Task bars have no role / no aria-label; the task table is the entire accessible representation	B, C	CONFIRMED	grep 'role=|aria-|tabIndex' src/components/GanttChart/{ChartCanvas,TaskBar}.tsx → zero hits. Across all of src/components/GanttChart/*.tsx there are exactly two: DependencyPropertiesPanel.tsx:241 role="dialog" and DependencyArrow.tsx:116 role="graphics-symbol". Meanwhile TaskTable.tsx:146 role="grid", TaskTableRow.tsx:162-164 role="row" + aria-rowindex, Cell.tsx:179/:225 role="gridcell".
41	TaskTable should be role="treegrid", not role="grid" — pre-existing bug	B	CONFIRMED	TaskTable.tsx:146 role="grid"; the same tree has aria-expanded on the expander (TaskDataCells.tsx:289) and nested parent-based hierarchy. W3C APG: choose Treegrid when rows nest. Genuine pre-existing defect, correctly scoped as independent of #88.
42	SC 2.1.1 and SC 2.5.7 are already failing in classic mode	C	CONFIRMED for 2.1.1; PARTLY for 2.5.7	2.1.1: confirmed — no tabIndex on any bar, no keyboard move/resize anywhere in useKeyboardShortcuts.ts, so bar move/resize is mouse-only. Clean failure. 2.5.7: the SC requires a single-pointer non-dragging alternative, and one arguably exists today: the startDate / endDate / duration cells in the table are pointer-editable, which is a non-drag path to the same outcome. C's own §7 cites the "Equivalent" reasoning for 2.5.8; the same reasoning weakens its 2.5.7 claim in classic mode. In packed mode, if the per-task table row goes away, the alternative goes with it and 2.5.7 becomes a hard, newly-introduced failure. So: C's conclusion (build "Move to… / Extend to…" pointer paths) is right; the framing "already failing" overstates it for 2.5.7 and understates the risk that #88 creates the failure.
43	aria-rowindex is set but aria-rowcount is not	R3 (new finding)	CONFIRMED	TaskTableRow.tsx:164 sets aria-rowindex={globalRowNumber}; no aria-rowcount anywhere in src/. aria-rowindex without aria-rowcount on the grid is under-specified — screen readers announce "row 7" with no "of N". Pre-existing; and note globalRowNumber is deliberately gappy under hiddenTaskIds (useFlattenedTasks.ts:47-52), which makes the missing count worse. Any Phase-3 table redesign inherits this.

---

2. Cross-concept contradictions on matters of fact

CONTRADICTION-1 — how hard are same-lane dependency arrows? (A vs D vs B-addendum)

Three different factual postures on the same code:

• A (concept_A:130): "The hardest-sounding consequence of packing already has a rendering
  path. It will need stress-testing, not inventing."
• D (concept_D:273-285): correctly notes that today isSameRow fires only on
  milestone/rounding coincidences, that same-row FS degenerates to a straight line (not a
  hook), and proposes a real gutter + buildSCurvePath change.
• B-addendum (A1): Airtable ships Gantt-layout and swimlane-stacking as mutually exclusive
  modes, and its Gantt layout requires one-record-per-lane. B concludes packing and arrows
  may not be simultaneously legible and arrows should possibly default off.

Ground truth: D is right and A is wrong. buildSameRowHookPath is reachable only from the
FF and SS branches (elbowPath.ts:423-434). For FS — by far the most common dependency
type and the one packing produces most often, since first-fit places chained predecessor→successor
pairs in the same lane — same-row hits buildStraightLine via buildElbowAtTurnX:100-102 or
buildTwoCornerPath. A straight horizontal line between two abutting bars in one lane is
invisible: it has zero length when the gap is zero and is indistinguishable from the lane
itself when it is small. A's "already has a rendering path" is false for the case that matters.

Resolution for Phase 3: treat same-lane FS routing as new work, sized as such. Adopt D's
gutter approach. And take B-addendum's warning seriously enough to make "arrows in packed mode"
an explicit product decision with a default, not an assumed capability.

CONTRADICTION-2 — does the left table stay one row per task?

• D (concept_D §4 item 4): "The left table stays one row per task in both modes."
• C (concept_C1:11, :249-257): the table "changes granularity" — replaced by a ledger
  plus a single-row Detail Strip bound to the focused task, i.e. the N × 7 cell grid collapses
  to 1 × 7.

These are not reconcilable. They imply different work in taskTableRenderer.ts, different export
output, and different a11y consequences (C's design removes the per-task rows that finding #40
identifies as the only accessible representation — C acknowledges this and proposes a
tree/treeitem canvas; D's design sidesteps it entirely).

Resolution: Phase 3 must pick one before sizing anything. My read: D's "table unchanged" is
the safe Phase-1 shipping position (it preserves a11y, export, and aria-rowindex for free);
C's ledger + Detail Strip is the better end state but is a second, larger project. Do not blend
them — a half-ledger is worse than either.

CONTRADICTION-3 — where does lane assignment live?

A (:207) puts buildLaneLayout in a useMemo; D (:13-14, :46) is emphatic it must be a pure
module + useRowLayout hook drilled from GanttLayout, explicitly not a store selector,
because "Zustand selectors re-run on every store change; packing must be memoized on a content
key, not on object identity."

D is right, and the reason is verifiable: useFlattenedTasks.ts:38-44 memoizes on tasks
identity, and Immer produces a new tasks array on every mutation including a single
keystroke in an inline name edit. A naive useMemo(..., [flattenedTasks]) would re-pack per
keystroke. D's packKey proposal (:540-560) is the correct mitigation and A does not have one.
Take D's architecture, A's algorithm.

CONTRADICTION-4 — ChartCanvas.taskGeometries as "the injection point"

B (and the brief's late correction #5) say it is the injection point. Verified false at #9 —
there are three. C is implicitly correct here: concept_C1:187 says "Those geometries come from
getTaskBarGeometry({rowIndex: index, …}) in ChartCanvas.tsx:320. Swap index for laneIndex
and marquee selection is packed-mode-correct" — C correctly scopes the win to marquee, not
to rendering. B over-generalises.

---

3. True blast radius

Consolidated and corrected. "Est." is my own estimate of net changed lines, not the concepts'.

3.1 Rendering / layout (must change for the minimal feature)

File	LOC	What breaks	Est.	Who found it
src/utils/timelineUtils.ts	451	getTaskBarGeometry rowIndex semantics (:349-372)	5–15	A, D
src/components/GanttChart/ChartCanvas.tsx	583	taskGeometries :325; SelectionRows :154-205; taskBasedHeight :414; rowCount :417-420; GridLines taskCount :445	80–150	A, B, C, D
src/components/GanttChart/TaskBar.tsx	687	independent geometry at :316	10–25	D
src/components/GanttChart/GridLines.tsx	258	:189-194 lines + gridHeight	10–20	A, D
src/components/GanttChart/DependencyArrows.tsx	183	independent geometry at :81	15–30	D
src/utils/arrowPath/elbowPath.ts	~500	same-lane FS routing (CONTRADICTION-1)	40–90	D
src/hooks/useTimelineAreaContextMenu.ts	143	:84 Math.floor(svgY/rowHeight)	20–35	C, D
src/utils/layoutCalculations.ts	71	:59 (taskCount + PLACEHOLDER_ROW_COUNT) * rowHeight — the scroll-height driver	15–30	only D
src/components/Layout/GanttLayout.tsx	225	:151-158 taskCount: flattenedTasks.length; two-pane height divergence (MAJOR-1)	30–80	only D (partially)
NEW src/utils/layout/packRows.ts	—	pure packer + resolver	150–250	D (A supplies algorithm)
NEW src/hooks/useRowLayout.ts	—	memo + packKey + stability ref	40–70	D

3.2 Export (must change, or PNG/PDF/SVG silently disagree with screen)

File	LOC	What breaks	Est.	Who found it
src/components/Export/ExportRenderer.tsx	623	:388, :461, :481-490, :614	50–90	D
src/utils/export/exportLayout.ts	396	:128 content height	10–20	D
src/utils/export/pdfLayout.ts	495	:410 page-fit height	10–20	only D
src/utils/export/taskTableRenderer.ts	681	table/timeline height reconciliation :478, :663	20–60	D
src/utils/export/svgExport.ts	682	table vs cloned-chart vertical alignment	20–50	none explicitly
src/utils/export/types.ts + src/components/Export/SharedExportOptions.tsx	—	rowLayoutMode export option	40–70	D

Note on prepareExportTasks.ts: no change required. Packing removes no tasks, and #25/#26
kill the only proposed change. The right action is D's doc-only @see note.

3.3 Persistence (8 files; miss any one and state silently fails to round-trip)

fileOperations/types.ts · fileOperations/deserialize.ts (normalizeViewSettings) ·
config/viewSettingsDefaults.ts · fileOperations/loadFromFile.ts ·
hooks/useFileOperations.ts (useFeatureViewSettings:369 — the one A missed) ·
store/slices/chartSlice.ts (SettableViewFields + setViewSettings) ·
utils/multiTabStorage.ts (ChartState:48-77) · hooks/useMultiTabPersistence.ts.
Est. 80–140 lines. serialize.ts and validate.ts need nothing.

3.4 Shell / rules (project rules make these mandatory)

src/config/helpContent.ts (CLAUDE.md rule: user-facing feature ⇒ help topic) ·
src/hooks/useViewTabActions.ts + src/components/Ribbon/ViewTabContent.tsx (the toggle) ·
src/hooks/useKeyboardShortcuts.ts (if a shortcut) ·
src/components/TaskList/RowOverlays.tsx + src/hooks/useTaskRowData.ts (only if the table
changes — CONTRADICTION-2). Est. 60–120 lines.

Total: 25–31 files, 700–1,400 net lines, before any of Concept C's UX surface (Detail Strip,
tool mode, nudge mode, ledger, tree canvas) which is a comparable amount again. This is a
multi-sprint epic, not "a substitution of one integer."

---

4. Integration feasibility

MAJOR-1 (BLOCKER-adjacent) — one scroll height, two pane heights. Nobody solved this.

Finding #12 establishes there is exactly one vertical scroll driver, sized by
calculateLayoutDimensions({ taskCount: flattenedTasks.length, rowHeight, … })
(GanttLayout.tsx:151-158 → layoutCalculations.ts:59), whose handler translates both panes
by the same -scrollTop.

Under packing the table needs N rows and the timeline needs L ≤ N lanes. One height, one
delta, two different content extents. The consequences are unavoidable and unaddressed:

              table pane            timeline pane
              (N rows)              (L lanes)
  scrollTop=0 ┌───────────┐        ┌───────────┐
              │ task 1    │        │ ▓▓▓  ▓▓▓  │  lane 0
              │ task 2    │        │  ▓▓▓▓ ▓▓  │  lane 1
              │ …         │        │           │  <- dead space
              │ task N    │        │           │
              └───────────┘        └───────────┘
   scroll to  │ task N    │        │           │  table still has content,
   bottom     └───────────┘        └───────────┘  timeline ran out L·h ago

Options are (a) totalContentHeight = max(N, L) · rowHeight and accept that the timeline is
mostly whitespace — which destroys the entire point of the feature; (b) let the timeline pane grow
its own lane height so L · laneHeight ≈ N · rowHeight — which also destroys the point;
(c) decouple the panes into two scroll containers — which un-does the architecture B correctly
identified and reintroduces sync complexity; (d) change what the left pane is (Concept C's
ledger), which is CONTRADICTION-2.

D touches the edge of this (concept_D §4 item 4: "the panel heights disagree… top-align, total
canvas height = max(N,L)·rowHeight") but only for export, where it is a static-canvas problem.
On screen it is a scrolling problem and much harder. Phase 3 must resolve this explicitly; it
is the single largest unanswered architectural question in the four concepts, and it is
upstream of the naming, the algorithm, and the UX.

MAJOR-2 — the proposed Phase-0 gate is achievable but proves almost nothing

D's gate: "after the resolver refactor npm run test:vrt must pass with zero baseline
changes… a pixel-exact proof of no-behaviour-change."

Achievable: yes, trivially. Sufficient: no, and it is worse than it sounds. The VRT suite
is 9 baselines (tests/e2e/visual-regression.spec.ts-snapshots/):

empty-app-shell · file-menu-open · full-app-with-data · ribbon-format-tab ·
ribbon-help-tab · ribbon-home-tab · ribbon-view-tab · status-bar · task-table-populated

Five of nine are ribbon/menu chrome and cannot regress from a row-geometry change at all. The
empty-state test explicitly masks the timeline region (visual-regression.spec.ts:89-90).
That leaves full-app-with-data and task-table-populated — and DEFAULT_SAMPLE_TASKS
(tests/e2e/fixtures/sample-data.ts:21+) is 7 tasks with dependencies = [] (:160) at a
single fixed viewport and the default density only, with maxDiffPixelRatio: 0.01
(:36 — ~9,200 pixels of tolerance at 1280×720).

So the gate would not catch: any dependency-arrow routing regression (zero arrows in the
fixture), any regression at compact/comfortable density, milestone rendering (one milestone,
one lane, no packing pressure), selection-band rendering (nothing is selected), hiddenTaskIds
gap behaviour, scroll-position restore, or any export output at all — PNG/PDF/SVG are not in
VRT.

Resolution: keep the gate (it is free) but do not treat it as the proof. The real Phase-0
no-regression gate must be:

1. npm run ci:local green — 5,239 unit tests, of which 746 live in the 28 files that reference
   row geometry (hierarchy 75, elbowPath 69, svgExport 56, contextMenus 54,
   renderConstants 51, timelineUtils 42, taskTableRenderer 41, useHideOperations 38,
   useTaskRowData 31, TaskBar 28, GridLines 21, DependencyArrow 21, …). Those 746 are the
   real safety net; if list mode is genuinely the identity case, all 746 pass untouched. That
   is a far stronger and far cheaper statement than 9 screenshots and Phase 3 should adopt it as
   the headline gate.
2. All 190 E2E pass untouched (~89 of them sit in row/bar-coupled specs, led by
   dependency-scheduling.spec.ts with 40).
3. Add 3–4 VRT baselines before Phase 0, not after — timeline-with-dependencies,
   compact density, comfortable density, multi-selection — so the gate has something to bite on.
   Generated in Docker via npm run test:vrt:update, per CLAUDE.md.
4. A golden-file assertion that screen lane count == calculateExportDimensions lane count on a
   shared fixture. D proposes exactly this (concept_D:411) and it is the best single test in
   any of the four concepts.

MAJOR-3 — three geometry sites, not one (finding #9)

Any Phase-3 plan that says "change taskGeometries" will produce a build where marquee selection
and connection handles land in the packed positions and the bars do not move. The fix is
architectural, and D already specifies it (concept_D:189: "Every renderer takes
resolver: RowResolver and asks for a y. Nobody computes index * rowHeight"). Adopt that, and
add a lint rule or a test that greps src/components/GanttChart/ for rowIndex: to keep it true.

MINOR — taskGeometriesArray skips date-less tasks (#14); EDGE_THRESHOLD is horizontal, so packing is not its cause (#16); useTimelineAreaContextMenu is correct today (#8).

---

5. What is solid — Phase 3 should keep these without re-litigating

• Concept D §5 (persistence). Complete, correct, line-accurate, and it found a real
  pre-existing bug (Bulk editing for multi-selected tasks #32/Review and redesign settings dialogs #33) with a working demonstration (Logo embedding for chart exports #34). Take it as written, including
  the recommendation to close the ViewSettings unknown-field hole in a separate PR first.
• Concept D's RowResolver + packKey architecture (CONTRADICTION-3). The Immer-identity
  argument is verifiable and A has no answer to it.
• Concept D's mouseup lane-snap analysis (:566-574). The premise (PDF export preview does not match actual export result #39) is confirmed and the
  conclusion — the danger is the snap, not per-frame packing — is exactly right and non-obvious.
  One correction: do not park the frozen layout on chartSlice.dragState, which is written every
  frame at useTaskBarInteraction.ts:478.
• Concept D's pdfLayout.ts:410 catch. The only concept that found it; the failure mode it
  describes is silent.
• Concept C's file:line discipline. 11/11 citations resolved. Its EDITABLE_FIELDS
  reference is more current than the project's own MEMORY.md.
• Concept C's marquee finding (Color features are not saved into file #13), correctly scoped (CONTRADICTION-4).
• Concept B's two corrections to the shared brief (App crashes when switching form task to summary #11, When creating a new chart milestones does not get an end date in the saves file which results in an error when opening the file #12). Both right, both load-bearing,
  and When creating a new chart milestones does not get an end date in the saves file which results in an error when opening the file #12 is what surfaces MAJOR-1.
• Concept A's date-space-not-pixel-space argument and its milestone-diamond hazard (Compact/collapsed view for task groups #23).
  A's algorithm is sound; it is A's cost estimate and export reasoning that fail.

---

6. Actions for Phase 3

#	Action	Severity	From
1	Resolve the two-pane scroll-height problem before anything else.	BLOCKER	MAJOR-1
2	Delete D's collapsedTaskIds addition to prepareExportTasks and the "export ignores collapse" premise.	BLOCKER (wrong as specified)	#25, #26
3	Re-cost the feature. ~25–31 files, 700–1,400 lines minimum. Discard "one integer".	BLOCKER	#3, §3
4	Pick one answer to CONTRADICTION-2 (table stays / table becomes a ledger) before sizing.	BLOCKER	CONTRADICTION-2
5	Treat same-lane FS arrow routing as new work, not existing capability. Decide whether arrows are even on by default in packed mode.	MAJOR	CONTRADICTION-1
6	Replace the VRT gate with "746 row-coupled unit tests + 190 E2E pass untouched"; add 3–4 chart-focused baselines before Phase 0.	MAJOR	MAJOR-2
7	Rewire all three geometry sites via RowResolver; guard with a test.	MAJOR	#9, MAJOR-3
8	Add useFileOperations.ts + deserialize.ts to the persistence file list (A's list is missing both).	MAJOR	#35
9	Add layoutCalculations.ts, GanttLayout.tsx, pdfLayout.ts, svgExport.ts to the file list.	MAJOR	§3
10	Fix the SC 2.5.7 framing: it is a risk created by removing per-task rows, not a pre-existing failure. Bank 2.1.1 as pre-existing.	MINOR	#42
11	Adopt D's screen-lane-count == export-lane-count assertion.	MINOR	MAJOR-2
12	Spin off as independent bug fixes: ViewSettings unknown-field loss; role="grid" → treegrid; missing aria-rowcount; stale MEMORY.md EDITABLE_FIELDS line.	MINOR	#32, #41, #43, #20

---

Reviewer: R3

[kitikonti]

Review R1 — Algorithmic Correctness, Layout Semantics & Performance

Adversarial pass over Concept A (packing engine), with cross-checks into C (§8 undo purity, §"deterministic stable sort") and D (§6 memoization, §"the drag trap", §"arrows"). Every code claim below was re-read in main @ v1.7.9. I also ran the measurement A said should gate the whole feature — results in §3; they are the most important part of this review.

Verdict in one line: the pipeline A designed is sound and I would keep almost all of it, but the two decisions A argued hardest for are the two that do not survive contact — D6 (band per summary) makes the feature nearly worthless on ordinary project data (measured), and A's central de-risking claim about same-lane dependency arrows is factually wrong about the code it cites.

---

1. Source-verification scoreboard

Every claim I could check. ✅ = verified, ❌ = falsified, ⚠️ = true but materially misleading.

#	Claim (source)	Status	Evidence
1	getTaskBarGeometry at timelineUtils.ts:349, y = headerHeight + rowIndex*rowHeight + taskBarOffset (A §2.1)	✅	timelineUtils.ts:349, :368
2	ChartCanvas.tsx:168 const y = index * rowHeight (A §2.1)	✅	exact
3	GridLines.tsx:190 y: i*rowHeight, :194 gridHeight = taskCount*rowHeight (A §2.1, Part 7.3)	✅	exact
4	MIN_ZOOM = 0.05 at timelineUtils.ts:32; PRESET_ZOOM_LEVELS (A §2.6, Part 4)	✅	exact
5	MILESTONE_SIZE_MIN/MAX = 6/10 at TaskBar.tsx:38-40; size clamp at :452-457 (A §2.8)	✅	exact
6	Milestone endDate falls back to startDate (A §2.8.3)	✅	timelineUtils.ts:359 task.endDate || task.startDate
7	useFlattenedTasks memoizes on tasks identity (A §2.4)	✅	useFlattenedTasks.ts:38-45
8	TaskLabelPosition = "before"|"inside"|"after"|"none" at preferences.types.ts:28 (A §2.6.3)	✅	exact
9	Export renders at its own scale, so pixel-based packing would desync export from screen (A §2.6, Part 4.1)	✅	export/calculations.ts:240 pixelsPerDay = BASE_PIXELS_PER_DAY * effectiveZoom
10	INFINITE_SCROLL_THRESHOLD, FIT_TO_VIEW_BLOCK_MS in layoutConstants.ts (A §2.6)	✅	:43, :34
11	elbowPath.ts "already handles same-row dependencies"; the packed-mode FS chain is "handled by buildSameRowHookPath() (elbowPath.ts:423)"; "stress-testing, not inventing" (A §2.1 finding 1, §2.5, Part 6 wireframe 2, Part 8)	❌ FALSE	see F2
12	Prefix-stability: "an edit to tᵢ can never move any tⱼ with j<i"; ship it as help text (A §2.5)	❌ FALSE	see F3
13	layoutEpoch "incremented only by mutations that touch startDate/endDate/order/parent/type/open" (A §2.4)	❌ undeliverable	see F4
14	"Ties … no tie-break rule is required at all" (A §2.5)	❌	see F11
15	Chart-height change on layout toggle "interacts with useInfiniteScroll" (A §2.6, Part 7.4)	❌	useInfiniteScroll.ts is horizontal only (:49, :102, :232 — all scrollLeft; it extends the date range). Zero vertical involvement. D verified the same.
16	"the two scroll containers that useSyncScroll keeps aligned will drift" (A Part 6)	❌	one vertical driver (GanttLayout.tsx outerScrollRef → translateY on both panes); useSyncScroll is horizontal only
17	"SelectionHighlight prev/next-sibling merging breaks" (A Part 7.2)	⚠️ right problem, wrong file	the row-band component is the inline SelectionRows in ChartCanvas.tsx (~142-200) + TaskList/RowOverlays.tsx. SelectionHighlight.tsx is the date-range band. A's own §2.1 names SelectionRows correctly; Part 7.2 retargets it wrongly.
18	"the whole change is: replace the number passed as rowIndex" (A §2.1)	⚠️ understated ~3×	see F7
19	pixelsPerDay ≈ 0.9 at 5% zoom (A §2.8)	❌ minor	FIXED_BASE_PIXELS_PER_DAY = 25 (timelineUtils.ts:31) → 25 × 0.05 = 1.25. Conclusion unaffected; a 20px diamond still spans ~16 days.
20	chartSlice owns bar-drag state and can gate the freeze (A §2.5; D §drag trap :139, :1183)	✅ but see F5	useTaskBarInteraction.ts:407-408, 478, 567 really do write chartSlice.dragState
21	Bar drag keeps its preview in local state; tasks does not change during a gesture (D §drag trap)	✅	useTaskBarInteraction.ts:411-419, 473-478; commit only on mouseup
22	useTimelineAreaContextMenu maps y → tasks[index] and breaks in packed mode (D, E2E case 5)	✅	useTimelineAreaContextMenu.ts:84-87 Math.floor(svgY/rowHeight) → tasks[rowIndex].id. A never mentions this.
23	FS same-lane → buildStraightLine; SS/FF → buildSameRowHookPath; SF → S-curve (D §arrows)	✅	elbowPath.ts:102-104, :423-424, :431-432, :434-455
24	"Packing is trivially fast" / "sub-ms at 500 tasks" (A §2.4, D §6)	✅ measured	0.04 ms at n=500 (§3)
25	"10 000 → ~5–10 ms" (D §6 table)	❌ optimistic	measured 29 ms with a linear fits() scan; you need A's binary-search fits() to approach D's number

---

2. Findings

ID	Sev	Finding	Owner
F1	BLOCKER	Band-per-summary caps compression at a level that makes the feature pointless on the commonest project shape — measured, 0–11 % row saving	A §2.7-B / D6
F2	BLOCKER	A's same-lane-arrow de-risking claim is false about the code it cites; at A's own gapDays = 0 default the typical packed FS arrow is a 30 px backwards hook	A §2.1, §2.5, Part 6
F3	BLOCKER	The prefix-stability invariant is falsified by an existing shipped feature (bidirectional auto-scheduling); A proposes to put the false version in help text	A §2.5
F4	BLOCKER	layoutEpoch is undeliverable as specified (≈30 setState({tasks}) sites bypass every action) and buys 0.04 ms	A §2.4
F5	MAJOR	"Gate the memo on drag state" as worded repacks every rAF frame — the opposite of the intent	A §2.5
F6	MAJOR	Zoom-invariance leaks that A's render-time mitigations cannot close: milestone/summary labels are structurally outside the shape	A §2.6.3
F7	MAJOR	The hairline-stroke fix is harmful at low zoom and wrong-coloured over weekend/holiday shading	A §2.6.1
F8	MAJOR	Three concepts propose three mutually exclusive packing orders; D's lane-hints violate C's purity mandate and D's own test invariants	A vs C vs D
F9	MAJOR	"Substitution of one integer" is ~10 sites, one of which is the scroll-driver height	A §2.1
F10	MAJOR	The mouseup lane snap is a real UX defect, not a solved one — freeze-then-snap is the easy answer, not a good one	A §2.5 / C §"pack on commit" / D §drag trap
F11	MINOR	"No tie-break rule required" is unsafe — sibling sort is by order only and undo reorders the backing array	A §2.5
F12	MINOR	toDayNumber unspecified; must be date-fns-based, not epoch division	A §2.3
F13	MINOR	Working-day gapDays drags two more store fields into the pack key and into the export path	A §2.6
F14	MINOR	gapDays = 1 destroys most of the compression (measured 15 → 22 rows) — must never become the default	A §2.6
F15	MINOR	Min-bar-width clamping breaks zoom-invariance in reverse: date-disjoint bars overlap in pixels	A §2.6.2
F16	MINOR	Lane-indexed UI state (C's explodedLanes) is not undo-safe under C's own recommended option (a)	C §"lane explode"

---

3. The measurement A said should gate the feature — I ran it

A, Part 8: "How many lanes real charts actually produce … This should be the gate on the whole feature — cheap to measure, and it decides whether any of this is worth building." Then A recommends D6 anyway. I opened the gate.

Data 1 — the only real project file in the repo, examples/mars-colony.ownchart (29 tasks, 7 summaries, 5 milestones, max depth 2). I implemented A's packBand verbatim (document-order first-fit, inclusive day intervals, milestones [d,d]) plus A's band model, and a start-order variant for comparison.

Layout	Rows	totalRows / taskCount
One per Row (today)	29	1.00
A's band model, gapDays = 0	15	0.52
A's band model, gapDays = 1	22	0.76
Global packing (A's rejected option A)	10	0.34

Two things fall out immediately:

1. Every band in this file packs to exactly one lane. Band leaf counts are 1, 3, 2, 2, 3, 4, 3, 4. 7 summaries + 8 single-lane bands = 15 rows. The band model is already at its own optimum and still only reaches 0.52 — while global packing reaches 0.34.
2. Document order vs start order makes zero difference here — both give 15. The longest and most heavily-argued section of Concept A (§2.2–§2.5: the 8ω bound, first-fit vs best-fit, prefix stability) is a decision taken over bands where ω = 1. That is not a reason to discard the reasoning, but Phase 3 should know the decision is currently unfalsifiable on real data.

Data 2 — synthetic WBS shapes (seeded LCG, work packages scheduled sequentially, leaves inside a package either chained or overlapping). This is where it gets bad.

depth	branch	leaves/pkg	tasks	summaries	leaves inside a package	band-model ratio	global ratio
2	3	4	16	4	overlap (parallel work)	0.94	0.50
3	3	4	49	13	overlap	0.88	0.35
4	3	3	121	40	overlap	0.92	0.36
3	4	6	117	21	overlap	0.87	0.23
2	3	4	16	4	sequential (chain)	0.44	0.31
3	3	4	49	13	sequential	0.45	0.29
4	3	3	121	40	sequential	0.55	0.34
3	4	6	117	21	sequential	0.32	0.19

F1 (BLOCKER). When sibling leaves overlap each other — parallel work inside one work package, which is what a WBS is for — the band model saves 6 – 13 % of rows. A user turns on "Packed" on a 121-row plan and gets 111 rows. That is not "collapses toward a single line"; that is a no-op with a reflow. Global packing on the same data gives 43 rows.

There is also a hard analytic ceiling, which is the real problem and is independent of my synthetic data:

band-model rows ≥ S + B, where S = number of summaries and B = number of leaf-bearing bands.

Because every summary keeps its own row (A's D6) and every non-empty band needs at least one lane. For a 4-level, branch-3 WBS that floor is 40 + 27 = 67 of 121 → ratio 0.55 is the best the design can ever achieve there, no matter how favourable the dates. In mars-colony the floor is 7 + 8 = 15 — which is exactly what it scores. The band model is already running at its ceiling and the ceiling is too low.

Resolution (this is the single most important change Phase 3 should make). Do not ship band-per-summary as the mechanism that delivers the value. Instead:

• Promote A's option C (rollup on collapse) from "additive" to the headline. Collapse the top-level summary and its whole subtree packs into one band — which is global packing with the outline intact, and it lands at the 0.19–0.36 ratios above. A already argues this is the right answer for the "single line" question (Part 3.4); the measurement says it is also the only version of the feature that delivers compression at all.
• Make band scope a setting, not a constant: packScope: "perSummary" | "level:N" | "global". perSummary is the safe/legible default only if a project's leaves are chained; global is what a 121-task overlapping WBS needs. A's §2.7 dismisses global with "annihilates the outline" — but the outline lives in the table, and Concepts B/C are redesigning the table anyway.
• Show the number. The Row Layout dropdown should say what the user will get: "Packed — 121 rows → 43". It is one packRows() call to compute, and it converts an unmeasurable promise into a visible one. If the number is 121 → 111, the user learns not to bother, and that is a better outcome than a silent no-op.

Data 3 — density cost of document order (A's §2.3 decision), 1 200 randomized bands:

n	span	max dur	ω (optimal)	start-order FF	doc-order FF	worst case seen
8	180 d	20 d	2.30	2.30	2.31	1.50×
20	365 d	30 d	3.59	3.59	3.63	1.50×
50	365 d	30 d	6.21	6.21	6.39	1.20×
200	730 d	45 d	13.49	13.49	14.12	1.17×
500	1095 d	60 d	24.68	24.68	26.00	1.17×
500	365 d	30 d	33.12	33.12	34.80	1.18×

A's density claim is empirically vindicated: document order costs 2–5 % extra lanes on average, never worse than 1.5× in 1 200 trials. Start-order first-fit hit ω exactly every single time (as theory says it must for interval graphs). So the cost side of A's trade is fine and A should be credited for it — but A asserted it rather than measuring it, and the benefit side (prefix stability) does not hold (F3).

On the 8ω citation (A §2.2). It is being used decoratively rather than incorrectly. 8ω is the competitive ratio for online first-fit interval colouring, where items arrive adversarially and cannot be revisited. A's packer is offline and re-run from scratch, so it is not competing against an adversary — it is just first-fit in a fixed order, and the bound is a loose upper bound on that. It does not "licence" anything by itself; the measurement above does. Keep the conclusion, drop the theorem, cite the table.

Data 4 — timing. n=100: <0.01 ms · n=500: 0.04 ms · n=1 000: 0.18 ms · n=5 000: 5.7 ms · n=10 000: 29 ms (naive linear fits(); A's binary-search version will be much better at the top end). A's "sub-ms at 500" is confirmed. D's "10 000 → ~5–10 ms" is 3–6× optimistic unless fits() really is the binary search A wrote.

---

4. F2 (BLOCKER) — the same-lane arrow claim is false, and the reality is worse

A leans on this twice as the reason the feature is low-risk:

§2.1: "elbowPath.ts already handles same-row dependencies — isSameRow(from, to) at line 74, used at lines 102, 423 and 431, feeding buildSameRowHookPath(). The hardest-sounding consequence of packing … already has a rendering path. It will need stress-testing, not inventing."
Part 6, wireframe 2: "Frontend→QA abut in lane 1 and are a real FS dependency — the arrow … is handled by buildSameRowHookPath() (elbowPath.ts:423)."

Read the file. isSameRow (:74) has three call sites and they do three different things:

Call site	Branch	What actually happens
:102 inside buildElbowAtTurnX	reached by FS and SF	return buildStraightLine(from, to) (:79-81) — a flat horizontal line at bar-centre height
:423	FF only	buildSameRowHookPath
:431	SS only	buildSameRowHookPath

Line 423 is the FF branch. A's Frontend→QA example is FS. It never reaches buildSameRowHookPath. D read this correctly (D §arrows: "FS same-lane → buildElbowAtTurnX short-circuits to buildStraightLine (:102-104)") — A did not.

Now trace A's own wireframe-2 example with A's own default packingGapDays = 0. Frontend ends Apr 5, QA starts Apr 6, same lane:

• getFSConnectionPoints (:306-313): from.x = fromPos.x + fromPos.width, to.x = toPos.x.
• width = calculateDuration(start,end) * pixelsPerDay (timelineUtils.ts:360-361, inclusive) ⇒ from.x === to.x exactly. horizontalGap = 0.
• calculateArrowPath FS branch (:411-419): 0 >= minGapForElbow false → calculateRoutedPath.
• calculateRoutedPath (:275-287): 0 >= 2*(15 − r) false (r = 7 at Normal density) → buildSCurvePath.
• buildSCurvePath (:217-262): firstX = from.x + 15, secondX = to.x − 15 = firstX − 30.

So the arrow exits right 15 px (over the successor bar), turns down into the inter-row gutter, runs left 30 px (back over the predecessor bar), then turns up and enters the target — a 30 px backwards hook tucked under the join. calculateMiddleY (:191-208) puts it at centre + max(4r, rowHeight·0.4) = +14.4 px at Normal, +11.2 px at Compact — inside the gutter, but the same y for every such arrow in the lane. A dependency chain of eight abutting tasks in one lane produces eight identical, collinear, backwards hooks. You cannot tell which belongs to which pair, and the arrowhead points backwards through the predecessor.

This is not a stress-test finding. It is a design gap, and A's "already has a rendering path" is the load-bearing reason A gives for not budgeting arrow work.

Is D right that same-lane routing is tractable, or was D underplaying it? I think D is right that it is tractable and right that it is a differentiator, but D's estimate is too low. D calls it "a ~10-line change to one if in elbowPath.ts:411-419". The if change is indeed small; what is not small is what D's own next paragraph asks for — a per-lane routing gutter (laneHeight = taskBarHeight + 2·taskBarOffset + gutter) with channel packing inside it. That changes rowHeight semantics in packed mode, which changes layoutCalculations.ts:59, GridLines, the density presets' visual balance, every export row-height calculation and every VRT baseline. Budget it as a work package, not an if.

Resolution.

1. Delete the "already handled" claim from the synthesis. Arrow routing is new work and is on the critical path.
2. Adopt D's gutter + packIntervals channel reuse — it is the right shape, and reusing the lane packer for arrow channels is genuinely elegant.
3. Add the missing branch D did not name: an FS arrow between two tasks in the same lane that are not adjacent in that lane (A ends Mar 1, C occupies Mar 5–10, B starts Mar 20, A→B). Today's straight line runs straight through C's bar. The gutter fixes this too, but only if channel assignment considers the whole x-span, not just the endpoints — which D's packIntervals(getSpan) does. Say so explicitly.
4. E2E case: an FS chain of ≥5 abutting tasks packed into one lane, at Compact / Normal / Comfortable density.

---

5. F3 (BLOCKER) — prefix stability is not an invariant

A §2.5, boxed and offered as help text:

"Prefix-stability invariant. … an edit to tᵢ can never move any tⱼ with j < i. Nothing above the edited row moves." … "That is a guarantee you can put in the help text: 'Editing a task can only affect rows below it.'"

Three independent falsifications.

(a) Auto-scheduling already breaks it. taskSlice.ts:250-278: any updateTask touching startDate/endDate calls propagateDateChanges(..., { bidirectional: true, ... }). Propagation follows the dependency graph, not document order (dateAdjustment.ts:382-396, getSuccessors + topologicalSort), and bidirectional: true lets tasks move earlier (:342, :457). Nothing in OwnChart requires a successor to have a higher order than its predecessor — you can draw a dependency from row 40 to row 2. Editing row 40's date then rewrites row 2's dates, which changes lane(t₂), which changes the packing of everything from index 2 onward. A bar above the edit moves, and so does the entire chart below it. A never mentions auto-scheduling in §2.5.

The same applies to recalculateSummaryAncestors (taskSlice.ts:240-247) — editing a child rewrites its ancestors' dates, and an ancestor is always at a lower document index than its child. Under rollupCollapsedSummaries (where the summary is itself packed), that moves a bar above the edit too.

And to computeWorkingDaysRecalc.ts:186-192 — flipping the working-days preference re-propagates every dependency in the chart.

(b) "Above" is not defined in a packed view. Even where the invariant holds mathematically, it is about the document prefix, not the screen. Task 3 can sit in lane 1 while task 7 sits in lane 0 — visually above it. So "editing a task can only affect rows below it" is not merely unproven in the packed view; it is not even a well-formed statement there. Shipping it as help text would be actively misleading, which is worse than shipping no promise.

(c) It says nothing about the operations the user actually fears. A's own table concedes reorder / indent / outdent / unhide "expected — no mitigation needed". Those are precisely drag-reorder and indent, i.e. the majority of structural editing. So the invariant covers date edits (where (a) breaks it) and excludes everything else.

Resolution. Keep document-order first-fit — §3 shows its density cost is 2–5 %, and some locality is better than none. But:

• Delete the invariant and the help text. Replace with an honest, testable, weaker statement: "A change that does not alter any task's dates, order, parent, type or collapsed state never changes the layout." That one is true, is what users actually notice (typing a name must not move bars — D makes the same point), and is enforceable as unit invariant I6.
• If a stability guarantee is wanted, it must come from the algorithm, not from the iteration order: pack the unchanged tasks first in document order, then re-insert the changed ones — or accept C's position that determinism is the only guarantee on offer.

---

6. F4 (BLOCKER) and F5 — layoutEpoch is a footgun that buys 0.04 ms

A §2.4 proposes layoutEpoch in taskSlice, "incremented only by mutations that touch startDate, endDate, order, parent, type, or open", and calls it "explicit and testable rather than emergent".

It is the opposite of testable, because ~30 write sites bypass every action. grep -c "useTaskStore.setState" src/ (non-test) = 39, of which the great majority write tasks wholesale. historySlice alone does it at :282, :325, :344, :359, :423, :522, :564, :644, :692, :710, :784, :876, :922 plus a dozen setState((state) => …) forms. None of these route through updateTask / reorderTasks / indentTasks. For example:

// historySlice.ts:347-359  undoReorderTasks
const currentTasks = getTasksCopy();
applySnapshot(buildTaskMap(currentTasks), params.previousOrder); // rewrites parent + order
recalculateSummaryAncestors(currentTasks, affectedParentIds);    // rewrites summary dates
useTaskStore.setState({ tasks: currentTasks });                  // no action, no epoch bump

Under A's design, undoing a reorder leaves the packing memo stale: bars keep their pre-undo lanes until some unrelated edit happens to bump the epoch. Same for undo-delete, undo-indent, undo-paste, and every clipboard path (clipboardSlice.ts:224, :227). There is no type-level enforcement — a setState is just a setState — so this is a permanent class of silent bug, and it lands hardest on the undo path, which is exactly where Concept C's §8 purity guarantee is supposed to protect us.

Second, worse: there is a second, larger memo that invalidates on tasks identity anyway. ChartCanvas.tsx:305-355 builds taskGeometriesMap / taskGeometriesArray with deps [tasks, scale, densityGeometry], allocating one geometry object per task. That runs on every task mutation regardless of layoutEpoch, and it is strictly more expensive than packing. Skipping a 0.04 ms pack while still rebuilding 500 geometry objects is not an optimization.

Resolution — adopt D's approach, explicitly. D §6 already rejects exactly this ("Not a memoized field on chartSlice… historySlice uses the Command Pattern over task state. A derived cache in a sibling slice is invisible to it — undo would restore dates but not lanes.") and proposes a content-derived packKey computed from flattenedTasks in O(n). D is right and A is wrong; Phase 3 should take D's version verbatim. It cannot go stale because it is derived from the same data the packer consumes, it needs no discipline at 39 call sites, and at 500 tasks the whole pack is 0.04 ms so there is nothing to protect.

F5 (MAJOR) — the freeze, as A words it, does the opposite. A: "gate the memo on it, so buildLaneLayout is not recomputed between mousedown and mouseup." chartSlice.dragState is written once per requestAnimationFrame during a move (useTaskBarInteraction.ts:478 inside the rAF-throttled mouseMoveRef), producing a fresh {deltaDays, sourceTaskId} object each time (chartSlice.ts:1185); TaskBar subscribes to it (TaskBar.tsx:327), so every bar already re-renders per frame. Putting dragState in a memo dependency array therefore invalidates the pack memo 60×/second. The freeze must be edge-triggered — snapshot the layout into a ref on gesture start, read the ref while a gesture is active, drop it on commit. D words it correctly ("snapshot the current RowLayout and pin it"). Take D's wording.

Also note the signal is incomplete: setSharedDragState is called on the move branch only (:478), not on resize (:491-512), not by useProgressDrag, not by useDependencyDrag. Harmless today (none of them mutate tasks mid-gesture) but it must not be mistaken for a general "a gesture is in progress" flag.

Complete invalidation set (union of A's, plus what A and D missed). Anything that changes any of these must be in the pack key:

Input	In A's epoch list?	Note
startDate, endDate	✅
order, parent	✅
type	✅	milestone ⇒ [d,d] footprint
open	✅	band membership under rollup
task added / deleted	❌ ambiguous	no existing task's order changes on append
hiddenTaskIds	✅ (separate dep)
undo / redo of anything above	❌	~30 raw setState sites
auto-schedule cascade	❌	writes dates through a second set() (taskSlice.ts:270-277)
recalculateSummaryAncestors	❌	rewrites ancestor dates
workingDaysConfig / holidayRegion	❌	only if gapDays is in working days (A §2.6) — and computeWorkingDaysRecalc rewrites all dates on toggle
packingGapDays, rollupCollapsedSummaries, rowLayout	✅
file load / multi-tab restore	❌	useFileOperations, multiTabStorage replace tasks wholesale

A content-derived key covers all thirteen rows for free. A counter covers six of them and requires perfect discipline for the rest. That is the whole argument.

---

7. F6 / F7 / F15 — where zoom-invariance leaks

A and D both assert date-unit packing and neither stress-tested it, so here is the stress test. The principle is right — A's export argument (export/calculations.ts:240 computes its own pixelsPerDay) is correct and by itself sufficient, and I verified it. The failures are all in A's claim that the consequences are "a rendering problem with a rendering fix".

F6 (MAJOR) — labels. A's mitigation is inapplicable to two of the three task types.
A §2.6.3: "in packed layout force inside with clipping". But:

TaskBar.tsx:483   labelPosition={labelPosition === "inside" ? "after" : labelPosition}   // milestone
TaskBar.tsx:523   labelPosition={labelPosition === "inside" ? "after" : labelPosition}   // summary

TaskShapeLabel (:124-155) is shared by milestones and summaries and has no inside branch at all — none returns null, everything else renders <text> at anchorX ± LABEL_PADDING with no clip. A milestone therefore always renders an unbounded-length name 8 px to the right of its diamond. Pack a milestone into lane 0 followed by a task starting three days later and the milestone's name is painted over that task's bar, at every zoom level, with no clip path to stop it. Milestones are exactly what A most wants to pack (§2.8.1) and what the rollup precedent is famous for.

Regular bars are fine — inside uses clipPath={url(#clip-${task.id})} (:675-678, clip defined :561-570).

Also: forcing inside silently overrides chartSlice.taskLabelPosition (default "inside", chartSlice.ts:344, but user-settable via the Format ribbon and persisted in ViewSettings). Toggling Row Layout would silently change a saved preference's effect — a direct hit on the author's non-negotiable "all features in both displays".

Resolution: give TaskShapeLabel a real inside branch (milestones have no inside, so the honest answer for a milestone in packed mode is suppress the label and rely on hover/tooltip, or reserve a label column in the table); do not mutate the stored preference — compute an effective label position and surface it in the tooltip ("labels are shown inside bars in Packed layout").

F7 (MAJOR) — the hairline stroke is harmful at exactly the zoom where packing matters.
A §2.6.1: "Give every bar a 1px stroke in the grid background colour." Two problems:

1. At MIN_ZOOM = 0.05, pixelsPerDay = 25 × 0.05 = 1.25. A 1-day bar is 1.25 px wide. A 1 px stroke centred on the rect edge consumes 0.5 px on each side — the bar is gone. The fix erases data at the zoom level where a compressed chart is most useful.
2. There is no single "grid background colour". GridLines.tsx renders weekend shading and holiday shading (:3-4, :19-20, :38-41 GRID.lineDailyWeekend). A bar straddling a weekend gets a hairline that is right on one side and wrong on the other. It is also wrong under the today marker and under any selection/hover band.
3. Bars already carry rx = ry = TASK_BAR_RADIUS = 4 (TaskBar.tsx:43, :583-584), which already produces a visible pinch between two abutting bars at Normal zoom — so the hairline is largely unnecessary where it works and destructive where it is needed.

Resolution: separate abutting bars in layout space, not stroke space — inset each bar's rendered rect by min(1, width/4) px on each side, so the separation degrades gracefully instead of eating the bar. That is still a render-time, height-neutral fix (A's principle survives), it needs no colour knowledge, and it is one expression in getTaskBarGeometry.

F15 (MINOR) — the min-width clamp breaks invariance in reverse. A §2.6.2 proposes clamping rendered width to ~3 px. At pixelsPerDay = 1.25, two tasks that are disjoint in dates (Mar 1 and Mar 2) are 1.25 px apart and both clamped to 3 px — so they overlap on screen while sharing a lane legally. The packer says "no collision", the user sees a collision. The zoom-invariant lane promise leaks in the direction nobody checked. Precedent exists for accepting pixel-gated degradation (PROGRESS_HANDLE.minBarWidth = 30, TaskBar.tsx:69, :603 — the progress handle simply disappears below 30 px), so the honest options are: clamp and accept overlap, or do not clamp and accept sub-pixel bars. Pick one deliberately and write it down; do not let it be emergent.

F-note — milestone clustering (A §2.8.2) is the right instinct (zoom-dependent, height-neutral) but is under-specified in two ways that matter geometrically: (i) the diamond is drawn off-centre today — centeredX = geometry.x + pixelsPerDay/2 − size (TaskBar.tsx:457) is passed as the centre to diamondPath, so the diamond's true centre sits size px left of the day centre; any overlap threshold must use the actual drawn extent [cx − 2·size, cx], not the nominal day. (ii) A cluster glyph ◆3 replaces three independent hit targets with one — useTaskBarInteraction, useDependencyDrag and ConnectionHandles all need a story for "you cannot drag a clustered milestone", which is another parity hole.

Retired concern: sub-day durations are a non-issue. Task.startDate / endDate are date-only YYYY-MM-DD strings and calculateDuration is differenceInDays + 1 (dateUtils.ts:41-45). Nothing sub-day exists. F12 (MINOR): but A's toDayNumber is unspecified — it must be built on date-fns (differenceInDays from a fixed epoch date), not Date.parse(s)/86400000, because parseISO("2025-03-30") returns local midnight and epoch division would go off-by-one across a DST boundary in half the world. One line in the spec, one nasty class of bug avoided.

---

8. F10 — the mouseup lane snap: is freeze-then-snap good, or just easy?

All three concepts converge (A: freeze during drag; C: "Hard rule: pack on commit, never during a live drag"; D: "the real trap is the lane snap on mouseup"). D is the only one who states the consequence plainly. Let me answer the question the brief asks: what does the user see, and is it acceptable?

What happens today, mechanically: tasks is untouched during the gesture (verified, useTaskBarInteraction.ts:411-419), so lanes are stable for free. On mouseup, executeDragMoveCommit calls updateTask, which (a) may run auto-scheduling on the whole dependency-reachable set, (b) may rewrite ancestor summary dates, then the packer re-runs. So the user releases the mouse and the dragged bar jumps to a new y, and an unbounded number of untouched bars jump too.

My assessment: an unannounced vertical jump on release is a genuine UX defect, and animation alone does not fix it — a 150 ms tween of forty bars simultaneously is not "following", it is a shuffle. But it is also unavoidable in a derived-layout model, which is the right model. So the honest framing for Phase 3 is: this cannot be designed away, it can only be made rare, legible and recoverable. Concretely, in priority order:

1. Make it rare. The dragged bar should stay in its lane whenever it still fits there. This is the one place where a lane hint is genuinely justified — but it must be gesture-scoped, not persistent: pack() stays pure, and the freeze snapshot is consulted only to break ties for the dragged task, then discarded. (Persistent hints — D's packRows(previous?) — are a different thing and I reject them in F8.)
2. Never let it leave the viewport. If the committed lane is off-screen, scroll it into view. D says this; make it mandatory, not optional.
3. Animate the dragged bar differently from the rest. The dragged bar gets a 150 ms y transition and keeps its selection ring; other bars that moved get a shorter, lower-contrast transition. Users need to track one object, not forty.
4. prefers-reduced-motion: reduce ⇒ no transition (A says this; keep it) — and VRT must disable transitions or snapshots are non-deterministic (C flags this; keep it).
5. Multi-drag is the bad case. MULTI_DRAG_TASKS moves N selected bars at once; on commit, N lanes change plus cascades. Prototype this specific gesture before committing to the design — it is the one I would expect to actually feel broken.

And one non-goal worth writing into the spec, which D states and I endorse: vertical drag must never be interpreted as a lane assignment. Lanes are derived; letting the user drag a bar "into" a lane creates a pin, a pin creates persisted layout state, and persisted layout state destroys export ≡ screen and undo determinism in one move.

---

9. F8 — the cross-concept contradiction nobody can dodge

Three concepts, three incompatible packing orders, each load-bearing for that concept's other guarantees:

	Order	Rationale	Incompatible with
A §2.3	Document order, never re-sorted	prefix stability (F3: false)	C's I2-style optimality; C's explicit sort
C §8	Stable sort (startDate, endDate, order, id); "never from remembered previous layout"	determinism ⇒ undo correctness	A's document order
D §6/§stability	first-fit + previous-layout hint: "if a task still fits its previous lane, keep it there", packRows(previous?)	minimise visible motion	C explicitly, by name; D's own invariants

D's hint is the one that must go, and it fails on four independent counts:

• It violates C §8's core mandate ("pack() must be a pure, deterministic function of (visible task set, dates, tie-break key)" — C even names the failure mode: "a 'keep the lane it had' heuristic that reads mutable state … undo(redo(x)) !== x visually").
• It violates A's export ≡ screen guarantee (§2.4): the export path has no previous layout, so prepareExportTasks → svgExport would produce a different lane assignment than the screen. That is the exact silent-wrong-output bug A rejects pixel-based packing to avoid.
• It violates D's own unit invariants I5 ("Same input ⇒ byte-identical output") and I6 ("Re-packing after a non-date edit yields an identical layout") — with hints, output depends on history, not input.
• It also breaks D's I2 ("laneCount === max simultaneous overlap depth"). Note I2 is already broken by A's document order — §3 measures a 2–5 % average excess and up to 1.5×. If Phase 3 takes A's algorithm and D's test suite, I2 fails on day one. Whoever writes the tests must know this.

Resolution. Adopt A's document order (the density cost is measured and small; locality is worth more than optimality), adopt C's explicit total-order tie-break and C's purity mandate, adopt D's content-derived packKey and D's gutter/channel arrow work, and drop D's persistent hints in favour of the gesture-scoped tie-break in §8.1. Then restate D's I2 as laneCount <= 1.5 * omega with omega computed by a sweep — a real, passing property test rather than an aspirational one.

F11 (MINOR) — and C's tie-break is not optional. A claims "document order is a total order (order is unique per parent), so first-fit is deterministic. No tie-break rule is required at all." But buildChildrenLookup sorts siblings by order only (hierarchy.ts:146 siblings.sort((a,b) => a.order - b.order)). Array.prototype.sort is stable, so equal order values resolve by position in the tasks array — and undoDeleteTask rebuilds that array as [...getTasksCopy(), ...params.deletedTasks] (historySlice.ts:312-325), i.e. restored tasks are appended at the end. Duplicate order values are reachable via paste and import. So delete-then-undo can change flattened order, hence lane assignment, hence undo(delete(x)) !== x visually. C's (startDate, endDate, order, id) — or for A's algorithm, (order, id) — is required, not decorative.

---

10. Undo/redo purity (brief item 5) — verdict

C's claim holds, conditionally. pack() is a pure function of (visible task set, dates, order, parent, type, open, gap, scope). Every one of those is restored by historySlice (dates via undoUpdateTask :288-306 incl. reverseDateAdjustments; parent+order via applySnapshot :239-253; existence via undoAddTask/undoDeleteTask; open via the expansion commands). So if the packer is pure, undo restores the document and the lanes follow for free, and packing correctly never enters the history stack.

The conditions, all of which are currently violated by one concept or another:

Condition	Violated by	Fix
No previous-layout dependence	D packRows(previous?)	drop it (F8)
Total-order tie-break	A "no tie-break required"	adopt C's (F11)
Invalidation cannot go stale	A layoutEpoch vs ~30 raw setState	content key (F4)
No lane-indexed persisted UI state	C explodedLanes option (a)	see below

Re-parent while a lane is focused/selected. Selection is by TaskId (selectedTaskIds), so it survives any reflow — good. The exposure is lane-indexed state. C §"lane explode" flags this and recommends option (a), "collapse all lanes on any lane-count change". Under undo that is wrong: undoing an unrelated edit elsewhere in the chart changes the lane count and therefore silently closes the lane the user was working inside. Take C's own option (b) — key exploded/focused lane state to the id of the earliest task in the lane, and drop it only when that task is gone. Same rule for any "focused lane" concept Concepts B/C introduce.

One more: indent/outdent runs recalculateSummaryAncestors (indentOutdentActions, mirrored in historySlice.ts:335-345), which rewrites ancestor dates. In the band model summaries keep their own row, so no lane changes — but under rollupCollapsedSummaries a collapsed summary is itself packed, so re-parenting a leaf can move a summary bar to a different lane. Deterministic, so undo-safe, but it is a visible motion nobody has drawn.

---

11. What is good and should survive Phase 3

Not padding — Phase 3 needs to know what not to relitigate.

• Date-unit packing, pixelsPerDay never an input (D5 / Part 4). Correct, and the argument that carries it (export computes its own zoom, export/calculations.ts:240) is the one I verified. Note that A gives three arguments and only this one holds — the useInfiniteScroll argument is false (item 15) — but one sufficient argument is enough. Do not revisit this.
• Derived, never persisted; the same pure function on the screen and export paths. This is the best structural decision in any of the four concepts. It makes CLAUDE.md's export-parity rule satisfiable by construction. Protect it — every rejection in F8 and §10 exists to protect it.
• First-fit over best-fit (§2.3). The reasoning ("closest flips on a one-day edit") is exactly right, and the left-aligned-text analogy is a good way to explain the resulting ragged bottom to users.
• Document order over start order — for the right reason. The stability argument A gives is false (F3), but the measured cost is 2–5 % (§3), and document order preserves the user's own ordering as a visual input, which is worth more than 2–5 % of rows. Keep the decision, replace the justification.
• Rollup-on-collapse (D6-C). A's best idea by some distance: it turns collapse from lossy into lossless, reaches the author's "one line" outcome through a control that already exists, and — per §3 — it is the only variant that actually compresses. Promote it from "additive" to primary.
• Rejecting the true-single-line overlap mode (D8) — right call, but fix the reasoning. A says feature parity there is "structurally impossible"; D found that Bryntum ships exactly this as eventLayout: 'none', so it is evidently possible, just read-only-ish. The defensible version: an overlap mode cannot offer unambiguous hit-testing, so it can only ever be a read-only view; ship it in the export dialog if at all. Same conclusion, defensible premise.
• A Part 7's list of second-order breakages (globalRowNumber, GridLines row count, marquee semantics, cell navigation, VRT, migration) is genuinely good scoping work and mostly correct — retarget item 2 to SelectionRows/RowOverlays and add useTimelineAreaContextMenu.ts:84-87 (item 22), which is a silently wrong task target, not a cosmetic issue.
• D's packIntervals reuse for arrow channels is the most elegant idea across all four concepts. Keep it.

F9 (MAJOR) — one correction to scoping, though. A §2.1: "the whole change is: replace the number passed as rowIndex. Not a rewrite — a substitution of one integer." The real count, grep -n rowIndex src/ = 34 hits across 8 non-test files, plus:

Site	What it is	Why it is not free
ChartCanvas.tsx:328	rowIndex: index in the geometry memo	arrows + connection handles
ChartCanvas.tsx:494	rowIndex={index} on <TaskBar>	geometry is computed twice, independently (TaskBar.tsx:316-323) — both must agree or handles detach from bars
ChartCanvas.tsx:168	SelectionRows y = index*rowHeight	+ prev/next merge logic
ChartCanvas.tsx:413	taskBasedHeight = (tasks.length+1)*ROW_HEIGHT	SVG height
GridLines.tsx:190,194	line positions + gridHeight	must become totalRows
layoutCalculations.ts:59	totalContentHeight = (taskCount + PLACEHOLDER_ROW_COUNT)*rowHeight + …	this is the scroll-driver height consumed by GanttLayout's outerScrollRef — get it wrong and the single vertical scrollbar has the wrong range in packed mode
taskTableRenderer.ts:478,663	export table row math	export path
ExportRenderer.tsx	export chart row math	export path
useTimelineAreaContextMenu.ts:84-87	inverse map y → task	the only inverse consumer; silently wrong, not visibly wrong
TimelineHeader.tsx:209-274	rowIndex * ROW_HEIGHT	false positive — that is the header's scale rows, unrelated. Leave alone.

So: ~9 real sites, one inverse map, two on the export path, and one that is the scroll geometry. Call it a day's careful work rather than a one-integer substitution, and note that the natural single injection point is ChartCanvas's taskGeometries memo (:305-355) — but only if TaskBar stops computing its own geometry from rowIndex and consumes the shared one instead. That refactor is the prerequisite that makes A's "one integer" claim become true; right now it is not.

---

12. Recommendations to Phase 3, ranked

1. Open A's gate before writing any code. Run packRows over Martin's real .ownchart files and report totalRows/taskCount for perSummary vs global. My §3 numbers say perSummary alone does not justify the feature. If Martin's real files look like mars-colony (0.52) that is defensible; if they look like the overlapping WBS rows (0.88–0.94) the feature must ship as rollup/global, not band-per-summary. This is a half-day of work and it decides the shape of everything else.
2. Ship rollup-on-collapse as the headline; make band scope a setting; show the predicted row count in the dropdown.
3. Budget dependency-arrow routing as real work (gutter + channel packing), not as "stress-testing an existing path". Delete the "already handled" claim.
4. Delete the prefix-stability invariant and its help text. Replace with the true, weaker, testable statement.
5. Kill layoutEpoch; use D's content-derived packKey. Kill D's persistent lane hints; use a gesture-scoped tie-break for the dragged task only.
6. Write the purity contract down once, with C's four conditions (§10 table), and make pack(doc) === pack(applyThenUndo(doc)) a unit test — it will catch F11 and F4 automatically.
7. Restate D's invariant I2 as a bounded-excess property, or it fails on day one against A's algorithm.
8. Add three E2E cases nobody listed: (a) an FS chain of ≥5 abutting tasks in one lane at all three densities; (b) an FS dependency between two same-lane tasks with a third task between them in x; (c) right-click on the second bar in a shared lane → menu targets that bar (useTimelineAreaContextMenu.ts:84-87).

Reproduction: the three measurement scripts (real-file packing, WBS synthesis, order/timing benchmark) are ~120 lines of plain Node and can be re-run against any .ownchart file; happy to hand them over if Phase 3 wants the numbers regenerated on real data.

---

Reviewer: R1 — Algorithmic Correctness, Layout Semantics & Performance

[kitikonti]

FINAL CONCEPT — Issue #88

Part 1 of 3 — Verdict, the decision gate, and rulings on every open conflict
(Part 2 = full implementation spec + parity matrix. Part 3 = test plan, rollout gates, open questions.)

---

The verdict, unhedged

STAGED, with a hard measurement gate — and the gate is very likely to close.

Ship a Collapse All / Expand All ribbon button this week. It compresses the repo's own reference project from 29 rows to 7 (4.14x). The design that four concepts and roughly 250,000 characters of analysis were built around — shared rows with a band per summary — compresses the same file to 15 rows (1.93x). Two agents measured this independently; I re-ran it a third time and reproduced both numbers exactly. collapseAll and expandAll already exist at src/store/slices/expansionActions.ts:82,90, are unit-tested at tests/unit/store/taskSlice.test.ts:1425-1505, and are wired to zero UI surfaces. The cheapest answer to #88 is not a feature. It is a wiring bug.

Then run the measurement script in §2 over your own .ownchart files. That is the gate. If your charts are hierarchical like mars-colony, stop after Stage 3 and close this issue — you will have got more compression, losslessly, for about 4% of the cost. If your charts are flat (many independent parallel tasks, few or no summaries), the ratios invert, collapse does nothing, and shared rows is genuinely your feature — build Stage 4 and the full spec in Part 2 is waiting for you.

Do not build: the Lane Ledger, the Detail Strip, a second keyboard model for the canvas, a true single-line overlay mode, layoutEpoch, persistent lane hints, or lane pinning. Reasons in §5.

Honest cost if the gate opens and you build everything: 8–14 weeks of solo evenings, roughly one quarter, across 25–31 files and 700–1,400 lines before any left-panel work. Concept A's "a substitution of one integer, four sites" is wrong by about an order of magnitude (R3 §3). You deserve to know that before you start, not in week six.

---

1. Why the premise underdelivers — the arithmetic, not the opinion

The band-per-summary model has a hard analytic floor that R1 derived and I have verified:

rows >= S + B, where S = number of summaries and B = number of leaf-bearing bands.

Every summary keeps its own row (a summary bar spans all of its children by construction, so it can never share a lane with them), and every non-empty band needs at least one lane. That floor is not a property of your dates. It is a property of your outline. For a 4-level, branch-3 WBS the floor is 40 + 27 = 67 of 121 tasks — ratio 0.55 is the best the design can ever reach there, no matter how favourable the schedule.

On examples/mars-colony.ownchart the floor is 7 + 8 = 15. The measured result is 15. The band model is already running at its own ceiling, and the ceiling is too low.

Reproduced just now, third independent run:

examples/mars-colony.ownchart
  29 tasks | 7 summaries (24%) | 1 top-level leaf task
     29 rows  1.00x  one task per row (today)
      7 rows  4.14x  collapse all -- LOSSY, code already exists
      7 rows  4.14x  rollup on collapse -- lossless, Stage 3
     15 rows  1.93x  shared rows, band per summary
     10 rows  2.90x  shared rows, summary rail + leaves packed globally
      7 rows  4.14x  shared rows, fully global (outline lost)

Read the last row against the second. Even the maximally aggressive variant of shared rows — the one that throws the outline away entirely and which nobody is proposing to ship — only matches what a button that already exists gives you for free. That is the single most decisive number in this whole effort and it emerged from re-running the script, not from any of the nine comments.

R1's synthetic WBS shapes make it worse in the case a WBS is for. When sibling leaves overlap each other — parallel work inside one work package — the band model saves 6-13% of rows:

depth	branch	leaves/pkg	tasks	leaves inside a package	band-model ratio	global ratio
2	3	4	16	overlap (parallel work)	0.94	0.50
3	3	4	49	overlap	0.88	0.35
4	3	3	121	overlap	0.92	0.36
3	4	6	117	overlap	0.87	0.23
4	3	3	121	sequential (chain)	0.55	0.34

A user turns on Shared Rows on a 121-row plan and gets 111 rows. That is not "collapses toward a single line". That is a no-op with a reflow.

And R4 found the trap that makes the remaining compression fragile: compression collapses as you zoom out — that is, it is weakest exactly in the fit-the-whole-project-on-one-screen case the feature exists to serve. Label-aware measurement on the same file: 9 lanes at 25 px/day, 12 at fit-to-1200px, 17 at fit-to-600px. At 10.4 px/day the mean 5.5-day task is a 57px bar and a 20-character name needs ~140px. The median bar in the reference project cannot show its own name in shared-rows mode at fit-to-screen zoom. A packed chart of anonymous rectangles is not an overview; it is a heat map. This matters doubly because §4.5 below rules that the bar's own name is the only always-on cue binding a table row to its bar.

---

2. The measurement caveat, stated honestly — and the gate

Both measurements are n=1. There is exactly one real .ownchart file in this repository. mars-colony is 100% hierarchical: 24% summaries, exactly one top-level leaf task, zero orphan work. Every argument in §1 depends on that shape. If your real charts are flat, my recommendation inverts and I will say so in advance: a flat 40-task list gets nothing from collapse-all and 4-8x from packing. R4 said this too and was right to.

So do not take my word or R1's or R4's. Take twenty minutes and measure your own files. Save this as scripts/measure-row-packing.js — it is read-only, has zero dependencies, and is the same document-order first-fit algorithm the feature would actually ship:

#!/usr/bin/env node
/**
 * Issue #88 decision gate. Read-only, zero deps.
 *   node scripts/measure-row-packing.js examples/*.ownchart ~/charts/*.ownchart
 */
const fs = require("fs");

const day = (s) => Math.round(Date.parse(s + "T00:00:00Z") / 86400000);
const span = (t) => {
  const a = day(t.startDate);
  return { a, b: t.type === "milestone" ? a : day(t.endDate || t.startDate) };
};

/** Document-order first-fit -- the algorithm this issue would ship. Returns lane count. */
function pack(list, gap = 0) {
  const lanes = [];
  for (const t of list) {
    const s = span(t);
    let hit = -1;
    for (let l = 0; l < lanes.length && hit < 0; l++) {
      if (lanes[l].every((o) => s.b + gap < o.a || o.b + gap < s.a)) hit = l;
    }
    if (hit < 0) { lanes.push([]); hit = lanes.length - 1; }
    lanes[hit].push(s);
  }
  return lanes.length;
}

for (const file of process.argv.slice(2)) {
  const tasks = JSON.parse(fs.readFileSync(file, "utf8")).chart.tasks;
  const kids = new Map();
  for (const t of tasks) {
    const k = t.parent || " root";
    if (!kids.has(k)) kids.set(k, []);
    kids.get(k).push(t);
  }
  for (const v of kids.values()) v.sort((x, y) => x.order - y.order);
  const isSummary = (t) => (kids.get(t.id) || []).length > 0;

  const N = tasks.length;
  const summaries = tasks.filter(isSummary);
  const leaves = tasks.filter((t) => !isSummary(t));
  const roots = kids.get(" root") || [];
  const topLevelLeaves = roots.filter((t) => !isSummary(t)).length;

  const band = (key) => {
    let rows = 0;
    const leafKids = [];
    for (const k of kids.get(key) || []) {
      if (isSummary(k)) rows += 1 + band(k.id);
      else leafKids.push(k);
    }
    return rows + (leafKids.length ? pack(leafKids) : 0);
  };

  const rows = {
    "one task per row (today)": N,
    "collapse all -- LOSSY, code already exists": roots.length,
    "rollup on collapse -- lossless, Stage 3": roots.length,
    "shared rows, band per summary": band(" root"),
    "shared rows, summary rail + leaves packed globally": summaries.length + pack(leaves),
    "shared rows, fully global (outline lost)": pack(tasks),
  };

  console.log("\n" + file);
  console.log(`  ${N} tasks | ${summaries.length} summaries (${Math.round(100 * summaries.length / N)}%) | ${topLevelLeaves} top-level leaf tasks`);
  for (const [k, v] of Object.entries(rows)) {
    console.log(`  ${String(v).padStart(5)} rows  ${(N / v).toFixed(2)}x  ${k}`);
  }
  const verdict =
    summaries.length === 0
      ? "FLAT -> shared rows is genuinely your feature. Build Stage 4."
      : topLevelLeaves > N * 0.4
        ? "MIXED -> read the two ratios above and decide."
        : "HIERARCHICAL -> collapse/rollup wins. Stop after Stage 3.";
  console.log(`  >> ${verdict}`);
}

How to read the output — the gate criterion, stated in advance so it cannot be rationalised afterwards:

Condition across your files	Decision
shared rows, band per summary beats rollup on collapse by less than 1.5x	Stop after Stage 3. Close #88 as "solved by collapse + rollup".
Beats it by 1.5x-2.5x	Build Stage 4, but only the reduced scope in Part 2. Revisit after two weeks of use.
Beats it by more than 2.5x, or summaries == 0 on most files	Build Stage 4 in full. The spec in Part 2 is complete enough to start from.

And a second, softer gate that costs nothing but time: use the Collapse All button for two weeks before deciding. If the itch is gone, that is the most valuable measurement available and no script can produce it.

---

3. The plan

flowchart TD
  S0["<b>Stage 0</b> · hours · <code>feat:</code><br/>Wire Collapse All / Expand All<br/>to View ▸ Layout + shortcuts + help"]
  M["<b>GATE</b> · 20 min<br/>Run measure-row-packing.js<br/>on your own files<br/>+ two weeks of using Stage 0"]
  S1["<b>Stage 1</b> · 3-5 evenings · <code>refactor:</code><br/>RowResolver refactor.<br/>Zero user-visible change.<br/>Worth doing regardless."]
  S2["<b>Stage 2</b> · 4-7 evenings · <code>feat:</code><br/>Rollup on collapse.<br/>Lossless 4.14x.<br/>One row per task survives."]
  S3["<b>Stage 3</b> · 25-45 evenings · <code>feat:</code><br/>Shared Rows.<br/>The full spec in Part 2."]
  X["<b>Close #88.</b><br/>Solved, at 4% of the cost."]

  S0 --> M
  M -->|"hierarchical charts<br/>ratio < 1.5x"| S1
  M -->|"flat charts<br/>ratio > 2.5x"| S1
  S1 --> S2
  S2 -->|"hierarchical"| X
  S2 -->|"flat, or itch remains"| S3
  style S0 fill:#166534,color:#fff
  style M fill:#854d0e,color:#fff
  style X fill:#166534,color:#fff
  style S3 fill:#7f1d1d,color:#fff

Loading

Stage	Contents	Cost	Verifiable gate to exit
0	collapseAll/expandAll in View ▸ Layout, Ctrl+Shift+[ / Ctrl+Shift+], one HelpTopic	hours	E2E: collapse-all on the mars fixture leaves 7 visible rows; expand-all restores 29; undo of an unrelated edit does not change expansion
GATE	Run the script; use Stage 0 for two weeks	20 min + 2 weeks	Written down in the issue: ratio per file, and "does it still itch"
1	packRows.ts + RowResolver supporting only mode: "list"; rewire all three geometry sites, layoutCalculations, the export renderers, useTimelineAreaContextMenu	3-5 evenings	npm run ci:local green with all 5,239 unit tests untouched (746 of them live in the 28 row-geometry files); all ~190 E2E untouched; npm run test:vrt with zero baseline updates. Ships as refactor:, no version bump, bisects cleanly.
2	Rollup glyphs on collapsed summary rows + scrollToTaskOnClick reveal; export parity	4-7 evenings	Collapse a summary: every descendant is still visible as a glyph on the parent's row and still clickable; PNG/PDF/SVG show the same glyphs; row count identical to Stage 0's collapse
3	Shared Rows — Part 2's spec in full	25-45 evenings	Per-phase gates in Part 3 §3

Stage 1 is worth doing even under DON'T BUILD. y = index * rowHeight is scattered across ChartCanvas, GridLines, TaskBar, DependencyArrows, ExportRenderer, exportLayout, pdfLayout and layoutCalculations. That is real architectural debt today, and a resolver with a list-mode identity case and a zero-VRT-churn acceptance gate is a self-proving refactor. It makes every future non-1:1 rendering cheap — resource bands, snapshot overlays, multi-project.

One process note I am obliged to pass on. R4 flagged #84: the coverage thresholds are in the wrong config key and are silently inert — npm run test:unit reports 33.09% and exits 0 against the 80% floor documented in CLAUDE.md. Adding several thousand lines of new mode-dependent behaviour on top of an unenforced coverage gate is the wrong order of operations. Fix #84 before Stage 1.

---

4. Rulings on the seven open conflicts

Every one is decided. Nothing is split.

4.1 — B's left panel vs C's Lane Ledger → B wins, unconditionally.

Ruling. The left panel keeps one row per task, in flattened outline order, with the full column set and the full editing model, in both modes. It stops pretending its y-coordinates mean anything about the chart and binds to the chart by identity instead of position. Add a docked, non-modal Inspector as an additive second surface present in both modes. The Lane Ledger and the Detail Strip are rejected outright.

Why, in order of decisiveness:

1. The table is what makes OwnChart accessible, and C's design removes it. R2 §4.2 corrected C's central a11y premise and R3 PDF/PNG export: Color column values don't match task colors when using color themes #42 confirmed the correction. TaskTable.tsx:146 is role="grid", rows carry role="row" + aria-rowindex, cells role="gridcell". Across all of src/components/GanttChart/*.tsx there are exactly two ARIA hits, neither on TaskBar. The task table is the entire screen-reader representation of the task set. C used "SC 2.5.7 is already failing" to argue the a11y cost was pre-existing debt. The opposite is true: removing the per-task rows converts passing criteria into failures. That is the strongest single argument here and it is stronger than the one B actually made.
2. The Ledger delivers the author's own complaint back to him. The issue says: "I can't type the task name because there is no task table." C's answer is a left panel of rows labelled Lane 1 · 4 tasks. By default no task name is visible for any task. WelcomeTour.tsx:52 tip Undo/Redo not working for Indent/Outdent operations #1 is "Click the empty row to add tasks"; helpContent.ts gs-create-task says "Click the empty placeholder row at the bottom of the task table". Under B both stay true in both modes. Under C both must be rewritten and the tour's first promise becomes conditional on which mode you are in.
3. C's continuum claim is false (R2-1). "Classic mode is literally packed mode with every lane exploded" cannot be implemented: explode-all yields lane-grouped, chronologically-ordered rows with no summary rows and no indentation — a third view, not classic mode. The "no silo" framing that motivated the ledger does not survive.
4. C's own a11y fallback contradicts C's own design (R2-3). C §5.6 promises "every task is reachable here in outline order"; C §0/§6.5 make ledger rows lanes, with tasks visible only when exploded and then in chronological order.
5. Parity. R2's audit found eight breaks against the author's non-negotiable constraint, three of them conceded in C's own matrix: no task name visible without interaction; dates/duration/progress not visible together; row drag-reorder marked "no meaning in packed mode" (silently removing a keyboard-operable operation — TaskTable.tsx:112-115 wires dnd-kit's KeyboardSensor); InsertRowButton/InsertLine dropped; HiddenRowIndicator dropped; column hide/resize semantics degraded from an N×7 grid to a 1×7 strip; screen-reader outline traversal broken; aria-rowindex no longer truthful.
6. Scoring. B's own decision matrix scores option (b), the ledger, at 9/25 — its worst option, parity 1/5. R4 independently reached the same place, and noted Bryntum's shipped real-world answer to "what goes in the left cell when a row holds N bars" is showEventCount: a number. A vendor already confirmed the ledger is informationally worthless for editing.
7. A 1×7 Detail Strip is a regression from a table for the workflows that matter. A spreadsheet's value is not editing one cell; it is that thirty rows are legible simultaneously. "Which of these ends in March?" is a visual scan of one column across N rows; in a strip it is N focus changes. "Why is this task 12 days when its sibling is 3?" is impossible in a strip.

What survives from C, and it is a lot. C's genuine value was never the ledger — it is the CRUD/keyboard/a11y inventory built around it, and every item of it works on B's panel: non-drag pointer paths (Move to… / Extend to… / Set progress… / Link to…), nudge mode, Ctrl+D duplicate, paste-at-cursor, the freeze-packing-during-drag rule, "packing is never an undoable command" with the purity test pack(doc) === pack(applyThenUndo(doc)), post-paste scroll-to, and the useTimelineAreaContextMenu hit-test rewrite. C was also the most factually accurate document of the four (R3: 11/11 file:line citations resolved within ±5 lines). Take C's inventory wholesale. Drop C's panel.

Recorded loser: C's Lane Ledger, C's Detail Strip, C's lane-explode mechanism, C's mode-dependent menu labels, C's 4-axis canvas keyboard model.

---

4.2 — The scroll-driver blocker → B's clamped dual-translate. It is not a blocker.

R3 raised this as the largest unanswered architectural question and said all four resolutions destroy either the feature or the architecture. R3's option list was incomplete: it did not include the model B actually proposed. I rule for B, and here is the arithmetic that settles it.

Today (GanttLayout.tsx:100-115, 159):

outerScrollRef                 overflow-y: auto    height = totalContentHeight
└─ spacer                      height = totalContentHeight
   └─ sticky container         height = viewportHeight, overflow hidden
      └─ SplitPane
         ├─ left   taskTableScrollRef   overflow-x: auto, overflow-y: CLIP
         │         └─ taskTableTranslateRef   transform: translateY(-scrollTop)
         └─ right  chartContainerRef    overflow-x: auto
                   └─ chartTranslateRef       transform: translateY(-scrollTop)

Proposed — one scrollbar, two independently clamped translates:

listContentHeight  = (taskCount + PLACEHOLDER_ROW_COUNT) * rowHeight + HEADER + SCROLLBAR
chartContentHeight = (laneCount + PLACEHOLDER_ROW_COUNT) * rowHeight + HEADER + SCROLLBAR
totalContentHeight = max(listContentHeight, chartContentHeight)

maxScroll(pane)    = max(0, paneContentHeight - contentAreaHeight)
translate(pane)    = -clamp(scrollTop, 0, maxScroll(pane))

Four properties, each checkable:

• List mode is provably unchanged. laneCount === taskCount ⇒ both pane heights equal ⇒ both clamps identical ⇒ translate = -scrollTop for both. Zero regression risk on the existing mode — the "extend, not replace" constraint expressed as arithmetic, and it is a unit test, not a promise.
• The common shared-rows case needs no scrolling on the right at all. With 3 lanes, maxScroll(chart) === 0, so the chart never translates: it pins at the top while the list scrolls beneath the shared scrollbar. This falls out of the formula; it needs no special case.
• The tall-chart case degrades gracefully. A chart taller than the viewport but shorter than the list scrolls until it bottoms out, then pins. One scrollbar, no racing.
• One persisted scroll position. ViewSettings.scrollTop (fileOperations/types.ts:101) is a single scalar in the saved file format. Any design giving the panes independent scroll positions forces a file-format change plus a migration. The clamped model does not.

And the point nobody made, which is why I am confident rather than merely persuaded: the clamp is not a new mental model, it is the correct generalisation of one the code already has. Today, translate = -scrollTop is only safe because both panes are the same height. The moment they differ, unclamped translation pushes the shorter pane's content off the top of the screen. The clamp is the missing min, not a new invention.

Explicitly rejected: giving the left pane its own overflow-y: auto. Two scrollbars, breaks usePreventVerticalScroll, forks the persisted scroll position into the file format and multi-tab storage, and makes "reveal" ambiguous in both directions.

Rejected: R3's option (b), growing lane height so L * laneHeight ≈ N * rowHeight. It destroys the point of the feature and, per R2-14, it makes the layout mode fight the Density preference over one number. Ruling: laneHeight === rowHeight, always. Density stays the only control over row height. B's addendum A8 "shrink to a floor, then grow" is deferred, not adopted.

One thing this ruling does not settle, and I will not pretend it does: whether a 500-row list scrolling against a 4-lane chart that never moves feels right. B flagged this as its own uncertainty #3 and R2 agreed. It is ~10 lines to prototype against the existing calculateLayoutDimensions. Make it the first task of Stage 3 and a stop-work gate. If it feels broken, the answer is not to redesign the scroll model — it is that Stage 3 should not ship.

---

4.3 — The three-way packing-order contradiction → A's document order + C's tie-break. D's hints rejected.

	Order	Rationale given	Ruling
A §2.3	Document order, never re-sorted	prefix stability	ADOPT the order. Reject the justification (§5, falsified).
C §8	Stable sort (startDate, endDate, order, id)	determinism ⇒ undo correctness	ADOPT the tie-break only, not the sort.
D §6	first-fit + previous-layout hint, packRows(previous?)	minimise visible motion	REJECT.

Document order wins on measured evidence, not on A's argument. R1 ran 1,200 randomised trials: document-order first-fit costs 2-5% extra lanes on average versus optimal, worst case 1.5x, and start-order first-fit hit exact omega every single time (as interval-graph theory requires). R4 independently found document-order first-fit hitting exact omega in 7 of 8 configurations on real data. So the cost of document order is measured and small, and what it buys is real: it preserves the user's own ordering as a visual input. That is worth more than 2-5% of rows. C's date sort would silently reorder the document you authored into date order and gain almost nothing.

On the 8-omega citation in A §2.2: drop it. It is the competitive ratio for online first-fit interval colouring, where items arrive adversarially and cannot be revisited. This packer is offline and re-run from scratch. The bound licenses nothing. Cite R1's table instead.

C's tie-break is required, not decorative (R1 F11). buildChildrenLookup sorts siblings by order only (hierarchy.ts:146). Array.prototype.sort is stable, so equal order values resolve by position in the tasks array — and undoDeleteTask rebuilds that array as [...getTasksCopy(), ...params.deletedTasks] (historySlice.ts:312-325), appending restored tasks at the end. Duplicate order values are reachable via paste and import. So delete-then-undo can change flattened order, hence lane assignment, hence undo(delete(x)) !== x visually. Fix: total order (order, id).

Recorded loser: C's sort by start date; D's previous parameter; A's 8-omega justification; A's "no tie-break rule is required at all".

---

4.4 — D's lane hints vs purity → rejected, and I overrule R1's compromise too.

D proposed packRows(flattened, mode, options, previous?): if a task still fits its previous lane, keep it there. R1 rejected persistent hints on four independent counts and I agree with all four:

• It violates C §8's purity mandate — C even names the failure mode: "a 'keep the lane it had' heuristic that reads mutable state … undo(redo(x)) !== x visually."
• It violates export ≡ screen. The export path has no previous layout, so svgExport would produce a different lane assignment than the screen. That is precisely the silent-wrong-output bug that date-unit packing exists to prevent.
• It violates D's own invariants I5 ("same input ⇒ byte-identical output") and I6.
• It makes VRT baselines history-dependent, which makes them flaky, which means someone eventually deletes them.

Where I overrule R1. R1 proposed keeping a gesture-scoped tie-break: during a drag, consult the frozen snapshot to prefer the dragged task's previous lane. That is still impure if it affects the committed layout — the post-commit result would differ from a cold pack, and export would diverge exactly as with persistent hints. The compromise smuggles the rejected mechanism back in through a narrower door.

Ruling: packRows() takes no previous parameter, ever. Full stop. The freeze is a render-time concern only:

sequenceDiagram
  participant U as User
  participant TB as useTaskBarInteraction
  participant RL as useRowLayout
  participant C as ChartCanvas
  U->>TB: mousedown on bar
  TB->>RL: beginGesture()
  RL->>RL: frozenRef.current = layout (snapshot)
  loop every rAF, ~60/s
    U->>TB: mousemove
    TB->>TB: local dragState only; tasks UNCHANGED
    C->>RL: read layout
    RL-->>C: frozenRef.current (no repack)
  end
  U->>TB: mouseup
  TB->>TB: executeDragMoveCommit -> updateTask
  Note over TB: auto-schedule cascade may rewrite<br/>ancestors and dependency-reachable tasks
  TB->>RL: endGesture()
  RL->>RL: frozenRef = null; COLD packRows() -> truth
  RL-->>C: new layout + revision bump
  C->>C: animate y (150ms dragged bar, 90ms others)

Loading

The stability mechanism is document order itself, not a hint. Because iteration is in document order and first-fit is deterministic, a task whose predecessors in the document are unchanged usually keeps its lane for free. That is the real payoff of choosing document order over date order, and it is the only stability mechanism that survives the export-parity constraint.

And R1's F5 correction is load-bearing: do not put chartSlice.dragState in the memo dependency array. setSharedDragState is written once per requestAnimationFrame (useTaskBarInteraction.ts:478 → chartSlice.ts:1185), producing a fresh object each frame. Gating the memo on it would invalidate the pack 60 times a second — the exact opposite of the intent. Freeze must be edge-triggered via a ref, and the frozen layout must not be parked on dragState (R3 §5).

The mouseup lane snap is a real UX defect and cannot be designed away — only made rare, legible and recoverable:

1. Rare: document-order locality does most of the work.
2. Never let the dragged bar leave the viewport. If the committed lane is off-screen, scroll it into view. Mandatory, not optional.
3. Animate the dragged bar differently: 150 ms y transition plus its selection ring; other displaced bars get a shorter, lower-contrast 90 ms transition. Users track one object, not forty.
4. prefers-reduced-motion: reduce ⇒ no transition. VRT must disable transitions or baselines are non-deterministic.
5. Multi-drag is the bad case. MULTI_DRAG_TASKS moves N bars at once; on commit, N lanes change plus cascades. Prototype this gesture specifically before committing to Stage 3.
6. Vertical drag must never be interpreted as a lane assignment. Lanes are derived; a user-draggable lane creates a pin, a pin creates persisted layout state, and persisted layout state destroys export ≡ screen and undo determinism in one move. This also settles C's open question 5: no metadata.lanePin.
7. R2's addition, which I adopt: on any commit that relocates more than 3 unrelated bars, show a toast — "Moved Design. 3 other tasks shifted to make room." with an inline Undo. Otherwise the user's first instinct is Ctrl+Z to "put the layout back", they get their date back and a still-different layout, and they conclude undo is broken.

Recorded loser: D's packRows(previous?); R1's gesture-scoped tie-break; A's layoutEpoch (see §5); lane pinning in any form.

---

4.5 — Colour cannot be the binding key → the bar's own name is, and that has a consequence.

R2 falsified B's "colour as the persistent shared key" against src/types/colorMode.types.ts:11-16. Four of five ColorModes assign colour by group:

Mode	What colour identifies
manual	per task — the only mode where colour can be an identity key, and only if the user picked distinct colours
theme	palette-assigned; repeats across tasks
summary	children inherit the parent's colour — colour = group
taskType	three colours for the whole project
hierarchy	one hue lightened by depth — colour = depth

Colour is a category channel here. B cannot simultaneously spend it on data and use it as the identity key — and B's own §2 cites Griffin's "use leader lines when colour already carries a data attribute", which is an admission that it is spent. With colour out and B's addendum A11 cutting leader lines, B was left with no always-on binding cue at all. Fixed as follows.

Ruling — the four-tier binding model:

1. Always-on: the task's own name on the bar. It is what the user searches for, it survives every colour mode and high contrast, and it costs nothing new — TaskLabelPosition already exists (preferences.types.ts:28). Secondary always-on cue: the outline row-number badge at the left end of each bar (from C), suppressed below a narrow-bar threshold.
2. Transient: bidirectional cross-highlight on hover and selection, driven by hoveredTaskId in chartSlice and applied via data-task-id attributes plus a CSS attribute selector — not an isHovered prop, which would defeat the React.memo on TaskTableRow and re-render 500 rows on every mouse move. Apple HIG's split-view guidance endorses persistent selection highlight in every pane as the orientation mechanism (RESEARCH_PEER §A).
3. On demand: reveal, in both directions. Click a row → the chart scrolls horizontally to bring the bar into view and the bar pulses once (useScrollToDate already does exactly this for newly created tasks — reuse it). Click a bar → the list scrolls that row into view with scrollIntoView({ block: "nearest" }). Bryntum ships this as scrollToTaskOnClick. Both are the same code path in both modes, so One-task-per-row gains "locate" for free. Ship it in Stage 2, before Stage 3 exists.
4. Exactly one leader line, for exactly one case: the selected task whose counterpart is scrolled off-screen. Griffin 2015 (IEEE TVCG 21(3), eye-tracking) found leader lines and colour highlighting perform equivalently for information extraction (mean error 0.69 vs 0.88 — not meaningfully different) and are "a viable alternative to color-based highlighting" whose real advantage is that they free the colour channel to encode data. Steinberger 2011 (IEEE TVCG 17(12), InfoVis Best Paper) found links beat plain highlighting on speed and satisfaction in complex, ambiguous settings. The two papers do not fully agree; the reconciliation B's addendum reached is correct and I adopt it: adjacent panes tie, so highlight; links win when correspondence is ambiguous or the counterpart is far away, so reserve one line for exactly that. Constraints: one line at a time, never N; drawn in a portal overlay above the SplitPane divider (each pane clips independently); suppressed when the table is collapsed or >1 task is selected; visually distinct from a dependency arrow (thin, dotted, slate-400, no arrowhead).

Rejected: persistent connectors for all tasks (spaghetti past N=8, collides with dependency arrows); lane-index colour coding of table rows (fights the task-colour channel and churns on every edit).

The consequence, and it is uncomfortable. If the bar's name is the binding key, then shared rows only works at zoom levels where most bars can carry a label, and R4's measurement says the median bar in the reference project cannot at fit-to-screen zoom. Two things follow:

• Do not force TaskLabelPosition to inside as A §2.6.3 proposed. It is a persisted setting with a Format-tab control; silently overriding it is a parity break by the author's own definition (R2-13). Compute an effective label position, leave the stored preference alone, and surface the override in the tooltip.
• A §2.6.3's fix is also inapplicable to two of three task types (R1 F6). TaskBar.tsx:483 and :523 both do labelPosition === "inside" ? "after" : labelPosition for milestones and summaries, and TaskShapeLabel (:124-155) has no inside branch at all — it renders <text> at anchorX ± LABEL_PADDING with no clip path. A milestone in a shared lane paints its unbounded-length name over the next task's bar at every zoom level. Regular bars are fine (inside uses clipPath at :675-678). Fix: give TaskShapeLabel a real inside branch; for milestones, which have no inside, suppress the label and rely on hover/selection.
• Write the limitation into the help topic in plain words: "Shared rows works best when you are zoomed in enough to read the bar labels. Zoom out far enough and bars become unlabelled blocks."

Recorded loser: B's "colour as the persistent shared key"; A's forced inside label position.

---

4.6 — Naming → "Shared rows", in View ▸ Layout.

A's rejections are excellent and stand wholesale: Compact collides head-on with the 28px density preset whose own description string is "Shows more tasks on screen" (preferencesOptions.ts:59-63) — verbatim the new feature's value proposition. Condensed is the same word by another route. Swimlanes must be reserved for a future semantic group-by. Stacked implies z-order. A's lint guard banning the token compact inside the packing module is a good idea; keep it.

A's proposal is dead on two verified counts (R2-7): the pitch was "a dropdown sitting next to the existing density control" — but Density lives in the Format tab (FormatTabContent.tsx:101, ToolbarGroup label="Display" → "UI Density"), one tab away; and a control named "Row Layout" would sit inside ViewTabContent.tsx:213's ToolbarGroup label="Layout" — a naming collision at the exact point of installation. I verified both.

Ruling:

Layer	Name
Ribbon group	View ▸ Layout (next to the existing Table toggle — both are "how is the workspace arranged" controls, and the group is under-populated)
Control label	Timeline rows
Option A (today's view)	One task per row
Option B (new)	Shared rows
Feature name in help / CHANGELOG / commits	Shared rows
Internal / technical term	row packing
Code identifiers	RowLayoutMode = "list" | "packed", rowLayoutMode, packRows.ts, RowResolver

Test the pair against the collision it must survive — one sentence each, both of which a PM would accept:

Setting	Sentence
Format ▸ Display ▸ Density	"How tall each row is."
View ▸ Layout ▸ Timeline rows	"Whether tasks that don't overlap in time can share a row."

"Shared" is ordinary English, describes the mechanism truthfully, has zero collisions in this product's vocabulary, and — usefully — implies nothing about grouping, which directly serves §4.7 below. "Packed" implies containment; "shared" implies co-tenancy. "One task per row" is the author's own phrasing from the issue and is better than "Classic", which would imply the default view is deprecated.

And the part no concept proposed, which I consider the single best UI idea to come out of this effort — the live outcome string:

View  ▸  Layout

  Timeline rows  ▾
  ┌──────────────────────────────────────────────────────────────┐
  │ ● One task per row    Classic Gantt. Every task gets a row.  │
  │ ○ Shared rows         Tasks that don't overlap share a row.  │
  │                       29 tasks fit in 15 rows.       ← live  │
  └──────────────────────────────────────────────────────────────┘

It is one packRows() call on dropdown-open — 0.04 ms at n=500, measured. It converts an unmeasurable promise into a visible one at the point of use. If the answer is "29 tasks fit in 27 rows", the user learns not to bother, and that is a strictly better outcome than a silent no-op. When laneCount === taskCount, disable the option with "No rows can be shared in this project". This is the decision gate of §2, shipped into the product.

Recorded loser: "Compact Mode" (the issue title); A's "Row Packing" / "Row Layout"; B's "Timeline layout: Rows / Lanes"; "Condensed", "Swimlanes", "Stacked".

---

4.7 — The ARIA model → lanes are exposed as nothing; the table stays the required route.

Ruling, five parts:

(a) Packing is a purely visual affordance and is exposed to assistive technology as nothing. Lanes get role="presentation". A lane index is a bin number from a first-fit pass: it carries no project meaning, the user did not choose it, it changes when an unrelated task's date changes, it is unverifiable and unactionable for a non-sighted user, and announcing it lengthens every focus announcement. C §5.6's proposed "…Lane 2, third of five in this lane" is rejected. Accessible names carry project facts only — name, type, dates, working days, progress, dependencies, outline position ("task 17 of 42"), selection state. Live regions announce document changes ("Task created", "2 tasks deleted"), never shape changes ("chart is now 4 lanes").

The corollary is the reassuring part: because packing is invisible to AT by design, the AT experience in Shared rows is identical to One task per row — which is the author's parity constraint, satisfied exactly. That is only true if the per-task rows survive, which §4.1 guarantees.

(b) DOM order stays logical order. Packing is achieved entirely through geometry. Promote this from B's addendum A10 to a hard, tested requirement (WCAG 1.3.2 Meaningful Sequence, 2.4.3 Focus Order). For an SVG chart it is free — y already comes from a single rowIndex argument into getTaskBarGeometry — so nothing forces the bar array to be sorted by lane. Test it, because it is exactly the kind of invariant a later performance "optimisation" would break.

(c) Never aria-owns. The instinctive fix — bind a table row to its packed bar elsewhere in the DOM — is documented as unreliable (RESEARCH_PEER §C, MDN): "if an element has both DOM children and aria-owns references, DOM children appear first, followed by owned elements" — it can only append to accessible-tree order, never interleave; MDN explicitly says "avoid using aria-owns to match reordering from the CSS order property"; and it was not exposed to VoiceOver before iOS 17.3 / macOS 14.3. Anyone who reaches for it must be stopped.

(d) Reject role="application". It suspends browse/virtual mode and quick-nav keys entirely and, per MDN, "the author must take full responsibility" for all keyboard/focus/mouse handling. Also reject aria-roledescription and the role=img/application chart-fallback pattern — no W3C source supports it (RESEARCH_PEER §C, negative finding).

(e) The chart is supplementary, and stays supplementary. In Stage 3, give each TaskBar an aria-label and role="graphics-symbol" — matching the existing precedent in this codebase, DependencyArrow.tsx:116, which also carries tabIndex={0} and an aria-label and is the one focusable thing in the chart today (both B and C missed this). Wrap the bars in <g role="group" aria-label="Timeline chart, 42 tasks"> with one tab stop that announces the summary and directs to the table. Reject C's 4-axis canvas navigation model (←/→ along lane, ↑/↓ between lanes, Ctrl+←/→ chronological, Ctrl+↑/↓ outline): C itself concedes no commercial Gantt ships true 2-D timeline arrow navigation and that Syncfusion self-rates its own screen-reader support "Intermediate". Betting the product's only accessible surface on a model nobody has shipped is not a risk worth taking when the table is right there.

Roving tabindex over aria-activedescendant, if a focus model is ever added to the canvas. C is right and B's addendum A10.3 is wrong: activedescendant also requires the element to exist in the DOM, so it buys nothing against virtualisation, while additionally requiring manual scroll-into-view and having weaker SVG support.

Correcting the record on what actually fails today, because two reviewers disagreed and it matters for scoping:

SC	Classic mode today	Ruling
2.1.1 Keyboard for bar move / resize / progress	R3 called it a clean failure; R2 called it a pass	R2 is right, R3 is overruled. 2.1.1 is functionality-scoped, not gesture-scoped. startDate, endDate, duration and progress are editable cells (tableColumns.ts:141-209) reachable by useCellNavigation over EDITABLE_FIELDS (task.types.ts:54-63). Changing a task's dates is bar-move. Row reorder is keyboard-operable via dnd-kit's KeyboardSensor. Passes.
2.5.7 Dragging Movements for the same operations	C claimed pre-existing failure	Passes, same reasoning, under 2.5.8's "Equivalent" exception.
2.1.1 + 2.5.7 for dependency creation	—	Genuine failure, today, in both modes. addDependency is referenced by exactly three files: dependencySlice.ts, command.types.ts, useDependencyDrag.ts. No menu item, no field, no keyboard path.

So the a11y debt this issue must not be charged for is: dependency creation has no keyboard or non-drag pointer path. C's "Link to…" menu item + L shortcut fixes it. Ship it as its own issue, independent of #88 — and note that removing the per-task rows would create the 2.5.7 failure that C wrongly claimed already existed.

Three pre-existing defects to spin off as separate PRs, all found during this review, none belonging to #88:

1. TaskTable.tsx:146 declares role="grid" but the tree nests (parent), expands (task.open, aria-expanded at TaskDataCells.tsx:289) and is editable → should be role="treegrid" per W3C APG. B, C and R3 all agree.
2. TaskTableRow.tsx:164 sets aria-rowindex with no aria-rowcount anywhere in src/ — screen readers announce "row 7" with no "of N", and globalRowNumber is deliberately gappy under hiddenTaskIds, which makes the missing count worse.
3. ViewSettings has no unknown-field preservation while SerializedTask, SerializedDependency and GanttFile all do (types.ts:63-65, 88-90; re-emission at serialize.ts:126-137, 158-176). Save rebuilds ViewSettings from the store via two closed Pick<> literals in useFileOperations.ts:298-360, 369-433, so any field the store never held is erased on round-trip.

On the workingDaysMode finding — report it accurately, because it has been overstated. ViewSettings.workingDaysMode (types.ts:117) is read by deserialize.ts:511 but written by neither useLayoutViewSettings nor useFeatureViewSettings. That is real. But the field is vestigial: working-days arithmetic is always-on since b644186, and outside fileOperations/ the name survives only in comments. So this is a stale type plus dead parser surface to clean up — not live data loss. It is a working demonstration that the ViewSettings unknown-field hole is a real mechanism, which is why item 3 above is worth its own PR, but nobody's data is being harmed today.

Recorded loser: C's lane announcements; C's 4-axis canvas keyboard model; B's aria-activedescendant; aria-owns in any form; role="application"; R3's 2.1.1 framing.

---

5. Rejected, and why — do not re-litigate these

Falsified claims. Nothing may be built on these.

Claim	Source	Status	Evidence
"Same-lane arrows already handled by buildSameRowHookPath() (elbowPath.ts:423)"	A §2.1, §2.5, Part 6	FALSE	:423 is the FF branch; :431 is SS. FS — by far the commonest, and the one first-fit produces most — reaches :102 and returns buildStraightLine. At A's own gapDays = 0, from.x === to.x exactly, so calculateArrowPath falls to calculateRoutedPath → buildSCurvePath, which exits right 15px, drops into the gutter, runs left 30px back over the predecessor, and re-enters. A chain of eight abutting tasks in one lane produces eight identical collinear backwards hooks at the same y. Arrow routing is NEW work on the critical path.
Prefix stability: "an edit to t_i can never move any t_j with j < i" — proposed as help text	A §2.5	FALSE	Shipped bidirectional auto-scheduling (taskSlice.ts:250-278 → dateAdjustment.ts:382-396) follows the dependency graph, not document order, and bidirectional: true lets tasks move earlier. A dependency from row 40 to row 2 rewrites row 2. recalculateSummaryAncestors (:240-247) rewrites ancestors, always at lower indices. And "above" is not even well-formed in a packed view. Shipping it as help text would be actively misleading. Replace with the true, testable, weaker statement: "A change that does not alter any task's dates, order, parent, type or collapsed state never changes the layout."
layoutEpoch in taskSlice, "explicit and testable"	A §2.4	UNDELIVERABLE	grep -c "useTaskStore.setState" src/ (non-test) = 39, most writing tasks wholesale, none routed through actions — historySlice alone at :282, :325, :344, :359, :423, :522, :564, :644, :692, :710, :784, :876, :922. Undoing a reorder would leave the layout stale. And it buys 0.04 ms, while ChartCanvas.tsx:305-355 rebuilds a strictly more expensive geometry map on tasks identity anyway. Use D's content-derived packKey.
"The whole change is a substitution of one integer, four sites"	A §2.1	WRONG BY ~10x	R3: 25-31 files, 700-1,400 net lines, before any left-panel work.
"Export ignores collapse state"; add collapsedTaskIds to prepareExportTasks	D §4	FALSE	hierarchy.ts:440: const isCollapsed = task.open === false || collapsedTaskIds.has(task.id); — the open === false half is unconditional. tests/unit/utils/hierarchy.test.ts:811-822 proves it. The parameter is redundant at every call site. Dead API surface — drop it.
"10k tasks → 5-10 ms"	D §6	3-6x optimistic	Measured 29 ms with a linear fits() scan.
"Classic mode is literally packed mode with every lane exploded"	C §0(b)	FALSE	Explode-all yields lane-grouped chronological rows, no summaries, no indentation — a third view.
"Row Layout sits next to Density in the View tab"	A §1.4(c)	FALSE	Density is in FormatTabContent.tsx:101. "Row Layout" also collides with ViewTabContent.tsx:213's Layout group.
"ChartCanvas.taskGeometries is the injection point"	B, shared brief	FALSE	Three independent geometry sites: ChartCanvas.tsx:325 (marquee + handles), TaskBar.tsx:316 (the bar actually drawn), DependencyArrows.tsx:81 (arrow endpoints). Patching only the first moves hit-testing and handles while the bars stay put.
"useTimelineAreaContextMenu already mis-targets today"	C	FALSE	It is correct today — headerHeight: 0 and tasks is the same visible list the bars come from. The rewrite is still right; the "existing bug" framing is not.
"prepareExportTasks / svgExport / pdfExport can call buildLaneLayout identically"	A	CATEGORY ERROR	prepareExportTasks is a pure membership filter with no y-coordinate concept. The CLAUDE.md rule is satisfied vacuously for packing, because packing removes no tasks. Doc-only @see note.
SC 2.5.7 / 2.1.1 "already failing" for bar move/resize/progress	C §3.4	OVERSTATED	Both are functionality-scoped and the table discharges both. The genuine failure is dependency creation.
ViewSettings.workingDaysMode "live data loss"	R3	REAL BUT MILDER	Vestigial field; stale type + dead parser surface, not data harm.

Design decisions rejected, with the reason:

Rejected	Why	Ruling in
C's Lane Ledger	8 parity breaks, converts passing WCAG criteria into failures, delivers the author's own complaint back to him, scored 9/25 by B	§4.1
C's Detail Strip	A 1×7 strip cannot do the scan-and-compare work a spreadsheet exists for	§4.1
C's lane explode, explodedLanes	Lane-indexed UI state is not undo-safe; "explode all" is a third view, not classic mode	§4.1
C's mode-dependent menu labels	Teaches two vocabularies for one action	§4.1
B's "arrows default-off in packed mode" (addendum A11)	A literal violation of the author's constraint. showDependencies is already a global ViewSettings toggle; a different default per mode means an existing setting silently changes meaning. If routing fails, the packer is wrong, not the feature.	Part 2 §6
B's "colour as the shared key"	Colour is a category channel in 4 of 5 ColorModes	§4.5
B's shrink-lane-to-a-floor-then-grow (A8)	Makes the layout mode fight Density over one number	§4.2
A's band-per-summary as the default that delivers the value	Measured 1.93x; hits its own analytic ceiling S + B	§1
A's milestone ◆3 cluster glyph	Contradicts A's own tooltip promise "Nothing is hidden". Never hide a task in an editing view.	Part 2 §6
C's eventMaxStack "+N more" lane cap	Same reason	Part 2 §6
A's true single-line overlap mode	Right call, wrong reason. A said parity is "structurally impossible"; Bryntum ships exactly this as eventLayout: 'none', so it is evidently possible. The defensible version: an overlap mode cannot offer unambiguous hit-testing, so it can only ever be read-only. And R2 is right that a display the user cannot see or verify on screen has no business in the export dialog either. Do not ship it anywhere.	—
Lane pinning (metadata.lanePin)	Persisted layout state destroys export ≡ screen and undo determinism	§4.4
Vertical drag as lane assignment	Same	§4.4
A's 1px hairline stroke to separate abutting bars	At MIN_ZOOM = 0.05, pixelsPerDay = 1.25; a 1px stroke centred on the edge eats a 1-day bar entirely — it erases data at exactly the zoom where compression matters. There is also no single "grid background colour" (weekend and holiday shading, GridLines.tsx:38-41). Instead: inset each bar's rendered rect by min(1, width/4) px per side — separation in layout space, degrades gracefully, needs no colour knowledge, one expression in getTaskBarGeometry.	Part 2 §5

Confirmed-good foundations — keep without re-arguing:

• Document-order first-fit. Measured 2-5% excess lanes over optimal in 1,200 trials; exact omega in 7/8 real-data configs.
• Date-unit collision, never pixel. A and D reached it independently and D's export argument is decisive: export/calculations.ts:240 computes its own pixelsPerDay = BASE_PIXELS_PER_DAY * effectiveZoom, so a pixel-based packer would silently produce different lanes in the export than on screen. Note that of A's three arguments only this one holds — the useInfiniteScroll argument is false (that hook is horizontal-only) — but one sufficient argument is enough. Do not revisit this.
• Derived, never persisted; the same pure function on the screen and export paths. The best structural decision in any of the four concepts.
• First-fit over best-fit. "Closest flips on a one-day edit" is exactly right, and the left-aligned-text analogy is a good way to explain the ragged bottom to users.
• Sub-ms packing at 500 tasks — verified at 0.04 ms.
• useMarqueeSelection needs no work — already geometry-based over taskGeometriesArray. (One caveat nobody stated: ChartCanvas.tsx:319-321 skips date-less tasks, so those are already un-marquee-able. Worth a line in the sprint doc.)
• D's packIntervals reuse for arrow channel assignment — the most elegant idea across all four concepts.
• D §5 (persistence analysis) — complete, correct, line-accurate. Its placement recommendation is overruled in Part 2 §7, but its analysis remains the reference for any future ViewSettings field.
• B's two corrections to the shared brief — both verified true by R3: SelectionHighlight.tsx is the date-range band, not row selection (row bands are the inline SelectionRows at ChartCanvas.tsx:154-205, with a table-side twin at RowOverlays.tsx); and there is one vertical scroll driver writing translateY to both panes, with useSyncScroll horizontal-only.
• C's citation discipline — 11/11 file:line references resolved. (Aside: MEMORY.md still says EDITABLE_FIELDS is at taskSlice.ts:134; C is right and the memory file is stale.)
• A's rejection of the overlay mode, with the corrected reasoning above.

---

Part 2 follows: the full implementation spec — modules, interfaces, algorithm, scroll model, arrows, export, persistence, keyboard, help content, wireframes, and the merged parity matrix.

[kitikonti]

FINAL CONCEPT — Issue #88 · Part 2 of 3

Implementation spec. (Part 1 = verdict, decision gate, rulings, rejected-and-why. Part 3 = test plan, rollout gates, open questions.)

Everything here is written so it can be built without re-deriving anything. Stages 0-2 are recommended unconditionally. Stage 3 is gated on the measurement in Part 1 §2.

---

1. The pipeline, end to end

flowchart TD
  T["taskSlice.tasks"] --> S1
  H["chartSlice.hiddenTaskIds"] --> S2
  subgraph P["useFlattenedTasks — EXISTS, unchanged"]
    S1["Stage 1 · buildFlattenedTaskList(tasks, collapsedIds)<br/>hierarchy.ts:419 · assigns globalRowNumber<br/>drops descendants of task.open === false"]
    S2["Stage 2 · filter(hiddenTaskIds)<br/>row-number gaps preserved"]
    S1 --> S2
  end
  S2 --> S3
  M["rowLayoutMode<br/>userPreferencesSlice"] --> S3
  subgraph N["useRowLayout — NEW, additive"]
    S3["Stage 3 · packRows(flattenedTasks, mode, opts)<br/>PURE · date units only · no previous, no pixels"]
    K["packKey(flattenedTasks, mode, opts)<br/>content hash, O(n) · NOT tasks identity"]
    F["frozenRef — gesture snapshot<br/>edge-triggered, never a memo dep"]
    K -.memo key.-> S3
    F -.overrides during drag.-> S3
  end
  S3 --> R["createRowResolver(layout, rowHeight)<br/>laneOf · yOf · taskAtPoint"]
  R --> C1["ChartCanvas<br/>taskGeometries · SelectionRows · height"]
  R --> C2["TaskBar<br/>own geometry — MUST consume resolver"]
  R --> C3["DependencyArrows<br/>endpoints + gutter channels"]
  R --> C4["GridLines<br/>laneCount, not taskCount"]
  R --> C5["layoutCalculations<br/>SCROLL DRIVER HEIGHT"]
  R --> C6["useTimelineAreaContextMenu<br/>taskAtPoint — the INVERSE map"]
  R --> E["ExportRenderer · exportLayout · pdfLayout · svgExport<br/>SAME pure function, no reimplementation"]
  S2 --> TT["TaskTable — ALWAYS one row per task<br/>in BOTH modes. Never sees the resolver."]
  style N fill:#1e3a5f,color:#fff
  style TT fill:#166534,color:#fff
  style C5 fill:#854d0e,color:#fff

Loading

Two invariants the diagram encodes and Part 3 tests:

• The table never consumes the resolver. useTaskRowData and useHideOperations also read stage-2 output and must stay strictly one-row-per-task. Compose; never extend useFlattenedTasks.
• The export path calls the same packRows. Not a reimplementation, not a copy. Export computes its own pixelsPerDay (export/calculations.ts:240), which is exactly why lane assignment must be in date units.

---

2. Stage 0 — Collapse All / Expand All · hours · feat:

The whole of Stage 0.

Store: nothing. expandAll / collapseAll already exist at src/store/slices/expansionActions.ts:82-97 and are tested at tests/unit/store/taskSlice.test.ts:1425-1505.

src/hooks/useViewTabActions.ts — the file is 172 LOC and today exposes Today Marker, Weekends, Holidays, Dependencies, Progress, Auto-scheduling, Zoom, Fit-to-view, Task-table collapse, High Contrast and Hide UI. Add two lines in the same shape as the existing bindings:

const expandAll   = useTaskStore((s) => s.expandAll);
const collapseAll = useTaskStore((s) => s.collapseAll);

src/components/Ribbon/ViewTabContent.tsx:213 — into the existing <ToolbarGroup label="Layout">, beside the Table toggle:

┌─ VIEW ────────────────────────────────────────────────────────────────────────┐
│ Show/Hide │ Scheduling │ Zoom │ Layout                    │ Display           │
│                                ┌──────────────────────────┐                   │
│                                │ [◧ Table] [⊟ Collapse]   │                   │
│                                │           [⊞ Expand]     │                   │
│                                └──────────────────────────┘                   │
└───────────────────────────────────────────────────────────────────────────────┘

Two ToolbarButtons, variant="default" (they are commands, not toggles), Phosphor ArrowsInSimple / ArrowsOutSimple at ICON_SIZE, labelPriority={3} to match the Table button.

src/hooks/useKeyboardShortcuts.ts — Ctrl+Shift+[ = collapse all, Ctrl+Shift+] = expand all. Verified free: the only bracket-adjacent binding is Alt+Shift+Arrow for indent/outdent (:311-320).

src/config/helpContent.ts — one HelpTopic (project rule):

{
  id: "view-collapse-all",
  title: "Collapse or expand every summary",
  description:
    "Collapse All hides the children of every summary task, so the chart shows only " +
    "top-level phases. Expand All puts them back. Nothing is deleted — collapsing is " +
    "a view state and is saved with your project.",
  shortcuts: ["{mod}+Shift+[", "{mod}+Shift+]"],
  uiPath: "View > Layout",
}

Undo: consistent with the existing expansion commands, which are in historySlice. Collapse-all is a single undoable command over the whole document. Verify against the existing toggleTaskCollapsed command shape rather than inventing one.

Why it is worth an evening: measured 29 → 7 rows, 4.14x, on the repo's own reference project. Better compression than the entire four-concept program. And it is the two-week experiment that decides Part 1's gate.

---

3. Stage 1 — the RowResolver refactor · 3-5 evenings · refactor:

No user-visible change. mode: "list" only. Ships and releases on its own, bisects cleanly, and de-risks everything after it. Do this even if you never build Stage 3.

3.1 New module — src/utils/layout/packRows.ts

import type { TaskId } from "@/types/branded.types";
import type { FlattenedTask } from "@/utils/hierarchy";

/** Vertical layout strategy for the TIMELINE panel only. The table is always a list. */
export type RowLayoutMode = "list" | "packed";

/** How far packing is allowed to reach across the outline. */
export type PackScope =
  | "perSummary"   // every summary keeps its row; its leaf children pack inside its band
  | "summaryRail"  // summaries occupy leading rows; ALL leaves pack globally beneath
  | "global";      // outline ignored; everything packs. Read-only-ish, see Part 1 §5

export interface PackOptions {
  /** Minimum gap in CALENDAR days between two bars sharing a lane. 0-365. Default 0. */
  minGapDays: number;
  /** Band scope. Default "perSummary". */
  scope: PackScope;
}

/** Placement of one task in the timeline's vertical coordinate system. */
export interface RowPlacement {
  taskId: TaskId;
  /** 0-based visual row ("lane"). In "list" mode this ALWAYS equals listIndex. */
  lane: number;
  /** 0-based index in the flattened VISIBLE list — today's rowIndex. */
  listIndex: number;
  /** 1-based number from the FULL list, preserving Excel-style gaps for hidden rows. */
  globalRowNumber: number;
  /** Left-to-right position within the lane. Drives arrow disambiguation and slot tests. */
  slot: number;
}

export interface RowLayout {
  mode: RowLayoutMode;
  byTaskId: ReadonlyMap<TaskId, RowPlacement>;
  /** lanes[i] = task ids in lane i, ordered by start date then (order, id). */
  lanes: ReadonlyArray<ReadonlyArray<TaskId>>;
  /** Visual rows the canvas must draw. EXCLUDES the placeholder row. */
  laneCount: number;
  /**
   * Bumped only when placement actually changes, so React.memo can compare a number
   * instead of deep-comparing a Map. Renaming a task does not bump it.
   */
  revision: number;
}

/**
 * Assign every visible task to a lane.
 *
 * PURE. Deterministic. Depends ONLY on its arguments.
 * There is deliberately NO `previous` parameter — see Part 1 section 4.4.
 * There is deliberately NO pixel or zoom input — see Part 1 section 5.
 */
export function packRows(
  flattened: ReadonlyArray<FlattenedTask>,
  mode: RowLayoutMode,
  options: PackOptions
): RowLayout;

/** Reused verbatim for dependency-arrow channel assignment. Same invariants, x-spans. */
export function packIntervals<T>(
  items: ReadonlyArray<T>,
  getSpan: (item: T) => { start: number; end: number },
  minGap: number
): number[];

export function createRowResolver(layout: RowLayout, rowHeight: number): RowResolver;

3.2 The resolver — the only thing renderers see

export interface RowResolver {
  readonly mode: RowLayoutMode;
  readonly laneCount: number;
  readonly rowHeight: number;
  /** Lane index, or null when not laid out (hidden / collapsed away / date-less). */
  laneOf(taskId: TaskId): number | null;
  /** Top edge y in canvas coordinates. Null when not laid out. */
  yOf(taskId: TaskId): number | null;
  /**
   * INVERSE map. Needs BOTH coordinates: in packed mode a lane holds many tasks,
   * so y alone cannot identify one. This is why it is on the interface from day one —
   * it forces every inverse site to be found rather than silently mis-hitting.
   */
  taskAtPoint(x: number, y: number): TaskId | null;
}

taskAtPoint is not speculative. src/hooks/useTimelineAreaContextMenu.ts:84-88 does exactly the inverse map today:

const rowIndex = Math.floor(svgY / rowHeight);
if (rowIndex >= 0 && rowIndex < tasks.length) {
  const taskId = tasks[rowIndex].id;

That is correct today (headerHeight: 0, tasks is the same visible list the bars are drawn from — C's "already broken" framing is wrong, R3 #8) and silently wrong the moment a lane holds two tasks. Silently, not visibly: the menu targets the wrong task. Rewrite it as a point-in-rect test against taskGeometriesArray.

3.3 The three geometry sites — this is the finding that sizes Stage 1

The shared brief and Concept B both said ChartCanvas.taskGeometries is the injection point. It is one of three (R3 #9). Any plan that patches only it produces a build where marquee selection and connection handles land in packed positions and the bars do not move.

Site	File:line	What it feeds
1	ChartCanvas.tsx:325 (memo at :305-355)	marquee selection, connection handles
2	TaskBar.tsx:316-323	the bar that is actually drawn
3	DependencyArrows.tsx:81	arrow endpoints

The prerequisite that makes A's "one integer" claim finally true: TaskBar must stop computing its own geometry and consume the shared one. Do that inside Stage 1, where it is invisible and provable. Then add a guard so it stays true — a unit test or lint rule that greps src/components/GanttChart/ for rowIndex: and index * rowHeight.

3.4 Every file that changes in Stage 1

File	LOC	Change	Est.
NEW src/utils/layout/packRows.ts	—	pure packer + packIntervals + createRowResolver	150-250
NEW src/hooks/useRowLayout.ts	—	useMemo on packKey + frozenRef	40-70
src/utils/timelineUtils.ts	451	getTaskBarGeometry :349-372 — no signature change, it already takes rowIndex; rename the field to lane	5-15
src/components/GanttChart/ChartCanvas.tsx	583	taskGeometries :325; SelectionRows :154-205; taskBasedHeight :414; rowCount :417-420; GridLines taskCount :445	80-150
src/components/GanttChart/TaskBar.tsx	687	delete the independent geometry at :316; consume the shared one; rename prop rowIndex → lane	10-25
src/components/GanttChart/GridLines.tsx	258	:189-194 — the taskCount prop is already just a number, so pass laneCount. Zero code change, different value. The nicest file in the refactor	10-20
src/components/GanttChart/DependencyArrows.tsx	183	:75-95 rowIndex: index → resolver.laneOf(task.id)	15-30
src/hooks/useTimelineAreaContextMenu.ts	143	:84-88 → resolver.taskAtPoint(svgX, svgY)	20-35
src/utils/layoutCalculations.ts	71	:59 — the scroll-driver height. Add laneCount; see §5	15-30
src/components/Layout/GanttLayout.tsx	225	:151-158 taskCount: flattenedTasks.length; call useRowLayout; drill resolver; the clamped translate in :100-115	30-80
src/components/Layout/TimelinePanel.tsx	—	pass resolver through	5
src/components/Export/ExportRenderer.tsx	623	:264/:388/:461/:481-490/:524/:614	50-90
src/utils/export/exportLayout.ts	396	:128 content height	10-20
src/utils/export/pdfLayout.ts	495	:410 page-fit height — only D found this; the failure is silent (PDF over-allocates height, chart floats in whitespace, no error)	10-20
src/utils/export/taskTableRenderer.ts	681	:478/:663 — the left table is never packed, so this stays row-indexed; only the table/timeline height reconciliation changes	20-60
src/utils/export/svgExport.ts	682	table vs cloned-chart vertical alignment — no concept covered this explicitly	20-50
src/hooks/useMarqueeSelection.ts	—	No change. Already geometry-based over taskGeometriesArray, which becomes lane-correct for free	0
src/utils/export/prepareExportTasks.ts	—	No code change. Doc-only @see note: packing removes no tasks, so the CLAUDE.md rule is satisfied vacuously	0

src/components/GanttChart/SelectionHighlight.tsx: do not touch. It is the date-range vertical band shared by TimelineHeader and ChartCanvas (y=0, full height). The shared brief was wrong; B corrected it and R3 confirmed. Row selection is the inline SelectionRows at ChartCanvas.tsx:154-205, with a table-side twin at RowOverlays.tsx:37-38 fed by useTaskRowData.ts:68-69. Two files, two fixes, and the table-side twin is a third.

3.5 Stage 1 acceptance gate

1. npm run ci:local green — all 5,239 unit tests untouched. 746 of them live in the 28 files that reference row geometry (hierarchy 75, elbowPath 69, svgExport 56, contextMenus 54, renderConstants 51, timelineUtils 42, taskTableRenderer 41, useHideOperations 38, useTaskRowData 31, TaskBar 28, GridLines 21, DependencyArrow 21, …). Those 746 are the real safety net. If list mode is genuinely the identity case, all 746 pass with zero edits — a far stronger and far cheaper statement than nine screenshots.
2. All ~190 E2E pass untouched (~89 sit in row/bar-coupled specs, led by dependency-scheduling.spec.ts with 40).
3. npm run test:vrt with zero baseline updates. Keep this gate — it is free — but see Part 3 §2 for why it proves much less than it sounds, and why 3-4 new baselines must be added before Stage 1.
4. refactor: commit ⇒ no version bump.

---

4. Stage 2 — Rollup on collapse · 4-7 evenings · feat:

This is the headline deliverable, not a side note. A wrote it down as an "additive" note in §2.7-C and then recommended a worse-performing default. R4 measured it at 7 rows, lossless, 4.14x — matching collapse-all while keeping every descendant visible and clickable. B's addendum found it shipping in a real product (Bryntum Rollups: for rollup: true tasks the Gantt "displays a small bar or diamond below its summary task in the timeline", interactions fire with isRollup: true, and scrollToTaskOnClick scrolls the real row into view). A and B converged on it independently from different directions — the strongest signal in the whole Phase 1 set.

COLLAPSED SUMMARY, TODAY                    COLLAPSED SUMMARY, WITH ROLLUP
┌────────────────┬──────────────────┐       ┌────────────────┬──────────────────┐
│ ▸ Rocket & S/C │ ▐██████████████▌ │       │ ▸ Rocket & S/C │ ▐██████████████▌ │
│                │                  │       │                │  ▪▪  ▪▪▪▪  ◆ ▪▪▪ │ ← rollup glyphs
│ ▸ Supply & Log │   ▐███████████▌  │       │ ▸ Supply & Log │   ▐███████████▌  │
│                │                  │       │                │    ▪▪▪  ▪▪  ▪▪▪▪ │
└────────────────┴──────────────────┘       └────────────────┴──────────────────┘
  4 children invisible, unclickable            4 children visible, clickable,
                                               click -> expands + reveals the row

Why it is cheap, and this is the load-bearing property: row count is unchanged. One row per visible task still holds. y = index * rowHeight survives untouched. The table stays 1:1. ARIA is untouched. The scroll model is untouched. Exports need only the extra glyphs.

Spec:

• Rollup glyphs render inside the collapsed summary's own row band, in the lower third (taskBarOffset + taskBarHeight * 0.72), height max(3, taskBarHeight * 0.28).
• The glyph set for one collapsed summary is its entire visible descendant subtree (leaves and nested summaries alike), not just direct children. Nested collapsed summaries contribute their own descendants — the rollup is transitive, which is what makes collapse-all lossless.
• Glyph x-geometry comes from the same getTaskBarGeometry with the summary's lane. Milestones roll up as small diamonds, respecting MILESTONE_SIZE_MIN/MAX = 6/10 (TaskBar.tsx:38-40).
• Overlapping glyphs are the normal case — a phase's children overlap each other constantly. Run packIntervals over the glyph x-spans and give the rollup strip up to 3 sub-rows inside the summary band; beyond 3, merge into a single translucent density strip. This is the one place where the packer earns its keep before Stage 3 exists, and it validates packIntervals under real load.
• Click a glyph → expandTask(summaryId) and select the task and scrollIntoView on its now-visible table row. That is Bryntum's scrollToTaskOnClick and it is also Part 1 §4.5's "reveal" tier — ship reveal here, it improves the default view too.
• Glyphs are not drag targets, not resize targets, not dependency-drag sources. They are read + click-to-reveal. That is a deliberate, documented limit, not an oversight, and it keeps useTaskBarInteraction / useDependencyDrag / ConnectionHandles completely out of scope.
• aria-hidden="true" on the glyph strip; the summary row's existing accessible name gains ", 4 collapsed tasks". No new tab stops.
• Export: the glyphs must render in ExportRenderer or the PNG/PDF/SVG will show a collapsed summary as an empty band while the screen shows glyphs. Same geometry function, so it is a small addition — but it is on the CLAUDE.md manual-verification list.
• Setting: View ▸ Layout ▸ [☑ Roll up collapsed tasks], default on. One boolean, device-scoped, same tier as the mode in §7.

Acceptance gate: collapse every summary → every leaf is still represented and clickable; row count equals Stage 0's collapse-all; PNG/PDF/SVG show the same glyphs at the same x positions; npm run test:vrt gains exactly one new baseline.

---

5. Stage 3 — Shared Rows · 25-45 evenings · feat: · GATED

Only build this if the Part 1 §2 measurement says your charts are flat, or if two weeks of Stages 0-2 leave the itch intact.

5.1 The algorithm

Document order, first fit, date units, no previous, no pixels.

/** A closed day-number interval. Milestones have start === end. */
interface Interval { start: number; end: number; taskId: TaskId }

/**
 * MUST be date-fns based. NOT Date.parse(s) / 86400000 —
 * parseISO("2025-03-30") returns LOCAL midnight and epoch division goes
 * off-by-one across a DST boundary in half the world. (R1 F12.)
 */
function toDayNumber(iso: string): number {
  return differenceInCalendarDays(parseISO(iso), EPOCH);
}

function toDayInterval(t: FlattenedTask): Interval {
  const start = toDayNumber(t.startDate);
  const end =
    t.type === "milestone"
      ? start                                   // a point in time
      : toDayNumber(t.endDate || t.startDate);  // INCLUSIVE — mirrors getTaskBarGeometry
  return { start, end, taskId: t.id };
}

/**
 * Can `iv` join `lane`? The lane is kept sorted by start, so only the two
 * neighbours around the insertion point need checking. O(log k).
 */
function fits(iv: Interval, lane: Interval[], gapDays: number): boolean {
  const i = lowerBoundByStart(lane, iv.start);
  const left = lane[i - 1];
  const right = lane[i];
  if (left && left.end + gapDays >= iv.start) return false;
  if (right && iv.end + gapDays >= right.start) return false;
  return true;
}

/** Lane index per task, parallel to `band`. */
function packBand(band: readonly FlattenedTask[], gapDays: number): number[] {
  const lanes: Interval[][] = [];
  const assigned: number[] = [];
  for (const task of band) {                    // <- DOCUMENT ORDER. Never re-sorted.
    const iv = toDayInterval(task);
    let placed = -1;
    for (let l = 0; l < lanes.length; l++) {    // <- FIRST fit, not best fit
      if (fits(iv, lanes[l], gapDays)) { placed = l; break; }
    }
    if (placed === -1) { lanes.push([]); placed = lanes.length - 1; }
    insertSortedByStart(lanes[placed], iv);
    assigned.push(placed);
  }
  return assigned;
}

Total order, mandatory (Part 1 §4.3). buildChildrenLookup sorts siblings by order alone (hierarchy.ts:146) and Array.prototype.sort is stable, so equal order values resolve by array position — which undoDeleteTask changes by appending restored tasks at the end (historySlice.ts:312-325). Sort the band by (order, id) before packing.

Milestones consume a slot. A zero-width interval [d, d] must still occupy the lane, or two milestones on the same day stack invisibly. But note the drawn extent is not the nominal day: TaskBar.tsx:457 passes centeredX = geometry.x + pixelsPerDay/2 - size as the centre to diamondPath, so the diamond's true centre sits size px left of the day centre and its extent is [cx - 2*size, cx]. Packing is in date units so this does not affect lane assignment — but any rendering overlap check must use the drawn extent.

Complexity. O(n · L · log k). Measured: n=100 <0.01 ms · n=500 0.04 ms · n=1,000 0.18 ms · n=5,000 5.7 ms · n=10,000 29 ms with a linear fits(). Use the binary-search fits() above and the top end improves substantially. At realistic sizes this is free and there is nothing to protect — which is the whole argument against layoutEpoch.

packScope is a setting, not a constant. Ship perSummary as the default (legible, keeps the outline) but expose summaryRail — measured 10 rows vs 15 on the reference file — because a WBS with parallel sibling leaves gets 6-13% from perSummary and needs the rail. Surface it as a secondary control inside the Timeline rows dropdown, with the same live outcome string, so the user can see the difference instead of being told about it.

5.2 packKey — invalidation without discipline

Do not use layoutEpoch (Part 1 §5). Use a content-derived key, computed in O(n) from the same data the packer consumes:

// src/hooks/useRowLayout.ts
function packKey(
  flattened: readonly FlattenedTask[],
  mode: RowLayoutMode,
  opts: PackOptions
): string {
  let h = 2166136261 >>> 0;                     // FNV-1a, 32-bit
  const mix = (s: string) => {
    for (let i = 0; i < s.length; i++) {
      h ^= s.charCodeAt(i);
      h = Math.imul(h, 16777619) >>> 0;
    }
  };
  for (const t of flattened) {
    mix(t.id); mix(t.startDate); mix(t.endDate ?? ""); mix(t.type ?? "task");
    mix(String(t.order)); mix(t.parent ?? "");
  }
  mix(mode); mix(String(opts.minGapDays)); mix(opts.scope);
  return `${flattened.length}:${h.toString(36)}`;
}

This covers all thirteen invalidation triggers for free, including the seven a counter would miss: task add/delete, hiddenTaskIds, undo/redo through any of the ~39 raw setState sites, the auto-schedule cascade's second set() (taskSlice.ts:270-277), recalculateSummaryAncestors, a working-days recalc that rewrites every date, and file load / multi-tab restore replacing tasks wholesale.

Why a key is needed at all: useFlattenedTasks.ts:38-45 memoizes on tasks identity, and Immer produces a new tasks array on every mutation — including a single keystroke in an inline name edit. A naive useMemo(..., [flattenedTasks]) would re-pack per keystroke. Renaming a task does not change any field in the key, so the memo holds and revision does not bump.

Never put chartSlice.dragState in the dependency array. It is written once per rAF (useTaskBarInteraction.ts:478 → chartSlice.ts:1185) and would invalidate the pack 60 times a second. The gesture freeze is a useRef, edge-triggered on gesture start and cleared on commit — and it must not be parked on dragState either (R3 §5).

5.3 Layout invariants — the honest, testable statement

Delete A's prefix-stability invariant and its proposed help text (falsified, Part 1 §5). Ship this instead, which is true, is what users actually notice, and is enforceable as a unit test:

A change that does not alter any task's dates, order, parent, type or collapsed state never changes the layout.

Typing a name must not move bars. That is the promise worth making.

5.4 The scroll model

src/utils/layoutCalculations.ts — a pure, already-unit-tested function, which is where this belongs:

export interface LayoutDimensionsInput {
  taskCount: number;
  laneCount: number;        // NEW. In list mode, === taskCount.
  rowHeight: number;
  viewportHeight: number;
  scaleTotalWidth: number | null;
  containerWidth: number;
}

export interface LayoutDimensions {
  totalContentHeight: number;   // max of the two panes — drives the single scrollbar
  listContentHeight: number;    // NEW
  chartContentHeight: number;   // NEW
  timelineHeaderWidth: number;
  contentAreaHeight: number;
}

const rows = (n: number, h: number) =>
  (n + PLACEHOLDER_ROW_COUNT) * h + HEADER_HEIGHT + SCROLLBAR_HEIGHT;

const listContentHeight  = rows(taskCount, rowHeight);
const chartContentHeight = rows(laneCount, rowHeight);   // laneHeight === rowHeight, always
const totalContentHeight = Math.max(listContentHeight, chartContentHeight);

src/components/Layout/GanttLayout.tsx:100-115 — the scroll handler becomes:

const maxScroll = (paneHeight: number) =>
  Math.max(0, paneHeight - contentAreaHeight);

const apply = (ref: RefObject<HTMLElement>, paneHeight: number) => {
  const y = Math.min(scrollTop, maxScroll(paneHeight));
  if (ref.current) ref.current.style.transform = `translateY(${-y}px)`;
};

apply(taskTableTranslateRef, listContentHeight);
apply(chartTranslateRef, chartContentHeight);

That is the entire change. In list mode laneCount === taskCount, both heights are equal, both clamps are identical, and the result is byte-identical to today — provable in layoutCalculations.test.ts, not merely asserted. Everything else in the scroll architecture is untouched: useSyncScroll is horizontal-only (chart↔header, table↔table-header), usePreventVerticalScroll(taskTableScrollRef) still forces the table's own scrollTop to 0, and ViewSettings.scrollTop stays a single scalar so the file format needs no migration.

SHARED ROWS · 29 tasks in the list, 15 lanes in the chart

              LEFT PANE (29 rows)          RIGHT PANE (15 lanes)
scrollTop=0   ┌──────────────────┐         ┌──────────────────────────┐
              │ 1 Mission Plan.  │         │ ▐████▌  ▐██▌   ▐█████▌   │ lane 0
              │ 2 Crew Select    │         │   ▐███████▌ ◆ ▐███▌      │ lane 1
              │ 3 Site Survey    │         │ ▐██▌   ▐████████▌        │ lane 2
              │ …                │         │      ▐█████▌   ▐███▌     │ …
              │ 29 Handover      │         │ ▐███▌      ▐██████▌      │ lane 14
              └──────────────────┘         ├──────────────────────────┤
                                           │                          │ ← chart is
                                           │   (nothing below lane 14)│   SHORTER; it
                                           └──────────────────────────┘   pins here

scrollTop=            ┌──────────────────┐  ┌──────────────────────────┐
maxScroll(list)       │ 14 Cargo Load    │  │ ▐████▌  ▐██▌   ▐█████▌   │ lane 0
                      │ …                │  │   ▐███████▌ ◆ ▐███▌      │ lane 1
                      │ 29 Handover      │  │ …unchanged — clamped…    │
                      │ + Add task…      │  │ ▐███▌      ▐██████▌      │ lane 14
                      └──────────────────┘  └──────────────────────────┘
                        list scrolled          chart PINNED at its own bottom
                        to its bottom          (here: never moved at all)

Stop-work gate: prototype this before anything else in Stage 3. ~10 lines. If a 500-row list scrolling against a 4-lane pinned chart feels broken, Stage 3 does not ship. (B's own uncertainty #3; R2 agreed nobody has looked at it.)

5.5 Rendering — five decisions

(a) No per-row grid rules in shared-rows mode. GridLines.tsx:188-194 draws taskCount + 1 horizontal rules at i * rowHeight. Reused as-is under packing, those become lane borders — boxes drawn around groups of unrelated tasks, visually asserting that a lane is a container. It is not; it is a bin index from a first-fit pass. Draw the packed area as one continuous field. The correct metaphor is text wrapping, not rows: the plan is one long strip that wrapped because the viewport is narrow, and readers already know that wrapped lines of a paragraph carry no grouping meaning.

Keep exactly one horizontal partition and make it semantic: the summary-band boundary under scope: "perSummary". Those lines mean something, so they are the only ones allowed.

Never name or number a lane in user-facing UI. No "Lane 2" label, no lane column on by default, no "Placed in lane 2" toast. If something must be said, say "Moved to make room".

(b) Separate abutting bars in layout space, not stroke space. Reject A's 1px hairline (Part 1 §5: it erases a 1.25px bar at MIN_ZOOM, and there is no single grid background colour under weekend/holiday shading). Instead, one expression in getTaskBarGeometry:

const inset = Math.min(1, width / 4);
// rendered rect: x + inset, width - 2 * inset

Degrades gracefully, needs no colour knowledge, height-neutral. Bars already carry rx = ry = TASK_BAR_RADIUS = 4 (TaskBar.tsx:43, :583-584), which already produces a visible pinch at normal zoom.

(c) The min-width clamp, decided deliberately. At pixelsPerDay = 1.25, two tasks disjoint in dates (Mar 1 and Mar 2) are 1.25 px apart; clamping both to a 3px minimum makes them overlap on screen while legally sharing a lane. The packer says no collision; the user sees one. There is precedent for accepting pixel-gated degradation (PROGRESS_HANDLE.minBarWidth = 30, TaskBar.tsx:69, :603 — the handle simply disappears below 30px). Ruling: clamp to 3px and accept the visual overlap, but only below a zoom where labels are already gone. Write it down; do not let it be emergent.

(d) Labels. Do not force TaskLabelPosition to inside (Part 1 §4.5). Compute an effective position; leave the stored preference alone; give TaskShapeLabel (TaskBar.tsx:124-155) a real inside branch; suppress milestone labels in shared-rows mode since a milestone has no inside and its unclipped <text> currently paints over the next bar.

(e) Never hide a task in an editing view. Three concepts gave three contradictory answers to "what if it doesn't fit" — A promised "Nothing is hidden" in the tooltip and then hid milestones behind a ◆3 cluster glyph; C adopted FullCalendar's eventMaxStack "+N more" cap. Ruling: no clustering, no "+N more", no cap. If bars collide visually, add a lane. Row count is the thing the user asked to reduce, but not at the price of a task that is present in the document and absent from the picture. Clustering belongs in Stage 2's rollup strip, where it is explicitly a summary affordance, or in an export overview — nowhere in the editable chart.

5.6 Dependency arrows — new work, on the critical path

Delete A's "already handled" claim (Part 1 §5). Budget this as a work package, not an if. It is the highest-uncertainty item in the plan: Airtable, in production, made Gantt layout and swimlane stacking mutually exclusive rather than solve it.

But arrows stay on in both modes. showDependencies is already a global ViewSettings toggle; giving it a different default per mode means an existing user setting silently changes meaning when you switch views — precisely the either/or the author forbade. If routing fails, the packer is wrong, not the feature.

Three cases, only one of which today's code handles:

Case	Today	Needed
FS, same lane, abutting (gapDays = 0)	from.x === to.x exactly → calculateRoutedPath → buildSCurvePath → 30px backwards hook at centre + max(4r, rowHeight*0.4), identical y for every such arrow in the lane	route through a per-lane gutter with a distinct channel
FS, same lane, non-adjacent (A ends Mar 1, C occupies Mar 5-10, B starts Mar 20, A→B)	straight line through C's bar	gutter + channel assigned over the whole x-span, not just the endpoints
SS / FF, same lane	buildSameRowHookPath (:424, :432) — works	unchanged

Design — D's idea, and it is the most elegant thing in the whole effort:

lane height = taskBarOffset + taskBarHeight + taskBarOffset + gutter

  lane 0  ▐████ Frontend ████▌▐████ QA ████▌      ▐███ Docs ███▌
          ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
  gutter   ch0            └──►                └───────────►      ← FS, channel 0
           ch1     └──────────────────────────────►             ← FS non-adjacent,
          ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄  channel 1 (clears
  lane 1  ▐██ Design ██▌   ▐███████ Build ███████▌                the bar it passes)

Channel assignment is packIntervals again, run over the arrows' x-spans instead of the tasks' date-spans. Same function, same invariants, free tests. That reuse is what makes this tractable.

Cost that is not the if: changing rowHeight semantics in packed mode touches layoutCalculations.ts:59, GridLines, the visual balance of all three density presets, every export row-height calculation, and every VRT baseline. Budget 8-15 evenings and treat the estimate as uncertain.

Degradation: below a length threshold, or when channels exceed the gutter, replace the full path with a short chevron stub at each endpoint plus focus-mode dimming (hovering or selecting a task dims all arrows not incident to it). Focus-mode dimming is the cheapest large legibility win and should ship first, before channel routing, in its own commit.

5.7 Export

Packing removes no tasks, so prepareExportTasks.ts needs no code change — only a doc @see note. The CLAUDE.md rule is satisfied vacuously. D's proposed collapsedTaskIds addition is dead API surface and is deleted from this plan (Part 1 §5).

What does change:

• ExportOptions.rowLayoutMode in src/utils/export/types.ts + a control in SharedExportOptions.tsx, defaulting to the current screen mode so what you see is what you export.
• ExportRenderer.tsx takes the same resolver. Same three geometry edits as ChartCanvas.
• exportLayout.ts:128 and pdfLayout.ts:410 become lane-aware. The pdfLayout failure is silent — miss it and the PDF over-allocates height and the chart floats in whitespace with no error.
• taskTableRenderer.ts:478, :663 keeps its row indexing (the exported table is always 1:1) but the table/timeline height reconciliation must top-align at max(N, L) * rowHeight.
• svgExport.ts — table vs cloned-chart vertical alignment. No concept covered this; budget for it.
• The export preview must render the packed layout at export scale, not screen scale. At A4 width the bars are far narrower than on a 2560px screen, so the label-suppression threshold fires and the export loses every label. The user must see that before exporting. There is no @media print anywhere in the codebase — export is the print path.
• Golden-file assertion: screen lane count === calculateExportDimensions lane count on a shared fixture. D proposed it and it is the single best test in any of the four concepts.

5.8 Persistence — user preference, not ViewSettings. This overrules D §5.

R2-8 identified a tier mismatch nobody else caught: all four concepts put rowLayoutMode in ViewSettings (the saved file), while the setting it most resembles — uiDensity — is a device preference in userPreferencesSlice. Consequence: opening a colleague's .ownchart would silently change your display. That is the silo feeling the author objects to, arriving through the back door.

Ruling: rowLayoutMode lives in UserPreferences. Verified: userPreferencesSlice.ts already uses zustand's persist middleware with createJSONStorage(() => localStorage) (:175, :272) and already has a runtime-validation block for untrusted localStorage values (:108, :145). So the whole persistence story is three files:

// src/types/preferences.types.ts — UserPreferences
  uiDensity: UiDensity;
  hideUI: boolean;
  rowLayoutMode: RowLayoutMode;        // NEW, default "list"
  rowLayoutScope: PackScope;           // NEW, default "perSummary"
  rowLayoutMinGapDays: number;         // NEW, default 0, clamped 0-365
  rollupCollapsedTasks: boolean;       // NEW (Stage 2), default true

plus the default object, the VALID_* runtime validator, and the setters in userPreferencesSlice.ts, plus optional entries in preferencesOptions.ts.

What this ruling buys — and I am claiming it as a scope reduction, not a detail. It removes eight files and ~120 lines from the critical path: fileOperations/types.ts, deserialize.ts (normalizeViewSettings), config/viewSettingsDefaults.ts, loadFromFile.ts, useFileOperations.ts (useFeatureViewSettings:369 — the file A's list omitted, without which the field is silently never written), chartSlice.ts (SettableViewFields), multiTabStorage.ts (ChartState:48-77), useMultiTabPersistence.ts. It also removes the validate.ts clamping surface and the migration question entirely.

D §5's analysis remains correct and remains the reference for any future ViewSettings field, including the real pre-existing hole it found: ViewSettings has no unknown-field preservation while SerializedTask, SerializedDependency and GanttFile all do, and save rebuilds ViewSettings from the store through two closed Pick<> literals, so a field the store never held is erased on round-trip. Close that in its own small hardening PR — mirror the __unknownFields pattern already in serialize.ts:126-137 — on its own merits, not as part of #88.

Consequence to accept and document: two browser tabs on the same chart share the mode (localStorage is per-origin, and zustand persist applies it at load). That is correct for a device preference and differs from zoom, which is per-tab. Say so in the help topic.

A file hint is explicitly deferred. If someone later wants a colleague's chart to suggest a mode, add an optional ViewSettings.rowLayoutMode hint plus R2's dismissible bar — "This project was saved in Shared rows. [Switch] [Keep One task per row]". Do not write a field you ignore; do not add it until the prompt exists.

Undo: rowLayoutMode is not undoable, consistent with showWeekends, showDependencies and hiddenColumns, all of which sit outside historySlice. Ctrl+Z after switching modes undoes your last edit, not your last view change. Say it in the help topic so it reads as a decision rather than an oversight.

5.9 The ribbon and the wireframe

┌─ OwnChart ────────────────────────────────────────────────────────────────────────────┐
│ File │ Home │ Insert │ VIEW │ Format │ Help                                            │
│ ┌Show/Hide┐ ┌Scheduling┐ ┌Zoom┐ ┌────────── Layout ──────────┐ ┌Display┐               │
│                                │ [◧ Table]  [⊟][⊞]           │                        │
│                                │ Timeline rows ▾  Shared rows │                        │
│                                │ [☑ Roll up collapsed tasks]  │                        │
│                                └──────────────────────────────┘                        │
├───────────────────────────────────┬────────────────────────────────────────────────────┤
│ #  Name          Start    End   ⋮ │  Mar          Apr           May          Jun       │
├───────────────────────────────────┼────────────────────────────────────────────────────┤
│ 1 ▾ Mission Plan 03-01  04-12   ▪ │ ▐══════ Mission Planning ══════▌ ▐═ Rocket & S/C ═▌ │
│ 2    Crew Select 03-01  03-14   ▪ │ ▐Crew Sel▌ ▐ Mission Arch ▌ ▐Site Survey▌  ▐Deltas▌ │
│ 3    Mission Arc 03-15  03-28   ▪ │   ▐ Reqs ▌  ▐ Budget ▌   ◆      ▐ Vendor Review ▌   │
│ 4    Site Survey 03-29  04-12   ▪ │                                                     │
│ 5 ▾ Rocket & S/C 04-13  06-30   ▪ │                                                     │
│ 6    Delta-V Calc04-13  04-26   ▪ │                                                     │
│ 7    Vendor Rev. 04-27  05-20   ▪ │       ↑ 29 rows on the left, 15 lanes on the right  │
│ …                                 │         chart pins when it runs out                 │
│ 29   Handover    06-20  06-30   ▪ │                                                     │
│ +  Add task…                      │                                                     │
└───────────────────────────────────┴────────────────────────────────────────────────────┘
  ▲ every task still has a row, a name cell, every column, and every editor

Hovering the table row "Site Survey" (bidirectional cross-highlight):

│ 4    Site Survey 03-29  04-12   ▪ │ ▐Crew Sel▌ ▐ Mission Arch ▌ ▐▓Site Survey▓▌         │
  ▲ 1px inner outline + slate-50 wash                          ▲ 2px brand-600 outline,
    no layout shift                                              +2% fill lightness

Selecting a task whose bar is scrolled off-screen horizontally — the one case that gets a leader line:

│ 17 ▓ Cargo Load  05-02  05-18   ▪ │◄╌╌╌╌╌╌╌╌╌╌╌╌╌ (thin, dotted, slate-400, NO arrowhead
  ▲ selection band                  │                — must not read as a dependency)
                                    │ [ ← 3 tasks left of view ]   ← or this chip instead

5.10 Keyboard model

Everything that exists today keeps working, unchanged, in both modes. That is the parity guarantee, and it is inherited rather than rebuilt because the table keeps one row per task.

Group	Bindings	Shared rows
File / edit / view	{mod}+Z/Y/S/O/E/C/X/V, Delete, T, F, ?, {mod}+\	unchanged — all selection- or document-scoped
Structure	{mod}++, {mod}+-, Alt+Shift+←/→, {mod}+G, {mod}+Shift+G	unchanged
Cell navigation	useCellNavigation over rows × EDITABLE_FIELDS (task.types.ts:54-63)	unchanged — the table is still a grid of rows
Row reorder	dnd-kit KeyboardSensor (TaskTable.tsx:112-115)	unchanged — reorder is an outline operation and the outline is in the table

New in Stage 3: {mod}+Shift+L = reveal (scroll the counterpart into view, both directions). One binding, and it works in both modes.

Rejected: C's 4-axis canvas navigation (Part 1 §4.7). Deferred to its own issue, independent of #88: nudge mode (M/R + arrows, Shift = ×7, Enter commits one UPDATE_TASK, Esc cancels) and "Link to…" + L for keyboard dependency creation — the latter being the one genuine WCAG failure in the product today.

5.11 Help content

Per the CLAUDE.md rule, one topic per user-facing feature. Three topics across the three stages:

{
  id: "view-collapse-all",       // Stage 0 — text in section 2 above
  ...
},
{
  id: "view-rollup",             // Stage 2
  title: "Roll up collapsed tasks",
  description:
    "When a summary is collapsed, its tasks still appear as small marks on the summary's " +
    "own bar, so nothing disappears from the picture. Click a mark to expand the summary " +
    "and jump to that task.",
  uiPath: "View > Layout",
},
{
  id: "view-shared-rows",        // Stage 3
  title: "Shared rows",
  description:
    "Shared rows lets tasks that don't overlap in time sit on the same row, so a long " +
    "project takes fewer rows. Every task keeps its own row in the task table, so you " +
    "edit exactly as before. Row height is set separately under Format > Display > Density. " +
    "Shared rows works best when you're zoomed in enough to read the bar labels. " +
    "Switching layout is a view change and is not undoable.",
  shortcuts: ["{mod}+Shift+L"],
  uiPath: "View > Layout",
}

Also update WelcomeTour.tsx:52 and helpContent.ts gs-create-task / gs-move-tasks? No — and that is a point in favour of this design. Under B's panel "Click the empty placeholder row at the bottom of the task table" stays literally true in both modes. Under the rejected Lane Ledger both would have needed rewriting.

---

6. The parity matrix — merged and corrected

C's 55-row matrix, re-adjudicated against B's panel (the table keeps one row per task in both modes). Legend: [=] works unchanged · **[]** works, needs an affordance or label change · [!] new code · [X] breaks, must be rewritten.

Rows that were [X] or [!] under the Lane Ledger and become [=] under B's panel are marked ↑ — there are 14 of them, and they are the concrete measure of what §4.1's ruling bought.

Create

Operation	Today	Shared rows
Type a name in the placeholder row	NewTaskPlaceholderRow + usePlaceholderNameEdit	[=] Same row, same place, same code	↑
Create from Ribbon / Alt+N	useNewTaskCreation.createTask	[=] Identical
Insert task above / below	insertTaskAbove/Below, computeInsertionDates, fractional order + normalizeTaskOrder	[=] Unchanged — "above/below" is still literally true, because the table still has rows	↑
Insert n tasks ({mod}++)	insertMultipleTasksAbove	[=] Unchanged. New bars may scatter across lanes → select them all and reveal the first
Hover InsertRowButton / InsertLine	on RowNumberCell	[=] Unchanged — it lives in the table	↑
Working-days snapping on create	snapForwardToWorkingDay	[=] Unchanged
Which lane a new task lands in	n/a	[!] Derived. Toast + reveal if it lands off-screen. No lane pinning
Create by drawing a bar / double-click empty space	does not exist	[deferred] Not in scope. It conflicts with marquee (Bryntum makes drag-select and drag-create mutually exclusive) and the table already has a create path

Read and select

Operation	Today	Shared rows
Click a bar / row to select	onTaskClick / useRowSelectionHandler	[=] ID-based, order-agnostic
{mod}+click toggle, Shift+click range, Select all	toggleTaskSelection, selectTaskRange (outline range, selectionActions.ts:31-51), selectAllTasks	[=] All unchanged. Shift+click stays outline range — it is a table gesture and the table is still an outline	↑
Marquee / rubber band	useMarqueeSelection → findIntersectingTaskIds over TaskGeometry[]	[=] Zero change. Already geometry-based; becomes a time-range selection for free. (Caveat: ChartCanvas.tsx:319-321 skips date-less tasks — already un-marquee-able today)
Row selection rendering (table)	RowOverlays.tsx:37-38, useTaskRowData.ts:68-69	[=] Unchanged	↑
Bar selection rendering (chart)	inline SelectionRows, ChartCanvas.tsx:154-205, full-width band + prev/next border merge at :166-169	[X] Rewrite. Bar-hugging 2px brand-600 ring, −3px inset, 4px end caps. Delete the merge logic — adjacency in a lane is chronological, not selectional
Find a selected task that is off-screen	row is visible in the table	[!] Reveal ({mod}+Shift+L) + one leader line + a "3 tasks left of view" chip
Hover feedback	hoveredTaskId gates ConnectionHandles	[~] Plus bidirectional cross-highlight via data-task-id + CSS selector (never an isHovered prop) and a 400ms hover card when the label does not fit
Read hierarchy	indentation in the table	[=] Unchanged — read it in the table, exactly as today	↑
Read sequence / row number	globalRowNumber in RowNumberCell	[=] In the table. Optional outline badge at the bar's left end, suppressed on narrow bars	↑

Update

Operation	Today	Shared rows
Edit name	name cell in the row	[=] Unchanged. This is the issue's headline problem, and it is dissolved rather than answered — in shared rows there is still a task table with a row per task	↑
Edit start / end / duration / progress / colour / type	TaskDataCells + CellEditors/ per row	[=] Unchanged, all N rows legible simultaneously	↑
Cell navigation ←/→ and ↑/↓	navigateCell over visibleFields / flattened index ±1	[=] Unchanged	↑
Cell copy / cut / paste	COPY_CELL / CUT_CELL / PASTE_CELL	[=] Unchanged
Drag bar to move	useTaskBarInteraction, deltaX → deltaDays, y never read	[~] Already packing-safe. New hard rule: freeze during the gesture, cold re-pack on commit, animate (§4.4 Part 1)
Multi-drag	MULTI_DRAG_TASKS	[~] Same freeze rule, one re-pack per committed command. Prototype this specifically — it is the gesture most likely to feel broken
Resize bar edges	detectInteractionZone, EDGE_THRESHOLD = 8 (taskBarDragHelpers.ts:27)	[!] effectiveEdge = min(8, floor(width/3)); below 16px the centre zone is already empty today. (Correction to C: this is a horizontal threshold on bar width — packing changes only vertical placement, so #88 is not its cause. It becomes common because packing removes the vertical excuse for zooming out.)
Drag progress	useProgressDrag, PROGRESS_HANDLE.minBarWidth = 30	[=] Geometry-relative; the 30px gate is already correct
Draw a dependency	useDependencyDrag + ConnectionHandles (offset 10px, hit radius 12px)	[~] Keep the hover/focus gate; flip handles inside the bar when the neighbour gap < 20px
Dependency arrow routing	DependencyArrow from row geometry	[!] New work. Gutter + packIntervals channels + focus dimming (§5.6)
Keyboard move / resize; keyboard dependency creation	do not exist	[deferred to its own issue] Nudge mode + "Link to…" + L. The dependency one is a genuine WCAG failure today, in both modes

Delete, clipboard, duplicate

Operation	Today	Shared rows
Delete	Delete on selectedTaskIds	[~] Unchanged. Aftermath is the risk: a re-pack pulls unrelated bars up → 120ms animation + live-region announcement of the document change ("2 tasks deleted"), never the shape change
Copy / cut	executeCopyOrCut, system-clipboard sync	[=] Unchanged
Paste (outline)	prepareRowPaste.resolveInsertContext	[~] Unchanged semantics + mandatory post-paste select-and-reveal, or a paste can be invisible
Cross-tab paste	pasteExternalRows	[=] Unchanged — lane is never serialised
Paste at end of list	usePlaceholderContextMenu, PLACEHOLDER_TASK_ID	[=] Unchanged	↑
Paste at a date ({mod}+Shift+V)	—	[deferred] Nice, not required by parity
Duplicate ({mod}+D)	copy + paste	[!] Worth shipping in both modes; in shared rows the clone necessarily packs into the next free lane, rendering directly under the original

Structure

Operation	Today	Shared rows
Indent / outdent, group / ungroup	indentOutdentActions, groupingActions	[=] Store unchanged. Result is visually invisible in the timeline — read it in the table. (Note: both run recalculateSummaryAncestors, which rewrites ancestor dates; under scope: "global" that can move a summary bar to a different lane. Deterministic, so undo-safe, but a visible motion nobody has drawn.)	↑
Summary tasks	one row, bracket bar	[!] The biggest packing hazard — a summary overlaps every child by construction (C's best algorithmic warning). Resolved by packScope: perSummary gives each summary its own row; summaryRail puts summaries in leading rows and packs all leaves globally
Collapse / expand a summary	toggleTaskCollapsed	[~] Yes, it re-packs — collapsed children leave the packing input. Collapse becomes the primary tool for controlling chart height, a role it never had before. Combined with Stage 2's rollup it is lossless
Expand all / collapse all	expandAll / collapseAll	[=] Wired in Stage 0. Dramatic re-pack; announce the document change
Hide rows / unhide by range	hideTasks, hiddenTaskIds, unhideRange over globalRowNumber gaps	[=] Unchanged — hidden tasks leave the packing input and outline row numbers still exist	↑
HiddenRowIndicator per-gap affordance	in the gap between two rows	[=] Unchanged — it lives in the table	↑
Reorder rows by drag (pointer and keyboard)	REORDER_TASKS, dnd-kit PointerSensor + KeyboardSensor	[=] Unchanged — reorder is an outline operation, performed in the table	↑
Explode / collapse a lane	—	[rejected] Part 1 §4.1

Menus, history, plumbing

Operation	Today	Shared rows
Bar context menu	useTimelineBarContextMenu → useFullTaskContextMenuItems	[=] Keyed on taskId from the bar's own event
Timeline empty-area menu	useTimelineAreaContextMenu:84-88, Math.floor(svgY/rowHeight) → tasks[rowIndex]	[X] Rewrite as resolver.taskAtPoint(x, y). Correct today; silently wrong under packing. Add "New task here (17 Mar)"
Table row / placeholder / column-header menus	useTaskTableRowContextMenu, usePlaceholderContextMenu, useTableHeaderContextMenu	[=] All unchanged	↑
Menu item labels	"Insert Task Above/Below", "Hide Row", "Unhide N Rows"	[=] Unchanged. No mode-dependent vocabulary — the table still has rows, so the words are still true	↑
Undo / redo	historySlice, Command Pattern	[=] Unchanged. Packing is derived and is never a command. Requires pack(doc) === pack(applyThenUndo(doc)) as a unit test
Auto-scheduling / cascade	src/utils/graph/*	[=] Verified index-free — every index there is a Map key or topological order. Add a test asserting cascade output is identical in both modes
Mode persistence	—	[!] UserPreferences, three files (§5.8) — not ViewSettings, no migration
Export	prepareExportTasks is the single source of truth	[!] Same pure pack() on both paths; pdfLayout.ts:410 is the silent one (§5.7)
Help content	helpContent.ts	[!] Three topics (§5.11)
Onboarding copy	WelcomeTour.tsx:52, gs-create-task	[=] Stays literally true in both modes	↑
Table ARIA	role="grid" (TaskTable.tsx:146)	[~] → role="treegrid" + aria-rowcount. Pre-existing bugs; spin off as separate PRs
Timeline ARIA	no role, no label, no tabindex on TaskBar	[!] <g role="group"> + per-bar role="graphics-symbol" + aria-label. Lanes exposed as nothing (Part 1 §4.7)
Visual regression	9 baselines	[!] +3 before Stage 1, +3 during Stage 3. Docker only. Transitions disabled

Score: under B's panel, 14 operations that the Lane Ledger would have broken or rewritten are simply unchanged, and there are three [X] items in the entire matrix — the chart-side selection band, the timeline-area context menu, and arrow routing. That is what "parity by construction" means in practice, and it is the argument for §4.1 restated as an inventory.

---

Part 3 follows: test plan, phased rollout with a verifiable gate per phase, and open questions with the method to resolve each.

[kitikonti]

FINAL CONCEPT — Issue #88 · Part 3 of 3

Test plan, phased rollout with a verifiable gate per phase, and open questions. (Part 1 = verdict, decision gate, rulings, rejected-and-why. Part 2 = implementation spec + parity matrix.)

---

1. Test plan

Martin's stated preference — E2E over unit tests for user-facing behaviour — maps cleanly here. The packing core is not user-facing behaviour; it is a pure function, so it gets heavy unit coverage. Everything a user can see or do goes to Playwright.

1.1 Unit — the pure core, target 100%, not 80%

tests/unit/utils/layout/packRows.test.ts

#	Invariant	Note
I1	No overlap. No two placements in the same lane have overlapping [start, end] day spans, after adding minGapDays.	property test
I2	Bounded excess. laneCount <= ceil(1.5 * omega), where omega = max simultaneous overlap depth computed by a sweep.	See below — this is the one every plan gets wrong.
I3	Identity. mode === "list" ⇒ lane === listIndex for every task, and laneCount === flattened.length.	the whole Stage 1 gate in one assertion
I4	Totality. Every input task appears exactly once across all lanes.	property test
I5	Determinism. Same input ⇒ byte-identical output, including slot and lanes[] ordering.	VRT depends on this
I6	Layout stability. A change that alters no task's startDate, endDate, order, parent, type or open yields an identical layout — including revision.	this is the true invariant that replaces A's falsified prefix-stability claim
I7	Slot monotonicity. Within a lane, slot is monotonic in start date, ties broken by (order, id).
I8	Purity under history. pack(doc) === pack(applyThenUndo(doc)) for every command type in historySlice.	C's test, and it catches both the missing tie-break and any accidental previous dependence
I9	No previous parameter exists. A type-level assertion plus a lint rule.	the mechanism rejected in Part 1 §4.4 must stay rejected

I2 must be stated as a bound, not an equality — and whoever writes the tests must be told this explicitly. Concept D specified laneCount === omega. That is the property of start-order first-fit, which this design deliberately does not use. R1 measured document-order first-fit at 2-5% excess lanes on average, worst case 1.5x in 1,200 trials. If you take A's algorithm and D's test suite, I2 fails on day one. Bound it, do not assert equality.

Property-test generator: a ~30-line seeded LCG in tests/unit/helpers/randomTasks.ts. The repo has no fast-check dependency and only 10 lean runtime deps. A seeded generator is deterministic, reproducible in CI, needs zero new dependencies, and prints the seed on failure. fast-check would shrink better and is dev-only — Martin's call, but do not block on it.

Edge cases, all of which have bitten someone in the analysis above:

• Milestones — zero-width [d, d] must still consume a slot, or two milestones on the same day stack invisibly.
• toDayNumber across a DST boundary. Assert toDayNumber("2025-03-30") - toDayNumber("2025-03-29") === 1 under a TZ=Europe/Berlin test. Epoch division (Date.parse(s)/86400000) is off by one here in half the world; differenceInCalendarDays(parseISO(s), EPOCH) is not.
• Duplicate order values within a parent (reachable via paste and import) — must resolve by id, deterministically.
• Zero tasks · one task · all tasks hidden · all tasks date-less.
• Identical start and end across many tasks.
• minGapDays = 0 / 1 / 365. Assert that 1 is not the default — R1 measured gapDays = 1 taking the reference file from 15 rows to 22, destroying most of the compression.
• 10,000-task perf smoke asserting < 20 ms with the binary-search fits().

Also unit:

• createRowResolver — laneOf / yOf / taskAtPoint, including taskAtPoint returning the correct task when a lane holds several, which is the whole reason it is on the interface.
• packIntervals on arrow x-spans — same I1/I2/I4 invariants, free, because it is the same function.
• calculateLayoutDimensions in list mode is byte-identical to today for a matrix of (taskCount, rowHeight, viewportHeight). This is the scroll-model ruling (Part 2 §5.4) turned into a proof rather than a promise.
• Clamped translate arithmetic: laneCount < taskCount ⇒ translate(chart) saturates at maxScroll(chart) while translate(list) keeps going.
• Scheduling invariance — propagateDateChanges output identical in both modes on the same fixture. src/utils/graph/* is verified index-free, so this should pass trivially; the test exists to keep it that way.
• exportLayout / pdfLayout height math with laneCount < taskCount.
• userPreferencesSlice runtime validation: invalid rowLayoutMode → "list"; rowLayoutMinGapDays of NaN / -1 / 1e9 → clamped to 0-365; corrupt localStorage → defaults.

1.2 Integration (Vitest + RTL)

• ChartCanvas with a stub resolver renders bars at the expected y attributes — this decouples the render tests from the packer entirely.
• GridLines receives laneCount, not taskCount.
• DOM order is outline order while y is packed. Assert that the rendered <g> sequence matches flattenedTasks order regardless of lane assignment (WCAG 1.3.2 / 2.4.3). This is the invariant a future performance "optimisation" would silently break.
• TaskBar consumes the shared geometry and does not recompute from an index — assert by rendering with a resolver whose laneOf returns a value that differs from the array index, then checking the bar's y.

1.3 E2E (Playwright)

D's 13 flows, plus the 3 R1 identified that nobody listed, plus 2 of mine. tests/e2e/ has 40 spec files today; follow the existing conventions.

#	Flow	Why it exists
1	Toggle to Shared rows from the View ribbon → chart height shrinks, bar count unchanged	the basic promise
2	Create a task while in Shared rows → it appears, gets a lane, and is revealed	the author's problem #1, and the flow most likely to be quietly broken
3	Select a bar → the correct bar highlights and the correct table row highlights	the binding model
4	Marquee across a lane → selects the bars actually inside the rectangle
5	Right-click the second bar in a shared lane → the menu targets that bar	direct regression test for useTimelineAreaContextMenu:84-88; the failure is silent, not visible
6	Drag a bar past another in the same lane → on drop, lanes reflow, the bar stays selected and visible	the mouseup snap
7	Multi-drag N selected bars → one re-pack, all N still selected, first one scrolled into view	R1's "the case I would expect to actually feel broken"
8	Undo after a Shared-rows drag → dates and lanes restored
9	An FS chain of 5+ abutting tasks packed into one lane, at all three densities	R1's F2 — the case A wrongly believed was already handled
10	An FS dependency between two same-lane tasks with a third task between them in x	the arrow must not pass through the intervening bar
11	Type a name in the table → no bar moves	invariant I6, made visible
12	Save → reload → mode persists; open a pre-feature fixture → opens in One task per row
13	Export PNG / SVG / PDF in Shared rows → dimensions match packed height	patterns exist in export-png.spec.ts / export-svg.spec.ts / export-pdf.spec.ts
14	Multi-tab: mode is shared across tabs (device preference); zoom is not	documents the §5.8 consequence
15	Keyboard: cell navigation and every existing shortcut still work in Shared rows	the parity constraint, tested
16	Collapse All → 7 rows; rollup glyphs present and clickable; click one → expands + reveals	Stage 0 + Stage 2
17	Scroll to the bottom of a 200-task list with a 6-lane chart → the chart pins, does not disappear upward	the clamped translate

Touch, which every concept missed. The app blocks mobile at <=768px and coarse pointer (useDeviceDetection.ts:25-30) — but with a "Continue anyway" escape hatch, so landscape iPad Pro and touch laptops run the full app today. ConnectionHandles are hover-gated and the hover card is a hover affordance. Rule: every hover-only affordance needs a tap equivalent (long-press → the same card), and hover must never be the primary read channel for anything. Add one Playwright touch-emulation spec.

1.4 VRT — Docker only, and the gate proves less than it sounds

There are 9 committed baselines in tests/e2e/visual-regression.spec.ts-snapshots/: empty-app-shell, file-menu-open, full-app-with-data, ribbon-format-tab, ribbon-help-tab, ribbon-home-tab, ribbon-view-tab, status-bar, task-table-populated.

Five of nine are ribbon or menu chrome and cannot regress from a row-geometry change at all. The empty-state test explicitly masks the timeline region (visual-regression.spec.ts:89-90). That leaves two — and DEFAULT_SAMPLE_TASKS (tests/e2e/fixtures/sample-data.ts:21+) is 7 tasks with dependencies = [] (:160), at one fixed viewport, at the default density only, with maxDiffPixelRatio: 0.01 (:36 — about 9,200 pixels of tolerance at 1280×720).

So the zero-baseline-churn gate would not catch: any dependency-arrow routing regression (there are zero arrows in the fixture), any regression at compact or comfortable density, milestone rendering, selection-band rendering (nothing is selected), hiddenTaskIds gap behaviour, scroll-position restore, or any export output at all — PNG/PDF/SVG are not in VRT.

Actions:

1. Add 3-4 baselines BEFORE Stage 1, not after, so the gate has something to bite on: timeline-with-dependencies, compact-density, comfortable-density, multi-selection. Generated in Docker via npm run test:vrt:update, verified deterministic by re-running npm run test:vrt, then committed.
2. Keep the zero-churn gate — it is free — but the headline Stage 1 gate is "all 5,239 unit tests and all ~190 E2E pass untouched", of which 746 unit tests live in the 28 row-geometry files. That is a far stronger and far cheaper statement than nine screenshots.
3. Stage 2 adds rollup-glyphs. Stage 3 adds shared-rows-chart, shared-rows-dense-overlap (many bars per lane plus arrows — the one that will actually catch routing regressions), and updates ribbon-view-tab (the View tab gains controls).
4. Disable CSS transitions under VRT or the animated re-pack makes baselines non-deterministic. This is why I5 and I6 are load-bearing rather than nice-to-have: a non-deterministic packer produces a flaky baseline, and someone eventually deletes it.

1.5 Coverage

CLAUDE.md documents an 80% floor and 100% for critical modules. Per R4, issue #84 says the thresholds are in the wrong config key and are silently inert — npm run test:unit reports 33.09% and exits 0. Fix #84 before Stage 1, then hold src/utils/layout/packRows.ts to 100%. It is a pure function with no I/O; there is no excuse for less.

---

2. Rollout, with the gate that lets you stop

flowchart LR
  A["#84 · fix the<br/>coverage gate"] --> B["+3 VRT baselines<br/>(Docker)"]
  B --> C["<b>Stage 0</b><br/>Collapse All<br/><i>gate: 29→7 rows</i>"]
  C --> D{"<b>MEASURE</b><br/>your files<br/>+ 2 weeks of use"}
  D -->|ratio < 1.5x<br/>and itch gone| E["<b>CLOSE #88</b>"]
  D -->|otherwise| F["<b>Stage 1</b> · refactor:<br/>RowResolver<br/><i>gate: 5,239 + 190 + 0 VRT</i>"]
  F --> G["<b>Stage 2</b> · feat:<br/>Rollup on collapse<br/><i>gate: lossless 4.14x</i>"]
  G --> H{"still itches?<br/>charts flat?"}
  H -->|no| E
  H -->|yes| I["<b>Stage 3.0</b><br/>scroll prototype<br/><i>STOP-WORK GATE</i>"]
  I --> J["3.1 packer + toggle<br/>3.2 interaction parity<br/>3.3 arrows<br/>3.4 export + a11y + docs"]
  style E fill:#166534,color:#fff
  style D fill:#854d0e,color:#fff
  style H fill:#854d0e,color:#fff
  style I fill:#7f1d1d,color:#fff

Loading

Phase	Deliverable	Gate — verifiable, not a feeling
Pre-0a	Fix #84 (coverage thresholds)	npm run test:unit fails below 80%
Pre-0b	+3 VRT baselines: dependencies, compact, comfortable, multi-selection	npm run test:vrt passes twice in a row in Docker
Pre-0c (optional, own PRs)	role="treegrid" + aria-rowcount; ViewSettings unknown-field preservation	existing tests green; new round-trip test proves an unknown field survives save
0	Collapse All / Expand All + shortcuts + help topic	E2E 16 (first half): collapse → 7 visible rows; expand → 29; undo restores
GATE	Run measure-row-packing.js; use Stage 0 for two weeks	The three numbers per file written into this issue, plus a one-line answer to "does it still itch". Criteria are in Part 1 §2 and were set before the data — do not move them afterwards
1	packRows + RowResolver, mode: "list" only; all three geometry sites, layoutCalculations, all four export renderers, taskAtPoint	npm run ci:local green with 5,239 unit tests unedited · ~190 E2E unedited · npm run test:vrt zero baseline updates · refactor:, no version bump
2	Rollup glyphs + reveal ({mod}+Shift+L) + export parity + help topic	Collapse everything: every leaf still visible and clickable; row count == Stage 0's; PNG/PDF/SVG show identical glyphs; +1 VRT baseline
3.0	Scroll prototype only. ~10 lines: clamped dual translate, 200 tasks, 6 lanes	STOP-WORK GATE. Does a long list scrolling against a pinned short chart feel right? If no, Stage 3 does not ship, and the answer is not to redesign the scroll model
3.1	packRows packed mode + packKey + View-tab control with the live outcome string, behind a localStorage flag	Live string is accurate on the mars fixture (29 tasks fit in 15 rows); toggling changes only y; bar count unchanged; unit I1-I9 green
3.2	Interaction parity: SelectionRows rewrite, taskAtPoint menu, gesture freeze + animated reflow, reveal, cross-highlight	E2E 3-8, 11, 15, 17 green; no existing E2E spec edited
3.3	Arrows: focus-mode dimming first (own commit), then gutter + packIntervals channels + chevron degradation	E2E 9, 10 green at all three densities; packIntervals I1/I2/I4 green on x-spans
3.4	Export options, UserPreferences persistence, ARIA (role="group" + per-bar graphics-symbol), help topic, VRT baselines, manual PNG/PDF/SVG verification	E2E 12-14, 16; golden-file assertion screen lane count == export lane count; CLAUDE.md manual export check
3.5	Remove the flag	—

Feature flag. There is no feature-flag infrastructure in this repo and you should not build one. The lightest thing that works:

// src/config/appConfig.ts
export const ROW_LAYOUT_FLAG_KEY = "ownchart:ff:rowLayout";
export const isRowLayoutEnabled = (): boolean =>
  import.meta.env.DEV || localStorage.getItem(ROW_LAYOUT_FLAG_KEY) === "1";

Gate only the ribbon control's visibility. packRows always exists, the preference is always read, and the export path never branches on the flag — branching there would reintroduce exactly the silent screen-vs-export divergence this whole design exists to prevent.

Commit hygiene, per CLAUDE.md: Stage 1 is refactor: (no version bump). Stages 0, 2 and 3.1-3.4 are feat: (minor bumps). The taskAtPoint context-menu correction and the treegrid / aria-rowcount fixes are fix:. One logical change per commit; npm run ci:local green before every push.

---

3. Open questions, and the method that resolves each

Ordered by how much they can change the plan.

#	Question	Why it is open	Method	Blocks
1	Are your real charts hierarchical or flat?	Every number in this analysis is n=1 on one hand-authored example file. If your charts are flat, the recommendation inverts and Stage 3 becomes the right call.	Run measure-row-packing.js (Part 1 §2) over every .ownchart you have. 20 minutes. Paste the output into this issue.	Everything after Stage 0
2	Does Collapse All close the itch?	No script can answer it. Compression is a means; "I can see my project" is the end.	Use the Stage 0 button for two weeks. Write one honest line in this issue.	Stages 1-3
3	Does a long list scrolling against a short pinned chart feel right?	The arithmetic is settled (Part 2 §5.4) and provably identity in list mode. Whether it feels right is unknown — B flagged it as its own uncertainty and R2 agreed nobody has looked.	~10-line prototype on calculateLayoutDimensions + the translate handler. 200 tasks, 6 lanes. Look at it.	Stage 3, as a stop-work gate
4	Does multi-drag survive?	MULTI_DRAG_TASKS moves N bars at once; on commit, N lanes change plus auto-schedule cascades. R1 named it "the one I would expect to actually feel broken".	Prototype the gesture specifically in Stage 3.1, before 3.2 is designed.	Stage 3.2
5	Does arrow routing converge at all?	Airtable, in production, made Gantt layout and swimlane stacking mutually exclusive rather than solve it. OwnChart has four dependency types plus cascade propagation.	Timebox Stage 3.3 to 15 evenings. If channel routing has not converged, ship focus-mode dimming alone and re-open. Arrows do not get turned off (Part 1 §5).	Stage 3.3 scope
6	perSummary or summaryRail as the default?	Measured 15 vs 10 rows on the reference file. perSummary keeps the outline legible; summaryRail is what an overlapping-sibling WBS actually needs.	Ship both behind packScope with the live outcome string showing each. The user picks; the data decides the default in v2.	Stage 3.1
7	Shift+click in Shared rows: outline range, chronological range, or lane-scoped?	All three ship somewhere — OwnChart's table is outline, C proposed chronological, vis.js does lane-scoped via multiselectPerGroup.	Ruled for now: outline range, unchanged — it is a table gesture and the table is still an outline. If it feels wrong in practice, a two-variant Playwright click-through on a 40-task chart settles it.	nothing
8	Is the leader line worth building at all?	Griffin 2015 says leader lines and colour highlighting tie for adjacent panes; Steinberger 2011 says links beat plain highlighting when correspondence is ambiguous. The papers genuinely differ, and B cut the feature between its main comment and its addendum.	Ship reveal + cross-highlight first (Stage 2). Only add the line if the "where is my bar" problem is still felt. It is the first thing to cut under time pressure.	nothing
9	Should the outline row-number badge be on by default on bars?	It is a second always-on binding cue, but it consumes bar width that the name — the primary cue — also needs, and R4's measurement says width is already the binding constraint.	A/B on your own chart during Stage 3.1. Cheap to flip.	nothing
10	Does role="graphics-symbol" on 500 bars degrade a screen reader?	It is the codebase's own precedent (DependencyArrow.tsx:116), but that is a handful of elements, not hundreds. vis-timeline documents zero accessibility support; FullCalendar's eventInteractive is off by default, so by default only events with a URL are keyboard-reachable. There is no good prior art.	Test with NVDA on a 200-task chart in Stage 3.4. If it is noisy, drop the per-bar labels and keep only the group summary — the table is the required route and remains unaffected either way.	Stage 3.4
11	Does the min-width clamp + visual-overlap tradeoff (Part 2 §5.5c) bother anyone?	Two date-disjoint bars can overlap on screen at MIN_ZOOM while legally sharing a lane. Precedent exists for pixel-gated degradation (PROGRESS_HANDLE.minBarWidth = 30).	Ship the documented choice. Revisit only if reported.	nothing
12	Should the file carry a mode hint?	Ruled: no, for now (Part 2 §5.8). Adding an optional ViewSettings.rowLayoutMode hint plus R2's dismissible switch bar is ~30 lines whenever someone actually shares a chart and wants the intent to travel.	Wait for a real report. Do not write a field you ignore.	nothing

Two things I could not resolve and will not pretend to:

• Whether Shared rows is legible at the zoom where it is most useful. R4's model — compression ≈ min(S / L̄, W / w_label) — says the reference project is capped at 8.6x by label width and measured 2.4x, with the ~3x gap attributable to phase clumping. Treat any theoretical compression estimate as roughly 3x optimistic. Whether an unlabelled packed chart is an overview or a heat map is a judgement only you can make, and you can make it in five minutes once Stage 3.1 exists.
• Whether the whole thing is worth a quarter of your year. Compact Mode #88 is the only issue referencing this and the requester is the maintainer — which is entirely legitimate, it is your product, but it is not a demand signal that justifies displacing all three remaining V1.1 items (Named snapshots, Custom fields UI, Multi-project management) plus four infrastructure issues. Note also that Make tasktable optional #6 "Make task table optional" is nearly done — isTaskTableCollapsed already exists in chartSlice — and shipping it would cost days and tell you a great deal about whether a chart without a 1:1 table is even pleasant to use. That is a cheaper experiment than Stage 3 and it answers an adjacent question.

---

4. What this comment asks you to do next

Three things, in order, none of which commits you to anything:

1. Fix Coverage thresholds are silently not enforced, and coverage scope includes stale worktrees #84. The coverage gate reports 33.09% and exits 0 against a documented 80% floor. Do not build a quarter-sized feature on top of that.
2. Ship the Collapse All / Expand All button. The code exists, is tested, and is wired to nothing. One evening. Measured 4.14x on the reference project — better than the entire proposed program's 1.93x.
3. Run the script in Part 1 §2 over your own files and paste the output here. Twenty minutes. It is the only thing standing between this issue and either a confident build or a confident close, and the criteria for reading it are already written down above so they cannot be rationalised after the fact.

If the numbers say your charts are flat, everything in Part 2 is ready to build and I would start at Stage 1. If they say what mars-colony says, you will have solved #88 for about 4% of the cost, and the RowResolver refactor is still worth doing on its own merits.

---

Phase 3 synthesis