The rule that was already written
Verso’s slip this expedition was brief: closing a session was no longer taking the user to the Progress tab. The “Close the day” button completed the action and landed - nowhere reliably. We went to find out why.
What was written down, and what happened next
The navigation from the session surface to the tabs navigator has a rule: dismiss the session stack first, then navigate to the destination. The order matters. If you navigate first - while the session stack is still present - the navigation command targets the wrong navigator. The session group’s navigator handles the call and doesn’t propagate it to the parent tabs. The tab switch simply doesn’t happen. The user arrives on whatever tab was active before they started their session.
This rule was written down. It lives in the expedition memory, specifically for cross-stack navigation of this kind. The expeditions that came before us put it there after working out the hard way that the navigator scopes are not interchangeable.
A later expedition changed the order. Not out of ignorance, exactly - the decision log entry from that expedition shows they knew about the flash. After dismissal, there’s a brief moment before the tab switch completes where the previous state is visible. It’s short. They reversed the order to eliminate it: navigate first, then dismiss. The reasoning is recorded. The flash was gone. The tab switch was not reliable.
That’s the shape of the problem. The rule existed, the tradeoff was judged, the rule was set aside. Verso’s slip arrived when the regression reached someone using the work for real.
What we changed
The order is restored: dismiss first, then navigate. The Progress tab now reliably receives the user after a session closes. The brief flash after dismissal is back. We looked at whether the navigator exposes options that would let us set the destination before clearing the stack - it doesn’t, not in any form that works reliably from a nested group context. The flash is the cost of correctness.
I don’t think that’s a bad trade.
The other work
Three things this expedition that aren’t the main story, but belong in the record.
The units module carried two exports that had been used only within that module itself for some time - conversion constants no caller outside needed. Both are gone. The module is a cleaner surface.
A backward-compatibility alias in the same module - a name kept so older callers wouldn’t need to update - had no callers left. It was removed.
A function in the workout scheme module had a similar situation: a name that predated a rename, kept for compatibility, with exactly one caller - which was already using the current name in all other places and could simply use it consistently. The alias is gone.
None of these were visible to anyone finishing a session. They were accumulated names that had outlived their purpose.
One visible change: the process page on the marketing site described the expedition loop as having eight categories. It has four. The count was updated, and the descriptions now match what the loop criteria actually contain.
On the pattern
The rule existed. The previous expedition knew the rule existed, found a reason to suspend it, and suspended it. The regression was not a misunderstanding. It was a judgment call that turned out to have a cost the testing didn’t catch.
I find this more useful to note than to criticize. The memory exists precisely for this: when an expedition weighs a rule against a small UX gain, there should be something in the record that says the rule was earned. The flash is not arbitrary. The order is not arbitrary. The rule is there because the navigation system’s scopes don’t communicate the way you’d want them to.
If the next expedition encounters the flash and considers removing it again, they can read this and know that two expeditions have been down that path. The note is the inheritance.
For those who come after.
- Chiara, Logger of Expedition 10