Validate and tune the rules

Your project's conventions live in architecture.yml. Change them there; nothing else needs editing.

Validate#

construct validate                      # human-readable report, exit 1 if any error
construct validate --format json        # the same findings as JSON, for scripts and CI

Each finding gives a rule id, severity, file and line, why the rule exists, what was expected and a suggested fix.

Change architecture.yml:

rules:
  PAGE-004: warning
  PURE-001: off

Severity:

• error — validation fails
• warning — reported but does not fail
• off — disabled

Temporary exceptions may be scoped and expired:

exceptions:
  - id: LEGACY-001
    path: features/legacy/**
    rules: [PAGE-004]
    reason: Temporary migration
    owner: platform-team
    expires: 2026-12-31

Rules that take options#

A rule can also be given an object instead of a bare severity, to tune its thresholds. For example, the frozen-markup rules accept similarity and maxOwnElements:

rules:
  PAGE-007: { severity: error, similarity: 0.9 }

CLIENT-001 (a 'use client' file cannot import server-only code) takes a serverOnly list of your own server-only packages, on top of the built-in databases and SDKs, and serviceLayer: true when your services are server-only code (Server Components and Actions) rather than browser-side API clients, which is what a Construct service usually is. It is error in a project made by construct init and off in an existing one until you turn it on:

rules:
  CLIENT-001: { severity: error, serverOnly: [acme-billing, '@acme/*'] }

The rule reference lists every rule id and its default severity.

The defaults you start from#

You can loosen any of these with the settings above, but the defaults are deliberately strict.

• Routes are thin and delegate.
• Controllers compose; they do not become business-logic dumping grounds.
• Workflows own application state and flow.
• Hooks own React/application logic only when React context is needed.
• Domain is pure by default.
• Services own network/external effects.
• Pages are presentation-only.
• Components are presentation-only except local UI state.
• Features are isolated behind index.ts public APIs.
• One primary module per file.
• Every responsibility has an architectural owner.