refactor(planning): remove the original decision trace

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