Check and Matrix
The corpus's spec-first discipline produces analyzer rules, codegen templates, and Feature classes. The discipline is only as good as the loop that verifies the specs match the implementations. @frenchexdev/ddd-cli-plugin-compliance provides two verbs that close the loop: compliance:check for the strict gate, compliance:matrix for the auditable document.
The Two Tasks
plugin.ts declares two tasks.
compliance:check — run requirements compliance --strict across every package in the workspace. The compliance command (from the @frenchexdev/requirements family) reads every Feature's acceptance-criteria declarations and every test's @FeatureTest / @Verifies decorations, builds the traceability matrix, refuses to exit with code zero if any AC lacks a covering test. The CI integration is run ddd compliance:check, refuse the commit on non-zero exit.
compliance:matrix — emit a human-readable traceability document. The output is typically Markdown (compliance-ddd.md) with a row per Requirement, sub-rows per Feature, leaf rows per AC, columns for the tests that verify each AC. Stakeholders read this document to know what does the corpus claim to satisfy, and the document is mechanically generated from the same data the strict check consumes.
The split between gate and document mirrors the build/verify split of codegen plugin. The gate refuses non-compliant ships; the document gives the team something to share without re-running the gate.
Cross-Links
- Consumes every analyzer's
defineAnalyzerSpecand every codegen'sdefineCodegenSpec— those are where the acceptance criteria live. - Consumes every test suite's
@FeatureTest/@Verifiesdecorations — those are where the AC coverage is claimed. - Surfaces the same compliance signal that Subdomain's investment-summary template informs — core subdomains carry stricter compliance expectations than generic ones.
- The output document is what makes the corpus auditable; the gate is what makes it stay auditable.
Back to the series index.