[jvsena42]

Companion to synonymdev/bitkit-android#1763 and synonymdev/bitkit-ios#1198. Both PRs send an on-chain BIP21 with an amount the wallet can pay straight to the review screen, skipping Amount. send.e2e.ts still drove the Amount step in two @ios_gate cases, and both platforms' e2e gate picks up this branch because it has the same name as the app PRs.

• @send_1: after AddressContinue for bitcoin:…?amount=0.0001, the spec now expects ReviewAmount-primary showing 10 000. On Android, Back from that review screen opens Amount with 10 000, and a second Back returns to the recipient field. On iOS, the review screen was pushed from manual entry, so one Back returns to it.
• @send_2: unified2 (on-chain 0.0002 with a 200 000 sat Lightning invoice above the Spending balance) now opens the review screen at 20 000 directly. The AssetButton-savings and ContinueAmount steps are removed.

Other cases in the spec are unchanged: plain addresses, amountless BIP21, BIP21 with an expired Lightning invoice, and unified invoices whose Lightning part has an amount all keep their routes.

Checks

• prettier --check and tsc --noEmit are clean for the spec.
• eslint reports one existing prefer-const error on amtAfterUnified3. It is also on main and was left as is.
• Not run locally against a device. The app PRs' e2e gate runs it.

🤖 Generated with Claude Code

[talosmachina]

No findings. Updates @send_1 and @send_2 in send.e2e.ts to expect the review screen when an on-chain BIP21 carries an amount the wallet can pay, matching synonymdev/bitkit-android#1763 and synonymdev/bitkit-ios#1198. Reviewed 1b28071, light tier, static.

Build skipped: talos-pr-run could not check the author's permission on this repo (HTTP 403) and fails closed, so tsc, prettier and eslint were not run here.

What I checked, and 4 candidates I ruled out

Read in full: test/specs/send.e2e.ts; helpers elementByIdWithin, verifyAmountToSend, enterAddress, typeAddressAndVerifyContinue, dragOnElement in test/helpers/actions.ts.
Traced against the app PR heads: bitkit-android 1d280b6 (AppViewModel.onScanOnchain, openOnchainConfirmForInvoiceAmount, SendSheet.backFromConfirm) and bitkit-ios cc8fce9 (PaymentNavigationHelper.onchainInvoiceRoute, SendEnterManuallyView.handleContinue, SendConfirmationView.navigateToAmount).

Ruled out

• @send_1 Back count differs per platform: Android sets canReturnToAmount, so Back from Confirm replaces it with Amount (popUpTo<Confirm> inclusive) and a second Back reaches the recipient field; iOS appends .confirm to the manual-entry path, so one Back pops to it. The driver.isAndroid branch matches both.
• @send_1 amount not payable: savings hold 15 000 after receiveOnchainFunds, the URI asks 10 000, coin selection is Autopilot by default, so both apps take the direct route rather than Amount.
• @send_2 unified2 still routed as Lightning: on Android extractViableLightningInvoice drops the 200 000 sat invoice when canSend fails against ~7 000 in Spending, leaving payMethod = ONCHAIN and amount = 20 000, which opens Confirm; on iOS onchainInvoiceRoute returns .confirm with no contact context. The removed AssetButton-savings and ContinueAmount steps would now fail.
• Swipe before coin selection on iOS: the new isPreparingOnchainSend gate disables the swipe while coins and fee are computed, and dragOnElement does not wait for enabled. I could not show the window outlasts the helper's settle time on the local stack, so it is not a finding; the iOS gate run will show it.

CI: this repo runs no checks on the PR. The spec runs only through the app PRs' e2e gate (e2e-branch resolves to this branch); on bitkit-android#1763 the send shard is pending, and the iOS gate on bitkit-ios#1198 has not run yet.

Merge confidence: 4/5, the only run of this spec (the app PRs' send shards) has not finished, and on main it holds only once both app PRs have merged.