feat: activity record deletion (#70), split measure controls + SpO₂ interval (#66), battery grid & runtime estimate (#65), split-night records (#68), derived stress (#67)

[foureight84]

Closes #65, closes #66, closes #68, closes #70. Addresses half of #67.

Five feature requests that accumulated during the 2.8.0 cycle, most of them split off from the bug work rather than raised cold. None of it is hardware-tested — every ring-facing change here is behind a capability the reporters' rings advertise, but the measure controls, the SpO₂ interval and the derived stress card all want a look on real hardware before this merges.

1335 tests, 0 failures. Two schema migrations (v25 → v26), so a downgrade past this wipes local data — see the note at the end.

---

#70 — delete individual activity records

The rest of #60's request, from the same reporter: the vitals side got a READINGS list with a delete per entry, activity had no equivalent. A ring logs activity in intraday blocks, so a day's total is built from a couple of dozen rows, and anything that inflates one — the ring carried rather than worn, a car journey on a rough road — is stuck in that total for good.

A RECORDS card on the Activity screen lists today's blocks with their times and step counts, each deletable behind a confirmation that states what the day's total will drop by. Deletion only, as in #60.

Two rules make it stick, and both live in ActivityBucketDeletion:

• A tombstone, not just a DELETE. activity_buckets is keyed by block start time and upserted deliberately — re-syncing a day must replace each block, not accumulate it, or the total drifts upward every pass. That idempotence is exactly what would undo the deletion. The tombstone goes in the same table the vitals ones use, under an activity:<startEpoch> key, so it rides the archive with them and needs no migration.
• The day is restated without the ratchet. A day's total is the sum of its blocks, but today is ratcheted against the existing row, because the live cumulative step count legitimately leads the block history. A deletion is the one case where the total must be allowed to fall — ratcheting would remove the row and leave its steps sitting in the headline, which reads as the delete having silently failed.

#66 — separate HR and SpO₂ controls, and an SpO₂ interval

Separate controls. The legs have almost nothing in common on a YCBT ring: heart rate runs to 45 s with the ring self-terminating near 35, blood oxygen runs to 75 s, first sample at t+13, with a 24 s silence in the middle. One button meant waiting out both to get either — a tester's run started at 123 s and heart rate landed with 85 s still on the clock. Each control now counts down its own leg. The combined 0x23 flow keeps its single button, because there it genuinely is one measurement. The two can't overlap: the ring serves one at a time and the live-sample gate is one switch per kind, so spotMeasureInProgress disables both while either runs — a visible refusal rather than a silent no-op.

An interval for blood oxygen (@Albabit's follow-up). Measurement Frequency offered an interval slider for heart rate and only an on/off toggle for SpO₂, so SpO₂ silently inherited the heart-rate interval — on a ring running both hourly, that's most of the battery. Nothing in the protocol was in the way: the monitor command takes the same shape for every vital (01 <key> {enable, interval}) and the encoder was already sending an interval byte for blood oxygen, it just passed heart rate's. 0 means "follow heart rate", which is what every existing row did implicitly, so the new column backfills losslessly.

#65 — battery grid and runtime estimate

Both halves of @aheider's request: a faint vertical rule at each day boundary on the 7 d view and every six hours on 24 h, and a runtime estimate underneath.

The estimate is fitted over the current discharge run, not the window. A least-squares line is what was asked for, but a 7 d window almost always contains a charge, and a line through "40 % falling, then 100 %, then falling again" has a slope that describes when the user plugged in. A rise of three points or more is the boundary; less is coarse reporting wobbling at a plateau (some firmware reports in 5 % steps) and must not split a run.

It refuses to answer rather than guessing — under four samples, under 90 minutes, under two points of fall, or a flat or rising line all give "not enough of a trend yet". Battery life is the kind of thing someone plans a trip around, so an unearned estimate is worse than none.

#68 — a split night's individual records

A ring closes a session when the wearer gets up and opens a new one when they settle, so one night can arrive as two or three records minutes apart. Merging them is right — that's the night, and the merge is what #63 fixed — but the records are real information the merge hides, and the vendor app keeps each as its own row.

The sleep detail screen now shows them under the hypnogram: each record's clock range and time asleep, with the wake between them stated. The merged session stays the headline, and the card only appears when there's more than one record.

Recovered from stored data rather than re-parsed: since #63 each record's blocks are placed against its own declared bounds, so a boundary is a stretch no block claims. The threshold is two minutes, which is what separates a real boundary from the one-minute seam left by rounding blocks onto the minute grid — without it every unsplit night grows a spurious second record.

#67 — derived stress (half the issue)

The R100 answers neither the stress history query nor its monitor-state read-back — 22 sends, 0 replies, while every other state query answered — so stress there is absent, not switched off. The app advertised it anyway, because the capability list is a static per-family constant, and the user got a card that could never fill.

It is labelled wherever it appears: the card reads "Estimated from HRV — your ring doesn't measure stress", and stressIsDerived travels with the series so no future surface can render it as measured by accident. Presenting a derived figure as a measurement would be worse than the empty card it replaces.

Scored against that user's own recent HRV rather than a population — HRV varies several-fold between individuals, so an absolute cutoff labels whole people permanently stressed or calm. Median and median-absolute-deviation, not mean and standard deviation, because ring HRV history is full of outliers; a test pins that a 400 ms reading moves the result by at most five points. Below twelve baseline readings it returns null. It fills in only where the ring returned no stress at all, and never blends with hardware readings.

What I did not do: the first half of #67 — tracking which capabilities an individual ring has actually confirmed, rather than trusting the family constant. That is the deeper fix and it touches the capability plumbing AGENTS.md warns about, so it wants its own change and its own reasoning. I've left #67 open for it.

---

Testing and risk

./gradlew testDebugUnitTest — 1335 tests, 0 failures. New pure, tested logic: BatteryProjection (steady discharge, a charge mid-window, plateau wobble, each refusal case, both gridline shapes), sleepRecordRuns (two- and three-record nights, the one-minute seam, an unsplit night, awake inside a record), DerivedStress (median behaviour, relative-to-the-person scoring, outlier resistance, every refusal), and the activity tombstone rules including that activity and measurement tombstones can't collide.

Two migrations, so rollback is destructive. v25 → v26 adds device_measurement_configs.spo2IntervalMinutes. Anyone moving back to a build older than 2.8.0 hits the destructive downgrade fallback and loses local data; export an archive first.

Unverified on hardware. Everything here compiles and is unit-tested, but nobody has run it on a ring. The three worth a real look before merge: the separate measure controls on a YCBT ring, the SpO₂ interval actually being honoured (the firmware floors it at 30 min on @Albabit's ring), and whether the derived stress numbers look sane against a real HRV history rather than a synthetic one.

🤖 Generated with Claude Code