Repository navigation
Fix logo white corners on GitHub dark theme - #4
Merged
Merged
Conversation
…corners The rasterized logo-v3.png looked fine on GitHub's light theme and wrong on its dark one: a white box around the badge. Cause: the PNG was rendered via QuickLook, which composites SVGs onto white, so the area outside the badge's rounded corners was opaque white rather than transparent. `hasAlpha: yes` hid this — the channel existed, the corners just weren't transparent in it. - README now points at docs/assets/logo.svg directly. It's a vector, so the transparency is real, it stays sharp at any size, and there's no rasterization step to get wrong. Verified against both GitHub background colours (#ffffff and #0d1117). - docs/assets/logo-v3.png restored to upstream's version: nothing references it now, and leaving a broken asset behind (or diverging from upstream on a file this fork doesn't use) helps no one. The app icon is unaffected — icon_1024.png is full-bleed with no transparent region at all, so the compositing that broke the badge can't apply to it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
DX23876
pushed a commit
that referenced
this pull request
Jul 22, 2026
Backup & Sync: keep-count dropdown, default 7, ~1am daily, Settings discoverability
DX23876
pushed a commit
that referenced
this pull request
Jul 22, 2026
From #34 (alarm not buzzing): the strap consistently reported a STALE armed time regardless of what NOOP sent (its clock was reset) — the ryanbr#401 readback caught it, but nothing surfaced it and the log even claimed 'armed' while disconnected. #3 — Alarm block in the debug export (both platforms): the configured wake + the last arm's sent-vs-strap-reports epochs with a MISMATCH flag, so a 'didn't buzz' report is decidable at a glance. armStrapAlarm persists the sent epoch (+ when + connected); the GET_ALARM_TIME readback persists what the strap reports; the export composes them (best-effort, guarded). #4 — don't log 'Alarm: armed' when the strap isn't connected (the SET was dropped). Log 'queued — will send on next connect' instead, so the log stops claiming an arm that never transmitted. Both platforms (iOS BLEManager/FrameRouter/DebugDataDiagnostics; Android WhoopBleClient/ AndroidDiagnostics). Android compiles clean; iOS gated by CI.
DX23876
pushed a commit
that referenced
this pull request
Jul 22, 2026
…ck skew Rounds out the Alarm block to cover the full alarm-failure matrix, not just 'didn't stick': - #1 last fired: persist STRAP_DRIVEN_ALARM_EXECUTED → 'Last fired: Nh ago / never observed' (the 'did the strap actually buzz?' leg of the armed→reports→fired sequence). - #3 model + 5/MG experimental gate → 'Model: 5.0/MG · experimental: off → NOT armed', the #1 '5/MG alarm never fires' cause (silently gated off). - #4 strap clock skew: persist the newest banked record → 'Strap clock: 446d behind (reset)', the actual #34 root cause, surfaced instead of buried in the CLOCK-WARNING log line. Now the block triages: didn't arm (model/experimental/connected), didn't stick (sent-vs- reports + clock), didn't fire (last-fired). Both platforms; persists at low-frequency points (fired event, GET_DATA_RANGE). Android compiles clean; iOS gated by CI.
DX23876
pushed a commit
that referenced
this pull request
Jul 22, 2026
The iOS #3 model line compared selectedWhoopModel against "whoop5", but the stored WhoopModel rawValue is "WHOOP 5.0 / MG" — so every iOS user (incl. 5/MG) showed "Model: WHOOP 4.0" and the experimental-gate hint never rendered. Compare against WhoopModel.whoop5mg.rawValue and print the real model name. Clock-skew (#4) only flagged a clock BEHIND wall; a future-dated strap clock (the ryanbr#928 case, equally breaks the alarm) showed "OK". Flag AHEAD too.
DX23876
pushed a commit
that referenced
this pull request
Jul 22, 2026
…m time (#34) When a strap's clock/alarm register is corrupted it silently rejects SET_ALARM_TIME — the readback keeps reporting an old time — and the firmware alarm never fires. Today that mismatch is detectable only in the debug export, and only as a one-shot. Instrumentation (#2 — observability only, no BLE command change): - FrameRouter: on each GET_ALARM_TIME readback, count CONSECUTIVE rejections (reported != last sent). A matching readback resets the streak, so a transient (first read stale, then correct) never trips it; only a persistent refusal climbs. - recordAlarmArm: persist the strap-clock skew AT ARM. Skew ~0 while the strap still rejects ⇒ a corrupted alarm register, not a clock problem — pins whether a re-clock could ever help. - Debug export Alarm block surfaces both (clock-at-arm on Last arm; "N in a row" on Strap reports). - disableStrapAlarm clears the streak (nothing armed to refuse once disarmed). User warning (#4): - SmartAlarmView shows a card, ONLY when the alarm is on and the strap has refused >=2 arms in a row, telling the user the strap isn't accepting the alarm and to reset it via the official WHOOP app / keep a phone Clock alarm. Driven by @AppStorage so it appears/clears live. Not a fix for a corrupted strap (that's firmware-side, #34) — it turns a silent, export-only failure into a persistent signal and actionable on-device guidance.
DX23876
added a commit
that referenced
this pull request
Jul 22, 2026
Fix logo white corners on GitHub dark theme
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does
The README logo showed a white box around the badge on GitHub's dark theme.
Cause:
docs/assets/logo-v3.pngwas rasterized with QuickLook, which composites SVGs onto awhite background. The area outside the badge's rounded corners ended up opaque white instead
of transparent.
hasAlpha: yesmasked the bug — the alpha channel existed, the corners justweren't transparent within it.
docs/assets/logo.svg. Vector, so the transparency is real, it stayssharp at any size, and there's no rasterization step left to get wrong.
docs/assets/logo-v3.pngrestored to upstream's version. Nothing references it anymore;keeping a broken asset (or diverging from upstream on a file this fork doesn't use) helps no one.
The app icon is unaffected:
icon_1024.pngis full-bleed with no transparent region at all, so thecompositing that broke the badge cannot apply to it.
Type of change
How it was tested
Rendered the SVG composited against both GitHub background colours (
#fffffflight and#0d1117dark) and inspected the result — the badge sits clean on both, with no white frame. Thatsame test is what surfaced the original bug in the PNG, so it's a real regression check rather than
a guess.
No code touched; nothing to build.
Checklist
android/— n/a,android/untouchedStrandDesigntokens — n/a, static asset, not in-app UIdocs/CONTRIBUTING.mdStrand.xcodeproj/) or any secrets/keystoresRelated issues
Follow-up to #3.