Parent
#351
What to build
Final integration slice: rename the bundled demo config from controller.yaml to fastcs.yaml, update the demo to host two controllers so the multi-controller feature is visible out of the box, ensure the launcher does not hard-code the filename, regenerate the JSON schema for the new dict-by-id options, and document manual migration for existing FastCS apps.
Scope:
- Rename
src/fastcs/demo/controller.yaml → src/fastcs/demo/fastcs.yaml.
- Demo
fastcs.yaml declares two controllers (e.g. two TemperatureController instances with distinct ids and connection settings) so the feature is exercised end-to-end on python -m fastcs.demo.
- Launcher does not hard-code
fastcs.yaml as a filename — the path remains a CLI argument.
launch ... schema regenerated and committed (src/fastcs/demo/schema.json) reflecting the new dict-by-id controllers: block.
- Changelog entry covering the breaking change with manual migration guidance:
controller.yaml → fastcs.yaml rename
controller: block → controllers: { <id>: { type: ..., controller: ... } } form
EpicsIOCOptions.pv_prefix removed; the id is the prefix
- Single-class
type: inference allowed
- Documentation updated to use the new filename and dict form throughout examples.
Out of scope (per the parent PRD): tutorial rewrite, useful defaults for omitted transport:, super-PVI parent record, automated migration tooling, per-controller GUI/docs overrides, per-transport id aliases, multi-process deployments.
User stories from #351 covered: 28, 29, 30, 31.
Acceptance criteria
Blocked by
Parent
#351
What to build
Final integration slice: rename the bundled demo config from
controller.yamltofastcs.yaml, update the demo to host two controllers so the multi-controller feature is visible out of the box, ensure the launcher does not hard-code the filename, regenerate the JSON schema for the new dict-by-id options, and document manual migration for existing FastCS apps.Scope:
src/fastcs/demo/controller.yaml→src/fastcs/demo/fastcs.yaml.fastcs.yamldeclares two controllers (e.g. twoTemperatureControllerinstances with distinct ids and connection settings) so the feature is exercised end-to-end onpython -m fastcs.demo.fastcs.yamlas a filename — the path remains a CLI argument.launch ... schemaregenerated and committed (src/fastcs/demo/schema.json) reflecting the new dict-by-idcontrollers:block.controller.yaml→fastcs.yamlrenamecontroller:block →controllers: { <id>: { type: ..., controller: ... } }formEpicsIOCOptions.pv_prefixremoved; the id is the prefixtype:inference allowedOut of scope (per the parent PRD): tutorial rewrite, useful defaults for omitted
transport:, super-PVI parent record, automated migration tooling, per-controller GUI/docs overrides, per-transport id aliases, multi-process deployments.User stories from #351 covered: 28, 29, 30, 31.
Acceptance criteria
src/fastcs/demo/fastcs.yamlexists with two configured controllers; oldcontroller.yamlremovedpython -m fastcs.demoruns end-to-end and serves both controllers over the configured transportsfastcs.yamlsrc/fastcs/demo/schema.jsonregenerated and matches the new dict-by-id optionsfastcs.yamland the dict formBlocked by