Symptom
Tier-3 handbook flow 25-restore-wallet.yaml started failing on every PR after the wallet-type screen copy was refreshed. The failure pattern is identical across runs:
- Logout from the home page succeeds (checkbox + Abmelden taps both fire —
maestro.log).
- Welcome page is reached and renders Step 1 (
Software-Wallet (App) + BitBox Hardware-Wallet cards visible — confirmed in _debug-25-restore-wallet-attempt-1/screenshot-⚠️-*.png).
- All three subsequent
repeat blocks (tap Start if Software-Wallet not visible, tap Software-Wallet if Neue Wallet erstellen not visible, tap Wallet wiederherstellen if Wiederherstellungs-Wörter not visible) silently skip — zero taps recorded across nine iterations.
- The terminal
extendedWaitUntil visible '.*Wiederherstellungs-Wörter.*' then fails after the 30s timeout.
Failure capture (welcome page step 1, still on screen at the final timeout):
_debug-25-restore-wallet-attempt-1/screenshot-❌-*.png in the handbook-captures artifact of the failing run.
Where it manifested first
Run 26791861991 on feat/dani-handbook-text-changes-tranche-a @ 5b686a4. The same flow was green on develop @ fff5035 (2026-06-01 14:34).
Hypothesis (not yet verified)
The three runFlow when: notVisible: conditions are skipping because Maestro's semantic-tree visibility check counts off-screen widgets as "visible". The welcome page wraps both Step-1 and Step-2 card groups in a Stack + AnimatedSlide (lib/screens/welcome/welcome_page.dart:74–135); the off-screen group stays in the widget tree at a translated offset. On Step 1 the off-screen Step-2 cards' Neue Wallet erstellen / Wallet wiederherstellen titles are in the semantic tree, so notVisible evaluates false and the conditional tap never fires.
If true, the same dynamic existed before the copy refresh — but the previous flow apparently slipped through. Either an animation-timing change has tipped the boundary, or the new (longer) subtitle alters layout timing enough that one of the assertions completes/fails on a different frame than before.
Suggested resolution direction
Stop relying on regex text-matching of card titles for these handbook navigation steps. Instead, give the two WelcomeCard instances explicit Semantics(identifier: …) wrappers (welcome-software-wallet, welcome-bitbox, welcome-create-wallet, welcome-restore-wallet, welcome-debug-auth) and target them in the Maestro flow with tapOn: id: — the same pattern already in use for wallet-logout-confirm-checkbox (lib/screens/settings/widgets/settings_confirm_logout_wallet_sheet.dart) and home-terms-link (lib/screens/home/home_page.dart:76).
That makes the taps deterministic regardless of which animation half-state the layout is in, and removes the substring-overlap surface entirely (the new subtitle "Ich möchte eine neue Wallet erstellen oder meine bestehende Wallet (z.B. Aktionariat) wiederherstellen." overlaps several of the regex match targets).
Out of scope for this issue
feat/dani-handbook-text-changes-tranche-a (PR #635) does not introduce the dynamic — the welcome-page widget code is unchanged on develop since the last green Tier-3 run. The copy refresh just happens to be the change in flight when the flakiness surfaced. PR #635 has all required checks green; Tier 3 is not a required check on the branch protection ruleset, so this issue is not a merge blocker.
Symptom
Tier-3 handbook flow
25-restore-wallet.yamlstarted failing on every PR after the wallet-type screen copy was refreshed. The failure pattern is identical across runs:maestro.log).Software-Wallet (App)+BitBox Hardware-Walletcards visible — confirmed in_debug-25-restore-wallet-attempt-1/screenshot-⚠️-*.png).repeatblocks (tap Start if Software-Wallet not visible,tap Software-Wallet if Neue Wallet erstellen not visible,tap Wallet wiederherstellen if Wiederherstellungs-Wörter not visible) silently skip — zero taps recorded across nine iterations.extendedWaitUntil visible '.*Wiederherstellungs-Wörter.*'then fails after the 30s timeout.Failure capture (welcome page step 1, still on screen at the final timeout):
_debug-25-restore-wallet-attempt-1/screenshot-❌-*.pngin thehandbook-capturesartifact of the failing run.Where it manifested first
Run
26791861991onfeat/dani-handbook-text-changes-tranche-a@5b686a4. The same flow was green ondevelop@fff5035(2026-06-01 14:34).Hypothesis (not yet verified)
The three
runFlow when: notVisible:conditions are skipping because Maestro's semantic-tree visibility check counts off-screen widgets as "visible". The welcome page wraps both Step-1 and Step-2 card groups in aStack+AnimatedSlide(lib/screens/welcome/welcome_page.dart:74–135); the off-screen group stays in the widget tree at a translated offset. On Step 1 the off-screen Step-2 cards'Neue Wallet erstellen/Wallet wiederherstellentitles are in the semantic tree, sonotVisibleevaluates false and the conditional tap never fires.If true, the same dynamic existed before the copy refresh — but the previous flow apparently slipped through. Either an animation-timing change has tipped the boundary, or the new (longer) subtitle alters layout timing enough that one of the assertions completes/fails on a different frame than before.
Suggested resolution direction
Stop relying on regex text-matching of card titles for these handbook navigation steps. Instead, give the two
WelcomeCardinstances explicitSemantics(identifier: …)wrappers (welcome-software-wallet,welcome-bitbox,welcome-create-wallet,welcome-restore-wallet,welcome-debug-auth) and target them in the Maestro flow withtapOn: id:— the same pattern already in use forwallet-logout-confirm-checkbox(lib/screens/settings/widgets/settings_confirm_logout_wallet_sheet.dart) andhome-terms-link(lib/screens/home/home_page.dart:76).That makes the taps deterministic regardless of which animation half-state the layout is in, and removes the substring-overlap surface entirely (the new subtitle "Ich möchte eine neue Wallet erstellen oder meine bestehende Wallet (z.B. Aktionariat) wiederherstellen." overlaps several of the regex match targets).
Out of scope for this issue
feat/dani-handbook-text-changes-tranche-a(PR #635) does not introduce the dynamic — the welcome-page widget code is unchanged on develop since the last green Tier-3 run. The copy refresh just happens to be the change in flight when the flakiness surfaced. PR #635 has all required checks green; Tier 3 is not a required check on the branch protection ruleset, so this issue is not a merge blocker.