[MPDX-9531] Swap spouse salary request fields

[canac]

Description

When the spouse created the effective salary request, the fields will be swapped from the perspective of the current user. This PR swaps them back.

MPDX-9531

Related backend PR: https://github.com/CruGlobal/mpdx_api/pull/3309

Testing

• Login with the test account (this account is linked to Mickie)
• Check that the dashboard shows Minnie as having $40K Requested Salary and Mickie as having $30K
• Impersonate caleb.cox@cru.org (my account is linked to Minnie)
• Check that the dashboard shows Minnie as having $40K Requested Salary and Mickie as having $30K

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://9531-swapped-salary-request-spouse.d3dytjb8adxkk5.amplifyapp.com

[github-actions]

Bundle sizes [mpdx-react]

Compared against 2f90b0b

No significant changes found

[canac]

Multi-Agent Review — PR #1761

Verdict: CLEAN — no blockers, no Important/Medium findings.
Risk: 8/10 (HIGH — graphql + multiple component files, mechanical fix)
Agents: Architecture, Testing, Standards, UX (4)

Summary

Targeted, correct fix for swapping user/spouse salary fields when the spouse initiated the request. Code traces cleanly in both useLandingData.ts and SalarySummaryCard.tsx. Test coverage extended to both the component (SalarySummaryCard.test.tsx) and the landing hook path (NewSalaryCalculatorLanding.test.tsx). Redundant ?. cleaned up. personNumber is required per schema, so the undefined === undefined edge case is moot.

Suggestions (informational, do not block)

• Duplicated ownRequest swap logic — src/components/HrTools/SalaryCalculator/Landing/useLandingData.ts:157-170 and src/components/HrTools/SalaryCalculator/Summary/SalarySummaryCard.tsx:21-28 both reimplement the same predicate + 4-field swap. Two callsites is borderline; if a third surface needs the swap, consider extracting a small projectForViewer helper into SalaryCalculator/Shared/. Severity 4.0.

Standards Checklist

All items PASS. Codegen, named exports, id selections, no any, no debug output, test colocation — all clean.

Financial Checklist

N/A — no arithmetic, rounding, or currency-mixing changes. Domain agent (Financial Reporting) skipped because the file lives under HrTools/SalaryCalculator/, not Reports/SalaryCalculator/.

[canac]

Multi-Agent Review (Quick) — PR #1761

Verdict: CLEAN — no findings at severity ≥ 5.
Risk: 8/10 (HIGH — file-pattern based; mechanical fix limited to HrTools/SalaryCalculator)
Agents: Testing, Architecture, Standards (3, sonnet)

Summary

Follow-up review after addressing the prior round's feedback:

• Tests added in NewSalaryCalculatorLanding.test.tsx cover both own-request and spouse-request paths via getAllByRole('cell') cell-array assertions matching the RequestedSalaryCard.test.tsx convention.
• LandingTestWrapper now exports its props interface and supports hasSpouseApprovedCalculation.
• The redundant inline ?. chains in SalarySummaryCard.tsx were dropped.
• Cell-content verification removed from the older heading-based spec in favor of the broader cell-array assertion.

Findings

All three agents traced the swap math through both useLandingData.ts and SalarySummaryCard.tsx and confirmed every expected cell value in both new tests is correct. useMemo dependency array on useLandingData.ts:255 is complete. No N+1 or waterfall introduced.

Standards Note (informational, not in diff)

SalarySummaryCard.test.tsx:66 — the GqlMockedProvider generic omits EffectiveSalaryCalculation: EffectiveSalaryCalculationQuery. Pre-existing setup; this PR makes the gap more visible because the new swap test exercises that mock key. The mock is still type-checked at the variable declaration via DeepPartial<EffectiveSalaryCalculationQuery['salaryRequest']>, so practical risk is low. Optional cleanup in a follow-up.

Standards Checklist

All PASS. yarn lint:ts clean. Named exports, id selections on both queries, no any, no debug output, no new Date(), test colocation correct.

[canac]

@wjames111 Sorry, AI calls this high-risk for some reason

[wjames111]

Looks great! My only gripe is that there's multiple places where spouse vs user is checked throughout this PR. Some might be unavoidable but where possible it would nice to have consolidated.