Maestro flows: full audit, bug fixes, and happy/negative-path coverage expansion

[Copilot]

PR #6945 only added thin runFlow wrapper files and left all legacy flows unfixed, with no negative-path coverage, no cross-platform hardening, and changes outside flows/. This PR supersedes it with a complete audit and expansion — all changes scoped to flows/ only.

Bugs fixed in existing flows

• appsettings.yaml — broken selector btn_App_Backup} (stray }); space-prefixed ID view_ KeeperTelegram
• exportseed.yaml — same btn_App_Backup} typo; passcode was 1-2-3-4 but app PIN is 1-1-1-1 (would always fail auth gate)
• setpin.yaml — only 1 of 4 required digits re-entered after mismatch+clear; stray tapOn: 'Create' that couldn't succeed
• copywalletaddress.yaml — loop condition inverted: repeat while visible 'Address Copied Successfully' kept tapping copy while the success toast was showing, potentially looping forever
• subscription.yaml — after tapping btn_choosePlan, flow incorrectly tapped into the key management screen instead of the subscription screen

Robustness improvements

• receive.yaml, buyBTC.yaml — replaced unbounded repeat while icon_unconfirmed_0 visible polling loops (no termination guarantee) with extendedWaitUntil notVisible (60 s ceiling) or simplified direct navigation
• walletSetting.yaml — added assertions + back navigation; previously entered settings and left app in a broken state for subsequent flows
• viewwallet.yaml — first-run info modal is now dismissed conditionally (runFlow when: visible); removed hardcoded wallet-name text assertions that break after any rename or re-run
• send.yaml — annotated Android-specific camera permission conditional to clarify iOS behaviour

New negative-path flows

File	Scenario
login_wrong_pin.yaml	Wrong PIN → error message + Retry visible → recover
send_invalid_address.yaml	Non-Bitcoin string → assert amount screen never appears
send_empty_amount.yaml	Valid address, empty amount → assert fee screen never appears
send_cancel.yaml	Back at address-entry step → clean return to wallet screen
exportseed_wrong_pin.yaml	Wrong PIN on backup screen → Recovery Phrase never revealed
wallet_creation_cancel.yaml	Back mid-wizard → no partial wallet created
setpin_mismatch.yaml	Standalone mismatch test: error shown, clear works, correct re-entry accepted

New happy-path flows

• receive_address_display.yaml — receive screen + copy address + Address Copied Successfully toast
• appsettings_toggles.yaml — dark-mode toggle round-trip

Orchestration & documentation

• regression_full.yaml — single entry point that runs all major happy-path flows followed by all negative-path flows in sequence
• flows/COVERAGE.md — documents what is covered, what remains missing, and what cannot be reliably automated with Maestro alone (hardware signers, biometrics, QR scanning, real transactions, OS-level permission matrixes, clipboard verification, in-app purchase dialogs)

Original prompt

Create a new pull request in KeeperCommunity/bitcoin-keeper against branch feat/openspec-integration that fully addresses the user's Maestro testing request and supersedes the limited scope of PR #6945.

Repository focus:

• Work only in the flows/ folder.
• The existing flows are under https://github.com/KeeperCommunity/bitcoin-keeper/tree/feat/openspec-integration/flows.
• Do not add or modify files outside flows/.

User's required outcome:

• Final Maestro YAML test cases for the latest Bitcoin Keeper app.
• Include both happy-path and negative-path coverage.
• Cover as much of the latest app flow as can be realistically automated with Maestro.
• Review all existing legacy flows under flows/, fix broken/brittle YAML where needed, and improve reliability.
• Make the YAML as cross-platform as realistically possible for Android and iOS.
• At the end, clearly document what app coverage is still missing and what cannot be completed reliably with Maestro alone.

Important context from prior review:

• PR Add composed Maestro core-journey flows for Bitcoin Keeper #6945 only added thin wrapper flows and does NOT satisfy the user's requirements.
• Existing flows include Android-specific permission selectors and other brittle assumptions; improve these where possible.
• The user explicitly wants the final result to include audited/fixed flows plus broader coverage, not just orchestration wrappers.

Detailed requirements:

1. Audit every existing flow in flows/ and correct syntax or logic issues that would prevent Maestro execution or cause avoidable flakiness.
2. Keep all changes limited to flows/ only.
3. Add/expand practical happy-path flows for major capabilities already present or implied by current app coverage, including as applicable:
   • onboarding/new app setup
   • passcode creation and validation
   • login / unlock
   • wallet creation
   • wallet viewing
   • wallet settings and wallet details editing
   • receive flows
   • copy address flows
   • send flows
   • buy bitcoin entry flow
   • app settings
   • backup/export seed
   • version history
   • subscription entry flow
   • key management / health check / delete / settings
4. Add negative-path flows where realistic and supportable by current UI, such as:
   • passcode mismatch
   • wrong/invalid passcode confirmation
   • invalid send address
   • invalid/empty send amount
   • cancellation / back navigation cases
   • permission denial / permission conditional handling where possible
   • validation message checks
5. Prefer reusing stable selectors and flow composition, but do not hesitate to improve existing YAML structure where needed.
6. Make flows more robust against timing/animation issues using Maestro primitives appropriately.
7. Avoid introducing unverified claims of execution success. If environment constraints prevent fully running all flows, be honest in the PR summary and document assumptions.
8. Include a concise coverage summary in the PR description or changed files that tells the user:
   • what is covered
   • what remains missing
   • what cannot be reliably automated with Maestro alone

Deliverable expectations:

• The PR should clearly represent a serious expansion/fix of Maestro coverage, not a minimal wrapper change.
• The changes should be reviewable and organized, ideally with separate flow files for major scenarios and reusable composition where appropriate.
• Do not create OpenSpec or other metadata/docs outside flows/.

If possible, close the gaps identified in the review of PR #6945, especially:

• lack of negative-path coverage
• no legacy flow fixes
• no Android/iOS hardening
• changes outside flows/

Create the PR with a title that makes clear this is the fuller Maestro flow audit/coverage expansion.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: I want you to generate maestro test cases for bitcoin keeper app.

Assistant: I’m waiting for your response to the approval dialog so I can continue creating the new Maestro test cases.

User: @copilot Accepted Confirmation: Confirm agent session

Assistant: Started — I’ve kicked off the work to generate the new Maestro test cases for KeeperCommunity/bitcoin-keeper from feat/openspec-integration.

You can track progress here:
https://github.com/copilot/tasks/pull/PR_kwDOHBFs3s7Zg8kt?session_id=5100fc9e-9d6a-401b-abce-3be0faf0ea61

data:
  - title: "[WIP] Add new Maestro test cases for Bitcoin Keeper app"
    repository: "KeeperCommunity/bitcoin-keeper"
    url: https://github.com/copilot/tasks/pull/PR_kwDOHBFs3s7Zg8kt?session_id=5100fc9e-9d6a-401b-abce-3be0faf0ea61
    state: queued

User: olease cover all possible test cases using maestro

Assistant: I’ve already started the PR task on KeeperCommunity/bitcoin-keeper for generating Maestro tests.

Your latest scope update is clear: cover as many app flows as reasonably possible with Maestro. I can’t modify the already-running task in place from here, but the active r...

This pull request was created from Copilot chat.