## What does this PR do?
Improves the visual presentation of overlapping calendar events in the weekly view with two key enhancements:
- **Dynamic startHour per scenario**: Each playground scenario now displays the calendar starting at an appropriate hour based
on its earliest event time, rather than always starting at 6am
- **Full width for non-overlapping events**: Single events and non-overlapping events now display at 100% width (previously
80%) for maximum visibility
## Key Changes
### Overlapping Event Layout Algorithm
Replaces the previous uniform-width, fixed-offset layout with an intelligent spread algorithm:
**Previous behavior:**
- All overlapping events: 80% width with 8% offset steps
- Events clustered on the left side
**New behavior:**
- **2 overlapping events**: 80% and 50% widths
- **3 overlapping events**: 55%, ~42%, and 33% widths
- **4+ overlapping events**: Progressive narrowing from 40% down to minimum 25%
- **Spread algorithm**: Events distribute across the full width with the last event aligned to the right edge
- **Right edge distribution**: `ri = Rmin + (Rmax - Rmin) × i/(n-1)` for even spacing
### Visual Improvements
- Single/non-overlapping events: **100% width** (was 80%)
- Overlapping events: **Variable widths** based on cascade position (leftmost events wider, rightmost narrower)
- Last overlapping event: **Aligned to right border** for maximum scatter
- Minimum width: **25%** maintained for readability
**Devin session:** https://app.devin.ai/sessions/168d2227f5304c49ae4d34d17da5b025
**Requested by:** eunjae@cal.com (@eunjae-lee)
## Visual Demo
https://github.com/user-attachments/assets/693546fa-448d-470a-b041-c08f4697c177
## Mandatory Tasks (DO NOT REMOVE)
- [x] I have self-reviewed the code
- [x] I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. **N/A** - playground-only changes
- [x] I confirm automated tests are in place that prove my fix is effective or that my feature works.
## How should this be tested?
1. Navigate to `/settings/admin/playground/weekly-calendar`
2. Verify each scenario:
- **Non-Overlapping Events**: Both events should be 100% width, no offset
- **Touching Events**: Both events should be 100% width, no offset
- **Two Overlapping Events**: First event 80% width, second 50% width aligned to right
- **Three Overlapping Events**: Progressive narrowing with spread across full width
- **Four Overlapping Events**: Four events spread across full width
3. Verify startHour values:
- Most scenarios should start at 9am (events start at 10am)
- Dense day scenario should start at 8am (events start at 9am)
- Mixed statuses scenario should start at 1pm (events start at 2pm)
4. Test with real calendar data to ensure overlapping events look visually distinct
**Environment variables:** Standard Cal.com development setup
**Test data:** Use playground scenarios or create overlapping events in your calendar
## Human Review Checklist
**⚠️ CRITICAL ITEMS:**
1. **Visual verification in playground** (MOST IMPORTANT):
- Open `/settings/admin/playground/weekly-calendar`
- Verify non-overlapping events are 100% width (not 80%)
- Verify overlapping events spread properly across full width
- Verify last overlapping event aligns to right edge
- Verify each scenario starts at appropriate hour
2. **Algorithm correctness**:
- Single events: 100% width (was 80%)
- Two overlapping: 80%, 50% widths with last aligned to right
- Three overlapping: 55%, ~42%, 33% widths spread across full width
- Right-edge distribution: `ri = Rmin + (Rmax - Rmin) * i/(n-1)`
3. **Edge cases**:
- Test with 10+ overlapping events to ensure no overflow
- Verify minimum width (25%) is respected
- Verify backward compatibility: custom `baseWidthPercent`/`offsetStepPercent` should use legacy behavior
4. **Type safety**:
- `startHour` parameter now properly typed as `Hours` (union of 0-23)
- All scenarios use valid `Hours` values
**Known limitations:**
- Local visual testing was not completed due to environment issues
- Easing curve parameters (curveExponent: 1.3) were chosen based on examples but may need visual tuning
- No E2E tests for visual appearance (only unit tests for layout calculations)
## Checklist
- [x] I have read the [contributing guide](https://github.com/calcom/cal.com/blob/main/CONTRIBUTING.md)
- [x] My code follows the style guidelines of this project
- [x] I have commented my code, particularly in hard-to-understand areas
- [x] I have checked if my changes generate no new warnings