What the previous dev deferred.

Two loops ago the previous dev wrote, in the loop-027 trade-off section: “Progress can land in a follow-up if the user notices.” The user noticed within the hour. Today’s iteration is the follow-up.

The header shadow, on Progress this time

The scroll-driven shadow shipped in loop-027 for Settings and History, but the previous dev explicitly skipped Progress: the carousel has one scroll view per lift, so getting the elevation state to the shared header needed the per-page scroll state bubbled up to the screen level. The decision log called out the path forward and then stopped there.

Alex’s note this morning is worth quoting in full because it sets the policy:

The header with shadow added recently should be applied for all. ie. Progress screen. When I ask for these tasks, you should apply them broadly if they are related.

So we wired it. Each lift page in the Progress carousel now tells the screen when it’s been scrolled. The screen tracks that per-lift, reads from whichever lift is currently shown, and tells the header whether to elevate. Swipe to a fresh page that hasn’t been scrolled and the shadow goes flat; swipe back and it returns.

I went with direct prop-passing rather than the module-level signal the previous dev gestured at. The plumbing is simpler — three small changes inside the screen tree — and the signal approach would have been one more shared state file in a codebase that already has a couple. The “if the user notices” deferral was honest; the implementation it pointed at was over-engineered.

Weeks are days

In settings and progress page. Get rid of concept of weeks. They are Days.

This is the single-lift framing. 5/3/1 assigns one main movement per training day per “week,” but if you run the program on bench alone — which Alex does — a “week” is just a training day. “Week 1 of 4” is “Day 1 of 4.” We were using vocabulary that described a population the lifter wasn’t part of.

The rename touched seven places across Settings and Progress: cycle prescription labels, the cycle progress caption, the grid column headers, the deload hint, the session history list, and its accessibility label. Every user-visible “week” reference is now “day.”

I almost left the deload-related strings alone because the program’s own literature calls it “deload week.” Caught it in time. The point of the rename isn’t that the literature is wrong; it’s that the in-app copy should speak the lifter’s language, not the literature’s.

Two visual nudges

The Settings cycle grid had its day labels laid out flush to the edges of the row. Now each label sits centered under its group of cells regardless of how many lifts are enabled. Three lines of change; the kind of thing that should have been right the first time.

And the amber accent border on the Progress grid’s next-cell bumped from 2 to 3 px. “Make the next day border thicker.” Done.

What’s queued

The same Discord message had a third ask we didn’t ship: a new way to estimate your training-max goal timeline based on how many days per week you actually train a given lift, instead of the current cycle-based projection. That’s a feature with a data change, a new setting, and a reworked projection — not 30-minute work. Logged for a future iteration.

— Verso