Repository navigation
Open
Labels
area:releaseRelease readiness, distribution, signing, and hardware validationRelease readiness, distribution, signing, and hardware validationpriority:P0Critical path or release-blocking workCritical path or release-blocking workrisk:R2Health data, persistence, integration, AI, accessibility, or native riskHealth data, persistence, integration, AI, accessibility, or native risk
Description
Goal
Ship the next verified 0.1.x build as a real, non-prerelease GitHub release with a signed Android APK and an externally testable iOS build. First validate the Android compatibility fix through a private release-mode candidate; do not create another public prerelease just for diagnosis.
Guardrails
- Do not publish tester contact details, screenshots, sensor/device identifiers, health data, credentials, profiles, certificates, or private diagnostics.
- Do not ask testers to uninstall, unpair, or reset an active sensor unless a separately reviewed recovery procedure requires it.
- Product-facing release notes describe user-visible changes only.
Now
- Fix the already-bonded Android session path. One real device completes Android pairing but OpenGlucose remains at
Connectingwith no sensor details. Capture identifier-free stage/failure evidence across service discovery, notification subscription, vendor handshake, and baseline reads; reproduce an already-bonded reconnect; add deterministic regression coverage; verify on both the affected and known-good phones. - Build a private Android candidate. Use release mode, the existing package/signing lineage, and a fresh build code. Verify package, version, signer, and digest. Deliver privately as an in-place update and record the sanitized result. Do not attach it to a GitHub Release or public workflow artifact.
Stable 0.1 release blockers
- Record stable-release semantics. GitHub already has
v0.1.0andv0.1.1as prereleases, so those tags cannot represent new bytes. Select the next unusedv0.1.xversion/build and publish it as non-prerelease only after the candidate passes. Keep historical tags unless a separate destructive-cleanup decision is approved. - Make release automation support a real release. The current Android lane and draft TestFlight lane require
prerelease == true; update and test both so an approved non-prerelease can launch the two platform lanes without creating another public prerelease. - Land and configure the protected TestFlight workflow. Merge #33 after review, then configure its protected release environment and durable private state store under owner approval. Prove configuration with fail-closed preflight evidence before publishing a release.
- Resolve export compliance truthfully. Review the cryptography shipped by the app and dependencies, have the Apple Account Holder make the required determination, and store the decision/evidence privately before external beta review or notification.
- Upload and approve the next iOS build. No iOS
0.1.1 (19)was uploaded. Use the next verified version/build, confirm processing and exact audience, submit Beta App Review, and notify only after approval. - Choose and restore the external tester path. Decide between a controlled invite-only group and a public join link. Configure the workflow and audience consistently, attach the approved build, set usable capacity/invitations, and verify join + install with a new tester.
- Close external-release device controls. Record redacted physical-device evidence for data handling, active lock-screen redaction, release logging, and the critical sensor journey required by the repository control register.
Product follow-up
- Verify the complete warmup lifecycle. A phone entering warmup is useful evidence but does not prove countdown, transition to ready, or reading availability. Capture expected behavior, verify warmup-to-ready on hardware, and add a regression test.
- Raise the iOS deployment floor before Apple’s deadline. The current iOS 14 warning is not the present upload blocker; schedule iOS 15 migration, compatibility documentation, and CI/device verification before Spring 2027.
Operational tracking
- Reconcile the checked-in backlog. All 43 existing
.backlog/tasksentries still reportTo Do, including features already shipped. Audit each against its acceptance criteria, markDone/In Progress/To Doaccurately, remove stale branch notes, and add the release/compatibility work above. - Keep private-chat follow-ups sanitized. Review tester conversations for additional action items, but record only technical summaries in this public repository.
Current evidence
- v0.1.0 and v0.1.1 are both public prereleases.
- #33 is draft, cleanly mergeable, and its current CI/security checks pass; live release infrastructure is intentionally not enabled by the PR.
- #32 addressed initial Android bonding but does not yet have passing evidence for the newly reported already-bonded session path.
Metadata
Metadata
Assignees
Labels
area:releaseRelease readiness, distribution, signing, and hardware validationRelease readiness, distribution, signing, and hardware validationpriority:P0Critical path or release-blocking workCritical path or release-blocking workrisk:R2Health data, persistence, integration, AI, accessibility, or native riskHealth data, persistence, integration, AI, accessibility, or native risk
Activity
raynman1 commentedon Aug 15, 2026
Private Android validation candidate built and delivered (not published as a GitHub Release).
0.1.1-ronell.1 (20)4ba534f825c4d2101a1bcc61230a85c82b53958145ce00819246642f91bce1617235943199370e20a9ab64d8d90d1d8fe8ad831aHardware validation remains pending. Do not mark the compatibility item complete until the affected phone successfully reaches a verified sensor session (or returns a sanitized failure stage).
raynman1 commentedon Aug 15, 2026
Hardware result for private candidate
0.1.1-ronell.1 (20): failed on the affected Android device.Observed after selecting the already-paired sensor:
Connecting.The sensor disconnected. Keep the phone close and try again.--, and history remains at zero.This is not a warm-up state and does not close the compatibility task. The candidate did improve failure presentation but did not establish a verified vendor session. Next step: capture an identifier-free setup phase/operation/diagnostic code in a private diagnostic build, then patch the exact failing boundary. No public release should be created for this iteration.
shroominic commentedon Aug 15, 2026
Private candidate round 2 is now in hardware validation.
Copy support codeaction emits only a closed setup phase plus sanitized BLE category/operation/code; it excludes identifiers, native text, readings, and raw data.0.1.1-ronell.2 (21)was delivered privately as an in-place update. It was not published as a GitHub Release or public artifact.Awaiting the affected-phone result. If setup still fails, the copied
OGSUP1line will identify the exact phase for the next fix.shroominic commentedon Sep 1, 2026
Unverified field observation: intermittent disconnect
A participant reported that the sensor “sometimes disconnected” and that reconnecting in the app was unclear. This is not yet a reproducible defect: the interview did not capture the platform, app version, phone/OS, exact state, frequency, message, support code, or recovery result.
Before opening a separate runtime-reconnect bug, collect:
Android setup recovery from PR #52 and PR #55 shipped in v0.1.3 and is present in v0.1.6. If a verified session on a current build fails to recover, open a focused runtime-reconnect bug. Recovery must preserve the bond, active session, and stored readings.