Repository navigation
Preserve legacy RR-derived vitals and remove accidental scaffolding - #2141
Conversation
|
Thanks @bhelm. Reviewed on a checkout rather than from the description, and the substance holds up. The red check is not yours
The twin map's authority pins 4308 functions; the current derivation gives 4310. Same numbers and same hashes on It surfaced on your PR only because the gate is path-filtered to Nothing for you to do. I will re-derive the authority on main, and this should go green on a rebase. Verified independently
One nuance, not a blocker
Worth a sentence in the snapshot's doc all the same. A later reader who widens the gate past WHOOP 5, or a day whose stored respiration arrived from another brand under the computed id, would meet a preserved value that was never R-R-derived. Preservation never fabricates, so the risk is a stale value rather than a wrong one, but the reasoning is currently only true because of a device fact stated elsewhere. Still a draftLeaving it to you to mark ready. The hardware boundary you name is the right one: this widens a mechanism already hardware-tested for HRV and Recovery, and respiratory rate was the specific gap reported in #2123. |
The suite is path filtered to Tools/ on both triggers, but one of its tests is not about the scanner at all: the repository acceptance asserts the checked-in authority still reproduces from the CURRENT product source. Product changes are what invalidates it, and product changes are exactly what both filters exclude. So main could carry stale authority indefinitely with nothing red, until some later PR touched Tools/ and inherited the whole accumulated drift. Four staleness events now, three of them landing on an outside contributor's PR that caused none of it. Tonight was #2141: the same 4308 against 4310 and the same hashes failing on main, on that branch, and at 0b0d206 before any of today's merges. A daily run on main finds it within a day, where re-deriving is a two-minute maintainer action. Deliberately a schedule rather than an unfiltered push. My first attempt removed the push filter, and the suite's own test_core_tools_filter_covers_every_governance_tool_path caught it: that test pins BOTH filters and forbids product globs, so not running on product source is a deliberate invariant rather than an oversight. A periodic check keeps it true. Both path lists are therefore untouched and that test passes unchanged. This does NOT make drift repairable. --refresh-derived still fails "migration required" because the checked-in authority cannot be reproduced from the base, so the only route remains deleting both snapshots and re-bootstrapping, which no contributor can do. All this does is make the maintainer the one who finds out.
…2142) The suite is path filtered to Tools/ on both triggers, but one of its tests is not about the scanner at all: the repository acceptance asserts the checked-in authority still reproduces from the CURRENT product source. Product changes are what invalidates it, and product changes are exactly what both filters exclude. So main could carry stale authority indefinitely with nothing red, until some later PR touched Tools/ and inherited the whole accumulated drift. Four staleness events, three of them landing on an outside contributor's PR that caused none of it. The last was #2141: the same 4308 against 4310 and the same hashes failing on main, on that branch, and at 0b0d206 before any of that day's merges. A daily run on main finds it within a day, where re-deriving is a two-minute maintainer action. Deliberately a schedule rather than an unfiltered push. The first attempt removed the push filter and the suite's own test_core_tools_filter_covers_every_governance_tool_path rejected it: that test pins BOTH filters and forbids product globs, so not running on product source is a deliberate invariant rather than an oversight. Both path lists are therefore untouched and that test passes unchanged. This does NOT make drift repairable. --refresh-derived still fails "migration required" because the checked-in authority cannot be reproduced from the base, so the only route remains deleting both snapshots and re-bootstrapping, which no contributor can do. All this does is make the maintainer the one who finds out.
Summary
Follow-up to #2115 and #2123.
The exact-window legacy WHOOP 5 snapshot now preserves the remaining stored nightly values that are exclusively derived from R-R:
respRateBpm)avgSdnn)They use the same existing guard as HRV/Recovery and are released by the same labelled-transport boundary, including when the labelled transport is too sparse to score. No R-R rows are converted or relabelled, and the general upsert behavior is unchanged. A review of every stored
DailyMetricfield found no other value exclusively derived from nightly R-R.This PR also removes the repository scaffolding accidentally included in #2115:
okf/filesopenspec/files, includingopenspec/config.yaml, the German archived change, and the published specThe product implementation, Swift/Kotlin tests, cross-platform source contract, and maintainer-derived parity data from #2115 remain.
Verification
git ls-files okf openspecis empty.Test boundary
The current Linux environment cannot compile the Swift app/tests, so GitHub CI must provide the Apple build and test evidence. This widening has not yet been exercised with a real v11.5
.noopbakon physical WHOOP 5 hardware; it extends the same preservation mechanism already hardware-tested for HRV/Recovery.