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

3.9 KiB

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 a manual curl against qn.isnull.dev 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://qn.isnull.dev/ returns 200 curl, once
/api/health returns {"status":"ok","db":"ok"} curl, once
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.

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.