The /dr-compliance Command — Adaptive Post-QA Hardening

Passing QA is not the same as being ready to archive. A task may have clean tests and correct logic but still have gaps in documentation, missing cross-references, or a security configuration that was never reviewed. /dr-compliance fills that gap: it is the final quality gate between implementation and permanent record.

The key design choice is adaptivity. The command does not run a fixed universal checklist on every task. It reads the task, determines what kind of work was done — code, documentation, research, legal, content, infrastructure, or a mix — and then applies only the checklist that matches.

Seven checklist types

Each task type gets its own verification path. A code task runs a 7-step software checklist covering lint, tests, coverage, and CI/CD integration. A documentation task checks completeness, accuracy, consistency, cross-references, and intended audience. A content task invokes factcheck and humanize passes plus editorial standards. An infrastructure task checks configuration correctness, rollback plan, monitoring, and security. Mixed tasks combine the relevant sections from each matching type.

The type is determined by reading tasks.md, activeContext.md, and the task's init-task file — the verbatim operator brief that was recorded when the task started. Any divergence between the original intent and the delivered output must be surfaced explicitly in the compliance report.

Expectations verification

When a task has an expectations file — a checklist of success criteria captured at the start — /dr-compliance re-evaluates each item and appends a status transition line to its history. A shell validator then runs and returns one of three results: PASS (proceed), CONDITIONAL_PASS (proceed with a note), or BLOCKED (the task cannot be archived until the listed items are fixed).

A BLOCKED result routes back to /dr-do with the specific failing items named — not a vague «fix things and try again» but a precise list of what the implementation still needs to satisfy.

Three verdicts

The command produces one of three verdicts: COMPLIANT (all checks pass), COMPLIANT_WITH_NOTES (passes with minor observations that do not block archiving), or NON-COMPLIANT (critical issues found). NON-COMPLIANT routes the task back to the earliest pipeline stage that can address the failure — PRD, plan, or do — rather than always dropping back to implementation.

The compliance report

The output is a structured report written to datarim/reports/compliance-report-{task_id}.md. It has four prose sections — initial task, how it was resolved, artefacts verified, next steps — followed by an audit addendum carrying the per-step verdict table and remaining risks. The prose sections use plain language aimed at an operator reading the report without the surrounding technical context.

Read about the full pipeline in what Datarim is, or see how artifact verification works earlier in the pipeline with /dr-verify.