lubaskinc0de/loyalty

This system is a loyalty management platform that enables businesses to create and manage loyalty programs, branches, and member memberships. It provides a RESTful API for handling user authentication, tracking payments, calculating discounts, and maintaining financial records. The architecture is built on Flask and SQLAlchemy, utilizing PostgreSQL for data persistence and MinIO for file storage, replacing previous Redis and FastAPI components.

Introduced a new Value Object for roles within the loyalty domain, defining two distinct types: 'client' and 'business'. This change establishes a structured enumeration for role-based logic in the domain layer.

src/loyalty/domain/vo · high confidence

Users can now create, read, update, and delete business branches through new application service classes. The implementation includes a CreateBusinessBranch handler that generates a unique ID and stores branch details including location and contact information. A DeleteBusinessBranch handler enforces access control, ensuring users can only delete branches they are authorized to edit. The ReadBusinessBranch and ReadBusinessBranches handlers provide single and paginated list retrieval with appropriate validation and error handling. Additionally, a DTO layer converts domain entities to data transfer objects for API responses.

_src/loyalty/application/business\branch · high confidence

The loyalty application now supports creating, reading, and deleting payments. Users can create new payments with associated discounts and bonus calculations, retrieve specific payment details, and remove payments, with access controlled by business and membership affiliations.

src/loyalty/application/payment · high confidence

A new command-line interface has been added to the loyalty system, allowing users to run database migrations and generate new migration scripts via the CLI. This provides a direct way to manage the database schema without relying on the Flask application's internal bootstrap process.

src/loyalty/bootstrap · high confidence

Added the Flask application entrypoint in src/loyalty/bootstrap/entrypoint/flask\_api.py, which configures the Flask app, registers blueprints and error handlers, sets up logging, and launches the application using Gunicorn on port 5000 with multi-process workers.

src/loyalty/bootstrap/entrypoint · high confidence

Added SQLAlchemy-based database gateway implementations for core loyalty domain entities, including bonus balances, business and branch management, client and user authentication, loyalty cataloging, membership tracking, payment recording, and aggregate statistics. These adapters provide the data access layer for the loyalty module, enabling operations such as querying loyalty programs, managing business branches, and tracking member interactions.

src/loyalty/adapters/db/gateway · high confidence

The loyalty system now uses a new SQLAlchemy-based database adapter. This introduces a database connection provider that manages SQLAlchemy engines and sessions, alongside a registry for ORM mappings. The adapter exposes table definitions for core entities including users, clients, businesses, business branches, payments, and loyalty memberships, as well as a many-to-many association table linking loyalties to branches.

src/loyalty/adapters/db · medium confidence

Added application-layer services for managing business entities (create, read, attach/detach avatars, and view statistics), client profiles (create and read), and system-wide statistics (payments, clients, businesses). These new modules enable users to create and manage business accounts, upload and update profile images, and access aggregated loyalty statistics.

src/loyalty/application/business · high confidence

Users can now create, read, and delete loyalty memberships. The new application layer includes commands for creating a membership (with targeting validation), deleting a membership (with edit permission checks), and reading membership data (including a paginated list filtered by business ID).

src/loyalty/application/membership · high confidence

Added new protocol interfaces for user and access token gateways, defining methods for retrieving and inserting users and managing access tokens.

src/loyalty/adapters/common · high confidence

Added new files in the loyalty authentication adapter: a WebUser and TelegramUser data models, an Argon2-based password hasher, an AccessToken entity, and a WebAuthProvider that handles user registration by hashing passwords and inserting users into the gateway. This provides the core web authentication mechanism for the loyalty system.

src/loyalty/adapters/auth · high confidence

Added new domain entities including Loyalty, Business, BusinessBranch, Client, User, Payment, and LoyaltyMembership, along with a BranchAffiliationGateway protocol. These classes define the core data structures and access control logic for the loyalty program, such as discount application, membership management, and role-based read/edit permissions.

src/loyalty/domain/entity · high confidence

Added new shared type definitions for the loyalty domain, including a Gender enum (MALE, FEMALE) and a LoyaltyTimeFrame enum (CURRENT, ALL) to standardize data representation across the system.

src/loyalty/domain · high confidence

The loyalty application now defines four new abstract protocols in the common package to standardize cross-cutting concerns. AuthProvider defines the contract for binding a user to an authentication context. FileManager specifies upload and removal operations for binary data. Idp.py introduces three identity providers (ClientIdProvider, BusinessIdProvider, and UserIdProvider) to retrieve current user, client, or business entities. UoW establishes a Unit of Work interface with commit, add, delete, and flush operations. These protocols provide a consistent abstraction layer for authentication, file handling, identity resolution, and transaction management within the loyalty application.

src/loyalty/application/common · high confidence

