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

Claude QA Report — Queue North Website

Status: Current
Owner: _null
Last reviewed: 2026-08-18
Governs: the QA verdict — build SHAs, round summaries, the overall judgment
Review trigger: Any QA round run

The QA verdict. Companion to ClaudeQACoverage.md (what each pass reached) and ClaudeQAPlan.md (the playbook).

Defects are issues, not entries here. A defect found in a round is filed in the tracker with a severity label, where it can be assigned, closed by a commit, and counted. This file keeps the part a tracker is bad at: a human's judgment about whether the thing is fit to ship.

Current run-state

• Last QA round: Round 0 — 2026-08-18, no round has been run
• Last verified build SHA: ac6f5d1 on dev, deployed to nebula as queue-north-website:dev
• Last tested device / environment: none under this plan. The container's own healthcheck and manual curls against both public origins are the only automated observations of the running site
• Overall status: No QA round has been run against this site under any written plan, and there is no automated test suite to fall back on — the only gate is that the build compiles. The site is up, healthy and taking real form submissions, and 178 issues have been found and fixed by review rather than by testing, which is a real record but a different one. What is untested is everything a round would actually look at: the two form paths end to end into Zoho, the failure behaviour when the CRM is unreachable, accessibility, and what happens to the lead database if the volume is lost.

Open defects

Do not list them here, and do not read a defect count out of this file. The Command Center's docs report parses this document for open P0 / P1 / P2 counts, and under this convention they are always zero — the defects are in the tracker, which is the whole point. A repository with seventeen open P1s reports openP1: 0 in that block and the real figure in its tracker counts. Anything summarising defects reads the tracker's label counts; the zeros here mean this file does not hold them, never there are none.

Filed as issues in this repository's tracker, labelled by what they cost:

• P0 — ships broken, or loses data
• P1 — materially wrong, but shippable
• P2 — cosmetic or low impact
• release-blocker — a release built today would be wrong, not merely incomplete

Severity is what it costs, not how annoying it is to fix. Every defect needs the build SHA it was found at — a finding that cannot be re-tested cannot be closed — so put it in the issue body.

A note on P3. This repository carries a fifth label, P3, on 21 closed issues from before it adopted the convention. It is frozen: nothing new gets it. It is not one of the four names the Command Center queries, so a defect filed P3 today would be counted by nothing.

Round notes

Round 0 — 2026-08-18 — baseline, no testing performed

Recorded on the day the project adopted the template, so that the run-state above is a measurement rather than a blank. Nothing was tested. What is known about the running system on this date, and how:

Observation	How it is known
https://queuenorth.com/ returns 200	curl, once
https://qn.isnull.dev/ returns 200	curl, once
/api/health returns {"status":"ok","db":"ok"} on both origins	curl, once each
Both origins serve the identical bundle assets/index-pTFwovIx.js	curl, once each — this is what established they are one container, not two
www.queuenorth.com 301s to the apex; both origins 301 plain HTTP and carry HSTS	curl -I, and scripts/preflight.sh clean against each
Container qn-website-dev on nebula is healthy, restart count 0	docker inspect
The lead database holds 3 tables and took writes on 2026-08-18	sqlite_master count and the file mtime
Security headers, CSP and HSTS are present on the live origin	response headers

None of that is a QA pass. It is evidence that the thing is running.

Added later the same day. The table above originally recorded only qn.isnull.dev, because this session had not yet established that queuenorth.com is the production front door for the same container — an earlier draft of docs/OPERATIONS.md asserted the opposite. The extra rows are what was actually checked once that was known, and they are added rather than substituted so the record shows the correction happening.

The first real round should start with pass B — the two form paths end to end, including whether a lead actually lands in Zoho — because that is the product's entire purpose and nothing has ever verified it end to end from outside.