Skip to content

Integrate upstream 12.1.0 prerelease into the Apple test version - #25

Closed
AlexSchmidt1999 wants to merge 8 commits into
codex/offline-trainingfrom
codex/prerelease-sync-oct10
Closed

AlexSchmidt1999 wants to merge 8 commits into
codex/offline-trainingfrom
codex/prerelease-sync-oct10

Conversation

@AlexSchmidt1999

Copy link
Copy Markdown
Owner

Integrate the published upstream 12.1.0 prerelease (testing-latest, pinned to eae23433) into the existing Apple test version, preserving the fork's assistant, training, widget, and performance work.

The seven upstream commits include battery-pack charge display, ECG probe corrections, and the upstream Android stress-cache fix. Android files are imported unchanged as part of the authorized full sync; local builds and tests cover Apple only. Keep the fork's higher iOS build counter and review only the project-version hash in the source-security baseline.

Validation on the combined candidate: 4 ECG probe Swift tests; macOS app compilation and 44 focused app tests, including battery-pack routing, sync presentation, and training; iOS Release compilation including widget/watch targets. No ECG command was sent to a strap. Real battery-pack/ECG behavior remains untested on hardware. GitHub checks must be assessed separately from these local results.

This is a fork-only test integration. No upstream PR or main-branch promotion is requested.

kavemang and others added 8 commits October 8, 2026 23:53
The caller list was written as an exhaustive set, so it goes stale the
moment a gate joins. StressWidgetProducer's memo became the fifth.

Refs ryanbr#2710
Route the validated WHOOP 5/MG event 109 reading into Apple live state so the Devices card matches Android without new BLE traffic.

Clear stale readings on pack removal and disconnect.
The MG ECG probe could not observe a completed reading on any strap or
firmware, and its report looked correct while it happened.

@meta1971's field timing on ryanbr#891 is the evidence: across five MG sessions
the terminal frame (classifier state 2, progress 100) landed 38 to 39 s
after the first live frame, against a 30 s listen window held independently
by both platforms. The verdict sheet appearing at 30 s made it worse than a
missed deadline, since Stop is the next control a person reaches for.

Second defect, same report: the candidate cap kept the FIRST twelve frames
and R17 arrives about once a second, so the retained evidence was seconds 1
to 12 while result, average HR and the reason mask populate only on the
terminal frame. The packet count stayed honest; the retained evidence did
not.

Whoop5EcgProbe now owns the window, the caps and the two decisions, with a
declared twin on each side, so the numbers cannot drift apart again. A
capture run listens 60 s, wrist-select and stop keep 30 s, a terminal frame
is retained past the cap within a bounded reserve, and it re-arms the run
for 10 s more rather than ending it: the variability field reads 0xffff for
2 to 9 s after that frame, so stopping on it would pin the unset value as
the reading's own. A terminal frame also now ends a run EARLY, so the report
quotes the time listened rather than the window asked for.

The client wiring is BLE code and cannot be covered without a strap. The
rules it calls are pure and pinned on both platforms, including the window
against the measured 39 s, and a mutation back to the old behaviour kills
the two cases that name the two defects on both sides.

Tools/parity_twin_map.json carries the derived counts for the four new
declarations (functions 4534 to 4538) so the authority keeps reproducing.

Refs ryanbr#891
Found re-reviewing the window change, which is what created it.

A stop re-arms the probe run, and re-arming cleared the candidate lines and
the packet count along with the steps. At a 30 s window the verdict sheet
had almost always rendered first, so little was lost. At 60 s it has not:
the reading completes at 38 to 39 s while the sheet still reads "waiting",
so the obvious next action is to stop a session the user can see has
finished, and that discarded every R17 line including the terminal frame
this change exists to retain.

So a stop issued while the capture's window is still open carries the
lines, the count and the run's START TIME. The start time travels with
them because the report states "packets seen in Ns", and a count from a
47 s capture under a 30 s stop window would attribute those packets to a
span that did not collect them.

Only while the window is open. Once the verdict has rendered the lines are
already out, and a later stop is a separate run. A fresh capture still
clears, or a previous reading's frames would surface as the new one's, and
wrist select still clears because its report is about a different command.

Refs ryanbr#891
Second re-review pass, on my own first pass.

`ecgProbeDeadline` is a MARKER: `ecgProbeArmed` tests it for nil and nothing
in the file compares the stamp to the clock. So stamping it with
`now + window` encoded the window a second time, where only the verdict
timer's delay can act on it, and `ecgStartCapture` had to pass the same
number twice for the code to read correctly.

The window now lives in `scheduleEcgProbeVerdict` alone, which also renews
the marker, and `beginEcgProbeRun` goes back to arming the run. Arming stays
there rather than moving into the scheduler because the sends in between can
draw a COMMAND_RESPONSE and the triage is gated on it.

This is the shape Kotlin already had, where `ecgProbeListening` is a plain
flag and the window exists only in the posted delay, so the two clients now
make the same four window decisions in the same four places.

Refs ryanbr#891
Marketing version moves with it, since this beta is of 12.1.0 rather than
another 12.0.0 staging build.

Refs ryanbr#891
Review the project hash for the prerelease version; capabilities and endpoints are unchanged.
@AlexSchmidt1999

Copy link
Copy Markdown
Owner Author

Closing this older fork test PR. Its full head (d3919e3f2a82) is included in the combined test branch. New test-version work continues in #28. The branch and commits are kept.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants