feat(gemini): A Dockerized utility that simulates a scavenger drone reporting on discovered resources and anomalies in a post-apocalyptic wasteland.

[polsala]

Implementation Summary

• Utility: nightly-scavenger-drone-sim
• Provider: gemini
• Location: docker-tools/nightly-nightly-scavenger-drone-sim
• Files Created: 5
• Description: A Dockerized utility that simulates a scavenger drone reporting on discovered resources and anomalies in a post-apocalyptic wasteland.

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-scavenger-drone-sim.
• 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-scavenger-drone-sim/README.md
• Run tests located in docker-tools/nightly-nightly-scavenger-drone-sim/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

• Self‑contained utility – All source, Dockerfile, README and tests live under a dedicated folder, keeping the rest of the repo untouched.
• Deterministic test suite – The tests mock random and datetime (and the DRONE_ID env var) so the output is fully reproducible.
• Clear output contract – generate_report() always returns a pretty‑printed JSON string, making it easy to pipe into log aggregators or other tools.
• Good coverage of edge cases – The three test cases cover “full report”, “no findings”, and “resources only”, ensuring the branching logic is exercised.
• Readable README – The documentation explains the purpose, build/run steps, and how to customise the drone ID, which is sufficient for a first‑time user.

🧪 Tests

• Add a “anomalies‑only” test – Currently there’s no scenario where only anomalies are reported. A small test would guarantee the random.random() branch for resources is skipped while the anomaly branch fires.

  @patch('drone_sim.random.random', side_effect=[0.8, 0.1])  # no resources, yes anomalies
  def test_report_only_anomalies(mock_random):
      # …assert that findings contain only anomaly entries

• Validate JSON schema – Instead of only checking a few fields, consider loading the JSON and asserting required keys exist (timestamp, drone_id, location, findings). This protects against accidental field renames.
• Avoid over‑mocking – The tests patch random.choice and random.randint heavily. Using a helper that returns a deterministic random.Random instance (e.g., random.Random(0)) could simplify the setup while still being explicit.
• Test exit code / stdout – When the script is executed as a module (python -m docker-tools...), verify that it prints a valid JSON string and exits with status 0. This can be done with subprocess.run([...], capture_output=True) in an integration‑style test.

🔒 Security

• Run as non‑root – The Docker image currently runs as the default root user. Add a low‑privilege user to reduce the impact of a container breakout:

  FROM python:3.9-slim-buster
  RUN useradd --create-home appuser
  WORKDIR /app
  COPY src/requirements.txt .
  RUN pip install --no-cache-dir -r requirements.txt
  COPY src/drone_sim.py .
  USER appuser
  CMD ["python", "drone_sim.py"]

• Pin dependencies – Even though requirements.txt is empty now, future additions should pin exact versions (e.g., requests==2.28.2) to avoid supply‑chain surprises.
• Healthcheck (optional) – Adding a lightweight HEALTHCHECK that runs the script with a --dry-run flag (if you add one) can help orchestration platforms detect a broken container early.

🧩 Docs/DX

• Clarify environment variables – The README mentions DRONE_ID but does not list it under a “Configuration” section. Adding a small table (e.g., DRONE_ID, REPORT_INTERVAL) would improve discoverability.
• Show Docker tag naming – Suggest a conventional tag, e.g., docker build -t ghcr.io/yourorg/scavenger-drone-sim:latest ., so users know how to version the image.
• Add a quick‑start script – A one‑liner that runs the container in a loop (with --restart unless-stopped) would help users who want continuous reporting without writing their own shell loop.
• Link to test execution – The README’s “Running Tests” section could include the exact command to run the test suite inside the container (e.g., docker run --rm scavenger-drone-sim python -m unittest discover -s tests). This makes CI verification reproducible locally.

🧱 Mocks/Fakes

• Consistent patch target – The tests patch drone_sim.datetime and drone_sim.random.*. This is correct, but be aware that if the module imports from datetime import datetime the patch path would need to change. Keeping the imports as import datetime (as you have) avoids that pitfall.
• Document mock rationale – Each @patch is accompanied by a comment, which is great. Consider moving those comments into a docstring for the test method to keep the decorator line clean.
• Avoid hard‑coded side‑effect lengths – The current mock_choice.side_effect list must match the exact number of calls. If the implementation adds another random.choice, the test will break with a StopIteration. Using a helper that returns a deterministic sequence based on an index (or a custom MockRandom class) can make the test more resilient to future changes.

Overall, the contribution is well‑structured, functional, and test‑driven. Addressing the minor security hardening, expanding test coverage, and polishing the documentation will make the utility production‑ready and easier for downstream users to adopt.