FCTL3314/HealthNutrition-Backend

This system is a Django-based backend service for nutritional product comparison and user health management. It provides a RESTful API for managing products, categories, and user profiles, while supporting features like calorie burning calculations and product comparisons. The architecture emphasizes type safety and testability through structured services, DTOs, and comprehensive automated testing.

A new API endpoint at /api/v1/auth/uid-token-check/ has been introduced to validate a user ID and token pair. This allows clients to verify the validity of a user's UID and token combination, returning a 204 No Content on success or 404 Not Found with error details if the UID or token is invalid.

api/v1/auth · high confidence

Introduced new services for calculating the time required to burn a specific number of calories through walking, running, and cycling. The domain logic is implemented in \calorie\_burning\_calculators.py\, providing core calculation capabilities, while \humanized\_calorie\_burning\_calculators.py\ adds a facade that returns human-readable time durations for these exercises.

api/v1/nutrition/services · high confidence

Users will now receive HTML-formatted emails for email verification and password reset flows. The new templates include personalized greetings, specific instructions for each action (verification code or reset link), and security disclaimers.

templates · high confidence

Introduced a new production environment configuration that orchestrates the application stack using Docker Compose. The setup includes a Gunicorn-based Django service, a Celery worker, and an Nginx reverse proxy with SSL termination via Certbot. The entrypoint script now executes database migrations and static file collection before starting the Gunicorn server, ensuring the application is ready to serve traffic in a production context.

docker/production · high confidence

New abstract base classes are now available in the common models module to standardize common functionality across the application. The \ViewsModelMixin\ provides a \views\ counter field, while \SlugModelMixin\ and \AutoSlugModelMixin\ handle automatic slug generation and unique slug management. These changes allow developers to easily add view counting and automatic slug generation to their Django models by simply inheriting from these mixins.

api/common/models · high confidence

The \api/common\ module now provides a centralized set of shared utilities for the API layer. This includes a custom Djoser settings configuration to manage permissions, a trigram-based search filter for improved text matching, and standardized email sending functions (including HTML support and task wrappers for Celery). Additionally, a suite of reusable test base classes is introduced to simplify and standardize testing for common API operations like retrieval, listing, creation, update, and deletion.

api/common · high confidence

The core application now includes standard Django entry points (ASGI, WSGI, and Celery configuration) and a central URL router that exposes the admin interface, Django Summernote editor routes, and the API v1 namespace. In debug mode, the media file server and Silk profiling tool are also enabled, providing immediate access to static assets and request tracing during development.

core · high confidence

The API application is initialized with a Django AppConfig, a root URL configuration that includes the v1 namespace, and a shared APIResponse class that standardizes error responses with detail, code, and messages fields. Additionally, the api/conftest.py file introduces pytest fixtures for users, categories, products, and other models, along with a test cache-clearing hook, supporting the testing of the API endpoints.

api · high confidence

The repository is initialized with essential configuration files including .dockerignore, .env.dist, .gitattributes, and .pre-commit-config.yaml, alongside the Django manage.py entry point. The README is updated to reflect the project's focus on nutritional product comparison, and the codebase is configured with pre-commit hooks for Black, Ruff, and Pyupgrade to enforce code quality standards.

(repo-wide) · high confidence

The API now supports creating, listing, and managing 'comparison groups'—collections of compared products. Users can add or remove products from their comparison groups via new endpoints at /api/v1/comparisons/add/ and /api/v1/comparisons/remove/. The /api/v1/comparisons/groups/ endpoint allows users to list, retrieve, and delete their own comparison groups, with support for filtering by a selected product and retrieving detailed nutritional averages (calories, protein, fat, carbs) for the group. A new endpoint at /api/v1/comparisons/groups/change-order/ allows reordering groups. The implementation includes new models (ComparisonGroup, Comparison), serializers, services, and permissions to enforce that users can only modify their own groups.

api/v1/comparisons · high confidence

The Category API has been extracted into its own application, providing a dedicated endpoint for categories. The API now returns detailed nutrition averages (calories, protein, fat, and carbs) for each category, calculated from associated products. This change includes new models, serializers, and viewsets that support searching by name or description and tracking view counts.

api/v1/categories · high confidence

