odoo-introspectlisted

# 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. The `model_brief` 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.