tessera-ctl/.planning/quick/260929-dmx-widget-raster-horizontal-feiner-48-spalt/260929-dmx-SUMMARY.md

quick_id, status, commits, plan_head_before, plan_head_after, completed, actuals

quick_id	status	commits	plan_head_before	plan_head_after	completed	actuals
260929-dmx	complete	3	acd3c7a05f	46ebb4e7ce	2026-09-29	tasks commits 3 3

Quick 260929-dmx: Widget-Raster horizontal 48 Spalten, Kalender schmaler

Grid version 3: horizontal resolution doubled (COLS lg 48 / md 40 / sm 24 / xs 16 / xxs 4), row height 20 and margin 12 unchanged. Stored layouts are migrated stepwise, so every existing widget keeps its on-screen size and position. Calendar minimum is now 8 of 48 columns (about 250 px at lg).

Commits

• 97744b5 feat: grid v3 with stepwise migration, COLS, fallbacks
• 9c9e142 feat: widget constraints in 48-column units, calendar minW 8
• 46ebb4e docs(changelog): two bullets under "Unveröffentlicht / Geändert"

Every place where width units changed

1. apps/web/src/lib/grid-layout-migration.ts: GRID_VERSION 2 to 3. Migration is now a step table: v1 to v2 scales x, y, w, h, minW, minH, maxW, maxH by 2; v2 to v3 scales only x, w, minW, maxW by 2. A v1 layout gets both steps, a v2 layout only the second, a v3 layout nothing. Marker semantics unchanged (marker only in the persisted JSON, stripped on load, re-added by withGridVersion). Header comment updated.
2. apps/web/src/components/dashboard/dashboard-grid.tsx:
   • COLS is { lg: 48, md: 40, sm: 24, xs: 16, xxs: 4 }.
   • Fallback for a widget without a layout entry: defaultW ?? 8 and minW ?? 8 (was 4/4). The ?? 4 fallbacks for height stay.
   • Comment block above BREAKPOINTS/COLS extended.
3. apps/web/src/components/dashboard/widget-registry.tsx (WIDGET_CONSTRAINTS, minW/defaultW doubled, heights untouched):
   • clock 4/8
   • search 12/24
   • calendar minW 8, defaultW 16. Calendar is the only one that is not a plain doubling for minW: 8 instead of 12.
   • note 8/12
   • calculator 6/12
   • favorites 2/12
   • stopwatch 8/12
   • picture-frame 8/16
   • xframe 8/24
   • proxmox 6/16
   • Comments updated, German, including the calendar note (narrower on user request 29.09., 8 of 48 is about 250 px measured usable).
4. dashboard-store.ts needed no code change. addWidget reads defaultW from WIDGET_CONSTRAINTS, so new widgets are placed in the new units automatically. Load and save already route through migrateGridLayouts and withGridVersion.
5. centeringOffset needed no code change. It takes cols as a parameter and gets the new COLS[breakpoint].
6. breakpointFor needed no change. It depends only on BREAKPOINTS, not on the column count.

The existing override in applyConstraintMinima (quick-260916-dyv) already replaces the stored minW/minH from the constants in every breakpoint, so existing calendars pick up minW 8 with no code change there. This is verified by a new test.

Tests

• grid-layout-migration.test.ts: v1 to v3 (x/w/minW/maxW times 4, y/h/minH/maxH times 2), v2 to v3, v3 untouched, v1 result equals v2 result, idempotence for both paths with marker 3 written, future marker 4 untouched, string marker, foreign values.
• dashboard-store.test.ts: marker 3, new expected values, new-widget default of 8 wide.
• dashboard-grid.test.tsx: COLS pin, centeringOffset with 48 columns, data-grid fallbacks, minima overrides, new Test 9c (existing calendar with stored minW 12 gets minW 8 in every breakpoint, w 6 raised to 8, w 16 kept).
• widget-registry.test.tsx: constraints table.
• Verification: pnpm --filter web exec vitest run src/lib src/components/dashboard green (513). The full web suite is green (995). Type-check for @tessera/web is green. Biome shows 55 warnings, equal to the baseline. Note: the turbo filter name is @tessera/web, not web.

Rebuild

docker compose up -d --build web ran, and the web container is up. Browser check is left to the orchestrator (calendar at minimum, existing layout unchanged after migration, marker 3 persisted).

Found but deliberately left

• apps/api/src/dashboard/dashboard.service.spec.ts:834 stores __gridVersion: 2 as a passthrough fixture. The API only passes the JSON through, so the value is arbitrary, and I did not touch it.
• RESIZE_AXIS_FALLBACK and its tests use abstract grid numbers and are unit-independent, so nothing was changed. Its resize logic has no column dependency.
• Historical comments that mention "24 Spalten" (the quick-260922-vdk explanation in dashboard-grid.tsx, the quick-260916-bwo test description, the bwo header text) describe past states and were left. The vdk comment's numbers (24 columns, 50 px) describe the old bug, not the current state.
• Widget internals (calendar, favorites, calculator) use pixel-based or container-based layout, not grid units, so no change was needed.
• md/sm/xs/xxs columns are doubled proportionally with lg. Only lg was measured, and I did not check the smaller breakpoints in a browser.
• API/seed: no default layouts or seed data with width units exist in apps/api (empty defaults { lg: [], ... } only).
• A brand-new empty v2 layout is not re-saved with marker 3 on load (migrated stays false for empty layouts, existing behaviour). The marker gets written on the next save.

Deviations from Plan

None. The plan was executed as written. The SUMMARY, STATE, PLAN and ROADMAP files were not committed, as instructed.

Self-Check: PASSED

Commits 97744b5, 9c9e142, 46ebb4e exist. Changed files exist. Working tree contains only the untracked quick-task directory.

Browser-Pruefung (Orchestrator, 29.09., dunkel, lg 1888 px)

• Bestehende Anordnung nach Migration pixelgenau gleich (6 Widgets, left/top/width/height vor und nach identisch); DB: __gridVersion 3, lg-w verdoppelt.
• Kalender im Bearbeitungsmodus nach links gezogen: stoppt bei 252 px (vorher Minimum 383 px), Monatsraster, Kopf und Terminliste sauber lesbar.
• Schrittweite beim Ziehen 33 px (284/317/350), vorher 66 px.
• Kalender danach wieder auf 515 px gezogen, Testzustand zurueckgesetzt.
• Nicht im Browser geprueft: kleinere Breakpoints (md/sm/xs/xxs).