Odoo domain playbooks

Version floor: Odoo 17 / 18, through Odoo 19 (current LTS). Method and field names below are the v17/18 standard; v16 and earlier differ (notably the v17 stock.move.line field rename — see references/stock.md), and v18.1 → 19 renamed several APIs (check_access/has_access, _read_group/formatted_read_group, aggregator, record.env.*) — confirm against the instance and version-matrix.md.

A playbook is a map, not the territory. These "standard" apps are not one fixed thing — what exists in this database depends entirely on which modules are installed:

• sale alone has no delivery; sale_stock adds the stock chain; sale_management adds templates/optional products. The procurement methods you want to hook only exist with sale_stock.
• account localizations (l10n_*) heavily extend _post and add country-specific constraints — your override lands among them, at an MRO layer you can't guess.
• mrp vs mrp_workorder, purchase vs purchase_stock — same story: different methods, different entry points.

So the playbook tells you where to look and what to read — never what to type from memory. The field list, the MRO, the real super() chain, and the cross-model flow exist only in the running registry.

The universal move (before customizing ANY app)

Step 0 — is it already native? If the change adds behavior (a field, wizard, report, cron, automation) or overrides a flow method, first check what the app already ships via the odoo-capabilities skill — odoo-ai capabilities <key.model> / --module <addon> surfaces the native wizards, automations, sequences, and hooks so you reuse them instead of rebuilding. These standard apps are dense with native capability; assume it exists until the instance says otherwise.

Then run these two via the odoo-introspect skill's odoo-ai CLI, feed the JSON to the agent, then plan the patch: