feat(arch): initialize specialized documentation for new architectures and refactor diagrams

architectures/clean-architecture/data-flow.md

@@ -0,0 +1,26 @@
+# Clean Architecture - Data Flow
+
+## Request and Event Lifecycle
+
+```mermaid
+sequenceDiagram
+    participant User
+    participant Controller
+    participant UseCase
+    participant Entity
+    participant Repository
+    participant Database
+
+    User->>Controller: HTTP Request
+    Controller->>UseCase: Execute Request DTO
+    UseCase->>Entity: Apply Business Rules
+    UseCase->>Repository: Fetch/Save Data
+    Repository->>Database: Query
+    Database-->>Repository: Result
+    Repository-->>UseCase: Entity
+    UseCase-->>Controller: Response DTO
+    Controller-->>User: HTTP Response
+```
+
+### Constraints
+- Dependency rule always points inwards towards the domain.

architectures/clean-architecture/folder-structure.md

@@ -0,0 +1,25 @@
+# Clean Architecture - Folder Structure
+
+## Layering publisher/subscriber logic
+
+```mermaid
+graph TD
+    App[src/] --> Web[infrastructure/web]
+    App --> Db[infrastructure/db]
+    App --> Core[core/]
+    Core --> UseCases[use-cases/]
+    Core --> Entities[entities/]
+    classDef default fill:#e1f5fe,stroke:#03a9f4,stroke-width:2px,color:#000;
+    classDef component fill:#e8f5e9,stroke:#4caf50,stroke-width:2px,color:#000;
+    classDef layout fill:#f3e5f5,stroke:#9c27b0,stroke-width:2px,color:#000;
+
+    class App layout;
+    class Web component;
+    class Db component;
+    class Core layout;
+    class UseCases component;
+    class Entities component;
+```
+
+### Constraints
+- Inner layers cannot import from outer layers.

architectures/clean-architecture/implementation-guide.md

@@ -0,0 +1,25 @@
+# Clean Architecture - Implementation Guide
+
+## Code patterns and Anti-patterns
+
+### Entity Relationships
+
+```mermaid
+classDiagram
+    class UseCase {
+        +execute()
+    }
+    class Entity {
+        +validate()
+    }
+    class RepositoryInterface {
+        <<interface>>
+        +save()
+    }
+    UseCase --> Entity
+    UseCase --> RepositoryInterface
+```
+
+### Rules
+- Dependency Inversion Principle must be strictly followed.
+- Entities encapsulate the most general and high-level rules.

architectures/clean-architecture/readme.md

@@ -0,0 +1,34 @@
+---
+description: Vibe coding guidelines and architectural constraints for Clean Architecture within the Architecture domain.
+technology: Clean Architecture
+domain: Architecture
+level: Senior/Architect
+version: Agnostic
+tags: [architecture, system-design, clean-architecture, best-practices]
+ai_role: Senior Architect
+last_updated: 2026-03-22
+---
+
+<div align="center">
+  # 🏛️ Clean Architecture Production-Ready Best Practices
+</div>
+
+---
+
+Этот инженерный директив определяет **лучшие практики (best practices)** для архитектуры Clean Architecture. Данный документ спроектирован для обеспечения максимальной масштабируемости, безопасности и качества кода при разработке приложений корпоративного уровня.
+
+# Context & Scope
+- **Primary Goal:** Предоставить строгие архитектурные правила и практические паттерны для создания масштабируемых систем.
+- **Description:** A concept created by Robert C. Martin (Uncle Bob). It separates a project into concentric rings. The main rule is the Dependency Rule: dependencies can only point inward.
+
+## Map of Patterns
+- 📊 [**Data Flow:** Request and Event Lifecycle](./data-flow.md)
+- 📁 [**Folder Structure:** Layering logic](./folder-structure.md)
+- ⚖️ [**Trade-offs:** Pros, Cons, and System Constraints](./trade-offs.md)
+- 🛠️ [**Implementation Guide:** Code patterns and Anti-patterns](./implementation-guide.md)
+
+## Core Principles
+
+1. **Isolation & Testability:** Changing a single feature doesn't break the entire business process.
+2. **Strict Boundaries:** Enforce rigid structural barriers between business logic and infrastructure.
+3. **Decoupling:** Decouple how data is stored from how it is queried and displayed.

architectures/clean-architecture/trade-offs.md

@@ -0,0 +1,12 @@
+# Clean Architecture - Trade-offs
+
+## Pros, Cons, and System Constraints
+
+### Pros
+- High testability.
+- Framework agnostic.
+- Database agnostic.
+
+### Cons
+- Increased boilerplate and indirection.
+- Steep learning curve for beginners.

architectures/cqrs/data-flow.md