Adds new data models for business branches, including a form for creating branches with location and contact details, and a data transfer object for reading branch information. This change introduces the necessary structures to support the business branch functionality.

_src/loyalty/application/data\model · medium confidence

Adds new database table definitions for the loyalty domain, including tables for users, clients, businesses, business branches, loyalty programs, memberships, payments, and access tokens. The schema supports a many-to-many relationship between loyalty programs and business branches, and links payments to clients, loyalty programs, memberships, businesses, and branches. This establishes the data model for managing loyalty programs, member associations, and associated financial transactions.

src/loyalty/adapters/db/table · high confidence

Added protocol-based gateway interfaces for key domain entities including loyalty programs, memberships, clients, businesses, and payments. These abstractions define the data access layer for the loyalty application, enabling the implementation of specific storage mechanisms for each entity.

src/loyalty/application/common/gateway · high confidence

Adds a new application-layer exception hierarchy under \src/loyalty/application/exceptions\, defining specific error classes for business, client, loyalty program, membership, and payment domains (e.g., \BusinessAlreadyExistsError\, \LoyaltyDoesNotExistError\). Additionally, introduces \CreateUser\ and \ReadUser\ application commands that handle user creation and retrieval, integrating with the unit of work and authentication provider.

src/loyalty/application/exceptions · high confidence

The loyalty system's web presentation layer is now fully implemented, providing a complete set of RESTful API endpoints for managing businesses, branches, memberships, and loyalty programs. Users can now sign up, log in, and manage their accounts via the \/user\ and \/login\ routes. The platform exposes CRUD operations for business entities (\/business\, \/business/\<id\>/branch\), loyalty configurations (\/loyalty\), and payment records (\/payment\). A public-facing landing page at the root \/\ displays business statistics and partner information, while a robust error handling system ensures consistent JSON responses for all API interactions.

src/loyalty/presentation · high confidence

Users can now create, read, update, and delete loyalty programs. This includes defining program details (name, description, dates, monetary values, age/gender filters), retrieving specific programs or paginated lists with access control, modifying existing programs, and removing them. The implementation introduces the application layer components (interactors, DTOs, forms) required to support these operations.

src/loyalty/application/loyalty · medium confidence

The loyalty module now includes a new API client (api\_client.py) that provides methods for creating and reading clients, businesses, business branches, and loyalty data, as well as user authentication and profile reading. A new image utility (image\_utils.py) validates image files, and a Minio-based file manager (minio.py) handles uploading and removing images. Additionally, the configuration loader (config\_loader.py) has been updated to support JWT secrets and Minio storage settings, replacing previous Redis configuration.

src/loyalty/adapters · high confidence

The legacy 'crudik' module and its associated infrastructure have been removed. This includes the deletion of database and Redis adapters, the Yandex GPT integration, and the FastAPI entry point and routing configuration. Additionally, the dependency injection container, CLI bootstrap scripts, and exception handling logic specific to the old architecture have been eliminated, leaving only the new 'loyalty' module.

src/crudik · high confidence

The loyalty service now uses a centralized dependency injection container (via the \dishka\ library) to manage application components. This includes wiring up authentication adapters (Argon2, JWT, Minio), database gateways (SQLAlchemy), and all application commands/queries (e.g., CreateLoyalty, ReadBusiness, CalcDiscount) through a unified \container.py\ and provider modules (\adapter\, \command\, \data\, \config\, \gateway\). This replaces the previous ad-hoc or implicit wiring, making the service's internal structure more explicit and testable.

src/loyalty/bootstrap/di · high confidence

The database schema has been updated to support the loyalty program's core entities and relationships. This includes the creation of tables for \loyalty\, \payment\, \loyalty\_membership\, and \business\_branch\, alongside a new association table \loyalties\_to\_branches\_table\ to link them. The \payment\ table was extended with \bonus\_spent\ and \discount\_sum\ fields, while the \loyalty\ table received a \money\_for\_bonus\ field. Additionally, the \users\ table was restructured to include \client\_id\ and \business\_id\ foreign keys, and the \client\ table had its \city\ column removed. Several migrations also added unique constraints to ensure data integrity across the new structure.

src/loyalty/adapters/db/alembic · high confidence

The development environment has been restructured with new configuration files for Minio and PostgreSQL, including environment variables for S3 and database connections. The Nginx configuration has been updated to include proxy settings for Swagger UI, static files, and file storage, along with increased client body size limits.

.config · medium confidence

The IDP adapter now handles authentication via JWT tokens. It introduces an AccessTokenProcessor for encoding and verifying tokens, and a Flask-based parser that validates the Authorization header, checks the token against the database, and resolves the current user, client, or business identity. This replaces the previous authentication mechanism with a structured, token-based approach.

src/loyalty/adapters/auth/idp · medium confidence

