glennandClaude Opus 5
17ebc96bdc
Overlay 3 said what not to install and gave no shape for what to build instead, so the staging script was being written from scratch each time against models nobody had the field list for. reference/buildease_demo_data.md carries the QTO -> sale order -> project -> progress statement -> invoice graph: required fields per model, creation order, which transitions are button methods rather than writes, and the seven guards that stop the chain mid-build (missing product blocks conversion; the SO will not confirm while the QTO is in QTO state; no statement until the QTO is Confirmed; statement periods may not overlap; a QTO-linked order cannot be copied at all). All of it read from callista-tools/mev @ 43c2e19 and Odoo 19 core, nothing inferred. The config block is labelled illustrative because build_demo.py cannot execute it — it is a per-engagement template that silently ignores keys it does not implement, which is now an error upstream in callista-odoo-demo. Two purge corrections fall out of the source, both loosening rules that were stricter than reality: - Deleting the take-off already deletes its sale order; unlink() cascades. - A take-off with no sale order cancels and deletes normally. cancel() writes the state directly and no-ops on the empty order, since Odoo 19's action_cancel has no ensure_one(). The convert-to-quotation-first workaround was unnecessary. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
136 lines
6.7 KiB
Markdown
136 lines
6.7 KiB
Markdown
---
|
|
name: buildease-demo
|
|
description: BuildEase (callista-tools/mev) construction overlay for the callista-odoo-demo skill. Routes the client's pains onto the 34 BuildEase Odoo 19 modules before any custom work is considered, replaces the generic teardown with the take-off → progress-statement chain, and keeps the per-client dataset instead of the old buildease_demo_data bundle. Use for "BuildEase demo", "QTO demo", "quantity take-off demo", "construction Odoo demo", "vorderingsstaat demo", or a follow-up after one.
|
|
---
|
|
|
|
# BuildEase Demo
|
|
|
|
A **vertical overlay** on `callista-odoo-demo`. That skill owns the pipeline — discovery
|
|
brief, build, test, purge, sales docs, follow-through. This one supplies the five things
|
|
that are specific to construction, and nothing else.
|
|
|
|
**Requires** `callista-odoo-demo` installed at `~/.claude/skills/callista-odoo-demo/`
|
|
(Callista's fork of Smetools/odoo-demo-architect). If it is missing, say so and stop —
|
|
do not reimplement its XML-RPC connector, data builder, or pipeline here.
|
|
|
|
> Do **not** substitute an `odoo-demo-architect` install for it. That is upstream, without
|
|
> Phase A's source-agnostic discovery, without Phase C, and without the extension points
|
|
> this file plugs into.
|
|
|
|
**Run `callista-odoo-demo` and apply the overlays below at the named steps.** Everything
|
|
not listed here is that skill's job — follow it as written.
|
|
|
|
---
|
|
|
|
## Overlay 1 — Module routing
|
|
|
|
*Applies at:* **Install modules**, and Phase A's `## Phase 1 scope`.
|
|
|
|
Read `reference/buildease.md` and route the client's pains onto BuildEase modules using
|
|
its pain → module table. Match on **the client's own words** — the table is keyed on what
|
|
they actually say ("we measure in Excel then re-type it into the quote"), not on module
|
|
names they will never utter.
|
|
|
|
Install the umbrella module `buildease` plus the routed set. `buildease` depends on
|
|
nothing and installs the set.
|
|
|
|
## Overlay 2 — Solution precedence
|
|
|
|
*Applies at:* **Research native-vs-custom**.
|
|
|
|
The precedence becomes **BuildEase → native Odoo 19 → custom**, in that order. Most
|
|
construction pains are already solved in mev; custom work is the last resort, and native
|
|
Odoo is the middle tier, not the first question.
|
|
|
|
Odoo 19 only — every mev manifest is `19.0.x`. Do not attempt this against 17 or 18.
|
|
|
|
## Overlay 3 — Demo data policy
|
|
|
|
*Applies at:* **Load demo data**.
|
|
|
|
**Do not install `buildease_demo_data` or `buildease_demo_data_sale_progress`.** They are
|
|
the previous generation of environment setup: one fixed Belgian construction dataset, the
|
|
same for every prospect, dragging in `l10n_be` and `accountant` whether or not the client
|
|
is Belgian. The per-client dataset generated from the discovery brief replaces them — the
|
|
client's own partners, articles, projects and orders, staged so each hero has a record to
|
|
fire on.
|
|
|
|
Install them only if the user explicitly asks for the generic sandbox. The app-level
|
|
dependencies that bundle used to drag in (`sale_management`, `project`, `purchase_stock`,
|
|
`sale_timesheet`, `industry_fsm`, `accountant`, `uom`) still need installing — route them
|
|
from the pain table, not from the demo bundle.
|
|
|
|
**Read `reference/buildease_demo_data.md` before writing the staging script.** It carries
|
|
the QTO → sale order → project → progress statement → invoice object graph from mev source:
|
|
required fields per model, creation order, which transitions are button methods rather than
|
|
writes, and the seven guards that will otherwise stop the chain mid-build.
|
|
|
|
`scripts/build_demo.py` is a per-engagement template, not an engine — it knows nothing about
|
|
take-offs, and it ignores config keys it doesn't recognise. Adapt it; do not assume a
|
|
BuildEase-shaped config will drive it.
|
|
|
|
## Overlay 4 — Purge chain
|
|
|
|
*Applies at:* **Purge test residue**, replacing the generic chain.
|
|
|
|
```
|
|
transient wizard rows → statements (cancelled only, newest first) → invoices
|
|
→ timesheet lines → tasks → projects → sale orders → take-offs → the partner
|
|
```
|
|
|
|
The generic traps still apply. These are the BuildEase-specific ones, each of which cost
|
|
a debugging round:
|
|
|
|
- **Cancel before deleting, on all three.** `unlink()` refuses unless `quantity.take.off` is
|
|
`cancel`, a QTO-linked `sale.order` is `cancel`, and `sale.progress` is `cancelled`.
|
|
- **Deleting the take-off deletes its sale order** — `quantity.take.off.unlink()` unlinks
|
|
`sale_order_ids` first. The take-off is the handle for both.
|
|
- A take-off with **no** sale order still cancels and deletes normally: call `cancel()`, which
|
|
writes the state directly and no-ops on the empty order. No convert-to-quotation dance.
|
|
- **Statements cancel newest-first only** — `action_cancel` refuses unless it is the last one,
|
|
and `action_draft` refuses if a newer statement exists.
|
|
- Leftover `add.dynamic.article.template.line` rows pin take-offs. Clear them first.
|
|
|
|
Full field-level detail, including the guards, is in `reference/buildease_demo_data.md`.
|
|
|
|
## Overlay 5 — Follow-through framing
|
|
|
|
*Applies at:* **Phase C**.
|
|
|
|
Where an objection is already covered by BuildEase, name the **module and the screen** on
|
|
the objection sheet — "that's `sale_progress_revision_formula`, on the statement's Revision
|
|
tab" lands better than "yes, we support that". Where mev does not cover it, say so and give
|
|
the workaround or the build estimate.
|
|
|
|
Check the scoped quote against `reference/buildease.md`'s gotchas before pricing:
|
|
`custom_product_sale`, `custom_product_bom` and `bom_on_sale_order_line` are **not in the
|
|
mev repo**, so anything under `buildease_custom_product*` is not a "just install it" line.
|
|
|
|
---
|
|
|
|
## BuildEase-specific checks
|
|
|
|
- After installing, **walk Settings once**. `res.config.settings` and `res.company` are
|
|
extended by 8 modules each and several BuildEase behaviours default to off.
|
|
- At the staged-numbers sanity check: **booked hours well under ordered hours**. Over 100%
|
|
makes the progress statement look wrong on screen even when every assertion passed.
|
|
- The spine of every BuildEase demo is QTO → sale order → project → progress statement →
|
|
invoice. If that chain breaks mid-demo you lose the deal, so it is the chain **Test
|
|
heroes** must exercise end to end.
|
|
- `quantity.take.off` inherits `mail.thread` + `mail.activity.mixin` — chatter and
|
|
activities work for free. Cheap demo beats.
|
|
|
|
## Guardrails
|
|
|
|
- Never claim a BuildEase feature works without having seen it work in the demo DB.
|
|
- Never invent a pain quote. `(inferred)` is fine; a fabricated quote read back to the
|
|
client in the demo is not.
|
|
- If something you need is not one of the five overlays above, that is a gap in
|
|
`callista-odoo-demo` — fix it there, so the next vertical gets it free. Do not work
|
|
around it here.
|
|
|
|
## Files
|
|
|
|
- `reference/buildease.md` — the module map, the pain → module routing table, and the mev
|
|
gotchas. Read it at Phase A.
|