concept-demo-design

Start by writing a Demo Contract that picks one demo_kind (concept_story, product_experience_gate, or journey_validation) and one delivery_lane. Then define the single judgment the demo must answer, the soul frame, and the minimal visible evidence before building any frontend.

concept_story explains an abstract causal change to an audience, product_experience_gate lets operators compare UI options and decide keep/tune/sunset, and journey_validation proves a user can travel from start state to a judgeable end result across real handoffs and recovery.

Use internal_product_gate whenever the demo will be experienced, compared, or decided on inside the real product shell. Use external_showcase only when there is a defined external audience or distribution scenario, and never mix both into a hybrid half-product shell.

No. The default is a deterministic pure-frontend orchestration with fake backends like in-memory state or localStorage. Only add a real backend when the core claim itself depends on real backend behavior.

Each claim needs semantic controls with real handlers, a novel sentinel input absent from fixtures, and a replayable browser journey proving the sentinel produces new DOM or store state. Persistence claims additionally require a refresh-and-recover assertion.

Skip it for signed-off production frontend work, editing existing recorded footage, slide decks, or pure visual exploration. Those route to console-dev, video-forge, or ppt-forge style workflows instead.