added imlementation of API,

updated AGENTS.md by Codex

AGENTS.md

@@ -15,12 +15,11 @@ It describes what the project is, what is already implemented, and what still ne
   - `backend/`
   - `frontend/`
 
-## Current State (as of 2026-02-11)
+## Current State (as of 2026-02-12)
 
 - `README.md` already contains product specification in Slovak and English.
 - Backend DB migrations exist in `backend/src/Maintenance.php` up to version `7`.
-- Backend API routes are not implemented yet:
-  - `backend/src/API.php` extends `APIlite` but has no endpoints.
+- Backend API methods are implemented in `backend/src/API.php`.
 - Frontend is still template-level:
   - `frontend/src/App.vue` has placeholder content.
   - `frontend/src/router/index.ts` has empty `routes: []`.
@@ -34,6 +33,8 @@ It describes what the project is, what is already implemented, and what still ne
   - Supports `mysql` and `sqlite`
   - Loads override config files from `backend/config/*.php` (except the base file itself)
 - Migration logic: `backend/src/Maintenance.php`
+- API implementation: `backend/src/API.php`
+- DB table models: `backend/src/Models/*.php`
 
 ## Database Schema Snapshot
 
@@ -55,6 +56,51 @@ Migration creates these tables:
   - `diary_entry_id`, `diary_day_id`, `meal_type`, `meal_id`
   - unique: `(diary_day_id, meal_type)`
 
+## API Surface (Implemented)
+
+All actions are invoked through `backend/public/API.php` with `?action=<method_name>`.
+
+- Utility:
+  - `health`
+- Ingredients:
+  - `ingredientList(user_id, query = "", include_global = true)`
+  - `ingredientGet(user_id, ingredient_id)`
+  - `ingredientCreate(user_id, name, protein_g_100, carbs_g_100, sugar_g_100, fat_g_100, fiber_g_100 = 0, kcal_100 = 0)`
+  - `ingredientUpdate(user_id, ingredient_id, name, protein_g_100, carbs_g_100, sugar_g_100, fat_g_100, fiber_g_100 = 0, kcal_100 = 0)`
+  - `ingredientDelete(user_id, ingredient_id)`
+- Meals:
+  - `mealList(user_id, meal_type = "", with_items = false, with_totals = false)`
+  - `mealGet(user_id, meal_id, with_items = true, with_totals = true)`
+  - `mealCreate(user_id, name, meal_type)`
+  - `mealUpdate(user_id, meal_id, name, meal_type)`
+  - `mealDelete(user_id, meal_id)`
+- Meal items:
+  - `mealItemList(user_id, meal_id, with_calculated = true)`
+  - `mealItemAdd(user_id, meal_id, ingredient_id, grams, position = 1)`
+  - `mealItemUpdate(user_id, meal_item_id, ingredient_id, grams, position)`
+  - `mealItemDelete(user_id, meal_item_id)`
+  - `mealItemReorder(user_id, meal_id, ordered_item_ids)`
+- Calculations:
+  - `mealTotals(user_id, meal_id)`
+- Diary:
+  - `diaryDayGet(user_id, day_date, with_totals = true)`
+  - `diaryDaySetMeal(user_id, day_date, meal_type, meal_id)`
+  - `diaryDayUnsetMeal(user_id, day_date, meal_type)`
+  - `diaryRange(user_id, date_from, date_to)`
+
+## Behavior and Validation Rules
+
+- `meal_type` must be one of: `breakfast`, `lunch`, `dinner`.
+- Date params must use format `YYYY-MM-DD`.
+- `grams` must be `> 0`.
+- Nutrition input values are validated as non-negative.
+- If `kcal_100` is `0`, API computes kcal by formula:
+  - `protein*4 + carbs*4 + fat*9`
+- Ownership checks are enforced by `user_id`:
+  - meals and meal items must belong to the user
+  - ingredients can be user-owned or global (`user_id = null`) for read/select
+- API currently requires an existing `users` record for almost all actions.
+
 ## Known Pitfalls and Notes
 
 - The historical FK issue in `meal_items` should reference `meals(meal_id)`.  
@@ -62,6 +108,9 @@ Migration creates these tables:
 - If someone ran migrations before FK fix, old MySQL state may still be broken.  
   In that case reset affected table(s) or rebuild DB from clean state.
 - Some comments in `Maintenance.php` show encoding artifacts, but SQL structure is valid.
+- Authentication is not implemented yet; `user_id` is passed as an action parameter.
+- For `array` parameters (for example `ordered_item_ids`), APIlite expects JSON in request payload.
+- APIlite wraps responses with a nested `data` object. Keep this in mind on frontend parsing.
 
 ## Local Runbook
 
@@ -82,15 +131,15 @@ Frontend:
 
 ## Product Behavior Target (what to build next)
 
-- CRUD for ingredients with per-100g nutrition values.
-- CRUD for meals grouped by day part (`breakfast`, `lunch`, `dinner`).
-- Add meal items by ingredient + grams.
-- Compute per-item nutrition and calories from grams.
-- Compute totals for full meal.
-- Diary day view: assign one meal per day part and compute whole-day totals.
+- Implement auth and session handling (replace plain `user_id` input model).
+- Build frontend screens for ingredients, meals, meal item editor, diary day, diary range.
+- Connect frontend to implemented backend actions.
+- Add API tests for validation, ownership checks, and totals calculation consistency.
+- Add pagination/filter strategy where list endpoints grow.
 
 ## Practical Conventions
 
 - Keep IDs as `BIGINT UNSIGNED` and use `*_id` naming consistently.
 - Keep MySQL + SQLite compatibility in SQL where possible (project supports both).
 - When changing schema, always bump DB version in `Maintenance.php` with forward-only migration steps.
+- Keep API action names stable unless frontend is updated at the same time.