Repository navigation
docs(wallet): redesign the Send screen as one From/To form - #1111
Conversation
Adds a UX analysis, simplified requirements, a UX spec and ASCII wireframes for Wallet > Send: one form with a From section (wallet and a "Pay from" choice with Auto) and a To section (someone else's address, username or identity, or one of my wallets with Auto), a live Auto status line, one Summary card and Advanced sources inside the form. User stories SND-019..022 are added as gaps. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 59 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Records the user's decisions on the open questions. The four Platform fee strategies stay, with their labels and default, behind a collapsed "Fee options" row in the Summary card shown only in Expert view when an Advanced source or several recipients involve Platform. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
✅ Final review complete — no blockers (commit 99aef55) · triage: trivial · Phase 2 only (no Phase 1 for this repository) |
Renders wireframes W1–W14 as an interactive HTML page in the same visual style as the usernames redesign wireframes, linked from the design README. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
thepastaclaw
left a comment
thepastaclaw
left a comment
There was a problem hiding this comment.
Final validation — Phase 2 only (no Phase 1 for this repository)
The documentation-only redesign is coherent overall, but two specification gaps should be resolved before implementation. SND-019 summarizes Auto resolution too broadly compared with the destination-specific ordering, and destination Auto does not define what happens when its allocated address becomes used while the form remains open.
🟡 2 suggestion(s)
Review provenance
Source: reviewer 1: gpt-6.1-sol (agent: phase2-reviewer, role: general); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)
- Triage:
trivialbygpt-6.1-sol(effort low) — This pull request adds design documentation and user-story entries only, without changing application behavior or any critical code surface. - Phase 1 reviewers: not run (disabled for this repository)
- Fresh verifier:
gpt-6.1-sol— final-verifier; agentsol-verifier - Phase 2 reviewers:
gpt-6.1-sol— general (completed, effort low); agentphase2-reviewer
🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `docs/user-stories.md`:
- [SUGGESTION] docs/user-stories.md:545-547: Align SND-019 Auto ordering with the destination-specific rules
SND-019 says Auto pays from the same kind as the recipient and then falls back to Platform, then Core. That does not precisely describe the rules in `01-requirements.md` §4 and `02-ux-spec.md` §4.1: Core destinations try Core then Platform, Platform and Identity destinations try Platform then Core, and Shielded destinations try Shielded then Platform then Core. The story also omits that Shielded must never be used for a non-private destination. Because this catalog is intended to summarize the gap for implementers, its wording can lead to behavior that conflicts with the detailed specification. State the destination-specific candidate order, or explicitly link the story to the normative table.
In `docs/ai-design/2026-10-23-send-screen-redesign/02-ux-spec.md`:
- [SUGGESTION] docs/ai-design/2026-10-23-send-screen-redesign/02-ux-spec.md:101-111: Define how destination Auto handles an address that becomes used
Destination Auto must use an unused receiving address, but the spec says the address is fetched again only when the To wallet or kind changes and otherwise remains displayed. The pinned wallet integration confirms that `next_unused` is non-reserving: repeated calls return the same address until it is actually marked used. If another receive flow or an incoming payment uses that address while this form is open, the form can retain an address that no longer satisfies the stated unused-address invariant. Specify either a reservation and release lifecycle, or a final revalidation immediately before confirmation that replaces the address when it has become used.
| - The form has two sections, From and To. From is a wallet plus "Pay from": Auto, Core, Platform, Identity (when the wallet has identities), Shielded (when shielded sending is available) and Advanced (Expert view). Auto is the default. | ||
| - Auto pays from the same kind of balance as the recipient (Core address → Core, Platform address → Platform, private address → private balance), then falls back to Platform, then Core. It never spends identity credits, never unshields private funds for a non-private recipient, and never splits one payment across two balances. | ||
| - A line under Pay from says what Auto chose and how much that balance holds, and why when it fell back. The line updates as the recipient, amount or balances change. The confirmation repeats the chosen balance. |
There was a problem hiding this comment.
🟡 Suggestion: Align SND-019 Auto ordering with the destination-specific rules
SND-019 says Auto pays from the same kind as the recipient and then falls back to Platform, then Core. That does not precisely describe the rules in 01-requirements.md §4 and 02-ux-spec.md §4.1: Core destinations try Core then Platform, Platform and Identity destinations try Platform then Core, and Shielded destinations try Shielded then Platform then Core. The story also omits that Shielded must never be used for a non-private destination. Because this catalog is intended to summarize the gap for implementers, its wording can lead to behavior that conflicts with the detailed specification. State the destination-specific candidate order, or explicitly link the story to the normative table.
source: gpt-6.1-sol (phase2-reviewer: general)
| ### 4.2 Destination Auto (My wallets) | ||
|
|
||
| ``` | ||
| kind = source kind (Advanced source → its Core/Platform kind) | ||
| if source is Identity → Platform (SR-09) | ||
| if To wallet == From wallet: | ||
| Core → Platform, Platform → Core, Shielded → Platform | ||
| address = next unused receive address of `kind` in the To wallet | ||
| ``` | ||
|
|
||
| The status line shows "Getting a new address in Savings…" until the address arrives. The address is fetched again only when the To wallet or the kind changes (it stays the same while unused). |
There was a problem hiding this comment.
🟡 Suggestion: Define how destination Auto handles an address that becomes used
Destination Auto must use an unused receiving address, but the spec says the address is fetched again only when the To wallet or kind changes and otherwise remains displayed. The pinned wallet integration confirms that next_unused is non-reserving: repeated calls return the same address until it is actually marked used. If another receive flow or an incoming payment uses that address while this form is open, the form can retain an address that no longer satisfies the stated unused-address invariant. Specify either a reservation and release lifecycle, or a final revalidation immediately before confirmation that replaces the address when it has become used.
source: gpt-6.1-sol (phase2-reviewer: general)
TL;DR: A design for a simpler Wallet > Send screen: one form with a "From" part and a "To" part, an Auto choice on either side that says in plain words what it picked, and one summary of what will be sent and paid. Design documents only; no code changes.
User story
As a wallet user, I want to send funds by saying where they come from and where they go, without choosing between several send modes or opening hidden options, so that sending is quick and I can see exactly what will happen before I confirm.
Scenario
Actual behavior
The Send screen mixes several modes, scattered fee and route read-outs, and a separate "Advanced Options" form. Choosing a source clears an already pasted destination.
Expected behavior
One form: pick the wallet and a balance to pay from (or Auto), then someone else's address, username or identity, or one of your own wallets (with Auto). Each Auto shows a live line saying what it chose; one Summary card shows amount, fee and total; the button always says "Send".
Detailed discussion
Documents in
docs/ai-design/2026-10-23-send-screen-redesign/:01-requirements.md: inventory of today's screen, UX findings, requirements SR-01..21, acceptance criteria, deviations from the original brief (D-01..14) and dependencies.02-ux-spec.md: flows, Auto resolution rules (source fallback order per destination kind, destination address allocation), Max with Auto, conflicts when Auto is chosen on both sides, errors, locked wallets, accessibility and progressive disclosure.03-wireframes.md: ASCII wireframes W1–W14.docs/user-stories.md: SND-019..022 added as [Gap].Main deviations from the brief, all aimed at a simpler screen: the To section is a "Someone else / My wallets" switch instead of wallet options plus a manual field; the default To is "Someone else" (the literal default would produce a fee-only self-send); Auto never spends identity credits, never unshields for a non-private destination, and never splits one payment across balances; Advanced sources and multiple recipients are Expert view only. All four fee strategies are kept, behind a collapsed "Fee options" row in the Summary card, shown only in Expert view when an Advanced source or several recipients involve Platform.
Decisions
Q1–Q5 are resolved; the answers are recorded in the design README and
01-requirements.md§7.Dependencies
Builds on the Max semantics of #1107 (upstream quotes, pooled Core) and #1106 (Core→Shielded drain). Implementation is a follow-up.
Testing
Documentation only. The required CI checks do not run for documentation-only changes.
🤖 Co-authored by Claudius the Magnificent AI Agent
🤖 Generated with Claude Code