Issue State Model
Six fixed states — fix submitted and verified are not the same
Table of Contents
The six fixed states
Issues in QA Note have exactly six states. There are no per-project custom states — states must mean the same thing everywhere for reports and verification to be a trustworthy record.
| State | Meaning | Who transitions it |
|---|---|---|
| Received (open) | Issue filed | Capture, report, or manual entry |
| In progress (in_progress) | Work started | Human or agent (MCP) |
| Fix submitted (fix_submitted) | A fix was submitted (commit/PR) | Agent, or commit key auto-record |
| Verified (verified) | A human confirmed the fix | Humans only (signed-in session) |
| Reported (closed) | Included in a published report | Automatic on report publishing |
| Blocked (blocked) | Cannot proceed (reason recorded) | Human or agent |
Why separate fix submitted from verified?
Because we don't trust the agent's self-report. An agent reporting "it's fixed" (fix submitted) and a human confirming the fix on the actual screen (verified) are different events. MCP and API keys cannot transition an issue to verified.
Ready to verify
Even a submitted fix can't be verified before it's deployed. QA Note correlates commits with deploy events and marks an issue "ready to verify" only when its fix commit has actually shipped. Verifiers only need to watch that list.
Recurrence and corrections
- If the same problem recurs after verification or reporting, a reopen event is recorded. State history is never erased.
- With GitHub sync, each state maps to a fixed label. Changing labels on the GitHub side cannot bypass the verification and reporting gates.