embabel scenario

Put the world in a named state, from wherever it is now.

embabel scenario list                     # what exists, and which one you are in
embabel scenario run pipeline-at-risk     # bring the world to that state
embabel scenario next                     # the one after the one you are in
embabel scenario capture pipeline-at-risk # freeze the world as it is now
embabel scenario run … --dry-run          # say what would change, change nothing

A scenario declares what should be loaded rather than listing steps:

{ "name": "pipeline-at-risk", "order": 2, "description": "a deal has stalled",
  "wants":   ["accounts-base", "deals-at-risk"],
  "without": ["pipeline-healthy"] }

Running it works out the difference and does the minimum — adds what is missing, removes what should not be there, leaves everything else alone.

Declared rather than scripted, because sample add X && sample remove Y works right up until somebody is watching. Then a question from the room means a step gets skipped, or re-shown, or half-applied, and every later line of a script of CHANGES assumes a state its predecessor no longer produced. A declaration asserts the state, so jumping straight to the fourth scenario from anywhere lands correctly, and re-running one that is already current does nothing.

There is no saved position. next works out where you are by looking at what is loaded, because a remembered “you are on step 3” is a second source of truth that goes wrong the moment somebody loads a set by hand — and goes wrong silently.

capture is how scenarios actually get made. Nobody writes one first: you load a set, load another, remove the one that was wrong, look at the screen, and only then know what you wanted. Capture turns that arrangement into something repeatable.

✓ Wrote scenarios/pipeline-at-risk.json
   wants:   accounts-base, deals-at-risk
   without: pipeline-healthy

without is inferred, and it is the part that matters: every set the OTHER scenarios name that is not loaded here, so this one knows what to clear away when somebody arrives from a sibling. Recording only wants would give a scenario that adds correctly and never removes anything — which shows up as yesterday’s data still on screen halfway through a demo. A captured scenario is ordered after everything that exists, so it appends to the walk rather than inserting itself into somebody’s sequence, and it refuses to overwrite an existing file without --force.

Scenarios are .json files in ./scenarios, ordered by their order field and then by name. A set named in wants is looked for beside the scenario (scenarios/sets/<name>.json) before the ordinary rules apply, so a scenario and the data it needs travel together.

This is not only for demos, which is why the verb is not demo: the same move puts a world into a fixed state to evaluate a realm before connecting an account, to reproduce a support case, or to start a test from somewhere known.