Rules Engine

Overview

The rules engine lets you define architectural constraints in .sentrux/rules.toml and enforce them automatically — in CI, before merges, or via MCP so your AI agent knows the boundaries.

Example rules file

.sentrux/rules.toml

[constraints]
max_cycles = 0          # zero tolerance for circular dependencies
max_coupling = "B"      # maximum coupling grade
max_cc = 25             # maximum cyclomatic complexity per function
no_god_files = true     # no file with >500 lines or fan-out >15

[[layers]]
name = "core"
paths = ["src/core/*"]
order = 0

[[layers]]
name = "service"
paths = ["src/service/*"]
order = 1

[[layers]]
name = "app"
paths = ["src/app/*"]
order = 2

[[boundaries]]
from = "src/app/*"
to = "src/core/internal/*"
reason = "App must not depend on core internals"

Running checks

sentrux check .
# ✓ All rules pass — Quality: 7342

Exit code 0 = pass, 1 = fail. Use in CI:

.github/workflows/quality.yml

- name: Architecture check
  run: sentrux check .

Layer ordering

Layers define a dependency hierarchy. Lower order = more foundational. Higher layers can depend on lower layers, but not vice versa.

app (order 2)    → can depend on service and core
service (order 1) → can depend on core
core (order 0)    → cannot depend on app or service

Boundary rules

Boundaries block specific dependency paths:

[[boundaries]]
from = "src/api/*"
to = "src/db/internal/*"
reason = "API layer must use the DB interface, not internals"

MCP integration

Your AI agent can check rules before committing:

Agent: check_rules()
→ { pass: true, violations: [] }

Or after making changes:

Agent: check_rules()
→ { pass: false, violations: [
     { rule: "boundary", from: "src/api/handler.rs",
       to: "src/db/internal/pool.rs",
       reason: "API layer must use the DB interface, not internals" }
   ]}

The agent sees the violation and fixes it before you ever see it.