Update callista-odoo-demo skill (local edits: README, SKILL, field gotchas, templates)

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DywdYrFTrWa4h1T3ZykPBX

reference/odoo19-field-gotchas.md

@@ -60,3 +60,21 @@ A custom module that sets `category_id` on `res.groups` or `groups_id` on `res.u
 ## Module install over RPC
 - `x("ir.module.module","button_immediate_install", ids)`. Heavy — let it run minutes (`x()` defaults to a 600s timeout for this reason). On a failed XML-data load it rolls back cleanly (module stays uninstalled); fix and retry.
 - After deploying a custom module to git (Odoo.sh), wait for the rebuild, then `x("ir.module.module","update_list")` and search for it before installing.
+
+## Custom module on v19 — five that cost a build cycle each
+- **`stock.move.name` is gone.** `_rec_name = 'reference'`. Passing `name` in move vals raises. Set `description_picking` if you need text on the line.
+- **Search views: `<group expand="0" string="Group By">` no longer validates.** RelaxNG rejects the attributes (`ERROR:RELAXNGV:RELAXNG_ERR_NOELEM`, reported only as "Invalid view definition"). Use a bare `<group>` wrapping the group-by `<filter>`s, as core does.
+- **Mixed stored/non-stored fields in one compute → `UserWarning: inconsistent 'store'`**, and the non-stored one silently recomputes the stored ones. Give non-stored fields their own compute method.
+- `sale.order.line` uses **`product_uom_id`** in v19 while `stock.move` still uses **`product_uom`**. `_action_launch_stock_rule` is keyword-only: `def _action_launch_stock_rule(self, *, previous_product_uom_qty=False)`.
+- Suppressing the automatic delivery on confirmation (blanket/call-off orders) is cleanest by overriding `sale.order.line._action_launch_stock_rule` to skip those lines — no picking is created at all, so nothing has to be cancelled afterwards.
+
+## Local Odoo 19 Enterprise in Docker (no Odoo.sh, no sudo needed)
+`postgres:16` + the official `odoo:19` image (it carries every Python dep), but **run the mounted 19.0 source, not the image's copy**:
+```yaml
+entrypoint: ["/bin/bash","-lc","rm -rf /usr/lib/python3/dist-packages/odoo && exec python3 /mnt/odoo/odoo-bin \"$$@\"","--"]
+command: ["-c","/etc/odoo/odoo.conf"]
+```
+Without the `rm`, `odoo.addons` is a **namespace package spanning both trees**: core loads from the mount while half the addons load from dist-packages — a silent version mix. Verify with a traceback path or `python3 -c "import odoo"` (should fail).
+- Config keys: `http_port` (not `xmlrpc_port`), `gevent_port`. `--without-demo=all` is now a boolean — pass `--without-demo=True`.
+- Driving the build through `odoo-bin shell` (script on stdin) beats the external API **on a local box only**: full ORM, no named-argument footguns, and **nothing commits unless you call `env.cr.commit()`** — which makes a dry-run of the live demo beat trivially safe (`env.cr.rollback()`). It needs shell access to the container, so it is not an option on Odoo.sh or Odoo Online; there, JSON-2 remains the only route.
+- **After a CLI `-u <module>`, restart the server container.** The upgrade runs in its own process: the DB gets the new fields and views, the long-running web process keeps its old registry. The browser then loads a view referencing a field that server doesn't know → `OwlError: "model"."field" field is undefined`, reported as an Owl lifecycle crash. `odoo-bin shell` scripts never see it (fresh registry per process), so **the whole test suite can be green while the UI is broken** — verify a renamed/added field with `fields_get` over JSON-2 against the *running* server, not only through shell.