adding agent tasks to the repo to not lose them

.gitignore

@@ -92,7 +92,7 @@ external/*
 **/frontend/dist/
 
 # Agent Tasks
-Provider/AgentTasks/
+# Provider/AgentTasks/
 
 # OTA files
 *.bundle

Provider/AgentTasks/epic1_client_power.md

@@ -0,0 +1,22 @@
+# Epic 1: Client Power Strategy
+
+## Goal
+Achieve a battery life measured in months for the ESP32-C6 Client.
+
+## Context
+The ESP32-C6 serves as a "dumb" E-ink display client connected to the Calendink Provider. It needs to wake up, check for new layout data, download it, refresh the E-ink panel, and go back to sleep.
+The current standard method of deep sleep followed by full Wi-Fi re-association (DHCP negotiation) consumes ~100-300mA for multiple seconds, drastically limiting battery life for frequent updates.
+
+## Scope & Technologies to Investigate
+1. **Wi-Fi 6 Target Wake Time (TWT):**
+   - The ESP32-C6 supports 802.11ax TWT. TWT allows the device to negotiate specific wake-up schedules with the router, meaning the radio can sleep while the connection remains "active".
+   - Packets sent to the device during sleep are buffered by the AP until the Target Wake Time.
+2. **ESP-PM (Power Management):**
+   - Combine TWT with `esp-pm` dynamic frequency scaling and automatic Light Sleep.
+3. **Alternative - Hybrid ESP-NOW:**
+   - If TWT requires unsupported features on the specific home router, evaluate a fallback where the Client sends a sub-millisecond ESP-NOW broadcast to ask "Is there an update?". Full Wi-Fi is only enabled if the Provider replies "Yes".
+
+## Next Steps to Start
+1. Create a `tdd/client_power_strategy.md` in the Provider/Client workspace.
+2. Develop a minimal test firmware on the C6 to enable TWT via the `esp_wifi_twt_setup` API, monitoring power draw and wake times using a multimeter or profile.
+3. Document the final chosen power strategy pattern before modifying `main.cpp` or `epd.cpp`.

Provider/AgentTasks/epic2_sd_card_storage.md

@@ -0,0 +1,23 @@
+# Epic 2: Provider Persistent Storage (SD Card)
+
+## Goal
+Ensure Users, Tasks, and Settings survive device reboots on the ESP32-S3 Provider.
+
+## Context
+Currently, the Provider's state (Todo tasks, Registered Devices, and User objects) resides in static BSS arrays like `g_Tasks[32]`. This means the state is lost on every reset.
+The ESP32-S3 board has an onboard 3GB SD Card reader. This Epic focuses on migrating the data layer to utilize this SD Card.
+
+## Scope & Technologies to Investigate
+1. **Hardware Pinout:**
+   - Determine the exact physical pins the SD Card reader is using on the specific ESP32-S3 board.
+   - Investigate if it is wired for standard SPI (`sdspi`) or native SDMMC (1-bit or 4-bit mode).
+2. **ESP-IDF Storage Drivers:**
+   - Mount a FATFS partition using the `esp_vfs_fat_sdmmc` / `esp_vfs_fat_sdspi` components.
+3. **Data Model:**
+   - Decide between compiling SQLite for ESP-IDF (better querying, harder setup) or relying on flat `.json` files parsed via cJSON (easier setup, sufficient for MVP limits like 4 users and 32 tasks).
+
+## Next Steps to Start
+1. Create a `tdd/sd_card_persistence.md`.
+2. Find the board schematic or test GPIO configurations to successfully mount the SD Card.
+3. Abstract the storage functionality into a generic `store.hpp/cpp` interface so the `manage.cpp` and API handlers don't need to be rewritten.
+4. Update `seed_users()` and `seed_tasks()` routines to populate initial `.json` files if the SD Card is empty.

Provider/AgentTasks/epic3_voice_to_task.md

@@ -0,0 +1,23 @@
+# Epic 3: Voice-to-Task AI (Gemini)
+
+## Goal
+Allow users to dictate tasks naturally in French, directly creating JSON task structures on the Provider.
+
+## Context
+Adding tasks manually using a keyboard via the web dashboard is friction. We want to utilize automated intelligence (Google Gemini API) to ingest natural language (specifically French) and figure out the JSON properties (task name, user, due date).
+Input can come from the Svelte frontend (browser recording) or an iOS Shortcut automation.
+
+## Scope & Technologies to Investigate
+1. **Ingestion Endpoint:**
+   - Create a `POST /api/tasks/audio` endpoint on the ESP32-S3 Provider.
+   - Decide exactly what format this accepts. Is it raw audio binaries like `.wav` or `.m4a`? Or is it transcribed text sent from the device's native speech-to-text? (Note during implementation if ESP32 memory constraints force pre-transcription on iOS before sending).
+2. **Gemini API Integration:**
+   - Implement an HTTP/HTTPS client on the ESP32-S3 to call Gemini API endpoints.
+   - Construct a prompt template: *"You are an assistant. Extract the task properties from the following French audio/text and output strict JSON matching our schema: { "title": "...", "due_date": "...", "user_name": "..." }"*
+3. **API Key Management:**
+   - Add a Svelte dashboard configuration page to allow the user to securely save their Gemini API key to the SD Card.
+
+## Next Steps to Start
+1. Create a `tdd/voice_ai_integration.md`.
+2. Secure an HTTPS connection from ESP-IDF to the Google Gemini API (managing certs/mbedtls).
+3. Test a hardcoded prompt execution before wiring up the web UI.

