Error updates for the TVM calculator

[jenbreese]

READY FOR REVIEW

UI Consistency changes

• Positive/negative description in accordion. Remove border of the box, looks clickable , just keep the background color
• Dashes look off here --- Change to : Positive: Money you receive (cash in) Negative: Money you pay (cash out)
• Update these tabs to the same color and styling of other clickable tabs. Size , color, font styling, hover state - teal #007c92
• Can we make the radio button be one of the colors we use like the teal and navy , respectively for ligh and dark mode
• Payment Timing Tab , use our brand colors

Structural

• Combined app.tsx + page.tsx into a single page.tsx

Constraints updated

• Payment range: ±$1,000,000 → ±$100,000,000
• Rate range: -100%/100% → -99.99%/1,000%
• Periods max: hardcoded 12,000 → dynamic 500 × effectivePaymentFrequency (uses payment frequency when set to "Different")

Error messages

• M1 sign error: updated copy for both rate and periods variants
• M2 payment too small: updated copy
• M3 no convergence: updated copy, applied to all three throw paths in the RATE solver
• M5 output overflow: added >= 1e15 check showing "Too large to display. Try a lower rate or fewer periods."

Validation behavior

• Field errors now show as soon as all required fields for the active tab have values
• Result is suppressed until complete; errors on filled fields are never suppressed

Global

• All incomplete/error states show —, never $0 or a stale result
• Extracted ResultDisplay component shared by desktop card and mobile footer

UX2

• Mobile sticky footer already existed in the original code and displays the result correctly without scrolling; no changes needed

UX4

• Accordion auto-expands on first visit via localStorage (tvm_howto_seen), collapsed on every visit after

SIGN_HELPER

• Kept as-is; the conditional helper line remains visible under PV, FV, and Payment fields when those fields have a value

Periods max

• Confirmed with Rachel and implemented as dynamic 500 × effectivePaymentFrequency; aligned with payment frequency when "Payments occur: Different" is selected

Review By (Date)

• When does this need to be reviewed by?

Criticality

• How critical is this PR on a 1-10 scale? See Severity Assessment.
• E.g., it affects one site, or every site and product?

Review Tasks

Setup tasks and/or behavior to test

1. Check out this branch
2. Navigate to...
3. Verify...

Front End Validation

• Is the markup using the appropriate semantic tags and passes HTML validation?
• Cross-browser testing has been performed?
• Automated accessibility scans performed?
• Manual accessibility tests performed?
• Design is approved by @ user?

Backend / Functional Validation

Code

• Are the naming conventions following our standards?
• Does the code have sufficient inline comments?
• Is there anything in this code that would be hidden or hard to discover through the UI?
• Are there any code smells?
• Are tests provided? eg (unit, behat, or codeception)

Code security

• Are all forms properly sanitized?
• Any obvious security flaws or new areas for attack?

General

• Is there anything included in this PR that is not related to the problem it is trying to solve?
• Is the approach to the problem appropriate?

Affected Projects or Products

• Does this PR impact any particular projects, products, or modules?

Associated Issues and/or People

• JIRA ticket(s)
• Other PRs
• Any other contextual information that might be helpful (e.g., description of a bug that this PR fixes, new functionality that it adds, etc.)
• Anyone who should be notified? (@mention them here)

Resources

• AMP Tool
• Accessibility Manual Test Script
• HTML Validator
• Browserstack and link to Browserstack Credentials