# Claude QA Report — ``` Status: Current Owner: Last reviewed: 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:** - **Last verified build SHA:** `` - **Last tested device / environment:** - **Overall status:** ## 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. ## Round notes