Queue-North-Website/docs/qa/ClaudeQACoverage.md

Claude QA Coverage — Queue North Website

Status: Current
Owner: _null
Last reviewed: 2026-08-18
Governs: what each QA pass actually reached
Review trigger: Any QA round run

Pass by pass, what was reached and what was not. The point of this file is the Blocked and Not run rows: a pass left out of a report reads exactly like a pass that succeeded, and that is how untested code ships believing it was tested.

Round 0 — 2026-08-18 at ac6f5d1

Not a round. The table is filled in on the day the template was adopted so that the honest state is written down rather than absent, because an absent table reads as one nobody got to and this one is a decision.

Pass	Result	Notes
A — First run	Partial	scripts/qa-browser.mjs loads five pages cold at five viewports and measures render, images, CLS and LCP. Not run: any real device, any interaction
B — Core flow	Not run	The two form paths — contact and support — end to end into Zoho. This is the product's entire purpose and it has never been verified from outside
C — Failure paths	Not run	Zoho unreachable, reCAPTCHA failing, a duplicate email hitting the 409, an oversized body hitting the 413
D — Persistence	Not run	Container restart with the named volume intact; SQLite surviving it
E — End of loop	Not run	A submitted lead actually appearing in the Zoho CRM UI. Nothing on this side can observe that
F — Accessibility	Partial	A static audit was run on 2026-08-18 against the six filed defects (#189–#194): contrast computed rather than eyeballed, and every aria-label checked against its visible text for WCAG 2.5.3. Three were real and fixed, three were not defects. Still not run: anything in a browser — no keyboard-only walk, no screen reader, no zoom or reflow testing
G — Performance	Partial	First numbers ever recorded, 2026-08-18 via scripts/qa-browser.mjs: LCP 136-264ms and CLS 0-0.032 across five pages at five viewports, against thresholds of 2500ms and 0.1. Not run: anything under load, any bundle-size budget, any throttled network or CPU
H — Abuse and what a stranger can reach	Not run	See below — this pass is rewritten for this project

Pass H, as it applies here

The template's pass H is written for a product with accounts. This one has none: no login, no session, no roles, no per-user data. Deleting the pass would have been wrong anyway, because the other half of it — what a stranger can reach and exhaust — is the most exposed surface this project has. Rewritten, it is:

• Both POST endpoints called directly, off the form, with hand-made payloads
• The rate limiter actually exercised past RATE_LIMIT_PER_MINUTE and the 429 body checked
• The honeypot field and the reCAPTCHA score path bypassed deliberately
• dist/ inspected for anything secret — VITE_RECAPTCHA_SITE_KEY is inlined there by design and must be the site key, never the secret one
• The 1 MB body limit and the 30 s request timeout tripped on purpose

scripts/preflight.sh covers the headers-and-TLS fraction of this and nothing else. Its --auth checks are deliberately not used: there is no login to rate-limit and no account to enumerate.

Pass I — money flowing backwards — was deleted from the plan, not skipped. No money moves through this site. Carrying it as a permanently skipped row is the lie this file exists to prevent.

Standing gaps

Things no round has ever covered, carried forward until they are. This list existing is not a failure; it not existing while the gaps do is.

• There is no automated test suite at all, and no typecheck. No test runner is installed, package.json has no test script, and the project is plain .jsx with no TypeScript. npm run build is the only gate, and a build proves the imports resolve and nothing else. Closing this gap is not currently filed as an issue — deliberately, because nobody has decided to do it and filing it would put invented work into the denominator. It is recorded here instead, which is where a gap nobody has chosen to close belongs.
• Nothing has ever verified a lead reaching Zoho end to end. The forward is fire-and-forget by design, so a total failure of it is silent by construction: the visitor sees success, SQLite has the row, and the CRM has nothing. The only way to catch that is pass E, and pass E needs somebody with a Zoho login.
• The lead database has never been backed up or restored. backup.sh and restore-check.sh exist as of 2026-08-18 and neither has been run against production. Filed as an issue in Batch 15.
• There is now a way to measure the rendered site: scripts/qa-browser.mjs drives real Chromium at real viewports. It exists because Batches 10 and 11 were twenty issues filed from reading markup of which seven of ten misstated their own evidence, and on its first production run it found two defects none of the twenty had noticed — a header CTA clipped at iPad portrait and the reCAPTCHA widget cut off at 320px. Reach for it before believing a UI defect report, and before writing one.
• It measures five things and no more: horizontal scroll, broken images, elements past the right edge, CLS and LCP. It opens no menus, presses no keys and reads no contrast. A clean run is not "the UI is correct".
• No accessibility testing has ever been done with a screen reader or by keyboard alone, and that is still true after Batch 10. The fixes there were verified by computing contrast, by re-auditing accessible names against visible text, and by grepping the built output — not by using the site. A focus ring proven to be 13.62:1 in arithmetic has still never been seen.
• Four of the six accessibility issues in Batch 10 misstated their own evidence — two contrast figures were wrong, one proposed a colour measuring 1.96:1, and one asked for a change that would have spread a Level A failure. All six had been filed from reading markup. Treat a filed defect's numbers as a claim to check, not a measurement.
• No performance numbers exist for any build, ever.