[thebrandonlucas]

Stack position: 11 of 13 in the look-and-feel stack. Base: feat/cli-look-10-qr (#109).

Problem

A settled Lightning payment, the moment a payment tool exists for, ended on the same ✓ as any finished step. The closing line also printed above the payment's ~30-line record, so it scrolled off screen right when the payment settled.

Behavior

On a terminal, a payment wait that ends completed closes with:

⚡ Payment 44444444-4444-4444-8444-444444444444 completed · 4s

• The bolt is bold yellow. A ready invoice (not yet paid) keeps ✓ Payment … ready, because nothing was paid yet.
• In ASCII it is ok, as ✓ already was. Redirected stderr has no closing line, as before.
• This is the only emoji in the CLI's vocabulary, as the plan decided.
• Order: the closing line now prints after the payment's record, so the outcome is the last thing on screen. For a ready invoice with --qr, the order is the record, then ✓ … ready, then the code. --json and piped output are unchanged. Hiding or shortening the record behind a --detail flag was considered and set aside, because it would change what every human payments command shows.

Try it on staging

Setup: Try a pull request on staging (added by #97). This creates a receive invoice (--execute): pay it from another test-network wallet to see the bolt. Find a wallet ID with voltage wallets list --account me.

voltage payments receive --account me --wallet WALLET_ID --currency btc --kind bolt11 \
  --amount 1000 --unit sats --qr --wait completed --timeout 600 --execute

Expect: once you pay it, the payment record, then ⚡ Payment … completed · … in bold yellow as the last line.

voltage payments receive --account me --wallet WALLET_ID --currency btc --kind bolt11 \
  --amount 1000 --unit sats --qr --execute

Expect: the record, then ✓ Payment … ready · 0s (no bolt, because it's only ready), then the QR code last.

Validation

• cargo fmt --check, cargo clippy --locked --all-targets -- -D warnings, cargo machete --with-metadata, cargo test --locked (168 unit and 131 integration tests), and python3 scripts/check-coverage.py all pass.
• A unit test checks the closing symbol: completed gives a bold yellow ⚡, ready gives a green ✓, and both are ok in ASCII. The PTY tests now expect ⚡ Payment … completed in the timeline and wait tests, with its exact bold yellow sequence. A new test with every stream on a terminal checks that the record comes first and the ⚡ line is last, and the ready-invoice test checks the record, then ✓ ready, then the code.
• CRAP: 0 of 762 measured functions at or above 20. The highest is 18.00 (src/cli.rs endpoint, untouched).

Docs

docs/reference/output.md and CHANGELOG.md.

[tee8z]

Approved 6faa0ec against feat/cli-look-10-qr (#109 d674fb9), on its own diff. closing() draws the bolt only for Outcome::Completed. A failed payment goes through unsuccessful, so it gets no bolt. reached uses notice_line, so --quiet and redirected stderr leave it out, and it never reaches stdout or JSON. The record is now written before the closing line, so a failed write prints no closing line. The tests and output.md match.

This PR builds on #109, whose expiration P1 still blocks the stack.

Nonblocking:

• When --qr implies --wait ready on a receive that has already completed, the order is the record, ⚡ … completed, then "Scan to pay" with a QR for an invoice that is already paid. Skipping the QR on Completed would be clearer.
• ⚡ is East Asian Wide, so its width varies by terminal.

Validation on this head, in nix develop: cargo fmt --check, cargo clippy --locked --all-targets -- -D warnings, cargo machete --with-metadata, cargo test --locked (184 unit, 140 integration) and python3 scripts/check-coverage.py passed. CRAP: 798 measured functions, none at or above 20, highest table at 17.00. CI is green.

[tee8z]

Re-approved a0ab94e, a rebase onto #109 8280881. The patch matches 6faa0ec, which I approved; only context lines from #109's new qr::check changed. With #109's P1 fixed, nothing in the stack below blocks it now.

Validation on this head, in nix develop: cargo fmt --check, cargo clippy --locked --all-targets -- -D warnings, cargo machete --with-metadata, cargo test --locked (186 unit, 141 integration) and python3 scripts/check-coverage.py passed. CI is green. I did not run the CRAP report for this re-review.