MPDX-9544 Frontend - Add validation to ensure the Requested Gross Salary for SOSA staff doesn't exceed their cap

[zweatshirt]

Description

• We don't want SOSA staff to be able to continue their form if their gross requested salary exceeds their cap.
• This needs to be done against their gross requested salary, and not their base requested salary.
  • Because of this, I chose not to do Formik field validation on the user input for their requested salary, as this can easily cause drift between the frontend and backend values and lock the user into an error state.
  • The alternative solution if we want to allow input field validation is doing the calculations in the frontend for validation instead of depending on API state.

Testing

• Use one of the test data emails that is SOSA and ensure that they cannot continue past step 3 if their gross requested salary exceeds their cap.
• Determine if the Alert is sufficient in notifying the user.

Checklist:

• I have given my PR a title with the format "MPDX-(JIRA#) (summary sentence max 80 chars)"
• I have applied the appropriate labels (Add the label "Preview" to automatically create a preview environment)
• I have run the Claude Code /pr-review command locally and fixed any relevant suggestions
• I have requested a review from another person on the project
• I have tested my changes in preview or in staging
• I have cleaned up my commit history

[github-actions]

Preview branch generated at https://MPDX-9544-frontend.d3dytjb8adxkk5.amplifyapp.com

[github-actions]

Bundle sizes [mpdx-react]

Compared against d15e969

No significant changes found

[zweatshirt]

Multi-Agent Code Review — PR #1770 (v2)

Verdict: APPROVED WITH SUGGESTIONS — No blockers. The v2 refactor cleanly addressed the previous round's two medium findings (Alert variant deviation + OverCapPerson field-name mismatch). Remaining items are non-blocking test-coverage gaps and minor stylistic polish.

Risk: 6/10 (MEDIUM) — 5 source files, 74 non-test lines, single-domain scope.

Agents: Architecture, Testing, Standards, UX, Financial Reporting.

Summary

Tier	Count
Critical (9.0+)	0
High Priority (8.0–8.9)	0
Important (7.0–7.9)	0
Medium (5.0–6.9)	2
Suggestions (<5.0)	7
Pre-existing	1

Top medium-priority items

1. Continue-button gating contract untested — useSosaBlockOnCap's markInvalid('over-cap') side effect (the entire reason the hook exists) is not asserted by any test. Carried over from round 1.
2. SOSA + spouse branch combinations untested — All new tests use hasSpouse={false}. The invariant blockOnCap = isUserSosa && overUserCap (not && overCapPerson !== null) is the most refactor-fragile line in the diff and has no regression net.

Both are non-blocking (severity 5) but would be quick wins.

What's confirmed good

• All 5 useCaps consumers verified aligned with the new raw-number interface (Receipt, useSubmitDialogContent use only combinedGross; the 3 over-cap consumers correctly wrap fields in formatCurrency() at the display boundary).
• Financial checklist: pass on every item (single source of truth = server, formatting at display boundary, USD-only, server-provided aggregations preferred, safe handling of undefined via formatCurrency's ?? 0).
• <Trans> {{ var: expr }} pattern matches 5+ precedents in the codebase.
• All four affected test files were observed to pass after the refactor.

[zweatshirt]

[Suggestion] **`useCaps` still has no dedicated unit test.** Now that the hook exports a public `OverCapPerson` interface and is consumed by 5 callers, a direct `useCaps.test.ts` would pin down: `combinedGross` math, `overUserCap` truth table, `overCapPerson` precedence (user wins over spouse when both over cap), and the null short-circuit when neither is over cap. Indirect coverage exists through three consumer tests, but the precedence rule isn't directly exercised.

Estimated ~40 lines via renderHook.

Flagged by Testing.

[zweatshirt]

[Suggestion] **Negative-Alert tests assert absence without anchoring to a positive render first.** The `waitFor(() => expect(queryByRole('alert')).not.toBeInTheDocument())` will pass on the first tick before the salary-calculation query resolves. A regression that delays the Alert past the initial render would slip through. Awaiting some other rendered element (e.g., a rowheader cell) before the absence assertion would catch that.

Flagged by Standards.

[github-actions]

AI Review Auto-Approval

Risk Level: MEDIUM (6/10)
Verdict: APPROVED_WITH_SUGGESTIONS (suggestions posted, no blockers)

This PR was auto-approved because:

• The multi-agent AI review determined it is medium risk
• No blocking issues were found
• All suggestions have been posted as review comments for the developer to consider

If you believe this PR needs human review, dismiss this approval and request a review manually.

[zweatshirt]

@canac Waiting for Grace or CD to respond with the proper alert message. I am curious what you think about this in terms of UI design. I didn't choose to go with input field validation (see PR description). Thank you Caleb

[canac]

I have a few suggestions, but the core logic looks good! Do you think we should hide the "Approval Process" card when the error message displays since they can't submit anyway?