Tap the daily-activity strip on the Accounts screen. It expands to a full-screen month calendar. Tap a day. The day view opens. Tap Back.
You’re on Accounts. The calendar is gone.
That’s A8. Round-2 device QA on AnF, 2026-06-19.
How the navigation got to three levels
Phase K rebuilt the Accounts tab into a stacked-module layout: total-balance hero with a rotating sigil, 30-day trend chart below it, scrollable daily-activity strip at the bottom. Each module was independent. The strip was a strip, a horizontal scroll of daily summaries.
Phase O changed the strip’s destination. CJ deepened the original ask mid-design: click the strip → full-screen calendar, click a day on the calendar → day mode. Three distinct levels. Two transitions. One screen origin.
That’s a legitimate deepening of the feature. It’s also the moment the navigation architecture needed to be explicit about what those three levels were, and it wasn’t.
What the stack saw
From NavigationStack’s perspective, the Accounts screen had two navigation events on top of it: calendar pushed, day pushed. Pop once: back to calendar. Pop again: back to Accounts.
That sequence is correct. A8 wasn’t the stack doing the wrong thing. A8 was that Back from the day view popped past the calendar and landed on Accounts directly. The expected intermediate step was skipped.
This class of bug arises when navigation depth and presentation depth diverge. A full-screen expansion can be wired as a fullScreenCover, a conditional subtree swap, or a NavigationLink, each with different Back semantics and different positions relative to the NavigationStack. When the presentation choice is made before the navigation model is declared, the wiring ends up carrying navigational semantics by accident rather than design.
The stack counted positions. The user counted levels. When those two numbers agree, nobody notices. When they diverge at a presentation boundary, which is exactly where Phase O added a level, the Back button does something the user didn’t ask for.
Navigation depth as state
The fix is to stop inferring navigation level from presentation mechanics and start declaring it.
The Accounts screen has three modes: base (the stacked-module view), calendar (full-screen month), day (single day detail). Those are named states, not stack positions. The transitions between them are explicit: base → calendar on strip tap; calendar → day on day tap; day → calendar on Back; calendar → base on Back.
Each back transition has a declared target. The target isn’t whatever is below on the stack; it’s a specific, named state. Once that’s true, a Back handler can implement the correct transition regardless of how the views are physically presented. It doesn’t matter whether the calendar is a push, a cover, or a conditional subtree. The navigation level is the authority; the presentation is a consequence.
Concretely: an enum with three cases and a binding in the Accounts view model. Tapping the strip sets the level to calendar. Tapping a day sets the level to day and captures the selected date. Back in day mode returns the level to calendar. Back in calendar mode returns the level to base. The SwiftUI view layer reacts to the enum; it does not drive it.
This is not a novel pattern. It’s the standard SwiftUI approach for complex navigation that Apple formalised with the NavigationStack redesign. The error in Phase O was implementing the expansion before specifying the state model, which meant the presentation choice carried navigational semantics it wasn’t designed to carry.
Why it took two rounds
Round-2 caught A8. Round-1 ran on AnF on 2026-06-16, across the J→K→L→M arc. A8 wasn’t there to find in round-1 because Phase O, which introduced the three-level structure, shipped in response to round-1’s own findings.
Round-1 surfaced findings #4, #7, and #8 on Accounts. Phase O addressed them. Phase O then introduced the three-level calendar navigation. A8 was a regression Phase O itself created; round-2 found it.
That’s not a QA process failure. That’s cause and effect. The structural point is what happens when the same shape appears on a different feature: a navigation level is added, a presentation choice is made, a Back destination gets surprising. Without a declared state machine, the diagnostic path is the same every time. Find it on device, trace the presentation wiring, fix the wiring. With a declared state machine, the transition matrix is enumerable before any device test runs.
What changed in round-2
Improving on the finding documented in Device QA found three regressions the simulator had approved them all: that article recorded A8 as one of three regressions caught in round-2. The fix shipped in the same branch. Calendar → Day → Back now returns to the calendar correctly on AnF.
What that article didn’t cover is the structural position: Phase O needed the state machine before the presentation decisions, not after. The round-2 branch corrected the wiring. The state machine as a design-time constraint is what prevents the next multi-level feature on Accounts from producing the same shape of bug.
Out of scope: the other A-series findings from round-2, the balance-module layout, the rearrangeable-module pattern, the categorisation logic.
The pattern
Three-level navigation isn’t exotic. A tab with a list of items leading to a detail view leading to a sub-detail is three levels. An Accounts screen with base, calendar, and day mode is three levels. Any time the level count exceeds two and at least one transition isn’t a standard NavigationLink push, you have a boundary where navigation depth and stack depth can diverge.
The default assumption is that NavigationStack handles it. That assumption is wrong as soon as a non-push presentation enters the flow. The safe assumption: declare the navigation levels first, pick the presentation primitives second. If the presentation changes later, the navigation model doesn’t.
A8 is the canonical case because the structure is minimal enough to reason about clearly: three levels, four transitions, one missing declaration, one wrong Back.
