| 10 | `2026-08-03-em-planner-rolling-execution-implementation.md` | Task 4 - Generic Control Adapter | `aa51ae2` | RED: `executor` exited 1 with missing `TrajectoryControlAdapter` and `IVehicleStateProvider`. GREEN: `PASS executor` verifies exact forward/reverse signed-velocity and yaw-rate mapping, telemetry preservation, zero holds, one-shot direction requests, no lateral body command, and no in-place rotation. |
| 10 | `2026-08-03-em-planner-rolling-execution-implementation.md` | Task 5 - Plugin Output and License Packaging | `3c84e36` | RED: `plugin-package` exited 1 because `Publish-ClumsyPilotPlugin.ps1` was absent. GREEN: `PASS plugin-package` verifies build-output metadata, managed `ClumsyPilot.dll`, x64/hash-checked `osqp.dll`, the exact three-license tree, and repeat publication with no stale staging directory. |
| 10 | `2026-08-03-em-planner-rolling-execution-implementation.md` | Task 6 - Rolling End-to-End and Final Gate | `4058230` | RED: `em-all` exited 2 because its command route did not exist. GREEN: `PASS rolling-end-to-end` and `PASS rolling-execution-tail` cover forward/reverse publication, supersession, unsafe-tracking reset, gear dwell, goal stop, and failure continuation to a non-extrapolated zero-speed tail. |
| 9 | `2026-08-03-em-planner-rolling-execution-implementation.md` | Task 1 - Cycle Identity, Scheduling Decision, and Stale-Result Suppression | `d75380c` | RED: the authorized inherited coordinator draft threw `ObjectDisposedException` when a completed current cycle was followed by another cycle. GREEN: `coordinator` printed `PASS coordinator`; the exact 100-run planned loop completed with exit 0 and 100 PASS lines. |
| 9 | `2026-08-03-em-planner-rolling-execution-implementation.md` | Task 2 - Safe Previous-Trajectory Handoff | `55119de` | RED: `coordinator` exited 1 with missing `TrajectoryHandoffSelector` contracts. GREEN: `PASS coordinator` covers forward/reverse same-segment interpolation, age/tracking/terminal/segment/direction/beyond-trajectory/gear-boundary rejection, no cross-boundary interpolation, and coordinator consumption of its immutable published trajectory. |
| 9 | `2026-08-03-em-planner-rolling-execution-implementation.md` | Task 3 - Gear-Switch State Machine and Trajectory Executor | `de402e6` | RED: `executor` exited 1 with missing gear-switch and execution-state types. GREEN: `PASS executor` covers forward-to-reverse and reverse-to-forward zero-speed dwell, one-shot request, confirmation, and Goal/RollingSafetyStop completion. |
| 1 | `2026-08-03-em-planner-foundation-implementation.md` | Task 2 — Configuration, Diagnostics, and Request Validation | `b326431` | RED: `foundation` failed with missing configuration/validation types; GREEN: `foundation` printed `PASS foundation` twice with byte-identical stdout and exit 0. |
| 1 | `2026-08-03-em-planner-foundation-implementation.md` | Task 3 — Direction Segmentation and Exact Boundary Anchors | `e492e16` | RED: `segmentation` failed with missing `ReferencePathSegmenter`; GREEN: `foundation` and `segmentation` each printed their PASS line with exit 0. |
| 4 | `2026-08-03-em-planner-osqp-backend-implementation.md` | Task 4 — OSQP Solve Lifecycle and Status Mapping | `a957fda` | RED: `osqp-loader` failed with missing `OsqpNativeSolver`; GREEN: fixed bounded, equality, infeasible and one-tick time-limit QPs pass inside a copied clean-plugin process. Status values 1–11 map to the planner-neutral contract, with finite metrics and captured native status. Twenty exact `osqp` solve/cleanup cycles printed `PASS osqp-solve` and `PASS osqp-loader` on every iteration. |
| 4 | `2026-08-03-em-planner-osqp-backend-implementation.md` | Task 5 — Backend Completion Gate | `61dfa79` | RED: `osqp` was rejected by the verification-host command parser; GREEN: it runs the full solver/loader group. README now records the pinned package, deployment layout, absolute-load rule, ownership and status mapping. `dumpbin /dependents` found only Windows/runtime DLLs; an externally located working directory still loaded a copied clean plugin bundle and solved the micro QPs. |
| 5 | `2026-08-03-em-planner-lateral-ls-implementation.md` | Task 1 — Variable Layout and Exact Discrete Lateral Dynamics | `c225b17` | RED: `lateral-model` failed to build with missing `LateralVariableLayout`; GREEN: `PASS lateral-model` covered contiguous `4N-1` indices, range checks, unequal-S exact integration, station/corridor/start validation, defensive copies, and the lateral result publication contract. |
| 5 | `2026-08-03-em-planner-lateral-ls-implementation.md` | Task 2 — Normalized Objective and Linear Hard Constraints | `f703d41` | RED: `lateral-model` failed to build with missing `LateralObjectiveBuilder`; GREEN: `PASS lateral-model` inspected normalized P/q coefficients with `1e-12` comparisons, exact integration equalities, finite hard bounds, goal/gear versus rolling terminal behavior, empty-intersection early failure, and the solver-neutral fake-QP boundary. |
| 5 | `2026-08-03-em-planner-lateral-ls-implementation.md` | Task 3 — Nonlinear Geometry Evaluation and Independent Validation | `0c48a7d` | RED: `lateral-model` failed to build with missing `LateralGeometryEvaluator`; GREEN: `PASS lateral-model` covered straight and constant-curvature references in forward/reverse, full Frenet curvature, actual strictly increasing PathS, curvature/yaw-rate signs, and rejection of denominator, curvature, non-finite, and independently recomputed world-geometry violations. |
| 6 | `2026-08-03-em-planner-lateral-ls-implementation.md` | Task 4 — Sequential Convex Outer Loop and Feasible-Candidate Fallback | `f19df53` | RED: `lateral-integration` failed to build with missing `SequentialConvexOptimizer` and `LateralPlanner`; GREEN: `PASS lateral-integration` scripted validation-before-fallback, invalid-vector rejection, `SolvedInaccurate` residual/geometry rejection, 0.05 m trust centering, complete-primal warm starts, five-call cap, cancellation, timeout and facade behavior. |
| 6 | `2026-08-03-em-planner-lateral-ls-implementation.md` | Task 5 — Real-OSQP Lateral Scenarios and Gate | `4d83ed2` | RED: `lateral-all` reached the real forward scenario but rejected the empty initial warm start; the subsequent loader diagnosis confirmed the host output bundle intentionally lacks `osqp.dll`. GREEN: the solver-neutral full initial primal and a clean copied plugin-bundle probe produced `PASS lateral-model`, `PASS lateral-integration`, and `PASS lateral-real-osqp` for deterministic forward/reverse straight, gentle curve, seed-connected obstacle narrowing, gear-switch, and rolling scenarios. |
- Commands: entry regressions `coordinator`, `executor`, `em-core-all`, `trajectory`, `lateral-all`, `optimization`, `osqp`, and `all-foundation`; Task 4 `executor`; Task 5 `plugin-package`; final `em-all` and `git diff --check`, all from the repository root.
- Result: every entry regression exited 0. The final post-commit `em-all` exited 0 with foundation, OSQP, lateral, longitudinal, trajectory, facade, coordinator, executor, plugin packaging, rolling end-to-end, and rolling-tail PASS lines; `git diff --check` exited 0.
- RED/GREEN: Task 4 RED `executor` exit 1 (missing generic adapter/provider), GREEN exit 0. Task 5 RED `plugin-package` exit 1 (missing script), GREEN exit 0. Task 6 RED `em-all` exit 2 (unregistered command), GREEN exit 0; the Task 5 output metadata required test-only clean-bundle copy fixtures to omit host-output `osqp.dll` before their existing explicit pinned-DLL copy.
- Result: The Stage 5 `lateral-model` gate exited 0 after all three Task commits. It proves the `4N-1` layout, exact unequal-station dynamics, immutable lateral inputs/results, normalized OSQP-convention P/q assembly, finite hard corridor/derivative/trust/denominator bounds, terminal distinction, full forward/reverse world reconstruction, actual PathS, and independent validation. `optimization`, `osqp`, and all four `all-foundation` groups exited 0. The dependency list remains `KERNEL32.dll`, `VCRUNTIME140.dll`, and API-set CRT DLLs only—no MKL, CUDA or external QDLDL. `git diff --check` had no whitespace diagnostics; immediately before this checkpoint update the staging area was empty and no Stage 5 scope files were uncommitted.
- Result: Stage 6 exit commands all exited 0 at `4d83ed2`: `lateral-integration`; `lateral-all` (model, scripted SQP, and clean-plugin real OSQP groups); `optimization`; `osqp`; `all-foundation`; and `git diff --check`. The real OSQP gate runs every fixed scenario twice and compares status, point count, and all lateral-path numeric fields within `1e-10`; the obstacle scenario stays in the negative, seed-connected corridor interval. The LS implementation remains dependent only on `IQpSolver`/`QuadraticProgram`; no LS P/Invoke, UI, hardware object, or current-working-directory dependency was added.
- Result: Stage 7 exit commands all exited 0 from the repository root at `510bf97`: `longitudinal-model`; `longitudinal-integration`; `lateral-integration`; `lateral-all`; `optimization`; `osqp`; `all-foundation`; and `git diff --check`. ST consumes only actual LS `PathS` and reaches OSQP only through `IQpSolver`/`QuadraticProgram`; no ST P/Invoke, UI, hardware object, or current-working-directory dependency was added. The jerk-stop case retains only the independently validated initial seed when OSQP reaches its 4000-iteration limit; the timed-out solver vector is not accepted.
- Baseline note: invoking the pre-existing `lateral-all` test from the `ClumsyPilot` subdirectory fails its pinned-DLL lookup because that Stage 6 test constructs the source path from `Directory.GetCurrentDirectory()`. Running the documented command from the repository root exits 0. Stage 7 does not modify or bypass the completed LS test.
- Normal-project baseline: the historical checkpoint recorded exit 1 from legacy `auto_avoidance/MultiWheelAutoAvoidance.cs` references to `NetTopologySuite` and `OpenCvSharp`. At the Stage 7 final read-only audit that source path is absent from both the working tree and the tracked `HEAD` tree, so `dotnet build ClumsyPilot/ClumsyPilot.csproj --no-restore` exits 0 with only two unrelated obsolete-API warnings. Stage 7 issued no delete/clean command and made no legacy-module change; preserve the observed workspace and do not recreate, delete, hide, or otherwise alter legacy functionality merely to change this baseline.
- Result: Stage 8 exit commands all exited 0 from the repository root at `019b896`: `em-core-all` twice (each printed `PASS longitudinal-model`, `PASS longitudinal-integration`, `PASS trajectory`, `PASS em-planning-service` in order); then `longitudinal-model`, `longitudinal-integration`, `trajectory`, `lateral-all`, `optimization`, `osqp`, `all-foundation`, and `git diff --check`. The trajectory gate independently verifies physical world-space publication and the service consumes only request snapshots through `IQpSolver` / `QuadraticProgram`; no Stage 8 production P/Invoke, UI, hardware, current-working-directory, dynamic-obstacle, rolling-execution, or controller dependency was added.
- Stage 8 RED commands and exits: Task 4 `trajectory` exit 1 (missing `EmTrajectoryAssembler`); Task 5 `trajectory` exit 1 (missing validator contracts); Task 6 `em-planning-service` exit 1 (missing `EmPlanningService`). Task 4/5 GREEN command was `trajectory` exit 0 / `PASS trajectory`; Task 6 GREEN command was `em-core-all` exit 0 twice with the required four PASS lines.
- Every captured user-baseline status entry remains untouched and unstaged: the final `git status --short` set has the same 125 entries as Stage 10 entry, with no additions or losses.
- The `lateral-all` fixture still resolves its explicitly copied pinned OSQP DLL from the repository-root current directory. Build-output `osqp.dll` is omitted only from the temporary clean-bundle host copy before that existing explicit copy; no LS/ST/OSQP/facade production behavior changed.
- The workspace continues to contain the same unrelated Map, CoarsePath, PathSmoothing, project-file, report, and documentation changes captured at Stage 6 entry. They belong to the user and remain untouched and unstaged.
- The historical legacy `auto_avoidance/MultiWheelAutoAvoidance.cs` dependency failure is not reproducible in the Stage 7 final workspace because that untracked/unversioned source path is absent. Do not recreate, delete, bypass, or otherwise alter legacy functionality to manufacture a different baseline.
- Remaining observed baseline noise: the first fresh Stage 8 core build printed the existing `Lidar2dDetect2LegTray.LegWidth` and `MultiWheelChassis.GetSteerWheels()` obsolete-API warnings; `git diff --check` emits CRLF conversion advisories for user-owned dirty files but exits 0. Neither is an EM Planner regression.
- Confirm branch `trajplanner`, `a957fda`, `61dfa79`, `c225b17`, `f703d41`, `0c48a7d`, `f5c69c2`, `f19df53`, and `4d83ed2` are ancestors of `HEAD`, and the Stage 6 progress checkpoint is present.
