Skip to content
Architecture Guardian
Documentation

Architecture enforcement for .NET

Your architecture deserves more than good intentions.

Define your architectural boundaries once. Enforce them across your IDE, CI pipeline, and AI coding agents.

Get Started View on GitHub

Repository-owned policies. Evidence-backed feedback. Open source.

01 / Make intent executable

A boundary you can build on.

A passing C# build can still violate your architecture. Make the intended direction explicit, then check what the code actually does.

THE POLICYarchitecture.guardian.yaml
Clean Architecture sample policy
version: 1
modules:
  - id: Shop
    projects: ["Shop.*/*.csproj"]
layers:
  - id: Domain
    projects: ["Shop.Domain/*.csproj"]
  - id: Application
    projects: ["Shop.Application/*.csproj"]
    allowedDependencies: [Domain]
  - id: Infrastructure
    projects: ["Shop.Infrastructure/*.csproj"]
    allowedDependencies: [Domain]
  - id: Host
    projects: ["Shop.Host/*.csproj"]
    allowedDependencies: [Application, Infrastructure, Domain]
rules:
  AG001: error
  AG002: error
  AG003: error
gate:
  failOn: error
THE FEEDBACKAG002 / error

Application reaches into Infrastructure.

The sample application compiles. Its Application layer bypasses the Domain port and calls an Infrastructure implementation. The policy allows Application → Domain, so the scan rejects that edge.

Actual CLI output · excerpt
Shop.Application/Checkout.cs(7,33): error AG002: Layer 'Application' must not depend on layer 'Infrastructure': project 'Shop.Application/Shop.Application.csproj' depends on 'Shop.Infrastructure/Shop.Infrastructure.csproj'.
Analysis completed: 1 diagnostic(s). Gate failed.

Repair the dependency. Depend on the Domain port and keep the Infrastructure implementation behind it.

Run the passing and violating examples

02 / One policy, several checkpoints

From the editor to the merge gate.

Architecture testing for Clean Architecture, modular monoliths, and the boundaries your team defines.

01

Architecture as code

Declare modules, layers and allowed dependencies in versioned YAML. Review architecture changes alongside code.

02

Feedback in your editor

Roslyn analyzers check AG001, AG002 and AG004–AG006 in the host compilation. Keep solution scans for module cycles.

03

A gate for every pipeline

Scan locally or in CI. Export JSON or SARIF, and distinguish policy violations from incomplete coverage.

04

Context for coding agents

The read-only MCP server exposes architecture context, solution analysis and guidance for current violations.

05

Explicit public contracts

Define shared contracts as whole projects. Keep cross-module implementation access behind intentional boundaries.

06

Diagnostics you can act on

Follow source evidence, dependency ownership and remediation guidance to remove or invert the offending edge.

03 / Close the loop

Good architecture is a practice.

  1. 1

    Define your architecture

    Map every project to a module and layer. Declare public contracts and select the rules that express your intent.

    Write your policy →
  2. 2

    Analyze your code

    Restore the intended build context, inspect ownership, and scan actual references and semantic dependencies.

    Run your first scan →
  3. 3

    Prevent architectural drift

    Keep a full solution gate in CI. Review accepted debt with baselines and evaluate new findings against a Git base.

    Add a CI gate →

04 / Give agents the map

AI moves fast.
Keep the boundaries in view.

Give your coding agent architecture context before it edits. Validate the result with the same policy you use in CI.

Set up the agent workflow
  1. 01

    Retrieve the context

    Discover list_rules and resolve ownership with get_architecture after authorizing and restoring the workspace.

  2. 02

    Implement within the boundaries

    Use the retrieved module, layer and contract permissions while making the requested code change.

  3. 03

    Validate the result

    Call analyze_solution. Require completed coverage and a passed gate, alongside the normal build and tests.

  4. 04

    Correct and repeat

    Use explain_violation with a current diagnostic ID. Repair the dependency, restore when needed, and analyze again.

Make the next change intentional

Start with one boundary.

Install the tool. Write the policy. Let your code tell you the rest.

Get Started