Sidenav column geometry and resize handle have no automated coverage

[Astro-Han]

The Astryx sidenav column has no automated coverage for its geometry or for its resize handle, and one of its CSS comments points at a spec file that does not exist.

1. shell-layout.css cites a spec that was never added (or was removed)

apps/desktop/src/renderer/styles/shell-layout.css explains why .maka-shell-astryx .maka-sidenav-motion needs a definite height, and attributes the guarantee to a test:

/* The nav sizes itself against a definite height (`.maka-session-panel`
   is `height: 100%`); without one here the wrapper grows to the unclipped
   content and the footer leaves the window — the geometry
   e2e/sidebar-geometry.spec.ts locks. */
height: 100%;

apps/desktop/e2e/sidebar-geometry.spec.ts does not exist. Nothing in the repository matches that path. The comment asserts a lock that is not there, so the next person to touch this rule will trust a guarantee that cannot fail loudly.

2. The sidenav resize handle has zero e2e coverage

grep -rn "astryx-sidenav-resize-handle" apps/desktop/e2e returns nothing. The handle is referenced only from two stylesheets:

• apps/desktop/src/renderer/styles/shell-layout.css — top: var(--h-titlebar), so the handle starts below the window chrome strip instead of under it
• apps/desktop/src/renderer/styles/sidebar.css — transform: none !important, a workaround for an Astryx 0.2.0 hitAreaOffsetX bug that otherwise leaves the grab zone covering only the top half of the handle

Both rules exist because the handle was already silently broken once. Neither is verified by anything. A regression in either one produces a column that looks correct and simply cannot be dragged, and CI stays green.

Why this surfaced now

Reviewing #3779 (overflow: clip on .maka-sidenav-motion) raised a concrete question: does clipping the wrapper also clip the resize handle, which is a descendant of it, or the collapsed-state tooltips, which overflow the 48px rail by ~54px?

Neither the test suite nor the passing test check could answer that. It had to be measured by hand in Storybook against live computed styles:

• the handle root and its 16px hit area both span 244 → 260 inside a 0 → 260 wrapper, so nothing overflows and elementFromPoint returns the same hit area at every probe point before and after the clip
• the collapsed-state tooltip does render inside the wrapper and does overflow it, but it is popover="manual" and therefore in the top layer, which ancestor overflow cannot clip
• the only overflowing normal-flow descendants are six 1×1 screen-reader labels already carrying clip: rect(0, 0, 0, 0)

#3779 is correct and has been merged. The problem is that establishing that took a manual Storybook session, and the same question will come back on the next change to this column.

Suggested scope

• Add the missing geometry coverage, or correct the comment to describe what actually holds the invariant
• Add e2e coverage for a resize-handle drag that asserts the column width changes, so the two workaround rules above fail loudly when they stop applying

[Rangsh]

Hi @Astro-Han ,

Thanks for the extremely detailed breakdown and the suggested scope. This is very helpful.

I'd like to take on this issue and work on the automated coverage. My plan is:

Fix or remove the misleading CSS comment in shell-layout.css regarding the missing spec file.

Add the missing e2e coverage for the resize-handle drag to assert the column width changes.

Explore how to add proper coverage to ensure the overflow clipping works as expected (or address the root cause).

I'll start by familiarizing myself with the existing e2e setup and will open a PR once I have a working solution. Could you please assign this to me?

Thanks!