Scaffold repo: infra docker-compose, service layout, README

Sets up the microservice home-automation platform skeleton: docker-compose
for mosquitto/postgres/clickhouse/redis/rabbitmq, per-service README stubs
describing responsibilities, and top-level README with architecture/stack.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

services/device-control-service/README.md

@@ -0,0 +1,20 @@
+# device-control-service (Go)
+
+Status: not implemented yet.
+
+Responsibility:
+- Expose a gRPC API (see `proto/device_control.proto`) for issuing commands
+  to devices — called by Laravel (manual control) and rule-engine-service
+  (rule-triggered actions).
+- Publish the command to the device's MQTT topic (`devices/{device_id}/commands`)
+  and listen for acknowledgements (`devices/{device_id}/ack`).
+- Maintain the Device Shadow pattern in Redis: `desired_state` (what the user
+  wants) vs `reported_state` (what the device confirmed), plus `status` and
+  `last_seen`.
+- Owns the health-check loop (or delegates to health-check-service): a ticker
+  goroutine that flips a device to `offline` when `last_seen` exceeds a
+  timeout, and emits an event for notification-service.
+
+Not this service's job: deciding *when* to send a command based on sensor
+thresholds — that's rule-engine-service's logic. This service only executes
+and tracks state for whatever command it's given.

services/esp32-emulator/README.md

@@ -0,0 +1,11 @@
+# esp32-emulator (Go)
+
+Status: not implemented yet.
+
+Responsibility:
+- Stand in for real ESP32 hardware during MVP development.
+- Publish plausible telemetry (temperature/humidity/etc.) to
+  `devices/{device_id}/telemetry` over MQTT on an interval.
+- Subscribe to `devices/{device_id}/commands` and reply on
+  `devices/{device_id}/ack`, so device-control-service has something real
+  to talk to.

services/health-check-service/README.md

@@ -0,0 +1,11 @@
+# health-check-service (Go)
+
+Status: not implemented yet. May start as a goroutine inside
+device-control-service and get split out into its own container later —
+kept as a separate directory from day one so the split is a non-event.
+
+Responsibility:
+- Periodically (ticker) check `last_seen` for every device in Redis.
+- When a device exceeds the offline timeout, flip its `status` to `offline`
+  and publish an event for notification-service.
+- Good place to demonstrate goroutines + graceful shutdown in Go.

services/ingest-service/README.md

@@ -0,0 +1,13 @@
+# ingest-service (Go)
+
+Status: not implemented yet.
+
+Responsibility:
+- Subscribe to MQTT topics `devices/{device_id}/telemetry`.
+- Validate/parse payload (device_id, sensor_type, value, timestamp).
+- Batch-write raw readings into ClickHouse `telemetry` table.
+- Publish a "new reading" event to RabbitMQ for rule-engine-service.
+
+Not this service's job: interpreting what a sensor reading *means* (thresholds,
+actions) — that belongs to rule-engine-service. This service only ingests and
+stores.

services/rule-engine-service/README.md

@@ -0,0 +1,18 @@
+# rule-engine-service (Go)
+
+Status: not implemented yet.
+
+Responsibility:
+- Consume "new reading" events from RabbitMQ (async — delivery reliability
+  matters more than latency here).
+- Load active `automation_rules` for the relevant zone/device from PostgreSQL,
+  caching in memory/Redis to avoid a DB round-trip per event.
+- Evaluate rule conditions generically: `sensor_type X operator value` against
+  the reading — no hardcoded sensor/device names, everything comes from the
+  `automation_rules` row.
+- On match: call device-control-service over gRPC (needs a fast pass/fail
+  result) and publish an event to notification-service over RabbitMQ (not
+  latency-critical).
+
+Not this service's job: talking to MQTT or Redis directly — device state
+changes always go through device-control-service's gRPC API.