Odoo introspection — read ground truth, then customize

Odoo composes each model class at runtime from the installed addon dependency graph. The field list, the MRO, the super() chain, the view layout, the security rules, the automations that fire on write, the report parser — none are reliably knowable from memory or source-grep. They exist only in this running instance. Guessing is the root cause of "half-working" customizations that break elsewhere.

The rule: read ground truth from the running registry first, then customize. Never guess.

Three different "orders" — do not conflate them

1. Module load order — from depends in __manifest__.py. Determines what exists when the registry builds. Override sale.order.action_confirm while depending only on sale (not sale_stock) and your override lands at a different MRO layer than intended.
2. Method resolution order (MRO) — the class chain of the final registry model. The potential super() path, not a guarantee of what runs. An override that skips super() cuts the chain; an early return under a context flag skips the rest. Layer A reports has_super / super_position / returns_before_super (heuristics) so you can judge.
3. Runtime call order — what actually executes on a click/cron: onchange → constrains → method → procurement → stock moves → invoice hooks → automations → recomputes. A graph across many models, not a list. Static analysis can't reconstruct it. Trace it (Layer D).

The four ground-truth layers