Built a full demo against a real BuildEase instance and three documented
facts turned out to be wrong, each costing a debugging round.
buildease installs nothing. Its manifest depends on base alone, so the
"depends on nothing and installs the set" line left an empty database with
no error to catch it. Route and install every module explicitly.
The purge chain had invoices after statements. An invoiced sale.progress
refuses action_cancel outright -- cancelling its invoice is what reverts it
to approved, the first state it can be cancelled from. The documented order
deadlocks on the one statement you invoiced.
custom_product_sale, custom_product_bom and bom_on_sale_order_line are
absent from mev but present on the Callista demo servers, so "not in the
repo" is not the same as "not installable" when pricing.
Also records the revision-formula object graph, which no reference covered:
the coefficients live on formula.input, not on revision.formula, and that
model hangs off either the take-off (contract S, I) or the statement (that
period's s, i). That split is what makes "de index van die maand, niet van
vandaag" work. Its rows come from an @api.onchange that write() never fires
over XML-RPC, and a stale initial_index_value computes a plausible but
wildly wrong revision with no guard behind it -- a factor of 65 instead of
1.005 in this build.
Plus: percentage is a cumulative fraction not 0-100, index_value truncates
to 3 decimals, and button methods return an action dict Odoo cannot marshal
over XML-RPC after the transition has already committed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Most of this skill was never construction-specific. Phase A (discovery brief
from any source), the two-agent parallel build, the generic purge craft and
Phase C (follow-through docs) applied to any Odoo demo — but sat behind a
BuildEase trigger, so Callista's plain Odoo implementations could not reach
them and still ran upstream's Knowcap-bound step 1 with no follow-through.
Those moved to callista-odoo-demo (Callista's fork of Smetools/odoo-demo-
architect, which we cannot PR). What is left here is the part that is actually
about construction, expressed as five overlays on named substrate steps:
module routing, solution precedence, demo-data policy, purge chain, and
follow-through framing.
SKILL.md goes from 208 lines to 119. Nothing BuildEase-specific was dropped —
the take-off-without-a-sale-order trap, the dynamic-article-template-line pin,
the settings-default-off walk, the booked-vs-ordered-hours check and the
custom_product_* dependency gap all survive.
Two rules now carry the boundary: anything needed that is not one of the five
overlays is a gap to fix in the substrate rather than work around here, and
substrate steps are referenced by name, never by number — numbering was how an
upstream renumber could silently misroute this skill.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Wraps odoo-demo-architect for BuildEase (callista-tools/mev) construction
demos: discovery brief from any source instead of Knowcap, pain-to-module
routing onto the 33 BuildEase modules, parallel instance-prep/research
agents, throwaway-record verification with a full purge, and the post-demo
follow-through set.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
adminandClaude Opus 5