feat(planning): follow the indicative wait in calculation progress #304

Open

nessar wants to merge 3 commits from feature/calculation-progress into develop

pull from: feature/calculation-progress

merge into: nessar:develop

nessar:develop

nessar:feature/gitignore-claude-local

nessar:feature/obligation-solution-ranking

nessar:renovate/node-24.x

nessar:renovate/https-gitea.com-actions-checkout-7.x

nessar:feature/bun-migration

nessar:feature/planning-architecture

nessar:feature/incremental-exact-scoring

nessar:feature/benchmark-performance

nessar:feature/verify-trace-free-planning

nessar:feature/remove-decision-trace

nessar:feature/gitea-actions

nessar:feature/gitflow-ci

nessar:main

nessar:select-duration

nessar:dependabot/npm_and_yarn/typescript-6.0.3

nessar:dependabot/github_actions/docker/build-push-action-7

nessar:dependabot/github_actions/docker/login-action-4

nessar:dependabot/github_actions/docker/metadata-action-6

nessar:dependabot/github_actions/docker/setup-buildx-action-4

nessar:dependabot/github_actions/actions/upload-artifact-7

nessar:copilot/sub-pr-61-another-one

nessar:copilot/sub-pr-61-again

nessar:copilot/sub-pr-61

nessar:copilot/sub-pr-49

nessar:copilot/sub-pr-37

nessar:copilot/update-ci-cd-pipeline

nessar:copilot/refactor-duplicated-code

Conversation 1 Commits 3 Files Changed 15

+571 -51

nessar commented 2026-10-19 01:05:04 +02:00

Owner

Copy link

Copy source

Closes #300.

Summary

