feat: Implement comprehensive architectural guidelines and clean code standards

- Establish feature-based architecture with clear separation between Logic, Data, and Shared layers
- Define directory structure conventions for controllers, entities, DTOs, managers, mappers, models, processors, providers, repositories, and services
- Implement Symfony 7.4+ compliance with proper Request handling (UI layer only)
- Enforce PHP 8+ attributes usage instead of annotations
- Set up proper DTO usage in UseCases with immutable properties
- Configure repository pattern with interfaces in Logic layer and implementations in Data layer
- Implement strict separation of concerns with UI layer handling Request objects exclusively
- Define clear naming conventions (PascalCase for feature names)
- Add shared components directory for reusable elements across features
- Establish HTTP status code constants usage instead of magic numbers
- Configure proper file placement for controllers in UI/Frontend, UI/Api, and UI/CLI subdirectories
- Enforce modern PHP practices with explicit return types and strict typing

This commit lays the foundation for a maintainable, scalable Symfony 7.4+ application following clean architecture principles and modern coding standards.

.continue/rules/controller-feature-folder-structure.md

@@ -0,0 +1,9 @@
+---
+globs: UI/Controller/**/*.php
+description: When creating new controllers in the UI/Controller directory, a
+  corresponding feature subfolder should be created to organize related
+  controller files
+alwaysApply: true
+---
+
+All controllers in the UI/Controller directory must be placed within feature-specific subdirectories

.continue/rules/data-layer-file-placement.md

@@ -0,0 +1,9 @@
+---
+globs: src/Data/**
+description: This rule ensures that all implementation files belonging to the
+  Data layer are consistently organized under the /src/Data directory structure,
+  maintaining clear separation between Logic and Data layers.
+alwaysApply: true
+---
+
+All files in the Data layer must be placed within the /src/Data directory

.continue/rules/dto-location-rule.md

@@ -0,0 +1,10 @@
+---
+globs: src/Logic/**/DTO/*
+description: This rule ensures that all DTO (Data Transfer Object) files are
+  correctly placed within the Logic layer according to the feature-based
+  architecture, with proper naming conventions for feature directories and clear
+  separation of data transfer objects.
+alwaysApply: true
+---
+
+All DTO files in the Logic layer must be placed within /src/Logic/[FeatureName]/DTO directory, where [FeatureName] is a valid feature-specific subdirectory. If the FeatureName is unknown or ambiguous, developers must actively provide a proper feature name rather than defaulting to 'Unknown'.

.continue/rules/entity-directory-structure-with-feature-validation.md

@@ -0,0 +1,11 @@
+---
+globs: src/Data/*/Entity/*.php
+description: This rule enforces that entities are placed in feature-specific
+  directories under /src/Data/[FeatureName]/Entity. When [FeatureName] is
+  unknown or ambiguous, the developer must select an appropriate feature name
+  instead of automatically using a default 'Unknown' directory to maintain
+  proper architecture and code organization.
+alwaysApply: true
+---
+
+All entities must be located in /src/Data/[FeatureName]/Entity directory, where [FeatureName] is a valid feature-specific subdirectory. If the feature name cannot be determined, developers must actively provide a proper feature name rather than defaulting to 'Unknown'. This ensures consistent architectural separation.

.continue/rules/entity-directory-structure-with-php-attributes.md

@@ -0,0 +1,11 @@
+---
+globs: src/Data/*/Entity/*.php
+description: This rule enforces proper entity organization in the Data layer
+  with clear separation by feature. It mandates usage of modern PHP attributes
+  for Doctrine mappings instead of annotations to align with contemporary PHP
+  standards and Symfony best practices. When feature names cannot be determined,
+  explicit developer decisions are required rather than automatic defaults.
+alwaysApply: true
+---
+
+All entities must be placed in /src/Data/[FeatureName]/Entity directory, where [FeatureName] represents a valid feature-specific subdirectory. Entities must use modern PHP attributes (not annotations) for Doctrine mapping. When the FeatureName is unknown or ambiguous, developers must actively select an appropriate feature name rather than defaulting to 'Unknown'.

.continue/rules/entity-directory-structure.md

@@ -0,0 +1,10 @@
+---
+globs: src/Data/*/Entity/*.php
+description: This rule ensures consistent entity placement within the
+  feature-based architecture by requiring entities to be stored in a specific
+  directory structure under /src/Data/[FeatureName]/Entity, with proper Doctrine
+  configuration for each directory.
+alwaysApply: true
+---
+
+All entities must be located in /src/Data/[FeatureName]/Entity directory, where [FeatureName] is the feature-specific subdirectory. If [FeatureName] is unknown, use "Unknown" as the directory name.

.continue/rules/feature-based-architecture-rules.md

@@ -0,0 +1,9 @@
+---
+globs: src/**/*.php
+description: Enforce architectural rules for Feature-Based Development including
+  repository interface definition in Logic layer, implementations in Data layer,
+  and proper data flow through Services using DTOs.
+alwaysApply: true
+---
+
+Follow feature-based architecture with clear separation between Logic, Data, and Shared layers