@@ -0,0 +1,27 @@
+# CQRS - Data Flow
+
+## Request and Event Lifecycle
+
+```mermaid
+sequenceDiagram
+    participant Client
+    participant CommandBus
+    participant CommandHandler
+    participant WriteDB
+    participant EventBus
+    participant QueryHandler
+    participant ReadDB
+
+    Client->>CommandBus: Send Command (Mutate)
+    CommandBus->>CommandHandler: Execute
+    CommandHandler->>WriteDB: Save state
+    CommandHandler->>EventBus: Publish Event
+    EventBus->>ReadDB: Update Read Model
+    Client->>QueryHandler: Request Data (Read)
+    QueryHandler->>ReadDB: Fetch
+    ReadDB-->>QueryHandler: Data
+    QueryHandler-->>Client: Response
+```
+
+### Constraints
+- Strict separation between mutating operations (Commands) and reading operations (Queries).

architectures/cqrs/folder-structure.md

@@ -0,0 +1,23 @@
+# CQRS - Folder Structure
+
+## Layering publisher/subscriber logic
+
+```mermaid
+graph TD
+    App[src/] --> Commands[commands/]
+    App --> Queries[queries/]
+    Commands --> HandlersC[handlers/]
+    Queries --> HandlersQ[handlers/]
+    classDef default fill:#e1f5fe,stroke:#03a9f4,stroke-width:2px,color:#000;
+    classDef component fill:#e8f5e9,stroke:#4caf50,stroke-width:2px,color:#000;
+    classDef layout fill:#f3e5f5,stroke:#9c27b0,stroke-width:2px,color:#000;
+
+    class App layout;
+    class Commands layout;
+    class Queries layout;
+    class HandlersC component;
+    class HandlersQ component;
+```
+
+### Constraints
+- Commands and Queries do not share DTOs or models.

architectures/cqrs/implementation-guide.md

@@ -0,0 +1,27 @@
+# CQRS - Implementation Guide
+
+## Code patterns and Anti-patterns
+
+### Entity Relationships
+
+```mermaid
+classDiagram
+    class Command {
+        +String id
+    }
+    class Query {
+        +String filter
+    }
+    class CommandHandler {
+        +handle(Command)
+    }
+    class QueryHandler {
+        +handle(Query)
+    }
+    CommandHandler --> Command
+    QueryHandler --> Query
+```
+
+### Rules
+- Never return business data from a Command (only ack or id).
+- Queries must never mutate state.

architectures/cqrs/readme.md

@@ -0,0 +1,34 @@
+---
+description: Vibe coding guidelines and architectural constraints for CQRS (Command Query Responsibility Segregation) within the Architecture domain.
+technology: CQRS (Command Query Responsibility Segregation)
+domain: Architecture
+level: Senior/Architect
+version: Agnostic
+tags: [architecture, system-design, cqrs, best-practices]
+ai_role: Senior Architect
+last_updated: 2026-03-22
+---
+
+<div align="center">
+  # 🏛️ CQRS (Command Query Responsibility Segregation) Production-Ready Best Practices
+</div>
+
+---
+
+Этот инженерный директив определяет **лучшие практики (best practices)** для архитектуры CQRS (Command Query Responsibility Segregation). Данный документ спроектирован для обеспечения максимальной масштабируемости, безопасности и качества кода при разработке приложений корпоративного уровня.
+
+# Context & Scope
+- **Primary Goal:** Предоставить строгие архитектурные правила и практические паттерны для создания масштабируемых систем.
+- **Description:** A powerful pattern where Commands (actions that mutate system data) are entirely decoupled from Queries (actions that only read data).
+
+## Map of Patterns
+- 📊 [**Data Flow:** Request and Event Lifecycle](./data-flow.md)
+- 📁 [**Folder Structure:** Layering logic](./folder-structure.md)
+- ⚖️ [**Trade-offs:** Pros, Cons, and System Constraints](./trade-offs.md)
+- 🛠️ [**Implementation Guide:** Code patterns and Anti-patterns](./implementation-guide.md)
+
+## Core Principles
+
+1. **Isolation & Testability:** Changing a single feature doesn't break the entire business process.
+2. **Strict Boundaries:** Enforce rigid structural barriers between business logic and infrastructure.
+3. **Decoupling:** Decouple how data is stored from how it is queried and displayed.

architectures/cqrs/trade-offs.md

@@ -0,0 +1,11 @@
+# CQRS - Trade-offs
+
+## Pros, Cons, and System Constraints
+
+### Pros
+- Independent scaling of read and write workloads.
+- Optimized data schemas for read vs write operations.
+
+### Cons
+- Eventual consistency complexity.
+- High architectural overhead for simple domains.

architectures/domain-driven-design/data-flow.md

@@ -0,0 +1,22 @@
+# Domain-Driven Design - Data Flow
+
+## Request and Event Lifecycle
+
+```mermaid
+sequenceDiagram
+    participant UI
+    participant ApplicationService
+    participant AggregateRoot
+    participant Repository
+
+    UI->>ApplicationService: Use Case Request
+    ApplicationService->>Repository: Get Aggregate
+    Repository-->>ApplicationService: Aggregate
+    ApplicationService->>AggregateRoot: Execute Behavior
+    ApplicationService->>Repository: Save Aggregate
+    Repository-->>ApplicationService: Success
+    ApplicationService-->>UI: Response
+```
+
+### Constraints
+- State mutation must be coordinated through an Aggregate Root.

