Search the whole application for a term: entity and property names, controllers, actions, validation messages, criteria expressions and seed data. Use when you know roughly what you are looking for but not where it lives — for example a field name mentioned by the user, or a business concept like 'discount'. Returns what matched and where.

What this XAF application is and everything it contains: ORM, module setup, and the COMPLETE list of entities, controllers, actions and navigation groups. Call this first when asked anything about the application as a whole. The lists are exhaustive: if something is not in them, it does not exist in this application.

Full detail of one business entity: every property with its type and attributes, relationships to other entities, validation rules, appearance rules, and calculated property expressions. Use before writing or changing any code that touches an entity.

What is loaded when a screen opens: every controller XAF activates on that view, why each one matches, and which of their actions appear. Call with no view to list the application's screens. IMPORTANT — most views exist in no file at all; XAF generates them from the business classes, so neither the C# nor the .xafml can be read to find them. Use before changing a controller, adding an action, or answering what a screen does.

Reports the application registers in source: what each is over, the filter and expressions in its layout, and the parameters dialog it opens with. Use when asked what a report shows, why its numbers differ from a screen's, or before writing a new one. Says explicitly when the list is a lower bound because users can also design reports at run time.

Model Editor (.xafml) customizations: captions, list and detail view settings, columns, filters and application options. IMPORTANT — this behavior exists only in XML and cannot be inferred from the C# at all, so check it before concluding how a screen behaves.

Custom property and list editors this application defines, and built-in editors its controllers reconfigure at run time. IMPORTANT — a property rendered by one of these does NOT show the control its type implies, and the business class says nothing about it. Check this before describing or changing how anything appears on screen.

Full detail of one controller: which views it applies to, every action it defines with the actual C# that runs when the action fires, and its helper methods. Use when asked what a button or command actually does.

Trace one business process end to end: what runs, in what order, which entities it touches and which rules govern them, every step citing file and line. Start from an action, a controller method, a controller or an entity. Use this when asked HOW something works — 'how does approval work', 'what happens when I press this' — rather than what exists. Calls the trace could not follow are reported explicitly, so an empty list of them means the path really is complete.

Updater blocks that ran once when an existing database was upgraded past a version, and never again. Use when asked why a column contains what it contains, where legacy data came from, or what changed between releases — the code running today cannot explain any of that, and reasoning from it produces a plausible wrong answer.

The business rules the application enforces: validation rules with their messages and conditions, conditional appearance rules, and calculated properties. Use when asked what the system requires, forbids, or computes. Optionally narrowed to one entity.

Discard cached analysis and re-read the source on the next query. The server already detects file changes automatically, so this is only needed if you believe the cached view is wrong.