.continue/rules/feature-name-validation-for-entities.md

@@ -0,0 +1,10 @@
+---
+globs: src/Data/*/Entity/*.php
+description: This rule requires that when entities are created and the feature
+  name cannot be determined, instead of defaulting to an 'Unknown' directory,
+  developers must actively select or define a proper feature name to maintain
+  clean architectural separation.
+alwaysApply: true
+---
+
+When creating entities, if [FeatureName] is unknown, prompt the user to provide a feature name rather than automatically using 'Unknown'. This ensures proper categorization of entities within the feature-based architecture.

.continue/rules/logic-layer-file-placement.md

@@ -0,0 +1,9 @@
+---
+globs: src/Logic/**
+description: This rule ensures that all implementation files belonging to the
+  Logic layer are consistently organized under the /src/Logic directory
+  structure, maintaining clear separation between Logic and other layers.
+alwaysApply: true
+---
+
+All files in the Logic layer must be placed within the /src/Logic directory

.continue/rules/manager-location-rule.md

@@ -0,0 +1,11 @@
+---
+globs: src/Logic/**/Manager/*
+description: This rule ensures that all manager implementations are correctly
+  placed within the Logic layer according to the feature-based architecture,
+  with proper naming conventions for feature directories. Managers serve as
+  orchestration layers that expose Provider and Processor methods while
+  implementing caching.
+alwaysApply: true
+---
+
+All manager implementations must be located in the Logic layer under feature-specific subdirectories: /src/Logic/[FeatureName]/Manager. Feature names must be properly capitalized and follow the PascalCase convention. Managers expose methods from Providers and Processors and implement caching functionality.

.continue/rules/mapper-location-rule.md

@@ -0,0 +1,9 @@
+---
+globs: src/Data/**/Mapper/*
+description: This rule ensures that all mapper implementations are correctly
+  placed within the Data layer according to the feature-based architecture, with
+  proper naming conventions for feature directories.
+alwaysApply: true
+---
+
+All mapper implementations must be located in the Data layer under feature-specific subdirectories: /src/Data/[FeatureName]/Mapper. Feature names must be properly capitalized and follow the PascalCase convention.

.continue/rules/minimal-comments-rule.md

@@ -0,0 +1,10 @@
+---
+globs: "**/*.php"
+description: Comments should only be used for complex logic, business rules,
+  non-obvious decisions, or explanations of why something is done (not what is
+  done). Code should be readable without comments. Remove all unnecessary
+  comments that don't add value to understanding the code.
+alwaysApply: true
+---
+
+Only add comments when they provide essential clarification that the code itself cannot convey. Avoid redundant or obvious comments; let code be self-documenting through clear naming and structure.

.continue/rules/model-directory-structure.md

@@ -0,0 +1,10 @@
+---
+globs: src/Logic/**/Models/*.php
+description: This rule ensures consistent architectural separation by placing
+  all model files in their respective feature-specific directories within the
+  Logic layer. It prevents improper placement of models and enforces clear
+  organization based on features.
+alwaysApply: true
+---
+
+All model files in the Logic layer must be placed within /src/Logic/[FeatureName]/Models directory, where [FeatureName] is a valid feature-specific subdirectory. If the FeatureName is unknown or ambiguous, developers must actively provide a proper feature name rather than defaulting to 'Unknown'.

.continue/rules/model-location-rule.md

@@ -0,0 +1,10 @@
+---
+globs: src/Logic/**/Models/*
+description: This rule ensures that all model files are correctly placed within
+  the Logic layer according to the feature-based architecture, with proper
+  naming conventions for feature directories and clear separation of business
+  logic models.
+alwaysApply: true
+---
+
+All model files in the Logic layer must be placed within /src/Logic/[FeatureName]/Models directory, where [FeatureName] is a valid feature-specific subdirectory. If the FeatureName is unknown or ambiguous, developers must actively provide a proper feature name rather than defaulting to 'Unknown'.

.continue/rules/no-closing-php-tag.md

@@ -0,0 +1,8 @@
+---
+globs: "**/*.php"
+description: In PHP files, omit the closing ?> tag to prevent issues with
+  whitespace and ensure consistent file handling
+alwaysApply: true
+---
+
+Do not include the closing PHP tag (?>) at the end of PHP files

