Repository navigation
Conversation
Nutcasey
changed the title
This was referenced Nov 1, 2026
Trends reviews one period at a time (a day, 7, 14, 30 or 90 days) on one screen: summary tiles (average with SD and CV, GMI, insulin, carbs and boluses per day, Loop active), time in range, the daily pattern (AGP), basal and bolus, insulin per day and Loop status with its gaps. A one-day period leads with that day's timeline. Tapping a day opens a day page with the insulin timeline and active insulin and carbs, stepping a day at a time. The period exports as a PDF report or a CSV with one row per day. Inside Loop's 7 days the figures come from Loop's own stores, so manual and automatic boluses, temp basals, historical targets and presets are known. Older days come from Apple Health. Closed and open loop are recorded from launch, because Loop's automation history only covers 36 hours. Trends opens from Settings, beside Statistics, as a sheet with its own navigation and a Done button. Statistics and Current Setup are unchanged. This is part 1 of 6 splitting LoopKit#2621. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QHnVP7ynB62LNuuYMy3yvH
Nutcasey
force-pushed
the
redesign-4-add-carbs
branch
from
November 1, 2026 15:30
3537d7e to
3531385
Compare
Trends now carries everything Statistics shows that it lacked, so it can take Statistics' place: - Consensus goals: average under 8.6 mmol/L (154 mg/dL), GMI under 7% and CV 36% or less under the summary tiles; time in range over 70%, under 25% above and 4% below, under 5% very high and 1% very low, and CGM active over 70% on the Time in range card. - Scheduled basal under Basal in Basal and bolus: the schedule that applied over the same days (the stored profile with presets), or today's schedule where the profile history doesn't reach. - "Usually X U by HH:MM": today's insulin against the median by this time over the last 14 days, from InsulinDeliveryHistory as on Statistics. Under Total so far on today's Day view, and under the Insulin per day chart on longer periods ending today. - "CGM data covers 5 of 14 days." under Summary when readings start partway through the period. - Typed-in (fingerstick) readings are left out of every figure, as on Statistics. The day timeline still draws them. Each new line reuses a pattern already on the screen: the Aim footnote, the indented line under Bolus, and the muted footnote. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QHnVP7ynB62LNuuYMy3yvH
The Logbook lists Loop's 7 days newest first, a section per day with its insulin and carb totals and the day's basal and bolus split. Rows cover manual and automatic boluses, carbs, basal adjustments, suspends and resumes, site changes and pump alarms. Runs of automatic boluses fold into one row that opens the list of doses, and a day's basal adjustments open as their own list. Filters narrow it to boluses, basal, carbs or what Loop did automatically. Carb entries can be edited or deleted with a swipe when Loop's own carb editor would allow it, and doses can be deleted. Editing opens Loop's existing carb entry screen in a sheet, which keeps the bolus screen that can follow it clear of anything underneath. The Logbook opens from Settings, beside Trends, as a sheet with its own navigation and a Done button. This is part 2 of 6 splitting LoopKit#2621, and builds on part 1. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QHnVP7ynB62LNuuYMy3yvH
Now replaces the classic status screen's HUD and charts with one screen: the current glucose with its trend and target, Loop's state in words, the pump and CGM, IOB, COB and the current basal against plan, and Add carbs, Bolus and Presets. Under it, the next three hours with Loop's prediction and today so far on one timeline. Device and Loop problems are written out as notices that open the screen that fixes them. Now is StatusTableViewController's table with the new rows, so every existing flow keeps working from it: bolus progress and cancel, suspend and resume, alerts, presets, the insulin delivery log, carb absorption, the prediction breakdown, pump and CGM settings, the last Loop error, deep links and activity restoration. The last-error check compares with Loop's last completion rather than the HUD's, as Now has no HUD. Trends and the Logbook become tabs. Settings stays a sheet: its tab selects Now and presents Settings from there, as device and service screens open through StatusTableViewController. Deep links select Now first. A New Interface toggle in Settings switches back to the classic status screen with its action tabs, where Statistics, Trends and the Logbook stay in Settings. The new interface is on by default. This is part 3 of 6 splitting LoopKit#2621, and builds on parts 1 and 2. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QHnVP7ynB62LNuuYMy3yvH
The new interface's Add carbs leads with the amount in large type over a chart of how the meal will absorb, which redraws as the amount, speed and eaten time change. Favourite foods sit under it as chips, then the speed (Fast, Medium, Slow or Other with its own emoji and time) and when it was eaten (Now, 15 or 30 minutes or an hour ago, or an exact time). Warnings and Continue to the bolus screen are as before. Editing a carb entry from the Logbook uses the same screen. Choosing a speed after a favourite lets the favourite go but keeps its amount. The view model applied a favourite selection on the next run loop turn, which could reset an amount or speed set straight after it; it now applies it at once, with a regression test. The amount field follows the model whenever it doesn't already show that amount, so a favourite fills it in even while the field still has focus. An entry older than Loop's usual 12-hour window keeps its own time in the eaten picker rather than showing the clamped limit. Letting a favourite go resets the speed to Medium along with the absorption time, so a speed chosen before the favourite can't stay highlighted over a medium meal. The classic interface keeps the classic carb entry screen. This is part 4 of 6 splitting LoopKit#2621, and builds on parts 1 to 3. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QHnVP7ynB62LNuuYMy3yvH
Nutcasey
force-pushed
the
redesign-4-add-carbs
branch
from
November 1, 2026 20:59
3531385 to
f8b498e
Compare
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.
Part 4 of 6 splitting #2621. Builds on parts 1–3 (#2637, #2638, #2639). Review commit
f8b498e6.The new interface's Add carbs leads with the amount in large type, over a chart of how the meal will absorb. The chart redraws as the amount, speed and eaten time change. Under it:
Warnings, and Continue to the bolus screen, work as before. Editing a carb entry from the Logbook uses the same screen. The classic interface keeps the classic form.
Choosing a speed after a favourite lets the favourite go but keeps its amount.
CarbEntryViewModelapplied a favourite selection on the next run-loop turn, which could reset an amount or speed set straight after it. It now applies the selection at once, with a regression test.Differences from #2621: two fixes found while testing this part
Testing
On the
loopsimulator, through XCUITest, with before and after screenshots:LoopTests (450 run on this part, on
next-dev5ee95cc6): all pass exceptBolusEntryViewModelTests.testCarbEntryDateAndAbsorptionTimeStringand…String2, which fail the same way on plainnext-dev("12:00 PM" against "12:00"). Xcode's hosted test run stalls at test-host launch on this machine, so these ran in the app bundle under Xcode's simulator XCTest agent, with next-dev's test classes except the HealthKit-hostedDeviceDataManagerTests. Every part was built on its own, in order, on theloopsimulator.The series
#2621 is split into six PRs, in the order Pete suggested: statistics and Trends first, then the Logbook, then the home screen. Add carbs, the widget and Live Activity, and the appearance options follow as their own parts. Each part builds on the one before it and targets
next-dev(5ee95cc6, after #2635), so a PR shows the earlier parts' commits too. Review only the last commit of each PR (part 1 has two: Trends, then what came across from Statistics). #2621 stays open as the combined reference until the series lands.The six parts together match #2621 apart from the changes listed under "Differences from #2621" in each part.
Merging. Merged in order with merge commits, all six apply cleanly. With squash merges, each next PR needs a rebase onto
next-devonce the previous one lands, because it still carries the earlier part's original commit. I've checked that every one of those rebases applies cleanly and that the end result is identical to part 6. I'll rebase each PR as the one before it merges.Strings. Each part adds only its own catalogue entries, with their translations in Loop's languages, and fills in translations for the existing keys it starts using. GitHub's line diff of
Localizable.xcstringscan show deletions where Xcode's ordering interleaves new keys. Parsed as JSON, no part removes or rewrites any existing entry.🤖 Generated with Claude Code
https://claude.ai/code/session_01QHnVP7ynB62LNuuYMy3yvH