Tapping Back from the Day view should return to the month calendar. It returned to Accounts instead. One navigation frame too many unwound on the first tap. The simulator had never flagged it. AnF, the device used for the first hands-on QA pass, found it immediately.
That is A8 in docs/qa/2026-06-18-round-2-findings.md. It is also an accurate summary of how the Accounts screen was built: across four iterations, each narrower in scope than the last, each more faithful to the intended interaction than the one before it.
Sprint 2: establish the data model
Sprint 2 replaced the placeholder Dashboard with a real AccountListView and the actual Accounts tab. The structure was a SwiftUI List: a total-balance hero at the top, account rows below it showing name, type badge, and balance, swipe-to-delete on each row, a + toolbar button for new entries.
The scope was narrow by design. No trend data. No activity. No calendar. The screen answered one question: what accounts exist, and what do they total? Getting that question answered in shipped code was the prerequisite for every question that followed. Real data, real navigation, real delete behaviour.
Two things had to be true before Phase K could add a trend chart: the account model had to exist, and the Accounts tab had to have a working address in the navigation graph. Sprint 2 established both. Nothing else was in scope.
That was 2026-06-14.
Phase K: rebuild for analysis
Phase K rebuilt the Accounts tab from a list into a stacked-module screen. The List was gone. In its place: a total-across-accounts hero with a rotating sigil at the top, a 30-day balance trend chart below it, and a horizontally-scrollable daily-activity strip at the base showing mint-in and mint-out categories.
Phase K was the destination of Phase J’s balance CTA. That CTA had to navigate somewhere worth landing; a flat account list was not it. The module stack was.
The trade was list legibility for analytical surface. Flat rows are readable at a glance: name, balance, done. A module stack requires more vertical engagement; the user orients to the hero first, moves down to trend, moves to the strip. The tradeoff was worth making because Phase J’s CTA framed Accounts as the place to understand your money, not just enumerate it. Understanding requires the trend and the activity. The list didn’t have them.
What Phase K did not do was go deep on any individual module. The activity strip scrolled through days horizontally. That was the right scope decision for Phase K: prove the module exists, prove the data surfaces, leave interaction depth for later.
That was 2026-06-15.
Phase O: deepen the activity strip
Phase K’s daily-activity strip was the input to Phase O. The brief was to convert the strip into a month calendar. Variant B was the design decision: tap the strip, get a full-screen month calendar; tap a day in the calendar, get a day view.
CJ deepened the original ask mid-design session. The original brief named a calendar view. What arrived was a three-level flow: the strip in the Accounts screen, a full-screen month calendar on tap, a day mode on day-tap. Three levels settled over the session rather than in the brief.
That mid-design expansion materially changed the Accounts screen’s navigation depth. Before Phase O, Accounts was one level deep from the tab bar. After: three levels inside the calendar interaction. The stack arithmetic got more complex. A8 was the consequence.
The Accounts screen itself became shallower at the strip level as a result. In Phase K the strip was a scrollable surface you read. In Phase O it became an entry point. The detail moved into the calendar stack; the strip became the doorway to it. Phase O only became possible because Phase K had shipped the strip and given it enough real usage to know what deepening meant.
Out of scope for Phase O: device verification. Device QA runs after the arc closes, not during design. The three-level flow shipped from simulation.
That was 2026-06-16.
First device pass: what the simulator had cleared
The first hands-on device QA pass ran the J→K→L→M arc together. The build was code-signed against the Apple Development identity. It was then built for the device and installed on AnF. Four things ran as a single package: Energy Dock nav, the Accounts screen, rearrangeable modules, the DNA sweep.
Device QA is a different instrument from the simulator. The simulator renders navigation flows and marks them correct when the view hierarchy loads; it does not always reproduce the runtime stack arithmetic. The first device pass found issues the simulator had cleared. That is the point of the gate: not to catch simulator bugs, but to catch the category of bug the simulator structurally cannot see.
The fix pass that followed was the first Accounts-specific correction loop grounded in device behaviour. It was not the last.
Round-2: correct the navigation model
docs/qa/2026-06-18-round-2-findings.md drove a dedicated branch. A8 was the calendar back-nav bug: Calendar → Day → Back returned to Accounts instead of returning to the calendar. The fix corrected the pop target.
Round-2 also shipped the theme work: brand fonts, a 20-colour palette library, light mode. Those were system-wide. They were verified on the Accounts screen as part of the same branch, but the Accounts-specific work in Round-2 was A8.
A8 is a correctness fix, not a feature. Sprint 2 through Phase O all added surface; Round-2 tightened existing surface to match the design intent. That distinction is worth keeping visible. Iterative builds accumulate surface faster than they accumulate correctness on that surface. Device QA is the mechanism for closing the gap.
All Round-2 changes were device-verified on AnF before the branch merged.
The sequence was not arbitrary
Four iterations. Four different questions.
Sprint 2: does the data model hold? Phase K: does the analytical surface read correctly? Phase O: how deep should the activity interaction go? Round-2: does the navigation stack match the design intent on device, not just in the simulator?
None of those questions could have been answered out of order. Phase K needed Sprint 2’s model. Phase O needed Phase K’s strip. Round-2 needed Phase O’s three-level flow to exist as a runtime target before A8 could present itself.
Each step was an explicit scope trade. Sprint 2 excluded analysis: analysis needs data. Phase K excluded interaction depth because the strip was too new. Phase O excluded device verification; the gate runs later. Round-2 excluded feature work because the Phase O correctness debt had to close first.
That is what “trading scope for fidelity” means in practice. It is not gradual refinement. It is deliberate sequencing: answer the lower-level question before you can see what the higher-level question even is. Phase O’s three-level flow was not in Sprint 2’s design. It emerged from Phase K’s strip having existed long enough to know it needed deeper interaction. A8 was not in Phase O’s scope. It emerged from the runtime behaviour of the three-level flow on hardware.
The next device pass will find the next A8. That is expected. The sequence continues.
