carmanagement/input-validation-plan.md

Task: Add Input Validation for User Data Form

Objective

Add length/format/range validation for the fields listed below, enforced at three layers: frontend (UX), backend (source of truth), and database (last line of defense). Do not change unrelated form behavior, styling, or fields not listed here.

Scope

Only touch the files responsible for these fields: the form component(s), the API endpoint(s) that receive this data, the validation schema/middleware, and the DB migration/schema for these columns. If a field doesn't exist yet in the DB/API, flag it and ask before creating new schema — don't assume the shape.

---

Field Rules

Field	Type	Rule
firstName	string	required, trim, 1–50 chars, Unicode letters/spaces/hyphens/apostrophes allowed
lastName	string	required, trim, 1–50 chars, same charset as firstName
email	string	required, trim, max 254 chars, valid email format (use an existing validation library, don't hand-roll regex)
nationality	enum	required, must be a valid ISO 3166-1 country code (dropdown-backed, not free text)
phoneNumber	string	required, normalize to E.164 on save (use existing phone validation lib if the project has one; otherwise ask before adding a dependency), max 20 raw input chars
driverLicense	string	optional unless told otherwise, trim, 5–30 chars, alphanumeric only
date (generic)	date	must be a valid ISO 8601 date (YYYY-MM-DD); reject free text
address	string	required, trim, 1–255 chars
idPassport	string	required, trim, 5–30 chars, alphanumeric
country	enum	required, valid ISO 3166-1 country code (dropdown-backed)
issuedDate	date	required, ISO 8601, must be ≤ today
expirationDate	date	required, ISO 8601, must be ≥ issuedDate
dateTime	datetime	required, store as ISO 8601 with UTC offset — do not store naive local time
vinNumber	string	required, exactly 17 chars, alphanumeric excluding I/O/Q, uppercase
city	string	required, trim, 1–85 chars
amount	number	required, numeric, > 0, max 2 decimal places, reasonable upper bound (ask what "reasonable" means for this use case if not obvious from context — don't guess a business rule)

Cross-field rules

• expirationDate must be after issuedDate.
• issuedDate must not be in the future.
• Do not implement any cross-field rule not listed here without asking first.

---

Implementation steps

1. Locate existing validation approach. Check if the project already uses a validation library (Zod, Yup, Joi, class-validator, pydantic, etc.) or a pattern for form validation. Use whatever already exists — do not introduce a new validation library if one is already in use.
2. Frontend: add maxlength/type-appropriate input constraints and inline error messages matching the rules above. Reuse existing form error-display patterns in the codebase.
3. Backend: add/extend the validation schema or middleware for the relevant endpoint(s) to enforce the same rules server-side. This is the authoritative check — assume the frontend check can be bypassed.
4. Database: only if column definitions currently allow unbounded/incorrect lengths, add matching length constraints via migration. Do not touch unrelated columns or tables.
5. Normalize country/nationality to ISO codes, phone to E.164, and dates to ISO 8601 at the point of validation/save — not scattered across multiple layers.

Explicitly out of scope (ask before doing any of this)

• Adding a new third-party validation/phone/country-list library if one doesn't already exist in the project.
• Changing the DB schema shape (splitting address into multiple columns, etc.) — flag it as a suggestion instead.
• Any field not in the list above.
• Deep format validation for driverLicense/idPassport beyond length + charset (these vary too much by issuing country to hardcode safely) — ask if stricter per-country validation is actually wanted.

Validation before reporting done

• Confirm each rule above has a corresponding check in frontend AND backend (list them field by field in your report).
• Confirm existing tests still pass; add new tests only for the fields touched here.
• Report any field where the existing DB column type/length conflicts with the rule above, rather than silently changing it.

Task: Add Language-Aware Input Handling (EN / FR / AR)

Objective

Each record has ONE selected language (EN, FR, or AR). Free-text fields are typed and stored in that language's script. Add a language field to the record, validate free-text fields against the script rules for the selected language, and handle RTL display for Arabic. This extends input-validation-plan.md — do not redo work already covered there; only add what's described here.

Scope

Touch only: the form component(s) already handling these fields, the language selector (add one if it doesn't exist), the validation schema from the previous task, the API endpoint(s), and the DB column for storing the selected language. Do not touch fields/logic unrelated to language handling.

---

1. Data model change

• Add a language column/field to the record: enum, one of en, fr, ar. Required, no default — must be explicitly selected (unless the project already has a default locale convention; ask if unsure).
• This is a single value per record, not per field. All free-text fields in that record are assumed to be in this language/script.

2. Which fields are affected

Only free-text, human-language fields are language/script-dependent:

• firstName, lastName, address, city

These are not language-dependent — keep exactly as specified in input-validation-plan.md, do not add script validation to them:

• email, phoneNumber, driverLicense, idPassport, vinNumber, amount, all dates, nationality, country

nationality and country stay as ISO codes regardless of selected language — only their displayed label is translated (a UI/i18n concern, not a data validation concern). Do not store translated country names as the value.

3. Script validation per language

Update the charset rule for firstName, lastName, address, city based on the record's language value:

Language	Allowed script	Notes
en	Latin (a-z, A-Z), spaces, hyphens, apostrophes	Same as current rule in input-validation-plan.md
fr	Latin + French diacritics (à, â, ç, é, è, ê, ë, î, ï, ô, œ, ù, û, ü, ÿ, etc.), spaces, hyphens, apostrophes	Do not reject accented characters
ar	Arabic script (Unicode range \u0600-\u06FF and \u0750-\u077F for extended Arabic), spaces, standard Arabic punctuation	Do not force Latin transliteration

Implement this as a per-language regex/charset map, not a single hardcoded regex — so a future 4th language is a config addition, not a rewrite. Length limits (50 for names, 255 for address, 85 for city) stay the same as input-validation-plan.md regardless of language — do not add or remove digits from those limits.

Do not attempt to auto-detect the language from the text itself — the language field is user-selected and is the source of truth for which validation rule applies.

4. Frontend

• Add a language selector if one doesn't already exist (dropdown or toggle: EN / FR / عربي).
• When ar is selected, apply dir="rtl" to the affected text inputs (firstName, lastName, address, city) and their containing form section. Do not flip the entire page layout unless explicitly asked — scope this to the form only.
• Switch the input validation pattern (pattern attribute / live validation) to match the table above based on the current language selection.
• If the project already has an i18n/translation library in use (e.g. i18next, react-intl), use it for labels and error messages. Do not introduce a new i18n library if one already exists.

5. Backend

• Validate language is one of en/fr/ar.
• Apply the matching charset rule from the table above to firstName, lastName, address, city based on the submitted language value — reject if the text doesn't match the selected language's script (don't silently strip characters).
• Store the text as submitted (UTF-8), no transliteration or normalization beyond standard Unicode NFC normalization (consistent with the rest of the validation plan).

6. Database

• Ensure the column encoding/collation supports UTF-8 fully (utf8mb4 if MySQL; Postgres is UTF-8 by default) — Arabic and accented French characters will break under older utf8/latin1 collations. Only change this if it's actually currently a problem; check first, don't assume.
• Add the language column via migration if it doesn't exist. Do not alter unrelated columns in the same migration.

Explicitly out of scope (ask before doing)

• Translating the actual stored data between languages (e.g. auto-translating an English name to Arabic) — this task is about validating/storing what the user typed, not translation.
• Full-page RTL layout changes beyond the form fields listed.
• Adding a new i18n library if the project doesn't already have one — flag and ask which one to use.
• Any language beyond en/fr/ar.
• Changing how nationality/country are stored (they remain ISO codes).

Validation before reporting done

• Confirm each of firstName/lastName/address/city is validated against the correct script for the selected language value, in both frontend and backend.
• Confirm language is required and validated as an enum.
• Confirm DB encoding supports Arabic/French characters (test by saving a record with Arabic text and reading it back unchanged).
• Confirm unrelated fields (email, phone, VIN, dates, amount, nationality, country) are untouched by this change.