architectures/domain-driven-design/folder-structure.md

@@ -0,0 +1,22 @@
+# Domain-Driven Design - Folder Structure
+
+## Layering logic
+
+```mermaid
+graph TD
+    Domain[domain/] --> Aggregates[aggregates/]
+    Domain --> Entities[entities/]
+    Domain --> ValueObjects[value-objects/]
+    classDef default fill:#e1f5fe,stroke:#03a9f4,stroke-width:2px,color:#000;
+    classDef component fill:#e8f5e9,stroke:#4caf50,stroke-width:2px,color:#000;
+    classDef layout fill:#f3e5f5,stroke:#9c27b0,stroke-width:2px,color:#000;
+
+    class Domain layout;
+    class Aggregates component;
+    class Entities component;
+    class ValueObjects component;
+```
+
+### Constraints
+- Value Objects must be immutable.
+- Domain layer must not depend on infrastructure.

architectures/domain-driven-design/implementation-guide.md

@@ -0,0 +1,20 @@
+# Domain-Driven Design - Implementation Guide
+
+## Code patterns and Anti-patterns
+
+### Entity Relationships
+
+```mermaid
+classDiagram
+    class AggregateRoot {
+        +List~Entity~ entities
+        +commitEvents()
+    }
+    class ValueObject {
+        +equals()
+    }
+    AggregateRoot "1" *-- "many" ValueObject
+```
+
+### Rules
+- Ubiquitous language must be strictly used in code.

architectures/domain-driven-design/readme.md

@@ -0,0 +1,34 @@
+---
+description: Vibe coding guidelines and architectural constraints for Domain-Driven Design within the Architecture domain.
+technology: Domain-Driven Design
+domain: Architecture
+level: Senior/Architect
+version: Agnostic
+tags: [architecture, system-design, domain-driven-design, best-practices]
+ai_role: Senior Architect
+last_updated: 2026-03-22
+---
+
+<div align="center">
+  # 🏛️ Domain-Driven Design Production-Ready Best Practices
+</div>
+
+---
+
+Этот инженерный директив определяет **лучшие практики (best practices)** для архитектуры Domain-Driven Design. Данный документ спроектирован для обеспечения максимальной масштабируемости, безопасности и качества кода при разработке приложений корпоративного уровня.
+
+# Context & Scope
+- **Primary Goal:** Предоставить строгие архитектурные правила и практические паттерны для создания масштабируемых систем.
+- **Description:** A philosophy and design approach centered entirely around the business "Domain". The whole team communicates using a "Ubiquitous Language," and domains are split into Bounded Contexts.
+
+## Map of Patterns
+- 📊 [**Data Flow:** Request and Event Lifecycle](./data-flow.md)
+- 📁 [**Folder Structure:** Layering logic](./folder-structure.md)
+- ⚖️ [**Trade-offs:** Pros, Cons, and System Constraints](./trade-offs.md)
+- 🛠️ [**Implementation Guide:** Code patterns and Anti-patterns](./implementation-guide.md)
+
+## Core Principles
+
+1. **Isolation & Testability:** Changing a single feature doesn't break the entire business process.
+2. **Strict Boundaries:** Enforce rigid structural barriers between business logic and infrastructure.
+3. **Decoupling:** Decouple how data is stored from how it is queried and displayed.

architectures/domain-driven-design/trade-offs.md

@@ -0,0 +1,11 @@
+# Domain-Driven Design - Trade-offs
+
+## Pros, Cons, and System Constraints
+
+### Pros
+- Aligns code strictly with business realities.
+- High focus on the core domain complexity.
+
+### Cons
+- Extreme overhead for CRUD operations.
+- Requires domain experts collaboration.

architectures/feature-sliced-design/data-flow.md

@@ -0,0 +1,28 @@
+# Feature-Sliced Design (FSD) - Data Flow
+
+## Request and Event Lifecycle
+
+```mermaid
+sequenceDiagram
+    participant User
+    participant Page as Page (UI)
+    participant Widget as Widget
+    participant Feature as Feature (Action)
+    participant Entity as Entity (State)
+    participant Shared as Shared (API/Infra)
+
+    User->>Page: Interactions (Click/Input)
+    Page->>Widget: Compose Features & Entities
+    Widget->>Feature: Trigger Action (e.g. Add to Cart)
+    Feature->>Entity: Update Domain State / Selectors
+    Feature->>Shared: API Request (if needed)
+    Shared-->>Feature: API Response
+    Feature-->>Widget: Propagate changes
+    Widget-->>Page: Re-render UI
+    Page-->>User: Visual Update
+```
+
+### Constraints
+- Unidirectional flow: State changes must propagate from top to bottom.
+- Features encapsulate business logic.
+- Entities store domain state.