fix(tasks): refuse a due or start date the calendar does not have

[h4yfans]

Summary

Closes #1923.

dueDate and startDate were validated by a bare /^\d{4}-\d{2}-\d{2}$/, so 2026-02-30, 2025-02-29 and 2026-13-01 parsed clean and landed in the tasks row. completedAt is a z.string().datetime() and zod already refused the impossible instant, which is the asymmetry the issue names.

packages/contracts/src/calendar-date.ts holds one CalendarDateSchema. It keeps the regex as a first pass, then rebuilds the date from its parts and checks the parts survive. TaskCreateSchema and TaskUpdateSchema use it on both fields. The round trip goes through the local constructor and the local getters, the same pair localMidnight uses for the done date in #1922; new Date('2026-01-01') parses as UTC, so reading getDate() off it answers 31 December anywhere west of UTC and refuses a real date.

taskPatchSchema in the Vault MCP tool schemas gets the same schema on due, due_date and start_date. The agent's writes run handles.tasks.create into createDesktopTasksDomain, which never touches TaskCreateSchema, so that tool schema is the only gate on the path. The isoDateSchema the journal and calendar read tools share is left alone.

Validate on write, tolerate on read. Nothing parses a task row on the way out: the IPC responses, the RPC Task and the calendar projection items are plain interfaces, and the query layer compares dueDate as a SQLite string. TaskSyncPayloadSchema stays deliberately loose, because a strict date there would make a receiving device reject a peer's older row forever, on a value the user cannot see to fix.

Release note

An Obsidian task line carrying a date the calendar does not have, such as 📅 2026-02-30 or 📅 2025-02-29, no longer imports as a task with a due date that never arrives. The line is left exactly as written and a message names the refused date.

Test plan

• vitest --project shared packages/contracts/src/ — 52 files, 1724 tests pass. tasks-api.test.ts covers 2026-02-30, 2025-02-29, 2026-13-01 and 2024-02-29 on create and update; calendar-date.test.ts pins the year boundary and the leap day in Pacific/Pago_Pago, Pacific/Kiritimati, UTC and Asia/Kolkata, and a day whose local midnight does not exist in America/Santiago and America/Havana; sync-payloads.test.ts pins that a peer's stored impossible date still parses.
• Fourteen of those cases fail on the first commit of this branch, which lands the tests before the fix.
• vitest --project main src/main/agent/mcp — 15 files, 124 tests pass. Reverting schemas.ts to origin/main and rerunning turns the new case red with expected true to be false, so the MCP guard is load-bearing rather than duplicated.
• vitest --project main src/main/database/queries/tasks.test.ts — a seeded row holding dueDate: '2026-02-30' and startDate: '2025-02-29' reads back verbatim through getTaskById, appears in listTasks, sorts correctly under sortBy: 'dueDate', is found by getTasksByDueDate, counts in getTaskStats, survives duplicateTask, and does not throw from getOverdueTasks.
• vitest --project renderer src/renderer/src/lib/task-utils — 4 files, 423 tests pass, including new cases pinning that parseDueDate rolls a stored impossible date onto a real day instead of throwing or returning Invalid Date.
• pnpm lint, pnpm typecheck, pnpm --filter @memry/desktop typecheck:test, pnpm check:architecture, pnpm check:contracts, pnpm ipc:generate && pnpm ipc:check, pnpm --filter @memry/desktop i18n:check, git diff --check all pass.
• pnpm docs:impact --base origin/main --strict and pnpm docs:build pass.
• npx react-doctor reports only pre-existing findings under apps/mobile, none in files this branch touches.
• No E2E was run from this worktree. apps/desktop/tests/e2e/obsidian-tasks-import.e2e.ts needed no edit; it uses no impossible dates.

[github-actions]

React Doctor found no new issues. 🎉

_{Reviewed by React Doctor for commit 8039032.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!