asap-quickstart: docker-compose.dev.yml mounts controller-config.dev.yaml, which is not in the repo

[SheriffOreo]

The documented way to run the quickstart from source fails on its first command.

asap-quickstart/docker-compose.dev.yml:17 bind-mounts ./config/controller-config.dev.yaml into the planner container. That file does not exist in a fresh clone, was never tracked on any branch, and is not gitignored. Docker's bind-mount semantics then create a directory at that path and the planner exits.

Steps to reproduce

git clone https://github.com/ProjectASAP/ASAPQuery.git
cd ASAPQuery/asap-quickstart
ls config/
#  -> controller-config.yaml  engine_config.yaml  grafana  prometheus.yml
#  -> no controller-config.dev.yaml

git log --all -- config/controller-config.dev.yaml
#  -> no output: never tracked on any branch

docker compose -f docker-compose.dev.yml up asap-planner-rs

Actual

Error: Is a directory (os error 21)

Substituting the controller config that does ship does not help, because it is in the older schema:

Error: query_groups[0]: missing field `repetition_delay_ms` at line 5 column 5

Related version skew met in the same install

These may be intentional across the v0.5.1 → main boundary, but they are not documented anywhere I could find, and together they mean a config or script written against the published image fails against a source build and vice versa:

• Planner CLI flags differ in both directions. v0.5.1 takes --data-ingestion-interval (s), --prometheus_scrape_interval, --range-duration, --step; main takes --data-ingestion-interval-ms, --range-duration-ms, --step-ms and has no --prometheus_scrape_interval. Each rejects the other's flags. The repo's two compose files each target one side.
• Planner input schema: repetition_delay (s) versus repetition_delay_ms (ms).
• Planner output schema: windowSize/slideInterval (s) versus windowSizeMs/slideIntervalMs (ms), so a planner output is not portable between the two.
• docs/01-getting-started and docs/02-components still describe a Python main_controller.py planner; on main the planner is the Rust crate asap-planner-rs.

One behaviour worth separating out

Given an engine config in the other schema, the engine starts cleanly, logs Backend reachable and CSV ingest complete, serves HTTP 200 for every query — and accelerates nothing, forwarding everything, with no error or warning. An operator following the wrong version's documentation would reasonably conclude ASAPQuery was running correctly and simply not helping. Happy to split that into its own issue if you would rather track it separately.