Added new API endpoints for email verification and email updates. Users can now request a verification email via a new \UserSendEmailVerificationView\ and verify their email using \UserEmailVerifierView\. Additionally, a \UserChangeEmailView\ allows authenticated users to update their email address. These endpoints are backed by new services (\EVSenderService\, \UserEmailVerifierService\, \UserChangeEmailService\) and serializers, and are exposed under the \/api/v1/users/\ path with pagination and documentation support.

api/v1/users · high confidence

A new user\_profiles application has been added, introducing a UserProfile model and a corresponding admin interface for managing user profiles. Users can now update their profile information, including their about section, body weight, and profile image, through a dedicated update endpoint. The update service enforces a 10 MB limit on uploaded images and validates body weight within specified ranges. This change adds the backend infrastructure, serializers, and services required to support profile updates.

_api/v1/user\profiles · high confidence

The v1 API is now structured with dedicated URL routers for categories, products, comparisons, users, user profiles, comments, and authentication (token obtain/refresh). Additionally, schema and Swagger documentation endpoints are exposed at /schema/ and /docs/ respectively, providing API discovery and interactive documentation for developers.

api/v1 · high confidence

A new 'Nutrition' model has been added to the application, storing calories, protein, fat, and carbs as decimal or integer fields. This model includes database indexes on each nutritional field for performance. Corresponding Django admin configuration allows management of Nutrition records. Additionally, a 'CaloriesBurningTimeSerializer' has been introduced, providing output fields for walking, running, and cycling durations, indicating the start of a calorie-burning calculation feature.

api/v1/nutrition · medium confidence

A new Products API is introduced, providing endpoints to list, retrieve, and manage products. The API supports filtering by category slug and searching by name or description. Each product response includes a calculated 'healthfulness' score based on nutrition data (calories, protein, fat, carbs) using defined coefficients. Additionally, the retrieve endpoint returns 'calories\_burning\_time' for basic exercises, requiring an optional 'body\_weight' query parameter. The API uses slug-based lookups, implements custom pagination, and restricts write access to admins while allowing read access to all users.

api/v1/products · high confidence

The API now includes a new service for calculating calorie burning times for basic exercises, utilizing a dedicated calculator and serializer to return burn times. Additionally, a new service has been added to increment and cache product view counts, implementing the standard view-increase pattern with IP-based caching keys.

api/v1/products/services · high confidence

Added a suite of new utility functions to the API: code generation helpers (codes.py) for creating alphanumeric and digit-based codes; time utilities (time.py) for comparing datetime objects by specific attributes and rounding datetime fields; text utilities (text.py) for generating unique slugs; file size conversion functions (files.py) for bytes and megabytes; network helpers (network.py) to extract client IP addresses; error message templates (errors.py); and a model cache invalidation helper (models.py). These changes introduce new capabilities for code generation, datetime comparison, and file handling within the API utilities.

api/utils · high confidence

The project now includes a Dockerfile that sets up a Python 3.11 Alpine-based environment with Poetry for dependency management, distinguishing between development and production build stages. Additionally, a shell script (celery\_entrypoint.sh) was added to configure the Celery worker to run with eventlet and log to a specific file.

docker · high confidence

Introduced Pydantic-based schemas (User, EmailVerification) and corresponding Django ORM-to-DTO converters (UserConverter, EVConverter) to standardize how user and email verification data is transformed from the database models into structured data transfer objects.

api/v1/users/services · high confidence

An empty 'logs' directory has been added to the repository, ensuring the directory structure is preserved for logging output.

logs · low confidence

Empty \_\init\\_.py files were added to the migrations directories of the comments, comparisons, products, and users apps. This ensures each app has a proper Python package structure for Django migrations, which is a prerequisite for generating and running database migrations for these components.

(repo-wide) · high confidence

The comments API now uses a single Comment model backed by django-mptt to support nested replies, with parent-child relationships and tree traversal methods like get\_descendants(). The API returns comments sorted by creation date (newest first) and includes metadata such as has\_replies and replies\_count. A generic foreign key allows comments on any object type, currently restricted to Product. The endpoint supports creating, updating, and listing comments with pagination (16 per page) and cache invalidation on updates.

api/v1/comments · high confidence

