Project: build a case intake path from form to stored record

Define the contract

Build a case intake form for case 47. The HTML must contain a visible label for the note, a real POST action, and a submit button. Specify a 160-character note limit, but enforce the same rule on the server; an attacker can bypass every browser control. A successful response should identify the created inspection, while an invalid note should return field errors and preserve safe input for correction. Decide whether a repeated POST may create another inspection or whether the client supplies an idempotency key. Write this contract down before adding a visual design.

Trace the boundaries

Follow one submitted note through the browser, request, authentication check, authorization check, parsing, validation, persistence, and response. A cookie can identify a session, but the server must look it up and decide whether that reviewer may edit case 47. Include a CSRF defense for the write. Keep the case ID from a hidden field or path as untrusted input. If the note contains markup, escape it when rendering the confirmation. Store a timestamp on the server; do not accept the browser clock as an audit timestamp.

Verify failure and recovery

Test an empty note, a 161-character note, a missing session, an unauthorized reviewer, a duplicate request, and a lost response after a committed write. For each, record expected status, whether storage changes, and the visible message. Submit with JavaScript disabled to confirm the native form still works. After adding an in-page enhancement, test keyboard submission and a network failure. The output of this project is a working path plus a short trace that proves which layer made each decision.

Acceptance contract

POST /inspections
Input: caseId=47, note="seal replaced", idempotencyKey="review-47-19"
Checks: session -> permission for case 47 -> CSRF token -> body limit -> fields
Success: 201, inspectionId=93
Invalid note: 422, errors.note="Write a note of at most 160 characters"
Repeated key: return the first committed result without a second write

Common Mistakes

• Do not trust the browser length limit as the storage rule.
• Do not infer record permission from a valid session alone.
• Do not blindly retry a write after an ambiguous response.

Related lessons

Form submission: validate on the server and return field errors; Sessions and CSRF: keep identity on the server; Accessible forms: connect labels, errors, and focus; DOM events: enhance a working control without losing its baseline.

Harder boundary

Add a version field to the stored case and submit two edits from the same base version. Exactly one should commit; the other must return a conflict that preserves the attempted note. Then interrupt the winning response and retry with the same intent key. The retry must identify the committed inspection rather than create a second one. These two tests separate concurrent editing from an uncertain transport result.

Extend the build

Continue with Project: paginated inspection feed with safe writes.