api-gateway
- Critical: Extend `SERVICES` and `service_requests` to include every routed microservice so proxy endpoints stop returning 404/KeyError for battery/demand-response/p2p/forecasting/iot routes (api-gateway/main.py:70-169).
- High: Guard `request_stats` updates against unknown services or look up configs dynamically before incrementing counters to avoid crashes (api-gateway/main.py:88-169).
- Possible Feature: Add per-service rate limiting and fallback routing with circuit breakers to keep the gateway responsive during downstream outages.
- Data to Store: Persist rolling latency/throughput metrics per backend plus authentication decision logs for audit and tuning.

battery-service
- High: Handle zero or missing max charge/discharge power before dividing when optimising SOC to prevent ZeroDivisionError (battery-service/battery_service.py:205-213).
- Medium: Use the stored `capacity_kwh`/`stored_energy_kwh` fields when computing fleet totals so analytics reflect real values (battery-service/main.py:95-96).
- Possible Feature: Expose predictive maintenance recommendations based on usage profiles and integrate battery grouping/aggregation endpoints.
- Data to Store: Track per-cycle metadata (depth of discharge, temperatures) and maintenance events to support lifecycle analytics.

data-ingestion-service
- High: Wrap the initial `wait_for(check_for_new_files)` call in error handling so startup connection/timeout issues don't kill the monitoring task (data-ingestion-service/src/ftp_monitor.py:62-100).
- Possible Feature: Provide a dashboard/REST endpoint for real-time ingestion status with manual retry controls and support for additional protocols (SFTP/HTTPS).
- Data to Store: Record per-file ingestion outcomes, error traces, and FTP scan history to analyse gaps and retry logic effectiveness.

demand-response-service
- Critical: Restore the missing `models`, `database`, and `demand_response_service` modules referenced during import so the app can boot (demand-response-service/main.py:15-20).
- Possible Feature: Implement participant opt-in/opt-out scheduling, incentive tracking, and automated curtailment verification reports.
- Data to Store: Persist device participation history, response accuracy, and incentive payouts to evaluate program efficiency.

forecasting-service
- Critical: Recreate the forecasting microservice implementation; the directory is empty so nothing can start (forecasting-service/).
- Possible Feature: Offer multiple forecast horizons with confidence intervals and expose model version management APIs.
- Data to Store: Keep training dataset metadata, forecast error metrics, and model artefacts to support retraining and auditing.

iot-control-service
- Critical: Recreate the IoT control microservice implementation; the directory is empty so nothing can start (iot-control-service/).
- Possible Feature: Add device scheduling/policy engines with rules-based automation and rollback support for failed commands.
- Data to Store: Log all device capabilities, issued commands, acknowledgements, and firmware status to manage the fleet safely.

p2p-trading-service
- Critical: Recreate the P2P trading microservice implementation; the directory is empty so nothing can start (p2p-trading-service/).
- Possible Feature: Build order-book style trading with price discovery, bidding windows, and settlement workflows.
- Data to Store: Capture trade offers, matched transactions, settlement receipts, and participant credit balances for compliance.

sensor-service
- High: Fix the aggregation pipeline so sensor types are grouped correctly and room metrics use real readings instead of the constant "energy" fallback (sensor-service/room_service.py:408-420).
- Medium: Filter system events using comparable types (e.g., `created_at` or int timestamps) so queries return results (sensor-service/sensor_service.py:218-227).
- Possible Feature: Add anomaly detection on sensor streams and configurable alerting thresholds surfaced via dashboards/WebSockets.
- Data to Store: Maintain sensor calibration history, room occupancy patterns, and WebSocket subscription metrics for optimisation.

token-service
- Medium: Stop forcibly overriding client-provided expiry/embargo values so custom lifetimes survive token generation (token-service/main.py:99-108).
- Possible Feature: Support role/permission templates with bulk token provisioning and self-service revocation flows.
- Data to Store: Persist token usage logs (IP, endpoint, timestamp) and refresh token metadata to improve security monitoring.