docs: a strikethrough that renders, and the 22% claim attributed to the right document

SPECS.md

@@ -39,13 +39,15 @@
 
 ## Deviations from the spec
 
-The following were built differently from what the spec states, for documented reasons in `README.md`:
+The following were built differently from what was asked for, each for a reason `README.md` states
+in full:
 
 - **`todo.md` item 2 — relative timing.** Implemented as `--relative-time`. The retained history
   in this mode is **41.943 s** against the default **83.886 s** (measured at 100 kS/s, 4 channels,
   `--buffer-mb 200`): exactly half, because a second f64 ring for absolute time raises a tick's
   cost from 24 to 32 bytes — a third more — and `Partition::time_capacity` is floored to a power
-  of two, so a third more weight costs a full halving. The spec and the original plan both quoted
-  ~22%, which is wrong; the per-byte figure of 75% is also wrong for the same reason.
+  of two, so a third more weight costs a full halving. The design document and the implementation
+  plan both put the cost at ~22%, which is wrong; the per-byte figure of 75% is wrong for the same
+  reason.
   Absolute stream time is preserved in a separate ring and used for the export's `abs_seconds`
   column, exactly as `todo.md` requires.

todo.md

@@ -2,14 +2,13 @@
    1. the antialisaing strategy with phosphore effect should be applied with more stregth
    2. the lines should be more tick
    3. the sample points should be bigger
-~~2. relative timing:
+2. ~~relative timing~~ **done**: `--relative-time`; see README and SPECS.md for the measured history cost.
    - in order to avoid problem with time jitter user can decide to go in relative time mode
    - in this mode absolute signal time is only use for export
    - the plot time depends just on signal sample rate and frame number, e.g.:
      - user is acquiring a signal with 1MSps and 100_000 samples per udp frame
      - last frame as number <N> and previous <N-2> in this case a 100_000 indexes must be skipped
-     - time is simply: `((<N_frame> - <N_last>) * <n_samples_per_frame> - <sample_index>) / <sample rate>` (or something like that)~~
-   done: `--relative-time`; see README and SPECS.md for the measured history cost.
+     - time is simply: `((<N_frame> - <N_last>) * <n_samples_per_frame> - <sample_index>) / <sample rate>` (or something like that)
 3. named configurations: in order to have multiples configurations for the same sources configuration can also have comments
 4. optional udp frame storage for debugging of strange behaviours (store last <N>, default = 1000, udp packets binary content on disk for forensic analyss)
 5. open exported binary waveforms to view/analyse, in the source selection dialog there should be the option to open exported waveform (maybe a tab with latest opened file and option to open new ones?)