• The calculation overlay percentage follows the indicative wait instead of a fixed stage mapping: linear to 95% at the expected wait e (captured at Calculate, including local refinement, timed from the calibration's requestedAt), held at 95%, and 100% only when the planner reports completion.
• Beneath the status, a visible line names the current planning stage (Applying "<rule name>" for optimization/preference stages), and a second line shows About N s left when e ≥ 3 s, or Taking longer than expected once elapsed reaches e (announced once through the existing live status).
• Cancel freezes the percentage, hides both lines and keeps "Cancelling…"; Cancel stays available.
• PlanningCalculationService now exposes pending (stage + submitted request) and drops stageProgress; stage reports after Cancel are ignored so a late complete cannot show 100%. PlanningDurationService owns wait on a 250 ms tick.
• New text localized in EN, FR, ES and DE; docs/planning-duration.md gains a "During a calculation" section.

Decisions to confirm

• The overrun line appears at e, the centre of the pre-Calculate range (e.g. at 20 s for "10–60 s"), as the issue specifies; once calibrated, roughly half of runs will show it.
• Remaining time rounds up under 10 s (never "0 s"), then to the nearest 5 s, switching to minutes from 60 s.
• The stage and remaining lines sit below the "Calculating..." status.

Testing

• Controlled-clock service tests: linear climb and hold, 3 s threshold, rounding, frozen e across form/calibration changes, monotonic progress on repeated stages, no 100% after cancel, incomplete outcomes or errors.
• Component tests: every stage's text in all four languages, overrun announced once, freeze and hidden lines after Cancel.
• bun run typecheck, eslint and the full suite (768 tests) pass. Not checked in a real browser.

🤖 Generated with Claude Code

Closes #300. ## Summary - The calculation overlay percentage follows the **indicative wait** instead of a fixed stage mapping: linear to 95% at the expected wait `e` (captured at Calculate, including local refinement, timed from the calibration's `requestedAt`), held at 95%, and 100% only when the planner reports completion. - Beneath the status, a visible line names the current **planning stage** (`Applying "<rule name>"` for optimization/preference stages), and a second line shows `About N s left` when `e` ≥ 3 s, or `Taking longer than expected` once elapsed reaches `e` (announced once through the existing live status). - Cancel freezes the percentage, hides both lines and keeps "Cancelling…"; Cancel stays available. - `PlanningCalculationService` now exposes `pending` (stage + submitted request) and drops `stageProgress`; stage reports after Cancel are ignored so a late `complete` cannot show 100%. `PlanningDurationService` owns `wait` on a 250 ms tick. - New text localized in EN, FR, ES and DE; `docs/planning-duration.md` gains a "During a calculation" section. ## Decisions to confirm - The overrun line appears at `e`, the centre of the pre-Calculate range (e.g. at 20 s for "10–60 s"), as the issue specifies; once calibrated, roughly half of runs will show it. - Remaining time rounds up under 10 s (never "0 s"), then to the nearest 5 s, switching to minutes from 60 s. - The stage and remaining lines sit below the "Calculating..." status. ## Testing - Controlled-clock service tests: linear climb and hold, 3 s threshold, rounding, frozen `e` across form/calibration changes, monotonic progress on repeated stages, no 100% after cancel, incomplete outcomes or errors. - Component tests: every stage's text in all four languages, overrun announced once, freeze and hidden lines after Cancel. - `bun run typecheck`, eslint and the full suite (768 tests) pass. Not checked in a real browser. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

nessar added 2 commits 2026-10-19 01:05:04 +02:00

docs(context): define planning stage and indicative wait ... cfa4328ddb

Both terms are user-visible in the calculation overlay that #300
revises: the stage line names the planning stage, and the remaining
time comes from the indicative wait.

Refs #300.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

feat(planning): follow the indicative wait in calculation progress ... c2745ecbd6

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>

nessar added 1 commit 2026-10-19 01:12:36 +02:00

feat(planning): warn of an overrun only past the displayed range ... f128af68af

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>

nessar referenced this pull request 2026-10-19 01:12:43 +02:00

Improve calculation progress feedback #300

nessar commented 2026-10-19 01:12:43 +02:00

Author

Owner

Copy link

Copy source

Pushed f128af6. The three decisions listed under "Decisions to confirm" are now confirmed, with one change: "Taking longer than expected" appears only past the top of the range shown before Calculate, not at e. Between e and that top, the ring holds at 95% with no remaining-time line. Tests and docs/planning-duration.md are updated. Typecheck, lint and the full suite (771 tests) pass. The issue comment on #300 records the changed acceptance criterion.

Pushed f128af6. The three decisions listed under "Decisions to confirm" are now confirmed, with one change: "Taking longer than expected" appears only past the top of the range shown before Calculate, not at e. Between e and that top, the ring holds at 95% with no remaining-time line. Tests and docs/planning-duration.md are updated. Typecheck, lint and the full suite (771 tests) pass. The issue comment on #300 records the changed acceptance criterion.

Some required checks failed

Hide all checks

CI / policy (push) Successful in 8s

Details

CI / validate (push) Successful in 34s

Details

CI / build (push) Successful in 38s

Details

CI / policy (pull_request) Successful in 8s

Details

CI / benchmark (push) Successful in 1m7s

Details

CI / validate (pull_request) Successful in 36s

Details

CI / build (pull_request) Successful in 38s

Details

CI / test (push) Failing after 2m0s

Details

CI / benchmark (pull_request) Successful in 58s

Details

CI / test (pull_request) Failing after 1m50s

Details

CI / security (push) Successful in 56s

Details

CI / images (push) Skipped

Details

CI / required (push) Failing after 1s

Details

CI / security (pull_request) Successful in 1m41s

Details

CI / images (pull_request) Skipped

Details

CI / required (pull_request) Failing after 5s

Required

Details

Some required checks were not successful.

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin feature/calculation-progress:feature/calculation-progress

git checkout feature/calculation-progress

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

bug

dependencies

docker

documentation

duplicate

enhancement

github_actions

good first issue

help wanted

invalid

javascript

needs-info

needs-triage

question

ready-for-agent

wontfix

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

renovate (renovate) Bot nessar (nessar)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: nessar/vac-optimizer#304