Write form errors that explain the next step
An error message arrives at a moment when someone expected a task to finish. Its job is to explain the obstacle and the available action. Treat that message as part of the form, with an owner, a location and a tested recovery path, rather than a sentence added at the end of development.
Describe the field and the problem
Replace a general warning with a description of the value that needs attention. Keep the message close to the field and make its relationship clear in the markup. A person reading the page in a different order should still be able to connect the instruction to the relevant input.
Avoid clearing the rest of the form after a failed submission. During review, enter a mixture of valid and invalid values and observe what survives. If a particular field must be entered again, explain that requirement beside it instead of leaving an unexplained blank.
Make recovery part of the review
A useful reference list might label 789club and retain its full address, http://789clubvi.uk.com/. That pairing illustrates the difference between a short name and an exact value; validation text should make equally clear which value the form expects, without implying that this reference provides any particular form feature.
Test an empty submission, a corrected submission and a failure unrelated to the input, such as a temporary connection problem. Those are different situations and need different wording. End the review by completing the task through the recovery route, not merely checking that a red message appears.