.continue/rules/processor-interface-location-rule.md

@@ -0,0 +1,9 @@
+---
+globs: src/Logic/**/Processor/*
+description: This rule ensures that all processor interface definitions are
+  correctly placed within the Logic layer according to the feature-based
+  architecture, with proper naming conventions for feature directories.
+alwaysApply: true
+---
+
+All processor interfaces must be located in the Logic layer under feature-specific subdirectories: /src/Logic/[FeatureName]/Processor. Feature names must be properly capitalized and follow the PascalCase convention.

.continue/rules/processor-location-rule.md

@@ -0,0 +1,9 @@
+---
+globs: src/Data/**/Processor/*
+description: This rule ensures that all processor implementations are correctly
+  placed within the Data layer according to the feature-based architecture, with
+  proper naming conventions for feature directories.
+alwaysApply: true
+---
+
+All processor implementations must be located in the Data layer under feature-specific subdirectories: /src/Data/[FeatureName]/Processor. Feature names must be properly capitalized and follow the PascalCase convention.

.continue/rules/provider-and-processor-model-usage.md

@@ -0,0 +1,9 @@
+---
+globs: src/Data/**/*{Provider,Processor}.php
+description: Ensure that data providers and processors in the Data layer depend
+  exclusively on models defined in the Logic layer's Models directory,
+  maintaining proper architectural separation between layers
+alwaysApply: true
+---
+
+Providers and Processors in the Data layer must only use models from the Logic layer's Models directory

.continue/rules/provider-interface-location-rule.md

@@ -0,0 +1,9 @@
+---
+globs: src/Logic/**/Provider/*
+description: This rule ensures that all provider interface definitions are
+  correctly placed within the Logic layer according to the feature-based
+  architecture, with proper naming conventions for feature directories.
+alwaysApply: true
+---
+
+All provider interfaces must be located in the Logic layer under feature-specific subdirectories: /src/Logic/[FeatureName]/Provider. Feature names must be properly capitalized and follow the PascalCase convention.

.continue/rules/provider-location-rule.md

@@ -0,0 +1,9 @@
+---
+globs: src/Data/**/Provider/*
+description: This rule ensures that all provider implementations are correctly
+  placed within the Data layer according to the feature-based architecture, with
+  proper naming conventions for feature directories.
+alwaysApply: true
+---
+
+All provider implementations must be located in the Data layer under feature-specific subdirectories: /src/Data/[FeatureName]/Provider. Feature names must be properly capitalized and follow the PascalCase convention.

.continue/rules/provider-processor-repository-relationship-rule.md

@@ -0,0 +1,9 @@
+---
+description: This rule describes the architectural relationships between
+  components in your Symfony application, clarifying how Providers and
+  Processors interact with data sources and how they relate to repository
+  patterns and integration APIs.
+alwaysApply: true
+---
+
+Providers deliver data to the Logic layer. Processors write data. The Logic layer defines requirements through interfaces. Providers and Processors can utilize repositories or integration APIs for data access.

.continue/rules/repository-implementation-location.md

@@ -0,0 +1,8 @@
+---
+globs: src/Features/*/Data/Repository/*.php
+description: The Data layer handles concrete storage mechanisms while keeping
+  business logic unaware of these details.
+alwaysApply: true
+---
+
+Repository implementations must be located in the Data layer, using entities for persistence.

.continue/rules/repository-interface-definition-location.md

@@ -0,0 +1,8 @@
+---
+globs: src/Features/*/Logic/Repository/*.php
+description: Ensures that business logic is decoupled from data access
+  implementation details, promoting flexibility and testability.
+alwaysApply: true
+---
+
+Repository interfaces must be defined in the Logic layer, not in the Data layer.

.continue/rules/repository-location-rule.md

@@ -0,0 +1,9 @@
+---
+globs: src/Data/**/Repository/*
+description: This rule ensures that all repository implementations are correctly
+  placed within the Data layer according to the feature-based architecture, with
+  proper naming conventions for feature directories.
+alwaysApply: true
+---
+
+All repository implementations must be located in the Data layer under feature-specific subdirectories: /src/Data/[FeatureName]/Repository. Feature names must be properly capitalized and follow the PascalCase convention.

.continue/rules/repository-location.md

@@ -0,0 +1,9 @@
+---
+globs: src/Data/*/Repository/*.php
+description: Enforce consistent placement of repository implementations within
+  feature-specific directories in the Data layer, ensuring proper organization
+  by feature name.
+alwaysApply: true
+---
+
+All repository implementations must be located in the Data layer under feature-specific subdirectories: /src/Data/[FeatureName]/Repository. Feature names must be properly capitalized and follow the PascalCase convention.

.continue/rules/repository-pattern.md

@@ -0,0 +1,9 @@
+---
+globs: "**/Repository/*.php,**/Data/**/*Repository*.php,**/Logic/**/*Repository*.php"
+description: Enforce clear separation between Logic, Data, and Shared layers by
+  ensuring proper placement of repositories according to domain-driven design
+  principles.
+alwaysApply: true
+---
+
+All repository implementations must be located in the Data layer and use entities for persistence. Repository interfaces must be defined in the Logic layer, not in the Data layer. Services in the Logic layer must depend on repository interfaces defined in their respective Logic folder.

