Software-only show-control readiness baseline

docs/build_and_deploy.md

@@ -0,0 +1,46 @@
+# Build and Deploy
+
+## Host Side
+
+Required tools:
+
+- Rust stable toolchain
+- `cargo`
+
+Suggested commands:
+
+```powershell
+cargo test
+cargo run -p infinity_host -- snapshot --config config/project.example.toml
+cargo run -p infinity_host_api -- --config config/project.example.toml --bind 127.0.0.1:9001 --runtime-state data/runtime_state.json
+cargo run -p infinity_host_ui
+cargo run -p infinity_host -- validate --config config/project.example.toml --mode structural
+cargo run -p infinity_host -- plan-boot-scene --config config/project.example.toml --preset-id safe_static_blue
+```
+
+The host API server now exposes the common software-first control boundary over HTTP and WebSocket. The creative web UI is served directly from the same process at `http://127.0.0.1:9001/`. Runtime creative data such as saved presets, groups, active scene state, and creative snapshots are persisted to `data/runtime_state.json` by default.
+
+The native engineering UI and the CLI snapshot continue to run against the same simulation-backed host core so looks, presets, grouping, and parameter flow can be exercised before transport and firmware integration are complete.
+
+Before any live activation, run:
+
+```powershell
+cargo run -p infinity_host -- validate --config config/project.example.toml --mode activation
+```
+
+Activation mode is expected to fail until the hardware mapping has been confirmed and the config is updated from `pending_validation` to concrete driver references.
+
+## Firmware Side
+
+Required tools:
+
+- ESP-IDF
+- Xtensa or RISC-V toolchain matching the actual ESP32 variant
+
+Suggested layout:
+
+- `firmware/esp32_node/`
+- build with `idf.py build`
+- flash with `idf.py -p <serial-port> flash monitor`
+
+The firmware skeleton is intentionally conservative. It will not silently select a backend for `UART 6`, `UART 5`, or `UART 4`.