The /dr-qa Command — Four Layers of Verification

Shipping code that compiles is not the same as shipping code that works. The /dr-qa command is the verification gate between implementation and archive. It runs four layers of checks — each independent, each with its own verdict — and only routes forward when the aggregate result clears the bar.

The command reads every artifact produced upstream: the PRD, the design documents, the implementation plan, the operator expectations, and the code itself. Each layer is conditional: it only runs when the corresponding artifact exists. A task with no PRD skips Layer 1; a task with no design documents skips Layer 2. The verdict from each executed layer feeds into an overall result.

What it does

Layer 1 checks PRD alignment. Every stated requirement is compared against the implementation. Missing features — things in the PRD that were not built — are flagged. Scope creep — things built that were not in the PRD — is also flagged. Both are explicit findings, not observations.

Layer 2 checks design conformance. The architectural decisions documented in creative files are compared against the actual code. A deviation is identified and assessed: was it an improvement or a regression? The layer does not assume deviations are wrong, but it requires them to be acknowledged rather than invisible.

Layer 3 checks plan completeness. Each step in the implementation plan is verified as done, skipped, or modified. Skipped steps are assessed for risk. Unplanned additions are listed. Layer 3b, which runs when an expectations file exists, is the most directly tied to the operator's original intent. Each wish from the expectations file is evaluated against the implementation using the success criterion defined when the wish was captured. The verdict for each wish is written back to the expectations file, and the command runs the validator script to confirm the aggregate status.

Layer 4 checks code quality: runs the test suite, scans for security issues, checks for anti-patterns such as methods over 50 lines or missing error handling on async operations, and verifies each Definition of Done criterion. When the changed files include frontend markup, a Playwright pass runs to capture a screenshot and a trace of the running interface.

One concrete example

A task to implement per-tenant rate limiting arrives at /dr-qa after implementation. Layer 1 finds the PRD required an HTTP 429 response with a Retry-After header — the header is missing from the implementation. Layer 1 verdict: FAIL. Because Layer 1 is the earliest failing layer, the overall verdict is BLOCKED and the routing points back to /dr-do focused on the missing header. The other layers still run and are recorded, but the earliest failure determines the return target. After the fix and a re-run, all layers pass and the task advances to /dr-compliance.

Where it fits in the pipeline

The command runs after /dr-do for Level 3 and 4 tasks. Level 1 and 2 tasks may skip it and go directly to archive. The QA report is written to datarim/qa/ and kept as an audit trail. If the command is re-run after a fix, the new report gets a version suffix rather than overwriting the prior one.

When the overall verdict is ALL_PASS or CONDITIONAL_PASS, the pipeline routes to /dr-compliance for final hardening before archive. When it is BLOCKED, the routing target is the earliest failed layer — Layer 1 routes back to /dr-prd; Layer 2 to /dr-design; Layer 3 to /dr-plan; Layers 3b and 4 back to /dr-do. This routing is deterministic, not a judgment call.

Read more about the full pipeline in what Datarim is, or go back to the implementation stage described in the /dr-do command.