[MPDX-10004] - Block savings fund transfers that would overdraw the account

[tjohnson009]

Description

Prevents savings fund transfers from taking an account balance below $0 (MPDX-10004).

Per Scott (via stakeholder Crystal): a transfer can never take an account below $0 — fund deficitLimits apply to salary, not savings fund transfers. Recurring transfers get a warning rather than a block, since their payments process in the future against future balances; each payment is enforced at processing time.

Behavior

• New one-time transfer — hard-blocked when the amount exceeds the source fund's available balance: field error ("Amount cannot exceed the available balance of $X") and disabled Submit. Comparison is at cent precision, fails closed if the fund's balance can't be resolved, and transferring the exact full balance is allowed.
• New recurring transfer — non-blocking warning showing the projected balance after the first scheduled payment.
• Edits (recurring only) — same non-blocking warning, so an over-balance recurring transfer can still be wound down or stopped.
• BalanceCard — the "Transfer From" button now gates on the same shared availableBalance helper (endBalance <= 0) instead of the old deficit-limit check, so the entry point and the form enforce the same rule.

The balance policy lives in one place (Helper/availableBalance.ts) with the $0 floor documented, including a warning about the two conflicting deficitLimit sign conventions found in the tree.

Not covered client-side (server-side enforcement question)

The form check can't catch a recurring transfer that overdraws in a later month, stacked pending transfers that jointly overdraw, or a balance that changed after page load. Whether SAA rejects these at processing time is pending confirmation with Ethan Tison — if it doesn't, a backend ticket is needed.

Checklist:

• All 162 tests across the 16 SavingsFundTransfer suites pass; new coverage for the one-cent boundary (blocked), exact-full-balance (allowed), deficit-limit funds (still blocked below $0), recurring/edit warning paths (submittable), and the edit wind-down flow
• eslint and tsc clean

🤖 Generated with Claude Code

[github-actions]

Preview branch generated at https://MPDX-10004-Block-Negative-Transfers.d3dytjb8adxkk5.amplifyapp.com

[github-actions]

Bundle sizes [mpdx-react]

Compared against df619f6

No significant changes found

[tjohnson009]

Pre-PR code review findings (multi-agent review of the initial implementation; all addressed in this PR unless noted):

1. Edit-flow deadlock — an over-balance recurring transfer couldn't be saved at all (even just to add an end date), with the error invisible when the amount field was untouched. Fixed: edits warn instead of block (matches Scott's ruling).
2. Fail-open validation — the check silently passed when the source fund wasn't in the loaded funds list (query error, group-filtered fund types). A pre-existing test was green only via this hole. Fixed: fails closed for one-time creates; test fixture corrected.
3. Recurring judged against today's balance — blocked legitimate future schedules, missed month-N overdrafts. Resolved by Scott: recurring warns on the first payment; per-payment enforcement is server-side.
4. Entry point / form rule mismatch — BalanceCard still gated its button on the old deficit-limit rule. Fixed: both use the shared availableBalance helper.
5. Float precision — a balance like 14999.9999999998 displays as $15,000.00 but rejected typing 15000. Fixed: cent-precision compare.
6. deficitLimit sign convention — the tree contained both "negative floor" and "positive magnitude" readings. Documented in the helper; not otherwise touched.
7. Test gaps — assertions that couldn't fail, no edit-mode coverage, unanchored boundary input. Fixed.
8. Server-side parity (open) — the client check can't catch stale balances, stacked pending transfers, or later-month recurring overdrafts. Pending confirmation with Ethan Tison whether SAA enforces the floor at processing time; backend ticket if not.

🤖 Generated with Claude Code