[MPDX-9574] - Show required fields on load in PDS Goal Calculator

[wjames111]

Description

• Required fields in the PDS Goal Calculator Setup step now display their validation error (red border + helper text, e.g. "Goal Name is a required field") immediately on load, instead of staying silent until the user touches them.
• Removed the touched/empty-value gate in the PDS-only AutosaveTextField so the underlying schema error surfaces on first render.
• Made Benefits optional in the Setup schema (was conditionally required for non-Part-time staff). The positive-number check still applies if a value is entered.
• Updated AutosaveTextField tests to assert the new on-load behavior.

Related ticket: MPDX-9574

Testing

• Go to the PDS Goal Calculator and create a new goal (or open one with an empty Goal Name).
• On the Setup step, confirm that empty required fields (Goal Name, Employment Status, Pay Type, Pay Rate, Hours Worked when Hourly) show their red error state and required-field helper text on load — no need to click into them first.
• Confirm that Benefits does NOT show a required-field error when empty, regardless of Full-time / Part-time status.
• Enter a negative value into Benefits and confirm the "Benefits must be a positive number" error still appears.
• Fill in the required fields and confirm errors clear and the Continue button enables as expected.

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]

Bundle sizes [mpdx-react]

Compared against 7a8f99f

No significant changes found

[wjames111]

Multi-Agent Code Review — APPROVED WITH SUGGESTIONS

Risk: LOW (2/10) — small validation behavior change scoped to PDS Goal Calculator.
Verdict: No blockers. 1 medium finding + several lower-priority suggestions.
Agents: Architecture, Testing, Standards, UX, Financial Reporting (5 agents, full debate round).

Headline finding

With this PR, benefits is the only required-for-completion field that no longer renders a field-level error when blank, while pdsCompletion.ts:25 still gates Setup completion on benefits > 0 for non-PartTime. Every other required field (name, status, salaryOrHourly, payRate, hoursWorkedPerWeek) now surfaces its error on load — benefits is the orphan. See the inline comment on SetupStep.tsx:68 for the suggested fix paths.

What's working

• All downstream benefits consumers are null-safe (OtherExpenses.ts:47, pdsCompletion.ts:25, PdsSummaryTable.tsx:139, otherBreakdown.tsx:89). No financial-correctness regression.
• Standards checklist: clean pass — named exports, i18n via t(), no any, no console.log, no new Date(), no unused imports.
• Removing the touched state brings the PDS AutosaveTextField into alignment with sibling SalaryCalculator/Autosave/AutosaveTextField and GoalCalculator/.../Autosave/AutosaveTextField, neither of which had a touched gate. Net debt: better.
• DesignationSupportCalculationUpdateInput.benefits is already InputMaybe<Float>, so the server accepts null — schema relaxation is server-compatible.

---

Findings on Related Files (Not in This PR)

These findings reference files outside the PR diff and cannot be posted as line comments.

[Medium 5.5] src/components/HrTools/PdsGoalCalculator/Setup/SetupStep.test.tsx — Missing positive test for the schema change

• The Yup schema for benefits was changed from conditional-required to always-optional. The existing test at SetupStep.test.tsx:355 uses benefits: null but only asserts the field is visible, never asserts it does NOT render aria-invalid='true' on load. A future regression that re-introduces .required() on benefits would pass all existing tests.
• Suggested test:

  it('does not show validation error for empty Benefits when Full-time', async () => {
    const { findByRole } = renderSetup({
      calculationMock: { ...fullTimeSalariedMock, benefits: null },
    });
    const benefits = await findByRole('spinbutton', { name: 'Benefits' });
    await waitFor(() => expect(benefits).toHaveValue(null));
    expect(benefits).not.toHaveAttribute('aria-invalid', 'true');
  });

[Suggestion 3.5] SetupStep.test.tsx:360 — Stale comment

• The comment // Benefits is visible and required when Full-time is now inaccurate; benefits is no longer required. Update or extend the test to assert benefits is not in an error state when empty.

[Suggestion 4.0] src/components/HrTools/PdsGoalCalculator/SummaryReport/PdsSummaryTable.tsx:139 — Display honesty for benefits = null

• With benefits now optional, a Full-time user can save the goal with benefits = null. calculateOtherExpenses coerces null → 0, and the Summary table renders $0.00 for the Benefits line — indistinguishable from a real entered $0. Per the rule "A report with zero donations should render 'no data' — not $0.00 that looks like real data," consider rendering "—" or "Not entered" when calculation.benefits == null && isFullTime. Mitigation already in place: SetupSectionList flags the section as incomplete via pdsCompletion.ts:25, so the user has another signal — this is a polish-tier nice-to-have, not a blocker.

---

Severity distribution

Severity	Count
Critical (9.0-10.0)	0
High (8.0-8.9)	0
Important (7.0-7.9)	0
Medium (5.0-6.9)	3
Suggestion (< 5.0)	9

Auto-approval

This PR is LOW risk + APPROVED_WITH_SUGGESTIONS — qualifies for auto-approval. The repo's ai-review-auto-approve.yml workflow will be triggered after this review posts.

[github-actions]

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

[github-actions]

AI Review Auto-Approval

Risk Level: LOW (2/10)
Verdict: APPROVED_WITH_SUGGESTIONS (suggestions posted, no blockers)

This PR was auto-approved because:

• The multi-agent AI review determined it is low 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.