[USCMig]

Stacked on #37 (group rules), and through it on the earlier PRs. Merge those first; until then this diff also shows their changes.

Summary

Delay with veto, a new group rule. Payments of at least an amount (together, in one transaction) have to be announced first, and can be sent only after a wait in which no member vetoed them.

1. Announce. The send form offers Announce it instead of Review payment for such a payment. That starts a payment poll, reusing pay if agreed.
2. Veto. Any member vetoes by choosing Don't pay, and the veto holds for as long as they keep that answer. Nobody has to choose Pay.
3. Send. Once the wait (1 hour to 30 days) has passed with no veto, the member who announced it sends it from Votes, with the usual approvals.

The wait runs on each member's own clock

• Arrival times are recorded. The group log now notes when each entry arrived (GroupLog.received).
• An announcement dates from when this app saw it. PollView.announced_at is the later of that arrival time and the time its author wrote on it.
• Every member gets the full wait. Each app counts the wait from when it received the announcement, so backdating gains nothing.
• Approvers who see it later wait longer. An approver whose app received the announcement later refuses until its own wait has passed, which is the point.

How it's enforced

• One decision, commands::rules::poll_permits, says whether a poll's payments can be sent. Under a delay rule, it requires the wait to have passed with no veto (rules::announcement_ready). Otherwise it requires the group's agreement, as before.
• Sender (wallet_send): refuses a poll that isn't ready, and a large payment without a poll (Broken::NotAnnounced).
• Approver (the gate): refuses an announcement that isn't ready on its own clock, and an unannounced large payment, including one whose poll it doesn't have.
• Approvals screen: shows "Announced … 30 hours ago, past the group's 1 day wait, and no member vetoed it."

Changes

• Core
  • rules.rs: Delay, delay_for, announcement_ready and NotYet; Broken::NotAnnounced; check takes an announced flag; validity limits on the delay.
  • polls.rs: GroupLog.received, insert_received and received_at; PollView.announced_at.
  • polls.rs: the poll's rules are boxed. They pushed Message::Record over clippy's large-variant limit; serialization is unchanged.
• App
  • polls.rs: records arrival times when writing and receiving.
  • rules.rs: poll_permits.
  • wallet.rs: sends a poll only when permitted, and tells the rules check it's announced.
  • signing.rs: the delay check in check_poll, and announced passed to the rules check.
• Frontend
  • The delay option in Propose rules.
  • Announce it in the single and batch send forms, and Send all disabled under a delay.
  • Announcement states in Votes: waiting (and until when), vetoed (and by whom), or ready.
  • The announcement line in Approvals.
• Docs: user guide (Rules), VOTING.md, README, CHANGELOG, TODO.md.

Testing

• cargo clippy --workspace --all-targets -- -D warnings
• cargo test --workspace
• tsc, then vitest (44 tests)
• Core tests:
  • large_payments_wait_for_their_announcement_and_any_veto_stops_them
  • a_poll_is_announced_when_this_device_got_it_whatever_time_its_author_put_on_it
  • Delay validity limits.
• App test: an_announced_payment_waits_out_its_delay_and_any_veto_stops_it.
• Devnet (NU7), tests/devnet_send.rs, which passed:
  1. A one-hour wait for payments of 0.5 ZEC or more is adopted by poll.
  2. 0.6 ZEC without an announcement is refused.
  3. The announced 0.6 ZEC is refused as too soon ("can be sent in 60 minutes").
  4. After Bob vetoes, it's refused as vetoed.
  5. A rules poll replacing those takes effect, and the rest of the run passes.
  • Waiting out a real hour isn't practical in the test, so the ready path is covered by the unit tests.
• Frontend tests:
  • Proposing a delay rule.
  • Announce it replacing review.
  • An announcement waiting, then vetoed, then ready to send.
  • The announcement line in Approvals.

🤖 Generated with Claude Code