A new "email" field type, with real format validation

The single most common thing a feedback or contact form asks for -- after the free-text comment itself -- is the respondent's email address, so the owner can follow up. Right now, an owner who wants that has to use type: "text", which accepts literally anything: "n/a", "call me", a phone number, a typo'd address that will bounce. Every one of those degrades the owner's contact list and wastes a follow-up email or outreach attempt on an address that was never going to work. This is a gap in one of the most common real-world use cases for a "feedback form" product, and it is a gap this codebase is specifically well-positioned to close cleanly, since its whole design point is a table-driven set of field types -- adding one more type is meant to be a natural, contained extension, not a rearchitecture.

FIELD_TYPES in app/models.py is ("text", "number", "choice", "multichoice", "file") -- there is no "email" type. Creating a form with a field of "type": "email" is rejected at form-creation time with "'type' must be one of [...]", before validation of any actual submitted answers ever comes into play. This project already depends on email_validator (see requirements.txt) and already uses it correctly in one place -- app/blueprints/auth/routes.py::register, to validate an owner's email at signup -- that is the tool to reach for here too, not a hand-rolled regex.

cd flask/feedback_service export FLASK_ENV=testing FLASK_ENV=testing .venv/bin/python -m pytest ticket_tests/test_ticket_05_email_field_type.py -v

test_form_can_declare_an_email_field fails: creating a form with a "type": "email" field

is rejected with "'type' must be one of ['choice', 'file', 'multichoice', 'number', 'text']".

This is the project's core architectural extension point, exercised for real: validate_submission_answers is a fixed, table-driven dispatch over field["type"] -- the README is explicit that this function must never eval/exec/dynamically import anything derived from form data, so a new field type has to be a new, ordinary elif branch, following the exact same fail-closed shape (append to errors[name] and continue on any problem; only add to cleaned[name] once a value is fully valid) as every branch already there. Getting this right is a good test of whether you have actually understood that pattern, versus just copy-pasting the text branch and calling it done.

Start at app/models.py::FIELD_TYPES -- a field type has to be recognized there before validate_field_definitions will let a form declare it at all. Then look at validate_submission_answers in app/blueprints/forms/validators.py: find where the if ftype == "text": ... elif ftype == "number": ... chain lives, and add a branch for "email" that calls email_validator.validate_email(...), catching the specific exception it raises for an invalid address (see app/blueprints/auth/routes.py::register for exactly how that is already done once in this codebase) and turning that into a field error rather than letting it propagate.