Phase K left the Accounts screen with three stacked modules. A total-balance hero at the top, rotating sigil and all. A 30-day balance trend chart below it. Then at the bottom: a horizontally-scrollable daily-activity strip showing mint-in and mint-out markers per day, swipeable left or right along the timeline. That strip was the smallest viable surface for “show me what happened on which day.” It shipped. QA on my test iPhone passed the J→K→L→M arc. The strip was done.
Phase O’s brief was to replace it with a calendar.
What I had scoped
The conservative read of the brief: a compact month calendar in the same module slot, replacing the strip. One surface, one depth. The Accounts screen stays at one navigation level. Simpler to build, faster to ship, nothing new for the navigation stack to get wrong.
That was what I had scoped before the design session.
The deepening
It came mid-design. Not in a spec revision, not in a follow-up message. Mid-session, the brief changed.
“Click the calendar, full-screen. Click a day, day mode.”
That is three navigation levels where the brief had implied one. Level one: the Accounts screen, unchanged. Level two: a full-screen month calendar, entered by tapping the calendar surface. Level three: day mode, entered by tapping any date. Variant B, as it got labelled.
The case for reverting to the original scope was real. The compact calendar would have closed the brief as stated, faster. The case for taking Variant B was also real, and stronger: a compact inline calendar with no drill-down is navigation theatre. You see the month but can’t act on it. Banking apps go full-screen for a reason: the spatial layout needs full resolution to actually navigate. Day mode exists because the monthly summary alone is never enough. Variant B described the feature, not scope creep.
I took Variant B.
The three-level flow
Phase O shipped the full hierarchy. The Accounts screen kept its stacked-module layout: the hero, the trend chart, the calendar entry point. Tapping the calendar enters a full-screen month view, with enough room for the month grid at readable size and daily-activity markers visible at a glance. Tapping any day enters day mode: the detail surface for that date.
The daily-activity strip is gone. In its place: a calendar surface that affords actual navigation rather than horizontal scrolling through an undifferentiated timeline.
The branch shipped on 2026-06-16, shaped by device-QA findings #4, #7, and #8 from the first hands-on pass on my test iPhone.
What round-2 device QA found
Finding A8: Calendar → Day → Back popped past the calendar to Accounts.
Not Calendar → Day → Back → Calendar → Back → Accounts. One Back press, two levels up. The navigation stack was collapsing the intermediate level.
This is the class of regression that only surfaces on real hardware. The simulator does not exercise the same navigation timing and gesture handling. The round-2 pass is where it shows up: code-signed against the Apple Development identity, sideloaded onto my test iPhone. The fix is in the round-2 branch.
Why the regression argues for the scope decision
A8 only exists because there are three navigation levels. A compact inline calendar (one level) would produce no back-nav hierarchy, no A8, no round-2 fix branch.
That is not an argument for the compact calendar. It is an argument against it.
The regression surfaced a structural assumption in the navigation stack. It surfaced it in round-2 device QA, where it costs a fix pass. If Phase O had shipped the simpler surface and a later sprint had added full-screen and day mode on top of it, the same structural assumption would have surfaced then, in a hierarchy built on a design that hadn’t anticipated the depth. Retrofitting navigation levels is harder than designing them in from the start.
Taking the deepening mid-design meant one regression caught in round-2. Deferring it would have meant a harder structural rework when the feature eventually needed to grow. The back-nav bug is the receipt for the right call.
When to accept a mid-flight deepening
The condition for accepting: the deeper surface needs to serve the use case better than the scoped version, and “better” needs to be demonstrable, not gestural.
Full-screen month view plus day mode is better than a compact inline calendar because it affords real navigation. Monthly overview to orient. Day mode to act. The compact version stops at the overview. That is not the feature; it is half the feature.
The condition for reverting to the original scope: the deepening serves a different use case, adds surface for its own sake, or requires redoing work that doesn’t need redoing. None of those applied here. The strip was being replaced anyway. Variant B completed the replacement rather than just closing the brief.
The deepening was grounded in how the feature would actually be used. That is the test. When your own mid-flight change passes it, the right call is to take it rather than ship the smaller thing you already had ready.
Out of scope: the specifics of the A8 navigation fix. Out of scope: the broader round-2 QA arc, which covers brand fonts, a 20-palette theme library, and light mode, all device-verified on my test iPhone. This article covers the scope decision and what A8 reveals about it.
Where the calendar hierarchy stands
Three levels. Device-verified across two QA passes on my test iPhone. One known regression in the round-2 fix branch.
The Accounts screen is the entry point. The full-screen month calendar handles navigation; day mode is the detail surface. The daily-activity strip is gone.
The simpler surface would have closed the brief. It would also have required more work later to become what the feature needed to be. Taking the scope deepening when it arrived was cheaper, even with the round-2 regression as the cost. That was the right price to pay.
