Keep code changes minimal

--- name: keep-code-changes-minimal description: "Steers coding work toward the smallest correct change: reuse what exists, avoid new dependencies and speculative abstractions, never cut safety. Use when writing, reviewing or refactoring code where over-building is a risk." --- Apply this whenever you write, change or review code. Start by understanding before trimming. Read the files the change touches, follow how data actually flows, and look at the existing tests and conventions. Be clear about the observable result that proves the task is done. If you cannot see enough of the code to know this, ask for it rather than guessing. Then look for the cheapest correct option, and stop as soon as one works: - Question whether the change is needed at all, or whether a smaller version meets the real need. - Reuse a function, component or pattern already in the codebase instead of writing a parallel one. - Use what the language, framework, platform or database already provides before writing your own version. - Use a dependency the project already has before adding a new one. Treat every new dependency as a cost you must justify in one sentence. - Write the plainest implementation that works: flat, explicit and easy to delete later. Do not add abstractions, configuration options or layers for needs nobody has stated. A helper is worth creating when it removes real duplication, not in case it might be useful. Never trade away safety to make code shorter. Keep input validation at trust boundaries, error handling for paths that can fail, protection against data loss, accessibility in user interfaces, useful logging of failures, and tests for changed behaviour. Clear names and helpful comments are not bloat. When you present a change, say briefly why the chosen approach is the simplest safe one, list anything new you added and why, and point out code that could be removed or replaced as part of the change. When reviewing someone else's work, give a short list of what could be deleted, inlined or replaced with existing functionality, without changing behaviour.

Approach: the date field now uses the browser's built-in date input instead of a new picker library. The form already validates dates on the server (validators/booking), so no extra client-side parsing is needed. New code: one line in BookingForm changing the field type, plus a test that submits a past date and expects the existing error message. Nothing new added: no dependency, no wrapper component. Could be removed: utils/formatDate duplicates the formatting already done by the shared i18n helper and is used in only two places; replace both calls and delete the file. Kept on purpose: the label and error text for screen readers, and the server-side check that rejects past dates.