Validate and normalize input

A note title is trimmed and length-bounded, but HTML is not destroyed merely because one renderer must escape it. That contrast gives us something useful to test instead of a rule to memorize.

Parsing answers “can I read this?”; validation answers “is this allowed here?”; output encoding protects a later rendering context. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

The happy path can hide a bad design: you can call broad sanitization on every string and assume that replaces validation and output encoding and still get one successful demo. Push past the demo. validate at the boundary, normalize only by explicit product rules, and encode at the output context, then test the condition most likely to prove the choice wrong.

The module is moving toward one outcome: Accept useful input while keeping parsing, validation, state, and privilege boundaries visible. Save the before-and-after evidence now; it will make the final project review much more honest.

Create a table of malformed, boundary, Unicode, and malicious-looking inputs and test the resulting stored and rendered values. Save the evidence, then explain which requirement would force you to choose a different design.