# Technical QA Report Sample

This is a sanitized example of the evidence format used for a focused QA/debugging pass.
It is not a client deliverable and does not contain private data.

## Input

- Target: sample lead form on a staging URL
- Reported issue: valid submissions sometimes look successful but never reach the CRM
- Available access: staging URL, browser console, sample payload, exported CRM rows

## Reproduction

1. Open the staging lead form in Chrome.
2. Fill required fields with a safe sample name, email, phone, and message.
3. Submit once with DevTools Network open.
4. Compare the browser response with the exported CRM rows.

## Finding

The frontend shows a success state after the request resolves, but the API response can return
`accepted: false` with a validation message in the JSON body. The UI only checks the HTTP status,
so the user sees success even when the CRM rejects the row.

## Evidence

- Browser request: `POST /api/leads`
- HTTP status: `200`
- Response body: `{ "accepted": false, "reason": "phone_format" }`
- Console errors: none
- CRM export: no matching sample row after submission

## Acceptance Check

Run the same sample submission after the fix:

- invalid phone values show an inline error;
- valid phone values show success only when `accepted === true`;
- CRM export contains one matching row for the valid test;
- duplicate submit is blocked while the first request is pending.

## Handoff

Recommended first fix:

1. Check the API JSON body before showing success.
2. Surface the `reason` field as a readable form error.
3. Disable the submit button while pending.
4. Add one smoke test covering accepted and rejected responses.

Remaining risk: final CRM verification still needs a real staging/API credential from the owner.