plan-MAI

Evaluation and recommended combined plan What the three plans do well

1. plan-MAI.md Strengths:

Most complete and detailed technical blueprint. Strong alignment with the prompt: Dockerized app, Tesla API cost control, DK1 pricing, scheduling logic, auth flow, UI pages, and error handling. Clear project structure and implementation phases. Weaknesses:

Slightly over-scoped for a first version; it feels more like a polished product than a lean MVP. Some pieces (full dashboard/settings/setup flows, richer UI, more endpoints) may be more than necessary at the start. 2) plan-Kimi K2.7 Code.md Strengths:

Best at keeping the scope tight and focused on the core goal. Clear emphasis on low Tesla API usage and a simple Docker-based local app. Good “minimum viable product” tone. Weaknesses:

Too thin on implementation details. Missing important operational details like auth flow, storage model, UI structure, and error handling. 3) plan-big-pickle.md Strengths:

Strong balance between practicality and completeness. Good product decisions: configurable region/tariffs, limited SOC polling, API usage logging, manual overrides, optional ntfy, and deployment notes. Best at thinking about real-world deployment and usage constraints. Weaknesses:

Slightly less structured than plan-MAI on the initial architecture and file layout. Could be more explicit about the exact charging algorithm and fallback behavior. Best plan The best overall plan is plan-MAI.md.

Why:

It has the strongest technical depth and the clearest implementation blueprint. It covers the full app lifecycle: setup, auth, pricing, planning, charging control, UI, persistence, deployment, and failure handling. It is the most likely to lead to a robust and maintainable solution. That said, I would borrow two important things from the other candidates:

The tight MVP focus and low-API discipline from plan-Kimi. The practical deployment and usage-tracking choices from plan-big-pickle. Recommended combined plan Build a lean but robust local Docker app that charges a Tesla in the cheapest Danish hours while staying under the Tesla Fleet API budget and keeping the car ready by a user-defined departure time.

Product goals Charge the Tesla to a target SoC before a configurable departure time. Use public Danish hourly electricity prices (DK1 by default, DK2 optional). Keep Tesla API usage very low and predictable. Run locally in Docker with simple setup and local storage. Provide a basic web UI for configuration and status. Key design decisions Stack: Node.js + TypeScript + Express, plain HTML/HTMX or simple vanilla JS, local JSON storage, Docker-based deployment. Pricing source: Energi Data Service (or equivalent public DK1 feed) with caching. Tesla integration: OAuth PKCE flow, encrypted token storage, minimal read operations, start/stop commands only when needed. Scheduling: compute the cheapest contiguous charging window needed to reach the target SoC before departure. Cost control: read vehicle state only at controlled times, log Fleet API usage, and expose usage metrics in the UI. Deployment: local Docker app with a simple reverse-proxy or tunnel only if OAuth callback requires remote access. Core features Configuration Target SoC Departure time Monitor/start time Charger power (kW) Battery capacity (kWh) Active days Price region (DK1/DK2) Optional tariff tiers Optional ntfy topic Tesla integration Setup wizard for Tesla developer credentials and OAuth connection Token refresh handling Encrypted local storage of tokens Vehicle command proxy or equivalent signing approach Limited state reads and command execution Charging planner Fetch hourly prices Calculate needed charging hours from SoC gap and charging rate Find the cheapest contiguous window before departure Start charging at the window start and stop at the window end Skip planning when the car is already at/over target or no suitable window exists Scheduling and resilience Daily price refresh and repeated planning checks Retry logic for transient failures Graceful fallback to cached prices if the feed fails Clear logging and alerting on start/stop/error conditions Web UI Dashboard with current status and planned window Settings page for config and tariff tiers Setup flow for Tesla OAuth Simple status/history view with API usage info Implementation phases Scaffold the app Create project structure, Dockerfile, docker-compose.yml, package.json, and basic Express server. Implement configuration and storage Local JSON config file, encrypted token storage, price cache, and API usage log. Implement Tesla auth and client OAuth PKCE flow, token refresh, vehicle state reads, start/stop charging commands. Implement pricing and planner Price fetcher, tariff handling, cheapest-window algorithm, and local scheduling logic. Add scheduler and reliability Cron-based jobs, retries, logging, health checks, and manual overrides. Build UI and notifications Dashboard, settings, setup wizard, API usage view, and optional ntfy integration. Validate and harden Test end-to-end flow, verify low API usage, verify Docker deployment, and document setup. Out of scope for v1 Multi-car support Cloud hosting as the primary deployment target Complex analytics or forecasting Advanced geofencing or home detection Success criteria The app can charge the Tesla to the target SoC before departure using the cheapest available hours. Tesla Fleet API usage remains comfortably below the monthly credit. The app works locally in Docker with a simple setup flow. The UI clearly shows status, planned charging window, config, and API usage.