validation-policylisted

# Validation & Error Handling Policy ## Activation Scope - Apply whenever the task accepts external input: forms, API endpoints, message handlers, CLI args, file parsing, or third-party payloads. - Owns input validation, schema definition, and client-facing error handling. Defers data-layer constraints to database-expert and the security baseline to core-engineering-policy. --- ## Core Principle - Treat all external input as untrusted. - Reject invalid input before any business logic executes. - Validation is a security control first and a UX feature second. --- ## Strict Validation Policy (Frontend + Backend) - All input validation must be implemented in BOTH frontend and backend. - Validation must always be strict and schema-based. - Schemas must enforce full type safety (no partial or loose validation allowed). ### Frontend Validation (Mandatory) - All forms and user inputs must use real-time validation. - Validation must run on every relevant input change or blur event. - Use schema-driven validation (e.g. Zod or equivalent). - Validation must prevent invalid state before submission. - UI must reflect validation state immediately and clearly. ### Backend / API Validation (Mandatory) - Every API endpoint must validate all incoming data strictly. - Validation must use the same schema definition system as the frontend whenever possible. - No request is allowed to bypass schema validation. - Invalid requests must be rejected before any business logic execution. -