refactor(planning): remove the original decision trace

docs/adr/0004-separate-plan-explanation-from-calculation-trace.md

@@ -1,5 +1,7 @@
-# Separate Plan Explanations from Calculation Traces
+# Stable Plan Explanations Without Decision History
 
-The automatic planning deadline referenced below is superseded by [ADR 0006](0006-user-selected-horizons-and-cancellable-calculations.md), implemented by issue #59. Technical callers can still opt into an explicit planning-work budget; the user flow has no automatic cutoff.
+Issue #76 supersedes this ADR's original requirement to capture and deliver a complete calculation trace. The original decision trace, historical analysis, replay and candidate-history retention are removed end to end.
 
-VacOptimizer provides a stable plan explanation separately from the complete, untruncated calculation trace captured during the same planning run; on-demand counterfactual date analysis is identified as hypothetical and never presented as trace history. Explanation and tracing must not alter the planning outcome, so trace instrumentation is excluded from the planner deadline and the result may appear before the latest run's in-memory trace finishes loading; this narrows ADR 0003's ten-second hard limit to planning work rather than end-to-end trace delivery. This accepts additional transient memory and wall-clock time instead of inventing scalar day scores, truncating history, or reconstructing a trace by replay.
+The stable explanation describes the displayed plan, including valid incomplete incumbents: entitlement and rule provenance, contributions, the full ordered objective comparison and first decisive objective, time-off periods, remaining balances and concrete non-placement reasons. Invalid input and obligation conflicts retain their distinct explanations.
+
+Outcomes are delivered before explanation work. Explanation failures cannot discard an available outcome. Immutable calculation, valid-incumbent and final-state snapshots remain available for cancellation recovery and hypothetical analysis; they are independent of tracing. ADR 0006's opt-in technical planning-work budget excludes observer callbacks and post-outcome explanation work. The user flow has no automatic elapsed-time cutoff.

docs/adr/0004-stable-explanation-original-trace-counterfactual.md

@@ -1,11 +1,9 @@
-# Stable Explanation, Original Trace, and Counterfactuals
+# Stable Explanation and Displayed-Placement Counterfactuals
 
-The automatic planning deadline referenced below is superseded by [ADR 0006](0006-user-selected-horizons-and-cancellable-calculations.md), implemented by issue #59. Technical callers can still opt into an explicit planning-work budget; the user flow has no automatic cutoff.
+Issue #76 supersedes the original decision-trace and historical-counterfactual requirements of this ADR. Calculations no longer capture, retain or deliver decision history, and the UI has no trace explorer, replay, historical candidate statuses or balance-attempt lists.
 
-VacOptimizer exposes one client-side calculation context. Its immutable submitted snapshot and planning outcome are independent from three explanation concerns:
+VacOptimizer exposes one client-side calculation context with an immutable submitted configuration. Its outcome is independent from the stable explanation, which describes the final displayed plan and remains useful for complete and valid incumbent plans.
 
-- the stable plan explanation is derived from the final displayed plan and remains useful for complete or incumbent plans;
-- the calculation trace is captured while the producing run executes, grouped by phase and atomic decision, and may become ready after the outcome;
-- counterfactual date analysis is an explicitly hypothetical operation that removes only the selected final placement, or starts from a selected trace decision's exact pre-decision state, and never rewrites the plan or historical trace.
+Counterfactual date analysis tests a displayed placement over every date of the submitted half-open horizon. It uses the captured configuration and final-state snapshot, releases only that placement, preserves its entitlement, leave type and rule provenance, and fixes unrelated placements. Earned-entitlement chronology and all obligations still apply. The result is explicitly hypothetical and never mutates the displayed plan. Historical decisions are not selectable analysis baselines.
 
-The public planning outcome is delivered as soon as planning work finishes. Trace capture and delivery have separate readiness/failure state, remain local to the latest calculation, and cannot turn a valid outcome into an explanation error. Counterfactual work is cancellable or ignored when its calculation identity is stale. The existing deterministic constraint-first planner and its planning-work deadline remain unchanged.
+The public outcome is delivered as soon as planning work finishes. Explanation delivery failures cannot replace it. Counterfactual work is cancelled or ignored when its calculation identity is stale. Search breadth, allocation previews, user priorities, deterministic selection and ADR 0006's cancellation, liveness and technical-budget contracts remain unchanged. Workers finish after required outcome and explanation delivery without acknowledgement queues.