Provider/AgentTasks/epic4_modular_layout.md

@@ -0,0 +1,24 @@
+# Epic 4: Modular Grid Layout & Provider Integration
+
+## Goal
+Replace the single full-screen XML structure with a flexible 6-pane grid that dynamically wraps external data.
+
+## Context
+Currently, the Provider sends an entire E-ink screen generated from a single massive LVGL XML string. For the MVP, we want a flexible grid: 2 large top canvases (Main Task, Weather) and 4 small bottom canvases (One per Family Member).
+The user can assign distinct XML templates to any of these 6 panes.
+
+## Scope & Technologies to Investigate
+1. **Widget Architecture (Grid):**
+   - Rework the LVGL rendering logic in the Provider. It should boot an LVGL display, split it into 6 designated Canvas areas, and parse smaller, independent user XML strings into each respective area using `LV_USE_XML`.
+2. **Data Binding:**
+   - Investigate how live data gets into the XML before parsing. E.g., if Canvas 2 is 'Weather', how does `{{TEMP}}` inside the user's XML become `22°C`? String replacement via standard C functions before passing to LVGL.
+3. **OpenWeatherMap Integration:**
+   - Create a backend polling task or direct fetch mechanism on the Provider to query the OpenWeatherMap API.
+   - Expose the OpenWeatherMap API Key configuration in the Svelte dashboard.
+4. **4-User Constraint:**
+   - Enforce that the system tracks exactly 4 active users to match the 4 bottom E-ink panes.
+
+## Next Steps to Start
+1. Create a `tdd/modular_grid_layout.md`.
+2. Prototype a basic HTTP GET to OpenWeatherMap using the `http_client` component and parse the resulting JSON.
+3. Rework the Svelte `DeviceManager.svelte` to show 6 individual XML editors per Device instead of just 1.

Provider/AgentTasks/mvp_implementation_plan.md

@@ -0,0 +1,39 @@
+# Calendink MVP Plan - Executive Summary
+
+This document defines the macroscopic project scope for the Calendink Minimum Viable Product (MVP). 
+
+We will structure the development into **4 Major Epics**. Because features like Power Management and SD Card Integration require deep technical investigation, we will not prematurely guess the solutions here. Instead, each Epic will begin with a dedicated **Technical Design Document (TDD)** to map out the exact implementation before coding.
+
+---
+
+## The 4 Development Epics
+
+### Epic 1: Client Power Strategy
+**Goal:** Achieve a battery life measured in months for the ESP32-C6 Client.
+**Scope:** 
+- Research and design a formal power strategy.
+- Evaluate Target Wake Time (TWT), `esp-pm`, Light Sleep, Deep Sleep, and hybrid ESP-NOW routing.
+- The outcome will be a dedicated TDD followed by the firmware implementation.
+
+### Epic 2: Provider Persistent Storage (SD Card)
+**Goal:** Ensure Users, Tasks, and Settings survive device reboots.
+**Scope:**
+- Investigate the physical SD Card pinout on the ESP32-S3.
+- Decide between SQLite or flat JSON files.
+- Implement the ESP-IDF SDMMC/SDSPI driver.
+- Migrate the current in-RAM `g_Tasks` and `g_Users` arrays to the new persistent backend.
+
+### Epic 3: Voice-to-Task AI (Gemini)
+**Goal:** Allow users to dictate tasks naturally in French.
+**Scope:**
+- Implement an API endpoint on the Provider to accept raw audio/text.
+- Create an internal HTTPS client on the S3 to proxy the data to the Google Gemini API.
+- Parse the structured JSON response from Gemini to automatically save the new task.
+
+### Epic 4: Modular Grid Layout & Provider Integration
+**Goal:** Replace the single-XML screen structure with a flexible 6-pane grid.
+**Scope:**
+- Define a fixed layout layout on the E-ink display: 2 large top canvases (Main Task, Weather) and 4 small bottom canvases (One per family member).
+- Limit the user system to exactly 4 Active Users.
+- Allow the dashboard to assign distinct XML templates to any of the 6 canvases, making it adaptable to future widgets.
+- Integrate an OpenWeatherMap API wrapper on the Provider.