[USCMig]

Summary

Groups can now schedule payments that repeat, such as payroll, rent or subscriptions. Each one is still approved like any other payment. Stacked on #42 (share repair).

• Scheduled payments card on Home, with Schedule a payment. A schedule holds:
  • the payments, one or a batch;
  • a reason;
  • how often it repeats (week, 2 weeks, month, 3 months or year);
  • the first date;
  • its approvers.
• Every member sees each schedule, its next date, when it was last sent and which dates were skipped. Only its author can stop it.
• On each date the author's app asks the approvers through wallet_send. Each approver's checks, the group's rules and automatic approval within a spending limit all apply unchanged. With a limit, trusted payees and auto-approving members, a schedule pays without anyone clicking.

How it works

• Records: three new group record kinds, Schedule, ScheduleStopped and ScheduleRun, in core/src/polls.rs. Older versions keep and skip them.
• Schedule view: core/src/schedules.rs works out each schedule:
  • only the author's records count;
  • months are counted on the calendar, falling back to the month's last day;
  • there is a 3-day grace period, and later dates show as missed. Only the latest 12 missed dates are listed, so a schedule started long ago doesn't step through years of dates.
• Commands: commands/schedules.rs adds list_schedules, due_schedules, create_schedule, stop_schedule and record_schedule_run.
  • Creating a schedule checks the payments, the approvers (the author, plus enough for the threshold) and the date. It also runs the same rules check a send gets, via the new commands::rules::check_payments.
  • A recorded run must fall on one of the schedule's dates, and only once.
• Scheduler: src/Scheduler.tsx, mounted in the unlocked layout, asks for each due payment once per date and one payment per group at a time.
  • Which ceremony each date started is kept in the encrypted ceremony history (scheduleStarts), and the scheduler waits for that history to load after unlock.
  • A failed payment is asked again by hand. A payment that couldn't start (for example, the wallet wasn't synced) is retried after 10 minutes.
  • Runs are recorded when the send completes, and again on the next minute's check if that was missed.

Testing

• Core unit tests: calendar months (the 31st, leap years), dates, grace and missed dates, author-only stop, and long-ago starts.
• tests/group_schedules.rs: two apps over a real frostd.
  • A schedule reaches the other member.
  • Only the author's app sees it as due, can record runs or can stop it.
  • The approver and date rules are enforced.
  • A trusted-payees-only rule refuses a schedule to an untrusted address.
• vitest:
  • schedules.test.tsx: making a schedule, the card's details, stopping, and the delay-rule block.
  • scheduler.test.tsx: asked once, then recorded sent.
  • scheduler-retry.test.tsx: a start error is shown and not retried at once.
• cargo clippy --workspace --all-targets -D warnings and cargo test --workspace pass; vitest passes 60 of 60.

🤖 Generated with Claude Code