docs/adr/0006-user-selected-horizons-and-cancellable-calculations.md

@@ -1,17 +1,19 @@
 # User-Selected Horizons and Cancellable Calculations
 
-Accepted for [issue #12](https://gitea.nessar.fr/nessar/vac-optimizer/issues/12). Fixed, saved planning horizons are implemented by [issue #57](https://gitea.nessar.fr/nessar/vac-optimizer/issues/57); user cancellation with a retained valid plan and original trace is implemented by [issue #58](https://gitea.nessar.fr/nessar/vac-optimizer/issues/58); removal of the automatic calculation deadline and heartbeat-based worker liveness are implemented by [issue #59](https://gitea.nessar.fr/nessar/vac-optimizer/issues/59). The indicative duration estimate is implemented by [issue #60](https://gitea.nessar.fr/nessar/vac-optimizer/issues/60); its initial model, session-local refinement and calendar-rendering measurement are documented in [planning-duration.md](../planning-duration.md).
+Accepted for [issue #12](https://gitea.nessar.fr/nessar/vac-optimizer/issues/12). Fixed, saved planning horizons are implemented by [issue #57](https://gitea.nessar.fr/nessar/vac-optimizer/issues/57); user cancellation with a retained valid plan is implemented by [issue #58](https://gitea.nessar.fr/nessar/vac-optimizer/issues/58); removal of the automatic calculation deadline and heartbeat-based worker liveness are implemented by [issue #59](https://gitea.nessar.fr/nessar/vac-optimizer/issues/59). The indicative duration estimate is implemented by [issue #60](https://gitea.nessar.fr/nessar/vac-optimizer/issues/60); its initial model, session-local refinement and calendar-rendering measurement are documented in [planning-duration.md](../planning-duration.md).
 
-`deadlineMs` remains an opt-in contract for technical callers: a finite non-negative planning-work budget with no ten-second cap. An omitted value is unlimited. It starts after calendar preparation and excludes trace capture, observer callbacks, and post-outcome artifact work. The calendar and benchmark omit it. A one-second worker heartbeat renews the coordinator's thirty-second inactivity timer during cooperative preparation and search; total elapsed time never triggers that timer while activity continues. Worker errors and unavailable execution retain their explicit outcomes, and monitoring ends when the outcome arrives so delayed trace delivery cannot invalidate it.
+`deadlineMs` remains an opt-in contract for technical callers: a finite non-negative planning-work budget with no ten-second cap. An omitted value is unlimited. It starts after calendar preparation and excludes observer callbacks and post-outcome explanation work. The calendar and benchmark omit it. A one-second worker heartbeat renews the coordinator's thirty-second inactivity timer during cooperative preparation and search; total elapsed time never triggers that timer while activity continues. Worker errors and unavailable execution retain their explicit outcomes, and monitoring ends when the outcome arrives so delayed explanation delivery cannot invalidate it.
 
-VacOptimizer accepts explicitly selected, fixed planning horizons whose start may be past and whose duration may exceed twelve months, retaining today through the same date twelve months later as the default. Calculations remain in the browser and run to completion without an automatic elapsed-time cutoff, with an indicative duration estimate and an explicit Cancel action; this accepts variable waiting time and resource use to make longer horizons usable without silently changing the user's dates. This supersedes ADR 0003's ten-second automatic planning limit and its retention in both ADR 0004 documents, while preserving the separation between the planning outcome, stable explanation, and original trace.
+VacOptimizer accepts explicitly selected, fixed planning horizons whose start may be past and whose duration may exceed twelve months, retaining today through the same date twelve months later as the default. Calculations remain in the browser and run to completion without an automatic elapsed-time cutoff, with an indicative duration estimate and an explicit Cancel action; this accepts variable waiting time and resource use to make longer horizons usable without silently changing the user's dates. This supersedes ADR 0003's ten-second automatic planning limit and its retention in both ADR 0004 documents, while preserving the separation between the planning outcome and stable explanation.
 
 The planning-period control in Configure your leave uses an inclusive last planning date. The planner retains its half-open horizon by using the following calendar date as its exclusive end, matching the inclusive date-selection convention of TIME_WINDOW rules.
 
 Editing the horizon does not trigger a calculation. The user can adjust dates, balances, and rules before using the existing Calculate action; until a new calculation is requested, the displayed calendar retains its preceding outcome and horizon.
 
-A successful calculation displays the calendar once, as soon as the full planning objective order is complete, without displaying intermediate plans during optimization. Trace delivery continues in the background and never delays or changes that final calendar. The indicative duration estimate covers elapsed time until the final calendar is usable, including any trace capture that delays the outcome, rather than the additional time to deliver the complete trace.
+A successful calculation displays the calendar once, as soon as the full planning objective order is complete, without displaying intermediate plans during optimization. Stable explanation delivery follows the outcome and never changes that final calendar. The indicative duration estimate covers elapsed time until the final calendar is usable, excluding later explanation work.
 
 Before Calculate, the estimate is shown as an approximate range in seconds or minutes based on the horizon, balances, and rules. It starts with a rough estimate and is refined using measured calculation durations on the same device; it never becomes an automatic stopping deadline.
 
 User cancellation during optimization preserves the best valid plan already found and labels it as a cancelled, incomplete calculation. Before any valid plan exists, cancellation reports that the calculation was cancelled without presenting a plan or claiming an obligation conflict.
+
+Issue #76 supersedes all original-trace requirements in this ADR and both ADR 0004 documents. Decision capture, historical analysis and replay are removed. Immutable calculation, valid-incumbent and final-state snapshots remain for the retained explanation, cancellation recovery and displayed-placement counterfactuals. Cancellation still preserves the best available jointly valid plan and never implies an obligation conflict.

docs/benchmark/README.md

@@ -3,21 +3,27 @@
 ## Composable optimization rules: current verification status
 
 The #70–#75 implementation uses explicit active optimization configurations in
-the benchmark fixtures. The latest full functional coverage run passes 652 tests
+the benchmark fixtures. Before trace removal, the full functional coverage run passed 652 tests
 across 34 files under the 2 GB Node heap limit, excluding the separate benchmark.
-This does not establish a passing performance protocol.
+That run does not establish a passing performance protocol.
+
+On 2026-10-15, the #76 worktree based on `ea42561` passed 630 functional tests
+across 33 files with coverage under the 2 GB Node heap limit. Complete outcome
+comparisons against that baseline matched for all seven benchmark scenarios.
+The separate, unchanged benchmark did not complete within its 300-second limit
+(external timeout exit 124). Performance acceptance and any further optimization
+remain with #78.
 
 Before the Gitea migration, GitLab pipeline 320 passed all 652 functional tests
 in 109.43 seconds, then the seven-scenario protocol timed out at its unchanged
 300-second limit without an out-of-memory failure. In an earlier diagnostic run, the loaded-year warm-up took
 184.36 seconds and its first measured repetition began about 251.78 seconds into
 the protocol. Those diagnostic timings precede the final period-projection cache
-and the planned original-decision-trace removal, and are not a result for either.
+and the original-decision-trace removal in #76, and are not a result for either.
 
 At the user's request, #75 finishes on saved-rule migration and functional
 verification. #78 owns benchmark verification and implementation of further
-optimizations when needed, after #76 removes tracing and #77 verifies the retained
-behavior. All seven scenarios, one warm-up and two measured repetitions per
+optimizations when needed, after trace removal in #76 and integrated functional verification in #77. All seven scenarios, one warm-up and two measured repetitions per
 scenario, the 2 GB heap limit and the 300-second timeout remain required for #78.
 At the user's request, the Gitea CI configuration defines the benchmark in a
 separate job with `continue-on-error: true` while #78 is open. Functional coverage
@@ -30,7 +36,7 @@ workflow preserves the separate advisory benchmark job. See the
 [CI migration status](../../README.md#continuous-integration).
 
 The results below document earlier implementations and protocols. They are
-historical measurements rather than the performance result for composable rules.
+historical measurements rather than the performance result for composable rules or trace removal. Their trace counts, timings and controls describe the former implementation only.
 
 ## Reference-phone protocol
 
@@ -38,13 +44,9 @@ Open the deployed application at `/benchmark` on the reference phone. Tap
 **Run benchmark**, wait for the seven scenarios to finish, then tap **Copy
 report** and save the tab-separated output with the date and build identifier.
 
-The harness measures preparation, planning-to-outcome latency, later trace
-delivery, and total wall time separately. It also reports planning work, trace
-capture, trace materialization, and trace transfer independently, plus the
-largest extra delay of a 50 ms UI heartbeat. It records the outcome, last
-completed quality stage, placement count, determinism, trace status, and trace
-candidate count. `PlanningIncomplete` is not a conflict: its last completed
-stage and incumbent are retained.
+The harness measures preparation, planning-to-outcome latency, planning work, and total wall time through stable explanation delivery. It also reports the largest extra delay of a 50 ms UI heartbeat, available main-thread heap, outcome, last completed quality stage, placement count and determinism. `PlanningIncomplete` retains its last completed stage and valid incumbent and is distinct from a conflict.
+
+Issue #76 removes all trace timing, status and candidate-count columns, along with trace promises and delivery requirements. The seven scenarios, warm-ups, repetitions, 2 GB heap limit, 300-second timeout and performance gates are unchanged. #77 owns integrated functional verification; #78 owns performance acceptance and any necessary optimization.
 
 ## Protocol
 
@@ -67,23 +69,16 @@ stage and incumbent are retained.
 
 The browser page uses the same `createPlanningCalculation(request)` context as
 the calendar and adds no solver or backend dependency. It omits `deadlineMs`.
-Trace delivery is reported separately and cannot replace a valid planning outcome.
+Explanation delivery is independent of the outcome and cannot replace a valid plan.
 
-`planning_ms` is the observed latency until the outcome is usable;
-`planning_work_ms` excludes trace capture. `trace_capture_ms` accounts for
-instrumentation during planning, `trace_materialization_ms` accounts for
-building the stable explanation and finishing the trace after the outcome.
-`trace_transfer_ms` measures worker transfer and receiver assembly work;
-`trace_delivery_ms` measures elapsed time until the complete trace is ready. `max_ui_delay_ms` includes
-planning, trace delivery, and report preparation. Trace readiness has no
-elapsed-time ceiling and never permits truncating actual candidate evaluations.
+`planning_ms` is the observed latency until the outcome is usable. `planning_work_ms` excludes observer callbacks and post-outcome explanation work. `wall_ms` includes preparation, outcome and explanation delivery. `max_ui_delay_ms` covers this entire interval; there is no decision recording, trace materialization or trace transfer.
 
 `peak_main_thread_heap_bytes` is Chromium's available `performance.memory`
 sample, taken alongside the 50 ms UI heartbeat. A blank value means this API is
 unavailable. This measures the page's JS heap, excludes the worker heap, and is
 not a claim about total application memory. For a browser profile, record the
 isolated Chrome process-tree RSS separately during planning and subsequent
-trace delivery, including the worker and renderer. State the sampling interval,
+explanation delivery, including the worker and renderer. State the sampling interval,
 CPU throttling, viewport, and whether a warm-up preceded each measurement.
 
 For cancellation measurements, use the normal calendar with the same saved
@@ -91,11 +86,15 @@ two- or three-year dates and balances. Cancel during preparation and an active
 optimization phase, using the keyboard in one run. Record request-to-outcome
 latency separately from request-to-artifacts latency; verify the partial-plan
 status or absence of a plan, one planning request, no placements before the
-outcome, and continued acknowledged delivery of the original trace. Confirm
+outcome, and delivery of its stable explanation. Confirm
 that editing an input remains possible during active worker CPU work. These
 measurements describe that device and workload; they impose no latency limit.
 
-## Hardware status
+## Historical measurements before trace removal
+
+The following records remain as evidence for their dated builds. Trace-related behavior and metrics below are superseded by issue #76.
+
+### Hardware status
 
 No reference-phone run has been recorded. The project owner elected to close
 the release tickets on 2026-09-25 using the emulated run below, accepting its

docs/planner-cancellation.md

@@ -1,6 +1,6 @@
 # Cancelling a planning calculation
 
-Issue [#58](https://gitea.nessar.fr/nessar/vac-optimizer/issues/58) implements the cancellation portion of ADR 0006. Issue #59 removes the automatic deadline while keeping the same cancellation and original-trace protocol. The duration estimate remains in issue #60.
+Issue [#58](https://gitea.nessar.fr/nessar/vac-optimizer/issues/58) implements the cancellation portion of ADR 0006. Issue #59 removes the automatic deadline. Issue #76 removes decision tracing while preserving cancellation and valid-plan recovery. The duration estimate remains in issue #60.
 
 `PlanningCalculationContext.cancel()` requests user cancellation once while its outcome is pending. `CalendarYear` keeps an accessible Cancel button visible during preparation, obligation search, and optimization. It announces the request, disables duplicate cancellation, and moves keyboard focus to the result heading when the outcome arrives. Cancellation never triggers Calculate. A subsequent explicit Calculate creates a fresh immutable calculation snapshot.
 
@@ -10,25 +10,25 @@ The core exposes resumable generator steps. `calculatePlanningAsyncInternal` dri
 
 The synchronous `calculatePlanningInternal` adapter drains the same steps without pauses for existing direct core callers. The public non-browser calculation context uses the asynchronous driver so its cancellation method also works.
 
-User cancellation is distinct from replacement by another calculation (`stale-calculation`) and isolated worker failure (`worker-error` or `worker-unavailable`). Replacement retains the existing termination and stale-response protection. User cancellation leaves the producing worker alive until its explanation and trace have been delivered.
+User cancellation is distinct from replacement by another calculation (`stale-calculation`) and isolated worker failure (`worker-error` or `worker-unavailable`). Replacement retains the existing termination and stale-response protection. User cancellation leaves the producing worker alive until its outcome and explanation data have been delivered.
 
 ## Retaining a valid plan
 
-The asynchronous calculation retains a copied incumbent as soon as the obligation search finds a jointly valid solution, before that entire stage has completed. It also considers accepted placements and every feasible evaluated quality candidate, including candidates rejected by a stage's narrower comparator. Each candidate is reconciled for earned entitlement availability and checked against all obligation rules before retention. The existing full lexicographic comparator chooses the best available incumbent; its comparisons are recorded in the original trace.
+The asynchronous calculation retains a copied incumbent as soon as the obligation search finds a jointly valid solution, before that entire stage has completed. It also considers accepted placements and every feasible evaluated quality candidate, including candidates rejected by a stage's narrower comparator. Each candidate is reconciled for earned entitlement availability and checked against all obligation rules before retention. The existing full lexicographic comparator chooses the best available incumbent.
 
-Retention reuses quality metrics already computed for an evaluated candidate. An intermediate state with more unplaced at-risk leave, or worse preferences at equal unplaced leave, is rejected using that objective prefix alone, with the actual short-circuited comparison recorded in the trace. This avoids rescoring dominated states during large obligation previews without skipping any produced history or a candidate that could improve the retained plan.
+Retention reuses quality metrics already computed for an evaluated candidate. An intermediate state with more unplaced at-risk leave, or worse preferences at equal unplaced leave, is rejected using that objective prefix alone. This avoids rescoring dominated states during large obligation previews without skipping a candidate that could improve the retained plan.
 
-Preference occurrence dates and patterns are calculated once for the run's immutable calendar and rules. Each comparison still checks the candidate's actual placements against those patterns; candidate scores and trace records are not cached.
+Preference occurrence dates and patterns are calculated once for the run's immutable calendar and rules. Each comparison still checks the candidate's actual placements against those patterns; candidate scores are not cached.
 
 On cancellation, the core materializes the retained state with consistent placements, balances, periods, rule provenance, and preference satisfaction. It returns `PlanningIncomplete` with reason `user-cancelled`. With an incumbent the French status is **Calcul annulé — plan partiel**; without one it is **Calcul annulé**, without a plan or an obligation conflict. Temporary search states never become the displayed incumbent.
 
-## Preserving the original trace
+## Delivering the outcome and explanation
 
-Cancellation follows the core's normal finish path. Quality evaluations are recorded before their incumbent comparisons, and each greedy placement attempt starts its own atomic decision. The recorder closes interrupted and unexecuted phases and drains every remaining operation from that run. The worker retains staged updates, including ones not yet posted, and continues its bounded, acknowledged trace delivery after optimization has stopped. It sends `artifacts-complete` only when all queued updates have been sent and acknowledged. The facade drains its own received update queue before resolving the trace. Neither layer replays planning to reconstruct this history.
+Cancellation follows the normal finish path. The stable explanation is derived from the retained state. Outcome and explanation have separate promises: delayed or failed explanation delivery cannot replace or remove an already settled valid partial plan. Repeated and late outcome messages cannot change that outcome, and calculation identities protect the UI against obsolete results and explanations.
 
-The stable explanation is derived from the retained state. The outcome, explanation, and trace have separate promises: delayed or failed artifact delivery cannot replace or remove an already settled valid partial plan. Repeated and late outcome messages cannot change that outcome, and calculation identities protect the UI against obsolete results and artifacts.
+Immutable `PlanningStateSnapshot` values preserve exact entitlement metadata, earned activations, declarations and placements for checkpoints and the final state. A worker failure retains the latest delivered valid checkpoint and can recover its stable explanation in a separate worker without rerunning planning. Displayed-placement alternatives use the captured configuration and state; no original decisions or historical baselines are retained.
 
-If Cancel is accepted just before a queued natural result reaches the facade, the pending outcome still becomes a user cancellation. An already computed valid plan can be retained, while a queued conflict cannot become the cancellation result. Its existing explanation receives interruption metadata, and the original phase history is preserved even when the worker had already completed those phases.
+If Cancel is accepted just before a queued natural result reaches the facade, the pending outcome still becomes a user cancellation. An already computed valid plan can be retained, while a queued conflict cannot become the cancellation result. Its existing explanation receives interruption metadata. The planning worker terminates after delivering the required artifacts; it never waits for trace acknowledgements.
 
 ## Verification
 
@@ -42,10 +42,10 @@ bunx tsc --noEmit -p tsconfig.app.json
 bunx tsc --noEmit -p tsconfig.spec.json
 ```
 
-The public cancellation tests cover immediate cancellation, queued trace updates on both sides of the request, a stable partial outcome despite late completion or artifact error, distinct worker failure and replacement (including non-browser explanation metadata), and cancellation after settlement. A core regression compares the retained plan's full objective vector with every valid candidate actually evaluated before cancellation. The CalendarYear tests cover keyboard activation, translated statuses with and without an incumbent, focus, no implicit recalculation, explicit recalculation, and obsolete trace delivery.
+The public cancellation tests cover immediate cancellation, a stable partial outcome despite late completion or artifact error, distinct worker failure and replacement (including non-browser explanation metadata), and cancellation after settlement. Core regressions verify retained validity, provenance, earned chronology and the best available partial plan through the existing checkpoint seam. The CalendarYear tests cover keyboard activation, translated statuses with and without an incumbent, focus, no implicit recalculation, explicit recalculation, and obsolete explanation delivery.
 
-The real-worker suite bundles the production worker source with Bun and runs it on a separate Node worker thread. Its small host adapter maps browser worker messages to the thread's message port; the planner, CPU work, cancellation handling, and acknowledged trace protocol are real. It checks interruption after preparation has started, before the first obligation solution, during active obligation CPU work after a solution exists, and after a completed checkpoint. It also compares an uncancelled outcome with the synchronous adapter's deterministic result. These checks complement the controlled worker boundary tests.
+The real-worker suite bundles the production worker source with Bun and runs it on a separate Node worker thread. Its small host adapter maps browser worker messages to the thread's message port; the planner, CPU work, cancellation handling, and outcome and explanation delivery protocol are real. It checks interruption after preparation has started, before the first obligation solution, during active obligation CPU work after a solution exists, and after a completed checkpoint. It also compares an uncancelled outcome with the synchronous adapter's deterministic result. These checks complement the controlled worker boundary tests.
 
-For a browser check, serve the production browser build and use native Chromium Web Workers with a saved annual horizon. Check cancellation during calendar preparation, a broad obligation search, and a quality pass. Confirm one planning request per Calculate, no new request on Cancel, the appropriate translated status, joint rule satisfaction and balance accounting for an incumbent, and complete trace delivery after the outcome. Also check the Cancel control with the keyboard, at 375px width, and in light and dark themes.
+For a browser check, serve the production browser build and use native Chromium Web Workers with a saved annual horizon. Check cancellation during calendar preparation, a broad obligation search, and a quality pass. Confirm one planning request per Calculate, no new request on Cancel, the appropriate translated status, joint rule satisfaction and balance accounting for an incumbent, and stable explanation delivery after the outcome. Also check the Cancel control with the keyboard, at 375px width, and in light and dark themes.
 
-The production build was checked in native Chromium for all three interruption points, including keyboard cancellation during a 375px dark-theme obligation search and desktop light-theme checks. An editable input could still receive focus during CPU work, and focus moved to the result heading after keyboard cancellation. Each run sent one planning request and one cancellation request, displayed the appropriate French status, and completed acknowledged artifact delivery. The Cancel control was 44px high and the page had no horizontal overflow. In these sample runs, cancellation through artifact completion took under 200ms; this is measured evidence, not a latency guarantee.
+Earlier browser checks before #76: the production build was checked in native Chromium for all three interruption points, including keyboard cancellation during a 375px dark-theme obligation search and desktop light-theme checks. An editable input could still receive focus during CPU work, and focus moved to the result heading after keyboard cancellation. Each run sent one planning request and one cancellation request, displayed the appropriate French status, and completed acknowledged artifact delivery. The Cancel control was 44px high and the page had no horizontal overflow. In these sample runs, cancellation through artifact completion took under 200ms; this is measured evidence, not a latency guarantee.

docs/planning-duration.md

@@ -79,13 +79,12 @@ The existing initial calculation falls back to the start of `startCalculation`.
 The endpoint is Angular's `afterNextRender` callback after the complete plan has
 been projected into the calendar, its months and placements have been rendered,
 and the loading overlay has been removed. This measures request scheduling,
-calendar preparation, worker startup, search, trace capture that delays the
-outcome, outcome transport, projection and Angular rendering. It is a DOM
+calendar preparation, worker startup, search, outcome transport, projection and Angular rendering. It is a DOM
 readiness endpoint, rather than a claim to measure a physical screen's paint.
 
 Neither core `planningWorkMs` nor artifact timings supply the calibration
-measurement. The callback does not wait for the explanation or trace promises;
-later delivery, navigation and trace errors never add a second measurement.
+measurement. The callback does not wait for the explanation promise;
+later delivery, navigation and explanation errors never add a second measurement.
 Cancellation (including a retained incumbent), incomplete outcomes, invalid
 inputs, conflicts and calculation errors do not calibrate successful-plan
 waiting time. Superseded calculations and callbacks for destroyed calendars
@@ -98,12 +97,12 @@ timer, date adjustment or new calculation. **Cancel** remains explicit.
 
 Controlled-clock tests at the existing calendar and input seams cover initial
 estimation, unsubmitted edits, minute formatting, local refinement, request
-scheduling, a twenty-second calculation exceeding its initial range, a trace
-that fails five minutes after calendar readiness, cancellation with and without
+scheduling, a twenty-second calculation exceeding its initial range, an explanation
+that arrives after calendar readiness, cancellation with and without
 an incumbent, incomplete/error outcomes and superseded calculations. No timing
 assertion depends on CI hardware speed. Existing settings, planner and worker
-tests cover saved horizons, long calculations and original interrupted traces.
+tests cover saved horizons, long calculations and interrupted-plan explanations.
 
 Rendered annual, two-year and three-year references, with the actual displayed
-range and separate later trace wait, are recorded in
+range and historical artifact-delivery wait, are recorded in
 [the benchmark report](benchmark/README.md).