The development environment has been significantly restructured. The application now uses PostgreSQL with PostGIS extensions instead of the previous database setup, and Redis has been removed in favor of MinIO for file/object storage. The Docker Compose configuration has been split into separate files for development and testing, with dedicated Dockerfiles for the test environment. The main application container no longer includes test dependencies or test code, and the build process has been updated to use Python 3.13.3-alpine3.21 with curl installed.

(repo-wide) · high confidence

Added new application-layer components for the loyalty system: a read interactor to retrieve a member's bonus balance and a calculation interactor to apply loyalty discounts to a purchase amount. These new modules enforce membership ownership and client identity checks before exposing balance data or computing discount amounts.

src/loyalty/application/bonus · high confidence

Added a new payment service module that defines constants for service income (5%) and bonus balance coefficients (8%), and provides functions to validate payment eligibility and calculate service income and bonus accruals based on purchase amounts and balances.

src/loyalty/domain/service · high confidence

The loyalty application module has been reorganized, with files moved from the previous 'crudik' package to 'src/loyalty/application'. A new shared types file was added, defining constants for pagination limits and a custom phone number type for Russia. Additionally, the 'Ping' service's execute method was changed from asynchronous to synchronous.

src/loyalty/application · medium confidence

A new exception class, WebUserAlreadyExistsError, has been added to the loyalty module's exception hierarchy. This change also involves moving the exceptions module to a new location within the codebase.

src/loyalty/adapters/exceptions · medium confidence

Add integration tests for user and client APIs; Added integration tests for bonus calculation and reading; Added integration tests for business endpoints; Added integration tests for loyalty management; Added integration tests for membership CRUD operations; Added integration tests for payment operations; Added test assets for hello scenarios; Added test infrastructure for loyalty and business domain models; Removed obsolete e2e test infrastructure.

The project has been renamed from 'crudik' to 'loyalty' and the Python version requirement raised to 3.13. Several dependencies were updated to newer versions, including aiohttp (3.11.13 to 3.12.15), adaptix (3.0.0b9 to 3.0.0b11), dishka (1.4.2 to 1.7.2), sqlalchemy (2.0.37 to 2.0.43), and alembic (1.14.0 to 1.16.5). New dependencies such as flask, gunicorn, pydantic, and psycopg2 were added, while fastapi and redis were removed. Test tooling was also updated, with pytest upgraded from 8.3.5 to 8.4.2 and pytest-asyncio from 0.25.3 to 1.2.0.

(dependencies) · medium confidence

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

• CAI 49 → 52 (+3.1)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 100 → 99 (-0.7)
• Architecture 89 → 65 (-23.6)
• Maturity 57 → 56 (-0.2)
• Readiness 36 → 39 (+3.5)
• Security 52 → 70 (+18.2)
• Accessibility 70 → 70 (+0.0)

• Change coupling: adapter.py ↔ sign_up.py (src/loyalty/bootstrap/di/providers/adapter.py)
• Change coupling: api_client.py ↔ exc_handler.py (src/loyalty/adapters/api_client.py)
• Change coupling: api_client.py ↔ root.py (src/loyalty/adapters/api_client.py)
• Change coupling: business.py ↔ client.py (src/loyalty/presentation/web/flask_api/business.py)
• Change coupling: command.py ↔ root.py (src/loyalty/bootstrap/di/providers/command.py)
• Change coupling: command.py ↔ sign_up.py (src/loyalty/bootstrap/di/providers/command.py)
• Change coupling: create.py ↔ create.py (src/loyalty/application/business/create.py)
• Change coupling: sign_up.py ↔ client.py (src/loyalty/presentation/web/controller/sign_up.py)
• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
• 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)
• High: security finding (details withheld)
• High: security finding (details withheld)
• Medium IaC: CKV_DOCKER_3 (Dockerfile)
• Medium IaC: CKV_DOCKER_7 (Dockerfile.swagger)
• …and 3 more

• Banned license: psycopg
• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• Duplicated block (11 lines × 4) (src/loyalty/application/business_branch/delete.py)
• Duplicated block (13 lines × 2) (src/loyalty/adapters/db/alembic/migrations/versions/7f305bb8adef_change_bonus_income_field_on_payment_to_.py)
• Duplicated block (5 lines × 2) (src/loyalty/adapters/db/alembic/migrations/versions/b7c63e7f7cd1_business.py)
• Duplicated block (7 lines × 2) (src/loyalty/adapters/db/alembic/migrations/versions/1c0e2700f275_remove_tables.py)
• Duplicated block (7 lines × 3) (src/loyalty/adapters/db/alembic/migrations/versions/5493b7169389_rm_city.py)
• Duplicated block (8 lines × 2) (src/loyalty/application/business_branch/read.py)
• Duplicated block (9 lines × 4) (src/loyalty/adapters/db/gateway/business.py)
• 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)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• …and 25 more

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

lubaskinc0de/loyalty 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.