XAF Logic Explainer

XAF Logic Explainer

**Teach your AI coding agent what *your* XAF application actually does.**

[See how it works →](https://peopleworks.github.io/XAFLogicExplainer/)

Point it at an XAF module. It reads your entities, controllers, actions, business rules, navigation and Model Editor customizations straight from source — and hands the result to whatever agent you code with.

Why this exists

DevExpress has done excellent work making AI agents fluent in XAF. Two pieces already exist, and this is the third:

An agent that has read every page of the XAF documentation still does not know that your Invoice total is calculated from its lines, that ApproveController refuses to run when the period is closed, or that three columns were hidden in the Model Editor and appear in no C# file at all. It will confidently invent all three.

That gap is not solvable by better prompting. It is solvable by extraction.

These tools compose. Install the DevExpress skills for framework knowledge, use the Docs MCP for the official reference, and use this for your own codebase. None of them replaces the others.

What it extracts

Everything below is read as syntax, using Roslyn. Your project never has to compile, and this tool never links against DevExpress assemblies:

• Entities — properties, types, associations, and the XAF attributes that give them meaning ([Association], [Aggregated], [RuleRequiredField], [Appearance], [ModelDefault], …). Found however your application declares them: through an XPO base, through a DbSet in any spelling a real project uses, through the type argument of a generic context base, and through a base class that lives in a referenced project. An empty answer is a claim, so the rule leans towards reading more — and what it still does not read is written down and asserted rather than remembered.
• Which ORM the application persists with — decided by what the project itself declares, not by what sits beside it. An EF Core cache next to an XPO application does not make it EF Core, and the answer becomes a hard rule in the agent file.
• The framework it targets — in every spelling a project file uses, including the pre-SDK v4.8 that no modern reader looks for. On .NET Framework the agent file gains a ground rule for what is genuinely unavailable there, which is narrower than most people assume and stated that way.
• Controllers and actions — SimpleAction, PopupWindowShowAction, SingleChoiceAction, their target criteria, and the handler code that runs when they fire.
• Business rules — validation attributes and code rules, with the conditions attached.
• Module setup — ModuleUpdater seed data and what gets created on first run.
• Navigation — the groups and items your users actually see.
• Model Editor (`.xafml`) — the customizations that exist *only* in XML and are invisible to anyone reading your C#. Module and platform files are merged the way XAF merges them.
• Custom property and list editors — including the JavaScript they cannot work without, and built-in editors reconfigured at run time through View.CustomizeViewItemControl (). These live in the platform project *beside* the module, so nobody reading the business objects meets them.
• Version-gated migrations — the CurrentDBVersion < new Version(…) blocks in your updater. Each runs at most once for any database, and is the only explanation for data the current code cannot account for.
• Reports — what each one is over, the filter inside its layout, its calculated fields and bound expressions, and the parameters dialog it opens with, down to the GetCriteria() that turns the answers into a filter. Read from designer code, from a .repx, or from the report's own constructor.
• Every screen, and what loads onto it — see below.

These are the reason an agent that has read every business class can still be confidently wrong about the application:

What runs when you open this screen

Nothing in an XAF repository answers that, and both halves are missing for different reasons.

The screens themselves are in no file. XAF generates a list, a detail and a lookup view for every business class, plus a list view for every collection, and the Model Editor stores only the ones somebody changed. Grepping your source for Patient_Prescriptions_ListView finds nothing — and that is not evidence it is missing.

Which controllers run there is decided at run time, by four conditions XAF ANDs together: nesting, view type, object type and view id. Each is unrestricted when unset, so a controller that sets none of them loads onto *every* screen you have.

This reads all four the way ViewController.IsFitToView evaluates them, against a view inventory built from the framework's own id generators — and records why each one matched, so the answer can be checked rather than trusted:

Two layers, kept apart. What your team wrote gets the full treatment; what XAF provides is folded away behind one line, because there is a great deal of it and it is not yours to change. With a ground-truth catalog it is named too — scoped to the modules you actually register, so a WinForms controller never appears on a Blazor screen.

What it will not claim: a controller listed here can still switch itself off through Active["reason"], which depends on the data and the user. This is what XAF loads onto a screen, not what will necessarily do something — and anything it could not read from the source is listed apart, with the reason, instead of being quietly treated as "runs everywhere".

The reports are the test of whether you can trust any of this

Every other section here is a claim that we found something you could not see. This one is the opposite, and it is the more useful half.

Reports V2 lets your users design reports at run time. Those are stored as rows in your database, not as files — so no tool that reads a repository can see them, this one included. An application with forty reports and none in its source is not unusual; it is what a successful reporting setup looks like.

So the answer changes shape depending on what is knowable:

That last row is the common case, and it is where a confident tool does real damage. An agent told "this application has no reports" will design as though none can exist — for an application whose users built forty. AGENTS.md says it outright:

The number is unknown, not zero — do not tell anyone this application has no reports.

The same rule governs the framework catalog. If the catalog on your machine describes DevExpress 26.1 and your application declares 23.2, every framework answer says so, with both numbers, rather than being presented as certain.

A tool that never says "I cannot see that" is not more capable. It is less checkable.

Quick start

dotnet tool install -g XafLogicExplainer.Cli

xaflogic agents --project "C:\MySolution\MyApp.Module"

That writes AGENTS.md, CLAUDE.md and .github/copilot-instructions.md at your solution root. No account, no API key, no server. Your agent understands the application on its next question.

What it writes, and why it is split in two

AGENTS.md is prepended to *every* request an agent makes in the repository, so its cost is paid forever. Dumping 70 KB of entity detail there would crowd out the actual question. So the output is tiered:

<img alt="What a full documentation dump costs an agent's context on every request, against the tiered output that leaves that room free." src="https://raw.githubusercontent.com/peopleworks/XAFLogicExplainer/main/docs/assets/two-tier-context-ligh