Odoo development

Odoo composes each model at runtime from the installed addon dependency graph. The field list, the method resolution order (MRO), the super() chain, the view layout, the security rules, and the automations that fire on write — 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. Discovery is a solved problem — delegate it to the odoo-introspect skill. This skill is the customize-safely loop layered on top of it.

Version floor: Odoo 17/18, through Odoo 19 (current LTS). On v16 or older, some ORM/method names differ — and v17.2 → 19 renamed several you'll otherwise emit from memory: group_operator→aggregator (17.2); check_access_rights/check_access_rule→check_access/has_access (18/19); public methods are RPC-callable unless marked @api.private (18.2); record._cr/._context/._uid→record.env.cr/.context/.uid (19); from odoo.osv import expression→the odoo.Domain API (18.1→19); constraints/indexes can be model attributes (18.1). Check skills/odoo-introspect/references/version-matrix.md before relying on a signature below.

Three different "orders" — do not conflate them

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

Workflow: discover → plan → code (never skip step 1)

0. Native-check — is it already built in? (delegate to odoo-capabilities)

Only when the task ADDS something (a field, model, wizard, report, cron, automation) or overrides a core flow method. Before reinventing platform behavior, ask odoo-ai native-check "<requirement>" (matches curated cards + existence-gates them here) or enumerate the full surface with odoo-ai capabilities <model> / --module <addon> — then decide: reuse a native primitive (sequence, automation rule, computed field, mixin, an existing wizard / _prepare_* hook), or build only the genuine gap. The odoo-capabilities skill's references/native-primitives.md is the anti-pattern → native map; the "Pick the built-in, don't hand-roll it" table below is the quick version. Skip this step for bug-fixes, refactors, or edits inside your own module — go straight to Discover.