e2e/06_search_anchor.yaml now reaches the conversation and fails one step later, on the in-conversation match navigator.
Verified state
Run 2026-08-12 on an iPhone 17 Pro Max simulator, Release build carrying the change in #657:
Assert that id: conversation-row-conv-search-anchor is visible... COMPLETED
Take screenshot search-anchor-00-results.png... COMPLETED
Tap on id: conversation-row-conv-search-anchor... COMPLETED
Assert that id: search-match-nav is visible... FAILED
The hub half of this flow is fixed: the anchor conversation is found, is tappable, and opens.
That was #646, addressed in #657.
search-match-nav is a different surface — the match navigator inside the conversation — and has not been investigated at all.
It is not yet known whether this is a missing mock route, an accessibility-text mismatch like #648 and #658, or a real product gap.
Do not assume it is the same class as the previous two without checking the mounted hierarchy.
Useful technique
Dumping the testIDs actually mounted at the failing step settles this class of question far faster than reading code.
The Maestro debug artifact under e2e/_artifacts/debug/.maestro/tests/<run>/<flow>/screen-hierarchy/ contains a JSON hierarchy per step.
Two failure modes have already appeared in this suite and both look identical in the log: an element present but not matchable because a glyph or a Line <n>: prefix is part of its accessibility text, and an element genuinely absent because its parent view is not mounted.
What done looks like
06_search_anchor passes end to end, or the search-match-nav assertion is removed with a written reason if the surface it targets is not reachable in the mock.
e2e/06_search_anchor.yamlnow reaches the conversation and fails one step later, on the in-conversation match navigator.Verified state
Run 2026-08-12 on an iPhone 17 Pro Max simulator, Release build carrying the change in #657:
The hub half of this flow is fixed: the anchor conversation is found, is tappable, and opens.
That was #646, addressed in #657.
search-match-navis a different surface — the match navigator inside the conversation — and has not been investigated at all.It is not yet known whether this is a missing mock route, an accessibility-text mismatch like #648 and #658, or a real product gap.
Do not assume it is the same class as the previous two without checking the mounted hierarchy.
Useful technique
Dumping the
testIDs actually mounted at the failing step settles this class of question far faster than reading code.The Maestro debug artifact under
e2e/_artifacts/debug/.maestro/tests/<run>/<flow>/screen-hierarchy/contains a JSON hierarchy per step.Two failure modes have already appeared in this suite and both look identical in the log: an element present but not matchable because a glyph or a
Line <n>:prefix is part of its accessibility text, and an element genuinely absent because its parent view is not mounted.What done looks like
06_search_anchorpasses end to end, or thesearch-match-navassertion is removed with a written reason if the surface it targets is not reachable in the mock.