StrictPath CLI

StrictPath turns a backend domain into a working NestJS + Fastify service and then produces evidence that the generated architecture actually runs.

domain model
    ↓
TypeScript + Prisma + migration + OpenAPI + event schemas
    ↓
real PostgreSQL + Redis + Kafka/Redpanda verification
    ↓
SBOM + provenance + signed production-proof report

Most generators stop after creating files. StrictPath treats generation as the beginning: runtime wiring, architecture boundaries, persistence recovery, contract drift and supply-chain evidence are part of the output.

Public beta: use @beta explicitly. Releases beginning with 0.1.0-beta.6 are source-available; generated backends remain yours to use and commercialize. Stable-beta, preview and experimental surfaces are listed below; experimental output is not a production-readiness claim.

See It in 90 Seconds

pnpm dlx @strictpath/cli@beta doctor

pnpm dlx @strictpath/cli@beta domain create order-management \
  --tier core \
  --type backend \
  --template svc-golden-path \
  --path ./services \
  --dbmr \
  --no-install

cd services/svc-order-management
pnpm install
pnpm run typecheck
pnpm run test:runtime

From a repository checkout, the repeatable recording script is:

pnpm install
pnpm run build
pnpm run demo:terminal

The exact narration and shot list live in docs/demo/90-second-demo.md.

The Canonical Domain-to-Proof Journey

Start from a checked-in domain specification:

strictpath domain lint examples/domain-specifications/orders.yaml

strictpath domain compile examples/domain-specifications/orders.yaml \
  --preset microservice \
  --output ./generated/orders

The compiler derives synchronized artifacts from one model:

• aggregate, command, query, event and policy TypeScript;
• Prisma models and SQL migration;
• OpenAPI schemas and versioned event JSON Schemas;
• property/invariant tests;
• bounded-context and deployment-boundary evidence.

For a complete service baseline:

strictpath domain create orders \
  --template svc-golden-path \
  --path ./services \
  --dbmr

cd services/svc-orders
strictpath verify --runtime
strictpath verify --full --report reports/full-verification.json

verify --full runs runtime wiring, OpenAPI/event drift, generated CI, real PostgreSQL, real Redis and Redpanda/Kafka, plus mutation testing. It is intentionally heavier than a normal unit-test loop.

What It Produces

svc-orders/
├── src/
│   ├── domain/
│   ├── application/
│   ├── adapters/
│   ├── infrastructure/
│   └── modules/
├── prisma/
├── openapi/
├── schemas/events/
├── tests/
├── helm/
├── policies/
├── observability/
├── scripts/
├── docs/
├── .strictpath/template-manifest.json
├── Dockerfile
└── package.json

The generated service includes:

• strict TypeScript, ESM, NestJS 11 and Fastify 5;
• hexagonal boundaries and real Nest CQRS handler registration;
• Prisma/PostgreSQL persistence with transactional unit of work and outbox;
• idempotent inbox processing, retry and dead-letter behavior;
• RFC 7807 Problem Details and OpenAPI contract checks;
• Redis/Kafka production-dependency rehearsals;
• OpenTelemetry, structured logging, dashboards and alerts;
• Docker, Helm, Kubernetes policies and CI gates;
• CycloneDX/SPDX SBOM, VEX, SLSA provenance, STRIDE threat model and signed proof report.

Capability Maturity

StrictPath exposes maturity in command help instead of pretending every feature has the same stability.

Level	Intended use	Commands/capabilities
Stable beta	Core generation and repository health	doctor, domain create, domain list, template validation, generated service gates
Preview	Early adopters; interfaces may change	domain lint, domain compile, verify, upgrade
Experimental	Evaluation and design research; do not automate irreversible production decisions	Event Storming discovery, digital twin, counterexamples, consistency model, impact engine, governed AI proposals, distributed rehearsal, executable ADR and plugin SDK

Run strictpath --help and strictpath domain --help; preview and experimental descriptions are explicitly labelled.

Experimental Backend Intelligence

These commands are real and tested, but their schemas and UX may change before a stable release:

# Event Storming → bounded contexts, commands, events and inferred sagas
strictpath domain discover examples/domain-specifications/commerce.event-storming.yaml

# State-machine digital twin
strictpath domain simulate examples/domain-specifications/orders.yaml \
  --aggregate Order \
  --commands PlaceOrder,CancelOrder

# Minimal invariant counterexamples
strictpath domain counterexamples examples/domain-specifications/orders.yaml

# Consistency model and failure windows
strictpath domain consistency examples/domain-specifications/orders.yaml

# API/event/schema consumer blast radius
strictpath domain impact baseline.yaml candidate.yaml --fail-on-breaking

