feat(plans): clamp the inactivity period and preview its expiry date

[bilhokista]

Closes #1088.

A correction to the premise

The issue says the picker "only allows fixed preset dropdowns (30, 90, 180 days) without custom day input". On master it is the opposite: there is no dropdown at all, just a free <input type="number">. So requirement 1 was already met — and the presets the issue assumed existed did not.

I added the presets anyway, as one-click shortcuts beside the free input rather than replacing it, since the issue clearly expects them to be available. If you would rather keep the field bare, they are easy to drop.

The bug I found instead

The existing input fed its raw value straight through:

value={inactivityDays}
onChange={(e) => setInactivityDays(Number(e.target.value))}
// ...
grace_period: inactivityDays * 86400,

Number("") is 0 and Number("abc") is NaN. So clearing the field produced a plan with a zero-second grace period — one that triggers inheritance immediately — and typing a letter produced NaN seconds.

The min={1} max={3650} attributes do not prevent this. They constrain the spinner arrows and native form validation; they do not stop someone typing or pasting 99999 or -5, and this form does not use native validation. The clamp has to happen in code, which it now does in parseInactivityDays / clampInactivityDays, with daysToSeconds as the single path to the contract value.

The input is also backed by a separate text state so it can be empty while you are editing without the value snapping to 1 under your cursor; it settles to the committed value on blur.

The expiry preview

describeExpiry renders the full sentence: the duration and the date the plan would trigger if never pinged again.

Two details in it:

• Dates are built by adding whole days (setDate) rather than milliseconds, so "180 days from now" does not drift by an hour across a daylight-saving boundary.
• The month is spelled out via toLocaleDateString. 03/12/2027 means two different days depending on where the reader is, and this date is the entire point of the control.

The sentence describes the clamped value, so it can never claim a duration the plan will not actually use.

A bug my own test caught

While writing these tests, clampInactivityDays(Infinity) returned the minimum — the guard was !Number.isFinite(value), which lumps ±Infinity in with NaN. "Impossibly large" mapping to "one day" is the opposite of intent. Only NaN needs that fallback, since it has no position on the number line; ±Infinity clamps correctly on its own. I fixed the implementation rather than relaxing the test, and there is a comment at that line explaining why the guard is narrower than it looks like it should be.

Tests

frontend/tests/lib/gracePeriod.test.ts — 19 cases across parsing (empty, whitespace, non-numeric, out of range, fractional), clamping, seconds conversion (never zero, never NaN), date arithmetic (year boundary, leap-day span, no mutation of the input date), formatting, and the sentence including singular/plural and the clamped-value rule.

Honest note on verification: I could not run Vitest locally (no full workspace install), but this frontend has Vitest configured so the file runs in CI as a normal test. I transpiled gracePeriod.ts and executed it standalone against 30 assertions covering the same ground — all pass, after the Infinity fix above.

The panel wiring — the presets, the blur behaviour and the live preview — has no test here and needs CI or a manual check.

Overlap note: this touches CreateInheritancePlanPanel.tsx, which my open PR #1212 also modifies. Different sections of the file (Inactivity Timer vs Beneficiaries), so a textual conflict is unlikely, but whichever lands second may want a trivial rebase — happy to do it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CrfEY1tvXrbeMDAUzxfuk7