4.4 KiB
Requires UI/UX UAT approval from the maintainer
Screens and flows to review
The shared dialog restores access to operations protected by fresh password and enabled-TOTP proof. It uses the existing modal, keyboard, navigation and scroll-lock conventions. It is mounted for the dashboard and signer broker. This source patch does not authorize a live payment, credential migration, deployment, release build, signing or publication.
Use an isolated candidate and fixture/regtest operations for the walkthrough. Prepare password-only and TOTP-enabled accounts, a remembered session and a device-token session. Use disposable app credentials and identities. Each protected operation must require the actual node password even after device login or remembered-session restoration.
- Wallet send and Lightning channels —
/dashboard, wallet dialogs in/dashboard/apps/:id, and/dashboard/apps/lnd/channels. Start a fixture send or channel action in the existing dialog, review its details, submit, and enter fresh proof. Confirm one authorized operation and the existing success result. Cancel and verify no operation occurs. With funds proof disabled, check that the action succeeds without a prompt and that an ambiguous transport failure still does not replay it. - Application credential handoff —
/dashboard/appsand/dashboard/app-session/:appId. Launch an app with a credential handoff, enter fresh proof, then view/copy its fixture credentials and continue to the app. Spend longer than 30 seconds at the proof dialog to verify the short-lived app capability is minted afterwards. Cancel and close the underlying launch flow; check that credentials do not appear later. - Identity and signing —
/dashboard/web5,/dashboard/web5/credentials,/dashboard/app-session/:appId, and/nostr-signer. Request a fixture signature/export from an existing flow, authorize it, and confirm the correct identity and operation complete. Cancel or navigate while proof is checking; a late grant must not sign. Verify private messages, keys and capability tokens are absent from the shared dialog's summary. - Security settings, device pairing and backups —
/dashboard/settingsand their existing global dialogs. Change the session policy, create a disposable device token, or request a fixture backup. Complete fresh proof, verify the resulting state, and repeat with cancellation. Changing the funds preference must itself remain protected. - Paid content and recovery —
/dashboard/cloud/peers/:peerIdand content dialogs. Use fixture payment results, including a deliberately lost response. Verify no automatic second dispatch or proof prompt; explicit recovery must retrieve the existing paid result without paying.
For each flow check empty/required fields, loading, incorrect password, incorrect/already-used TOTP, rate limiting, cancelled/expired authorization, session expiry, success and unavailable backend. Open a second protected operation while the first prompt is visible: it must refuse without replacing the first operation. Change the underlying form while proof is pending and verify the submitted operation still matches the original displayed request.
Review desktop and phone widths, light/dark themes, keyboard focus and Escape, browser Back, nested-dialog stacking, and kiosk/remote input where the flow is available. Controls must remain reachable and cancellation must clear inputs.
Source evidence and remaining gates
FreshAuthorizationModal.test.ts mounts the shared dialog with the real RPC
client and mocked HTTP responses: 24 tests cover proof, immutable parameters,
single-use dispatch, credential-capability ordering, cancellation/late results,
lookalike errors, malformed grants, transport failures, and paid-file recovery.
Existing RPC client and Bitcoin-send component suites also passed (104 tests).
These are frontend fixture checks, not backend cryptographic, installed-node,
browser-layout, real payment, or maintainer acceptance.
The parent integration must run its backend HTTP/cryptographic regressions and complete the frontend typecheck. An overlapping whole-project typecheck in this worktree was stopped to avoid competing with the integration check; it did not produce a pass receipt. Maintainer UAT remains required before merge or deployment. Preserve source, artifact, installed and physical acceptance as separate qualifications.