5 Commits

Include renames

Author	SHA1	Message	Date
nessarandClaude Opus 5.5	58be749949	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 10:45:28 +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	6811142299	feat(planning): make optimization rules composable ... Evaluate explicit, ordered optimization configurations through one shared planner model. Add six editable presets, durable one-time legacy migration, and consistent completed and cancelled plan provenance. Include functional regressions and the agreed trace-removal and benchmark follow-up specs. Performance acceptance remains in #78 under unchanged gates. Refs: #70, #71, #72, #73, #74, #75, #76, #77, #78	2026-10-10 16:07:34 +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