feat(gemini): A containerized service for post-apocalyptic meal planning, suggesting balanced meals and highlighting nutrient deficiencies based on available pantry items.

[polsala]

Implementation Summary

• Utility: nightly-nutrient-noodler
• Provider: gemini
• Location: docker-tools/nightly-nightly-nutrient-noodler
• Files Created: 6
• Description: A containerized service for post-apocalyptic meal planning, suggesting balanced meals and highlighting nutrient deficiencies based on available pantry items.

Rationale

• Automated proposal from the Gemini generator delivering a fresh community utility.
• This utility was generated using the gemini AI provider.

Why safe to merge

• Utility is isolated to docker-tools/nightly-nightly-nutrient-noodler.
• README + tests ship together (see folder contents).
• No secrets or credentials touched.
• All changes are additive and self-contained.

Test Plan

• Follow the instructions in the generated README at docker-tools/nightly-nightly-nutrient-noodler/README.md
• Run tests located in docker-tools/nightly-nightly-nutrient-noodler/tests/

Links

• Generated docs and examples committed alongside this change.

Mock Justification

• Not applicable; generator did not introduce new mocks.

[polsala]

🤖 Review by GROQ Agent

✅ What's solid

• Isolation & Scope – The new utility lives entirely under docker-tools/nightly-nightly-nutrient-noodler. No existing codebase is touched, which keeps the change low‑risk.
• Containerisation – The Dockerfile is minimal (Python 3.9‑slim, pip install --no‑cache-dir) and the docker‑compose.yml correctly maps port 5000 and sets a sensible restart policy.
• Flask‑based API – A single POST /plan_meal endpoint keeps the surface area tiny and makes the service easy to consume from scripts or other services.
• Deterministic Tests – All external data (recipes, nutrient tables) are hard‑coded, so the test suite runs offline and is repeatable.
• README – The documentation explains building, running, and testing the service clearly, with example curl commands and a step‑by‑step “Development & Testing” section.

🧪 Tests

• Coverage of core paths – The test suite hits the happy path (single & multiple recipes), the empty‑payload error case, and the internal helper functions (calculate_total_nutrients, identify_deficiencies).
• Flask test client – Using app.test_client() avoids the need for a live container, which speeds up CI and keeps tests hermetic.

Actionable suggestions

1. Add a test for malformed JSON / missing ingredients key

   def test_plan_meal_missing_key(client):
       response = client.post('/plan_meal', json={})
       assert response.status_code == 400
       assert "ingredients" in response.get_json()["message"]

   This guards against a KeyError if the request body is malformed.

2. Validate ingredient type & length – Add a parametrised test that sends a non‑list or a list with non‑string items and asserts a 400 response.

3. Exercise the health endpoint (if added, see Security section) – A simple GET /health test ensures the container is alive before the main endpoint is hit.

4. Run the test suite inside the Docker image – Add a CI step that builds the image and runs pytest inside the container to catch any runtime dependency mismatches.

🔒 Security

• Input validation – The endpoint currently trusts the ingredients array. An attacker could send a huge list (e.g., 10 000 items) or non‑string values, potentially exhausting memory or causing type errors.

  • Fix: Validate that ingredients is a list of strings and enforce a reasonable length (e.g., max 100 items). Return 400 with a clear error message if validation fails.

• No authentication – For a post‑apocalyptic utility this may be acceptable, but if the service ever becomes internet‑facing you’ll want at least a simple token check (e.g., Authorization: Bearer <token>).

• Dependency hygiene – requirements.txt pins only Flask. Consider adding a version constraint (e.g., Flask>=2.2,<3) to avoid accidental upgrades that could introduce regressions or vulnerabilities.

• Error handling – Ensure that unexpected exceptions are caught and transformed into a generic 500 response without leaking stack traces. A Flask error handler can centralise this:

  @app.errorhandler(Exception)
  def handle_unexpected_error(e):
      app.logger.exception("Unexpected error")
      return jsonify({"message": "Internal server error"}), 500

🧩 Docs/DX

• README enhancements

  1. Add a “Run locally (without Docker)” section – Show how to start the Flask dev server (FLASK_APP=src/app.py flask run) for developers who don’t have Docker handy.
  2. Explain the data model – Briefly describe the shape of RECIPES, INGREDIENT_NUTRIENTS, and DAILY_RECOMMENDED_INTAKES. This helps contributors understand where to add new items.
  3. Health check endpoint – Document a simple GET /health that returns {"status":"ok"}. This is useful for orchestration tools (Docker healthchecks, Kubernetes liveness probes).

• API contract – Consider adding an OpenAPI/Swagger spec (even a minimal YAML file). It can be generated automatically from Flask using flasgger or apispec, and it gives consumers a machine‑readable contract.

• Contribution guidelines – Since the utility is generated by Gemini, a note on “When updating the hard‑coded data, keep tests deterministic” would guide future maintainers.

🧱 Mocks/Fakes

• Current approach – The code deliberately uses hard‑coded recipe and nutrient dictionaries (RECIPES, INGREDIENT_NUTRIENTS, etc.) to avoid external services. This is a solid strategy for a self‑contained utility and makes the tests fast and reliable.

• Potential extension – If you later want to pull real nutrition data (e.g., from USDA APIs), introduce an abstraction layer (NutritionProvider) with a default in‑memory implementation. Then the existing hard‑coded data can stay as a fallback mock, and tests can continue to inject the mock provider.

• Test isolation – The fixture client sets app.config['TESTING'] = True, which disables error catching and propagates exceptions to the test runner—good practice. No additional mocking is required at the moment.

---

TL;DR Action items

Area	What to do
Input validation	Enforce list‑of‑strings, limit size, return 400 on bad payloads.
Error handling	Add a generic Exception handler that logs and returns a safe 500 response.
Dependency pinning	Specify a version range for Flask in requirements.txt.
Docs	Add local‑run instructions, data‑model overview, health‑check docs, and optionally an OpenAPI spec.
Tests	Add cases for malformed JSON, oversized payloads, and (if added) health endpoint.
CI	Build the Docker image and run pytest inside it as part of the pipeline.
Future‑proofing	Sketch an abstraction for nutrition data sources to ease later integration with external APIs.

These tweaks will tighten security, improve developer experience, and make the utility easier to maintain as it evolves. 🚀