Reseam onto callista odoo demo #1

2026-07-31T11:12:55+02:00

admin commented

2026-07-31 11:12:55 +02:00

No description provided.

admin added 2 commits 2026-07-31 11:12:55 +02:00

Reseam: reduce to a vertical overlay on callista-odoo-demo 96d02fe0d7

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>

Add the BuildEase demo-data reference, read from mev source 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>

admin merged commit 8454aa132e into main

2026-07-31 11:13:02 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: admin/Claude-buildease-demo#1