@dashforge/ui DatePicker inside form: clicking a valid weekday does not commit the value (dash test-calendar section 7)

[kensaadi]

Symptom

In dash's /test-calendar route, section 7 — Full suite inside a form (bridge + validation), clicking on a valid weekday inside the Start date DatePicker's calendar popup does NOT commit the selected value to the form field. The popup closes but the input stays empty.

Discovered while

Manual visual smoke test during Sprint 5 pre-flight for issue #60 (Option C). Reported by @kensaadi 2026-07-12 during the dash smoke session.

Repro

1. cd ~/projects/web/learn/dash && pnpm dev (or open http://localhost:5176 with dash already running)
2. Navigate to /test-calendar
3. Scroll to section 7 — Full suite inside a form (bridge + validation)
4. Click the calendar icon on the Start date (required, weekdays only) input → calendar popup opens
5. Click a valid weekday within the min-max range (e.g. May 15, 2026 — a Friday, not weekend, within minDate='2026-05-01' / maxDate='2026-07-31')
6. Observe: the calendar popup closes, BUT
7. The Start date input remains empty — the selected value never gets committed to the form field

Diagnostic evidence (from live session)

Ran during repro:
```js
const day = Array.from(grid.querySelectorAll('button')).find(b => b.textContent?.trim() === '15');
day.click();
// After: input.value === '' (still empty)
// After: popup closes (data-dialog gone)
// After: 0 console errors
```

The day button IS a real button with:

• disabled: false
• aria-disabled: 'false'
• aria-label: 'Friday, May 15, 2026'

But the click:

• Does NOT call handleCalendarChange → does NOT reach commitValue → does NOT trigger bridge.setValue
• Does close the popup (ClickAwayListener or a Radix outside-click may be swallowing focus)

What is NOT the cause

• Not React duplicate: dash uses a single React 19.2.7 instance
• Not a min/max issue: May 15 2026 is well within the configured range
• Not isDateDisabled: verified disabled=false on the button
• Not a bridge issue: same pattern works in section 3 (DatePicker standalone) — the standalone version DOES commit the value (verified by checking `Value: ...` display)

Suspected root cause

Calendar (in @dashforge/ui) day-button `onClick={() => calendar.selectDate(day.iso)}` — the `selectDate` call chain in `useCalendar` (from `@dashforge/calendar-core`) is not firing the parent's `onChange` prop when the value TRANSITIONS from `null` to a valid date inside a form-bridge context. Behavior might be specific to the form-integrated path (`resolvedValue = bridgeValue ?? null`) — the standalone path (section 3) has different value plumbing and works.

Acceptance

• Identify why `calendar.selectDate(day.iso)` inside section 7's bridge-integrated DatePicker does not propagate the new value to the form field
• Fix so that clicking a valid weekday commits the value AND closes the popup AND `bridge.setValue` is called
• Add regression test rendering a `` with a `<DatePicker name='x' rules={{ required: true }} />` inside, asserting that after simulating a day-cell click the RHF value updates
• Verify the same pattern works for the DateTimePicker + DateRangePicker inside the same form (section 7 has all of them)

Versions

• `@dashforge/ui` 1.0.0
• `@dashforge/forms` 1.0.0 (fresh with typed engine from Type-safe engine.getNode() API in @dashforge/forms #2)
• `@dashforge/calendar-core` peer dep
• React 19.2.7

Related

• @dashforge/ui DateRangePicker renders 'undefined – undefined' when value is unset #61 (DateRangePicker "undefined – undefined") — similar class of bridge-integration issue in the same calendar suite, fixed 2026-07-11 via boundary normalization at `resolvedValue`. This one might have the same root cause; worth checking if `normalizeDateRange` pattern needs to extend to `useCalendar`.

[kensaadi]

Not reproducible against current HEAD as of f0320dd.

Live repro against dash /test-calendar section 7 (Full suite inside a form, bridge + validation):

1. Bridge defaultValues.startDate = null → input value "".
2. Click the calendar icon → popup opens (role="dialog" present).
3. Click day 15 (Wed, July 15, 2026 — valid weekday, in range, aria-disabled="false") → input.value becomes "Jul 15, 2026", popup closes.

Same pattern verified on appointmentAt (DateTimePicker inside the same form) — commits "Jul 15, 2026, 00:00" end-to-end.

No commits touching libs/dashforge/ui/**/{DatePicker,Calendar,DateTimePicker}/** nor libs/dashforge/calendar-core/** since 2026-07-11 (only related commit is 763d7cc which closed #61, a different pattern on DateRangePicker). Nothing in the tree changed the code path #114 described — the report was most likely a HMR / dev-bundle stale state or an RHF timing race that can't be isolated after the fact.

Regression test shipped in f0320dd — the existing commits the selected date to the form bridge test seeded a non-null default ('2026-05-20'), so it never exercised the null-transition path. The new test walks the exact #114 scenario:

• Bridge default { startDate: null }
• Faked system time so calendar seeds on May 2026 deterministically
• Assert: bridge null → '2026-05-15', display 'May 15, 2026', popup gone

If this path breaks again in a future useCalendar / DatePicker refactor, CI catches it before the next dash smoke session does.

Closing as not reproducible. If it resurfaces in dash with a fresh pnpm install && rm -rf .vite, re-open with an updated repro.