# Partition, clock-skew, duplicate/out-of-order and partial-rollout semantics
strictpath domain distributed-rehearsal examples/domain-specifications/orders.yaml

# Turn an ADR into executable fitness rules
strictpath architecture adr-verify examples/domain-specifications/ADR-004-hexagonal-boundaries.yaml

AI-assisted proposals are provenance-bound and remain blocked until a human approves and signs them. StrictPath does not call an AI provider by itself and does not silently apply model output.

Evidence, Not “Production Ready” Marketing

StrictPath reports what passed and what did not. The release evidence recorded on 2026-07-19 produced:

• CLI: 59/59 suites and 433/433 tests;
• generated service verify --full: 11/11 checks;
• PostgreSQL/Redis/Redpanda production rehearsal: 3/3 scenarios;
• distributed semantic rehearsal: 4/4 scenarios;
• signed readiness proof: 100/100 required evidence present.

That run is evidence for that commit and machine—not a universal performance or production guarantee. Reproduce it locally and publish the JSON report with any claim.

Benchmarking Without Invented Numbers

pnpm run benchmark:launch
pnpm run benchmark:launch -- --full

The harness records raw durations, machine details and generated output counts in reports/benchmarks/launch-benchmark.json. It makes no “two hours to two minutes” claim unless a human supplies a measured baseline following docs/benchmarks/METHODOLOGY.md.

Who It Is For

• senior backend engineers who repeatedly rebuild the same production baseline;
• small teams that need platform-engineering discipline without first building a portal;
• platform teams evaluating executable golden paths;
• regulated or audit-heavy environments that need machine-readable evidence.

It is probably not for you if you want a framework-neutral template runner, a low-opinion CRUD generator, a frontend scaffold or a guarantee that generated business rules are correct without review.

How It Differs

Tool	Primary job	StrictPath difference
Nest CLI	Nest modules/controllers/providers	StrictPath generates and verifies a complete opinionated service baseline.
Nx	Workspace graph, caching and generators	StrictPath can run standalone and focuses on backend architecture/runtime proof.
Backstage Scaffolder	Portal-driven templates	StrictPath is local/CI-first and does not require a platform installation.
JHipster	Broad full-application generation	StrictPath targets one narrow NestJS/Fastify/TypeScript golden path.
Cookiecutter/Yeoman	General templating	StrictPath adds semantic compilation, evolution and evidence gates.

StrictPath can complement Nx or Backstage; it does not need to replace them.

Requirements

• Node.js 22 or 24
• pnpm 10
• Git
• Docker for verify --full and container rehearsals
• Syft/OpenSSL or Cosign for the complete supply-chain proof path

Run strictpath doctor to see required and optional capabilities.

Privacy

Telemetry is off by default. No request is made unless you explicitly opt in.

strictpath telemetry status
strictpath telemetry enable
strictpath telemetry disable
STRICTPATH_TELEMETRY=0 strictpath doctor

Arguments, paths, project names, source files, generated code, environment variables and secrets are never part of the telemetry payload. See docs/privacy/TELEMETRY.md.

Development and Release Gates

pnpm install --frozen-lockfile
pnpm run verify
pnpm run demo:terminal -- --full
pnpm run benchmark:launch
pnpm run release:dry-run

Maintainers additionally rehearse a fresh generated service with strictpath verify --full. The exact public-launch checklist is tracked in docs/PUBLIC-LAUNCH-PLAN.md.

Known Limitations

• This is a public beta; preview and experimental schemas may change.
• The default feature-domain service template is intentionally opinionated rather than domain-neutral. Use Domain Specifications for genuinely different domain models.
• Full verification requires Docker and is slower than the normal development loop.
• Upgrade supports manifest-aware planning, merge and rollback, but every real repository should review the plan and keep version-control backups.
• Plugin trust is local; there is no hosted signed plugin registry yet.
• The CLI package currently vendors shared runtime support packages into generated services.
• There are no independent customer benchmarks yet. Contributions of raw benchmark reports are welcome.

Contributing and Security

Read CONTRIBUTING.md, CODE_OF_CONDUCT.md and SECURITY.md. Security reports must use private vulnerability reporting, not public issues.

License

StrictPath releases beginning with 0.1.0-beta.6 are source-available, not OSI open source, under the PolyForm Shield License 1.0.0. You may freely use StrictPath to build and commercialize your own non-competing applications. You may not repackage, rebrand, sell or offer StrictPath—or a competing fork, wrapper or service—as your own product.

Generated backends remain yours to use, modify, license and sell. See LICENSING.md for the generated-output exception, examples and the boundary for commercial permission. Releases through 0.1.0-beta.5 were originally published under MIT and have been removed from npm; copies already obtained remain under their original MIT terms.