docs: add offline speed comparison artifacts

docs/superpowers/specs/2026-08-11-em-cycle-deadline-and-publication-contract-design.md

@@ -92,6 +92,16 @@ Tests are written before each production change.
 3. Optimizer checks: the 12-call cap and one-retry rule remain unchanged; a validated anchor is returned rather than an optional improvement when the publication reserve prevents another attempt; a physical stop failure is not promoted.
 4. Real-OSQP regression: run `longitudinal-model`, `longitudinal-integration`, `em-speed-profile`, and the exact four-scenario `em-longitudinal-contract-offline` command twice.  The final command must show all four scenarios published, physically valid, nondecreasing in PathS, terminally stopped, peak speed within the existing envelope, and total elapsed time below five seconds.
 
+## Offline speed-comparison artifacts
+
+Before any production planner behavior changes, the offline verifier exports a real-OSQP baseline for the four acceptance scenarios.  After the repair, it exports the same scenarios with the same fixed geometry and configuration.  Each run uses a new timestamped, ignored artifact directory so a later test cannot overwrite a baseline.
+
+Every published trajectory CSV contains one row per emitted trajectory point with the run label, scenario name, sample time, PathS, progress speed, progress acceleration, progress jerk, curvature, total planning elapsed time, peak speed, terminal speed, and publication status.  A non-published scenario writes a summary CSV row containing its status, elapsed time, and diagnostic reason, but it writes no invented trajectory-point rows.
+
+A repository Python script using `matplotlib` accepts one baseline artifact directory and one repaired artifact directory.  It produces one PNG per scenario with baseline and repaired speed-versus-time curves on their native time coordinates, a 1.0 m/s reference line, and annotated peak and terminal speeds.  It also produces a compact CSV summary of published state, total planning time, peak speed, and terminal speed before and after repair.  Artifacts are test evidence, not source-controlled deliverables; the exporter, schema validation, and plotting-script invocation are version-controlled verification code.
+
+The comparison is observational only.  It must never substitute a reference schedule, seed, or fabricated zero-speed curve for a failed publication.  The final acceptance run still uses the existing trajectory and timing contracts rather than an image-based assertion.
+
 ## Failure handling and observability
 
 The public result distinguishes validation failure, solver timeout, cancellation, and deadline-expired non-publication.  Diagnostics must state whether any earlier trajectory was retained, but must not expose unbounded raw solver output.  Failure messages include enough local state to reproduce the first rejecting condition without logging whole trajectories.
@@ -104,3 +114,4 @@ The public result distinguishes validation failure, solver timeout, cancellation
 - Stoppable-set and PathS failures contain the stated local diagnostics.
 - Existing strict solver/physical limits remain unchanged.
 - The four real-OSQP acceptance scenarios are green only when they independently publish valid trajectories inside five seconds; safety timeout behavior cannot make them green.
+- The baseline and repaired artifact directories contain schema-valid CSV evidence, and the Python plotter produces a speed-comparison PNG for every scenario published in both runs.