radar init

The init command scans your project structure and generates two configuration files: radar.yml (project metadata) and rules.yml (enforcement rules). It auto-detects your tech stack and suggests matching rule packs.

Usage

radar init [options]

Options

Flag	Description	Default
--path <dir>	Target directory to scan	. (current directory)
--architecture <pattern>	Force architecture pattern instead of auto-detecting	auto-detect
--regenerate-rules	Regenerate rules.yml from existing radar.yml	false
--no-ai	Skip AI refinement (deterministic detection only)	false

What It Detects

Frameworks

The detector reads your package.json dependencies to identify your framework:

• NestJS -- @nestjs/core
• Express -- express
• Fastify -- fastify
• Koa -- koa
• Hapi -- @hapi/hapi

ORMs / Database Libraries

• Prisma -- @prisma/client
• TypeORM -- typeorm
• Sequelize -- sequelize
• Mongoose -- mongoose
• Drizzle -- drizzle-orm
• Knex -- knex
• MikroORM -- @mikro-orm/core

Architecture Patterns

The detector scores your directory structure against known architecture patterns:

Pattern	What It Looks For
DDD (Domain-Driven Design)	domain/, use-cases/, infra/ directories
Hexagonal / Ports & Adapters	ports/, adapters/ directories
Clean Architecture	entities/, use-cases/, interfaces/ directories
Layered	controllers/, services/, repositories/ directories
MVC	models/, views/, controllers/ directories
Event-Driven	Event emitters, message queues, CQRS patterns
Feature-Module	NestJS co-located modules with *.module.ts files

Example Session

$ radar init

  Detecting project structure... done
  Detecting layers... done
  Detecting modules... done
  Estimating data volumes... done
  Detecting feature modules... done
  Scoring architecture patterns... done

  Project scanned

  ✓ Stack: TypeScript + NestJS + Prisma
  ✓ Found 4 layers: api, application, domain, infrastructure
  ✓ Found 3 modules: billing, identity, orders
  ✓ Found 6 tables with estimated volumes

  📦 Matching rule packs found:
    1. nestjs-prisma-ddd-strict          — Strict DDD enforcement for NestJS + Prisma with full ...
    2. nestjs-prisma-ddd-relaxed         — Relaxed DDD rules for teams transitioning to domain-d...
    3. nestjs-starter                    — Minimal starter rules for new NestJS projects with ba...
    4. custom — Configure rules manually from presets

? Use a rule pack? (or choose "custom" for manual preset selection)
  ❯ NestJS + Prisma DDD Strict — Strict DDD enforcement for NestJS + Prisma with ...
    NestJS + Prisma DDD Relaxed — Relaxed DDD rules for teams transitioning to do...
    NestJS Starter — Minimal starter rules for new NestJS projects ...
    Custom (select architecture presets manually)

When you choose "Custom", the detector shows its best guess and lets you confirm or override:

  Primary architecture detected:
  ➤ DDD (Domain-Driven Design) — 87% match

? Use DDD (Domain-Driven Design)? (Y/n) Y

? Do you also use any of these patterns? (select all that apply)
  ◯ Hexagonal / Ports & Adapters
  ◯ Clean Architecture
  ◉ Event-Driven
  ◯ Layered (Controller → Service → Repository)
  ◯ MVC Simple
  ◯ Feature-Module (NestJS co-located modules)
  ────────────
  ◯ None — just DDD (Domain-Driven Design)

Generated Files

radar.yml

Project metadata and structure:

# radar.yml — Generated by Technical Debt Radar
# Detected: TypeScript + NestJS + Prisma

stack:
  language: TypeScript
  framework: NestJS
  orm: Prisma
  runtime: node

architecture: ddd

layers:
  - name: api
    path: "src/**/controllers/**"
  - name: application
    path: "src/**/use-cases/**"
  - name: domain
    path: "src/**/domain/**"
  - name: infrastructure
    path: "src/**/infra/**"

modules:
  - name: billing
    path: "src/billing/**"
  - name: identity
    path: "src/identity/**"
  - name: orders
    path: "src/orders/**"

data_volumes:
  orders: L
  events: XL
  users: M
  companies: S

rules.yml

Enforcement rules generated from the chosen architecture:

# rules.yml — Generated from DDD + Event-Driven presets

architecture_rules:
  - deny: domain -> infrastructure
  - deny: domain -> api
  - deny: application <- domain
  - deny: cross-module direct imports
  - allow: cross-module through "src/**/contracts/**"

runtime_rules:
  block:
    - sync-fs-in-handler
    - sync-crypto
    - unhandled-promise
  warn:
    - unbounded-json-parse
    - cpu-heavy-loop-in-handler

reliability_rules:
  block:
    - unhandled-promise-rejection
  warn:
    - missing-try-catch
    - external-call-no-timeout
    - empty-catch-block

gates:
  block_merge:
    - architecture_violations > 0
    - circular_dependencies_introduced > 0
    - runtime_risk_critical > 0
  warn:
    - complexity_increase > 5
    - coverage_drop > 2%

scoring:
  architecture_violation: 5
  circular_dependency: 10
  runtime_risk_critical: 8

Forcing Architecture

Skip detection and specify your architecture directly:

# Single pattern
radar init --architecture ddd

# Multiple patterns (comma-separated)
radar init --architecture ddd,event-driven

Valid patterns: ddd, hexagonal, clean, layered, mvc, event-driven, feature-module.

Regenerating Rules

If you edit radar.yml (add layers, modules, or change architecture), regenerate rules.yml to match:

radar init --regenerate-rules

This preserves any custom exceptions you added to rules.yml.

$ radar init --regenerate-rules

  Regenerating rules.yml... done
  rules.yml regenerated (87 lines)
  ✓ Preserved 2 exceptions from previous rules.yml

Next Steps After Init

# 1. Review generated files
cat radar.yml
cat rules.yml

# 2. Validate configuration
radar validate

# 3. Run your first scan
radar scan .

Tip: Always review the generated data_volumes section. The detector estimates table sizes from your Prisma schema or ORM models, but you should adjust these to match production reality. Volume sizes (S, M, L, XL, XXL) directly affect which performance rules trigger.