.continue/rules/request-handling-in-controllers.md

@@ -0,0 +1,10 @@
+---
+globs: src/UI/**/*.php
+description: Defines best practices for handling HTTP requests in Symfony 7.
+  Ensures strict separation of concerns by transforming raw request data into
+  immutable DTOs at the boundary of the UI layer, preventing leakage of
+  infrastructure details into business logic.
+alwaysApply: true
+---
+
+The Request object must only be used in the UI layer (Controllers). Immediately convert request data into DTOs located in /src/Logic/[FeatureName]/DTO before passing them to UseCases. Use $request->getPayload() for JSON APIs, $request->query/request for forms, and $request->attributes for route parameters. Never pass the Request object to Logic or Data layers.

.continue/rules/service-dependency-on-repository-interfaces.md

@@ -0,0 +1,8 @@
+---
+globs: src/Features/*/Logic/Service/*.php
+description: This enforces dependency inversion, allowing for easy mocking and
+  testing without touching actual data sources.
+alwaysApply: true
+---
+
+Services in the Logic layer must depend on repository interfaces defined in their respective Logic folder.

.continue/rules/shared-components-location.md

@@ -0,0 +1,7 @@
+---
+globs: src/Shared/**/*.php
+description: Reduces duplication and promotes consistency throughout the application.
+alwaysApply: true
+---
+
+Common components like DTOs, Interfaces, Helpers, and Exceptions are placed in the Shared layer for reuse across features.

.continue/rules/shared-layer-file-placement.md

@@ -0,0 +1,10 @@
+---
+globs: src/Shared/**
+description: This rule ensures that all cross-cutting implementation files
+  belonging to the Shared layer are consistently organized under the /src/Shared
+  directory structure, maintaining clear separation between shared components
+  and feature-specific layers.
+alwaysApply: true
+---
+
+All files in the Shared layer must be placed within the /src/Shared directory

.continue/rules/symfony-74-request-handling.md

@@ -0,0 +1,8 @@
+k---
+globs: "**/UI/**/*Controller*.php"
+description: Ensures compliance with Symfony 7.4 deprecations and enforces
+  strict separation of concerns by isolating Request handling to the UI layer.
+alwaysApply: true
+---
+
+In Symfony 7.4+, never use the deprecated `Request::get()` method. Instead, use `$request->attributes` for route parameters, `$request->query` for query parameters, and `$request->getPayload()` for body data (JSON/Forms). Immediately convert request data into DTOs in Controllers. Never pass the Request object to Logic or Data layers.

.continue/rules/symfony-dto-validation-strategy.md

@@ -0,0 +1,11 @@
+---
+globs: "**/UI/**/*.php, **/Logic/**/DTO/*.php"
+description: Defines the standard for input validation in Symfony 7 projects.
+  Logic layer DTOs hold the validation rules via attributes. The UI layer is
+  responsible for executing the validation using the injected validator service,
+  ensuring clean separation of concerns and preventing invalid data from
+  entering the business logic.
+alwaysApply: false
+---
+
+All input validation must be performed on DTOs located in /src/Logic/[FeatureName]/DTO using PHP 8 #[Assert\...] attributes. Controllers in the UI layer (/src/UI/...) must inject Symfony\Component\Validator\Validator\ValidatorInterface, validate the DTO before passing it to UseCases, and handle validation errors immediately.

.continue/rules/ui-layer-file-placement.md

