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, baseline plus a static accessibility audit
- **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 `curl`s 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.