3 Commits
Author SHA1 Message Date
glennandClaude Opus 5 d913cdf09a Add the run-of-show and one-pager templates the README describes
templates/README.md specified three docs; only demo-script-1pager.template.html
existed, so two of the three were rebuilt from the prose every engagement. Both
now ship, matching the section order the README already documented, with
brand.css inlined and no external deps beyond Google Fonts.

The markup comments say what belongs in each slot rather than naming it: status
pills come from the verification log, so "tested" means Test heroes actually
exercised it; the pre-loaded data table marks the records that must stay
untouched, because a live click is consumed the first time it is used.

Two rules from the first engagement to use them:

No rate card means deleting the investment grid and keeping the note that
explains its absence. Filling those cards to avoid a gap contradicts Phase C's
"every number traces to something", and an invented figure becomes the figure
you are held to.

The docs carry spoken lines, so write them in the language the demo is held in.
An English Say column for a Dutch demo gets translated live in the room, which
is exactly where the wording stops matching the client's own quoted words.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 14:43:27 +02:00
glennandClaude Opus 5 6b48fdf126 Refuse to run on config keys the builder cannot build
build_demo.py reads every key with cfg.get(), so a config describing objects it does
not implement was skipped in silence — it printed DONE over an empty database. That
is the same "reports success over an environment that isn't" failure the purge section
exists to prevent, one layer up, and it is how a vertical config (take-offs, progress
statements) would have failed.

Unknown top-level keys now list themselves and abort. DEMO_ALLOW_UNKNOWN_KEYS=1
overrides for a deliberate partial run. Keys starting with _ stay free for comments,
so the shipped example config passes clean.

SKILL.md now states outright that build_demo.py is a per-engagement template rather
than an engine, since that is what makes the failure mode surprising.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 11:10:16 +02:00
glennandClaude Opus 5 8ea297e8bf Reseam as callista-odoo-demo: source-agnostic discovery, parallel build, follow-through
Callista consumes this pipeline for both plain Odoo implementations and
vertical demos, and is not a maintainer upstream — so the generic demo craft
that had accumulated in the buildease-demo vertical skill lands here instead,
where every engagement can reach it.

Moved in from buildease-demo (they were never construction-specific):
- Phase A: discovery brief from a transcript, notes, email, Knowcap, or a
  batched interview. Replaces the Knowcap-bound step 1. Infers before it asks.
- Fork the slow half: instance prep and client research as two parallel
  subagents, then join.
- Purge test residue: ordering, traps, read-back-the-counts evidence.
- Phase C: objection sheet, scoped quote, implementation timeline, SOW.

New here:
- Extension points — a vertical supplies module routing, solution precedence,
  purge chain, demo-data policy and follow-through framing, and nothing else.
  Anything it needs beyond those is a gap to fix here, not to work around.
- Named steps instead of numbered ones. Numbering meant an upstream renumber
  silently misrouted an extending skill with nothing to detect it.

Renamed the skill to callista-odoo-demo: skills resolve by directory name, so
a same-named fork shadows upstream depending on install order, and two people
would build different demos from the same brief.

MIT retained; SMEtools copyright kept, Callista added for modifications.
Fork point and divergence recorded in UPSTREAM.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 10:54:12 +02:00