@@ -0,0 +1,9 @@
+---
+globs: src/UI/**
+description: This rule ensures that all implementation files belonging to the UI
+  layer are consistently organized under the /src/UI directory structure,
+  maintaining clear separation between UI and other layers.
+alwaysApply: true
+---
+
+All files in the UI layer must be placed within the /src/UI directory

.continue/rules/ui-layer-separation.md

@@ -0,0 +1,9 @@
+---
+globs: "**/*.php"
+description: Diese Regel stellt sicher, dass die UI-Schicht klar in Frontend,
+  API und CLI unterteilt ist, was die Wartbarkeit und Skalierbarkeit des
+  Projekts verbessert.
+alwaysApply: true
+---
+
+Alle Dateien in der UI-Schicht müssen in feature-spezifische Unterverzeichnisse unter /src/UI platziert werden: /src/UI/Frontend, /src/UI/Api oder /src/UI/CLI.

.continue/rules/ui-layer-structure.md

@@ -0,0 +1,10 @@
+---
+globs: src/UI/**/*
+description: Ensures proper separation of concerns in the UI layer by organizing
+  controllers and related components into feature-specific subdirectories for
+  Frontend (web UI), Api (REST/GraphQL endpoints), and CLI (command-line
+  interface). This promotes clear architectural boundaries and maintainability.
+alwaysApply: true
+---
+
+The UI layer must be divided into three subdirectories: Frontend, Api, and CLI under /src/UI. Controllers and related UI components must be organized into these respective subdirectories based on their purpose: Frontend for web UI controllers, Api for REST/GraphQL endpoints, and CLI for command-line interface commands.

.continue/rules/use-modern-php-attributes.md

@@ -0,0 +1,10 @@
+---
+globs: "**/*.php"
+description: Ensure all new code uses modern PHP attribute syntax rather than
+  legacy annotation syntax for better type safety and code clarity. This applies
+  to routing, validation, security, and other Symfony components that support
+  attributes.
+alwaysApply: true
+---
+
+Always use PHP attributes instead of annotations for routing and other Symfony features in PHP 8+ projects

.continue/rules/use-symfony-http-status-constants.md

@@ -0,0 +1,9 @@
+---
+globs: "**/UI/**/*Controller*.php"
+description: Improves code readability and maintainability by using
+  self-documenting constants instead of magic numbers for HTTP status codes.
+  Applies to all controllers in the UI layer and any response handling.
+alwaysApply: true
+---
+
+Always use Symfony Response HTTP status constants (e.g., Response::HTTP_OK, Response::HTTP_CREATED, Response::HTTP_NOT_FOUND) instead of magic numbers (e.g., 200, 201, 404) when setting HTTP status codes in controllers and responses.

.continue/rules/usecase-input-via-dtos.md

@@ -0,0 +1,8 @@
+---
+globs: src/Logic/**/UseCase/*.php, src/Logic/**/DTO/*.php
+description: Enforces the use of DTOs for UseCase entry points to maintain clean
+  architecture, immutability, and type safety.
+alwaysApply: true
+---
+
+UseCase methods must accept DTOs (Data Transfer Objects) for input parameters instead of raw arrays or Request objects. DTOs must be located in the /src/Logic/[FeatureName]/DTO directory and should be immutable (readonly properties). This ensures decoupling between the Logic and UI layers. Simple primitive inputs (like a single ID) may be passed directly, but complex data structures require DTOs.

.continue/rules/usecase-location-rule.md

@@ -0,0 +1,10 @@
+---
+globs: src/Logic/**/UseCase/*
+description: This rule ensures that all use case implementations are correctly
+  placed within the Logic layer according to the feature-based architecture,
+  with proper naming conventions for feature directories. Use cases represent
+  specific business logic operations.
+alwaysApply: true
+---
+
+All use case implementations must be located in the Logic layer under feature-specific subdirectories: /src/Logic/[FeatureName]/UseCase. Feature names must be properly capitalized and follow the PascalCase convention.

.continue/rules/workflow-for-multiple-usecases.md

@@ -0,0 +1,10 @@
+---
+globs: src/Logic/**/*Controller.php, src/Logic/**/Manager/*.php
+description: Workflows werden verwendet, wenn eine Controller-Aktion oder ein
+  Manager mehrere UseCases koordinieren muss. Dies sorgt für saubere Trennung
+  von Concerns, Wiederverwendbarkeit einzelner UseCases und bessere Testbarkeit.
+  Der Workflow definiert die Reihenfolge und Abhängigkeiten zwischen UseCases.
+alwaysApply: false
+---
+
+Wenn mehrere UseCases kombiniert oder in einer bestimmten Reihenfolge ausgeführt werden müssen, ist ein Workflow zu verwenden. Workflows orchestrieren die Ausführung mehrerer UseCases und kapseln komplexe Geschäftsprozesse. Sie gehören in /src/Logic/[FeatureName]/Workflow und werden vom Manager aufgerufen, nicht direkt vom Controller.