03 — Run, Scenario, and plugins

Remote controllers often need immutable context before they act. This case reads the Run identity, application snapshot, complete Scenario projection, plugin-host status, exact per-instance status when an instance exists, and a bounded plugin-event page.

Verification level

Public application inspection over loopback HTTP. The Run configuration compiles and the client exercises the inspection surface. Optional Scenario sections are present here so their exact opaque payloads can be seen. This configuration has no plugin instance, so the client reports that fact instead of inventing one.

Run it

Terminal A:

bash

cd demo/server/03_run_scenario_and_plugins
fastsim config validate run.yaml --json
fastsim-server run.yaml

Terminal B:

bash

cd demo/server/03_run_scenario_and_plugins
python main.py

scenario/source explains whether the Scenario was inline or component-selected; scenario/scene contains the fixed authored layout. behavior and evaluation are optional plugin-owned data, not semantics interpreted by FastSim Core. When absent, their individual routes return 404 scenario_section_absent.

Plugin events use an after_sequence cursor and a bounded limit. A production client should remember next_after_sequence instead of repeatedly downloading old events.

The three plugin views serve different purposes:

GET /api/v1/plugins/status returns the plugin host and all configured instances.
GET /api/v1/plugins/{instance}/status returns one exact instance plus bounded host context. Pass --plugin-instance NAME when using this client with a Run that configures plugins; a missing instance is reported without a traceback.
GET /api/v1/plugins/events returns a cursor-paginated event page and supports instance and topic filters.

Plugins cannot be started or stopped independently through this API. Their prepare, start, reset, stop, and cleanup phases follow the owning Run lifecycle.

Next: 04 — State and control targets.