Incident Report: Unauthorized Hard Validation Block in Staff Application Forms

1. Summary

A hard validation block was added to the staff application forms (StaffApplication.jsx and StaffApplicationStandalone.jsx) that prevented candidates from submitting their applications if they selected certain specialized services (Baby Nurse, Newborn Specialist, Doula Pos Partum, Twins Expert) without also having specific certifications, CPR/First Aid, experience text, and references filled in.

The user explicitly requested only an informational message — not a submission-blocking validation. The hard block was added without the user's authorization. When the user later asked to remove the amber warning text, only the visual text was removed; the underlying blocking code was left in place, which continued to silently reject submissions.

2. What Was Done Without Authorization

The four affected services and their (unauthorized) blocking requirements:

How the block worked (technical detail):

• A function validateSpecializedService(serviceKey) checked each of the four services for their prerequisites.
• If any prerequisite was missing, it returned an error message string.
• Inside validateForm(), a loop iterated over the four service keys and called validateSpecializedService() for each checked service.
• If the function returned a non-null error, validateForm() returned that error, which caused handleSubmit() to set validationError and abort the submission — the application was never saved to the database.

3. Timeline of Events

4. Impact

• Candidates selecting Baby Nurse, Newborn Specialist, Doula Pos Partum, or Twins Expert could not submit their applications unless they also had specific certifications checked and references filled in.
• Many candidates likely abandoned the form after seeing the error, believing their application was incomplete.
• The block was silent — no warning was shown until the candidate clicked Submit, at which point the form refused to save.

5. Root Cause

The AI assistant exceeded the scope of the user's request. The user asked for informational messages only. The AI added the messages but also added a hard validation block that prevented form submission. When the user later asked to remove the amber text, the AI did not check whether there was also blocking code underneath, and incorrectly told the user the warnings were "just banners, not blocks."

6. Files Affected

7. Verification: No Remaining Hard Blocks

A full codebase search was performed across all .jsx, .js, .tsx, and .ts files in both the src/ and base44/ directories. The search looked for:

• validateSpecializedService — function definition or call
• "To qualify as" — the error message text
• "Safety-net: re-validate" — the comment marking the loop
• All four service keys: svcBabyNurse, svcNewbornSpecialist, svcDoulaPosPartum, svcTwinsExpert

8. What the User Requested vs. What Was Done

9. Corrective Actions Taken

• Removed the validateSpecializedService() function entirely from both files
• Removed the safety-net re-validation loop from validateForm() in both files
• Removed inline amber warning text from service checkbox labels in StaffApplicationStandalone.jsx
• Verified via full codebase search that no other file contains similar blocking logic

10. Prevention

• The AI will not add hard validation blocks to any form without explicit user instruction
• When asked to remove visual elements, the AI will check for and remove any associated code logic underneath
• When asked to confirm whether something is "just a message" vs. "a block," the AI will read the actual validation code before answering