6 Commits

Include renames

Author	SHA1	Message	Date
nessarandClaude Opus 5.5	f128af68af	feat(planning): warn of an overrun only past the displayed range ... The expected wait sits near the middle of recent waits, so about half of all runs pass it. Between the expected wait and the top of the range shown before Calculate, the percentage now holds at 95% with no remaining-time line; "Taking longer than expected" appears and is announced only past that top. Refs #300 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-19 01:12:35 +02:00
nessarandClaude Opus 5.5	c2745ecbd6	feat(planning): follow the indicative wait in calculation progress ... The overlay percentage now rises linearly to 95% at the expected wait captured at Calculate, holds there, and shows 100% only when the planner completes. Beneath the status, one line names the current planning stage (with the rule name for rule stages) and another shows the approximate remaining time, or "Taking longer than expected" once the wait is exceeded, announced once through the live status. Cancel freezes the percentage and hides both lines. PlanningCalculationService reports the stage and submitted request instead of fixed per-stage percentages; PlanningDurationService owns the wait progress on a 250 ms tick. Closes #300 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-19 01:04:47 +02:00
nessarandClaude Opus 5.5	31cb4a499c	fix(planning): recalibrate the duration estimate to the faster engine ... Rendered waits after #302, in throttled headless Chromium, were well below the shown ranges: two years waited 1.9 s against 3-24 s, three years 4.5 s against 11-68 s, and the loaded year 4.0 s against 4-26 s. The prior keeps its structure with refitted, rounded constants, 400 + 250 x (D/365.25)^0.5 x (P/30)^1.5 x R, which stays within about 1.2 times of all six measured configurations. Five years with 30 days per year now shows 6-37 s instead of 44-265 s. Local refinement is unchanged. The 4x CPU throttle slows only the main thread, not the planning worker, so phones can still wait longer than these desktop samples. Part of #302. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-18 23:31:28 +02:00
nessarandClaude Opus 5.5	5cb0b93339	refactor(planning): give planning calculations one state owner ... PlanningCalculationService now builds the submitted request, owns the pending and accepted calculation state, and delivers explanations for the accepted calculation only. The duration estimator reads the same request. The calendar and leave-balance summary consume the accepted outcome instead of coordinating writable state on the input service. Refs #275 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-17 11:11:37 +02:00
nessar	d9d9befa12	refactor(planning): remove the original decision trace	2026-10-15 20:42:33 +02:00
nessar	bc8570d8ca	feat: add PlanningDurationService for estimating planning duration ... - Implemented PlanningDurationService to provide an indicative wait time before calculation based on user input and calendar settings. - Introduced duration estimation logic that considers horizon dates, balances, and rules without triggering a calculation. - Enhanced user input component to display estimated duration using the new service. - Updated translation files to include new duration estimate strings in multiple languages. - Added tests for PlanningDurationService to ensure accurate duration estimation and calibration. - Refactored leave planner service to remove hardcoded deadlines and improve worker responsiveness.	2026-10-05 17:06:17 +02:00