Added new base classes and protocols in the \api/base\ package to standardize service and converter implementations. The \api/base/services.py\ file introduces an \IService\ protocol and an \AbstractConditionalIncreaseService\ (renamed from \ConditionalFieldIncreaseService\) that handles incrementing model fields based on conditions, including a \BaseViewsIncreaseService\ for tracking unique views via cache. Additionally, \api/base/converters.py\ defines an \IDjangoORMToDTOConverter\ protocol for type-safe model-to-DTO conversion, and \api/base/time\_providers.py\ provides an \ITimeProvider\ protocol with a \UTCTimeProvider\ implementation. These changes establish a reusable foundation for domain and infrastructure services, improving code structure and type safety.

api/base · high confidence

Users can now manage diets through a new backend structure. This change adds the core data models for diets, including DietType, Diet, and DietProduct, which link products to specific meals and users. Additionally, the Django admin interface is configured to allow administrators to view and search for DietType, Diet, and DietProduct records, with DietProduct displayed as an inline list within the Diet admin view.

api/v1/diets · high confidence

The email verification and user management logic has been restructured into new service classes. The \UserChangeEmailService\ now handles changing a user's email address with specific error handling for invalid passwords, duplicate emails, and same-email attempts. Email verification is managed by \EVSenderService\ and \UserEmailVerifierService\, which handle sending verification emails, respecting sending limits, and verifying codes with proper expiration and invalid code handling. Additionally, \create\_user\_with\_profile\ is now a dedicated function for user creation with profile association.

api/v1/users/services/infrastructure · medium confidence

The project's configuration has been reorganized into separate modules for base, local, production, and test environments. This change isolates environment-specific settings—such as database backends (SQLite for tests, PostgreSQL for local/production), email backends (console/dummy), and debug modes—while keeping shared configuration in a base file. As a result, the application now uses distinct settings files for each environment, improving clarity and security by preventing sensitive or environment-specific configurations from leaking between contexts.

core/settings · high confidence

Added API v1 comments tests; Added automated tests for the Product API; Added automated tests for the comparisons API and models; Added comprehensive test coverage for user email verification and change-email workflows; Added unit tests for the categories API views.

The project has switched from pip to Poetry as its primary package manager, introducing a pyproject.toml and poetry.lock file to manage Python dependencies and development tools. This change standardizes the build system, ensuring reproducible environments and simplifying the management of production, development, and testing dependencies.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 51 → 55 (+3.6)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 100 → 100 (-0.2)
• Architecture 98 → 73 (-24.9)
• Maturity 52 → 53 (+0.6)
• Readiness 46 → 44 (-1.3)
• Security 43 → 68 (+25.4)
• Domain Modelling 80 → 84 (+3.3)

• Change coupling: local.py ↔ production.py (core/settings/local.py)
• Coverage not included — suite not readable by the collector
• Critical CVE: [GHSA redacted] (poetry.lock)
• Critical CVE: [GHSA redacted] (poetry.lock)
• Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
• High CVE: [GHSA redacted] (poetry.lock)
• High CVE: [GHSA redacted] (poetry.lock)
• High CVE: [GHSA redacted] (poetry.lock)
• High CVE: [GHSA redacted] (poetry.lock)
• High CVE: [GHSA redacted] (poetry.lock)
• High CVE: [GHSA redacted] (poetry.lock)
• High CVE: [GHSA redacted] (poetry.lock)
• High CVE: [GHSA redacted] (poetry.lock)
• High IaC: DS-0025 (docker/production/nginx/Dockerfile)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• …and 20 more

• Banned license: gprof2dot
• Banned license: unidecode
• Critical CVE: [GHSA redacted] (poetry.lock)
• Critical CVE: [GHSA redacted] (poetry.lock)
• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• High CVE: [GHSA redacted] (poetry.lock)
• High CVE: [GHSA redacted] (poetry.lock)
• High CVE: [GHSA redacted] (poetry.lock)
• High CVE: [GHSA redacted] (poetry.lock)
• High CVE: [GHSA redacted] (poetry.lock)
• High CVE: [GHSA redacted] (poetry.lock)
• High CVE: [GHSA redacted] (poetry.lock)
• High CVE: [GHSA redacted] (poetry.lock)
• High IaC: DS-0025 (docker/production/nginx/Dockerfile)
• High IaC: DS-0025 (docker/production/nginx/Dockerfile)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• …and 48 more

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

FCTL3314/HealthNutrition-Backend was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.